How the Integration Risk Scorer Works: A StudioX Mission

When Ajay describes the Integration Risk Scorer as forecasting, an architect's first question is the honest one: forecasting how, mechanically, without hand-waving? I own the reference architecture for our Missions, so let me open the hood. The Scorer is a StudioX Mission — a small, ordered team of specialist agents driven by a reasoning controller — and everything it does is observable while it does it. No black box. That constraint shapes every design choice below.

The shape of the mission

A Mission is not one model with a big prompt. It is a controller loop over a private working memory — we call it the notepad — that decides one scoped action at a time, files each result, and re-plans from what the result actually says. The reasoning layer is the project manager; each agent is a worker that owns exactly one capability: one tool call, one knowledge-base query, or one vibe. Agents do not compose, so the controller decomposes the goal into single-capability asks. This is deliberate, and it is why the Scorer stays reliable on real, messy history instead of hallucinating resemblances.

For the Integration Risk Scorer, the roster is small and purpose-built:

• Change Analysis Agent — reads the proposed change (diff, touched files, the config and interface seams it crosses) through a source-control MCP server. Read-only.
• Escape History Agent — a bot backed by its own knowledge base: your post-mortems, defect records, and escape log. It answers one question well — which past escapes resemble this seam? Read-only, and knowledge-isolated: it searches escapes and nothing else.
• Coverage Agent — checks the planned test suite against the risky seam via a test-management MCP server (whatever you run — TestRail, Xray, an internal system). Read-only.
• Generic Agent — no fixed domain. It discovers whatever MCP tools are registered at runtime and uses them immediately, so wiring a new tracker never means a code change.

One iteration at a time, and why the order matters

Here is the mechanic that makes the forecast trustworthy: the controller authors each agent's request from the previous finding, and ships only a tightly scoped ask — never its whole context. Reliability lives in the correctness of the question, not in second-guessing the answer.

Walk the loop for a real change:

1. Iteration 1 — discover + invoke Change Analysis. The controller asks, in effect, "identify the components and integration seams this diff crosses, with the exact interface and config touchpoints." The agent runs its one source-control capability and files a small, precise finding: this change touches the billing↔payments retry-and-idempotency seam.
2. Iteration 2 — invoke Escape History. Now the controller uses that seam to author the next question. It does not paste the diff in. It asks the Escape History Agent for escapes whose failure signature involves that specific seam. The finding comes back: escape 2024-1183, a retry/idempotency test-escape that cost two cycles, plus two lower-similarity neighbors.
3. Iteration 3 — invoke Coverage. The controller now knows the exact hazard, so it scopes a coverage question: does the planned suite exercise the idempotency-under-retry path that 2024-1183 slipped through? The finding: it does not.
4. Render. The controller holds all three findings in the notepad and composes the verdict itself — a risk forecast with the resemblance named, the evidence cited, and the coverage gap called out.

Because every ask is scoped, each agent returns a handful of relevant rows, not a raw dump — so nothing truncates, and the reasoning stays grounded in real records. Critically, the controller re-plans on what a finding contains, not on how complete it looks. A grounded "no resembling escape found" is a valid, final answer — a low-risk forecast — and the mission never manufactures a resemblance to fill space.

scoped ask ▼ finding ▲