Between the agents that propose and the code that executes sits a component we call the execution council. It is the fourth layer in the stack and the last layer that decides. Every proposal from every agent passes through it. It approves or rejects against policy in milliseconds, and its rejections are the most important output the system produces.
What the council checks
The council is a policy engine. For a create-or-redeem proposal, it checks the position caps, the permitted symbols, the trading hours, the approval mode the customer has set, and whether the proposal conflicts with another proposal in flight. If any check fails, the proposal exits at the gate and is logged. Nothing downstream ever sees it.
This is the mechanism that turns a swarm of probabilistic reasoners into a governed system. Individual agents can be aggressive in what they propose because the council is conservative in what it permits. In our interactive demos we let visitors adjust council strictness and watch the approval rate change. The lesson is that autonomy is a dial, not a leap. Turn the strictness up and the swarm becomes a recommendation engine. Turn it down within limits and it becomes an autonomous desk.
Three operating modes
We ship the council with three modes, and every customer chooses one per lifecycle.
Automatic: the council approves within limits and execution proceeds without a person.
With approval: a named person must sign every approved proposal before it executes. The council does the policy work. The human does the accountability work.
Manual: agents prepare the full proposal, the council checks it, and the customer's own desk executes.
The point of three modes is that the same swarm, the same model, and the same ledger serve a customer at every stage of trust. Institutions do not adopt autonomy all at once. They adopt it gate by gate, and the council is how they control the pace.
The kill switch
One switch halts everything, in every mode. It is database-backed, so it does not depend on any agent or any process being healthy. Every design review I run ends with the same question: if this component fails, does the halt still work? If the answer is no, the design is rejected.
Conflict arbitration
The council also arbitrates between agents. When two decision agents propose actions on the same basket in the same window, the council resolves the conflict by policy before either reaches routing. This is the swarm equivalent of a lock, and it is what allows thousands of agents to operate concurrently on a single lifecycle without stepping on one another.