The User Who Left the Room

It is late, and an engineer is turning a goal into an agent. The ticket she picked up reads the way tickets have read for twenty years. As a support agent, I want to see the customer’s complaint history so I can resolve the complaint fairly. She has shipped a hundred features from stories like it, and she starts this one the same way.

Then she notices what is missing. She is not building a screen for a support agent to read. She is building the thing that resolves the complaint, start to finish, with no support agent in the chair. So she opens the model and begins writing the parts the story never mentioned. What the refund ceiling is. Which records the agent may change and which it may only read. When a payment needs a human signature. What has to be kept as proof once the case is closed. None of it was in the story, because the story described a person who would have known all of it without being told. By the time she ships, she has made a dozen decisions that were never hers to make. She has not written code. She has written policy.

That scene is happening across your industry right now, and it is the reason a book about product management had to be rewritten. For twenty years a user story worked because a person stood at the other end of it. The story could stay silent on the refund ceiling and the authorization rule and the evidence trail, because a trained human was going to read the screen and supply all of that at the moment it mattered. The specification was never complete. It was completed at runtime, for free, by the person in the chair. Take that person out and the judgment does not leave with them. It becomes context nobody wrote down, sitting in the one place it cannot stay: unstated, in a system that acts on its own.

Writing that context down, before the agent runs, is the job this book is about. It is product work, and it is the part that does not survive contact with an agent unless someone owns it deliberately.

Take the one line the engineer started from. As a support agent, I want to see the customer’s complaint history so I can resolve the complaint fairly. Written for a person, it needs nothing more. The support agent already knows that store credit under fifty dollars is hers to grant, that a refund over two hundred goes to a supervisor, that a customer who has charged back twice gets escalated rather than refunded, and that the note explaining the decision has to be saved for the auditors.

None of that knowledge was free, and none of it was in the story. She was interviewed for her judgment, her background, and her training before she was hired. She went through company onboarding and then support-agent training. She was handed the relevant policies, asked to read them, and made to sign that she had. Then she worked beside a senior agent as a trainee until someone decided she could be trusted on her own. The user story could stay silent on the refund ceiling because the company had spent months and a hiring pipeline making sure the person who would read it already knew the ceiling by heart. Written for an agent, all of it has to be on the page before the agent runs: the ceiling, the escalation trigger, the chargeback rule, the record that has to survive the case. The agent sat no interview. It completed no onboarding. It signed no policy and served no supervised probation. The story did not get more complicated. The reader changed, and the reader had been carrying half the specification.

Notice what the story was specifying all along. When its target was a person, it described a tool: a way to make someone who already knew the job faster at it. Take the person out of the room and the tool is beside the point. What you have to build now is the thing the story never described, because it never had to. Not a sharper instrument for a competent human. The competent actor itself.

Medicine settled a version of this a long time ago, and it is worth borrowing because the stakes there never allowed the shortcut. An attending physician cannot stand at every bedside at every hour. So the judgment is not handed to the night nurse as a description of what the attending would do if she were there. It is handed over as an order set and a protocol: the thresholds, the doses, the vital sign that means stop and call. The nurse acts inside a boundary the attending drew in advance, because the attending holds the authority and the nurse, at three in the morning, needs the decision already made rather than improvised. An agent needs exactly that, and it needs the people who hold the judgment to be the ones who write it down. What it usually gets instead is a story that still describes the daytime, when someone knowledgeable was always in the room, handed to the last engineer to touch it.

The deliverable that did not change

Look at what has moved on the team, and what has not.

Engineering has already changed its unit of work. A strong team building an agent does not hand over a sequence of screens to implement; it works from a statement of intent and the limits around it, an outcome and the boundaries on how the agent may reach it. Watch a capable engineer build an agent and you will see her writing conditions and constraints, not procedures. The unit of work moved from the steps to the goal and the guardrails.

Design is moving too. The designer’s object is no longer only the screen the user reads on the way to a decision. It is the moment a human is pulled back into the loop to approve or override, and what that human sees when they arrive: enough to make a real judgment, or a summary polished enough to rubber-stamp. When the user is doing the task, you design the task. When the agent is doing the task and a person supervises it, you design the interruption. Those are different crafts.

The product manager’s deliverable, in most organizations, has not moved at all. It is still a user story and a set of screens describing what a person would do, in a product where a person increasingly does not do it. And because the story reaches the engineer carrying none of the conditions the running system needs, the engineer supplies them, alone, in a prompt, at the one altitude in the whole organization least equipped to own them. She is not the person who has carried the refund rules in her head for fifteen years. She is not the one accountable when a payment goes out that should not have. She is the one holding the ticket at the moment the blank had to be filled.

A product manager’s deliverable exists to make the next person’s work possible. That is what it is for. When it still describes a user who will not be in the room, it makes the designer guess at the approval moment and the engineer guess at the policy, and it quietly reassigns decisions that belong to the business onto whoever is downstream when the deadline hits. The jobs of the people you hand work to have changed. If your deliverable has not changed with them, it is not neutral. It is a gap with their names in it.

The harder version

The comfortable reading of this is that agents introduced a new gap, and the team needs a new document to close it. That is not quite what happened, and the more uncomfortable version is the one worth holding.

The gap was always there. The user story always left the judgment out and counted on a present human to fill it at the moment of use. You never had to notice, because the human was already in the chair and cost you nothing extra. The agent did not create the missing policy. It withdrew the free labor that had been hiding it for twenty years. What looks like a new requirement is an old debt, called in the moment the person stepped out of the loop.

Someone will object that engineers have always filled gaps in a spec, and that is true, and for years it did little harm. The gap used to be a UI state nobody described or an edge case nobody thought through, and an engineer closing it on her own cost you a bug ticket and a follow-up. The gap now is who may authorize a payment, which records may be altered, and what proof shows the case was handled within the rules. The blank did not get wider. Its cost did. An underspecified deliverable used to produce a defect you could patch. Now it produces a consequence someone absorbs, and the someone is rarely the engineer who filled the blank.

What this book asks you to write down

The rest of this book is, in one sense, a long answer to a single question: what does the departed user’s judgment look like once you have to write it instead of assume it. It has parts, and the parts have owners. What counts as the goal being reached, and what the agent may decide on its own to get there, is yours. The moment a human is brought back in, and what they see when they are, belongs with design. What a given action is actually allowed to require, the real authorization rule and the evidence that has to survive the case, belongs with the person who holds that knowledge and is accountable for it, and they hold a veto over anyone who would guess on their behalf. Which of those boundaries is a suggestion the agent can be argued out of and which is a wall it cannot cross is an architecture decision. How the whole division of labor is staffed across a real team is its own subject, and not this book’s focus. This book’s focus is the part that starts it: the judgment itself, named and written, before anyone builds.

You do not need new ceremonies to do this. You need to stop shipping a deliverable built for a user who has already left the room. The agent will act on whatever judgment it is given. If you do not write that judgment down, it will run on the version an engineer typed at midnight, under a deadline, from a story that still assumed a person would be reading the screen. And whatever the engineer leaves unwritten, the agent does not leave unfilled. It invents the missing policy on its own, with the same confidence it brings to the parts you got right.

Before you can write it well, though, you have to be able to say what the system actually does, and to catch it when it is confidently wrong. That fluency is not optional and it is not the engineers’ alone. It is the floor the rest of this book stands on, and it is where we start.

---