Build the Product an Agent Can Operate

Why the next great software products will be built for machines that act, not humans who click

Nearly every app you use was built for a person who looks at a screen, points at things, and fixes small mistakes by eye before they matter. An agent doesn’t look. It reads, it acts, and it acts for someone who isn’t watching it work. So the product that wins the agent’s business won’t be the one with the prettiest dashboard. It’ll be the one an agent can pick up and run correctly on the first try, with nobody in the room to catch the error.

Design your product as if an agent is one of your most important users. That doesn’t mean ripping out your interface and bolting on a chat box; a prompt box on top of a confused product just gives the confusion a friendlier face. It means exposing the real structure of what your software does, clearly enough that a person and an agent can both run it. Four things make that possible, and most products today get all four wrong.

The API is the product, not a side door

The API used to be where you put the features that were convenient to expose. The clean ones. The ones that didn’t touch messy internal state or force a user through a three-step wizard with a warning to read and click past. The full product lived in the UI, and the API got a tidy excerpt of it, enough to integrate against but never the whole machine.

An agent works through that contract and nothing else. If a job your users do every day takes four actions and you exposed three, the agent can’t finish. It gets most of the way and stalls. Or worse: it finds a creative path through the three you did expose and leaves your data somewhere no human would have put it. Whatever your API leaves out, the agent can’t do, no matter how central it is to your product.

So expose the real actions, including the ones that felt too risky or too fiddly to publish. The wizard with the scary warning becomes an endpoint with a confirm flag. The thing a person does by shift-selecting forty rows and hitting delete becomes one call that takes forty IDs. The test is simple: if a person can do it in your product, an agent should be able to ask for it through the API.

Documentation has to change shape too. Most API docs only describe endpoints: here’s the route, here are the fields, here’s what comes back. An agent needs to know what the thing means, not just what it accepts. What’s an “account” in your system, and how is it different from an “organization” and a “workspace”? When does a charge become an invoice? Docs that explain the business concepts, and the rules connecting them, let an agent reason about a task instead of guessing at field names. Endpoint reference tells it how to call; concept docs tell it when and why.

And the object model has to be one model. The same entity should carry the same name and the same shape in the UI, the API, the exports, the webhooks, and the audit log. When a “customer” in the interface is an “account” in the API, a “user” in the CSV export, and a “party” in the webhook payload, a human shrugs and pattern-matches across the inconsistency without noticing. An agent can’t. It reads all five surfaces literally and concludes you have five different things. One concept with five names is five chances for the agent to act on the wrong one.

Make actions visible and reversible

Agents make mistakes.

So do people, and we’ve built our whole relationship with software around that fact: undo buttons, confirmation dialogs, the half-second of hesitation before someone clicks delete. But a person carries something an agent doesn’t. They remember what they did and roughly why. Ask them an hour later and they can reconstruct the decision and walk it back by hand, even if it takes a while to retrace.

An agent has no memory you can count on. The reasoning that produced an action may be gone the moment the action completes. If your product is the only durable record of what happened, that record has to be a good one. That means a trace for every action: what was attempted, what context informed it, which tool or endpoint was called, what changed, and how to undo it. Not a log line that reads PATCH /accounts/8821 200. A record a human reviewer, or another agent, can read later and understand: this agent, acting for this person, changed this field from this to that, because it was working on this task.

Often the reader isn’t a person at all. A supervising agent checks the work it delegated, or a compliance system scans for actions that crossed a line, and once in a while a human skims a week of agent activity over coffee, looking for anything that smells wrong. None of them can reconstruct what the agent was thinking, because that’s gone. So the trace has to carry the why, in a form the next reader can act on, whoever that reader turns out to be. A trace written for a developer staring at a stack trace at midnight won’t cut it.

Reversibility is the harder half. Plenty of products can tell you what happened; far fewer can put it back. The teams agents get trusted with will be the ones where a wrong action costs a rollback instead of a weekend. A product that can’t undo an agent’s mistake is one no sensible person lets an agent near for anything that matters. Action-level observability isn’t a feature you build for your own debugging; it’s the price of being let into the loop at all.

Permissions that assume delegated work

Almost every permission system in production today encodes one idea: a user is a person, and a person either can or can’t do a thing. Roles, scopes, access levels, all of it built around a human identity making a human decision in real time. Agentic work breaks that model, and not by needing more access. It needs access with more shape to it.

A founder building for this should be asking one precise question: what can an agent safely do on behalf of a user, a team, a whole company? The honest answer sits between “everything its owner can” and “nothing,” and the product has to give that middle ground a vocabulary.

Some of it is scope: an agent gets exactly the slice of authority its task needs and none of the rest. Some of it is time. A grant for Tuesday’s migration should expire Wednesday morning, not sit live for a year because nobody revoked it. Thresholds matter too: let the agent move forty dollars on its own, but make it stop and find a human for forty thousand. Give it a dry-run mode so it can show what it would do and wait for a yes. And put the rules in the system itself, enforced on every call, instead of in some operator’s head where they only get enforced when that operator happens to be watching.

None of this is exotic. A finance team already understands spending limits and approval chains; an ops team already understands temporary access. The work is taking those instincts, the ones we apply to people through process and trust, and turning them into mechanisms the product enforces on a non-human actor that won’t get tired, won’t feel awkward exceeding its mandate, and will do exactly what its permissions allow, ten thousand times, at three in the morning.

Data quality is now product surface

There’s a comfortable idea that data quality is an internal problem. Stale records, ambiguous fields, three duplicate copies of the same customer, an edge case nobody wrote down: messy, embarrassing, but contained. A human operator routes around all of it without thinking. They know the “status” field went unused after 2023, that the real email is in the second record and not the first, that when the amount is zero it actually means “pending” because of a bug from years ago that hardened into a convention.

An agent knows none of that, and it has no instinct to be suspicious. It reads your data as true and acts. Hand it the stale record and it emails someone who left the company a year ago. Give it two fields that both look like an email and it picks the wrong one. And when it meets that zero-means-pending charge, it tells the customer they owe nothing. Where your ops team quietly routes around the mess, the agent runs straight through it and multiplies it across every record you have.

So data quality has moved. It used to be something your operations team absorbed quietly behind the interface. Now it’s surface area, as much a part of what you ship as any endpoint. The duplicate entities, the fields whose meaning drifted, the edge cases that live only in tribal knowledge: every one of them is a place an agent can go wrong on a user’s behalf. An agent is only as good as the context it can trust, and your product is that context. Cleaning up the records, making the names mean one thing, writing down the conventions that only live in someone’s head: that used to be housekeeping for a slow afternoon. Now it decides whether an agent comes to rely on your product or quietly learns to route around it.

What you’re actually building

These four pieces are the same piece seen from four sides. An honest API, traces you can read and reverse, permissions built for delegation, data clean enough to act on: each one answers whether a thing that reads instead of looks can run your software without wrecking it or getting wrecked by it.

Identity already got the agent through your door; that part’s mostly solved. What it finds on the other side is still up to you. Build it so a non-human operator can see the structure, undo its own mistakes, hold exactly the authority you handed it, and trust the data in front of it, and agents will get sent to you to do real work. Skip it, and you become one more tool agents quietly learn to avoid, and you won’t even get a bug report to tell you why; the traffic just thins out and then it’s gone.