How Mentor Bot Works: A StudioX Mission You Can Watch Reason

When Ajay describes Mentor Bot as "guided learning and design Q&A against your own patterns," what he is describing, architecturally, is a StudioX Mission. I lead the Missions engineering team, and I want to walk through exactly what happens between an engineer typing "why does our payments service swallow retries the way it does?" and a grounded, cited answer coming back — because the how is what determines whether an engineer trusts the answer enough to act on it.

The short version: a Mission is a small org chart of specialist agents, coordinated by a reasoning core, where every decision is streamed as an observation you can watch. It is not a single model with a big prompt. Let me take it in tiers.

Tier 1: the reasoning core routes the question

Every message enters through the Mission chat route, which authenticates the request, loads the Mission and its enabled agents, and hands off to what we call the reasoning core. Think of the core as a project manager. It does not know anything about your payments architecture itself — all of that domain knowledge lives in the agents. What the core knows is the roster: each agent's name and description, plus a one-line directory of every knowledge base attached to the Mission.

Each round, the core makes a single LLM call and picks exactly one agent to act next — or decides the question is already answered and returns done. For Mentor Bot the agents are carved along the shape of your institutional memory: an Architecture agent over design docs and ADRs, an Incident History agent over post-mortems, a Conventions agent over your style guides and code-review norms. A "why do we swallow retries" question routes to Architecture first; if the reasoning core sees that the real answer lives in a specific outage, it routes a second round to Incident History and accumulates both results. It re-reads every prior result each round and decides semantically when it has enough — a design decision that shows up cleanly is a complete answer.

If a Mission has exactly one enabled agent, the core skips routing entirely and chats that agent directly. That is the cheapest, most common path, and it is worth knowing it exists so the architecture does not sound heavier than it is.

Tier 2: the chosen agent plans and executes

Once an agent is selected, the planner takes over. It first discovers what that agent can actually do — its knowledge bases, any MCP tools, any vibes — then decomposes the goal into an ordered list of steps. For Mentor Bot the steps are mostly knowledge retrieval: query the design-doc knowledge base, rerank the results for relevance, then a final reason step that produces the actual user-facing answer. Every plan is required to end with that reason step.

Here is a detail that matters for trust. Each agent is backed by its own StudioX bot with its own isolated knowledge base. The Architecture agent only ever searches architecture documents; it cannot accidentally pull an answer from an unrelated corpus. Knowledge isolation is by design, and it is why a cited Mentor Bot answer can point at the specific doc it came from.

Observations: you watch it reason

This is the piece I care most about. Every phase of the Mission — the routing decision, capability discovery, the plan, each step and its validation, the final answer check — is recorded as a trace event and streamed to what we call the Explain rail over Server-Sent Events. The engineer does not just get an answer; they get to watch the Mission select the Architecture agent, query the design-doc knowledge base, rerank, and synthesize. When the answer says "we swallow retries because of the March incident," the observation trail shows exactly which post-mortem produced that. An answer a new engineer can verify is an answer they will act on without pinging a senior to double-check — which is the entire point.

Where the decision queue and human-in-the-loop sit — and where they honestly don't

StudioX Missions support a decision queue and human-in-the-loop gating: for destructive or high-blast-radius actions, a Mission ends its turn with a [REQUEST_APPROVAL] marker instead of claiming it acted, which the route layer turns into a decision-queue row and emails a reviewer a magic approve/reject link. That machinery is real — but I want to be honest about Mentor Bot: it is a read-only Mission. It queries knowledge bases and reasons over what it finds; it does not deploy, mutate, or take any action that would warrant an approval gate. So the decision queue is not on its critical path. I mention it because the same framework that safely answers "how do we do X?" is the one you would extend the day you want an agent to actually do X — and then human-in-the-loop is exactly how you keep that safe.

The portal, and wiring tools with instant MCP servers

Engineers reach Mentor Bot through a StudioX portal — the UI surface where they ask questions and read the streamed observations. And when you want Mentor Bot to reach beyond static docs — to pull a live answer from your ADR service, your wiki API, or a source-control system — you register that tool as an instant MCP server. The agent discovers it at runtime and can use it immediately: no integration project, no redeployment. Register the tool, and the next question can use it.

That is the whole machine: a reasoning core that routes, specialist AI workers grounded in isolated enterprise knowledge bases, observations you can watch, and MCP for reach. For why this problem is worth solving at all, read Ajay's take on why it matters; for a field account of it running, see Harry on Mentor Bot in practice.