Every AI agent framework on the market has the same ceiling.
The agent is exactly as capable as the tools somebody pre-built for it.
Missing tool? That is a feature request. A feature request means a human in the loop. A human in the loop means the answer arrives in weeks, and the conversation that needed it ended weeks ago.
The entire industry has quietly accepted this. MCP servers, function schemas, tool registries — all of it is humans hand-carving capabilities in advance, hoping they guessed what the agent will need.
My LLM does not wait for a toolbox.
When it needs a tool that does not exist, it forges one. On demand. Mid-conversation. In production. And the tool is still there tomorrow.
Here is a tool that did not exist two minutes before this recording.
Why nobody else does this
Let us be honest about why this is rare.
Letting an LLM write and execute its own code in production is, in every mainstream stack, insane.
In Python or JavaScript, generated code is free-form code. Free-form code is arbitrary code execution. The generated function can import anything, call anything, reach anything the process can reach. One over-eager generation, one prompt injection hiding in a scraped web page, and your "self-improving agent" is running an attacker's wishlist with your database credentials.
So the industry made the sane choice for its architecture. Freeze the toolbox. Have humans write every tool, review every tool, deploy every tool. Safe — and frozen solid.
The problem was never that self-growing tools are a bad idea.
The problem is that free-form languages make them unsurvivable.
What growing a tool actually looks like
Here is the flow, concretely.
An AI agent talks to Magic over MCP. Somewhere in a conversation it hits a wall — it needs a capability that is not in its tool list. Maybe "give me the ten customers with the most unpaid invoices, as CSV". There is no such tool.
So it describes the missing capability in a sentence, and hands that sentence to the Hyperlambda generator.
The generator emits Hyperlambda — not free-form source code, but an execution tree where every executable node is the name of a function the runtime knows about. The result is saved as a real endpoint. The agent invokes it immediately, gets its answer, and moves on with the conversation.
And here is the part that compounds: the tool persists. It shows up in the tool list from now on. The agent that runs tomorrow is more capable than the agent that ran today, because today's agent did some blacksmithing.
No deploy. No pull request. No human carving capabilities in advance.
Which should worry you — unless something is standing between "the model generated code" and "the code ran".
Three things are.
Lock one: it cannot reference what does not exist
Before generated code is even returned, the runtime statically walks every executable statement in it — at every nesting depth — and checks each one against the registry of functions that actually exist.
A hallucinated function is not a runtime incident. It is a named, mechanical verdict: false, plus the exact names of everything that does not exist. Those names go straight back into the generator, which tries again. Code leaves the loop only when every single instruction is proven to exist.
I wrote a whole article about this gate, because it is the reason the generator cannot hallucinate — not "rarely hallucinates", cannot.
For tool-growing, it means the forge only produces tools made of real metal.
Lock two: it cannot reach outside its envelope
Existing is not the same as permitted.
Generated code executes inside [whitelist] — a declared vocabulary of exactly which functions the code may invoke. Not "which functions exist", but "which functions you decided this code may touch". Everything outside the list fails before it executes.
And the whitelist pins more than names. It can pin arguments. If the envelope says the code connects to this database, or reads this file, no amount of creative generation talks it into a different one. The value is pinned at the boundary; the generated code never gets a say.
So even a perfectly valid tool — every function real, every argument well-typed — runs inside a capability envelope with walls it cannot see over. A prompt injection that successfully manipulates the generation still produces code that can only do what the envelope allows.
I have written about this gate too: how I use whitelist to execute partially untrusted Hyperlambda safely.
Lock three: it cannot run for the wrong person
The third lock is the oldest idea in the room, applied in the right place.
Every tool the agent grows is a real endpoint, and every endpoint in Magic is guarded by role-based access control enforced by the runtime itself — per function, per role, at the execution layer. Not middleware the generator was trusted to emit. Not an auth check the model hopefully remembered to include. The runtime's own gate, the same one guarding every human-written endpoint in the system.
A freshly grown tool is untrusted the way a new employee is untrusted. It gets a badge. The badge opens certain doors. It does not get a master key because it happened to be born yesterday.
The fine print, up front
Big claims deserve precise edges, so here is exactly what "securely" means in that headline.
It means a grown tool cannot invoke what does not exist. It cannot reach outside its declared envelope. It cannot run for a role that is not authorized to run it. Those three properties are enforced by the runtime, and none of them depend on the model behaving.
It does not mean the generated logic is automatically smart. Ask for the wrong tool and you will get a faithful implementation of the wrong tool — the same guarantee human developers have offered since the beginning of time. Bad requirements still make bad tools.
The difference is the blast radius. A badly specified tool in a free-form stack can do anything the process can do. A badly specified tool in this stack can disappoint you, inside its envelope, visibly, and get regenerated ten seconds later.
Why I think this is the endgame for agents
Fixed toolboxes do not scale to the long tail of real business needs — and the long tail is exactly where agents are supposed to shine. Nobody is going to hand-write an MCP tool for every report, every export, every one-off integration question every department will ever ask. The economics do not work, and the latency kills the conversation.
Self-growing tools fix the economics. The agent adapts at the speed of conversation, the capability library compounds daily, and the blast radius stays constant, because the boundaries live in the runtime and the runtime does not negotiate.
All of it is open source and MIT-licensed. Audit the locks yourself — the best security arguments are the ones you can read.
The first LLM that cannot hallucinate was a dumber runtime refusing to be impressed.
The only LLM that grows its own tools is that same runtime — finally willing to say yes, because it knows exactly what it is saying yes to.