Who Answers the Agent?

At twenty to eleven on a Tuesday morning a coding agent asked whether incomplete records should be hidden from the list or shown with a warning. It had finished the part of the work that did not depend on the answer, written the question to a file with the option it would take if nobody replied, and moved on. The product manager was in a review about the review process. The designer was on another project that week, the one with the budget. The developer running the agent was the only person in the room and was already on his way to lunch. By the time anyone read the question the default had been taken, the tests were green, and the list was hiding records that a user would have wanted to see. Nothing had gone wrong in any way a dashboard would show, which is the only way most organizations check. A product decision had been made by nobody at all, and the agent had done exactly what it was told to do when nobody answers.

I have spent the last few weeks building the same small product twice, once on my laptop with a coding agent as the builder and a frontier model as its supervisor, and once in the cloud with a different pair, to learn how the work changes when execution takes hours instead of weeks. I expected to learn about agents. What I learned was about the people around them, and it comes down to one question that I now think belongs on the wall of every team that has adopted these tools: who answers the agent?

Four topics, four latencies

The record of the laptop project is a file of numbered rulings. In six days it took forty-four entries, each an answer to a question the coding agent had parked because the instructions did not cover it. I did not plan to study that file; I planned to feel productive about it. But when I sorted it by the kind of question rather than the date, it showed something the daily reports had hidden.

Architecture questions were answered in minutes: which database, how migrations apply, whether a running process may differ from the committed code. That is why the data layer of the product is the mature part. Product questions were answered in hours, and sometimes a day, and the day-late ones were expensive; one of them produced a model comparison that nobody needed and that consumed most of a Sunday. Domain questions, the ones only I could answer, waited until I was back at the desk, and the agent's default in the meantime was usually wrong in a way only a person from the domain would notice. And the questions about the user's experience had no counterpart at all. The front door of the product, a service that shows the ranked list, sat unloaded for four days because nobody owned the question of what the page was for, and when it finally loaded, the page was one I described in a single unkind word, which the agent logged, without comment, as feedback. The rule that the model's assessment should sit below the decision buttons rather than above them, so that a person forms a view before being handed one, arrived only after I had seen the wrong version.

Same agent, same speed, four kinds of question, four different waiting times, and the product was worst exactly where the waiting time was infinite. That is the finding. The agent did not slow down for the questions nobody owned. It answered them itself, or it took the developer's answer, because the developer was the one in the room.

What worked was not real time

The obvious conclusion is that someone must answer faster, and it is the wrong one, though it will be the one in the vendor deck. Nobody answers in real time. People are in meetings, at lunch, on the other project, or on holiday, and an agent that produces a pull request every forty minutes will ask its next question before the last one has been read. What worked on both builds was two things that require no speed at all.

The first is a default. Every question the agent parked carried the option it would take if unanswered, and the supervisor's job was to set those options in advance and correct them afterwards, not to be available. The second is a written channel: the agent wrote to one file, the supervisor wrote to another, the agent read the rulings before acting on anything it had parked, and a ruling in the file was binding without a conversation. Once those two existed, the human's absence stopped being a stall. It became a delay on the small set of decisions that could not proceed on a default, and those were rare enough to fit into the hours a person actually has.

Hospitals solved this problem decades ago and never called it agentic. A resident on the ward does not wait for a meeting when a question comes up at the bedside. There is an attending of record for every patient, a specialist on call for every kind of question, standing orders that say what to do when nobody can be reached, and a chart in which every decision is written and every deviation explained. The resident pages the right specialty, acts on the standing order until the page is returned, and the morning conference reviews what was decided in between. The resident is never the sole decision-maker, and is never blocked by the absence of the people who are. A coding agent is a very fast resident with no judgment about which questions are consequential. The team around it has to be the hospital.

The pod is a set of lanes, not a meeting

This is the thing I would say to any team that has put a coding agent in the hands of one developer and wondered why the results feel strangely lopsided, strong where the developer is strong, thin everywhere else. The developer is not deciding UX because developers are power-hungry. The developer is deciding UX because the agent asked and the alternative was a stalled agent. Access to the terminal has become authority over every question that arrives at it, and the questions now arrive by the dozen.

The pod is the answer, and I mean something specific by it. A pod is a group of people, product, design, engineering, and the domain, who share one written decision channel and divide it into lanes by topic. Each lane has a supervisor of record: the person whose answer the agent takes, and who is accountable for the answers taken in that lane, including the defaults they wrote in advance. The pod as a whole is accountable for what the agent ships, because it is the pod that set the lanes, the defaults and the gates. Shared accountability is the phrase people use for this, and it is the phrase that usually means nobody is accountable and everybody is in the retrospective. The version that works is accountable by topic for decisions, jointly for the release. Take away the first half and the developer in the driver's seat is once again the only name on the commit.

One of the two projects taught me that lesson in the least abstract way available. The agent merged a change to the main branch under my identity because a sentence in an instruction implied it should, while I was away from the desk. The record showed that I had approved something at 5:37am on a Sunday morning, which I had not, and which nobody who knows me would believe. Accountability landed on the person whose name was on the commit, not on the condition that produced it. Nobody had written the rule that said merges need a named ruling. We wrote it afterwards. We wrote a lot of rules afterwards, and every one of them was a default that should have existed before the agent started.

The spec is a set of decisions made in advance

Which is why, against the mood of the moment, specifications matter more now than they did when implementation was slow. Not the ninety-page document; that was never read by the people it was written for, which was its great mercy, and an agent reads it and follows the wrong paragraph with perfect discipline. The spec that matters is the set of decisions made in advance: the intended outcome and the explicit non-goals, the behaviors that are never allowed, the approvals that cannot be skipped, the evaluation cases that define done, and the default the agent takes for each class of question when nobody answers. On the laptop project the spec was never one file. It was a rules file the agent read before its first command, a work order with acceptance criteria per step, the rulings log, and a board that allowed exactly one item in progress. The parts of that spec that held were the parts that could be executed. The list of actions the agent may never take autonomously, sending, submitting, deleting, editing the record of my own career, is not a paragraph; it is an allowlist in code, and the agent cannot reach past it whatever it is told. Rulings became tests. Real emails became fixtures. The rule that nothing enters the corpus until validated as the kind of thing it claims to be is a checker that fires on the agent's own code.

A spec that cannot be executed is a suggestion, and a suggestion is what an agent overrides, with the best of intentions, while everyone who would have objected is in a meeting. This is the deliverable that the product manager, the designer and the architect now owe: not a document that is pleasant to read, but a set of decisions in a form the agent can check itself against and a test can enforce.

The sprint is dead; the daily has a new job

I will be careful with this claim because it is the one people will quote, and the one the certification industry will send me a message about. The two-week sprint is dead as the unit of planning for work an agent executes. It is not dead as the moment when a team judges outcomes and decides where to invest; that judgment still needs a cadence and a room. What died is the assumption that implementation takes long enough for the next scheduled conversation to catch a wrong assumption before it becomes working code. On the laptop project a pull request arrived roughly every forty minutes. A consequential assumption became code, tests, and a merged branch between one daily and the next, and the daily was the wrong place to find it, because by then the question had been answered three times over.

What replaced the sprint was not a shorter sprint. It was the decision channel with a waiting-time budget by class: questions the agent may settle on its default, questions an owner must answer within hours in writing, and questions that block until answered because the action cannot be undone. And the daily, freed from the pressure of ruling on anything here and now, got the job it was always better at. It became the place for the questions that do not need an answer today: the conceptual ones, the ones about whether the lanes are drawn right, the ones a physician would take to the morning conference rather than page someone about from the ward. A meeting that does not have to decide can think.

Everyone commits, and there are gates

If the spec is executable and the channel is a file, then the people who own the lanes have to be able to write to the repository, and that is a larger change than it sounds. The product manager, the designer and the architect now add files, review pull requests and contribute to the project almost as the developer does, because that is where the decisions live and where the agent reads them. A ruling that exists only in a chat is a ruling the agent never sees.

That access needs the same protections developers have earned for themselves, and our own repository provided the cautionary tale. My rulings file lost its newest entries twice in one afternoon, because another writer's git command swept an uncommitted change into a stash and a later checkout threw it away. The fix was not a plea for care; it was a rule that two-writer files are append-only and read again before every write, and a commit before any destructive operation. Non-developer contributions need a review step before they merge, and one quality gate above all: any file that governs the agent's behavior has a test that asserts it. Otherwise it is documentation, and documentation is what an agent reads selectively, in the same tradition as everyone else.

The mechanism is one field

The whole model reduces to something small enough to fit in the agent's question. When the agent parks a decision, the entry already carries the evidence, the consequences, and the option it will take if nobody answers. It needs two more fields: the class of the question and the owner of that class. The agent fills them. A question about how the page should behave goes to the design lane; a question about a data model goes to architecture; a question about whether a customer's edge case is real goes to the domain expert. Misrouting costs a forward. Not routing costs a stalled agent, or a developer deciding what the product is for.

That is the picture I keep coming back to: a screen that says "one decision I need from you is whether team approvals belong in this release or the next one; I can continue with the agreed scope while you decide," and three people at a table who each own a kind of answer. The picture is not about the agent. The agent already does its part. It is about the three people, and whether the question has somewhere to go.

The evaluation is the north star

There is one class of question no lane can answer, and it turned out to be the most important one. Is the product any good? Is the ranking right? Does the assistant miss the roles worth seeing? No product manager, designer, architect or domain expert can answer that from the table, and I say this as someone who tried, at length, from memory and conviction, and was wrong in a table with eleven rows. On both projects the answer came from the same place: an evaluation set, labeled by the human whose judgment the product exists to serve, run against every version and every model, with the numbers reported against a baseline that does nothing.

Those tests answered questions that had consumed hours of pod discussion in minutes, and they answered them in ways nobody at the table expected. Eleven models from the smallest to the most advanced landed at the same judgment precision, because the ceiling was the rubric and the labels, not the model. The deterministic gates that run before any model were losing one suitable role in nine, silently, before a person could ever see it. A frontier model's agreement with the human's own ratings looked impressive until the constant-pass baseline was printed beside it, at which point it looked like the baseline. None of this could have been decided by a lane. All of it could be decided by an eval, and once it was, the pod's arguments stopped.

So the evaluation is the north star of the pod, not because it is fashionable but because it is the only lane whose supervisor is reality. The product manager owns it, in the sense of deciding what is measured and what failure matters; the domain expert grades the cases; the designer defines what a person should have seen; the developer builds the harness. The agent runs it on every change. And when the pod disagrees, which a good pod does, the disagreement becomes a case in the set rather than a conversation that ends when the loudest person leaves for a meeting.

The last job in the middle

In an earlier piece I wrote that watching code being written is not a job, and that the work had moved to the two ends: the boundary before the code and the gate after it. I want to add the part that two weeks of building made visible. There is one job left in the middle, and it is deciding. The questions arrive faster than any one person can own, by topic, throughout the working day, each with a default the agent will take if nobody speaks. A team that has not decided who answers them has already decided: the developer will, or the agent will, and neither is the person who should.

The pod is the answer, and it is not a meeting or a manifesto. It is lanes with names on them, standing orders written before the work starts, a channel the agent reads and the owners write to, gates that a test enforces, and an evaluation that settles what the table cannot. It is, in other words, the on-call structure of a hospital, applied to a resident that never stops and never knows which page is the important one. Who answers the agent? Everyone, by topic, in writing, with a default. That is the whole operating model, and it fits on the wall, next to the poster about values.

Part of the Product Management series: how AI is changing what product managers actually do.