Bring your own engine: why your agent runtime should be a commodity

Teams often start an agent project by choosing a runtime and then let that choice define the rest of the architecture. That reverses the durable part of the problem. A runtime should be replaceable. The governance around actions, spend, outcomes, and people is the part worth keeping stable.

The split

The control plane is the system that governs work across agents. It records receipts for each action, enforces budget caps, routes approvals, and decides what runs next. It knows whether a step is safe to run in away-mode, whether publication needs a human gate, and what outcome the previous step asserted. It can provide the same operational record even when the software performing the task changes.

The agent runtime is the execution environment for a particular worker. It calls tools and the model, manages a prompt or task loop, and turns a request into tool calls. The runtime may choose how to retry, how to format context, or which model to use. Those are important implementation choices, but they should not decide whether an external commitment is approved, whether a budget cap has been reached, or whether a claimed result is recorded as an outcome.

This separation gives each side a clear contract. The runtime asks to perform an action and reports what it observed. The control plane evaluates policy, allocates the action, records a receipt, and holds or releases the next step. Operators can change the runtime without losing the history that explains what the fleet did.

Two engines, same plane

Grex already governs two engines: Hermes and OpenClaw. They have different execution paths and different assumptions about how a worker interacts with its tools. That is useful evidence for the boundary. Both engines can operate under the same receipt shape and the same approval gates without requiring operators to rewrite either engine.

For a content workflow, Hermes might request a draft and OpenClaw might request the same CMS publication action. The runtime handles the model and tool calls. Grex records the action identifier, cost incurred, outcome assertion, and approval state at the moment of action for both. If publication needs a person, the same approval queue can hold either request. If the budget cap is reached, the same control plane can stop either run.

This also keeps migration practical. An operator can compare engines using the receipts they produce rather than comparing two unrelated transcript formats. Existing tool credentials, prompts, and retry behavior remain with the runtime. Fleet-level policy remains with Grex.

MCP as the slot

The Model Context Protocol (MCP) standardizes the tool-call surface between a client and the tools it uses. That surface is a natural slot at the edge of the control plane. An MCP client can ask to invoke a tool, receive its result, and provide the observations needed for a receipt while Grex continues to govern the action.

The important promise is not that every MCP client behaves identically. It is that another client can connect through a known mechanism without taking governance with it. A new runtime can slot into the control plane and keep receipts, audit history, and the approval queue. Its model choice and local loop can differ; the durable action record and policy checks do not.

MCP also makes the contract visible. Tool name, input, result, and error are explicit enough to attach to an action identifier and an outcome assertion. Grex can distinguish “the tool call returned” from “the requested business outcome was verified,” then route a publication or other external commitment to approval. The protocol is the connection point, not the governance layer.

What this means operationally

Choose the runtime your team already operates well. If your team has deployment, observability, and incident practice around Hermes, start there. If OpenClaw is already the better fit for a particular tool loop, use it. If another MCP client meets your operational needs, connect it through the same boundary. Do not let the runtime determine governance simply because it arrived first in the architecture.

A Grex Nidus is a machine running agents. A Manipulus is a crew of agents organized around a business function. The control plane can govern both while the runtime inside a Nidus changes. That lets a crew keep its budget cap, receipt history, and approval route as the underlying engine evolves.

In practice, standardize the things an operator must trust: receipts with a consistent outcome assertion, policy checks at the action boundary, explicit budget caps, and a visible approval queue. Leave model selection, prompt assembly, and tool-loop details to the runtime. This is a more useful division of ownership: execution can be a commodity, while the record of what happened and the authority to let it happen stay under your control.