Architecture and runtime integration

Scope

Define ownership and integration boundaries. The dashboard presents information and transports commands. The independent Agent Mate host owns task coordination. The existing AIOS runtime performs model turns and tool execution. Connections supplies authorization; the proposed MCP bridge enforces access to external tools.

The diagram shows the proposed complete path. The scoped MCP adapter is not operational yet.

Existing foundation

The reviewed Agent Mate runtime adapter launches aios tui-backend, creates or resumes a session, and submits through prompt.submit. AIOS loads configured MCP tools at runtime-process startup. The headless host exists separately from the dashboard.

Decisions

The harness remains unchanged. No alternative agent/model execution loop.
Do not use browser-connection lifetime as task lifetime.
Bind account, immutable project, task and runtime session before admitting tool operations.
MCP calls stay on the existing runtime tool path; a bridge handles protocol and permission enforcement.
A project name, prompt instruction or working directory alone is not an isolation boundary.

Questions to resolve

How can the supported startup configuration expose only a task's scoped bridge without copying a dashboard home or provider keys? How does the bridge authenticate a project when multiple workers share a Linux identity? What refresh mechanism can safely expose newly granted tools?

Implementation tasks

ID	Deliverable	Status
ARCH-01 / MCP-P01	Trace and prove runtime startup, MCP configuration and task identity	Pending
ARCH-02	Define independent bridge ownership and worker isolation	Pending
ARCH-03	Demonstrate two-project isolation through the unchanged runtime	Pending

Acceptance evidence required

A disposable tool must be invoked by the actual existing runtime. A second project cannot impersonate the first. Closing the dashboard must not kill the task. Confirm no harness changes. Current evidence is source review and the earlier independent-host handoff, not a completed scoped-runtime test.

Related areas

Agent Mate overview — A guide to the separate designs and how they fit together.
Connections, credentials, and permissions — Shared connection ownership, project grants, key handling and revocation.
Execution, recovery, and progress tracking — Independent tasks, cancellation, uncertain outcomes and durable progress.
Project-scoped MCP for Agent Mate — The existing seven-task MCP plan: grants, bridge integration, revocation and acceptance.

MCP-P01 progress — actual runtime proof

On 15 September 2026, an executable rmcp3.4 fixture ran through the existing shadow AIOS binary, using session.create and prompt.submit. A deterministic loopback model responder requested the MCP tool; no real provider or project was contacted.

Input	Observed result	Admitted fixture operations
Project A with matching enabled policy	Returned project-a and MCP_BOUNDARY_FIXTURE	1
Tool arguments include project B override	Rejected unknown project field	0
Disable policy after the runtime discovers tools	Project access denied	0
Launch binding B with policy for A	Project access denied	0

This proves runtime/protocol compatibility and per-call denial behavior in a controlled fixture. It does not prove hostile-worker isolation, multi-account ownership, concurrent projects, or real Connections grant enforcement. Launch arguments and the fixture policy are supervisor-controlled test inputs, not a production identity mechanism. MCP-P01 remains in progress.

The next implementation requirement is a trusted account/project/task binding and policy boundary outside the worker's writable filesystem. The current host is single-owner and authenticates Unix peers by UID; that alone cannot distinguish multiple projects. Do not enable live project MCP access until this boundary is implemented and verified. Harness source and live services were not changed by the proof.