Most "AI assistants" are bolted on. The model lives outside your system, you paste context into it, it hands you text, and you do the actual work. The model never touches anything. It can't, because nothing inside your system speaks a language it knows.

We wanted the opposite. We wanted a capable model to be able to actually drive the daemon — to start a properly governed session, look up the procedure for the work at hand, advance a workflow step by step, and hand sub-tasks off to smaller workers — using the same controls a person would. The way to do that without inventing a bespoke remote-control API was to speak a protocol the model already understands.

A standard protocol is the seam

There is now a common way for tools to expose themselves to an AI — a model-context protocol — and the daemon speaks it. Our design note puts the mechanism in one sentence: "The daemon exposes its toolset over [the model-context protocol] so [an external facilitator] and other facilitators can call session.boot, policies.check, procedures.get, workflow.next, delegation.prepare, agent.execute, session.log," along with the chain-data and operation tool families.

Read that list slowly, because it's the whole point. Those aren't "AI features." They're the daemon's actual governance, session, and workflow controls — the same machinery that records what happened, checks what's allowed, and tracks where in a procedure you are. By exposing them over a standard protocol, we turned "let an AI help" into "let an AI operate the controls," with no special back door. The external model is just another caller of the same tools.

There's a small but important translation layer at that boundary. The harness on the model's side sends every parameter as a string — that's how its schema works — and the daemon's handlers expect properly typed values. So the protocol boundary coerces those string parameters into the shapes the handlers need, and it does that coercion once, at the edge, not re-attempted inside every handler. Our note is specific that "coercion failures surface at the transport boundary, not inside handlers." If the model sends something that can't be made sense of, you find out at the door, not three layers deep.

What "driving" actually looks like

Concretely, a facilitating model working through this protocol does something like this. It boots a session — which is not a no-op; booting establishes the governed context the rest of the work runs inside. It checks policy before it mutates anything. It pulls the canonical body of whatever procedure governs the task, so it follows the real steps and not a half-remembered version. It advances the workflow one step at a time, with the daemon validating that each step actually produced what it was supposed to. And when a chunk of work is better done by a smaller, cheaper model, it prepares a delegation and dispatches a sub-agent.

Every one of those is a tool call over the protocol. The daemon is in charge of what each call means and whether it's allowed. The model is the operator; the daemon is the machine.

One daemon, many sessions, many signing identities

Here is the part that makes this practical at scale, and it's the part most "AI integration" stories skip. In our own development, there isn't one model session talking to one daemon. There are roughly a dozen facilitator sessions working the same repository at once. They cannot share a daemon naively — they'd step on each other's identity and audit trail.

So the daemon is built to serve them concurrently and keep them distinct. Our note describes it directly: "A single [protocol] daemon serves many concurrent facilitator sessions," and crucially, "each session carries its own signer context header." That signer context is the load-bearing detail. Every action a session takes gets recorded and signed — and because each session brings its own signing identity along with each request, two sessions hitting the same daemon don't blur into one actor in the record. Who did what stays legible even when twelve "who"s are working at once.

There's even a defensive choice in how the tools are exposed: they're grouped at a coarser tier by default, specifically to dodge a caching bug on the harness side where the model's view of the available tool list could go stale. That's the kind of unglamorous decision that only shows up when you actually run many sessions against one server for weeks — which we have.

Why expose the controls at all

It's a fair question to end on, because exposing your governance surface to an external model sounds risky. The answer is that the alternative is worse. If the model can only produce text and a human has to translate every suggestion into an action by hand, the human becomes the bottleneck and the audit trail has a gap exactly where the real work happens — in the translation. By making the model call the real tools, every action it takes runs through the same policy checks, lands in the same signed record, and is governed by the same rules as a human's action. The model gets reach; the system keeps control.

That's the trade we made, and it's the right one: don't give the AI a separate, weaker copy of your controls. Give it the real ones, behind a protocol it speaks, and keep the daemon firmly in charge of what each control does.

Related: Plan With the Big Model, Work With the Local One · One Door for Every Model You Run.

Written by AI agents from real project logs; owned and edited by Mujo.