How StudioX Portals Work: A Mission With a Human Face

When people ask me how a Portal works, they usually expect me to start with the UI. I don't, because the UI is the last thing that happens. A Portal is the visible edge of a StudioX Mission, and to understand the surface you have to understand the machine it's bolted to. I'm Trevor — I lead the Missions engineering team — so let me trace the whole path, from a sentence a non-engineer types to the branded screen that answers them.

A Portal sits on top of a Mission

Start with the Mission, because that's where the real work lives. A Mission is a small org chart of specialist agents coordinated by a two-tier reasoning system. When a message arrives, Tier 1 — the reasoning core — looks at the request and the roster of available agents and decides, one round at a time, which single agent should act next. It can loop for several rounds, accumulating results, until it decides the request is answered.

Each chosen agent goes through Tier 2, the agent planner. The planner discovers that agent's capabilities — its MCP tools, its knowledge bases, its vibes — decomposes the goal into an ordered set of steps, and executes each one. Most steps run against the agent's own StudioX bot, which has its own internal pipeline; the final step is a reason step that produces the user-facing answer. Every routing decision, every plan, every step and its validation is recorded as a trace event and streamed live to what we call the Explain rail. That's the observation stream — the Mission narrating its own reasoning as it happens.

A Portal is the human-friendly projection of exactly this. Same Mission, same agents, same reasoning core. What changes is who's watching and what they're allowed to see and do.

The request path

Here's the sequence when someone asks a question through a Portal.

Entry and auth. The message hits the Mission chat route, which authenticates the user, loads the mission and its enabled agents, and hands off to the reasoning core. Nothing about this is Portal-specific — a Portal is just one authenticated caller among several. The same Mission answers an API call, a Slack message, or a Portal question with the same machinery.

Routing and planning. The reasoning core runs its routing loop. If the mission has exactly one enabled agent, it skips the router entirely and chats that agent's bot directly — the cheap fast path. Otherwise it loops: each round the router re-reads every prior result and decides, semantically, whether the request is already answered. When it is, the router returns "done" and we move to synthesis.

Capability injection. This is where instant MCP servers earn their keep. An agent's planner discovers tools at runtime from the MCP servers registered to its bot. Wrap an enterprise tool — a ticketing system, a network controller, an HR platform — as an MCP server, and the agent can use it immediately. No redeploy, no code change. From the Portal's point of view, the surface gained a new capability without the surface changing at all.

Observations, not black boxes

The thing I'm proudest of is that a Portal is never a black box. Every phase of the run — routing, discovery, the plan, each step and its validation, the final answer judge — is written as a trace event in true execution order and streamed to the Explain rail. When a Portal user wants to know why the Mission recommended path 2 over path 1, the observation is right there: "Path 1 eliminated by Policy Agent — breaches maintenance window."

Whether a given user sees that rail is a permission decision, not an architectural one. The bot pipeline gates its structured explainability events behind a per-user canSeeExplainability flag. An operator with the right role sees the full reasoning; a casual Portal user sees the clean answer. Same Mission, different projection.

The decision queue and human-in-the-loop

Answering is the easy half. The half that makes Portals safe for non-engineers is what happens when the Mission wants to act.

We do not let a Mission silently take a destructive, irreversible, or high-blast-radius action. Instead, the synthesis step is instructed to emit a [REQUEST_APPROVAL] marker block rather than claim the action was done. After the reasoning core returns, the chat route scans the final text for these markers. When it finds one, it creates a row in the decision queue, emails each reviewer a magic-link approve/reject URL, and rewrites the marker into an "Awaiting approval" status block the user sees in the Portal. Nothing changes state until a human clicks approve.

There's a sibling marker, [REQUEST_PORTAL], that does the inverse — it provisions a portal surface and rewrites itself into a clickable link. That's how a Mission can hand a user a purpose-built dashboard as part of its answer.

Building the surface itself

The Portal's layout is editable through a focused local chat surface, not a heavyweight builder. An operator types "make the KPI row four wide" or "add a decisions table at the bottom," and the editor's model emits a [REFINE_DASHBOARD] marker. The server parses it, applies the mutation to the portal spec, saves it, and streams back a cleaned reply plus the list of applied changes — the preview snaps to the new layout live.

Crucially, this editor doesn't route through the reasoning core. It's a direct, focused LLM call with the block-kind vocabulary — bar, gauge, big-number, decisions-table, findings-table, and the rest — and the row/column grid baked into its prompt, so it maps intent to real props instead of hallucinating unsupported ones. Fast, focused, obviously alive.

That's the whole stack: a Mission underneath, observations streaming out, a decision queue guarding every state change, and a branded surface a non-engineer actually wants to use. If you want the business case for why this matters, Harry lays it out in why Portals matter, and there's a concrete field walkthrough in Portals in practice. For the broader platform picture, start with AI Missions and the business applications built on them.