MCP-native architecture

Autonomy does not host an agent. It hosts a daemon that speaks the Model Context Protocol, and any MCP-capable agent — Codex, Claude Code, or a bring-your-own client — connects to it, discovers its tools, and drives the conversation itself. This page explains why that split exists and what it replaced.

What it replaced

Earlier, the in-app “talk to your agent” surface worked by having the app spawn a subprocess directly: the UI called into a local runtime, which spawned a codex exec process, parsed its stdout, and rendered the reply. That agent had no connection back to Autonomy’s own tools — it was a one-shot CLI call with none of the accessibility, screen, browser, or speech capabilities the rest of the runtime offers.

That path (nightgram, internally) created three compounding problems: every agent needed its own bespoke subprocess adapter; the chain from user intent to result was long and indirect; and it implied Autonomy would need to keep reimplementing whatever Codex’s and Claude’s own agent ecosystems already provide. It also quietly contradicted the rest of the product: Autonomy markets itself as a generic MCP server agents connect to, not an agent in its own right.

The decision

The in-app conversation is MCP-native. Three pieces make that concrete:

1. Bring-your-own agent. Any MCP client can claim and drive the conversation over the daemon’s transport — claim it, append to it, release it — using the same tool surface a BYO agent would use for anything else. Because the integration point is simply “an MCP client,” the surface is agent-agnostic by construction; Autonomy doesn’t special-case Codex versus Claude versus anything else.
2. A thin default, not a custom runtime. Users with no particular preference get a default launcher — a standard CLI agent pre-wired to the Autonomy MCP server and its rules plugin. This is a default configuration Autonomy ships, not a maintained agent Autonomy has to keep building.
3. Rules ship as plugins, not app code. Consent-first behavior, the accessibility north star, and pacing rules are delivered as a Claude Code plugin (skills + .mcp.json), a Codex plugin, or generic MCP registration — artifacts each agent ecosystem already knows how to load. Codex and Claude Code follow the same Autonomy policy through their own extension points instead of each reinventing it.

Mental model

The daemon owns the tool surface and the consent boundary. The agent — however it got there — is a client of that daemon, not a subprocess it manages.

Discovery instead of a firehose

A connected agent doesn’t receive all of Autonomy’s tools by default context — the surface is large (roughly 170 tools across screen, browser, speech, VoiceOver-transport, and workflow domains). Loading every schema into a single agent’s context degrades tool selection rather than helping it. Autonomy addresses this at the daemon, not the client: the MCP server can filter its tools/list response to a single domain (screen, browser, speech, and so on) so a connecting specialist agent sees only the ~10–30 tools relevant to its job, plus a small set of cross-cutting tools — consent, the action ledger, and readiness checks — that every acting agent needs regardless of domain. A router then dispatches a task to the right domain specialist. This keeps the filtering capability in the daemon (the only place that can actually keep unused schemas out of an agent’s context) while the router and domain definitions live in the plugin/skill layer, alongside the rest of Autonomy’s rules-as-plugins delivery.

A concrete example

The Claude Code plugin manifest doesn’t hardcode any accessibility behavior in Swift or Rust — it points at a skills directory and an .mcp.json that runs a7y-cli daemon proxy. The skill file itself carries the actual rule set: read readiness before acting, prefer AX/keyboard/speech over pointer fallback, keep spoken updates short and screen-reader safe, and treat high-risk actions as requiring explicit consent. Codex gets the equivalent rules through its own plugin format. Same policy, two delivery mechanisms, zero duplicated app code.

Common misconceptions

• “Autonomy is an agent I talk to.” It’s a tool provider an agent connects to. See What is Autonomy for the distinction.
• “Every agent needs custom integration work.” Any MCP client can connect with no Autonomy-specific subprocess plumbing — that was precisely the indirection this architecture removed.
• “More tools visible is always better.” A larger tool surface without domain scoping measurably hurts tool selection; scoping is a feature, not a limitation.

Continue to the runtime for how the daemon composes its own subsystems, or to bring your own agent to connect a client today.