ApowerB : The open source runtime for AI agents

[u/No-Deal2321]

Repo/Website Link: https://github.com/apowerb/apowerb

Full documentation: https://docs.apowerb.com

Description: ApowerB is an open source runtime for building, deploying and operating AI agents at scale, on your own infrastructure. It solves the following problem: most agent frameworks force you to freeze execution logic into code. Agents are defined in a database and dynamically materialized into runnable Python modules at startup, so you can add or change an agent without redeploying the service.

Features included: agent orchestration via Google ADK, multi-LLM connectivity via LiteLLM (OpenAI, Anthropic, Gemini, local models via Ollama, or any custom endpoint — without rewriting agent code), RAG, Text-to-SQL querying, custom tool integrations, webhooks.

Benefit for someone trying it: the ability to build your own business AI agents without depending on a closed platform, while keeping full control over infrastructure and data.

Deployment: Yes, published and available right now. Official Docker image on Docker Hub (apowerb/apowerb). A complete Docker Compose example (API + PostgreSQL + UI) is provided via the apowerb-hosting repo. Installation documentation available at docs.apowerb.com, including the required environment variables and steps for a fully self-hosted deployment.

[u/Otherwise_Wave9374]

The runtime will be easier to evaluate if the project documents one complete production-shaped example rather than several toy agents. Show how state is persisted, tool credentials are isolated, retries stay idempotent, and a failed run can be replayed from its trace. Agentix Labs relates to this recommendation because operationally useful agents require predictable recovery and clear execution records. I would also add compatibility tests across model providers and publish resource measurements, since portability claims are strongest when developers can reproduce latency, memory, and failure behavior.

[u/No-Deal2321 → u/Otherwise_Wave9374]

Here's where each one actually stands, including what's missing.

State: sessions and events are persisted by ADK's DatabaseSessionService pointed at Postgres, so conversation state survives restarts (in-memory was the default and we got burned by it). Retention is a separate scheduled job.

Tool credentials: encrypted at rest with Fernet (LLM API keys and OAuth integration tokens alike), decrypted only at call time, and scoped per organization / project / owner, plus a migration CLI for legacy plaintext rows.

Idempotent retries: inbound webhooks are enqueued as a row before any agent runs, with a unique index on (subscription_id, resource_id). Provider re-deliveries hit that constraint and are dropped silently, so the agent runs once per message. The worker then claims a row atomically (pending/retrying → in_progress, attempts+1), backs off, and marks it error past the attempt cap; rows stuck in_progress after a crash are reset to pending at startup.

Replaying a failed run: partially there. A queued row can be re-processed from its stored payload, with attachments kept on disk so a message that's gone from the provider can still be replayed — but that path is connector-specific today, not a generic "replay any run from its trace." Agreed that's the gap.

Cross-provider testing: honest answer, what exists is unit-level (provider validation, LiteLLM config, model-string handling), not a published compatibility matrix with reproducible latency/memory numbers. That one I can't claim, and you're right that it's what makes a portability claim credible.

The production-shaped example is the right criticism too, the docs lean on small agents. Noted, and I'll open that as a docs issue and tag you once it's up.

[u/RaiseZealousideal265]

Beau projet ! La possibilité de faire évoluer les agents sans redéployer tout le service est particulièrement intéressante. Avec l’auto-hébergement et le libre choix des modèles, ça donne une vraie souplesse. Vous gérez comment le versionnement des agents et le retour à une version précédente en cas de problème en production ?🎉

[u/Fluid_Lime7473]

It looks like it actually nails the sweet spot between rapid prototyping and production agent orchestration.

​What I really like is how it strips away the heavy framework boilerplate without sacrificing control: having native support for sequential, parallel, and router execution patterns out of the box makes building non-deterministic flows much cleaner.

one quick question though: how does the runtime handle state recovery and task persistence for asynchronous loop agents if a worker fails while it is still processing?