The agent cannot ask questions

Part 1 promised a post about writing user stories an agent can build. This is that post and an argument that the (user) story, as most of us learned it, was built for a problem agents don't have.

Part 1 ended on a claim I owe you: once agents do the building, writing the work down is the whole game. This is that part. It starts with an argument that will irritate a good part of my own profession.

Most of how we learned to describe software work. The user story, the sprint, refinement, planning poker was built to solve a problem you stop having the moment an agent does the building.

The user story was never meant to be a full specification. The original idea was a card, a conversation, a confirmation: the card is a reminder to talk, not the talk itself. You finish it later, in refinement, at the standup, at someone's desk. Most of Scrum exists to schedule those conversations between people.

Now hand the card to an agent.

It can't have the conversation. A junior who doesn't follow your ticket asks. An agent doesn't. It takes the most likely reading, builds forty minutes on top of it, and hands the result back without a flicker of doubt. Mine write down the guesses they made in a section called ASSUMPTIONS, and reading that section is a humbling experience.

Every assumption in there is a sentence I didn't writ

So the ASSUMPTIONS block isn't really a feature of the agent. It's a defect report on my spec. And it changes the question from "which process?" to "how complete is this before anyone starts?" That is spec-first rather than conversation-first. Roughly the opposite of where the last twenty years pointed.

What survives

Not everything with an agile label goes in the bin. Kanban does fine. My pipeline is basically a Kanban board with the ceremony scraped off: a queue, a pull signal (I drag a label onto an issue), one job at a time, done when it merges. What doesn't survive is the machinery for coordinating people: sprints, story points, velocity. There is no team to coordinate. There is one builder that takes one card at a time and never gets bored.

But flow was never the hard part. Nothing in Scrum or Kanban tells you how to write a card an agent can actually build. That is the gap spec-driven development is trying to fill. I read through OpenSpec and GitHub's Spec Kit while working this out. Both keep the spec as a living, versioned document with a lifecycle of its own, rather than a ticket you throw away after the sprint. Worth borrowing the structure from. Not worth adopting a second system to maintain next to the one you already have.

And it isn't only the spec-driven crowd arriving here. Anthropic's own advice on running agents for long stretches says the thing I learned the slow way: attach a verification step to every requirement, or the agent decides for itself what "done" looks like. The most basic guidance from both OpenAI and Anthropic for getting anything decent out of a model (be specific, name the limits, give it the context) reads, in the end, like a description of a good spec. None of them tell you to build what I built. But when people working separately keep landing in the same place, it's usually the place that matters, not the map that got them there.

None of which answers the practical question: what do you actually write down? Five things, each learned by getting it wrong.

1. Write criteria you can check

"Login should work properly" is a wish, and an agent can't build or verify a wish. "A user can register, log in, and reach the dashboard, checked by a browser test that runs those steps" is something it can both do and prove. The check is part of the requirement. Leave it out and the agent decides what "working" means and it decides generously.

2. Never write "latest"

My favourite mistake. An issue asked for the latest version of the framework, and the agent scaffolded last year's release with complete confidence. That is not a bug: a model answers "latest" from its training data, and its training data is always the past. Writing the version number instead doesn't help either. The issue ages the same way. Don't write the fact; write where the truth lives. In this case: "use the current stable major, confirm it on the package registry first." That rule lives in the project's instructions now, and the mistake stopped.

Don't write the fact; write where the truth lives

3. Say what you don't want

One of my early issues had a line that looked strange on paper: "don't set up Teams," a feature the starter kit offered for free. It earned its place. Left alone, an agent builds more, because more looks like better coverage of a vague brief. Non-goals are cheap, and they help twice: the agent leaves out what you didn't want, and at review time a missing feature reads as a decision rather than a miss.

4. Point at context instead of repeating it

Every fact you copy into an issue is a fact that can go stale. Mine don't restate architecture; they link to it. There is one instructions file the agent always reads, holding the conventions and the house rules. The issue says what; the standing documents say how. A review lesson worth keeping goes into that file, not into every future ticket.

5. Size it for the review, not the build

Building takes minutes now, so the old reason for small slices is gone. Here is the new one: one issue, one pull request, something I can judge over a coffee. If the review takes longer than the build did, the issue was too big. Order lives in the links between issues, not in prose, which, handily, means the dependency graph already shows what could run in parallel, the day I trust it to.

Isn't this just waterfall?

Fair question, and the answer is no, for two reasons. The iteration didn't disappear; it moved out of the standup and into the write-build-review loop, where a rework comment gets me a new version in minutes. And the batch is tiny: one issue at a time. Small batches with a fast loop is closer to the spirit of agile than a fortnightly ceremony ever was. It just drops the ritual.

What this is really about

Here is the honest bit: none of those five rules is new. Checkable criteria, non-goals, one source of truth, small slices. That is what careful specification always looked like. We got away without it because people filled the gaps. They asked, they guessed well, they walked over to your desk.

An agent does none of that. So it holds up a mirror, every time, in writing.

My specifications have never had a reviewer this literal.

The loop I've settled into: write the issue, let it build, and when the result surprises me, don't just fix the code, but work out which sentence was missing from this issue, or from the standing rules. The first becomes a rework comment. The second becomes a permanent rule. The backlog gets easier to build every week, and not because the agents got smarter. The specifications did.

If there is one thing I'd hand a team staring at all this, it is that. The scarce skill isn't prompting, and it isn't picking the right model. It is saying what you want clearly enough that something which can't ask you to explain still gets it right.

Which was always the job.

What's next

Later in the series: the full setup for anyone who wants to build it, including why the agents moved off the cloud and onto the desk next to me, and the checks that keep them honest. Then the numbers like the first run of pull requests, unedited, including the week they handed me garbage and the system caught it before I did.

Part 1, in case you missed it: how the pipeline works and what broke on day one. If you're wondering what agent-ready specs would look like for your team, my inbox is open.