If I had to reduce the OpenEXA architecture to one sentence, it would be this: agents decide, code executes. Every design decision we have made follows from where we drew that line.
Our stack has eight layers. The top four decide. Signal intelligence perceives the environment with our own risk and prediction models. The model layer reasons on a post-trained language model. Domain-specific agents propose actions. The execution council governs those proposals against policy. All four are probabilistic. They estimate, they reason, they can be wrong.
The bottom four execute, and they are deterministic code. The routing layer selects a venue and counterparty by scoring, not by judgment. The execution layer is a state machine that is idempotent, retried, and reconciled against the broker. The MCP server exposes authenticated tools to the outside world and is deployed per customer. The authentication layer holds scoped, revocable permissions for every agent and every tool.
Why the boundary sits there
Language models are excellent at the part of the lifecycle that used to require a specialist: reading an exception, interpreting a rule, proposing what to do. They are the wrong tool for the part that requires certainty: sending an order once and only once, confirming a fill, writing a record that cannot be edited.
By making layers five through eight deterministic, we get a property I consider non-negotiable in regulated work. Nothing an agent believes can move what it is not permitted to. An agent can be confidently wrong about the size of a NAV gap. The consequences of that error stop at the council, and even if the council approves, the execution layer will only do what the permission scope allows, exactly once, and it will reconcile the result with an independent counterparty.
Idempotency as a safety property
The execution layer is built around a simple contract: do it once. Every order transition has a unique identity. If a network fault causes a retry, the state machine recognizes the transition and refuses to run it twice. This sounds like plumbing. It is actually the mechanism that lets us give agents autonomy. Autonomy without idempotency means a confused agent can double-execute. Autonomy with idempotency means the worst case is a rejected proposal.
MCP as the structural interface
We use the Model Context Protocol as the boundary between reasoning and the external world. Brokers, custodians, exchanges, and clearing houses are exposed to agents as authenticated tools. Each customer gets their own MCP server, so permissions are scoped to that customer's accounts and nothing else. Custody never moves. No agent and no tool has withdrawal rights.
This is what lets us claim that the lifecycle is machine-actionable. The structured trait in our lifecycle test is not about data formats. It is about whether the process can be expressed as a set of tools with clear inputs, outputs, and permission scopes. When it can, the swarm can run it. When it cannot, no amount of model capability will make it safe.