Agentic AI Workflows as a Delivered Capability

Why agentic AI is the next capability.

Generative AI writes the paragraph. Agentic AI processes the refund. That is the difference, and it is the whole reason this pillar exists as a separate capability from every other AI thing your organization is already doing.

A generative AI system produces an output when you ask it a question. It is fundamentally one shot: prompt in, response out, end of transaction. An agentic AI system decides what to do next, calls a tool, checks the result, decides what to do after that, and keeps going until the task is complete or it hits a stopping condition it recognizes. The loop is the whole point. When it works, the agent moves the work forward on its own rather than producing text that a human then has to act on.

That difference is what makes agentic AI both more valuable and dramatically harder to ship reliably. A generative demo fails in a way the user can see and correct: the paragraph is wrong, you edit it, you move on. An agentic failure fails silently: the refund got processed on the wrong customer, or the case got closed with the wrong resolution, or the calendar got booked twice. The blast radius of an agentic mistake is larger than a generative one, which is why the discipline underneath a production agentic build is qualitatively different.

This guide is the playbook for what agentic AI looks like when it works. The five stages, the architecture patterns, the framework choices, the governance rails that make autonomy safe, the evaluation harness, and the discovery sprint that de-risks the build. It sits alongside the other pillars in this series: AI-Ready Data, RAG and Knowledge Systems, Agent Assist, Case & Ticket Triage, Voice AI, and Governance & ATO. Agentic workflows sit on top of nearly every capability in that list, which is why we treat it as the last pillar in the series rather than the first.

The five stages of the agent loop.

Every credible production agent runs through the same five-stage loop. The loop is the whole capability. Get any one of the stages wrong and the agent fails in ways that are hard to debug because the bad output looks plausible.

Two things run alongside every stage. First, an evaluation harness that scores the agent on a labeled set of representative tasks: task completion rate, tool-choice accuracy, invariant violations caught, plans that stayed on track, plans that drifted, escalations that happened when they should have, escalations that were missed. The evals run on every meaningful change to the prompt, the tool set, the model, or the guardrails. Second, a tracing and observability layer that captures the full step-by-step trace of every production run: what did the agent decide, what tools did it call, what came back, what was the final outcome. Tracing is the difference between debugging an agentic failure in minutes and never being sure what went wrong. LangSmith, Arize, Braintrust, Weights & Biases Weave, LangFuse, and platform-native tracing in Bedrock and Azure AI Foundry are the production choices for this.

Architecture: single, multi, hierarchical, hybrid.

Agent architectures fall into four broad patterns. Most production builds use one; some combine two. The task shape picks the pattern, not the framework.

Single agent

One LLM in the loop, one set of tools, one continuous task. The right pattern for the majority of production agentic builds because the coordination overhead of anything else is not free. A single agent can be surprisingly capable when its tool set is well-designed, its planning is explicit, and its guardrails are strong. Most contact-center agent-assist workflows, most case-triage sub-tasks, and most in-app assistants are single-agent shaped underneath. Reach for this pattern first; only add complexity when the task really needs it.

Multi-agent (peer-to-peer)

Two or more agents with distinct specializations coordinating on a task. Common patterns: a researcher agent that gathers information and a writer agent that composes the output, a planner agent that decomposes tasks and worker agents that execute the pieces, a critic agent that reviews another agent's work before it commits. Multi-agent buys reliability through diversity and specialization; it costs latency, cost per task, and evaluation complexity. Right when the sub-tasks are genuinely different in shape (research vs synthesize vs verify), less right when the specialization is cosmetic.

Hierarchical (orchestrator + workers)

A senior orchestrator agent that plans the overall task and delegates each step to a worker agent (or a deterministic function). The orchestrator maintains the plan, the state, and the summary; the workers execute their piece and report back. Right for larger tasks that decompose cleanly into 5 to 20 discrete steps. Anthropic's guidance on building effective agents leans toward this pattern for most complex tasks because the state-management burden lives in one place. Some framework support is stronger for hierarchical patterns than for flat multi-agent (LangGraph, AutoGen, Bedrock AgentCore).

Hybrid (deterministic outer, agentic inner)

The pattern we recommend most often for enterprise workloads. A deterministic outer workflow handles the parts that are stable and known (routing, authentication, logging, permissioned actions). An agentic sub-step handles the parts that are open-ended (interpreting a customer message, deciding what information to gather, composing a personalized response). The determinism gives you predictable behavior, easy audit, and low latency on the common path; the agentic inner sub-step gives you the flexibility to handle the long tail without hand-coding every branch. Contained inside a fixed budget of iterations and tool calls, the hybrid pattern is the most production-safe way to introduce agentic behavior into a mature workload.

Rough distribution of what we ship: single agent inside a deterministic outer flow is about 50 percent of what we build. Hierarchical orchestrator plus workers is about 30 percent. Pure single-agent is about 15 percent. Peer-to-peer multi-agent is about 5 percent, mostly for research and writing workflows. The framework choice matters far less than the pattern choice.

Framework and platform choices.

The framework layer changes fast. As of mid-2026 the production choices sort into four camps. Framework choice matters less than most vendors want to convince you it does; the underlying discipline (planning, tool design, guardrails, evals) is portable. Pick against your platform stack, your team's existing skills, and your governance posture.

Open-source graph and role-based frameworks

LangGraph (LangChain) is the most mature production choice for graph-based orchestration. Strong state management, first-class human-in-the-loop support, deep tracing via LangSmith, and a clear pattern for hierarchical designs. AutoGen (Microsoft) is strong on multi-agent conversation patterns and has the tightest integration with Semantic Kernel. CrewAI is easier to start with and good for role-based agent teams. Pydantic AI is the right choice when strongly-typed tool interfaces and clean Python integration matter more than orchestration graph richness. DSPy is worth considering when you want to program agents declaratively and let the framework optimize prompts against evals.

Model-provider agent APIs

Anthropic Claude tool use and the newer Claude Agent SDK handle the loop for you against Claude models with clean structured tool calls, cache-aware pricing, and long-context handling. OpenAI Assistants API and Responses API serve the same purpose against OpenAI models. Both trade framework portability for a working loop out of the box; both are the fastest path to a first working agent when your organization has already committed to one of the model providers.

Cloud-native agent platforms

AWS Bedrock AgentCore is the right answer for AWS-first organizations and for federal builds. Handles orchestration, memory, tool registration, tracing, and evaluation with FedRAMP High authorization in GovCloud. Native integration with the rest of the Bedrock knowledge-base and guardrail primitives makes hybrid RAG-plus-agent patterns natural. Azure AI Foundry Agents plays the same role in the Microsoft ecosystem, with FedRAMP High in Azure Government and native integration with Azure OpenAI, Azure AI Search, and Semantic Kernel. Google Vertex AI Agent Builder plays it in the Google ecosystem. Databricks Agent Bricks is the natural choice when Databricks is already the data and model platform. Salesforce Agentforce and ServiceNow AI Agents are the choice when the workload lives inside those specific application platforms and integration cost is the dominant factor.

Self-hosted open-weight stacks

When the workload cannot leave your network and none of the managed options fit. vLLM or Text Generation Inference for model serving. Llama 3.1 / Llama 4, Qwen 2.5, or Mixtral for the model layer. LangGraph or Pydantic AI for orchestration. Higher engineering cost, full data sovereignty, no per-token fees at scale, thinner tool-use quality than the closed-model options on complex agentic tasks. Right for the small share of workloads where those trade-offs pencil out.

The portability point: your tool contracts, your evaluation harness, your prompt templates, and your guardrail rules should outlast a single framework choice. The framework is replaceable within a couple of engineering weeks if the underlying discipline is intact. Do not build the discipline around the framework; build it around the tasks the agent is doing.

Deterministic first, agentic on fallback.

This is the single design principle that separates the agentic builds that ship reliably from the ones that show well in a demo and stumble in production. It is worth its own section because most teams get the trade-off wrong on the first attempt.

Deterministic code is faster, cheaper, more predictable, easier to test, easier to audit, and easier for the humans on your team to maintain. Agentic behavior is more flexible, handles the long tail without hand-coding, and adapts to inputs the deterministic code never anticipated. The right architecture uses each where it earns its keep.

For any given task, ask this: if the same inputs came in a thousand times, would you want the system to do exactly the same thing every time? If yes, code it. Deterministic. If no, and the variation is meaningful, agentic. In practice this means the outer flow, the routing, the authentication, the logging, the permissioned writes, and the standard business rules are all deterministic. The agentic surface is scoped to the actual open-ended judgment steps: interpreting the customer's message, choosing which follow-up questions to ask, composing a personalized response, deciding whether the situation fits the standard playbook or needs escalation.

The rails around the agentic surface make the pattern work: bounded iterations, bounded tool call counts, bounded token spend, invariant checks between steps, guardrails on inputs and outputs, human approval gates for actions above a defined risk threshold. When the agent works, you get flexibility. When the agent hits the boundary of its judgment, the system escalates cleanly instead of failing silently.

Governance, safety, and human-in-the-loop.

Agentic systems concentrate risk because they act on the world instead of producing text. The governance posture is shape-of-architecture, layered by design, and it is what separates a production build from a demo.

Tool scoping.

The most powerful governance lever is which tools the agent has access to. An agent that cannot call the delete endpoint cannot delete anything. Tools are permissions; scope them like permissions. Different agents can have different tool sets. Different users of the same agent can gate different tools. Least-privilege applies here the same way it does to any other authorization design.

Approval gates for high-stakes actions.

Above a defined risk threshold, the agent proposes and a human commits. What counts as high stakes is a business decision, not a technical one: refunds over a dollar threshold, changes to permissions, message sends to external parties, actions that affect regulated records. The approval interface should show the human the agent's plan, the observation that led to the proposed action, and one-click approve or reject with reason capture. Approval gates are the single feature that most often lets a workload move from pilot to production.

Guardrails at every step.

Input classifiers to catch prompt injection attempts embedded in tool outputs or retrieved content. Output classifiers to catch policy-violating outputs before they reach the user or the destination system. Bedrock Guardrails, Azure AI Content Safety, Lakera Guard, and open-source options like NeMo Guardrails are the production choices. Guardrails are not bulletproof; they are one layer of a defense-in-depth posture that only works because every layer is doing its job.

Invariant checks between steps.

Business-logic invariants encoded as explicit checks the agent must pass to continue. The balance still adds up. The customer identity has not changed. The total remains under the approved limit. The referenced record still exists in the state the plan assumed. Invariant failures halt the loop and escalate. Invariants are the reason a well-designed agent recovers gracefully from a tool that returned unexpected data; without them the agent proceeds on a stale assumption.

Budget rails.

Every agent run has hard budgets: maximum iterations, maximum tool calls, maximum token spend, maximum wall-clock time. When any budget is hit the agent stops, logs the state, and escalates. Budgets are the reason a stuck agent does not become a runaway cost or an infinite loop. Sensible defaults: 15 to 30 iterations for most enterprise agents, hundreds of tool calls only for research-shaped tasks, wall-clock caps aligned to the user's tolerance for latency.

Tracing and audit.

Every step of every run captured with timestamp, identities, tool call, argument, output, decision. The trace is the artifact that lets a reviewer debug a failure, an auditor verify a compliant outcome, and an eval author extend the eval set based on real production behavior. Traces feed forward into eval expansion, prompt improvements, and regression detection. A production agent without a trace is a black box you cannot govern.

Federal and regulated workloads.

Everything inside the FedRAMP-authorized boundary for federal workloads: Azure Government, AWS GovCloud, or Google Cloud Assured Workloads. NIST AI RMF Map, Measure, and Manage functions apply directly to the tool set, the guardrails, the human-in-the-loop design, and the incident response process. HIPAA workloads run every component under BAA. See our Governance & ATO pillar for the full federal compliance layer including impact assessments, eval pack contents, and ongoing monitoring.

When this is the right capability.

Agentic AI workflows as a delivered capability pay off when the conditions below are met. Not all need to be true, but the more, the better.

• The task is multi-step and the sequence varies. If the flow chart branches unpredictably based on what the system finds, and the branching is expensive to hand-code, an agent inside a deterministic outer flow is the shape.
• The tools already exist as APIs. Well-defined endpoints for the reads and writes the agent will need to perform. Retrofitting an agent onto legacy screens that require RPA is possible but doubles the build cost; API-native workflows are dramatically easier.
• The task volume is meaningful. Hundreds of tasks per day or more. Below that, the operating cost and complexity often does not pencil out against a simpler hand-coded or human-in-the-loop shape.
• Deterministic code has been considered and rejected on merits. The team has looked at "just write the workflow" and can articulate why the flexibility is worth the complexity for this specific task.
• Failure modes are recoverable and non-catastrophic. When the agent gets it wrong, the human catches it, undoes it, and life goes on. Not "the agent accidentally emailed the customer list to an external address."
• Human approval gates are acceptable at high-stakes moments. The user experience can tolerate a "review this and approve" step above a risk threshold. This makes agentic workloads viable in domains that otherwise would not accept the residual failure rate.
• You have or can build the eval infrastructure. A labeled task set the agent can be measured against, and a team to keep the eval set current as the task evolves. Without evals, agents do not stay in production long.

When it is not the right answer.

We say no to roughly one in three agent conversations. The reasons repeat.

• The flow chart fits on one page. A deterministic workflow is faster, cheaper, more reliable, and easier for your team to maintain. Bringing an agent to a fixed-flow problem trades reliability for the cost of tokens.
• The stakes are too high for anything but a human. Actions that cannot be undone, affect large numbers of people, or carry criminal or regulatory exposure that a residual error rate cannot survive. Agent Assist beside a human is the shape for these workflows; the human commits.
• The tools are legacy screens, not APIs. If everything the agent needs to do runs through RPA against screens that change monthly, the RPA maintenance burden usually swamps the AI benefit. Fix the API layer first.
• Task volume is too small. A few dozen tasks a day are usually better served by a human with an AI assist tool than by a full agentic workflow. The build and operation cost per task does not amortize.
• Compliance posture is unresolved. If the organization has not decided how it treats autonomous actions in regulated workflows, the build is downstream of that decision, not upstream of it.
• There is no eval and no plan to build one. Programs that fund the build but not the eval set and the ongoing improvement loop end up with an agent that stagnates at its first-month accuracy number and quietly gets rolled back.

Saying no at the discovery stage is cheaper than discovering it after the build. The discovery sprint exists partly to catch these conditions.

ROI and what agents actually return.

Agentic AI ROI is task-specific because the value depends on what the agent replaces. The ranges below are the ones we see across contact-center, back-office, and knowledge-worker deployments. Numbers assume the deterministic-first, agentic-on-fallback design principle is followed.

The number that most often drives the business case is autonomous task completion rate. The important qualifier: task completion measured against a labeled eval set, not against "did the agent produce an output." An agent that produces the wrong output confidently is a failure regardless of how good the output looks. Programs that measure completion against ground-truth outcomes hit the ROI. Programs that measure surface signals (did the agent respond, did the ticket close) plateau early and often ship regressions without noticing.

The other number worth mentioning: reviewer time per escalation. Agents that escalate cleanly with a good summary, the observed state, and the proposed action reduce reviewer time by 50 to 80 percent versus reviewing raw tickets. That number often exceeds the direct-cost savings of the agent's autonomous completions because it compounds across every human in the loop.

Buyer's checklist.

If you are evaluating an agentic AI build or vendor, the questions below separate production-ready answers from "we wired up an LLM to some tools." Use the list verbatim in a vendor conversation; the ones who cannot answer nine of eleven crisply are not shipping this work.

1. Show me the five-stage loop. Plan, act, observe, decide, commit. All five, with named artifacts and a comparable production reference.
2. What is the deterministic-vs-agentic split for our workload? Which parts stay deterministic, which parts are agentic, and why.
3. How many tools does the agent have access to, and how did you pick that set? Tool contracts, typed inputs and outputs, error semantics.
4. What planning pattern? Implicit, explicit up-front plan, ReAct-style step-by-step, hierarchical. Why this pattern for this task.
5. What are the invariants that are checked between steps? Business-logic-specific. How does the agent recover when an invariant fails.
6. What are the budget rails? Max iterations, tool calls, tokens, latency. What happens when a budget hits.
7. What are the guardrails? Input classifiers, output classifiers, prompt injection defense, policy checks. Named products.
8. Where are the human approval gates? Which actions require human approval and what does that interface look like.
9. What is the eval harness? Task completion rate against a labeled set, tool-choice accuracy, invariant-violation catch rate. Who owns it, how often does it run.
10. What is the tracing story? LangSmith, Arize, Braintrust, Weave, LangFuse, Bedrock, Azure. What do the traces look like for a debugging run.
11. What artifacts transfer to our team if we take the build in-house? Prompt templates, tool definitions, eval set, guardrail rules, tracing configuration, runbooks.

Crisp answers to nine of eleven with named tools and specific numbers means the vendor has shipped this work. Fewer than six means you are paying for on-the-job training. The same questions structure the discovery sprint.

What's in the discovery sprint.

The agentic AI workflows discovery sprint runs 3 to 5 weeks and exists to settle the deterministic-vs-agentic split, the tool interfaces, the guardrail design, the evaluation approach, and the operating economics before the production build commits.

What we do during the sprint.

• Task decomposition with your subject-matter experts and operations owners. What actually happens when a human does this today, step by step. What varies. What is invariant. What triggers escalation.
• Deterministic-vs-agentic split. Which parts of the flow stay hand-coded (routing, auth, logging, permissioned writes, standard business rules). Which parts are genuinely open-ended and warrant an agentic surface.
• Tool inventory and design. What APIs already exist. What tools the agent needs. Tool contracts (typed inputs, typed outputs, error semantics). Governance boundaries per tool.
• Assemble a labeled evaluation set of 100 to 300 representative tasks with ground-truth outcomes. This is the artifact all future improvements measure against.
• Build a working prototype: the deterministic outer flow, the agentic sub-step, the tool interfaces, the guardrails, the tracing, the approval gates for high-stakes actions.
• Run the eval harness. Measure task completion, tool-choice accuracy, invariant violations caught, escalations that fired correctly, plans that stayed on track. Compare against the pattern alternatives when there is a real choice.
• Design the human-in-the-loop experience end-to-end. Where the reviewer sees the plan, the observations, the proposed action. What one-click approve, reject, and reason-capture looks like.
• Produce the fixed plan and fixed price for the production build with the rollout staging plan (pilot users, expansion cohorts, autonomy-threshold ramp).

What you walk away with.

• Task decomposition and deterministic-vs-agentic split documented
• Tool inventory with contracts and governance mapping
• Labeled eval set (100-300 tasks) that survives beyond the engagement
• Working agent prototype exercised end-to-end on a representative slice
• Baseline eval numbers for the recommended pattern with delta vs alternatives
• Human-in-the-loop UX designed and prototyped
• Guardrail and budget-rail configuration documented
• Compliance posture write-up for security and legal review
• Fixed plan and fixed price for the production build with staged autonomy ramp

If we are the right partner and the math works, you greenlight the build. If we are not, or if the math does not work, you keep the artifacts. The task decomposition, the eval set, the tool contracts, the prototype, the compliance write-up. You can hand them to another vendor or use them to inform your own work. We have not earned the next engagement and we do not pretend we have.

How it lands per audience.

The five stages, the architecture, and the deterministic-first principle are universal. The shape of the engagement is not. Three audience-specific deep dives are in progress.

Frequently asked.