# Agent workflow design: how to scope the first one.

> Agent workflow design in practice: why designing AI agent workflows starts with one bounded job, how to decompose it, and how to tell when it is done.

Published: 2026-09-08  
Updated: 2026-09-16  
Changelog: 2026-09-16: Expanded from a short note into a full guide with sources, examples and FAQ.  
Canonical: https://agentexperience.tech/insights/start-with-workflows/  
Tags: workflows, strategy, autonomy, scoping, delegated action

**Summary**

Agent workflow design, the part of designing AI agent workflows that is not model work, means deciding everything around the model: the job, the context that reaches it, the capabilities it can call, the authority it holds, how the result is verified, and what happens when a step fails. Starting with one bounded workflow instead of with autonomy is a diagnostic choice, because a narrow job with a real edge lets you trace a failure to its cause. Pick something frequent, observable and recoverable, decompose it along six axes, and treat the first version as a way to learn.

1. Agent workflow design starts with a boundary, because without one you cannot tell a correct result from a plausible one.
2. A defined set of actions also narrows what an agent can do once untrusted content has entered its context, which an open-ended assistant cannot.
3. Choose a first job that is frequent, observable, recoverable at its worst and owned by a real person, and never one whose failures are silent.
4. Decompose it along six axes (intent, context, capability, authority, verification and recovery); authority, verification and recovery are the ones most often left underspecified.
5. A first workflow is done when its result is checked, it states what it did not do, it hands back cleanly and a good run can be told apart from a merely completed one.
6. Widen autonomy only on evidence, by naming what the wider scope removes, what it puts at risk and which axes would have to change.

A bounded job with a real edge teaches you more in a fortnight than a broad demonstration does in a quarter.

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](https://arxiv.org/abs/2406.12045) (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](https://hkust-nlp.github.io/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)](https://arxiv.org/abs/2302.12173), and the design-pattern work of [Beurer-Kellner et al. (2025)](https://arxiv.org/abs/2506.08837) 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](/research/).

| Axis | The question | Field-map system |
| --- | --- | --- |
| Intent | What job is this, stated so that success is checkable? | Orientation and discovery |
| Context | What must the agent know, and where does it get it? | Orientation and discovery |
| Capability | Which actions can it take, and how does it tell them apart? | Tools and interfaces |
| Authority | What may it do without asking, and what needs a person? | Delegated action and trust |
| Verification | How does anyone know the result is right? | Evaluation and improvement |
| Recovery | What happens when a step fails or the world moves? | Workflows and state |

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](/insights/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](/insights/evaluating-agent-workflows/).

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.

![Scoping the first workflow in four steps, from top to bottom, each with what it has to be. 1. Choose one job, highlighted: frequent, observable, recoverable at its worst and owned, and never one whose failures are silent. 2. Decompose it on six axes: intent, context, capability, authority, verification and recovery. 3. Call it done: a checked result, stated gaps, a clean handback, and good runs told apart from completed ones. 4. Widen on evidence: name what it removes, what it puts at risk and which axes must change.](https://agentexperience.tech/diagrams/first-workflow.svg)

*Figure: From one bounded job to a wider scope, and what each step has to satisfy.*

## 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.