From Merge to Sign-off: The Contract Change Advisor in Practice

I want to walk you through a single Tuesday, because the value of the API Contract Change Advisor does not show up in an architecture diagram — it shows up in what does not happen six weeks later. If you have read how it works, you know the Mission's shape. Here I am going to run it against a real-feeling change and count the hours on both sides, the way I do when a team asks me whether this is worth standing up.

9:14 a.m. — the change

A platform engineer on the Orders team ships a change to fulfillment.proto. They rename warehouse_id to facility_id and, while they are in there, make a previously optional region field required. It is a clean, well-reviewed commit. It is also, unknown to the engineer, consumed by four downstream services owned by three different teams — a shipping-label printer, an inventory reconciliation job, a customer-facing delivery-estimate API, and an internal analytics pipeline. The engineer knows about exactly one of these. That is not negligence; it is the normal condition of working in a system too large to hold in one head.

The old Tuesday (that we are replacing)

In the world without the Advisor, nothing happens on Tuesday at all. That is the whole problem. The change merges, the CI is green, everyone moves on. The break is scheduled for later.

• Week 1–5: The reconciliation job silently reads a now-empty field. The delivery-estimate API starts rejecting a slice of requests because region is suddenly required and its callers do not send it. The errors are low-volume enough to sit under the alerting threshold.
• Week 6, Thursday: A key retail customer escalates that their delivery estimates have been intermittently failing. Now it is a Sev-2.
• The response: Two senior engineers spend the better part of a day on root cause. Another day and a half remediating and back-filling. A day of the delivery-estimate team's time patching their client. Account management spends a week on relationship repair. Call it five-plus engineer-days and a bruised customer — for a five-minute rename.

I have sat in that post-mortem. The most demoralizing line is always the same: "If we'd just known on the day, this would have been a Slack message."

The new Tuesday

Here is the same change with the Advisor running. A CI hook on the Orders repo fires the Mission the moment the commit lands on main.

Elapsed machine time: under 2 minutes. Human time: one 5-minute review. Field escapes avoided: 1.

By 9:16 the Mission has done its work, and every hop is visible on the Explain rail in the portal. The Diff Agent read both versions of the spec from the schema registry through its MCP tools and reported two breaking changes — the rename and the newly-required field — with the old and new shapes side by side. The Reasoning Core routed to the Impact Agent, which queried the dependency-graph knowledge base and returned all four consuming services and the three teams that own them. The Notification Agent drafted a message that actually says something useful: "fulfillment.proto changed on main. warehouse_id → facility_id (rename, breaking). region is now required. You consume this via the shipping-label and delivery-estimate services; here is what to change."

Then it stopped and asked. Because sending the notice is the one action that reaches real people, the Mission emitted an approval request rather than broadcasting on its own authority. A release lead got a magic-link email, opened the decision queue, read the draft and the impact map, and clicked approve at 9:41. The three downstream teams knew about the change the same morning it shipped — while the author was still on the same coffee.

What actually changed about the day

The reconciliation team updated their field mapping before their next run. The delivery-estimate team shipped a client change that afternoon that added region, so the requests that would have failed in week two never failed at all. Nobody spent a day on root cause, because there was no root cause to find. The Sev-2 in week six simply did not exist.

Tally it the way I do for customers:

• Machine time: under two minutes, unattended.
• Human time: one five-minute review by one person.
• Avoided: roughly five engineer-days of root cause and remediation, plus a week of account repair, plus one customer-visible incident that never happened.
• Cycle compression: "learn about the break" moved from week six to minute two — the entire point of the use case, which internally we file under the verb connecting: connecting a change to the people it touches before the field connects it for you.

Why the story generalizes

The specifics here are one proto and four consumers, but the pattern is the whole reason we built it as a Mission rather than a bespoke script. The dependency graph the Impact Agent reads is knowledge, not code — when a new service starts consuming a contract, you update the graph and the next advisory is correct, with no release. When you add a new source system, you wire it as an instant MCP server and the agents can use it immediately. And because every run leaves a full observation trace and a decision-queue record, you get an audit trail of who was told what, and who approved sending it, for free.

If you are weighing whether to stand this up, start from the leadership case Harry lays out in why it matters, then look at the enterprise integrations and AI workflow automation pages to see how it connects to the systems you already run. The math is not subtle. You are trading a five-minute review on the day for a five-day escalation six weeks out, and you make that trade every time a contract changes.