How the StudioX Decision Queue Works

When I explain the Decision Queue to an architect, I start by drawing the boundary it defends. A StudioX Mission is a small org chart of specialist agents coordinated by a reasoning core. It can read your systems, reason across them, and — through instant MCP servers that wrap your enterprise tools — it can act. The Decision Queue is the control point that sits between "the Mission has decided what to do" and "the action actually happens." Everything interesting about it is in how that boundary is drawn and enforced, and I want to walk through the real mechanics.

The Mission runs first, and it runs in the open

Before there is anything to approve, a Mission has to do its work. A user sends an intent in plain language, and the Mission's two-tier reasoning system takes over. Tier one — the reasoning core — looks at the request and the roster of registered agents and decides, one round at a time, which single agent should act next. Tier two — the agent planner — takes the goal handed to the chosen agent, discovers that agent's capabilities (MCP tools, knowledge bases, vibes), decomposes the goal into ordered steps, and executes them.

The part that matters for approvals is that none of this is hidden. Every phase — routing, discovery, the plan, each step and its validation, the final answer judge — is recorded as a trace event and streamed live to the Explain rail in true execution order. By the time a Mission proposes a state-changing action, the reasoning behind it already exists as an inspectable observation trail. This is not a log we generate to justify a decision after the fact. It is the decision, written down as it happens. That distinction is the whole reason the Decision Queue can be audited: the "why" is captured natively, not reconstructed.

The marker: how a Mission asks instead of acts

Here's the mechanic that does the real work. When a Mission's synthesis step produces its final response, it operates under a human-in-the-loop instruction: for any destructive, irreversible, or high-blast-radius action, it must not claim the action was taken. Instead, it ends its response with a structured marker block — [REQUEST_APPROVAL] (equivalently [REQUEST_DECISION]).

That marker is a contract. It says: I have reasoned my way to a proposed action, I have the capability to execute it, and I am deliberately stopping short. The Mission is choosing to ask rather than to do. And because it's a structured block rather than free prose, the system can parse it reliably instead of guessing at intent from natural language.

There's a subtle piece of the pipeline that protects this. StudioX runs an answer gate — a semantic judge that checks whether the Mission produced a usable answer before the user sees it, and can trigger one recovery render if it didn't. But the gate checks for action markers first: if the final response contains any matched marker block, the gate and its recovery pass are skipped entirely. The block is the structured answer, and re-rendering it through an LLM would corrupt the JSON inside. In other words, the architecture treats an approval request as a first-class outcome, not as prose to be cleaned up.

From marker to queue: the route layer

Once the reasoning core returns the final text, control passes to the Mission chat route, and this is where the marker becomes a Decision Queue entry. The route scans the final text for marker blocks and, on finding a [REQUEST_APPROVAL] / [REQUEST_DECISION] block, does three concrete things:

1. It creates an iris_decisions row — the durable, first-class record of the pending decision.
2. It emails each designated reviewer a magic-link approve/reject URL, so the reviewer can act without hunting through a console.
3. It rewrites the marker in the chat transcript into an "Awaiting approval" status block, so the person who triggered the Mission sees a clean pending state instead of raw marker syntax.

The Decision Queue tab then shows the pending row; the Email Log shows exactly what notification went out to whom. Two side effects, both auditable, both persisted before the user ever sees the reply.

Where the action actually lives — and why MCP matters here

A fair question at this point: what is the action the reviewer is approving? In StudioX, agents reach external systems through instant MCP servers — the mechanism that wraps enterprise tools and APIs as callable capabilities the Mission's agents discover and use at runtime. Register a tool with MCP, and the generic agent can use it immediately, no redeployment. That's how a Mission gains the ability to issue a refund or push a config change in the first place.

The Decision Queue is what keeps that ability from firing unsupervised. The Mission plans the tool call, reasons about it, and — for anything state-changing — routes the intent to call it through the queue rather than executing it inline. The capability and the authorization are deliberately decoupled: MCP gives the Mission its hands, and the Decision Queue makes sure a human decides when those hands move. My colleague Ajay writes about why that decoupling is the real unlock in why the Decision Queue matters.

What makes it auditable, precisely

Auditability isn't a feature you add; it's a property that either falls out of the architecture or doesn't. Here it falls out cleanly, from three facts working together:

• The decision is a row, not a message. iris_decisions is durable and queryable. There is exactly one place to look, and it holds who, when, and what.
• The reasoning is captured natively. Every step that led to the proposal is a trace event in the conversation record, rendered on the Explain rail in execution order. The "why" was written as it happened.
• The notification is logged. The magic-link email to each reviewer is recorded in the Email Log, so you can prove the request reached the person who acted on it.

Put those together and "who approved this, and on what basis?" stops being a forensic exercise across four tools. It's a lookup. That's the architectural promise underneath any credible AI workflow automation: the system that acts on your behalf must also be the system of record for why it acted.

The shape to remember

If you take one structural idea away, make it this: the Mission proposes in the open, marks state-changing actions with a parseable contract, and hands that contract to a route layer that turns it into a durable decision plus a magic link — while the reasoning that justified it already lives on the Explain rail. Autonomy and control are handled in separate steps, by separate parties, and the record writes itself. For the operational payoff of that design, our field team lays out the before-and-after in the Decision Queue in practice, and the broader agentic model is described in StudioX Missions.