An agent handed a goal and a set of tools will find a path to the goal. It will find a slightly different one next time. And it will not, on its own, tell you which one it took.
That is the whole appeal and the whole problem in one sentence. Flexibility is why an agent handles the case nobody anticipated. Flexibility is also why the same request produces two different sequences of actions on Tuesday and Thursday, and why nobody can say in advance which steps are guaranteed.
The missing artifact is old, unglamorous, and has an ISO number. It is a picture of the process that exists independently of the agent, drawn in a notation other people can read, marking which parts of the work are fixed and which parts are the agent’s to decide.
What a prompt cannot pin down
Instructions describe intent. Structure describes what is possible.
An instruction saying to check with the customer before issuing a refund is a preference. The model weighs it against everything else in its context, and it usually complies. Usually is the operative word, and it is doing an enormous amount of load-bearing work in a system that moves money.
An approval step placed before the refund step in the process, implemented so that the refund call cannot execute without the approval record, is structure. It is not weighed. It cannot be talked out of by an unusual case or a confidently worded email, which is a distinction that prompt security makes very concrete.
Three things fall into the structure category and stop being negotiable the moment they are drawn:
Order. Which step cannot start until another one finishes. Most processes have only a handful of genuine ordering constraints and a great many steps that could happen in any sequence. Knowing which is which is most of the design.
Owner. Which participant is responsible for each step, and therefore what that participant is allowed to touch. In the notation this is a lane, a horizontal band across the diagram carrying one participant’s steps. In the build it becomes a permission boundary, which is the same idea drawn from the other direction.
The failure path. What happens when the step does not complete: the document is missing, the customer replies in the middle, the approval never arrives, the API returns an error at 2am on a Sunday.
None of the three is expressible as a preference. All three are expressible as a diagram.
The improvisation budget
Here is the exercise, and it takes an afternoon rather than a quarter.
Draw the process. Then go step by step and mark each one as fixed or discretionary. Fixed means the same input always produces the same action, and a person could write down the rule. Discretionary means the step requires reading something, weighing something, or producing language, and the rule cannot be written down without a page of exceptions.
What comes out of that exercise is almost always lopsided in a direction people find surprising. A process with fourteen steps typically has two or three that genuinely need judgment. Classifying an incoming email by intent, drafting a response that fits the situation, summarising a call into the three things that mattered. The rest is lookup, transfer, formatting, validation, logging and routing, all of which have written-down rules and all of which run better in ordinary code.
That distribution is the improvisation budget, and it is worth being deliberate about because the two columns have completely different properties.
A fixed step in code costs effectively nothing per execution, produces the identical result every time, fails loudly when it fails, and can be tested with certainty. A discretionary step calls a model, costs money on every run, produces a result that varies, fails quietly, and can only be tested statistically against a set of known cases.
Neither column is better. They are for different work. What matters is that a build which never drew the line has put everything in the expensive, variable column by default, because handing the whole job to the model is the path of least resistance when nobody has said where the boundaries are.
The exception branches are most of the real diagram
The version of a process people describe out loud has six boxes in a row. The version that runs has six boxes and eleven branches, and the branches are where the work actually goes.
What happens when the invoice has no purchase order number. What happens when the customer replies while the request is mid-flight. What happens when two people submit the same thing. What happens when the approval sits unanswered for nine days.
Agents do not fail on the happy path. Any reasonable build handles the case where everything is present and correct. They fail on the branches, and they fail in a specific way: handed a situation the process never named, an agent will do something plausible rather than stopping. Plausible is worse than stopped, because plausible does not generate a phone call.
Drawing the branches forces the question that nobody wants to answer: when this happens, who deals with it. A branch with no destination is not an edge case. It is a decision nobody has made, and it will be made in production by whichever component happens to be holding the request.
Why the map makes the system cheaper as well as safer
The cost argument is the one that tends to land, so it is worth doing plainly.
A step handed to a model is billed by how much text goes in and comes out, every time it runs. A step implemented as a database lookup is billed at approximately nothing. Moving nine steps out of the first category and into the second does not improve the system marginally. It changes the shape of the monthly bill.
The map also shrinks what remains. Once the diagram exists, each model call has a defined job with a defined input, which means it can be handed the two paragraphs it needs instead of everything the process has accumulated so far. That is the difference context engineering describes, and the diagram is what makes it possible to decide. Without one, every step receives everything, because nobody knows what any particular step actually requires.
There is a second-order effect worth naming. A drawn process is a process that can be handed to a different model next year without redesigning the system, because the structure lives in the diagram and the code rather than inside a prompt that happened to work with one vendor’s model.
What this looks like in a proposal
For any agentic build, the question is short: show the process diagram, and mark which steps the model decides.
A good answer is a picture with the discretionary steps circled. Three of them, each with a stated job, each with a named input, each with a defined output the next step can rely on. The rest of the diagram is code. The exception branches all terminate somewhere, and at least one of them terminates at a person with a name.
A vague answer is a description of the agent’s capabilities and the tools it has been given. That is a description of what the system could do, offered in place of a description of what it will do, and the gap between those two is where the surprises live. Orchestration is mostly the discipline of closing it.
The notation itself is a detail. Business Process Model and Notation is the standard one, maintained by the Object Management Group and published as ISO/IEC 19510, and it is worth using because other people can read it without a translator. A clear diagram in any consistent notation beats a beautiful one nobody outside the room understands. What is not optional is that the diagram exists, on one page, agreed before the build rather than reconstructed afterwards.
The part worth carrying out the door
An agent is very good at finding a path and very bad at guaranteeing one. The diagram supplies the guarantee.
Draw the process. Mark the two or three steps that genuinely need judgment, and let the model have those. Put the order, the owners, the approvals and the exception branches into structure, where they run the same way on a Sunday as they do in a demonstration. Give every branch a destination and every step an owner.
The result costs less, breaks more loudly, and survives a change of model. It also gives you something a demonstration never does: a picture of what the system will do, agreed in advance by people who understand the work.