How the Bug Resolution Note Generator Mission Works
When Harry hands me the "engineers never write the notes" problem, my job is to turn it into something a StudioX Mission can actually run — and to be honest about which parts of it are safe to automate and which parts a human still has to bless. The Bug Resolution Note Generator has been live for us for a while now, so this isn't a whiteboard architecture. It's what's in production. Let me walk you through the mechanics the way I'd walk a new engineer through it.
A Mission is a small org chart of agents
The first thing to understand about StudioX Missions is that a Mission isn't a script. It's a roster of specialist agents plus a reasoning layer that decides, one step at a time, which agent should act next. You describe what each agent does in plain language; the Mission's router — what we call the Reasoning Core — reads those descriptions and routes to them. There's no hardcoded flowchart. Change an agent's description and the routing changes. Add an agent and it gets considered automatically.
For this use case the roster is small and purposeful. A Change Agent that reads the actual code change — the diff, the commit message, the linked PR. A Ticket Agent that reads the issue and, when approved, writes the status and fields back. A Note Agent that drafts the resolution note from what the other two found. And an Email Agent that composes the customer-facing message. Each agent is backed by its own StudioX bot with its own knowledge base, so the Ticket Agent only ever searches ticketing context and never accidentally leaks the customer-email tone guide into a status field. Knowledge isolation is a design property, not a convention.
How the reasoning actually runs
When someone tells the Mission "the fix for BUG-4471 just merged," the Reasoning Core runs a routing loop. Each round it makes one model call: given the request and the accumulated results so far, which single agent acts next — or are we done? Round one it routes to the Change Agent to go read what actually changed. When that comes back, it re-reads the result and routes to the Ticket Agent for the issue context. Then to the Note Agent to draft. Then the Email Agent. When the Core decides the request is answered, it exits and synthesizes one coherent response.
Underneath each agent is a second tier — the agent planner. When the Core hands a goal to, say, the Change Agent, the planner discovers that agent's capabilities (which MCP tools, which knowledge bases it has), decomposes the goal into a short ordered list of steps, and executes them against the agent's bot. The planner always ends on a reason step — the one that produces the clean, human-readable output. It's genuinely dynamic: nothing about "call GitHub, then read the PR body" is hardcoded. The planner reasons about the goal and the tools it discovered.
Observations: you watch it think
The thing I care most about as an engineer is that none of this is a black box. Every decision the Mission makes streams out as an observation over Server-Sent Events, in real execution order. You see "Routing to Change Agent — need the actual diff before we can describe the fix," then "Discovered 3 tools on the GitHub server," then the plan, then each step and whether its output validated. If the Mission drafts a note you don't like, you don't guess why — you scroll the Observations rail and see exactly which step produced it and what it read. That trace is what makes autonomous drafting trustworthy instead of scary.
Where a human still has to say yes
Here's the honest part, and it's the part that matters most for a tool that touches customers. Reading is autonomous. Acting is gated. The Change Agent reading a diff, the Ticket Agent reading an issue, the Note Agent drafting — all of that is read-only and runs without asking. But the moment the Mission wants to write the ticket status back or send an email to a customer, it doesn't just do it. The synthesis step emits a [REQUEST_APPROVAL] block instead of claiming the action was taken. The route layer turns that block into a row in the Decision Queue, emails the reviewer a magic-link approve/reject URL, and shows the user an "awaiting approval" status in chat. Nothing leaves the perimeter until a human clicks approve. For destructive or customer-visible actions, that human-in-the-loop gate is the default, not an option.
If the output is better shown as a surface than a message — a preview of the drafted note and email side by side — the Mission can emit a [REQUEST_PORTAL] block, and the route builds a portal in Studio and hands back a clickable link. Same pattern: the model asks for the surface, the platform provisions it.
Why the tools "just work"
The last piece is the one that used to be a six-month integration project: connecting to GitHub, to Jira or ServiceNow, to the mail system. In a Mission these register as instant MCP servers, and the Generic-style discovery means an agent finds a tool at runtime and uses it immediately — no code change, no redeployment. Swap Jira for Linear and you register a new MCP server; the Ticket Agent discovers it and adapts. That runtime capability injection is what "no engineering to add a tool" means concretely.
That's the whole machine: a roster of read-only-by-default agents, a reasoning core that routes over them, observations you can watch, and a decision queue that stops any real action until a person approves it. If you want the leadership framing for why this was worth building, Harry lays it out in why it matters; for a real bug run end to end, see in practice. And if you're mapping this pattern onto your own stack, it's the same architecture behind our business applications and AI workflow automation.
Discussion
No comments yet — start the conversation.