Here is where most teams go wrong. They think about review as a product surface — a page in the UI where someone looks at a diff and clicks approve. That is the dessert. The vegetables are understanding what review actually requires at the infrastructure level.
An agent working on code produces diffs. An agent writing a marketing brief produces a document. An agent updating a spreadsheet produces numerical output. An agent modifying a website produces a visual change. These are all review artifacts, and they are fundamentally different in how they need to be presented, verified, and approved.
Build a review system that only handles code diffs and you have built a feature, not a primitive. Build a review system that accepts an artifact type as input and returns the appropriate verification surface and you have built something composable. Something that scales across use cases without requiring a new product for each one.
This is the API-level thinking that matters. What is the request? What is the response? What is the contract between the agent that produces work and the human who verifies it? Get that right and the UI becomes a composition exercise. Get it wrong and you rebuild from scratch every time you expand to a new use case.
Review is the bottleneck. Not model quality. Not prompt engineering. Not integrations. The thing that separates an impressive demo from a production deployment is whether a human can look at what the agent produced, understand it, and approve it with confidence. And almost nobody is building review as a first-class primitive. It is the same pattern that shows up in supervising hundreds of agents — the review surface determines how much oversight scales.
If you are building agent infrastructure, treat review as a layer in your architecture, not a screen in your app. Define the artifact types you support. Define the verification contract for each. Compose them into product surfaces later. The teams that get review right will be the ones whose agents make it past the demo.
Related Essays
Human Review Is Not a Limitation
Human review is not the bottleneck to be eliminated. It is the quality gate that keeps AI-generated slop from compounding into technical debt that takes years to unwind.
Taste Does Not Scale With Token Throughput
Code production is no longer the constraint. Deploy pipelines, feature flags, and code review are. The new bottleneck is taste, and taste does not scale.
Controllability Is Not Optional. Enterprise Teams Do Not Want Magic
Enterprise teams do not want magic agents. They want control over which submodules load, which tools run, and what the agent remembers — because they have been burned by black boxes before.
Key takeaways
- Review is the contract between an agent that produces work and a human who verifies it.
- Different artifact types — code, documents, spreadsheets, visual diffs — need fundamentally different verification surfaces.
- Build review as a primitive accepting artifact type as input and you have something composable across use cases.
FAQ
Why does it matter whether review is a feature or a primitive?
A feature ships once and breaks the next time you expand to a new use case. A primitive composes — you add a new artifact type, register the verification surface, and your existing review infrastructure handles it.
What artifact types should the primitive support?
Code diffs, documents, structured records, spreadsheets, visual changes, and infrastructure changes at minimum. Each has a different verification surface. The contract should be artifact-agnostic.