I built this while working on a coding agent that kept starting cold every session. The deeper problem was that agent frameworks give you what a tool does and how to call it, but no structured answer to when — when should a tool fire autonomously, and when should it stay silent. That judgement is always implicit, scattered across system prompts and tool descriptions.
Tendril is a reference implementation of what I'm calling the Agent Capability pattern. It starts with three bootstrap tools and builds everything else itself. The key constraint: there's no direct code execution. The agent can only run registered capabilities, so every task forces it to write a tool, define its invocation conditions, and register it for future sessions. The registry accumulates across sessions.
I also ran the self-extending loop against five local models — Qwen3-8B, Gemma 4, Mistral Small 3.1, Devstral Small 2, Salesforce xLAM-2. None passed.
I did something that sounds similar for my home assistant.
The agent never executes anything. It has like four tools… search, execute, build, update.
The tool service runs vector search against the tools catalog.
The build runs authoring with review steps, declaring needed credentials and network access.
The adversarial reviewer can reject back to the authoring three times.
After passing, the tool is registered and embeddings are done for search.
Credentials are stores encrypted, and only get injected by tools catalog service during tool execution. The network resources are declared so tool function execution can be better sandboxed. The agent never has access to credentials and cannot do anything without going through vetted functions in the tool service.
Agent, author process, reviewer, embedding… all can be different models running local or remote.
Event bus, agent, tool service… all separate containers.
I have an url if you want to read a bit about what I did.
You can list the uses of the available tools in the AGENTS. I keep my agents on a tight leash, and self-extension runs counter to this. I would not my agent to spontaneously develop the ability to tap my bank account, for example.
It's really cool to see that other people run into the same issues and arrive at the same conclusions/solution.
At $DAYJOB, we have an LLM-based tool and this issue of "how do we avoid burning tokens solving the same problems over again" was an early obstacle
We wound up building a very similar thing to what you call "tools" (we named them "Saved Programs").
There's a wiki the LLM searches before solving a problem, that links saved programs for past actions to their content entry.
If it finds one, it'll re-use it, otherwise it'll generate a program and offer to save it, if you think it'll be common enough.
> how do we avoid burning tokens solving the same problems over again
Letting the LLM write half baked tools is the recipe for burning more tokens.
> There's a wiki the LLM searches before solving a problem, that links saved programs for past actions to their content entry.
What's the criteria for marking an LLM written tool as useful/correct before publishing it?
I built this while working on a coding agent that kept starting cold every session. The deeper problem was that agent frameworks give you what a tool does and how to call it, but no structured answer to when — when should a tool fire autonomously, and when should it stay silent. That judgement is always implicit, scattered across system prompts and tool descriptions.
Tendril is a reference implementation of what I'm calling the Agent Capability pattern. It starts with three bootstrap tools and builds everything else itself. The key constraint: there's no direct code execution. The agent can only run registered capabilities, so every task forces it to write a tool, define its invocation conditions, and register it for future sessions. The registry accumulates across sessions.
I also ran the self-extending loop against five local models — Qwen3-8B, Gemma 4, Mistral Small 3.1, Devstral Small 2, Salesforce xLAM-2. None passed.
The failure modes were distinct enough to be worth writing up separately: https://serverlessdna.com/strands/ai-agents/agents-know-what...
Stack: AWS Strands TypeScript SDK, Bedrock (Claude Sonnet), Deno sandbox, Tauri + React desktop shell.
I did something that sounds similar for my home assistant.
The agent never executes anything. It has like four tools… search, execute, build, update.
The tool service runs vector search against the tools catalog.
The build runs authoring with review steps, declaring needed credentials and network access.
The adversarial reviewer can reject back to the authoring three times.
After passing, the tool is registered and embeddings are done for search.
Credentials are stores encrypted, and only get injected by tools catalog service during tool execution. The network resources are declared so tool function execution can be better sandboxed. The agent never has access to credentials and cannot do anything without going through vetted functions in the tool service.
Agent, author process, reviewer, embedding… all can be different models running local or remote.
Event bus, agent, tool service… all separate containers.
I have an url if you want to read a bit about what I did.
You can list the uses of the available tools in the AGENTS. I keep my agents on a tight leash, and self-extension runs counter to this. I would not my agent to spontaneously develop the ability to tap my bank account, for example.
So basically you've built a mechanism for a model to de-compress itself.