Agent workflow design: how to scope the first one.

The tempting first move is the most autonomous version of the idea, because it demos well. It also changes the product interface, the workflow, the permission model and the evaluation approach in one go, so the first confusing failure has four plausible explanations and no way to separate them. Designing AI agent workflows the other way round, one bounded job at a time, is slower to demonstrate and much faster to learn from.

Why a bounded job beats a broad one

A boundary is what lets you interpret a result. Consider what “it worked” means without one. The agent produced something plausible, nobody checked it against a definition of correct, and the run is not comparable to the next one because the task was different. Evaluation practice has had to deal with this directly. τ-bench (Yao et al., ICLR 2025) measures with pass^k across repeated runs of the same task, on the reasoning that a single success in a multi-turn, policy-constrained setting tells you very little. AgentBoard introduced a progress rate for partially completed tasks, because binary success hides where a run actually stopped. Both of those instruments need a task with an edge, and so does your product.

Security points the same way. Indirect prompt injection is a demonstrated attack, documented by Greshake et al. (2023), and the design-pattern work of Beurer-Kellner et al. (2025) argues that the dependable mitigation is to narrow the consequential actions available once untrusted content has entered the context. A workflow with a defined set of actions can do that. An open-ended assistant with your whole tool catalogue cannot, because there is nothing narrower to fall back to.

Six axes that decompose a workflow

Take one job and answer six questions about it. The first three describe what the agent needs, and the last three describe what the system owes everyone else. Each maps onto one of the five systems in the Agent Experience field map.

Two of those are routinely underspecified. Authority tends to be inherited from whatever credential the integration happened to use, which produces a workflow that can technically do far more than its job requires. And verification is often deferred until after launch, which means the first version has no way to distinguish a good run from a completed one.

Recovery is the third. A failed step leaves the world in some state, and the workflow either knows that state or guesses. That is the argument in Design for recovery, and it applies from the first prototype, not only once you reach the hardening phase.

Choosing the first one

Four properties make a workflow a good first candidate, and one makes it a bad one.

Frequency. It should happen often enough that you accumulate runs in weeks rather than quarters. Ten runs a day teaches you something; ten runs a month teaches you nothing before the next reorganisation.

Observability. Someone must be able to look at a result and say whether it was right, ideally without a meeting. If correctness is a matter of opinion, you can only argue about the workflow, not evaluate it.

A recoverable worst case. The first version will do something wrong. Choose a job where wrong means an unnecessary draft or a wasted API call rather than a customer receiving a refund they were not owed.

An owner. A real person who cares whether this job is done well, who will look at the failures, and who can authorise a change to the surrounding product. Workflows without an owner produce dashboards nobody reads.

The disqualifying property is silence. A workflow whose failures are invisible, either because nobody checks the output or because a wrong answer looks exactly like a right one, is the worst place to start, however good the time savings look on a slide.

A worked decomposition: triaging an inbound support ticket

The following is synthetic. It describes no real company, product or ticket queue, and the numbers are invented to make the shape concrete.

Intent. When a support ticket arrives, classify it into one of six queues, attach the two most relevant knowledge-base articles, and set a priority. Do not reply to the customer. Success is checkable, because a human agent picks up the ticket and either accepts the routing or changes it.

Context. The ticket text, the customer’s plan tier, their last three tickets, and the current queue definitions. Explicitly not: billing records, other customers’ tickets, or anything from the CRM’s free-text notes field, which is where private commentary lives.

Capability. Four actions. classify_ticket writes a queue and priority. attach_article links an existing knowledge-base entry. request_clarification posts an internal note asking the human agent a bounded question. escalate_now flags the ticket for immediate human attention. There is no send-email capability in this workflow at all, and that is deliberate.

Authority. Classification and article attachment happen without asking, because both are reversible in one click and visible to the person who picks the ticket up. Escalation is also unasked, since the failure mode of escalating unnecessarily is mild. Anything customer-visible is outside the workflow entirely.

Verification. Two checks. The immediate one is whether the human agent changed the queue, which is recorded automatically as part of their existing work. The slower one is a weekly sample of twenty tickets read by the queue owner, scoring routing and article relevance separately, because a ticket can be in the right queue with useless articles attached.

Recovery. If classification is uncertain, the workflow routes to a general queue and says why, rather than guessing a specialist one. If the knowledge base is unreachable, the ticket is still classified and the article step is marked skipped rather than silently omitted. If the same customer’s ticket has been reclassified by a human twice this week, the workflow escalates instead of classifying.

Most of that is product design, and very little of it is model behaviour. The interesting decisions were which field to withhold, which action not to build, and what an uncertain answer should do.

What done looks like

A first workflow is finished when four things are true. It produces a result someone checks as part of work they were already doing. It states what it did not do, so a skipped step is visible rather than inferred. It hands back cleanly at its edges, carrying the reason for the work and not only its state. And it has a recorded way to distinguish a good run from a completed one, which is the loop described in Evaluate the decisions in an agent workflow.

After that, the case for more autonomy can rest on evidence instead of principle. An honest case names what the wider scope would remove, what it would newly put at risk, and which of the six axes would have to change to support it. If the current workflow already does the job and a person can follow what it did, widening it needs a reason.

Frequently asked questions

What does agent workflow design mean? It means designing the parts of an agentic feature that are not the model: what the job is, which context reaches the agent, which capabilities it can call, what it is authorised to do, how the result gets checked, and what happens when a step fails. The model is one component inside that design. Most of what makes an agent workflow usable or unusable is decided outside it.

Why start with one workflow instead of general autonomy? Because a broad autonomous feature changes the interface, the permissions, the tool catalogue and the evaluation approach at the same time, so when something goes wrong you cannot tell which change caused it. A bounded workflow has a start, an observable result and a reason to hand back. That boundary is what makes a failure diagnosable.

How do I choose the first agent workflow? Look for a job that happens often enough to learn from, has an observable outcome, has a recoverable worst case, and already has an owner who can say whether a result was correct. Avoid anything whose failure is silent or irreversible on the first attempt. The goal of the first workflow is to produce knowledge, not to remove the most headcount.

When is an agent workflow finished? When it produces a checkable result, states clearly what it did not do, hands back cleanly at its edges, and has a recorded way to tell a good run from a merely completed one. Finished does not mean unattended. A workflow that quietly succeeds most of the time and fails invisibly the rest is less finished than one that stops and asks.

Pick a job you would be willing to explain to the person it affects, then design every part of it that is not the model.