Runtime Bridge

It is not a wrapper UI. It is the supervisor, memory, policy, search, and verification layer that external agent runs flow back into. There are two independent ways to use it:

1. Mount Anymo's brain into any MCP-capable agent (anymo mcp-serve). Your agent gains read-only brain access plus propose-not-write memory, with no Anymo orchestration required.
2. Coordinate an installed CLI agent through a managed worktree (anymo runtime run), with its output captured as durable events, harvested into a diff, tests, and artifacts, and verified before anything is proposed back to the brain.

What it is, and is not

• It is a provider-neutral, config-driven bridge. A new runtime is a configuration row, not new code. The generic CLI adapter works with any headless agent that has a print or exec mode and emits line-JSON or plain output.
• It is not a re-implementation of any specific agent, and it never depends on a runtime's private formats, only on documented public surfaces.

No runtime ships enabled. You point the generic CLI adapter at the agent you have installed via .anymo/runtimes.toml.

Anymo as an MCP server

Any agent that can mount an MCP stdio server can read Anymo's brain:

anymo mcp-serve --workspace /path/to/workspace

It exposes exactly these tools:

Mounting instructions

Most MCP clients accept a stdio server entry shaped like this; consult your agent's MCP config docs for the exact file and field names:

{
  "mcpServers": {
    "anymo-brain": {
      "command": "anymo",
      "args": ["mcp-serve", "--workspace", "/path/to/workspace"]
    }
  }
}

To restrict the mount to read-only tools, pass an allowlist:

anymo mcp-serve --workspace . --allow-tools anymo.query,anymo.context_pack,anymo.memory_read

Coordinating a CLI runtime

# The built-in mock runtime works out of the box (no external dependency):
anymo runtime run mock --goal "demo the bridge" --project /path/to/repo

# A configured CLI runtime (see runtimes.toml below):
anymo runtime run cli-agent-a --goal "fix the failing auth test" --project /path/to/repo

The lifecycle: Anymo creates a managed Git worktree (a sibling *.anymo-worktrees/ directory, never your checkout), injects a context file the runtime reads on startup, launches the configured command in that worktree, streams its output into durable events, and on completion harvests the git diff, runs a configured test command, and produces a patch review. Only after that verification can a memory or skill be proposed back into the brain, always for human approval.

Discovery

anymo runtimes --json --project /path/to/repo

Lists runtimes detected on this machine: id, version when cheaply obtainable, the surfaces each exposes, the detection source, and the approval tier. Detection is conservative: a runtime is listed only when its binary actually resolves on this machine.

Security model

• Read-first, propose-not-write. Over MCP, only anymo.memory_propose and anymo.artifact_record mutate, and both produce proposals a human must approve.
• No secrets ever served. Every MCP response and every ingested observation passes through the same redaction the control plane uses. Provider keys are sealed and never enter the brain corpus.
• Bounded. Output is size-capped (64 KB by default); child processes are spawned with a cleared environment plus an explicit allowlist, piped stdio, a run timeout, and kill-on-drop.
• Approval discipline, never bypass. When a runtime exposes interactive approval, requests route through Anymo's shared approval broker. When a runtime runs autonomously, containment is the gate: it runs only inside a managed worktree, and nothing merges to your branch until a patch review and a human integration decision.
• Workspace containment. Configured context-file paths are sanitized against traversal; the runtime works only inside its worktree.
• Prompt injection is contained. Harvested text never auto-acts. It becomes durable events, proposed memory, and Query Fabric documents. It can never escalate Anymo's own tool permissions.

The runtimes.toml reference

This file is local to the workspace (under .anymo/, which is gitignored) and names the real tools you have installed. A ready-to-edit example ships at .anymo/runtimes.example.toml.

[[runtime]]
# Generic id used in events/config. display_name may name the product in LOCAL config only.
id = "cli-agent-a"
display_name = "Print-mode CLI agent A"
# A runtime ships disabled; set this to true to use it.
enabled = true

# Conservative PATH / well-known-location discovery (no execution at discovery time).
discover = { path_names = ["my-agent"], version_args = ["--version"] }

# Command template. {goal}, {worktree}, {context_file} are substituted (data, not code).
launch = { program = "my-agent", args = ["--print-json", "{goal}"], cwd = "{worktree}" }

# Output parsing: "line-json" (each stdout line is a JSON object) or "plain".
output = { parser = "line-json", event_path = "type", text_path = "message.content" }

# Explicit environment allowlist, applied after the environment is cleared.
env = { }

# How injected context reaches the runtime. V1 supports "project-file".
context = { mode = "project-file", path = "AGENTS.md" }

# Whether the runtime exposes interactive pre-execution approval.
approval = { supported = false }

# The configured project command run during harvest (defaults to "test").
test_command = "test"

Durable events

External activity becomes first-class durable events, so the brain, Query Fabric, memory, and replay machinery see external runs: runtime.connected, runtime.task.started, runtime.observation, runtime.task.completed, runtime.task.failed, runtime.harvest.recorded.

Existing events are reused for the substance: tool intents become tool.requested, approvals become approval.requested/granted/denied/expired, and harvested files become artifact.created. The current timeline, approval queue, artifact list, and the brain-learning analyzer all work on external runs unchanged.

Honest V1 limitations

• Local only. V1 controls a local child process and a local stdio MCP server. There is no remote runtime control and no socket or WebSocket MCP transport yet.
• Approval tier depends on the runtime. Most headless CLIs run autonomously to completion, so they get the sandbox plus per-merge-review guarantee, not per-action approval.
• No auto-merge. Harvested diffs are never merged to your branch without a human integration decision.
• Hooks ingestion is deferred. V1 ingests print and exec output and MCP only.
• No in-process runtime plugins. Only documented public surfaces are ever used.