I moved the agent topology out of my code and into the database

Description and use

Moving agent topology from code to the database reduced deployment overhead, enabled domain experts to edit agent behavior via an admin panel, and introduced multi‑agent workflows that catch errors without code changes.

Problem

Developers spent a month building invisible infrastructure—agent loops, tool registries, data storage, and workflow rules—each change requiring a deploy, making maintenance costly and opaque.

Outcome

Moving agent topology to the database reduced deployment overhead, enabled non‑technical domain experts to edit agent behavior, and introduced multi‑agent workflows that catch errors without code changes.

Workflow

• 1. Define tools as OpenAI function specs with editable Python bodies in the tools table.
• 2. Create skills that bundle instructions and required tools, stored in skills and skill_tool tables.
• 3. Assemble agents with system prompts and associated skills, stored in agents and agent_skill tables.
• 4. Design workflow graphs (start/group/stop) in projects.workflow JSON to control agent order and delegation.
• 5. Store domain data and schema descriptions in real tables; column descriptions serve as prompts for tools.
• 6. Use a context tool to run pre‑message logic, stored in agent_context_tools.
• 7. Run agents via a single uvicorn worker; tool bodies execute with full builtins and are admin‑reviewed.
• 8. Admins edit tool bodies or agent prompts through the panel; changes cache by body hash and apply to next message.

Evidence

I built it once. I open‑sourced it as CerebrumKit.

Source

Editing a tool body in the panel takes effect on the next message.

Source

Tool bodies are code execution. They run with full builtins and are not sandboxed.

Source