Agentic Workflow Production vs Development: The Hard Truth About What Breaks
Last quarter, a payments startup came to SIVARO with a demo that made their investors lean forward. Their AI agent could reconcile invoices, chase discrepancies, and flag fraud patterns. Beautiful UI. Smooth chat interface. Perfect responses — in the demo.
Three weeks into production, it had hallucinated a $40,000 credit memo and silently dropped 14 vendor invoices from its queue.
The gap between agentic workflow development and production isn't a gap. It's a canyon. And most teams only discover it after something expensive catches fire.
The Demo Isn't the System
Here's the thing nobody tells you: developing an agentic workflow is building a system that works in your presence. Production is building a system that works in your absence. Those are two different engineering disciplines.
In development, you have one user. You. In production, you have the entire org. In development, your LLM calls return in 900ms. In production, your rate limits spike, your context windows overflow, and your tool calls start returning malformed JSON at 2 AM.
From Proof of Concept to Production: Why Agentic AI Workflows Fail at Scale makes the point bluntly: most agentic POCs fail because they were built to demonstrate capability, not to survive operational reality.
I've seen it repeat. A team builds an agent that handles 3 tasks beautifully. They demo it. Leadership loves it. They ship it. And then the agent faces task #4 — the one nobody thought to include in the eval set — and it does something confidently catastrophic.
The core issue? Development rewards correctness. Production rewards controllability.
What "Production" Actually Means for Agentic AI
Let me define this clearly because the industry is muddy on it.
An agentic workflow in production is a system that:
- Runs continuously without human babysitting
- Handles real-world input variance (garbage in, garbage handled)
- Fails gracefully when tools fail, APIs timeout, or models degrade
- Costs predictable money per transaction
- Can be observed, audited, and rolled back
Development is where you prove it can work. Production is where you prove it continues to work.
Agentic AI Explained: Workflows vs Agents draws a useful distinction: workflows are deterministic paths through predefined steps, while agents dynamically decide their own path. Production reality sits in between. You need workflow structure with agentic flexibility — and that hybrid is where the engineering gets hard.
The Control Flow Problem
Here's what shocked me when we started deploying these systems at SIVARO: your code is not in control anymore.
In traditional software, you write the logic. The program follows it. Deterministic. Testable. Predictable.
In agentic systems, the LLM decides what to do next. You're not writing the logic — you're influencing it through prompts, tool definitions, and system design.
This inversion of control is the fundamental difference between development and production. In development, you can steer. You're in the loop. You see the agent go sideways and you correct it. In production, you're not there. The agent goes sideways at 3 AM and you find out when the CFO's morning report shows a negative balance.
A Practical Guide to Production-Ready Agentic Workflows with ADK and Agent Engine gets at this — production-ready means building guardrails that constrain the agent's freedom without destroying its usefulness.
The pattern that works:
python
# Development pattern - naive approach
def run_agent(task):
response = llm.call(system_prompt, task)
return response
# Production pattern - constrained approach
def run_agent(task):
# Step 1: Classify the task type
task_type = classify(task)
# Step 2: Route to a constrained workflow
if task_type == "invoice_reconciliation":
return reconcile_invoice_workflow(task)
elif task_type == "fraud_flagging":
return fraud_flag_workflow(task)
else:
# Step 3: Only fall back to free-form agentic behavior
# when you're in the blast radius of a human
return escalate_to_human(task)
The agent doesn't get unlimited freedom. It gets bounded freedom. Freedom to make decisions within a structured workflow. That's the production difference.
Agentic Workflow Production vs Development: The Context Problem
In development, context is clean. You write a prompt, you test it with known inputs, and you iterate.
In production, context is a swamp.
Your agent's context window is filling with:
- Historical conversation logs that drift from the original topic
- Tool outputs that include irrelevant data
- User messages that contradict each other
- System prompts that accumulate cruft over time
I had a client whose agent's accuracy dropped 30% over two weeks. The code hadn't changed. The model hadn't changed. The context management had drifted. Old messages were polluting the system prompt, and the agent was "remembering" things that were no longer true.
The six key elements of agentic AI deployment from McKinsey's work with enterprise deployments highlights this exact failure mode. The companies that succeed treat context as a first-class engineering concern, not an afterthought.
Production context management means:
python
# Production-grade context management
class ContextManager:
def __init__(self, max_tokens=8000):
self.max_tokens = max_tokens
def build_context(self, conversation_history, tool_results, user_input):
# 1. Trim old conversation (recency bias is real)
recent = conversation_history[-10:]
# 2. Summarize what's dropped
summary = self.summarize(conversation_history[:-10])
# 3. Only include relevant tool results
relevant_results = [r for r in tool_results if r.relevance_score > 0.7]
# 4. Prioritize system instructions over everything
return f"""
[SYSTEM INSTRUCTIONS - ALWAYS HIGHEST PRIORITY]
{self.system_prompt}
[CONVERSATION SUMMARY - LOW DETAIL]
{summary}
[RECENT CONVERSATION - FULL DETAIL]
{recent}
[TOOL RESULTS - FILTERED]
{relevant_results}
"""
Most development teams don't build this. They just stuff everything into the context window and hope. And it works — in development. Because the conversation is shortcars. There's no history. There's no drift. There's no accumulation of garbage.
Production is where context management becomes the difference between a system that works and a system that hallucinates confidently.
Tools Are the Easy Part. The Interfaces Are Hard.
Everyone talks about tool calling like it's the magic ingredient. "The agent can use your API!" Great. Can it handle your API being down? Can it parse the error message when your auth token expires? Can it recover when a tool returns data in a format the LLM wasn't expecting?
Agentic AI patterns and workflows on AWS describes tool abstraction layers as a core pattern for production agentic systems. And that's the right instinct — but most teams stop at the abstraction. They don't build the failure handling around it.
Here's a tool call in development:
python
# Development: tool call that always works
result = call_invoice_api(invoice_id="INV-1234")
return result
Here's the same tool call in production:
python
# Production: tool call that anticipates failure
def call_invoice_api_with_retry(invoice_id, max_attempts=3):
for attempt in range(max_attempts):
try:
result = call_invoice_api(invoice_id)
# Validate the response shape
if not validate_invoice_schema(result):
raise SchemaError(f"Unexpected shape: {result.keys()}")
return result
except (TimeoutError, RateLimitError) as e:
wait_time = 2 ** attempt # exponential backoff
log_warning(f"Attempt {attempt} failed: {e}")
sleep(wait_time)
except SchemaError as e:
# Try to repair the output
repaired = repair_with_llm(str(result))
if repaired:
return repaired
break
# Last resort: escalate to human
raise ToolFailure(f"Could not retrieve invoice {invoice_id} after {max_attempts} attempts")
That's the production difference. Development handles the happy path. Production handles everything after the happy path breaks.
Cost Isn't a Development Concern. It's a Production Emergency.
In development, you call the LLM 50 times to get one thing right. Who cares? It's $0.50.
In production, your agent handles 10,000 requests a day. If each request takes 15 LLM calls, that's 150,000 calls daily. At $5 per million tokens (mixed input/output), you're looking at hundreds of dollars a day. Thousands a month. And that's for a moderate workload.
I worked with a logistics company in 2025 that deployed an agentic workflow for shipment exception handling. In development, the agent took 6-8 LLM calls per exception. That felt fine. In production, handling 4,000 exceptions daily meant 28,000+ LLM calls per day. Their bill went from $800/month in testing to $37,000/month in production. In two weeks, they'd blown their entire annual AI budget.
The Agentic Workflow Patterns & Best Practices guide for enterprise deployments flags this explicitly: token economics must be part of the architecture, not an afterthought.
The fix isn't just "use a cheaper model." It's restructuring your workflow to minimize calls:
- Cache aggressively — identical requests should never hit the LLM twice
- Use cheaper models for routing — a small classifier can route tasks better than a massive LLM can
- Fall back to deterministic code — don't ask the LLM to do math when you can do it in Python
- Set per-transaction token budgets — hard limits that force the system to be efficient
That last one is critical. If the agent hits its token budget, it should be forced to make a decision with what it has — or escalate to a human. It should never be allowed to spiral into open-ended reasoning.
Observability: The Missing Pillar
Traditional software has logs, metrics, traces. Agentic systems need those — plus a whole additional layer of observability that most teams don't build.
You need to know:
- What the LLM was thinking (chain-of-thought traces)
- What tools it called, in what order, with what arguments
- Which prompt version it was running
- What the token cost was per step
- Where it deviated from the expected path
- When it was uncertain (and how uncertain)
A Practical Guide for Designing, Developing, and Evaluating Agentic Systems covers evaluation extensively, but observability in production is different from evaluation in development. Evaluation tells you if the system is good. Observability tells you why it failed when it wasn't.
We built a tracing layer at SIVARO that captures every LLM call, every tool invocation, every decision point. When something goes wrong, we can replay the exact sequence of events that led to the failure. That's the production debugging equivalent of a time machine.
python
# Minimal production tracing
import json
from datetime import datetime
class AgentTracer:
def __init__(self, agent_id):
self.agent_id = agent_id
self.events = []
def trace(self, event_type, data, metadata=None):
self.events.append({
"timestamp": datetime.utcnow().isoformat(),
"agent_id": self.agent_id,
"event_type": event_type, # "llm_call", "tool_call", "decision", "error"
"data": data,
"metadata": metadata or {}
})
def save(self):
# Store in a queryable format (e.g., structured logs, OpenTelemetry)
for event in self.events:
log_to_otel(event)
Without this, you're flying blind. Your agent is making thousands of decisions a day, and you have no idea why it made any of them. In development, that's fine. You can see the whole interaction. In production, you're miles away from the action.
The Testing Mirage
Most teams I meet have a testing story that goes like this: "We tested the agent with 20 sample inputs and it passed 18." That's not testing. That's a demo with extra steps.
Production agentic testing requires:
Golden set evals. A curated set of inputs with known-good outputs. Run every change against this set and compare. If accuracy drops, the change is bad.
Adversarial testing. Give the agent inputs designed to break it. Ambiguous instructions. Contradictory information. Hostile inputs. This is where agents fail — not on the happy path.
Regression testing. When you fix one bug, make sure you didn't introduce two more. Agents are non-deterministic, so you need to run the same test multiple times and check the distribution of outcomes.
Shadow deployment. Run the new version alongside the old one. Compare outcomes. Only promote when the new version outperforms.
The industry calls this "evaluation" but it's really just software testing applied to non-deterministic systems. The difference is you need statistical confidence, not just binary pass/fail.
Here's what a production eval harness looks like:
python
# Production eval harness - simplified
import numpy as np
def evaluate_agent(agent, golden_set, num_runs=5):
results = []
for sample in golden_set:
sample_results = []
for _ in range(num_runs):
output = agent.run(sample.input)
sample_results.append(judge(output, sample.expected))
results.append({
"input": sample.input,
"pass_rate": np.mean(sample_results),
"is_flaky": np.mean(sample_results) < 1.0 and np.mean(sample_results) > 0.0
})
return results
Notice the flakiness detection. A test that passes sometimes and fails other times is worse than a test that consistently fails. Flaky behavior is the signature of an agent that's not actually in control of its decision-making.
Agentic Workflow Production vs Development: The Human-in-the-Loop Question
There's a cult in this industry that believes agents should be fully autonomous. No human involvement. Set it and forget it.
That's not production engineering. That's a liability strategy.
The right pattern is human-on-the-loop — the agent works autonomously, but escalates to a human when it hits its confidence threshold, when the action is irreversible, or when the cost of failure exceeds a threshold.
A Practical Guide to Production-Ready Agentic Workflows with ADK and Agent Engine emphasizes this as a core production pattern. The Google teams building these systems at scale treat human escalation as a feature, not a failure mode.
What does that look like?
python
# Human-in-the-loop pattern
def agent_with_escalation(task, confidence_threshold=0.8, financial_threshold=5000):
# Agent does its thing
result = agent.run(task)
# Check if escalation is needed
if result.confidence < confidence_threshold:
return escalate_to_human(task, result, reason="low_confidence")
if result.financial_impact > financial_threshold:
return escalate_to_human(task, result, reason="high_impact")
if result.action_is_irreversible:
return escalate_to_human(task, result, reason="irreversible_action")
# Otherwise, proceed autonomously
return execute(result)
In development, you want to see the agent succeed autonomously. It feels like magic. In production, you want to see the agent know its limits. That's maturity.
The Deployment Pipeline Nobody Talks About
There's a pattern I've seen work repeatedly, and it's almost never discussed in the agentic AI hype cycle.
It's the phased rollout.
You don't go from dev to production in one step. You go through a series of increasingly risky environments:
- Local dev — your machine, your prompts, your test data
- Staging — a realistic environment with synthetic data
- Canary — 1% of real traffic, observed carefully
- Partial rollout — 25% of traffic, with manual review of outputs
- Full production — 100% of traffic, with automated monitoring
Each phase has different constraintsional and different failure modes. The problems you find at each phase are different. And crucially, you need a rollback mechanism at every phase.
Agentic AI patterns and workflows on AWS describes this as "progressive delivery" and it's absolutely the right approach. But I'd add one thing: at every phase, you need a clear exit criteria. What does "passing" mean? How do you know when to move to the next phase? If you can't articulate that, you're not ready to move.
Keep It Simple or Die
There's a profound article by Tim Deschryver on keeping agentic AI simple that I wish more teams would read. The gist: most agentic workflows don't need to be as complex as people make them.
A simple workflow that handles 80% of cases deterministically, with a small agentic fallback for the 20% that needs flexibility, is more robust than a fully agentic system that tries to handle everything with LLM reasoning.
We tested this at SIVARO. Two teams built the same invoice processing system. Team A used a fully agentic approach — LLM decides everything. Team B used a hybrid — deterministic code for parsing, validation, and routing, with an LLM only for ambiguous cases. Team B's system was 3x cheaper, 5x more reliable, and easier to debug.
The Virtido enterprise guide reaches the same conclusion: deterministic workflows should be the default, with agentic behavior reserved for genuinely open-ended tasks.
This is the contrarian take: most agentic workflows are over-engineered. The LLM doesn't need to make every decision. It needs to make the decisions that can't be made deterministically.
The Real Cost of Getting This Wrong
Let me give you a concrete example from 2025. A healthcare scheduling company deployed an agentic workflow to handle appointment bookings. The agent was supposed to check availability, book the slot, and send a confirmation.
In development, it worked flawlessly. 95% success rate on their test set.
In production, the agent started booking appointments in the past. It would find "available" slots that were already booked because its availability check wasn't atomic — it would check availability, then take too long to book, and by the time the booking API call executed, the slot was gone. But instead of failing gracefully, the agent confirmed the booking anyway.
The result? 214 patients showed up for appointments that didn't exist. The healthcare provider had to apologize to all of themcars. And the company that deployed the agent had to pay for the remediation.
That's the difference between development and production. In development, a bug is a fun debugging challenge. In production, a bug is a PR disaster.
What I'd Tell My Younger Self
If I could go back to 2023, when we first started building agentic systems at SIVARO, I'd tell myself these five things:
1. Build the guardrails before the intelligence. A constrained agent that works reliably is worth more than a brilliant agent that's unpredictable.
2. The LLM is not the product. The workflow is. The model is a component. The workflow — how the model interacts with your systems, your data, your users — is what delivers value.
3. Cost is an architectural concern. Not a billing concern. Token economics should shape your architecture from day one.
4. Observed is better than optimized. Before you optimize anything, instrument everything. You can't improve what you can't see.
5. Human escalation is a feature. Build it early. Build it well. Your agent should know when it's out of its depth.
The Bottom Line
The McKinsey deployment lessons from real enterprises boil down to one insight: agentic AI production is a different discipline than agentic AI development.
In development, you're proving what's possible. In production, you're managing what's probable — and preparing for what's improbable.
The teams that succeed treat agentic systems like the complex distributed systems they are. They build guardrails. They manage context. They observe everything. They test adversarially. They respect token economics. And they keep the human in the loop when it matters.
The teams that fail treat agentic systems like magic boxes that turn prompts into results.
You know which one you're building.
FAQ
What's the single biggest mistake teams make moving from agentic development to production?
Not accounting for input variance. Your test data is clean. Production data is messy, contradictory, and adversarial. Build your system to handle the mess.
Do you need a different model for production vs development?
Not necessarily different model, but different configuration. Production needs temperature control, output validation, fallback models, and circuit breakers. Development can tolerate higher variance.
How do you handle hallucinations in production?
You can't eliminate them. You can only contain them. Validation layers, confidence thresholds, and human escalation for high-stakes actions. Agentic Workflow Patterns & Best Practices calls this "pessimistic design" — assume the model will be wrong and design for it.
What's the minimum observability you need before going to production?
Every LLM call logged with its prompt, response, latency, cost, and decision outcome. Every tool call logged with its arguments, response, and error status. Every escalation logged with its reason. If you can't replay a failure, you can't fix it.
Is it worth building a custom eval harness or should you use off-the-shelf tools?
Build a minimal custom harness for your golden set. The off-the-shelf tools are improving, but your evaluation criteria are unique to your domain. The arxiv practical guide has good patterns for this.
How do you control token costs in production?
Set per-transaction budgets. Use cheap models for routing. Cache aggressively. Fall back to deterministic code wherever possible. And monitor token usage per workflow step so you know where the money is going.
When should you use a workflow vs a fully autonomous agent?
Use a workflow when the steps are known in advance. Use an agent when the path is genuinely unknown. And in production, prefer workflows with agentic escape hatches — not the reverse. Orkes's workflows vs agents breakdown gives a good mental model for when each is appropriate.
What's the right human involvement level?
Human-on-the-loop, not human-in-the-loop. The agent works autonomously but escalates for high-impact, irreversible, or low-confidence actions. The goal is to minimize human intervention while maximizing safety.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.