Definitions and comparisons
Agentic workflows explained: a customer support example, step by step
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
Agentic workflows are AI systems in which a language model completes a multi-step task by calling tools, reading the results, and deciding what to do next, inside limits set by code and people. Some steps follow fixed paths; others let the model choose. In customer support, that means classifying a refund request, checking order and policy systems, proposing a remedy, pausing for approval when rules require it, and logging the outcome.
Key takeaways
- An agentic workflow lets a language model complete a multi-step task by calling tools and deciding next steps from what they return, within limits set by code and people.
- Anthropic separates workflows (predefined code paths) from agents (model-directed process and tool use); most production systems mix both.
- Rules and RPA handle in-policy refunds well; agentic workflows earn their cost on exceptions that need investigation.
- Gate money-moving, irreversible and exception actions behind human approval, and log the human's decision, changed values and reason code as structured data.
- A useful trace records run metadata, each tool call and result, decisions with policy references, escalations, human interventions and the final outcome.
- Evaluate the end state first, measure consistency across repeated trials, and build tasks from historical cases that include real exceptions.
What is an agentic workflow?#
An agentic workflow is a system where a language model works through a task in several steps, uses tools to read or change real systems, and uses what each step returns to choose the next one. The model is not just answering a prompt; it is acting inside a process with a goal, a set of permitted actions, and a point where it stops or hands off.
Anthropic's engineering guide draws the clearest line. It calls workflows "systems where LLMs and tools are orchestrated through predefined code paths" and agents systems where "LLMs dynamically direct their own processes and tool usage." It groups both under the label agentic systems. In practice, most production agentic workflows mix the two: code fixes the order of some steps, and the model decides inside the steps where judgment is needed.
The idea has a research lineage. ReAct (an ICLR 2023 paper) studied combining a model's reasoning with actions it takes in an environment, with experiments on HotpotQA, FEVER, ALFWorld and WebShop. Modern tool-use APIs make the loop concrete: the model returns a structured tool call, your application runs it, and the result goes back to the model as input for its next decision.
A useful working test: if you can draw every path on a whiteboard before the request arrives, you have a workflow. If the model chooses which tools to call, in what order and how many times, you have an agent. Both count as agentic when a model, not a fixed script, makes at least some of the step-by-step decisions.
- Goal: a defined end state, such as a refund issued, a request denied with a reason, or a case escalated.
- Tools: functions the model may call, each with a schema and permissions (read order, create refund, update ticket).
- Feedback loop: each tool result is fed back so the model works from current facts rather than guesses.
- Decision authority: written limits on what the model may do alone and what needs a person.
- Stop and handoff conditions: a maximum number of steps, error thresholds, and triggers that route to a human.
How do agentic workflows differ from chatbots, RPA and fixed automation?#
The difference is who decides the next step and what the system can act on. A chatbot answers; rule-based automation and RPA execute steps someone scripted in advance; an agentic workflow lets a model choose among tools based on what it finds, within limits.
That flexibility is the reason to use one and also the main risk. Anthropic notes that the autonomy of agents brings "higher costs, and the potential for compounding errors," which is why the comparison below includes the typical failure mode for each approach.
| Approach | Who decides the next step | Handles messy input | Typical failure mode | Fit for a refund exception |
|---|---|---|---|---|
| FAQ or retrieval chatbot | Nobody; it answers one turn at a time | Yes, for questions | Gives policy text but cannot act on the order | Explains the policy, cannot resolve the case |
| Rule-based automation (helpdesk triggers, CRM flows) | Rules written in advance | No, needs structured fields | Breaks or misroutes when a case falls outside the rules | Handles in-window refunds, fails on exceptions |
| RPA bot | A recorded or scripted UI sequence | No, needs stable screens and fields | Stops when a screen, field or edge case changes | Can key a refund once someone has decided it |
| LLM workflow (predefined code path) | Code fixes the sequence; the model fills each step | Yes, within each step | Wrong output at one step flows into the next | Good when the exception path is known and stable |
| Agent (model-directed loop) | The model, within tool permissions and stop rules | Yes | Wrong tool, extra steps, overreach without guardrails | Good when cases vary and need investigation |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
What does an agentic customer support workflow look like?#
The worked example below is an illustrative refund exception at a hypothetical online retailer. It is not a real customer case, and the thresholds are placeholders a team would replace with its own policy.
A customer writes in through the helpdesk: a $180 order arrived with a cracked part, and they want a refund. Delivery was 41 days ago, and the return policy allows 30. The retailer's policy lets support refund up to $100 without approval inside the window; anything outside the window or above the limit needs a supervisor.
The agent has access to six tools: read the ticket, look up the customer, get the order and shipment, retrieve the policy, check refund history, and create a refund or store credit. It can also post an approval request to a supervisor queue (for example, a Slack channel or a helpdesk view) and update the ticket. Anthropic's guide singles out support as a natural fit because interactions follow a conversation but need "access to external information and actions," and because success can be measured through user-defined resolutions.
The point of walking the case step by step is that each step creates a record. Those records are what a team logs in production, replays in evaluation, and, when they come from another company, licenses.
Step by step: the refund exception as an agentic workflow#
Each row is one step: the tool call the agent makes, the decision it faces, what forces an escalation, which fields a human fills when they intervene, and the outcome label you record for evaluation. Tool names are generic; map them to your own systems.
| Step and agent action (tool call) | Decision point | Escalation trigger | Human intervention fields | Outcome label |
|---|---|---|---|---|
| 1. Intake: get_ticket(ticket_id), classify intent and urgency | Is this a refund or exception request, or another queue? | Legal threat, chargeback mention, safety or injury claim | reviewer_id, route_override, override_reason | intent_correct (yes or no), route_correct |
| 2. Identify: lookup_customer(email), get_order(order_id) | Does one order match the customer and the claim? | No match, or more than one plausible order after one clarifying question | verified_by, verification_method, corrected_order_id | order_matched, clarifying_turns |
| 3. Evidence: get_shipment(order_id), ask customer for a photo | Is the damage claim supported? | No evidence after two requests, or photo does not match the item | evidence_accepted (yes or no), reviewer_note | evidence_status |
| 4. Policy: get_policy(section returns), compute days since delivery | In policy, exception, or not eligible? | Outside the window (41 days versus 30) routes to the exception path | policy_exception_granted, exception_basis | policy_path (in_policy, exception, ineligible) |
| 5. Risk: get_refund_history(customer_id) | Do prior refunds or account flags change the remedy? | Refund count above the team's threshold, or an account flag | risk_override, risk_reason_code | risk_flag_raised, risk_flag_correct |
| 6. Propose: draft remedy options and check them against policy | Full refund, partial refund, replacement or store credit? | Amount above the $100 limit or any policy exception | n/a (proposal only) | proposed_remedy, proposed_amount, policy_check_passed |
| 7. Approve: post_approval_request(summary, evidence, proposal) and pause | Wait for a human decision | Always, on this path; also on timeout | approver_id, decision (approve, modify, reject), final_amount, reason_code, decided_at | approval_decision, agent_proposal_matched_human |
| 8. Execute: create_refund(order_id, amount, idempotency_key) or issue_store_credit | Did the action succeed? | Tool error after one retry, or a result that does not match the request | manual_action_taken, manual_reference | action_status, tool_errors |
| 9. Close: update_ticket(status, tags, internal_note), send_reply | Does the reply match the decision, policy and tone standard? | Output check fails, or customer disputes the outcome | edited_reply, edit_reason | resolution_code, reopened_within_7_days, csat, later_chargeback |
Which agentic design patterns does this example use?#
The refund case uses all five workflow patterns Anthropic describes, plus a model-directed loop inside the investigation steps. Naming them helps a team decide where code should stay in control and where the model can choose.
- Routing (step 1): classify the request and send it to a specialized path. Anthropic recommends routing when there are "distinct categories that are better handled separately." The OpenAI Agents SDK expresses the same idea as handoffs, using a support app with order-status, refund and FAQ agents as its example.
- Prompt chaining (steps 2 to 4): each step consumes the previous step's output. Use it when a task can be decomposed into fixed subtasks, and add a code check between links (for example, stop if no order matched).
- Parallelization (steps 4 and 5): policy lookup and refund history do not depend on each other, so they can run at the same time (sectioning). For a high-stakes classification such as a fraud signal, running the same check several times and comparing answers (voting) raises confidence.
- Orchestrator-workers: if one ticket covers several items with different problems, an orchestrator splits the case into sub-tasks per item and combines the results. Anthropic reserves this for tasks where you cannot predict the subtasks in advance.
- Evaluator-optimizer (steps 6 and 9): one model call drafts the remedy or reply, another checks it against written policy and tone rules, and the draft is revised until it passes. This works when the evaluation criteria are clear.
- Agent loop (steps 2 and 3): when the evidence is incomplete, the model decides whether to ask the customer, check tracking again, or escalate. A step cap and a clarifying-question limit keep the loop bounded.
Where should humans step into an agentic workflow?#
Put a human gate in front of any action that moves money, cannot be easily undone, or applies an exception to policy, and record what the human decided as structured data. Anthropic's guide describes agents that "pause for human feedback at checkpoints or when encountering blockers" and recommends stopping conditions such as a maximum number of iterations.
Frameworks now build this in. The OpenAI Agents SDK lets a developer mark a tool as needing approval, either always or by a function that decides per call. When approval is needed, the run pauses with the pending tool name and arguments, a person approves or rejects, and the run resumes from saved state. Guardrails in the same SDK check input before the agent runs and output after it finishes, and halt execution when a check trips.
The design mistake to avoid is treating the human step as a free-text comment. If the approver changes $180 to $120 store credit, that edit is the most valuable evaluation signal in the whole trace: it shows exactly where the agent's judgment differed from policy as applied by a person. Capture the decision, the modified values and a reason code from a fixed list.
- Money and irreversible actions: refunds, credits, cancellations, account closures.
- Policy exceptions: anything outside written thresholds or windows.
- Low confidence: identity or order not matched, conflicting evidence.
- Risk signals: chargeback mentions, legal threats, safety claims, fraud flags.
- Operational limits: step cap reached, repeated tool errors, approval timeout.
- Customer request: the customer asks for a person.
When should you not use an agentic workflow?#
Do not use an agent when a rule, a single model call or a fixed workflow already solves the problem reliably. Anthropic's advice is to find "the simplest solution possible, and only increasing complexity when needed," and it notes that optimizing single LLM calls with retrieval and in-context examples is usually enough.
In the refund example, in-window refunds under the limit with a matched order may need no agent at all: a helpdesk rule plus a single drafting call is cheaper and easier to audit. The agentic path earns its cost on the exceptions, where cases vary and someone has to investigate.
- The decision is fully determined by structured fields and stable rules.
- You cannot give the system safe, scoped tool permissions, or test it in a sandbox first.
- You cannot define what a correct outcome is, so you cannot grade it.
- Errors are costly and you have no human review step to catch them.
- Latency or cost per case matters more than handling the long tail of exceptions.
What should an agentic workflow trace record contain?#
A trace should let someone reconstruct what the agent saw, what it did, why, who intervened and how the case ended. Anthropic's evaluation guide defines a transcript (also called a trace or trajectory) as "the complete record of a trial, including outputs, tool calls, reasoning, intermediate results," and the outcome as the final state in the environment. The minimal field list below covers both, at the level of detail a team could log in production or specify when licensing workflow records.
| Field group | Minimal fields | Why it matters for evaluation | Example value |
|---|---|---|---|
| Run metadata | run_id, workflow_version, model_id, prompt_version, started_at, ended_at | Lets you compare versions and reproduce a run | wf-refund v3, prompt r12 |
| Task input | channel, customer_message, ticket_id, linked order_id (pseudonymized) | Defines the task the agent was given | email; order 7731 (pseudonymized) |
| Step record | step_index, step_type (route, lookup, decide, act, reply), timestamp | Orders events and measures extra or missing steps | step 4, decide |
| Tool call | tool_name, arguments, call_id | Checks the right tool was used with valid arguments | get_policy(section returns) |
| Tool result | call_id, status, returned fields or error code, latency_ms | Separates tool failures from model mistakes | ok; window_days 30 |
| Decision and rationale | decision, short rationale, policy_reference, confidence if used | Shows whether the agent applied the right rule | exception path; policy 4.2 |
| Escalation | trigger_type, triggered_at, queue, summary_sent | Measures escalation precision and missed escalations | policy_exception; supervisor queue |
| Human intervention | actor_role, decision, changed_fields, reason_code, decided_at | Captures the corrections that grade agent judgment | modify; 180 to 120 credit; partial_damage |
| Outcome | final_action, amount, resolution_code, customer_reply_sent | The end state graders compare to the expected result | store_credit 120; resolved |
| Post-outcome labels | reopened, csat, chargeback_within_60_days, qa_review_score | Shows whether a resolved case stayed resolved | not reopened; csat 4 |
How do you evaluate an agentic workflow with these records?#
Evaluate the end state first, then use the trace to explain failures. Anthropic's guide defines a task as a single test with defined inputs and success criteria, a trial as one attempt, and a grader as logic that scores some aspect of performance. It warns that checking that the agent followed specific steps is too rigid and that it is usually better to grade what the agent produced, not the path it took.
For support agents, consistency matters as much as average success. Anthropic distinguishes pass@k (at least one success in k attempts) from pass^k (all k trials succeed). The tau-bench benchmark, which simulates conversations between an LLM-played customer and an agent that has domain API tools and written policy, reports pass^1 through pass^4, and its scores fall as k rises. Its successor, tau2-bench, defines each domain by a policy, a set of tools, a set of tasks and optional tools for the simulated user.
Historical tickets make strong tasks because the outcome is already known, but only if exceptions are well represented. A task set made only of easy in-policy refunds will flatter any agent. Anthropic's guide also stresses reading transcripts: you will not know if graders work unless you read transcripts and grades from many trials.
- Outcome correctness: final action and amount match the expected resolution.
- Policy compliance: no action outside written limits without approval.
- Escalation precision and recall: escalated when it should have, and not otherwise.
- Human override rate: share of approvals the human modified or rejected, by reason code.
- Tool reliability: tool error rate and recovery after errors.
- Durability: reopen and chargeback rates after closure.
- Cost and latency per resolved case, compared with the non-agent path.
Where do teams get workflow records to build and test agents?#
Most teams start with their own helpdesk, order and payment history, then add records from other companies when they need more exceptions, other industries or a held-out test set. Historical tickets are not agent traces: they record what human staff did, usually across several systems, and rarely log tool calls. They do contain the parts that are hardest to synthesize, such as real exceptions, approvals, reason codes and outcomes, which is why linked ticket, order and refund records are useful for building tasks and graders.
When records come from another company, four questions are separate: whether someone can technically access and export the data, whether privacy law and notices permit the intended use, who owns the records, and whether a contract grants the right to use them for AI training or evaluation. De-identification reduces privacy risk, but it does not by itself create a right to license. Counsel should review the specific facts.
SourceX runs sourcing and qualification, rights review, contracting, data preparation, delivery and payment for businesses that license operational data to AI developers. For buyers, datasets are sourced on request from U.S. businesses rather than held in stock; you describe the scope, volume, language, format, timing and licensing terms you need. Supplying companies approve exactly what is released before anything is shared, and de-identification is performed by SourceX directly or through its processing partner.
Frequently asked questions
What is an example of an agentic workflow?
A support refund exception is a clear example. The system reads the ticket, looks up the customer and order, checks the return policy and refund history, proposes a remedy, pauses for supervisor approval when the case is outside policy, issues the refund through a payment tool, and closes the ticket. The model decides some of those steps; code and people set the limits.
What is the difference between generative AI and agentic AI?
Generative AI produces content, such as text or images, in response to a prompt. Agentic AI uses a generative model to pursue a goal over several steps, calling tools that read or change real systems and using the results to choose its next action. An agentic system is built on generative models, but adds tools, a loop and stopping rules.
Is a chatbot an agentic workflow?
Not by default. A chatbot that answers questions one turn at a time, even with retrieval, does not act on systems or plan steps. It becomes part of an agentic workflow when it can call tools, such as looking up an order or creating a refund, and decide what to do next based on the results.
What is the difference between an AI agent and an agentic workflow?
In Anthropic's terms, a workflow runs models and tools through predefined code paths, while an agent lets the model direct its own process and tool use. Agentic workflow is often used loosely for both. Most production systems combine them: fixed steps where the process is known, and model-directed loops where cases vary.
What data do you need to evaluate a customer support agent?
You need tasks with known correct outcomes, the policy the agent must follow, and traces of each attempt: tool calls, results, escalations, human decisions and the final state. Historical tickets linked to order and refund records are a good source of tasks, as long as exceptions and escalations are well represented.
Should every refund go through human approval?
No. Approval gates belong on actions that move money above a set limit, cannot be undone, or apply a policy exception. Routine in-policy cases can run without a person, while every human decision on the gated cases is logged with a reason code so it can be used to evaluate and improve the agent.
Sources
- Anthropic distinguishes workflows (LLMs and tools orchestrated through predefined code paths) from agents (LLMs dynamically directing their own processes and tool usage), describes prompt chaining, routing, parallelization (sectioning and voting), orchestrator-workers and evaluator-optimizer, advises starting with the simplest solution, notes higher costs and compounding errors, recommends checkpoints, stopping conditions and extensive testing in sandboxed environments, and discusses customer support as a fit for agents. Source
- Anthropic's agent evaluation guide defines task, trial, grader, transcript (trace or trajectory), outcome and evaluation harness, describes pass@k and pass^k, calls checking specific step sequences too rigid and recommends grading what the agent produced rather than the path, stresses reading transcripts, and cites refunds, cancellations and escalations as support eval coverage. Source
- With client tools, the model responds with a tool_use block and stop_reason tool_use, the application executes the operation, and sends back a tool_result the model uses for its next step. Source
- The ReAct repository (ReAct: Synergizing Reasoning and Acting in Language Models) describes its code as accompanying an ICLR 2023 paper, with experiments on HotpotQA, FEVER, ALFWorld and WebShop. Source
- tau-bench emulates dynamic conversations between an LLM-simulated user and a language agent with domain-specific API tools and policy guidelines, in retail and airline domains, and reports pass^1 through pass^4. Source
- tau2-bench defines each domain by a policy the agent must follow, a set of tools, a set of tasks and optional user tools, with domains including airline, retail, telecom and banking_knowledge. Source
- The OpenAI Agents SDK describes handoffs as delegating tasks between agents, using a customer support app with order status, refund and FAQ agents as its example, and presents each handoff to the model as a tool. Source
- The OpenAI Agents SDK human-in-the-loop feature lets a tool require approval always or per call, pauses the run with pending interruptions, records approve or reject decisions, and resumes from saved state. Source
- The OpenAI Agents SDK runs input guardrails on the initial user input and output guardrails on the final agent output, and halts execution when a guardrail tripwire is triggered. Source
Related resources
Tell us what data you need
Share scope, volume, format, timing and licensing needs. Datasets are sourced on request.