Agents in the database, not in the repo: a tour of apowerb

Description and use

apowerb stores agents in a database, generating lightweight Python stubs at runtime, enabling updates without redeploy. Editing a row triggers /reload to clear caches and rebuild the agent, applying changes instantly.

Problem

Managing agent definitions via code commits becomes cumbersome when many agents or non-engineers need to update prompts, leading to frequent releases.

Outcome

apowerb enables rapid, non-developer agent updates by storing definitions in a database and auto-generating stubs, reducing deployment overhead while maintaining consistency through boot-time repair and runtime reloads.

Workflow

• Create or edit an agent via the UI or API, which writes a row in Postgres.
• The runtime generates a stub in agents_pool/agentX/agent.py that imports a loader.
• On startup, ensure_agent_modules repairs missing or stale stubs based on database state.
• When an agent row is updated, POST /api/agents/{id}/reload invalidates in-memory modules and caches.
• The next request rebuilds the agent from the updated database row, applying changes immediately.
• If reload fails, warnings are logged but the UI shows a success toast; the old definition may persist until a restart.

Evidence

Changing an agent is an UPDATE, not a deploy.

Source

The boot sequence reconciles instead of trusting.

Source

POST /api/agents/{id}/reload drops the agent's modules from sys.modules and from the loader cache.

Source