Moving an agent definition into Postgres leaves seven lines of Python on disk

The chain starts with a string literal. The generated module calls to_agent(agent_name='agent1'); to_agent strips the word "agent" off that argument, casts what is left to an integer, and uses it as the key for get_agent_details ^[6][5]. The rest follows from the record. The agent_tools column is parsed into a list of ids, and then load_agent_tools_functions, load_mcp_servers and load_agent_skills_toolset attach the callables ^[7]. Instruction, model, sub-agents, guardrails and output schema are all read at load time ^[8].

In the tested stack the row read article_demo while the folder and the module argument read agent1 ^[9][5]. The display name and the lookup key are separate. Renaming an agent in the interface rewrites a column and leaves the stub pointing at id 1 ^[11]. The generated file also carries a comment naming a package the project has since renamed ^[5]. A row can be incomplete too: the creation form accepts an empty API key, so a definition exists before any credential does and cannot answer until one is added ^[12].

Derived state on a filesystem drifts. The post lists three ways it happens: a volume restored without its database, one environment synced onto another so a folder goes missing, and a package rename that leaves a stub importing a module that is gone ^[13]. All three arrive as the same ModuleNotFoundError the first time a user talks to that agent ^[13].

The repair is the part I would copy. ensure_agent_modules runs inside the single bootstrap() behind the ASGI lifespan ^[19]. Its docstring states the contract: "Auto-repair: regenerate missing *or stale* agent.py files for every agent," called at startup "so an environment heals itself on its next restart rather than waiting for someone to save each agent by hand" ^[14]. Staleness is the half that takes thought, because a present-but-broken file passes an os.path.exists check ^[15]. What the repair tests for is the single import line every generated stub carries, and a stub somebody has genuinely customised that still imports the core is left alone ^[16].

The post's case for the whole design is a scale threshold. The committed file is a good default, it says, and it holds until a non-engineer needs to change a prompt, or until you are running forty agents for twelve teams and every wording fix has become a release ^[17]. Forty across twelve is a bit over three agents a team ^[20]. What pushes you over is the number of people waiting on a deploy, not the number of agents. For one team and a handful of agents, git already gives you the version history and the review. The post describes the editing surface as an API and a UI, and does not describe a version history for the rows ^[18][21].