Corey James- 7 of 14function crates in the estate carry the generator's fingerprints
- 14 filesper function: eight framework, six sandboxed
- 4places written in one rollback-protected transaction per generation
My agents could call tools and could not add one. Every new capability meant a human wiring a crate into the gateway, the orchestrator and the result path by hand. I built a generator, exposed as a tool, that lets an agent author a new function for the estate. The generated code runs in a sandbox that sees only a capability-bounded context, cannot open its own connections or write the database directly, and runs only after a human rebuilds and restarts the gateway.
The challenge
AI-written processing code, given a database handle, will build unsafe queries, write tables it should not, and open connections nobody audits. And a tool that is half-registered, present in the gateway and absent from the result path, shows up as a hang. The generator had to make adding a capability cheap for an agent while making it impossible for that capability to bypass the rules the rest of the estate lives under.
Self-extending systems are where safety usually goes to die.
Constraints
Nothing runs without a human. Data-safety rules apply to generated code exactly as to hand-written code. Clean removal, so deleting a generated function is as thorough as creating it. No gateway restart from inside a call, because the restart would cut off the agent that asked for it.
My approach
Treat AI agents as bounded authors. The generator is itself an MCP tool. What it produces is split: framework files the author must not modify, and a developer zone where the author writes logic against a context object, never against raw resources. The human gate sits exactly at the privileged step, the rebuild and restart, and nowhere else.
What I built
A Rust generator that emits the function and edits the services it touches in one rollback-protected transaction. A symmetric delete reverses all of it.
Link-time registration, so a function is fully wired or the build fails. There is no half-registered state.
A compiled-in authoring guide that travels with the generated code.
The sandbox boundary: reads go through a schema resolver that validates every identifier, writes go only through the governed queue, raw connection pools are excluded, and the escalation path for anything the context does not offer is a filed enhancement request.
Difficult decisions
Redesigning after a self-audit. The first version passed its own fifteen-point integration check and generated code that did not compile. I redesigned it with the sandbox and inverted ownership instead of patching it.
No hot-loading. Rebuild and human restart is slower than hot-loading a new function. It is the governance step, and I kept it.
Bootstrap only, because an update would overwrite the developer zone.
Stubs over shortcuts. Some context features, such as vector search, were left as stubs instead of being wired through an unsafe path.
Results
The generated crates include mining, swarm management, the persona launcher and vector-store management.
Technologies used
Rust · Handlebars templates · Model Context Protocol and JSON-RPC · Link-time registration · YAML schema compilation · PostgreSQL · Transactional multi-service edits
What this demonstrates
Self-extending AI systems that stay operable and safe, with security achieved by API design, and the willingness to throw away a first version that passed its own tests.