The Unit of Design Is the Conversation, Not the Prompt

Most teams design a single call and then discover, in production, that they built a conversation. The request arrives underspecified, the model guesses, the guess is wrong in a way nobody notices until the output is downstream, and the fix is a second call that should have been the first. The mistake is not in the prompt. It is in treating the number of exchanges as an implementation detail rather than as the first architectural choice, made before a word of the prompt is written.

A turn boundary is a real boundary. It is where a system stops, looks at what it has produced, and decides what to do next with information it did not have when the work began. That is the same thing a checkpoint does, or a transaction commit, or a stage gate in a pipeline. Placing one costs latency, an obligation to carry state forward, and a dependency on whoever answers. Placing none costs every assumption you were forced to make up front. Deciding where those boundaries go is the design problem, and prompt quality does not touch it.

What a turn boundary actually buys

A single call commits to every assumption at once. You supply the inputs, the model resolves the ambiguities silently in the course of generating, and you pay for the entire output before you learn which resolutions it chose. If the interpretation was wrong at token fifty, everything after it is wrong too, and the wrongness is coherent, which is worse than incoherent, because it survives a skim.

A turn boundary buys the option to spend less before knowing more. Between two exchanges, a system can inspect an intermediate result, get a decision from a principal who holds authority the model does not, or discover that the request means something other than what it first appeared to mean. Everything downstream of the boundary is then conditioned on that information rather than on a guess. The value of the boundary is proportional to how much the work diverges based on what you learn there. That is the whole calculation, and it is worth stating plainly: a turn is worth its cost when the answer you get changes what happens next. If both answers lead to the same work, the boundary bought nothing and you paid for it in latency anyway.

This reframes four situations that otherwise look unrelated. When an action is irreversible and someone must authorize it, a boundary is where authority enters, because a single call has no place to put an approval that means anything. When the second step’s input is the first step’s output, a boundary is where the system reads that output instead of hoping the model held it. When a request is ambiguous in a way that materially changes the output, a boundary buys the disambiguation before the cost is sunk. And when a task is too large for one generation to hold with equal care throughout, boundaries are how it gets divided into pieces that fit. Four different-looking triggers, one underlying property: at each of them, information arrives that changes the work.

One of those triggers does not obey the calculation. When an action cannot be taken back and being wrong carries real cost, the boundary is mandatory whatever the divergence looks like, because the price of a wrong reading is no longer bounded by the price of redoing the work. That is a property of the action, so it can be settled at design time and enforced in the system rather than left to the model’s read of the moment. Everywhere else, the divergence test governs.

Turns are not free

The reason this is a design decision and not a default is that every boundary you add has a price, and the prices are not small in a served system.

Latency is the obvious one, and it is worse than it looks, because a round trip is not just a model call. It is a model call plus the time for a second party to respond, and second parties are slow. Each boundary you add pays that second cost again. A three-turn clarification sequence in an interactive product is a few seconds of model time and possibly minutes of human time. In a system with a response budget, that arithmetic decides the architecture on its own.

The second price is a state obligation. Each boundary is a place where a run can be interrupted, and a system that cannot resume from the boundary has not built a turn, it has built a failure point. In a long-lived interactive session this obligation is invisible because the session holds everything. Move the same design behind an API where the caller may return an hour later, or not at all, and the boundary suddenly requires durable state, an identifier for the pending interaction, an expiry policy, and a decision about what happens to the work in flight when nobody comes back. Designs that were free in a single session become infrastructure.

The third price is the one teams discover late: a boundary is a dependency on someone answering. An unattended run has nobody on the other side. A clarification turn in a batch pipeline is not a clarification turn, it is a hang, and it will present as a timeout somewhere unhelpful. So a boundary that asks a question is only designed once the no-answer path is designed with it. Choosing that path is the second half of placing the boundary, and a system that has skipped it has placed a hazard instead.

The fourth price is charged to the person on the other side. A boundary spends someone’s attention. Ask them something they reasonably expect the system to already know, and you have not just wasted a round trip, you have told them the system is not paying attention, which is a harder thing to recover from than a wrong answer.

The one question worth asking

Given that a question costs a round trip, the discipline follows directly: ask about the ambiguity whose resolution most changes the work, and ask about nothing else.

The failure this rules out is enumeration. When a system answers an underspecified request with four open questions, it has not reasoned about which ambiguity matters. It has listed every unknown and pushed the cost of resolving all of them onto the requester, who now has to do the specification work the system was supposed to do. Each additional question dilutes the one that mattered, and the answers to the other three usually turn out not to have changed anything. This is not a matter of conversational manners. It is that only one of those four unknowns had real divergence behind it, and the system failed to identify which.

What makes such an exchange work is mostly the part that is not the question. A system that asks without stating the reading it has already formed is withholding the thing most likely to be wrong, and a requester cannot correct a reading they never saw. State the interpretation and the exchange becomes a check on it, which is a cheaper thing to answer than a demand for information. The question itself should then be narrow enough to answer in a phrase, because one broad enough to invite a paragraph will get a paragraph without the specific fact in it. And the exchange should be bounded: a requester who knows what their answer unblocks is answering a question, while one who does not is being drawn into an exchange of unknown depth.

The negative case is just as important. If a question cannot be traced to a divergence in what the system will do, it should not be asked. There is a common pattern of asking for confirmation of something already unambiguous, which reads as diligence and functions as a tax. A system that asks whether you are sure, when there is only one thing you could have meant, is charging a round trip for theater.

Every turn should narrow the next

Once a task spans several exchanges, the ordering is not a matter of taste. It falls out of the inputs: no step can run before the output it consumes exists. Order by that dependency and the sequence designs itself. Put two goals in one exchange and you lose the ability to tell which one failed, which is the entire reason the work was split in the first place.

The subtler rule is about what carries forward. A later exchange that relies on the model recalling something from an earlier one is performing an implicit read against a store with no guarantees. The history is there, and the model may attend to the right part of it, and often does, which is precisely what makes this failure so patient. It works in testing, where the histories are short, and it degrades where the histories are long and the relevant fact is far away and competing with everything else that has accumulated since. The fix is not to hope harder. It is to pass the dependency in rather than reach for it: whatever the step operates on, and whatever constrains it, should arrive in the message that asks for the work. What was an implicit dependency on attention becomes an explicit argument to the call.

That is more than a reliability trick. Once every exchange states its own inputs, an exchange becomes reconstructible. It can be retried without replaying the whole history, evaluated on its own, and reasoned about in isolation when it goes wrong. A sequence whose steps each depend on ambient recall can only ever be debugged as a whole. A sequence whose steps declare their inputs can be debugged one step at a time, which is the only kind of debugging that scales.

An unverified change is not progress

The most reliable multi-exchange pattern is also the least glamorous: produce something, evaluate it against a specific criterion, revise the specific thing that failed, repeat. It works for a reason worth naming, because the reason tells you when it stops working.

A large rewrite cannot be verified. When a whole output changes at once, you have no way to isolate whether it improved except to re-read all of it and re-form a judgment, and that judgment is subject to the same fallibility that produced the first draft. A small, targeted change can be verified, because there is a specific claim to check: the summary now names the decision it was missing, or it does not. Refinement is not superior because iteration is virtuous. It is superior because it produces changes small enough to be checked, and a change nobody can check is not an improvement, only a difference.

This is also why unspecific feedback fails so reliably. An instruction to improve something gives the model no criterion, so it applies its own, which often means rewriting parts that were already correct. The output changes and does not improve. Worse, targeted feedback without a preservation constraint has the same failure in miniature: fix the third paragraph and the model may helpfully rework the first, which was fine. Naming what must not change is as load-bearing as naming what must, and it is the half that gets left out.

The boundary on refinement is real. Each cycle has a cost and a diminishing return, and there is a point past which cycles trade one flaw for another rather than converging. A refinement loop needs a criterion that says when it is done, and that criterion has to come from outside the loop, because a process evaluating its own output will always find something else to adjust.

When one call is the right answer

The corrective to all of this is that most work should still be a single call, and the multi-turn instinct has its own failure mode.

When a request is complete, the criteria are known, and the work is bounded, a single call is not a compromise. It is correct, and adding boundaries to it adds latency and state obligations in exchange for information you already had. There is no credit for structure that buys nothing.

The failure mode is using dialogue to avoid specification. When a system needs four exchanges to establish things a well-designed interface would have collected up front, the exchanges are not sophistication, they are an interactive substitute for a form nobody wanted to design. The tell is that the same questions get asked every time, which means they are not ambiguities at all, they are fields. A recurring clarification is a missing input.

The deeper trap is building an interaction that only functions with a human present. It demonstrates well, because a person is always there in a demo, patching the gaps with judgment nobody is measuring. Then it moves to a scheduled run or an API path or a queue consumer, and the human-shaped holes are exposed all at once as timeouts and abandoned work. A design that requires a person to answer has a human on its critical path. That is sometimes the right architecture, and it is never an accident worth discovering in production.

The shape of the interaction is the design

The choice of how many exchanges an interaction takes, and what each one is responsible for, determines more about a system’s behavior than the wording inside any of them. A boundary in the wrong place produces a system that questions users about things it should already know and proceeds silently on things it should ask about. A boundary in the right place produces one that resolves the question that matters, commits to work only after the answer is in hand, and leaves a record of what it assumed when nobody was there to ask.

Design that shape first. For each proposed boundary, ask what information arrives there and whether the work changes based on it. If the answer is nothing, remove the boundary. If the work changes, the latency has bought something, and then the job is to make the exchange worth its cost: one question, the interpretation stated, the inputs of the next step made explicit rather than remembered. And for every boundary that asks something, decide now what the system does when no answer comes. That case is not an edge condition. In any system that outlives its demo, it is the ordinary one.