Voiden synthesis
Type: agentic-system-analyses/types/agentic-system-synthesis.md
Bounded synthesis
From project registration to request execution
Voiden's agent-facing Model Context Protocol (MCP) subsystem gives an external agent tools for discovering and executing project-defined network requests. It is an extension or tool mechanism, not the enclosing model runtime. This account covers that subsystem in https://github.com/voidenhq/voiden at commit d7a0d05c40acb6cc483000643c700f17aecba0ef, with cutoff 2026-10-14. The evidence is inspected implementation and shipped guidance from SRC-1, not execution traces or causal experiments. The general desktop product, external model hosts, live project state and separately distributed plugin implementations are not established by this evidence. See the boundary and evidence and Source register.
The ordinary path starts when an operator registers a project with an MCP host. Bundled voiden agent points the host at voiden mcp-stdio; desktop initialization also writes registration and refreshes guidance. Those writes establish configuration delivery, not successful host discovery. Once connected, the external host owns problem interpretation, tool selection, confirmations, request editing and task completion. Voiden owns the symbolic execution path between invocation and tool return. The bundled stdio server registers six fixed tools and three plugin-management tools; standalone serving and the separate publishing server expose different surfaces (RT-RTE-host-registration, RT-RTE-request-execution, RT-RTE-tool-publication).
The representative workflow is discover → select environment → execute → inspect → repair if needed → optionally record. Shipped guidance explicitly connects these steps, while handlers implement the handoffs. Discovery returns file paths, section labels, UIDs and request previews without sending requests. Guidance asks the user to disambiguate environments, but the handler does not enforce that approval. Selected environment values persist in the server session independently of the desktop selection; an execution call can layer an env file and explicit overrides above them. This is a source-supported interactive procedure, not an observed successful agent workflow or an internally enforced state machine (workflow account, RT-BAP-agent-guidance, RT-OBJ-runtime-vars).
On run_request, code rereads the document, resolves linked content, selects sections, normalizes blocks and supplies document JSON, environment and shared runtime variables to plugin builders and hooks. These construct and can modify or cancel the request; shared execution then dispatches network work. A label filters multi-section files, but a stale label does not stop a single-section file from running its sole request. Per-section exceptions become failed results and later sections continue; earlier file/parse failures can escape that handling. The structured MCP result is the immediate delivery boundary. It does not decide whether the user's intended task succeeded or undo completed remote effects (RT-RTE-request-execution, RT-CMP-request-orchestrator, workflow execution and return).
What execution checks, and what recording preserves
Execution supplies more evidence than plausible request syntax, but its success field has a narrower license than semantic correctness. For HTTP-like responses the core classifier requires no error and a status from 200 through 399. A hypothetical 302 therefore passes that predicate; this is a deduction from code, not an observed request. The guide asks for stricter non-2xx inspection and a body check against intended purpose. That review remains a request to the foreground agent, not a core answer oracle or enforced evidence-consuming acceptance decision (EPI-RTE-outcome-classification, EPI-CLM-request-check).
Optional write_result is a separate admission step. The caller supplies a result and UID; software serializes selected fields and inserts or replaces a matching response in the section. UID matching establishes placement, not that the result came from an earlier execution. The timestamp is write time. String bodies longer than 20,000 characters are truncated and marked; some immediate-result fields are omitted. Thus recording is a latest-outcome ledger, not an authenticated complete transcript or factual acceptance. On a later run, parsed response blocks reach callback-visible document JSON. Whether unavailable plugins use their contents, or an external model reads and relies on them, is unresolved (RT-RTE-result-write, MEM-OBJ-response, EPI-RTE-response-serialization, MEM-RTE-response-reload).
The strongest supported trace-fed contribution is automatic execution-value extraction with durable carry-over into later request construction. Authored capture expressions select request/response values into named bindings; subsequent templates substitute those values. In standalone CLI session mode, Voiden reloads and saves a user-global ~/.voiden/.process.env.json snapshot, so the chain can cross invocations. This is a wired trace-learning route in the comparison's write-route sense: tool execution material produces durable behavior-shaping inputs. It does not require new explanatory knowledge. The unresolved question is whether that carry-over improves capacity for future action; there is no outcome comparison or exercised dependency trace establishing such improvement. Null extraction can leave an old key intact, and stored bindings retain neither source-run IDs nor generated reasons for adopting them (MEM-RTE-runtime-capture, MEM-OBJ-process-env, RT-RTE-session-driver, profile verification).
Other retention has different consumers. CLI session history appends raw execution results for later report/status/export commands, not automatically for future request construction or model prompts. Guide refresh copies enabled guides, builds short index summaries and retains full guide files for foreground-agent demand loading. That packaging changes reachability, not the host's token window: it does not establish conversation compaction, isolated subtasks or eviction of loaded instructions. Filesystem removal also cannot revoke already loaded copies, and uninstall does not cover every shared skill copy (MEM-OBJ-session-results, MEM-RTE-history-report, RT-BAP-agent-guidance and its memory annotation).
Capability changes and published tools
Bundled stdio plugin management can download, enable and load executable capabilities after a caller requests installation or update. Registry availability and download/load outcomes govern admission; there is no internal per-install human confirmation. Imported plugins run in the server process, not a sandbox. Reload rebuilds registries, but stable import URLs do not establish replacement of already imported bytes. Error reporting is not transactional rollback. This is an implemented capability-changing channel, not demonstrated performance improvement (RT-CMP-plugin-runner, RT-RTE-plugin-admission).
Request-backed publishing is a separate route. Core code delegates planning, verification and registration to a /tool provider whose implementation is unavailable here. Runner serving uses startup decisions; the separate publisher can replan periodically, reuse an in-memory cache and supply the latest successful decisions to later HTTP requests. Failed planning may leave prior decisions in place. Supervised stdio restarts on selected existing-tool state changes, but its detector is not complete for additions, deletions or description-only changes. CLI verification separately consumes provider statuses for output and exit code; unverified alone does not fail, empty discovery succeeds, and optional write failures do not determine that exit code. Known dispatch cannot establish the provider's oracle, cache use, status persistence or downstream acceptance (RT-RTE-tool-publication, MEM-OBJ-verify-entry-cache, MEM-RTE-status-write, EPI-RTE-cli-verification).
Three boundaries matter for interpreting this architecture. The fixed primary-file/env-file guard is lexical, not transitive filesystem confinement: linked reads, absolute binary inputs, symlinks and arbitrary plugins exceed that guarantee. Tagged-block gating checks compatibility, not exact version/byte replay, and skips blocks lacking the required tags. Publisher bearer authentication is optional and entry-point-specific, not per-action approval. Neither publication admission nor its authentication governs generic execution. A request can also call a remote MCP service directly; RPC completion can carry a remote tool-level failure. None of these checks licenses a universal verified-tools-only or task-correctness invariant (RT-CLM-project-confinement, RT-CLM-version-gating, RT-CLM-publisher-access, RT-RTE-remote-mcp).
Scenario-relative assessment and change conditions
For an external agent iterating on project requests, the supported contribution is concrete execution feedback, structured failure delivery, optional outcome retention and executable value chaining. Semantic acceptance, repair choices and final delivery remain with that agent. For publishing request-backed tools, the supported contribution is provider orchestration and refresh machinery; end-to-end verification and safe parameter binding remain unresolved. These are different scenarios and evidence domains, not a product ranking (workflow account, epistemic bounded conclusion).
The independent higher-level properties remain separately bounded. Inspectable guide prose is available, but the accepted runtime does not establish a formulated-theory route satisfying theory-builder condition 1, content-dependent theory consumption under condition 2, stated content-directed criticism under condition 3, or retained criticism shaping another round under condition 4. These are unestablished findings, not evidenced absences in the external host. Criticism improving future capacity is likewise unestablished. Reflection's two causal directions are not demonstrated by guide delivery or variable persistence. Computation owns internal request dispatch, but autonomous ownership of the whole selected workflow is not established: the external host owns interpretation and repair. Self-improvement is independently unestablished at this subsystem boundary; capture changes execution inputs and installation changes capabilities, but the records do not close an objective-directed, evidence-responsive self-change pathway through subsequent causally dependent operation. Missing run evidence does not erase the wired capture and capability mechanisms (RT-BAP-agent-guidance, MEM-RTE-runtime-capture, RT-RTE-plugin-admission, epistemic bounded conclusion).
Pinned provider implementation could change the publishing assessment by exposing actual checks, expected outcomes, parameter binding, persistence and later consumers. Host traces linking result inspection to repair and genuine recording could establish exercised workflow behavior. A comparison with an independently specified capacity objective could test benefit from retained bindings; it would need to distinguish the binding change from other interventions. Provenance-bound recording, canonicalized transitive path enforcement, authenticated plugin bytes or complete refresh detection would change the corresponding guarantees only on the routes they actually cover. No source files were read for this synthesis; it uses the supplied accepted members. Both report verification and profile verification declare no additional limits or blockers.
Limitations
| Limitation | Affected SRC IDs and record citations | Inspected boundary | Conclusion prevented | Evidence that would resolve it |
|---|---|---|---|---|
| Implementation and doctrine are not observed operation or benefit | SRC-1; RT-RTE-request-execution, RT-RTE-session-driver | Frozen agent-facing subsystem; no target execution, supplied host trace or causal experiment | Successful host launch, reliable workflow delivery, performance and causal improvement | Traceable executions under stated host/project conditions; controlled comparisons for benefit |
| External provider semantics are unavailable | SRC-1; RT-RTE-tool-publication, MEM-OBJ-verify-entry-cache, MEM-OBJ-tool-status-record, MEM-RTE-status-write, EPI-RTE-cli-verification | Core interfaces, scheduler, CLI consumers and status dispatch | End-to-end verification, oracle scope, binding correctness, complete cache/curation inventory, physical status persistence and later status reliance | Pinned provider code tracing checks, writes, selection and consequential consumers; corresponding execution evidence |
| External host controls interpretation and context | SRC-1; RT-BAP-agent-guidance, RT-RTE-host-registration, RT-OBJ-serve-decisions | Guide composition/installation and provider mode dispatch | Obedience, enforced semantic review, model-window budgets/eviction, universal revocation, dynamic-mode targeting, theory criticism or reflection | Host/provider context implementation and traces of actual guide loading, selection, criticism and later effects |
| Recorded responses lack execution provenance and can be incomplete | SRC-1; RT-RTE-result-write, MEM-OBJ-response, MEM-RTE-response-reload | Caller admission, serializer and parser-to-callback delivery | Authenticated history, complete transcripts, factual acceptance and demonstrated later model reliance | Execution-bound records with complete retained content and a traced later consumer; explicit evidence-consuming acceptance where claimed |
| Capture is known, but initialization and alternative writes remain unresolved | SRC-1; MEM-RTE-runtime-capture, MEM-OBJ-process-env, RT-OBJ-runtime-vars | Configured extraction, durable snapshot and substitution; opaque scripts and uncaptured initial/profile content | Complete lineage/admission/effect inventory or improved future capacity from the positive capture witness | Initial-state provenance, resolver/script implementation and comparisons isolating the retained update's capacity effect |
| Capability admission does not establish safe replacement or isolation | SRC-1; RT-CMP-plugin-runner, RT-RTE-plugin-admission | Core download, cache/store and stable-URL imports | Release-byte authenticity, immediate replacement of loaded modules, transactional rollback, malicious-plugin containment or improvement | Pinned release bytes, integrity/admission controls, exercised module replacement and recovery, separately evaluated isolation |
| Guarantees differ by route and leave alternate paths | SRC-1; RT-CLM-project-confinement, RT-CLM-version-gating, RT-CLM-publisher-access, RT-RTE-remote-mcp | Fixed lexical guard, tagged compatibility, optional publisher auth and outgoing RPC | Transitive sandboxing, exact replay, universal identity/per-action approval or task-success oracle | Route-complete enforcement and pinned external contracts; deployment and endpoint evidence for operational claims |
| Recovery and auxiliary coverage are bounded | SRC-1; RT-RTE-result-write, RT-RTE-tool-publication, MEM-RTE-history-report | Shared mutable maps/files, selected refresh comparisons and report dispatch; export internals not fully audited | Collision freedom, complete served-state withdrawal, reversal of remote effects, full export fidelity or whole-product reliability | Concurrency/recovery implementation and traces, complete refresh comparisons, export audit and an explicitly expanded product boundary |