How the Solution PDF Generator Works: A StudioX Mission

Harry has made the business case for the Solution PDF Generator in "Why it matters", and there's a field walk-through in "In practice". My job here is to open the hood. I'm the lead engineer on the Missions runtime, and I want to show you that this feature isn't a document template with an AI sprinkled on top — it's a full StudioX Mission: a multi-step, stateful, observable workflow that reasons about a goal, delegates to specialist agents, gates the irreversible step behind a human, and returns a verdict with every decision traced.

A Mission is an org chart, not a script

The mental model that matters: a Mission is a small org chart of specialist agents, each an expert in one narrow thing, coordinated by a two-tier reasoning system. Nothing here follows a fixed path. Routing, planning, and validation are all model calls, not hard-coded if statements — which is why the same Mission handles a terse firewall fix and a sprawling multi-day network remediation without anyone editing a flowchart.

Tier 1 is the reasoning core — the project manager. It reads the engineer's intent and the roster of available agents and decides, one round at a time, which single agent should act next. It accumulates each agent's result, re-reads everything it has gathered, and keeps routing until it judges the goal complete. Tier 2 is the agent planner — the worker. When the core hands a goal to an agent that's backed by a StudioX bot, the planner discovers that agent's capabilities (its MCP tools, knowledge bases, and vibes), decomposes the goal into an ordered list of steps, and executes them — always ending in a reason step that produces the user-facing output.

The Solution PDF Generator is assembled on the same prebuilt Help Desk template that ships with StudioX — the one where the same seven agents (Intake, Classification, Knowledge, Draft, Review, Response, Report) work out of the box and you specialize the Mission by swapping knowledge bases and MCP servers, not by writing code. For our use case the agents map cleanly onto the document lifecycle.

Following one document through the loop

An engineer sends the Mission an intent — "write up the failover fix I just closed for the Riverside plant." The Intake Agent goes first. Its bot is wired to our ticketing system through an MCP server, and this step is read-only by design: it pulls the ticket, the timeline, and the config change. The reasoning core hands each agent a scoped return ask — it doesn't want a raw dump of the whole ticket, it wants the specific slice (the problem statement, the resolution, the affected systems), which keeps the working context tight.

Next the core routes to the Knowledge Agent, whose bot owns its own knowledge base. This is where reusability becomes structural: the agent grounds the write-up in our approved policy language, prior solutions, and disclosure rules — the same grounded enterprise knowledge that backs the rest of our platform, not the model's imagination. Also read-only.

The Draft Agent then composes the customer-facing document from the intake slice and the grounded knowledge — structure, tone, the branded sections. Still nothing has left the building; a draft is not a send.

Where the human gate lives

Here's the honest part, because it's the part that earns trust. The first three agents are read-only — they retrieve and assemble, they don't act on the outside world. The irreversible step is publishing: rendering the branded PDF and pushing it to the customer archive. That step is gated behind a human.

When the Mission reaches a destructive or irreversible action, it doesn't quietly do it and claim success. It emits a [REQUEST_APPROVAL] marker instead. The Mission route intercepts that marker, writes a row into the decision queue, and emails the assigned reviewer a magic-link approve/reject URL. The engineer (or a designated approver) sees the finished draft, and only on their approval does the Publish Agent run its MCP tools to render and archive the PDF. That's human-in-the-loop as a structural guarantee, not a policy request. If the Mission instead needs to surface an interactive builder surface, it emits [REQUEST_PORTAL], which the route turns into a clickable portal link.

Finally the Report Agent persists the outcome as a first-class record, so the archive grows with every fix — which is exactly the "leaves something behind" property Harry was after.

Watching it reason

None of this is a black box, and that's deliberate. A Mission streams its observations live over Server-Sent Events. Every phase — the routing decision, capability discovery, the plan, each step and its validation, the answer gate — is recorded as a trace event and rendered on the Explain rail in true execution order. An engineer can literally watch "Intake Agent selected… querying ticketing… Knowledge Agent grounding draft… awaiting your approval." When something goes wrong, you don't guess; you read the trace and fix the knowledge base or the agent description that caused it.

Why "instant MCP servers" is the unlock

The reason we stood this up in days rather than a quarter is that every external tool — the ticketing system, the PDF renderer, the document archive — is wired through MCP. Tools register at runtime; an agent discovers and uses them immediately, with no redeployment. Swap the archive from SharePoint to something else and the agents don't change; they call the same tool names, and only the server behind them moves. That's what makes this a platform capability and not a one-off integration. If a customer wants this pointed at their own stack, it's a configuration exercise across our business applications, not an engineering project.

That's the whole machine: intent in, specialist agents reasoning one round at a time, read-only retrieval, a hard human gate on the send, full observability, and a verdict — a branded, archived PDF — out the other end.