Tendril is an agentic sandbox where a model always sees exactly three bootstrap tools, then searches, writes, and reuses TypeScript capabilities stored as plain files across sessions.
Key Takeaways
The core loop uses three tools only: listCapabilities, registerCapability, and executeCode — the tool surface stays fixed while the registry grows.
Capabilities persist as TypeScript files in a workspace directory (~/tendril-workspace/tools/*.ts), each with name, description, triggers, and suppression rules the model writes itself.
Code runs in a sandboxed Deno subprocess with scoped permissions; allowedDomains in config restricts network access per capability.
Implements the Agent Integrator Specification (ACP) — the same JSON-RPC 2.0/NDJSON stdio protocol used by Claude Code — making it composable with existing agent hosts.
The author’s stated core insight — that WHEN to call a tool is upstream of WHAT and HOW, and most frameworks leave this implicit — resonated strongly; commenters working on their own registries independently arrived at the same gap.
The registry-rot problem is the main practical objection: after many sessions, tools accumulate that are overly task-specific, creating redundancy and inconsistent APIs that degrade rather than improve model performance.
Multiple builders reported parallel work: “Saved Programs” + a searchable wiki at one company, a collector-style registry at another, and a dual-LLM router/thinker architecture with deterministic TSX skills — suggesting this pattern is converging across independent teams.
Notable Comments
@namuol: flags registry noise as the core long-term risk — highly specific tools accumulate, creating redundancy and API inconsistency that compounds over time.
@mtrifonov: argues the “when” framing is the real contribution — over-firing burns tokens, under-firing stalls agents, and neither problem is solved by better tool descriptions alone.
