How the DevOps Doc Quality Reviewer Mission Works

In the companion piece on why this matters I made the business case for catching a thin runbook at the pull request instead of at 3 AM. Here I want to open the hood. The DevOps Doc Quality Reviewer is not a prompt and it is not a linter with a regex. It is a StudioX Mission — a small org chart of specialist agents coordinated by a reasoning layer — and every mechanic in it is one we ship in the platform. If you have read our Help Desk deployment guides, the shape will be familiar, because the Doc Reviewer runs on the same seven-agent template. That is the point of Missions: you do not build a new engine per use case, you change the knowledge and the tools.

The two tiers

A Mission runs a two-tier reasoning system, and understanding the split is the key to understanding everything else.

The top tier is the Reasoning Core — the orchestrator. It reads the incoming intent ("review this runbook") and the roster of available agents, and it decides, one round at a time, which single agent should act next. It accumulates each agent's result, re-reads the accumulated findings every round, and decides — semantically, not by string-matching — when the request is fully answered. It knows nothing about DevOps specifically; all the domain knowledge lives in the agents. Change an agent's description and the routing changes. That is why the same Core drives HR onboarding, security triage, and doc review without a line of orchestration code changing.

The bottom tier is the agent planner. When the Core hands a goal to a chosen agent, the planner discovers that agent's capabilities — its MCP tools, its knowledge bases, its vibes — decomposes the goal into an ordered list of steps, and runs each step against the agent's own StudioX bot. Each agent is a genuine worker with its own bot and its own isolated knowledge base, which matters here: the agent that knows the rubric for a good runbook only ever searches the rubric, and never accidentally pulls unrelated policy text into its reasoning.

The seven agents, mapped to doc review

The Doc Reviewer inherits the Help Desk mission's seven agents and gives each one a DevOps job:

• Intake pulls the target document — a runbook, a post-mortem, an incident retro — from wherever it lives, via an MCP-connected source.
• Classification decides what kind of doc this is, because the standard for a rollback runbook is not the standard for an incident retro, and picks the matching rubric.
• Knowledge holds the completeness standard itself: the encoded expectations that a runbook must name a rollback path, an owner, an escalation contact, verification steps; that a post-mortem must carry tracked, assigned action items.
• Draft composes the findings — the gap report that says exactly what is present and what is missing.
• Review is the human-in-the-loop checkpoint.
• Response posts the verdict back to the source — a PR comment, a ticket.
• Report writes the audit trail and feeds the analytics.

Watching it reason: observations

The thing that makes a Mission trustworthy is that you do not have to take its verdict on faith. Every phase is emitted as an observation — a structured trace event — and streamed to the Explain rail over Server-Sent Events as it happens. You see the Reasoning Core select the Classification agent, then the planner's ordered steps, then each step run against its bot, then the validation of that step, then the final answer judge. For a doc review that means the verdict is never a black box: when the Mission says "this runbook is missing a rollback path," the trace shows the Knowledge agent retrieving the rubric clause it checked against and the reasoning that concluded the clause was unmet. If it ever gets a call wrong, you can see exactly which knowledge or which agent description caused it, and fix that — no code change, no redeploy.

Where the human gate actually sits — and where it doesn't

I want to be honest about this, because it is the question every serious engineering leader asks. Most of the Mission is read-only. Reading a runbook, classifying it, checking it against a rubric, and drafting a gap report changes nothing in your systems — there is no destructive action to gate, so gating those steps would be theater.

The human-in-the-loop gate matters at exactly one boundary: when the Mission is about to take an action that leaves the sandbox — posting a blocking comment on a PR, opening a remediation ticket, marking a doc as failed. For those, the synthesis step emits a [REQUEST_APPROVAL] marker instead of silently acting. The route layer turns that marker into a row in the decision queue, emails the reviewer a magic-link approve/reject URL, and rewrites the reply into an "awaiting approval" status the requester sees in chat. The engineer approves, and only then does the Response agent post. For destructive or high-blast-radius outcomes the Mission asks first; for the analysis itself it simply reasons and shows its work.

Wiring your tools: instant MCP servers

The Doc Reviewer has to reach wherever your docs live, and that is handled through MCP servers — the Generic agent discovers registered tools at runtime and uses them immediately. Point an MCP server at your Git host to fetch a runbook from a branch; point another at Confluence or your ticketing system to post findings back. There is no integration project. Register the server, enable it on the relevant agent's bot, and the Mission can use it that turn — the same day, no redeployment. Swap your wiki for a different one and the agents do not change; they call the same tool names, and only the server behind them changes.

That is the whole system: a Reasoning Core, seven specialist agents backed by isolated knowledge bases, an observation stream you can watch reason in real time, a decision queue that gates only the actions that need gating, and MCP wiring that connects your stack in minutes. The architecture that makes all of this deployable inside your own perimeter is covered in enterprise deployment, and the broader Missions model in AI Missions. To see it applied to a real on-call rotation, read the field write-up.