Support external agent harnesses via MCP (Claude Code, Codex, OpenCode, Pi, DeepSeek) #9

New issue

Open

opened 2026-10-20 07:55:59 +00:00 by rosa · 0 comments

rosa commented

2026-10-20 07:55:59 +00:00

Member

Requested by Felix 2026-10-20. Let external CLI agent harnesses participate as agents alongside native ones.

Goal. Run tools like Claude Code, Codex, OpenCode, Pi and the DeepSeek harness as first-class agents — same mailbox, same chat, same tool surface — rather than as subprocesses a native agent shells out to.

Proposed shape

MCP server exposing TreeGent primitives (chat.send/check, mail, approvals, files, memory) so a harness that speaks MCP can call them natively.
Wrapper/adapter per harness for the ones that do not: spawn the CLI, translate its I/O to MCP calls, surface its output as a chat message.
Identity: each external agent gets an actor id and a mailbox, so it is addressable and auditable exactly like a native one.

Why this is worth doing

Harnesses improve faster than any single native agent; being able to swap one in is leverage.
It turns "which model runs this task" into a routing decision rather than a rewrite.
Cost: external harnesses already handle their own context/tool loops, so they may be cheaper per task than a native agent driving an equivalent sequence.

Hard questions to settle first

Trust boundary. An external harness executes arbitrary code. It must not inherit approval-gating bypasses; mail.send in particular must stay gated by the supervising human.
Cost attribution. Metering currently assumes TreeGent calls the model. A wrapper needs to report usage or the ledger silently under-counts.
Failure surface. A CLI that hangs produces no events; the wrapper needs timeouts and a liveness signal or the agent appears alive while doing nothing.

Suggested first slice: one harness (Codex or OpenCode, whichever is most stable headless) behind the MCP server, running a single sandboxed task end to end, before generalising to the rest.

Requested by Felix 2026-10-20. Let external CLI agent harnesses participate as agents alongside native ones. **Goal.** Run tools like Claude Code, Codex, OpenCode, Pi and the DeepSeek harness as first-class agents — same mailbox, same chat, same tool surface — rather than as subprocesses a native agent shells out to. **Proposed shape** 1. **MCP server** exposing TreeGent primitives (chat.send/check, mail, approvals, files, memory) so a harness that speaks MCP can call them natively. 2. **Wrapper/adapter** per harness for the ones that do not: spawn the CLI, translate its I/O to MCP calls, surface its output as a chat message. 3. **Identity**: each external agent gets an actor id and a mailbox, so it is addressable and auditable exactly like a native one. **Why this is worth doing** - Harnesses improve faster than any single native agent; being able to swap one in is leverage. - It turns "which model runs this task" into a routing decision rather than a rewrite. - Cost: external harnesses already handle their own context/tool loops, so they may be cheaper per task than a native agent driving an equivalent sequence. **Hard questions to settle first** - **Trust boundary.** An external harness executes arbitrary code. It must not inherit approval-gating bypasses; mail.send in particular must stay gated by the supervising human. - **Cost attribution.** Metering currently assumes TreeGent calls the model. A wrapper needs to report usage or the ledger silently under-counts. - **Failure surface.** A CLI that hangs produces no events; the wrapper needs timeouts and a liveness signal or the agent appears alive while doing nothing. **Suggested first slice:** one harness (Codex or OpenCode, whichever is most stable headless) behind the MCP server, running a single sandboxed task end to end, before generalising to the rest.