Tendril – a self-extending agent that builds and registers its own tools | AI Paper Digest

TL;DR Highlight

Tendril demonstrates a self-extending AI agent pattern by dynamically writing and registering tools when needed, creating a growing repository of capabilities with each session.

Who Should Read

Backend/full-stack developers building LLM-powered agents who face repetitive problem-solving or token waste across sessions. AI application developers designing how and when agents should utilize tools.

Core Mechanics

Tendril serves as a reference implementation of the 'Agent Capability Pattern', where agents search existing tools, write and register new ones if missing, and execute them directly if available.
A core design constraint is prohibiting direct code execution; agents must register tools before running them, automatically building a reusable toolset that accumulates across sessions.
The agent loop relies on only three bootstrap tools—searchCapabilities, registerCapability, and execute—with the agent creating the rest. It's powered by AWS Strands TypeScript SDK and Bedrock (Claude Sonnet).
Tool execution is sandboxed using Deno subprocesses, and the desktop shell is built with Tauri + React.
Testing the self-extending loop with five local open-source models (Qwen3-8B, Gemma 4, Mistral Small 3.1, Devstral Small 2, Salesforce xLAM-2) resulted in complete failure, with each model exhibiting unique failure patterns detailed in a separate post.
Tendril addresses the 'WHEN problem'—most agent frameworks define WHAT tools do and HOW to call them, but lack a structured approach to determine WHEN to use them. Tendril encodes this decision logic as rules within the system prompt.
The registry structure is simple CRUD-based on index.json, and the source code is organized into agent.ts, loop/(tools, prompt, registry, sandbox), and transport/(protocol, stream, errors).

Evidence

"Concerns were raised about the registry becoming noisy with accumulated sessions, leading to overspecialized tools, duplication, and API inconsistencies. One developer shared experience building a similar system called 'Saved Programs' to avoid token waste from repetitive problem-solving. Another developer highlighted the need for a network-based reflection and type system for effective tool registries, having built a custom distributed type system (gluon) after struggling with MCP/Skills. Criticism arose regarding the rule-based (if X then Y) approach to the 'WHEN' problem, with some finding success by describing the current state instead of prescribing rules. The importance of complexity management as the registry grows was emphasized, specifically addressing context understanding, knowledge retention, and performance monitoring."

How to Apply

"If your agent repeatedly generates the same API calls or data processing code, introducing Tendril’s searchCapabilities → registerCapability → execute pattern can enable reuse without rebuilding. If you already use AWS Strands TypeScript SDK and Bedrock (Claude Sonnet), you can adapt Tendril’s tendril-agent/src/ structure, including the capability registry (index.json CRUD) and Deno sandbox execution layer. When building self-extending agents with local open-source models (Qwen3-8B, Gemma 4, etc.), consider that Tendril’s tests failed with all five models, suggesting a more powerful model like Claude Sonnet is currently necessary. To carry learnings across sessions, implement a routine to explicitly document what the agent learned and how it improved, similar to the '/learn command' mentioned in the comments."

Code Example

snippet

// Tendril agent loop example (based on README)
// First request: No tools → Create tool and execute
You: "fetch the top stories from Hacker News"
Tendril:
  → searchCapabilities("fetch url hacker news")  // Search registry → Not found
  → registerCapability(fetch_url, code)           // Write and register tool code
  → execute("fetch_url", {url: "https://..."})   // Execute registered tool
  → "Here are the top stories: ..."

// Second request: Reuse tool
You: "now fetch Lobsters and compare"
Tendril:
  → listCapabilities()                             // Search registry → Found fetch_url!
  → execute("fetch_url", {url: "https://lobste.rs"}) // Execute directly without rebuilding

// Directory structure
// tendril-agent/src/
// ├── agent.ts        ← Strands agent + Bedrock model configuration
// ├── index.ts        ← Orchestrator
// ├── loop/
// │   ├── tools.ts    ← 3 bootstrap tools
// │   ├── prompt.ts   ← System prompt (rules for autonomous behavior)
// │   ├── registry.ts ← Capability registry (index.json CRUD)
// │   └── sandbox.ts  ← Deno subprocess sandbox execution
// └── transport/
//     ├── protocol.ts ← ACP JSON-RPC over stdio
//     ├── stream.ts   ← SDK events → loop stage transformation
//     └── errors.ts   ← Provider error classification

Terminology

Agent Capability PatternA design pattern where agents autonomously create and register tools to reuse for tasks. The tool list isn't fixed but grows with use.

bootstrap toolsThe minimal set of tools an agent possesses at startup. Tendril uses only three—search, register, and execute—with the agent creating the rest.

Deno sandboxA method of running the Deno runtime as an isolated subprocess. This prevents agent-created code from directly accessing the system.

Strands Agents SDKAn AI agent building SDK from AWS, based on TypeScript. It simplifies agent loop construction and tool invocation with Bedrock models.

capability registryA storage repository for agent-created tools and their metadata. Tendril manages it with an index.json file, persisting across sessions.

self-extending agentAn agent capable of writing and registering new functionalities (tools) to expand its abilities. It eliminates the need for humans to pre-define all tools.

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