Shizhi Gu

Every product I look at now says it “uses AI.” So does every competitor, and the one shipping next quarter. Adding a model is not an advantage. It is the new table stakes, and table stakes are not a moat.

The leverage shows up somewhere more specific. AI is a wedge when it collapses a whole chain of work into one artifact, not when it makes a single step a little better. Reading, sorting, arguing, drafting, tracking: if a model compresses that entire handoff into a finished, ready-to-act result, that is worth paying for. A neater summary of the same inputs is not.

So I ask one thing. Does the thing produce a decision, or a tidier pile of inputs for a human to decide from? Organizing is cheap. Producing the finished artifact, with its sources attached so it can be trusted, is the wedge.

And when everyone can build the obvious version cheaply, the advantage moves to the loop. Not the feature, the loop: a set of examples you rerun every day, watching whether the output got sharper or quietly started lying. That is where a small team with a fast cycle beats a big one with a roadmap. The model is a commodity. The judgment about when its output is good enough to ship is not.

For as long as I have built software, the product was the screens. You designed the dashboard, the person learned it, the person clicked through it. That assumption is quietly breaking.

When an agent can operate a system, the screens stop being the product. The product becomes the substrate underneath them, a clean set of objects and actions a human or a machine can drive. If a human can click it, an agent has to be able to call it. Anything less and the agent is stuck scraping a screen built for eyes.

This changes what you sell. Not model output, not “our AI writes your summaries.” You sell that the customer's own agent can operate your system the way it operates code. The intelligence is theirs to bring. Your job is the substrate and the safe boundary around it.

It changes how it gets used, too. The old shape was a person working a dashboard. The new shape is an agent doing the work and a person approving it. Onboarding stops being a product tour, because nobody has to learn the screens first. Even the documentation inverts: a person will not read thirty thousand words before trying a tool, but an agent will, and the exhaustive manual that would bore a human becomes an edge for the machine reading it.

None of this needs a model living inside your product. Agent-native is an architecture, not a feature you bolt on.

Here is the problem with letting something non-human act inside a real system. It will be wrong sometimes, and confident while it is wrong. So you do not hand it the keys. You engineer the trust into the boundary where it acts.

The shape that works is borrowed from version control. The agent changes nothing directly. It proposes. The system computes a diff, shows what will change and what it touches, and a person approves, edits, or rejects before a single record moves. A git diff for operations. Holding the credential to request a change is not the same as permission to commit it.

Two habits earn the rest of the trust. Every claim carries its receipts: a generated summary is derived material, not evidence, and when the sources behind it are missing, the honest move is to flag that as a risk, not to fill the gap quietly. And be straight about reversibility. An audit log shows what changed. It does not promise you can undo it. Offer an undo only where a real one exists, and say so plainly everywhere else.

The rest follows from treating the agent as capable and untrusted. Credentials that are scoped and revocable. Errors verbose enough to repair, that name which gate blocked you and how to get past it. Actions that fail loudly instead of pretending. And a person who stays the approver of anything that reaches the outside world. The agent can draft the message. The human sends it.

The old way to measure a product was to count what it did. Features shipped, workflows built, boxes ticked on a comparison grid. When a system is a substrate an agent operates, that count stops meaning much.

The better question is what can be built from it that I never built myself. Call it expressive range: the number of useful workflows an agent can assemble from the objects and actions I exposed, without me shipping each one. A product with ten features and narrow range is worth less than one with five primitives an agent can combine a hundred ways.

Range is not the only axis. Intent fidelity: when someone asks for a result in plain language, how close the generated thing lands to what they actually meant. And generation efficiency: how many tries the agent needs to get there. A kernel that takes twenty attempts to produce one correct workflow is not really operable, however powerful it looks on paper.

There is a clean failure test. If the agent can only recreate the screens I already built, the kernel failed. I shipped a UI with an API stapled on, not a substrate. The point was never to let a machine click my buttons faster. It was to let it build the things I never got around to.