Your Agents Are Making Product Decisions. Who Owns Them?

Recently, on a client engagement, I had several agents working at the same time on a customer-facing app. One was working through the requirements, one was on interaction design, and another was writing code. They ran for a few hours, and I spent most of that time reviewing what came back, redirecting the agents that needed it, and talking with the client.

Some of it was exactly what I'd asked for. Some of it was the agent finding a gap I'd left, making a reasonable guess, and moving on as if the guess had been settled. Both versions looked equally finished, and the only way to tell them apart was to know the product well enough to notice which parts nobody had actually decided.

A Guess Becomes a Product Decision at Review

When an agent encounters a gap and has enough latitude to keep moving, it will often resolve the ambiguity itself. How often depends a lot on the instructions and the tooling around it, but giving an agent enough latitude to keep moving is part of the value, so some of this is going to happen on any team.

Say the spec doesn't cover what happens when a search returns no results. The agent might write an empty state with its own wording and a suggestion or two, then move on. Each of those is a product decision. None of them went through the person who owns the product, and nothing in the output says they were guesses.

Then the work reaches review. Whoever is reviewing it sees that it works and approves it, and at that point the guess has become the product. The decision was made by the reviewer, probably without anyone thinking of it as a decision at all.

People building software have always made small product calls along the way. What's different is the volume. An agent can make dozens of those calls in the time a person would have made a few, and it presents every one of them with the same confidence. Technically correct output is the easy part to check. The harder check is whether someone with enough product context looked at the choices the agent made on its own.

It Happens in Every Role on the Team

It's tempting to treat directing agents as an engineering topic. On a team working this way, everyone directs them, including designers, BAs, engineers and the delivery lead who's responsible for the product.

Nobody's title changed, though. Each of those people now spends part of the day handing off work, reviewing what comes back, redirecting it and deciding when it's ready, which is a fair description of managing. It's management of work rather than people, and it usually arrives without the training or the decision rights that come with a management job.

That's where product decisions leak. A designer reviewing an agent's interaction flow may accept a data-handling choice they'd never have been asked to make before. An engineer reviewing generated code may accept a UX choice buried inside it. Each approval is reasonable on its own. Added up, the product can end up reflecting whoever happened to review each piece.

The Skill Is Telling Execution From Invention

The most useful thing a reviewer can learn is to ask one question of every piece of agent output: did the agent execute something we decided, or did it make the decision on its own?

That sounds simple, and in practice it's hard. Invention often arrives looking just as finished as execution.

Telling the two apart is one part of a broader skill most teams seem to assume people will pick up by doing it. Some will. It's specific enough, though, that it probably deserves to be taught on purpose, and its parts are easy to name.

A habit that helps with the third row is asking the agent to list its assumptions alongside its output, so at least some of the inventions show up as inventions. It won't catch everything, since agents don't always know when they've guessed. It does turn some invisible decisions into visible ones, and visible ones can go to the person who should make them.

Every Product Gap Needs a Named Owner

That only works if the assumptions go somewhere. Product gaps need a named decision owner, and that person has to be known before review starts. Architecture, security and accessibility keep their own owners, and an agent's guess in one of those areas goes to whoever already makes those calls.

Who owns the product calls depends on the team. It might be a product owner, a product-focused delivery lead, a designer or a domain lead. What works for me is settling it before the agents start, so nobody has to work it out in the middle of a review.

That changes what review is for. The reviewer's job becomes spotting the agent's inventions and sending them to whoever owns that kind of decision. Approving the work and approving the decisions inside it become two separate steps, even when they happen in the same afternoon. On a small team the reviewer and the decision owner might be the same person for much of the work, and that's fine, as long as everyone knows it.

Product Context Still Belongs to the Team

Agents can oversee other agents, and sometimes that works well. A second agent can check the first one's output against the spec. Checking against a spec only catches what the spec covered, though, and the gaps are where the inventions happened in the first place.

Agents can also take part in client conversations now. They can help prepare for them, capture what was said, and pull themes out afterward. What they don't hold is the accountable relationship with the client, or the understanding of the problem and the unmet opportunity that builds up over weeks of those conversations. That stays with the team, and it's the thing that makes review work.

The reviewer who knows why the client asked for something is the one most likely to notice when an agent made a choice the client never would have. Whoever owns that decision is the one who says whether it stays. If nobody owns the decision explicitly, it gets made implicitly, usually by whoever happens to review the output.