> ## Documentation Index
> Fetch the complete documentation index at: https://developer.watson-orchestrate.ibm.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Agent or Agentic Workflow? A decision guide
> How to decide whether to use an Agent, an Agentic Workflow, or call a workflow directly — and how to choose the right integration pattern for your use case.
This guide helps you shape your watsonx Orchestrate solution: when an Agent adds genuine value, when to delegate to an Agentic Workflow, and when to call a workflow directly without an agent at all.
The most common source of production failures in wxO solutions is confusing an Agent with a workflow. They are not interchangeable — they solve different problems.
## The three building blocks
Understanding the distinction between these three concepts is the foundation for sound use case decisions.
| Concept | What it is | When it matters |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Agent** | An LLM-driven orchestrator that receives an instruction, reasons about it, and decides which tools to call and in what order. Limit: 10 tools per agent. | Use when the task requires interpretation, judgment, or handling variable inputs. Reasoning adds \~2–5+ seconds of latency per turn. If you don't need that reasoning, you may not need an agent. |
| **Agentic Workflow** | A structured sequence of steps that coordinates tools, agents, and people. No enforced tool limit. Steps can include tool calls, embedded agent nodes, and User Activities that assign tasks to humans and wait for their response. Can be called through an agent or directly via API. | Use when the process is multi-step and involves any combination of system calls, autonomous reasoning, and human decisions. Calling it directly (headless) removes agent reasoning overhead when determinism is acceptable. |
| **Tool** | An atomic callable unit — an OpenAPI endpoint, a Python function, or a tool exposed via an MCP server. | The building block. Each tool does one thing. Agentic workflows derive their power from coordinating tools across systems that would otherwise each require custom integration code. |
The key question an Agentic Workflow answers: *"I have a multi-step process that touches several systems and needs to adapt based on intermediate results — how do I orchestrate that without writing a custom integration for every variation?"*
## When an Agent adds genuine value
Use an Agent when the task genuinely requires reasoning over variable or unstructured input — where the correct next step cannot be determined by reading a rule, but must be inferred from context.
| Condition | Why an Agent is the right choice |
| -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Input is unstructured or variable (free-text, documents, emails) | The Agent interprets the input and decides which tools to invoke based on content — something a rule engine cannot do reliably. |
| The workflow path is not fully known at design time | When the conditions governing which step runs next depend on factors that can only be evaluated at runtime, Agent reasoning is what makes the workflow adaptive. |
| The task requires synthesising information across multiple sources before acting | The Agent can hold partial results in context, reason across them, and produce a coherent output — a coordination task that is hard to encode deterministically. |
| A human is interacting conversationally and intent must be interpreted | The Agent is designed to handle natural language and resolve ambiguous intent. |
## Why Agents should not enforce business rules or orchestrate fixed processes
The most common mistake is using an Agent to enforce business rules or orchestrate a workflow whose steps are already fully determined. These systems appear to work in testing but fail silently in production.
**The core problem: Agents approximate. They do not execute.**
Agent instruction-following is statistical, not deterministic. Three concrete consequences:
1. **Rules encoded in prompts are not reliably enforced.** `NEVER`, `ALWAYS`, and `MUST` are statistical weights, not logic gates. Frontier models achieve only 70–80% accuracy when multiple constraints are present simultaneously. Negative constraints are harder to follow; conflicting constraints resolve by positional bias.
2. **Longer prompts reduce reliability.** Attention is finite. Instructions in the middle of a long prompt receive less attention weight. Adding rule #41 to a 40-rule prompt does not enforce rule #41 — it pushes earlier rules further into the low-attention zone.
3. **Workflow logic in natural language is ambiguous.** Conditional instructions are pattern matches against a probability distribution, not boolean checks. Multi-turn state tracking is especially fragile — asking a model to remember whether the user confirmed in a prior turn is asking it to maintain structured state across a medium not designed for it.
The result is a specific class of production failure: the agent takes a wrong path, skips a mandatory step, or bypasses a governance gate — silently, with no error and no audit trail. In regulated industries, this is not an acceptable architecture.
"Agentic" does not mean every step is LLM-driven. The most important steps in enterprise solutions — compliance checks, financial transaction commits, governance approvals — must be deterministic and auditable. Use Agent reasoning where interpretation of variable input is required; use deterministic steps where logic is fixed, stakes are high, or output must be auditable. A well-designed wxO solution will contain both.
### The right design boundary
| If the task requires... | Use... |
| ------------------------------------------------------------ | ------------------------------------------------------------------------- |
| Interpreting variable input and deciding which tools to call | Agent |
| Synthesising across sources, reasoning over partial results | Agent |
| Executing a known, fixed sequence of steps | Agentic Workflow Direct (no Agent) |
| Enforcing a mandatory business rule or governance gate | A tool or code-level check inside the workflow — not an Agent instruction |
| Routing based on finite, known conditions | Conditional logic in the workflow — not Agent reasoning |
| Tracking multi-step state across turns | Agentic Workflow with explicit state — not Agent context |
Use an Agent where interpretation is required; use a deterministic workflow node everywhere else. When you need both, embed an Agent node at the step that requires reasoning and let the surrounding workflow enforce structure, sequencing, and governance.
## Decision criteria: shaping your wxO solution
These two decisions are often conflated. Answer them in order.
### Decision 1: What kind of agentic workflow do I need?
| Question | What it means for your workflow |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Does the process involve multiple steps where later steps depend on the results of earlier ones? | Use an agentic workflow — tool chaining across systems with managed state is the core capability wxO delivers. |
| Does the task need to coordinate multiple external systems? | Use an agentic workflow — wxO manages sequencing, state, and error handling across systems so you don't have to build custom integration logic for every combination. |
| Does the solution require a human to make a decision, approve an outcome, or provide input at a defined point? | Include User Activities in the workflow — the workflow pauses, routes a task to a specific person or role, and resumes with their response as a structured input to the next step. |
| Does the use case require custom multi-step agent coordination — critic loops, parallel agents with aggregated results, or human-in-the-loop with structured task assignment? | Use an agentic workflow as the coordination layer — these patterns require a workflow to enforce sequencing and govern what happens before and after each agent or human step. |
| Is the task long-running or stateful — does it span multiple steps over time, wait on external systems, or need to resume after a human response? | Use an agentic workflow — the platform persists state at every step, so execution can span minutes, hours, or days and resume exactly where it left off. |
| Is the logic fully deterministic — the same inputs always produce the same steps in the same order? | Call the agentic workflow directly without an Agent — deterministic logic is a strength here, not a limitation. Keep execution predictable and fast. |
| Does the process mix adaptive steps (reasoning required) with deterministic steps (compliance checks, transaction commits, mandatory approvals)? | Use an agentic workflow with an embedded Agent node only at the adaptive steps — the surrounding workflow enforces the deterministic steps with full reliability. |
### Decision 2: Should I call the workflow through an Agent, or directly?
The default is to invoke an agentic workflow as a tool inside an Agent, which interprets the user's input and passes the right parameters. This is correct when the input is unstructured or variable.
Routing through an Agent adds latency (2–5+ seconds of LLM reasoning before the workflow starts) and non-determinism (the Agent may rephrase parameters or vary tool selection across identical inputs).
**Call the workflow directly when any of the following apply:**
| Condition | Why it matters |
| ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The workflow entry point and parameters are fully known from the trigger | There is no interpretation work for the Agent to do. Calling it directly is faster and eliminates a source of variance. |
| The logic is fully deterministic — the same input always produces the same steps | Agent reasoning adds no value and introduces non-determinism into a flow that should be predictable. |
| The output must arrive verbatim — legal text, compliance language, regulated responses | An Agent will rephrase, summarise, or reframe output before returning it. Use User Activities to deliver workflow output directly to the channel without LLM modification. |
| Latency is critical — the end-to-end SLA cannot absorb the additional reasoning overhead | LLM inference adds 2–5+ seconds per turn depending on prompt complexity. For latency-sensitive flows, call the workflow directly so execution time is dominated by actual tool calls, not reasoning passes. |
| Governance gates must fire on every execution without exception | Agent instruction-following is probabilistic. A gate encoded in an Agent instruction can be bypassed. Encode mandatory controls as deterministic workflow steps or tools — not in the Agent's prompt. |
## Use case map
Common enterprise scenarios mapped to the recommended approach.
| Use case | Why Agentic Workflow fits | Recommended approach |
| -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Document ingestion and extraction (invoices, contracts, reports) | Input is unstructured and variable; the agent classifies, extracts, and routes based on content. | **Agentic Workflow via Agent** |
| Multi-step approval and validation (loan applications, compliance sign-off) | Each step depends on the prior outcome. Encode mandatory governance gates inside tools — not in agent instructions. | **Agentic Workflow via Agent** or **Agentic Workflow Direct** (supports multi-user flows with User Activities) |
| Data enrichment pipelines (CRM enrichment, entity resolution) | Agent calls multiple data sources, merges results, and writes enriched output. | **Agent** or **Agentic Workflow Direct**, depending on whether step sequencing is fixed |
| Intelligent triage and routing (support tickets, incident classification) | Agent reads, classifies, and routes or escalates based on content. | **Agentic Workflow via Agent** — classification requires reasoning |
| Latency-sensitive document processing (strict SLA, verbatim output) | Deterministic steps, known parameters. Agent reasoning overhead (\~5 seconds) and rephrasing are unacceptable. | **Agentic Workflow Direct** |
| Regulated or compliance output (legal text, audit responses) | Output must not be modified by an LLM. User Activities deliver it directly to the channel. | **Agentic Workflow Direct** — preserves output fidelity |
| Research and summarisation (market research, document synthesis) | Agent retrieves from multiple sources, synthesises, and produces structured output. | **Agentic Workflow via Agent** |
| Iterative reconciliation (ledger matching, inventory sync) | Agent matches records, flags discrepancies, and iterates until reconciled. | **Agent** or **Agentic Workflow Direct** with a loop guard. Always set a maximum iteration count. |
| Automated report generation (scheduled reports, on-demand summaries) | Pulls data from multiple tools, applies logic, produces a structured report. | **Agent** or **Agentic Workflow Direct**, depending on whether content synthesis is needed |
| Human-in-the-loop workflows (draft-then-approve, recommendation-then-confirm) | Agent produces a draft or recommendation; a human reviews before the final action. | **Agentic Workflow via Agent** — the human gate is the safety mechanism |
| Human-in-the-loop with structured task assignment (exception handling, expert review, regulated approvals) | Workflow pauses at a defined point, routes a task to a named user or role via User Activities, and resumes with their response as a structured input. Use when the interaction must be auditable and repeatable, not conversational. | **Agentic Workflow with User Activities** — encode the gate as a User Activity step, not in agent instructions |
| Agent-in-the-loop for controlled autonomous action (adaptive step within a governed process) | The overall process is deterministic, but one or more steps require reasoning over variable inputs. An agent node handles only that step; the surrounding workflow enforces entry conditions, output contracts, and sequencing. | **Agentic Workflow Direct with an embedded agent node** — define clear input/output contracts for the agent node |
| Custom multi-agent coordination patterns (critic loops, LLM-as-judge, parallel agents with aggregated results) | The built-in supervisor/collaborator model does not support these patterns. Build the coordination logic as a generic agentic workflow; the agents handle adaptive steps within it. | **Agentic Workflow Direct** as the coordination layer. Always set a maximum iteration count on any loop. |
| Long-running business processes (onboarding, procurement, claims processing, contract lifecycle) | The process spans hours, days, or weeks — crossing system boundaries, waiting on humans, and resuming after external events. State is persisted at every step. | **Agentic Workflow Direct with User Activities** — the workflow is the process record. Avoid routing through an agent for the overall orchestration; the workflow should own the state and sequencing. |
## Choosing the right integration pattern
Before building an agentic workflow, ask whether you need one — or whether a simpler pattern gets you to the same place.
**Expose it as an atomic tool**
If the capability is a single, self-contained function — a lookup, a write, a calculation — expose it directly as a tool (OpenAPI endpoint, Python function, or MCP tool). There is no reason to wrap a single-purpose function in its own workflow.
**Expose it as an MCP tool**
If you have an existing process or system that already works well, expose it as an MCP tool rather than re-implementing it as an agentic workflow. MCP tools encapsulate arbitrarily complex backend logic behind a clean, agent-ready interface. Use this for mature, stable processes where the value is composability, not rebuilding.
**Build an agentic workflow wrapper**
Many existing APIs require multi-step interaction to accomplish a single logical task, return raw data that needs filtering before an agent can use it, or need state managed across multiple calls. An agentic workflow is the right integration layer — not to replace the underlying system, but to wrap it with a clean, agent-ready interface that sequences calls, filters responses, and manages intermediate state.
### Where existing technology already suffices
Some scenarios involve no reasoning, coordination, or human interaction — agent overhead adds nothing.
| Scenario | Why existing technology is the right fit | Approach |
| ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| Microsecond or low-millisecond SLA decisioning (fraud scoring, live pricing, real-time credit checks) | LLM inference adds 2–5+ seconds per turn — orders of magnitude above these SLA requirements. Even calling the workflow directly without an agent reduces overhead to sub-second, but not to the sub-10ms range these use cases require. | Rule engine or ML model served directly via a low-latency API |
| Pure notification or alerting (send email when threshold exceeded) | Trigger and action are both deterministic. No interpretation or coordination involved. | Event-driven webhook or automation rule (for example, IBM App Connect) |
| High-frequency micro-transactions (per-click events, telemetry ingestion) | Volume and frequency far exceed what agent sessions are designed for. | Stream processing (Confluent Kafka or IBM MQ) or a lightweight serverless function — expose as an MCP tool if composability is needed later |
**The underlying principle:** Use an atomic tool for single-purpose functions. Use an MCP tool for existing processes. Build an agentic workflow when the coordination, sequencing, or human interaction logic is itself the value being delivered.
## Related resources
* [Foundational architecture considerations](/agents/agent_design/foundational_architecture) — common anti-patterns including the agent-as-business-process fallacy
* [Tooling and scalability considerations](/agents/agent_design/tooling_scalability) — tool design and agent tool limits
* [Building an agentic workflow](/tools/flows/building_flow) — step-by-step guide to creating workflows
* [User Activities node](/tools/flows/user_activities_node) — human-in-the-loop workflow steps
* [Agent node](/tools/flows/agent_node) — embedding an agent inside a workflow