When the workflow is known, don't let the agent invent the route

Call her Maria, because this is a composite, not a reported incident: the kind of miss that turns up wherever a refund workflow runs on an agent instead of a graph. She finds it three weeks later, during reconciliation, doing the kind of spreadsheet work nobody thanks you for. A customer got refunded twice, a little over $200 both times. The case looks clean on replay: purchase history pulled, complaint read, refund issued through Stripe, a warm confirmation email sent, apologizing for the wait. What's missing is one line in the CRM. The ticket was never marked resolved, so when the same complaint drifted into a different queue nine days later, a fresh agent instance found no closed case, saw only an open one, and did the whole job again.

Nobody had written a bad prompt. The instructions were numbered and specific: pull the order, read the complaint, check the refund policy, issue the refund, send confirmation, close the ticket. A person reading those six lines would never skip the last one. The agent skipped it anyway, and it took a human noticing a duplicate transaction to catch it.

That gap between "the steps are written down" and "the steps are enforced" is the whole argument in this piece. The prompt is not the process.

Numbered steps are a suggestion, not a runtime

Google engineers Swapnil Agarwal, Alan Blount, and Frank Guan named this exact failure pattern in "Why we built ADK 2.0," published July 1: "Moving AI Agents from prototype to production creates new challenges. In real-world enterprise environments, agents can get stuck in infinite loops, bypass key business logic due to hallucinations, or fail without raising clean exceptions."

Their diagnosis is structural, not a call for better prompt engineering: "The core issue is structural. Large language models are frequently tasked with execution orchestration—handling tasks like routing, scheduling, and error handling that traditional code already excels at."

A prompt that reads "Step 1: Do X. Step 2: Do Y." looks like a program. It isn't one. The post is blunt about what that phrasing actually produces: the model is left to orchestrate execution dynamically, deciding in the moment whether step 2 really needs step 1's output, whether a failed call means retry or move on, whether an ambiguous complaint means escalate or resolve. Every one of those decisions feels reasonable to the model in isolation. None of them is guaranteed to match what the business actually requires.

Google's fix in ADK 2.0 is a structured workflow runtime and task-collaboration model built around one design idea: "Workflows separate execution routing from language processing." Routing (the sequence, the branching, the retries, the handoffs) becomes code the application enforces. Language processing (reading a messy complaint, weighing whether a policy applies, drafting a reply) stays with the model, in the places where judgment is actually needed. The post's own test for which is which: "Before building an autonomous agent, ask if an agent is actually the right tool for the job. If you can clearly map the workflow, use determinism."

Google's own example is the refund workflow

The ADK 2.0 post is worth reading past its launch framing, because Google's own worked example is the abstract version of what just happened to Maria. Google maps a refund-and-support workflow across five nodes: a tool call to fetch purchase history, an LLM agent to analyze the complaint and any policy ambiguity, a tool call to issue the refund through the Stripe API, an LLM agent to draft the confirmation email, and a tool call to update the CRM and close the ticket.

Laid out as a graph instead of a paragraph of numbered instructions, the sequence stops being negotiable. Node E, updating the CRM, isn't a suggestion the model can deprioritize after drafting a nice email. It's the edge the graph requires before the workflow counts as finished. There's no path back from a closed complaint to a second refund, because that edge was never drawn.

Google reports illustrative benchmark numbers for that mock refund graph, run against Gemini 3.5 Flash with mock API responses: token usage dropped from 5,152 to 2,265, and latency from 7.2 seconds to 5.7 seconds. Google flags these as illustrative, not a universal claim, and that caveat is worth keeping. Your own numbers will depend on your model, your tools, and the shape of your workflow. What generalizes better than the specific figures is the mechanism behind them: a model that isn't re-deciding "what do I do next" at every turn spends fewer tokens re-explaining the plan to itself, and a graph structure gives prompt injection fewer places to hide, since there's no edge or node for an action nobody designed in.

The mechanics ship in ADK 2.0's Go SDK, which reached v2.0.0 on June 30, 2026, with a graph-based workflow engine and built-in human-in-the-loop support. Agents, tools, and functions become nodes in a directed graph, wired with conditional routing, fan-out/fan-in, parallel workers, retries with timeouts, schema validation, and approval checkpoints. The Python SDK followed similar ground, reaching v2.3.0 on June 18 with expanded telemetry around agent invocation and tool-call metrics: the instrumentation a team needs to actually see whether a routed step ran, and how long it took.

Route every step before you touch a runtime

You don't need to adopt ADK to steal the discipline behind it. The question worth answering before any workflow runtime touches production, Google's or anyone else's, is narrower than "agent or workflow." It's a decision made once per step: does this belong to code, to the model, to a person, or should it stop the workflow outright?

That's the Agent Workflow Boundary Map. Not a diagram of what the agent can do. A record of who routes each step before the system runs unattended.

Fill the map before the workflow runs unattended

Scroll sideways to see all 8 columns.

Step	Routes to	Retry owner / limit	Exception path	Checkpoint	Idempotency guard	Log destination	Rollback / stop rule
A. Fetch purchase history	Code (tool call)	System, 3 retries, then stop	Escalate to support lead if the order API fails twice	After fetch, before analysis	Read-only, no guard needed	Order service log	N/A, no side effects yet
B. Analyze complaint and check policy	Model (LLM reasoning)	No auto-retry on reasoning output	Route to a human reviewer when confidence is low or the policy is ambiguous	Before refund step fires	N/A	Support case log	Stop if the ambiguity flag is set
C. Issue refund via Stripe	Code (tool call), gated above a dollar threshold	System, 1 retry with idempotency key, then stop and alert	Alert finance lead; never blind-retry a payment call	After Stripe confirms the transaction	Stripe idempotency key tied to the case ID	Payments log, immutable	Reverse the charge if Stripe succeeds but the CRM step never confirms
D. Draft confirmation email	Model (LLM reasoning)	No auto-retry	Route to a human before send if drafting fails	After draft, before send	N/A	Support case log	Do not send unless step C is confirmed
E. Update CRM and close ticket	Code (tool call)	System, 3 retries, then escalate to ticket owner	Escalate to the ticket owner if the update fails after retries	Final; the case isn't closed until this log entry exists	Ticket ID as the idempotency key	CRM audit log	The workflow isn't "done" without this entry, regardless of what earlier steps reported

Workflow name and business owner: name both on the same line as the map, for example "Refund resolution, owned by the support ops lead," not filed separately where nobody checks it before a launch review.

Test case proving no skipped step: replay the case with Stripe returning a timeout on the first call, and assert the CRM update fires exactly once, only after the refund is confirmed, never after the email draft, never twice.

The field most teams leave blank is the idempotency guard, and it's the one that would have caught Maria's duplicate refund. A workflow that can't tell "this case already ran" from "this case looks like the last one" will happily run the refund twice, cheerfully, with a nice tone in both emails. The guard isn't a nice-to-have bolted onto step C. It's the difference between a routed step and a step the model is trusted to remember on its own.

A separate note on state, not routing

The same week Google published the ADK post, its team also wrote about building agentic full-stack apps with Genkit, describing an agent object that can hand back a one-shot reply, a streamed turn, a paused tool call, or a multi-turn conversation. Every successful server-managed turn writes a snapshot, so the app can resume by session ID or branch into a new path by snapshot ID.

That's a genuinely different question from the boundary map, and worth keeping separate rather than folding into one "agent reliability" bucket. The boundary map decides who routes each step before the workflow starts moving. What happens while a routed step is still waiting on a person, a vendor, or a timeout is its own contract. Which agents are even allowed to call each other is a third question. And what happens after a step already ran and needs to be undone is a fourth. Four different artifacts, because four different failures show up in the same production incident review, and conflating them is how a postmortem turns into an argument about vibes instead of a fix.

Before the next workflow goes live

Pick one workflow currently running with a numbered prompt instead of an enforced graph. For each step, write down whether it belongs to code, the model, a person, or a stop rule. Name the retry owner and limit. Name the exception path. Mark the checkpoint where state gets saved. Add the idempotency guard before the second Stripe call happens, not after Maria finds it.

Then decide whether ADK 2.0, another graph runtime, or your own routing layer should enforce what the map says.

Bring us one workflow that already runs mostly right and fails on the same step or two. BaristaLabs can help map which parts belong to code, which belong to the model, which need a person, and which should stop the workflow cold, as part of process automation grounded in AI workflow controls. The map is worth finishing before the runtime is worth choosing.