Agents in Production
The signal
Most agent failures are not model failures. They are workflow failures.
An agent can use a strong model and still break because the task is too broad, the tool call is risky, the memory is stale, the latency is unacceptable, the cost is invisible, or nobody knows when a human should step in.
That is the production shift.
In demos, agents are judged by whether they can complete a task once.
In real work, agents are judged by whether they can complete the right task repeatedly, safely, within budget, and with enough visibility for a human to trust the result.
Agent reliability is not one feature. It is a system. Cost. Latency. Evaluations. Memory. Tools. Guardrails. Human review. Logging. Escalation. Recovery.
The teams that treat agents as “model wrappers” will keep fighting unpredictable behavior. The teams that treat agents as operating workflows will have a better chance of turning AI into real work.
Why this matters
Agents are moving into real workflows:
– Customer support triage.
– Research.
– Sales follow-up.
– Content operations.
– Internal knowledge work.
– Developer workflows.
– Document review.
– Operational reporting.
But the production question is no longer: “Can an agent do this?”
The better question is: “Can this workflow tolerate what the agent gets wrong?”
That changes the design process.
A low-risk internal summarization agent can run with light review.
A customer-facing support agent needs routing, confidence checks, escalation rules, and audit logs.
An agent touching money, compliance, customer commitments, security, or production systems needs tighter scope and human approval before action.
Reliability depends on the work context.
The same agent pattern can be safe in one workflow and dangerous in another.
The production tradeoff
Agent cost is not just model price.
It comes from the whole loop:
model calls, context size, tool calls, retrieval, retries, validation, logging, and human review.
Latency works the same way.
A simple answer may be fast.
A multi-step agent that plans, searches memory, calls tools, validates output, retries failures, and waits for approval may be slow.
That is not automatically bad.
– Some workflows need speed.
– Some need accuracy.
– Some need traceability.
– Some need low cost.
The mistake is pretending one agent can optimize for all four.
A practical rule:
Use the cheapest and fastest workflow that still meets the reliability requirement.
Not every job needs an autonomous agent.
– Some need a prompt.
– Some need retrieval.
– Some need a tool workflow.
– Some need human-in-the-loop approval.
The evaluation shift
Traditional QA checks whether software behaves as expected against known requirements.
Agent evaluation is messier.
– The same input can produce different outputs.
– The same task may have several acceptable answers.
– The agent may call tools in different orders.
– The failure may be subtle.
– The answer may sound right and still be wrong.
So agent evals need a wider lens.
A useful agent eval should test:
Task success: Did it complete the job?
Output quality: Was the result accurate, useful, and complete?
Tool behavior: Did it call the right tools with the right inputs?
Boundary control: Did it stay inside scope?
Cost and latency: Did it finish within acceptable limits?
Escalation: Did it know when to ask for help?
Recovery: What happened when data was missing, a tool failed, or instructions conflicted?
Traditional QA asks, “Did it pass?”
Agent evals also ask, “Did it behave responsibly when the work became uncertain?”
The reliability layer
Memory is useful, but unmanaged memory makes agents confidently wrong.
Tools are powerful, but broad tool access turns small mistakes into real actions.
Guardrails help, but they cannot live only at the end of the workflow.
For production agents, these three layers need to be designed together.
Memory should answer:
– What should the agent remember?
– Who approved it?
– When does it expire?
– What source of truth overrides it?
Tools should answer:
– What can the agent access?
– What can it change?
– What requires approval?
– What gets logged?
Guardrails should answer:
– What is out of scope?
– What actions are too risky?
– When should the agent stop?
– When should a human review?
A practical rule:
Give agents narrow permissions before broad permissions.
“Create a draft” is safer than “send the email.”
“Recommend a change” is safer than “change production settings.”
“Summarize a ticket” is safer than “close the ticket.”
Reliability improves when agents are designed with permission boundaries, not just better prompts.
Agent readiness checklist
Before moving an agent into real work, check six things.
1. Scope
The task is narrow enough to evaluate.
2. Inputs
The agent has the right documents, data, examples, and context.
3. Tools
Tool access is permissioned, logged, and limited to the job.
4. Memory
Memory is scoped, inspectable, and subordinate to the source of truth.
5. Evaluations
The workflow can be tested for task success, output quality, tool behavior, cost, latency, and escalation.
6. Human review
A person remains responsible for judgment-heavy, customer-facing, financial, legal, security, or production-impacting actions.
That is the core reliability playbook.
Not full automation everywhere.
Structured delegation.
Agents do the repeatable work.
Humans approve the judgment-heavy work.
Systems log what happened.
Evaluations improve the workflow over time.
That is how agents become useful in production. Not by pretending they are perfect.
By designing the workflow around where they are strong, where they fail, and where humans still matter.
A useful question for any team building agents: Where should the agent act, where should it ask, and where should it stop?
INVENEW exists to help tech builders, operators, founders, and leaders turn AI from experiments into working systems.
Sponsored: In partnership with AWS