Tendril – a self-extending agent that builds and registers its own tools

Tendril A self-extending agentic sandbox that demonstrates the Agent Capability pattern — where the model discovers, builds, and reuses tools autonomously across sessions. Built with AWS Strands Agents SDK and Tauri. What it does You ask Tendril to do something. It checks its capability registry. If a tool exists, it uses it. If not, it writes one, registers it, and executes it — all without asking. Next time you need the same thing, the tool is already there. You: "fetch the top stories from Hacker News" Tendril: → searchCapabilities("fetch url hacker news") # nothing found → registerCapability(fetch_url, code) # builds a tool → execute("fetch_url", {url: "https://..."}) # runs it by name → "Here are the top stories: ..." You: "now fetch Lobsters and compare" Tendril: → listCapabilities() # found: fetch_url ✓ → execute("fetch_url", {url: "https://lobste.rs"})# runs it — no rebuild The registry grows with use. Every session is smarter than the last. The Agent Loop The core of Tendril is a Strands agent with three bootstrap tools. That's it — three tools to rule them all. Where it lives tendril-agent/src/ ├── agent.ts ← Agent configuration (Strands model + tools) ├── index.ts ← Orchestrator — wires loop to transport ├── loop/ ← The agentic loop │ ├── tools.ts ← 4 bootstrap tools in cycle order │ ├── prompt.ts ← System prompt (autonomous behaviour rules) │ ├── registry.ts ← Capability registry (index.json CRUD) │ └── sandbox.ts ← Deno subprocess execution with sandboxing └── transport/ ← Conversation framing + stream observation ├── protocol.ts ← ACP JSON-RPC over stdio ├── stream.ts ← SDK events → loop phases (think/act/observe) └── errors.ts ← Provider error classification How it works agent.ts — Creates the Strands agent with a Bedrock model and three tools: import { Agent } from '@strands-agents/sdk'; import { BedrockModel } from '@strands-agents/sdk/models/bedrock'; const agent = new Agent({ model: new BedrockModel({ modelId: '...', region: '...' }), systemPrompt: TENDRIL_SYSTEM_PROMPT(workspacePath), printer: nullPrinter, // suppress SDK stdout — we own the protocol tools: [ listCapabilities(registry), registerCapability(registry), executeCode(registry, workspacePath, config), ], }); index.ts — Observes the agentic loop and bridges it to the ACP protocol: // The agentic loop runs inside agent.stream(). // We observe each phase and forward to the UI. for await (const event of agent.stream(userText)) { const { phase, event: e } = classifyEvent(event); switch (phase) { case 'think': emitUpdate(handleThink(e)); break; // text delta case 'act': emitUpdate(handleAct(e)); break; // tool call case 'observe': emitUpdate(handleObserve(e)); break; // tool result } } loop/prompt.ts — The system prompt that makes the agent autonomous: BEFORE acting on any request: 1. Call searchCapabilities(query) to check if a relevant tool exists 2. If found: call loadTool(name) then execute(code, args) 3. If NOT found: you MUST build the tool yourself. RULES: - NEVER ask "would you like me to create a tool?" — just build it. - If a tool fails, read the error, fix the code, and retry. - NEVER answer from training data when a tool could get live information. The "too many tools" solution Most agent frameworks give the model a big bag of tools and hope it picks the right one. Tendril inverts this — the model always sees exactly three tools. It searches a registry, builds what it needs, and the registry grows over time. The tool surface never changes; the…

This excerpt is published under fair use for community discussion. Read the full article at GitHub.