Voiden boundary

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

Boundary and evidence

This run analyses Voiden's agent-facing MCP integration subsystem, not the entire desktop API client as an autonomous agent. Its intended use is to explain how external agents discover and execute project requests, retain results, select environments, acquire missing execution plugins, and consume published request-backed tools. The target class is extension or tool mechanism and the boundary kind is subsystem-only. The enclosing model-driven decision loop belongs to an external host; serving that loop through MCP is sufficient for this narrower target to be in scope.

Voiden describes itself as an offline API client, with requests, documentation and tests in text files, rather than as an enclosing model runtime (SRC-1, README.md). The shipped implementation establishes an agent-callable execution mechanism: the bundled CLI registers a project against its own hidden stdio server, then that server registers request tools and plugin-management tools. The model host decides when to invoke those tools; that responsibility is not attributed to Voiden (SRC-1, apps/electron/src/voiden-cli.ts).

const serverCommand: ServerCommand = { command: 'voiden', args: ['mcp-stdio', projectPath] } const installed = installMcpIntegration(projectPath, targets, MCP_SKILL_MARKDOWN, serverCommand) --- apps/electron/src/voiden-cli.ts

registerFixedTools(server, projectRoot, runtimeVars, activePlugins, selectedEnv) --- apps/electron/src/voiden-cli.ts

registerPluginManagementTools(server, activePlugins) await server.connect(new StdioServerTransport()) --- apps/electron/src/voiden-cli.ts

The repository tree and shipped consumers establish three related entry paths, not just an isolated exported library. The bundled voiden agent / mcp-stdio path registers and serves project execution tools; voiden-runner mcp install / serve provides the standalone runner path; voiden-mcp starts the separate publishing server. The desktop MCP IPC handler is also an included caller, not an excluded external application. It writes host registration and refreshes composed guidance. These responsibilities are visible in SRC-1, apps/electron/src/voiden-cli.ts, packages/voiden-runner/src/index.ts, packages/voiden-mcp/src/index.ts, and apps/electron/src/main/ipc/mcp.ts. Documentation and comments contain older descriptions of tool counts and registration targets; executable call sites govern this boundary, not those descriptions.

Functional coverage and limits

This is a subsystem coverage map, not a claim that every desktop or build path has been inspected. All listed paths refer to SRC-1 at the frozen commit. Included but not yet inspected material is distinguished from unavailable external evidence.

The retention boundary is concrete: write_result invokes upsertResponseBlock, which reads the existing document, inserts or replaces a response associated with a request UID, and writes the file. runVoidFile separately reloads document content for execution. This establishes source-visible production and later reading of the same document format, not that every retained response influences later model decisions (SRC-1, packages/voiden-runner/src/mcpServing.ts, packages/voiden-runner/src/resultBlock.ts, packages/voiden-runner/src/runner.ts).

upsertResponseBlock(resolved, requestUid, result as RunResult) return textResult({ written: true, filePath, requestUid }) --- packages/voiden-runner/src/mcpServing.ts

External dependencies and deliberate exclusions

• External model hosts and providers: Claude Code, Codex and other MCP clients are consumers, not frozen implementations in this source. Their inference, context assembly, tool selection, confirmation policies and later reuse of recorded content cannot be established here. The shipped host-configuration writers and guidance remain included (SRC-1, packages/executors/src/mcpInstall.ts, packages/executors/src/skillContent.ts).
• Separately distributed plugins: protocol builders, pipeline hooks, extension guides and the /tool capability implementation may arrive through plugin repositories or release assets. These are unavailable as pinned implementation evidence in this source set, not merely uninspected tracked files. Core delegation and download paths are inspectable, but plugin semantics and release-byte behavior cannot be reconstructed from core contracts alone (SRC-1, packages/voiden-runner/src/plugins/loader.ts, packages/voiden-runner/src/mcpToolCapability.ts, .gitignore).
• General desktop application: editor presentation, terminal/Git UX, unrelated imports, themes and general desktop behavior are deliberately excluded except where they produce, install or consume this subsystem's state or instructions. This prevents a whole-product characterization or a claim that the full desktop request loop has been covered. The included Electron IPC and skill callers are not excluded by this rule.
• Live operation: network APIs, user project documents, credentials, installed plugin caches, live registries, host config files and deployment services are not captured. Dependencies such as the MCP SDK and optional tunnel services are not independently frozen source repositories. No target execution, provider calls, test runs or deployment experiments were performed. Reliability, security effectiveness, performance and causal improvement therefore remain unestablished.

The delegation boundary is explicit in executable code, rather than inferred solely from documentation (SRC-1, packages/voiden-runner/src/mcpToolCapability.ts):

export async function planServedTools(projectRoot: string, env: Record, activePlugins: string[], opts?: PlanServedToolsOptions): Promise { if (!provider) return [] return provider.planServedTools(projectRoot, env, activePlugins, opts) } --- packages/voiden-runner/src/mcpToolCapability.ts

The frozen evidence is repository https://github.com/voidenhq/voiden at d7a0d05c40acb6cc483000643c700f17aecba0ef, with applicability cutoff 2026-10-14. The acquired checkout's HEAD was verified against that pin. The overall tier is code-grounded: implementation reads establish the subsystem boundary, while source-native documentation and guidance supply declared intent. No additional repository, web page, release asset or capture is registered. The complete disposition means this boundary has been established, not that the entire product or external agent loop has been analysed.

Source register