Keep your agent engine replaceable

Choosing an AI agent should not mean rebuilding the rules around its work whenever you change tools. Grex’s architecture separates those two responsibilities.

Grex coordinates AI teams on computers the operator controls. The agent engine performs the task. A separate control service records the assignment, its limits, and the evidence used to judge the result.

The engine does the work

An agent runtime is the software that runs the model-and-tool loop. It assembles context, calls a model, invokes tools, and decides how to continue the task.

A browser search, a draft, or a command-line operation happens through that execution layer. Different engines can organize those steps differently.

The control plane keeps the operating record

The control plane is Grex’s central coordination service. It tracks mission state, spending limits, approval decisions, and outcomes.

Consider a content assignment. One engine might produce a draft; another might prepare the publication request. Both still need to respect the same approval requirement and record what happened.

Keeping those rules outside an individual chat session makes a change of engine easier to assess. The operator can compare the resulting records without reconstructing two unrelated transcripts.

What the early implementation demonstrated

At the time of this July report, Grex had exercised two execution paths: the Claude Code CLI and its bundled task engine. Both used the same control-plane approach to action records and approvals.

That is historical implementation evidence. It is not a promise that every engine or assistant connects automatically today. The assistant compatibility page describes the current integration direction.

Where MCP fits

The Model Context Protocol, or MCP, provides a shared way for assistants to reach tools. It can serve as a connection point between an assistant and Grex.

The protocol does not itself supply a mission budget, an approval policy, or proof of an outcome. Those responsibilities still need an implementation behind the connection.

The distinction is visible in a publishing task. A tool can report that a request succeeded while the intended page remains unpublished. Grex’s operating record needs to preserve that uncertainty until the result is checked.

The practical design choice

A worker computer is called a Nidus in Grex. A reusable capability pack is a Manipulus, and its individual agent roles are Actors.

Those names describe where work runs and how it is organized. The architectural goal is simpler: let execution tools evolve while keeping the assignment, authority, and evidence understandable.

For a concrete example of that evidence, read How AI receipts make work checkable.