Use a rule-based workflow when conditions and outcomes are stable, and use one bounded AI step for a specific language task such as classification, extraction, summarization, or drafting. Use an AI agent only when the goal requires the system to choose among tools or variable steps. In production, combine them: AI for interpretation, rules for sensitive execution, and people for high-impact exceptions.
Confusing these patterns leads teams either to overengineer a simple process or to expect one generation call to operate a multi-stage business workflow. The useful question is not “Should we use AI?” It is: Which part requires inference, which part must remain deterministic, and what happens if it is wrong?
Three patterns, not two
“Intelligent automation” can describe three materially different designs:
Pattern | Who selects the next step? | Typical shape | Variability |
|---|---|---|---|
Rule-based workflow | The designer encodes branches in advance | If X, do Y; otherwise follow Z | Low |
Bounded AI step | A model returns one output for a defined task | Classify, extract, summarize, or draft | Moderate and contained |
AI agent | A model selects tools or actions and decides whether another step is needed | Plan, call a tool, inspect the result, then act or call another tool | Higher and in need of stronger safeguards |
Not every node labelled AI is an agent. A single model call that returns JSON or a draft does not automatically choose an API, retry an operation, or change an external system. Conversely, connecting tools to an agent does not mean it should receive every tool the company owns.
When are rules the correct choice?
Use rules when the condition, result, and validation can be specified before execution. Examples include:
Routing a Jeddah channel conversation to the Jeddah team.
Blocking a campaign when documented consent is absent.
Requesting ERP order status after validating the order-number format.
Escalating when a customer explicitly asks for a person.
Rejecting a discount above a financial or authorization threshold.
Rules are fast, auditable, and repeatable for the same input and context. They become brittle when teams try to represent free-form language with dozens of keywords and nested branches. The answer is not always a larger ruleset; a bounded interpretation step can precede the deterministic decision.
The WhatsApp workflow design guide shows how to structure triggers, conditions, actions, and failure branches without building an unmaintainable diagram.
Where does a bounded AI step fit?
A bounded step fits unstructured input with a clearly specified output. Useful examples are:
Classify a message as
sales,support,billing, orunknown.Extract order number, product, and city into a fixed JSON schema.
Summarize the last ten messages for an agent without taking external action.
Draft a reply grounded in approved facts for a person to review.
Return
needs_clarificationwhen required information is missing.
For example:
{
"intent": "order_status",
"order_id": "SO-10482",
"needs_human": false,
"missing_fields": []
}The workflow then checks that intent is allowed and the order ID matches the required pattern before calling another system. Invalid JSON or a missing field goes to a clarification or human branch. That differs from allowing the model itself to choose what to call and how to execute it.
In sales use cases, generation should be grounded in available customer and product facts rather than invented context. The AI sales and customer-context guide explains that separation between retrieval and drafting.
When is an AI agent worth the extra complexity?
An agent is justified when the sequence cannot be known in advance for every case, while the goal, tools, and boundaries can still be constrained. Consider “help an agent answer a complex order question.” The agent may need to:
Read the customer profile.
Find the referenced order.
Fetch shipment state if the order has shipped.
Compare the result with the return policy.
Draft an answer or ask for missing information.
One case may stop after step two, while another needs four calls. That flexibility is the value of an agent and the source of its risk: it can choose the wrong tool, repeat a call, access excessive data, or act before validation is complete.
Do not choose an agent merely because a conventional diagram contains five branches. If the branches are known and stable, rules are simpler. Agent behavior is useful when selecting the information or tool is itself part of the problem.
A compact decision table
Task characteristic | Rules | Bounded AI step | AI agent |
|---|---|---|---|
Structured conditions and fixed result | First choice | Usually unnecessary | Excess complexity |
Free text and one defined output | Validate the result | First choice | Only if variable follow-up tools are required |
Several systems and a changing sequence | Enforce boundaries | Useful as a sub-step | Appropriate with tool and step caps |
Financial or legal impact | Enforce eligibility and limits | Extract or propose only | Never execute without deterministic controls and approval |
Strong explanation and audit need | Naturally clear | Log input, output, and validation | Requires a trace of tool choices, arguments, and results |
Tight and predictable latency or cost | Best fit | Relatively bounded | More variable; enforce budgets and timeouts |
Evaluate the cost of being wrong before the benefit of flexibility. If the output is a draft reviewed by an employee, the AI role can be broader. If it changes a price, order state, customer record, or sensitive outbound message, narrow its authority and raise the approval bar.
A practical hybrid pattern
An order-support flow can look like this:
Inbound message
↓ rules: eligible channel? known customer?
AI step: classify intent and extract order_id
↓ validate schema and identifier format
Rule: order_status?
├─ yes → read-only ERP tool
│ ↓
│ AI step: draft from retrieved facts
│ ↓
│ policy gate + human approval where required
└─ no/unclear → assignment or clarification questionFor a genuinely ambiguous case, place a constrained agent between validation and drafting, with an allowlist of read-only tools. Keep eligibility and the outbound send gate outside its authority. When external systems are involved, use stable IDs and idempotent operations as described in the WhatsApp CRM and ERP integration guide.
Guardrails to build before the agent
The NIST AI Risk Management Framework organizes work around governing, mapping, measuring, and managing AI risk. Translate that into day-to-day workflow controls:
1. A narrow objective and scope
State what the agent can and cannot do. “Assist with order questions” is safer and more testable than “solve every customer request.” Tie every tool to a declared purpose.
2. An allowlist of least-privileged tools
Start with read operations. If writing is necessary, expose a purpose-built endpoint with limits rather than a general administrative token. The platform should execute the tool and protect credentials; never insert an API secret into the model's context.
3. Deterministic input and output validation
Use JSON schema, enumerations, length bounds, and identifier validation. Never transform unconstrained model text directly into a price, database query, or target URL.
4. Human approval for high-impact effects
Discounts, refunds, cancellations, customer-record changes, and bulk sends are candidates for approval or strict deterministic policy. Show reviewers the facts on which the draft or action was based.
5. Step, time, and cost ceilings
Cap tool calls, elapsed time, context size, and recovery attempts. In Wats, the ai.agent node can be constrained through maxToolSteps; its current default is four tool steps, and teams should tune the cap to the use case rather than extend it without limit.
6. An explicit failure and escalation path
When information is missing, tools disagree, or validation fails, the model must not guess. Return a structured outcome such as needs_human, including the reason and available facts.
7. Traces and evaluation tests
Record the workflow version, scrubbed input, safe tool arguments, tool results, validation, and final decision. Build an evaluation set from normal and edge cases, then rerun it whenever the prompt, model, or tool changes.
Treat customer messages and external page content as untrusted data rather than administrative instructions to the agent. When results arrive through external events, apply signature and deduplication controls from the WhatsApp webhooks guide.
How Wats represents the distinction
Wats separates its agent node from bounded generation steps. Nodes such as ai.generate_reply and ai.gemini_generate, or the ai.model.gemini_chat model node, perform defined inference or generation and can consume context and fact nodes. The ai.agent node can work across tools and multiple steps under a configured limit, including an HTTP tool where required.
That separation supports a hybrid workflow: deterministic conditions, extraction or generation, an agent only where the path genuinely varies, and a final validation and send gate. Node names do not replace risk design. Even a bounded step needs schema and approved facts; an agent additionally needs constrained permissions, steps, and escalation.
Give each layer only the autonomy it needs
If a decision can be written as a stable rule, keep it a rule. If the challenge is interpreting unstructured text and returning one defined result, use a bounded AI step. If a limited goal genuinely requires variable choices across tools and steps, use an agent inside a clear fence. The best design is not the one with the most “intelligence” in its name; it puts flexibility where it helps and keeps consequential decisions predictable and reviewable.