Tendril boundary

Type: agentic-system-analyses/types/agentic-system-boundary.md

Boundary and evidence

This run covers Tendril as a shipped desktop agent system, not just its capability-registry API. Its intended use is to answer user requests by selecting existing tools or authoring and retaining new TypeScript capabilities for later execution. The target qualifies as an agent runtime: its Node sidecar constructs a model-backed Strands agent, streams user prompts through it and supplies callbacks that write and execute capabilities. The shipped Tauri host and React client are inside the boundary. They initialize the workspace, launch and restart the sidecar, submit prompts, expose retained capabilities and permit workspace-file editing (SRC-1, tendril-agent/src/agent.ts, tendril-agent/src/index.ts, tendril-ui/src/App.tsx, tendril-ui/src-tauri/src/lib.rs, tendril-ui/src-tauri/src/workspace.rs, tendril-ui/src-tauri/src/files.rs).

The classification is enclosing runtime, with a whole-system boundary. Delegating model/tool iteration to the external Strands SDK does not make Tendril only a registry subsystem. Tendril supplies the runnable agent, prompt, tool callbacks, protocol entry point and its own enclosing desktop application. The implementation explicitly constructs the agent and registers its three bootstrap tools (SRC-1, tendril-agent/src/agent.ts):

tools: [ listCapabilities(registry), registerCapability(registry), executeCode(registry, workspacePath, config), ], --- tendril-agent/src/agent.ts

The retained-state loop is included end to end: model-facing listing and authoring; registry metadata and source-file writes; later disk reads for listing and execution; Deno subprocess execution; and results returned through the agent stream to the desktop UI. Registry creation/replacement is a shipped mechanism, not evidence that generated tools are effective. In particular, the registry writes both the index and TypeScript source, and execution reloads source by name (SRC-1, tendril-agent/src/loop/registry.ts, tendril-agent/src/loop/tools.ts, tendril-agent/src/loop/sandbox.ts, tendril-ui/src/context/AgentContext.tsx):

await this.saveIndex(index);

await fs.writeFile(path.join(this.toolsPath, `${definition.name}.ts`), code);

--- tendril-agent/src/loop/registry.ts

code = await registry.load(name); --- tendril-agent/src/loop/tools.ts

The shipped system prompt is included as an operational instruction, not merely documentation. It tells the model to consult retained capabilities and create one when none matches (SRC-1, tendril-agent/src/loop/prompt.ts):

1. listCapabilities() — always list first. Read the results.
2. Match found? → execute(name, args)
3. No match? → registerCapability(definition, code) then execute(name, args) --- tendril-agent/src/loop/prompt.ts

These instructions establish intended behavior, not enforced compliance or measured improvement across sessions. The boundary also includes the shipped human inspection and maintenance surfaces: capability browsing, tool-source viewing and workspace-file read/write commands. These are not an excluded external host (SRC-1, tendril-ui/src/hooks/useCapabilities.ts, tendril-ui/src-tauri/src/capabilities.rs, tendril-ui/src/components/CapabilityBrowser.tsx, tendril-ui/src/components/FileExplorer.tsx, tendril-ui/src-tauri/src/files.rs).

Frozen evidence and limits

The sole frozen source is SRC-1 at e671a4143d28de68289efd81580002041bb4cb6a, verified as the acquired checkout's HEAD. The applicability cutoff is 2026-10-15, the opening's run date; later revisions and current live documentation are not evidence. The overall tier is code-grounded. Source text and test definitions support implementation analysis; no target, tests, examples or model services were executed.

External dependencies include the Strands SDK and its provider adapters, Bedrock/OpenAI/Anthropic services or an Ollama endpoint, Node.js, Deno, Tauri and its shell/dialog/Stronghold plugins, and the platform filesystem/process facilities. Tendril's integration code is included; dependency implementations, model weights, service internals and remote packages fetched by generated tools are not frozen here. This prevents conclusions about SDK-internal iteration guarantees, provider reliability, actual sandbox isolation under attack or the behavior of arbitrary downloaded code. Provider selection and Deno invocation are inspectable at SRC-1, tendril-agent/src/agent.ts and tendril-agent/src/loop/sandbox.ts; bundling is inspectable at Makefile.

No user workspace, accumulated capability corpus, production trace or controlled intervention is supplied. Therefore this run cannot establish real tool reuse rates, longitudinal improvement, user outcomes or causal benefits of retention. Test source is not a passing test result. The inspected integration test covers protocol initialization/session creation/shutdown and can skip when the built entry point is absent; it does not demonstrate model-driven capability improvement (SRC-1, tendril-agent/tests/integration.test.ts).

Repository coverage

Every top-level tracked entry is classified below. Included means within the functional boundary, not that every file has already received a detailed behavioral audit. Initial inspection traced the material production, persistence and consumption paths named above; supporting modules and historical specifications remain available at the same pin for later analysis. No material shipped runtime path was unavailable. Inventory-only and search-only coverage are distinguished from full-file inspection.

All path-based coverage and classifications in this table refer to SRC-1. Excluded development material can be inspected for relevance, but it is not silently attributed to the product runtime.

Source register