Tendril synthesis
Type: agentic-system-analyses/types/agentic-system-synthesis.md
Bounded synthesis
Tendril implements a persistent, model-extensible tool library inside a desktop agent. Its strongest supported contribution is that model-authored programs can become durable machinery for later tasks without changing model weights. It also requests failure-guided repair of that machinery. The unresolved question is whether this requested repair occurs and improves future task capacity: no workspace corpus, execution trace or controlled comparison was supplied. The README's claim that every session becomes smarter therefore exceeds the evidence. See RT-BAP-capability-source, EPI-RTE-failure-repair and EPI-CLM-session-smarter.
The evidence is implementation and doctrine/design from SRC-1, https://github.com/serverless-dna/tendril, frozen at e671a4143d28de68289efd81580002041bb4cb6a, with an applicability cutoff of 2026-10-15. This is a code-grounded, whole-system analysis of the shipped enclosing runtime: React desktop, Tauri host, Node sidecar, capability registry and Deno execution integration. External Strands SDK implementation, provider services and weights, Deno internals and downloaded packages are not frozen. Neither target code nor tests were executed. The boundary and Source register fix that distinction; the report verification and profile verification accepted the bounded accounts without remaining blockers or declared limits.
From request to retained capability
A user selects a workspace and submits chat text. The Tauri host launches the Node sidecar and carries JSON-RPC messages. Node constructs one Strands Agent with a configured provider and three bootstrap tools: list capabilities, register a capability and execute by name. The model chooses next actions; the external SDK drives model/tool iteration; Tendril callbacks perform filesystem writes and process launching. The adapter forwards extracted current user text, not the desktop transcript. Protocol session labels do not reconstruct or isolate the Agent. See RT-RTE-prompt-stream.
The representative workflow is a request lacking a suitable retained tool. The shipped prompt connects listing, semantic matching, creation if needed, execution and return. A match skips creation. This is a connected single-agent workflow, not delegation to specialist agents. Its order is model guidance rather than a callback-enforced state machine; the same model is the instructed repairer. The workflow account traces these handoffs, supported by RT-CLM-action-sequence.
Listing reloads the entire index and returns names, descriptions, triggers and suppression conditions. These are model-interpreted selection guidance, not deterministic triggers or enforced suppression. Source bodies and bookkeeping fields are omitted. There is no listing-specific relevance filter, ranking or token/count budget in the inspected implementation. This saves bodies from entering that tool result but does not establish a bounded overall model context. See MEM-RTE-capability-list and MEM-BAP-selection-guidance.
When creating a capability, the model supplies natural-language metadata and TypeScript source. Node checks shape/name syntax and automatically writes the index followed by the source file. Human task initiation is not approval of each write. Admission precedes execution; no compilation, task-answer oracle or semantic approval gates it. Exact-name replacement revises current content without preserving a previous version. Sequential writes can leave index and source inconsistent, and corrupt-index fallback can hide retained source. See RT-RTE-capability-admission and MEM-OBJ-index-metadata.
From retained source to effects and feedback
Retention has two different authority paths. Descriptions and invocation conditions guide the model; executable TypeScript directs Deno. Execution reloads the entire current tools/{name}.ts file, adds argument/workspace bindings and launches a temporary script. Crucially, loading checks the name and file, not index membership. A source file can run without an advertised entry, while an advertised entry can lack executable source. Removing an index entry alone therefore does not revoke a known executable filename. See MEM-OBJ-tool-source, RT-RTE-capability-execution and RT-BAP-capability-source.
Deno receives workspace read/write and network permission, unrestricted by domain in the default configuration. No run, environment or FFI permission flag is passed. Enforcement depends on the resolved Deno binary and platform, not on the model's descriptions. The workspace grant includes the registry: generated programs are afforded a route to change source/index bytes without another registration or approval. Separately, the shipped human editor has a wired content decision and Save confirmation followed by path-checked backend writing. That confirmation governs the editor only, not program writes or generic backend callers. See RT-RTE-program-mutation and RT-RTE-editor-mutation.
The executor checks process termination, deadline and combined output volume. Zero exit returns trimmed stdout, not a verified answer; nonzero exit and resource/cancellation failures reject. Timeout and kill do not reverse completed file or network effects. The prompt asks the model to fix failed code and retry, but the repair route remains claimed rather than an observed or independently enforced controller. Repository development checks are real evaluator implementations, but do not gate runtime-generated capabilities. See EPI-RTE-execution-check, EPI-RTE-result-disposition, EPI-RTE-failure-repair and EPI-RTE-development-check.
Model text and tool events stream back to the desktop. Completion stops its processing indicator even after a caught stream error; completed tool labels likewise do not certify task success. The chat/debug display is process-local state, not an inspected durable conversation replay mechanism. A sidecar restart rebuilds agent state while capability files survive. SDK history, compaction and checkpoints remain uninspected. See EPI-RTE-display-result, MEM-OBJ-agent-display and RT-RTE-prompt-stream.
What the progression establishes
For requests needing reusable executable procedures, this architecture provides a concrete cross-session retention and later-consumption path. For requests needing warranted factual answers or reliable recovery, its generic checks establish narrower facts: a name was admissible, a file loaded or a process exited successfully. Tools can acquire live data, but freshness and source warrant depend on actual code and observations. Operational admission and retention do not establish evidence-consuming acceptance of a truth claim. No accepted ampliative claim or checked entailed derivation is established by these records. See EPI-CLM-live-data, EPI-RTE-model-production and epistemic bounded conclusion.
The independent learning-related findings are:
- Trace-fed adaptation: failure feedback → model repair → durable replacement → later execution is a claimed trace-learning route, with wired write/read endpoints. Neither feedback use nor successful repair is observed. This is a positive design contribution, not evidence of improved future capacity. See EPI-RTE-failure-repair.
- Theory-builder conditions 1–4: actual formulated theory content is uninspected (1); decisions depending on what such a theory says are unestablished (2); content-directed criticism assigning blame is unestablished (3); a retained criticism shaping another round is unestablished (4). Whole-file replacement alone establishes none of these semantic findings. The available registration route and repair instruction do not identify the required contents. See RT-RTE-capability-admission and EPI-RTE-failure-repair.
- Learning through criticism of consumed theory: improved future capacity is unestablished independently of the four conditions; there is no supplied theory/criticism episode or capacity comparison. See EPI-CLM-session-smarter.
- Reflection: a representation of selected system aspects participating in both causal directions is unestablished. Editable descriptions and source provide possible material, not a demonstrated reflective loop. See epistemic bounded conclusion.
- Autonomy: automatic capability admission is wired without per-capability human approval, while program mutation is afforded and editor replacement is human-directed. Autonomous theory-building is separately unestablished; automatic writes do not identify all its internal roles. See RT-RTE-capability-admission, RT-RTE-program-mutation and RT-RTE-editor-mutation.
- Self-improvement: over the cross-session horizon, successful task execution is the repair objective and retained source enters the system's own live behavioral machinery. Failure-responsive improvement is requested, but evidence causally determining a particular update and subsequent operation causally depending on it are unestablished. Thus exercised self-improvement, and separately its success, are not established. See EPI-RTE-failure-repair, RT-BAP-capability-source and EPI-CLM-session-smarter.
A retained episode linking failure evidence, diagnosis, replacement bytes and later dependent execution would change the repair assessment. A comparable task evaluation with and without the retained change could test capacity benefit; attribution to retention or another component would require independently varying that component. A candidate semantic acceptance gate or versioned rollback would change the admission/recovery account, but would not itself demonstrate improvement. These are resolving evidence or system changes, not claims that the present system cannot improve.
Limitations
| Limitation | Affected SRC IDs and record citations | Inspected boundary | Conclusion prevented | Evidence that would resolve it |
|---|---|---|---|---|
| No supplied workspace, execution trace or controlled comparison | SRC-1; RT-RTE-capability-admission, EPI-RTE-failure-repair, EPI-CLM-session-smarter | Shipped admission, repair instruction and reload paths; implementation/doctrine only | Actual reuse, feedback-driven repair, improved capacity, exercised self-improvement and causal benefit | Provenance-linked tasks, failures, revisions and later executions; outcome comparisons with appropriately varied components |
| Actual generated contents and preexisting corpus provenance are unknown | SRC-1; MEM-OBJ-tool-source, MEM-OBJ-selection-text, RT-RTE-program-mutation | Registry fields, initialization and alternate write capacity, not an accumulated corpus | Metadata truth, complete provenance, theory content/criticism, embedded evaluators or enumeration of application-memory schemas and consumers | Frozen corpus with writer/input lineage, operative contents and actual later-consumer evidence |
| SDK/provider implementation and model identity remain opaque | SRC-1; RT-RTE-prompt-stream, RT-CMP-bedrock-model, RT-CMP-openai-model, RT-CMP-anthropic-model, RT-CMP-ollama-model | Tendril constructor and adapters, not frozen dependency/service internals | Complete context-management/checkpoint inventory, complete memory-axis coverage, exact weight identity or provider-internal learning conclusions | Frozen dependency implementations and deployment/model identities, plus traces of context and retained-state consumption |
| Execution permissions and process controls were not exercised | SRC-1; RT-RTE-capability-execution, EPI-RTE-execution-check, RT-RTE-editor-mutation | Launcher flags, timeout/output checks and editor path validation, not a deployed security test | Actual isolation under attack, live cancellation reliability or reversal of prior effects | Deployment-specific binary/configuration evidence and scoped execution/security tests; separate recovery evidence for effects |
| Generic status checks do not validate task-domain content | SRC-1; EPI-RTE-result-disposition, EPI-RTE-display-result, EPI-CLM-live-data | Runtime callbacks and presentation paths; arbitrary generated evaluators unresolved | Truth/freshness of stdout, epistemic acceptance or correctness of delivered answers from exit/completion alone | Actual source-bound results and evidence-consuming checks with criteria, intended use, scope and consequential acceptance |
| Available historical documentation and remaining test material were not exhaustively assessed | SRC-1; boundary coverage, EPI-RTE-development-check | Material shipped routes and selected public claims/evaluator sources | Exhaustive historical warrant-claim inventory, complete test adequacy or passing test results | Targeted historical-document inspection for a named claim and relevant evaluator coverage/results |
No unresolved reconciliation conflict or verification-declared limit remains to carry beyond these evidence boundaries. Source-read log: none; this synthesis uses the supplied members only.