How do you review an agent platform?

For two years the agent-platform question arrived at our desk as a whiteboard exercise. It now arrives as a review request, and the difference is that real deployments have published their homework. Pinterest's engineering team has described a production MCP fleet with domain-specific servers, a central registry and human-in-the-loop approvals; the protocol side has shipped enterprise-managed authorization so agent access can run through an identity provider. The patterns are no longer speculative. The review checklist can stop being one too.

what is actually new here?

Less than the vendors say and more than the skeptics allow. An agent platform is, structurally, a job-execution system: work arrives, credentials are exercised, side effects happen, records are kept. Reviews know how to hold those. What is genuinely new is the source of instructions. Every prior automation executed a program someone wrote; an agent composes its program at runtime from a goal, which moves the review's center of gravity from "is the code correct" to "is the authority correctly bounded when the code is improvised". Stated as our standing question: what would have to be true for an improvising actor to be safe on your estate? The answer has three load-bearing parts.

where does its identity come from?

Both published designs route agent access through the provider that already governs humans: Pinterest pairs end-user JWTs with service-mesh identities, and the EMA extension moves the connection decision to the enterprise identity provider. Neither gets you all the way. EMA is explicit that it governs the connection and not the individual action, which leaves the per-agent identity as work the estate still owes. The anti-pattern is the shared service account, and in reviews we now treat it as disqualifying: an estate that cannot say which agent did a thing has no audit trail, only a genre of fiction. The checkable conditions: one identity per agent, credentials scoped to named tools, and revocation that takes effect in minutes, tested, because the day it matters is not a day for discovering token caching.

where does its authority end?

The second part is the boundary between reversible and irreversible. An agent reading dashboards and drafting changes is a productivity tool; an agent executing schema migrations is a change-management actor, and the review asks whether the platform can tell the difference structurally. What we look for: a tool registry that classifies operations by reversibility, hard caps (rate, spend, blast radius) enforced below the agent rather than requested of it, and the human-approval gate placed exactly at the irreversible line. Pinterest's published design puts approvals in the loop for consequential actions, which is the correct reading of the wrong-rule failure mode: you do not review the agent's judgment, you architect for the day its judgment is confidently wrong.

what does its history owe you?

The third part is the record. For humans we log privileged sessions; for agents the equivalent is the full tool-call transcript: what was asked, what was invoked, with which parameters, returning what. Not the agent's summary of its reasoning, which is prose, but the calls, which are facts. The checkable condition is reconstruction: pick one agent action from last week and rebuild its causal chain in under an hour. Estates that can do this have an operations capability; estates that cannot have a demo with credentials.

what do we recommend?

Sequenced, as usual. Before any pilot: identities and the reversibility registry, because retrofitting either into a running platform is the expensive version. During the pilot: the transcript pipeline and one rehearsed revocation drill. Before scale: the reconstruction test, run quarterly, plus a standing review of which tools have crossed from reversible to irreversible as the estate changed, because that boundary moves and nobody announces it.

The published deployments earn a closing note. The companies shipping this well are conspicuously boring about it: registries, approvals, identity plumbing. None of it is the demo that impressed the board. All of it is why the demo can be allowed near production, and the gap between those two sentences is, as ever, where our invoices come from.