Agentic Workflow vs Multi-Agent System

Does your business need one AI agent or several? Start with a deterministic workflow or one agent with well-defined tools. Add a specialist agent only when it creates a measurable boundary—different expertise, instructions, context, permissions, ownership or parallel work—and when the extra coordination, evaluation, latency and cost are justified. If two “agents” share the same job, evidence and authority, they are usually one agent split into harder-to-debug pieces.

Agentic does not automatically mean multi-agent

An agentic workflow is a process in which an AI system can choose or adapt some next actions while pursuing a bounded outcome. It may contain one model call, one agent looping over several tools, deterministic code around AI steps, or several coordinated agents. The defining feature is controlled decision-making in the workflow—not the number of personas in a diagram.

A multi-agent system distributes work across multiple stateful agents that communicate, delegate or hand control to one another. Microsoft's AutoGen documentation describes agents as software entities that communicate through messages, maintain state and take actions, with multi-agent applications coordinating those independent units toward a shared goal.

The distinction matters because a workflow can be highly capable without being multi-agent. A single agent can read a case, retrieve approved knowledge, call a CRM, draft an action, request approval and update the record. Splitting each tool into an “agent” does not necessarily add expertise; it adds interfaces and another place for context or accountability to be lost.

Four useful architecture levels

These are choices, not a ladder every project must climb. OpenAI's current agent-building guide recommends maximizing a single agent first because added agents bring complexity and overhead. Its Agents SDK then supports two common multi-agent patterns when that boundary is justified: a manager calling agents as tools while retaining control, and handoffs that transfer the active work to a specialist.

Begin with the control plane, not the cast

Before assigning agent roles, draw the authoritative business flow. Define the start event, accepted outcome, systems of record, permitted actions, approval points, stop conditions, evidence and exception owner. Then identify which decisions genuinely require model judgment and which should remain in code, rules or human approval.

OpenAI's orchestration guidance distinguishes model-led orchestration from code-led orchestration. Code is more deterministic and predictable for speed, cost and performance; model-led routing is useful when the path is open-ended. Most production systems benefit from both: code enforces limits and state transitions, while the model handles language, classification, planning or tool selection inside those limits.

For example, an invoice workflow should not create separate “extraction,” “tax,” “approval” and “posting” agents simply because the process has four boxes. Deterministic validation should protect totals, duplicates, supplier identity and posting rules. A bounded agent may interpret an ambiguous document or suggest coding. An authorized person approves exceptions. The architecture follows control requirements rather than an imagined digital org chart.

The single-agent or multi-agent decision tree

If you cannot answer step five, adding agents is premature. Every branch needs an owner that decides whether the combined result is complete, resolves disagreement and prevents two agents from taking conflicting actions.

Use six criteria, not agent count

A specialist should have a contract: required input, permitted tools, output schema, time or turn limit, evidence requirement, failure state and evaluator. “Ask the finance agent” is not a contract. “Return the reconciled totals, unmatched records, source references and confidence flags without posting anything” is closer to one.

Where multiple agents genuinely help

Independent research across a wide search space

Parallel agents can explore distinct sources or hypotheses when the information space is too broad for one context and the branches do not depend on each other. A manager can assign market, technical and regulatory research, then compare the evidence and produce one controlled result.

Anthropic's production research-system report is useful because it states both the advantage and the price. Their multi-agent design performed well on valuable, heavily parallel research, but the reported system used about 15 times the tokens of ordinary chat interactions. They also found poor fit where agents needed the same context or tasks had many dependencies. Those measurements belong to that research system—not every multi-agent application—but they demonstrate why parallelism needs an economic case.

Distinct permission or accountability domains

A service agent may gather evidence but lack permission to issue a refund. A refund specialist may act only after identity, policy and amount checks. Separating the roles can make sense when each has a distinct identity, tool set, evaluation and audit trail. The boundary must be enforced by the application and authorization layer, not merely described in prompts.

Specialists with materially different operating instructions

A manager may call a legal-research specialist, data-analysis specialist and writing specialist when each needs different tools, output schemas and quality tests. Keep the manager responsible for the final business result. This is the “agents as tools” pattern: specialists perform bounded work without taking over the customer interaction or final decision.

Where multi-agent systems make work worse

• Shared-context work is fragmented. Each agent receives a partial view, so handoffs omit assumptions, decisions or evidence.
• Errors compound. One plausible but incorrect output becomes trusted input to the next agent.
• Responsibility becomes ambiguous. The system logs activity but cannot say which component owned the accepted outcome.
• Permissions spread. Several agents inherit broad tools when one constrained execution boundary would be safer.
• Testing becomes combinatorial. Prompts, routing, order, state and tool results create more interactions to evaluate.
• Cost and latency become opaque. Repeated context, retries and reconciliation consume resources without improving the business result.
• Concurrency creates conflicts. Agents act on stale state, duplicate work or attempt incompatible writes.

Do not fix an overloaded prompt by immediately multiplying agents. First improve tool descriptions, separate deterministic rules, use structured outputs, trim irrelevant context and evaluate failure cases. Introduce a specialist only when those measures reveal a stable boundary.

Three business architecture examples

Customer support: one manager, optional handoff

A customer-facing agent can own the conversation, retrieve approved knowledge, inspect order state and draft permitted responses. A handoff is justified when a regulated, technical or retention specialist must take over under different instructions and authority. Preserve identity, customer intent, evidence, attempted actions and the decision required. Connect the transfer to the human escalation rules, not a generic confidence score.

Document-heavy finance: workflow first

Collection, extraction, matching, validation, approval and posting form one controlled process. Use deterministic gates around records and money; use AI for bounded interpretation. Multiple agents rarely solve weak master data or unclear policy. Start with the invoice and expense blueprint and its exception ownership before considering specialist agents.

Complex research: manager plus parallel specialists

When a high-value question requires independent investigation across markets, technologies and regulations, a manager can dispatch parallel specialists with non-overlapping scopes. Require citations and structured findings, then use a separate reconciliation step to identify agreement, contradiction, missing evidence and the decision impact. Parallel output is not accepted output until it passes that gate.

A safer migration path

1. Model the workflow. Define states, controls, exceptions and the accepted outcome.
2. Automate deterministic steps. Keep stable routing, validation and irreversible controls in code.
3. Add one bounded agent. Give it the minimum tools, context, permissions and stop conditions.
4. Evaluate the whole job. Test representative cases, tool correctness, policy, escalation, latency and cost using the agent evaluation playbook.
5. Measure the constraint. Identify whether failures come from overloaded instructions, tool ambiguity, missing context or a genuinely separate role.
6. Extract one specialist. Define its input/output contract, authority and evaluator; keep the existing agent as manager where possible.
7. Compare architectures. Run the same case set against both versions. Retain multiple agents only if quality, speed, scale or control improves enough to justify the operating burden.

Document the decision in the production agent architecture and estimate the additional calls, review and monitoring in the AI agent operating-cost model. Architecture is a business-control choice, not a demo preference.

Primary sources checked

Checked 10 September 2026. The decision tree and six criteria are Shuhaib's practitioner framework; adapt them to the workflow's consequence, data, integration and accountability requirements.

• OpenAI — a practical guide to building AI agents
• OpenAI Agents SDK — agent orchestration
• Anthropic — how we built our multi-agent research system
• Microsoft AutoGen — agent and multi-agent applications