Design AI Workflows Around Work, Not Agents

Yes: design AI workflows around the work that needs to be done, not around a collection of agents. Start with the task, its inputs, decisions, handoffs, and required outcome; then use an AI model or agent only where it reliably helps.

Why the workflow should come first

An agent is a software component that can pursue a goal by choosing actions, often using tools or calling other systems. A workflow is the broader process: it describes what happens from the initial request to a verified result, including human decisions and exceptions. The distinction matters because a process is responsible for an outcome; an agent is just one possible means of producing part of it.

When teams begin by asking, “How many agents should we build?”, they can end up with extra handoffs, duplicated context, and unclear responsibility. A better first question is, “What work is being done, and where are the real bottlenecks?” Some steps may need no AI at all. A deterministic rule, a database query, or a person may be more dependable than a model for a particular part of the process.

This is not an argument against agents. It is a way to use them deliberately: give a model a defined role within a process, set boundaries around what it may do, and measure whether it improves the outcome.

Map the work before choosing tools

Write down the current process before redesigning it. Include the ordinary path and the exceptions, rather than describing only an idealized task. For each step, identify who or what performs it, what information is needed, what decision is made, and what counts as completion.

• Trigger: What starts the work: a submitted form, an incoming message, or a scheduled event?
• Inputs: Which records, documents, or instructions are necessary, and which sources are authoritative?
• Transformations: Is information being extracted, classified, summarized, compared, or drafted?
• Decisions: Which choices are governed by explicit rules, and which require judgment or approval?
• Handoffs: Who receives the result, and what context must travel with it?
• Completion: What evidence shows the work is accurate, accepted, and recorded?

For example, processing a customer message might involve identifying its topic, finding relevant account details, drafting a response, checking whether a policy exception is involved, and sending or escalating it. That map may reveal that classification and drafting are good candidates for AI, while account changes and exception approvals need strict rules or human authorization.

Choose the right level of automation

Match each step to the simplest approach that meets its requirements. A fixed calculation or lookup is usually better handled by code or a rule than by asking a language model to reproduce it. A model may be useful for interpreting varied text, but its output should be constrained and checked where errors matter.

• Use rules or ordinary software for stable, explicit conditions, calculations, permissions, and required record updates.
• Use a model for bounded language tasks such as extracting fields from varied documents, categorizing free-text requests, or drafting a response from approved material.
• Use a human review step when a decision is ambiguous, consequential, outside policy, or difficult to verify automatically.
• Use an agent when action selection is genuinely needed: for example, when a system must choose among approved tools based on what it finds, within defined limits.

Do not grant an agent broad autonomy just because the task sounds complex. A sequence of predictable steps can be orchestrated as a straightforward workflow. If a model must choose an action, restrict its available tools, define stopping conditions, and require confirmation for consequential actions.

Make responsibilities and handoffs explicit

A robust workflow specifies what each stage receives and returns. This is especially important when a model’s output becomes another system’s input. Use structured fields where possible, such as a category, a short rationale, and an uncertainty flag, rather than passing an unrestricted paragraph and hoping the next step interprets it correctly.

Also define what happens when information is missing, sources disagree, or the model cannot make a confident recommendation. A safe fallback might be to ask for clarification, route the item to a reviewer, or stop before making a change. “Try again” is not a complete exception policy; repeated model calls can produce different answers without resolving the underlying uncertainty.

Keep permissions aligned with responsibilities. A model that drafts a message does not need the same access as a component that sends it. Separate reading, drafting, approving, and committing actions where that reduces the impact of mistakes. Record enough context to review what happened: the inputs used, the output, any tool actions, and the approval or rule that allowed the next step.

Measure outcomes, not agent activity

Counting agents, tool calls, or generated words does not show whether the process improved. Define measures tied to the work, and compare them with a baseline where practical. Useful measures may include completion time, correction or rework rates, successful handoffs, unresolved cases, and the share of work that needs human review.

Check quality on representative examples, including difficult and unusual cases. A workflow that performs well on routine requests can still fail on missing documents, conflicting instructions, or attempts to push it beyond its intended role. Review errors by stage: an incorrect answer may originate in poor source data, a weak retrieval step, an unclear instruction, a bad rule, or an unsuitable model choice.

Track the cost of the complete process, not just model usage. Human review, system maintenance, retries, monitoring, and the work of correcting mistakes all affect whether automation is worthwhile. A modest tool that reliably removes a bottleneck can be more valuable than an elaborate multi-agent setup that is difficult to debug.

Common design mistakes and misconceptions

“More agents means more intelligence” is a common misconception. Multiple agents can divide work, but each handoff can lose context, introduce disagreement, or make failures harder to locate. Add separate agents only when their responsibilities are distinct and the division provides a measurable benefit over a simpler design.

Another mistake is treating a fluent response as verified truth. Language models can produce plausible errors, and an agent’s ability to use tools does not make its decisions inherently reliable. Ground answers in approved sources when needed, validate structured outputs, and test the complete workflow rather than only the prompt.

Finally, avoid automating a process that is poorly understood. If people follow inconsistent procedures or source records are unreliable, AI may make the inconsistency faster rather than fix it. Clarify the process and its ownership first; then automate the parts that are stable enough to support.

Frequently Asked Questions

What does it mean to design AI workflows around the work?
It means defining the task, steps, decisions, constraints, and success measures before selecting AI tools. The model or agent is chosen to serve a specific part of that process.

Should every AI workflow use an agent?
No. Many workflows need only a model call within a fixed sequence, or no AI at all. Use an agent when the system must select among permitted actions based on changing information.

When should a human stay in the loop?
Keep human review for ambiguous cases, exceptions, consequential decisions, and actions that are difficult to reverse or verify. The exact threshold depends on the impact of an error and the quality of available checks.

How do I know whether an AI workflow is working?
Compare results with the existing process using measures such as accuracy, completion time, rework, escalation frequency, and total operating effort. Include difficult cases, not just routine examples.

How many agents should one workflow have?
There is no universal number. Begin with the fewest components that can meet the requirements, then add agents only when a clearly separated responsibility improves results without making oversight or debugging unmanageable.

Related

• Audiophile Curse or Blessing? Honest Look
• Morning Notes Before Work: 7 Real Reasons
• Raspberry Pi OS Bookworm Upgrade: What You Need to Know