A dozen gates, a dozen sources of truth
Shipping a frontier model upgrade means clearing a long line of gates before anything reaches users. The exact list differs by lab and by release, but the shape does not: safety and capability evaluations, red-teaming, a scaling-policy determination, policy and legal review, privacy and data-residency sign-off, a model card, infrastructure readiness, external communications — and whatever this particular release adds. Each gate has its own owner, its own definition of done, and its own place where the record lives.
The cost of that gap is predictable, and it shows up in three ways:
Answering “are we ready to ship?” means opening half a dozen tools, reconciling three definitions of “blocker,” and translating the result into one sentence an executive can act on.
By the time a readiness deck is assembled, it describes a state that expired hours ago. The answer ages faster than the meeting that consumed it.
A required review isn’t blocked — it was never opened. Nothing alerts on work that doesn’t exist yet, so it surfaces at the launch meeting a week late.
For a routine feature release this is friction. For a frontier model — where a rollback is public, a policy gap is a headline, and the release notes are read by regulators — it is risk.
And the bottleneck is not approval. Reviewers are fast when they have what they need; the two people on either side of the gap — the launch owner filing, and the safety, policy or legal reviewer approving — are both waiting on the same missing thing: a current picture of what’s outstanding and whose desk it’s on. That is a retrieval and reconciliation problem, which is exactly the shape of problem an agent is good at.
In launch rooms across the industry, the most repeated activity in the final weeks is not building, testing, or approving. It is asking someone else for status — and then re-asking, because the answer ages faster than the meeting that consumed it.
MCP as the universal adapter
No new dashboard. Nobody needs another place to check — they need answers where the launch conversation already happens, which is chat: Slack, Google Chat, Teams, or an internal assistant surface. That is a deliberate choice, not a shortcut. The launch thread is where the question gets asked out loud, so it is where the answer belongs, and an agent that lives there inherits an audience instead of asking for one. The Model Context Protocol gives the agent a standard way to discover and call the capabilities of each system — one common contract instead of a pile of bespoke point integrations that rot independently.
Each core tool sits behind an MCP server that exposes a narrow, typed surface: get_launch_milestones, list_open_blockers, get_approval_state. A middleware layer above them handles identity pass-through, caching, rate limits, and normalization — so a “P0” in the bug tracker and a “launch-blocking” flag in the governance portal resolve to one shared vocabulary before the model ever sees them.
Two behaviors fall out of that architecture, and together they are the whole product:
The agent walks the launch checklist on a schedule, detects prerequisites that were never opened, and pings the named owner in-thread with the one link that unblocks them.
“What’s blocking the v2.0 release?” returns one reconciled answer across every connected system in seconds — with a source link on every line, so the answer is checkable.
privacy “done”, portal shows no filing. Portal wins.
Ninety seconds of reading replaces forty minutes of assembly. Three things make that hard to build — and all three have an answer.
The third one is the real design decision. Disagreement between systems is not a bug to be fixed — it is the permanent condition of a large organization, and an agent that hides it is worse than no agent at all.
Boundaries before capability
The moment an agent speaks about release readiness, it is participating in a compliance process. Three boundaries make that defensible rather than reckless.
The agent prepares decisions. It does not make them.
Every answer is either cited or an admission that nothing was found.
Depth adapts to the audience. Access adapts to the asker.
Degradation is explicit. If an MCP server is unreachable, the agent posts a partial answer flagged with what it could not see and hands back to the manual runbook. The failure mode of a governance agent must be visibly incomplete, never confidently wrong.
Two scoreboards, not one number
Hours saved is the easiest number to claim and the least persuasive to a governance board. Two different questions get blurred into one: did the launch process get better, and is the agent trustworthy enough to keep in the loop. They deserve separate scoreboards because they carry different consequences. Missing a value target means the agent is disappointing. Missing a licence target means it gets switched off.
Time-to-approval per gate is the number leadership will ask for, so track it — median hours per gate, never averaged across gates. But treat it as context, not credit: it moves with reviewer capacity as much as with the agent, and cycle-backs are the part actually attributable to the work.
Two supporting checks sit under these: a weekly audit of sampled answers against source records (≥99% status accuracy), and escalation compliance — proof that every item touching safety, residency, or a public commitment actually reached the committee. Below threshold, the agent is paused, not tuned in place. That rule has to be written before launch, because nobody agrees to it afterwards.
These are proposed targets, not results. A frontier release is a small-n event — a handful a year, each different in scope — so the unit of measurement is the gate and the blocker, never “launches shipped faster.” Instrument first, run read-only through one pilot, establish the baseline from recent releases, and only then claim a delta.
Note what is deliberately absent: no “decisions automated,” no “reviews handled by AI,” no headcount deflection. In a release path that produces public commitments, those framings create exactly the wrong incentive. The value is that reviewers spend judgment on risk instead of retrieval — so the metrics measure preparation quality and elapsed time, never volume of human review displaced.
Wrong answers get triaged into one of two buckets: a retrieval failure (fix the tool or the precedence rule) or a reasoning failure (fix the prompt, add the case to a regression eval). That eval set is the real asset — it is what lets you upgrade the underlying model without re-litigating trust from scratch, which matters at a lab where the model beneath the agent changes faster than the process around it.
One pattern, many approval chains
Strip the launch vocabulary away and what’s left is a reusable pattern: a multi-party approval chain whose state is scattered across systems that will never be consolidated. Every large organization has several. The same architecture — MCP-brokered read tools, a normalized schema, declared precedence, cited answers, human-owned gates — transfers with the nouns changed.
This is why I think MCP is a transformation story and not an integration story. Once one uniform tool contract exists over the legacy estate, the marginal cost of the second agent is a fraction of the first — and the organization stops buying point solutions and starts building a capability. Which is the thesis this whole design serves: fund the middleware on the back of one high-value use case, then let the pattern compound. Launch governance is simply the use case worth funding it with.
What the module taught me
The hard part of conceiving an agent was never the model. It was deciding what the agent is not allowed to do, and writing that down precisely enough that an engineer could implement it and a lawyer could sign it. Capability came free; the boundary was the design work.
The second lesson: integration is a vocabulary problem before it is a plumbing problem. MCP solves how the agent reaches the tools in an afternoon. Agreeing what “blocked” means across three teams takes considerably longer — and that is the part that makes the answers trustworthy.
Which is the whole thesis, really. Agentic transformation in a serious organization is not a capability rollout; it is a governance design exercise that happens to ship software. The labs that will move fastest on releases are the ones that make their own approval process legible to a machine first — and keep every consequential decision firmly in human hands.
A six-week read-only pilot against one upcoming release. Read-only is the point — it earns an accuracy record before anyone is asked to trust the agent with an action.