Mission authority
Owns mission contracts, planning state, work inventory, budgets, checks, gates, ratification, and terminal receipts.
Technical documentation
Grex architecture
Grex separates the software doing the work from the system deciding whether that work is authorized, bounded, evidenced, and complete. This page describes those stable product boundaries without making a particular assistant or agent framework authoritative.
01 / System boundaries
Control plane, worker nodes, and portable capabilities.
Owned execution boundary
A physical or virtual computer controlled by the operator. It supplies local compute, tools, state, and runtime access.
Versioned capability
A deployable capability pack containing one or more Actors, declared requirements, health policy, and executable behavior.
Individual worker
An agent performing bounded work. Actors produce artifacts and execution evidence; they do not settle mission success themselves.
02 / Mission lifecycle
Durable state replaces a long-running chat transcript.
Contract
Outcome, verification surface, boundaries, economics, and stop conditions.
Plan
Work is decomposed into explicit items that can be claimed, retried, or settled.
Execute
Actors run on available Nidi and persist artifacts and receipts as work advances.
Evaluate
Checks and judgments compare the evidence with the authoritative contract.
Settle
The mission ratifies an outcome, waits at a gate, or records an evidence-backed stop.
03 / Verification and ratification
The producer is not the final judge.
Capability packs emit domain artifacts and evidence. Server-held checks evaluate those artifacts. Independent judgments may challenge their integrity, relevance, or citations. Ratification is a separate control-plane decision that requires an accepted basis; a worker's completion message is not that basis.
producer claim → artifact → check → judgment → ratification
04 / Economics
Budgets are executable policy.
Grex tracks spend across worker activity and supports cap actions that alert, degrade the selected model, or pause execution. Mission contracts can also carry time, value, margin, spend, and operator-attention terms.
Operator gates
Artifact and action policies determine when a durable operator decision is required. Gates remain control-plane state rather than depending on one assistant session staying connected.
05 / Receipts
One terminal record for the mission outcome.
A mission ends in a terminal receipt and may produce ratified artifacts. Exported receipt envelopes are signed, self-contained JSON documents. A third party can verify the signature and stored claims offline with the corresponding public key.
A signature proves the document was issued by the signing control plane and has not changed. The strength of an individual outcome claim still depends on the evidence captured and the checks applied to it.
06 / Assistants and runtimes
Interaction and execution are replaceable edges.
The target model is assistant-agnostic control through Grex MCP services. OpenClaw, Hermes Agent, Grok Bot, Claude, or another capable assistant can become an operator-selected command surface. Agent frameworks and model runtimes can also vary across capability packs.
Compatibility is named as supported only after the pairing has passed its onboarding, mission-control, and safety checks. The Grex control plane remains authoritative for budgets, gates, evidence, ratification, and receipts regardless of the assistant used.
For the customer-facing story, see how Grex bounds and verifies autonomous work.
Share your interest