How the API Contract Change Advisor Runs as a StudioX Mission

Harry has already made the business case for catching contract changes before they reach the field, in why it matters. I lead the Missions engineering team at StudioX, so my job here is the opposite: to open the hood and show you exactly how the API Contract Change Advisor runs as a StudioX Mission — which agents fire, how you watch them reason, where a human gates the one action that touches the outside world, and how we wired the enterprise tools without writing integration code.

A Mission is a small org chart of agents

The Advisor is not a script. It is a Mission: a roster of specialist agents coordinated by a two-tier reasoning system. When something kicks the Mission off — a CI hook calling the runtime endpoint POST /missions/run/{slug} with an intent like "the payments.proto contract just changed on main, advise" — Tier 1, the Reasoning Core, looks at the request and the roster and decides, one round at a time, which single agent should act next. It accumulates each agent's result and keeps routing until it judges the request answered. Tier 2, the agent planner, takes the goal handed to the chosen agent, discovers what that agent can actually do, decomposes the goal into ordered steps, and executes them.

For this use case the roster is three specialists plus a report agent:

• A Diff Agent, backed by a bot with MCP tools that can read the changed spec and its previous version from the source repository or schema registry. Its job is to turn "a commit landed" into a precise, structured list of what changed — fields added, removed, retyped, or made required.
• An Impact Agent, backed by a bot whose knowledge base is your service dependency graph — which services consume which contracts, and who owns them. It maps the diff onto that graph to produce the list of affected downstream services and their owners.
• A Notification Agent, which takes the diff and the impact map and drafts the actual downstream message — specific to what changed, addressed to the people who consume it.
• A Report Agent, whose output the Mission persists as a first-class report record for the audit trail.

Every one of these is a StudioX agent — a Vibe backed by its own bot and its own knowledge base. Knowledge is isolated by design: the Impact Agent only ever searches the dependency graph, so it never confuses a service map with a spec diff.

How the two tiers actually run

Round one, the Reasoning Core routes to the Diff Agent. Tier 2 kicks in: the planner runs capability discovery against that agent's bot — asking what MCP tools, knowledge bases, and vibes it has — then plans an ordered set of steps. Each plan ends in a reason step that produces the user-facing output; the earlier steps do the tool work. The Diff Agent's data step calls its MCP tools to fetch both versions of the spec and returns a scoped result: not the raw 8KB of the file, but the slice the Core asked for — the specific fields that changed and how.

The Core reads that result, decides the diff alone does not answer the request, and routes round two to the Impact Agent. That agent queries its dependency-graph knowledge base for every consumer of the changed contract and hands back the affected services with their owners. Round three routes to the Notification Agent, which now has both the diff and the impact map in context and drafts the message. When the Core judges the request answered, it stops routing and synthesizes the three results into one coherent advisory.

Watching it reason

The part I care most about is that none of this is a black box. Every phase — each routing decision, the capability discovery, the plan, every step and its validation verdict, the synthesis, and the final answer judge — is recorded as a trace event and streamed live over Server-Sent Events to the Explain rail in the portal. You are not trusting that the Impact Agent found the right consumers; you can watch it select the dependency-graph KB, see the query it ran, and read the plain-language reason the Core gives for each hop. When a change ships and the advisory looks wrong, the trace tells you whether the diff was misread or the dependency graph is stale — and you fix the knowledge, not the code.

Where the human gates the action

I want to be precise about what is automated and what is not, because it is the honest heart of the design. The diffing and the impact mapping are entirely read-only — they observe and reason, they change nothing. The one action that reaches the outside world is sending the downstream notification, and that is gated. During synthesis the Mission carries a human-in-the-loop instruction: for an outbound broadcast it does not claim it sent anything. It emits a [REQUEST_APPROVAL] marker block, which the chat route turns into a decision queue row and a magic-link approve/reject email to the reviewer. The message the user sees becomes an "awaiting approval" status block. Nothing goes out until a human clicks approve. If instead you want the impact map as a browsable surface, the Mission can emit [REQUEST_PORTAL], which the route turns into a clickable portal link.

Wiring the tools without writing integration code

The Diff Agent needs to read your spec repo and registry; the Notification Agent needs Slack and email. We wire all of it with instant MCP servers — you import an OpenAPI spec or start from a template, the tools are generated for you, secrets are encrypted and auto-injected as headers on every call, and a dynamic base URL lets one server point at prod or staging without duplicating anything. Because the Generic Agent discovers MCP tools at runtime, registering a new source — say a second registry — makes it usable immediately, with no redeploy. If your registry speaks something messier than clean REST, the same tool builder handles SOAP, RESTCONF, and form-encoded auth; the enterprise integrations guide covers those cases, and the AI workflow automation page shows where Missions fit the broader picture.

If you want to see the whole thing produce a real number on a real change, Harry's field walkthrough is in in practice.