Running AI Agents in Production in 2026: What Actually Works
By Stackvora Team · 2026-09-12 · 9 min read
Two years of agent hype have produced a clear split: demos that impress in a sandbox, and a much smaller set of agents that survive production traffic. The difference is almost never the model. It is the engineering around it — retrieval quality, tool design, evaluation, and cost control.
Start with a narrow job, not a general assistant
The agents that work in 2026 do one bounded job: triage a support ticket, reconcile an invoice, draft a firewall change, summarise a log bundle. Bounded jobs give you a measurable success criterion, a small tool surface, and a fallback path when the model is unsure. "General company assistant" gives you none of those, which is why so many internal copilots quietly die after launch week.
Tool design beats prompt engineering
Models are now good enough that most failures come from badly shaped tools. A tool that returns 40KB of raw JSON will blow your context and confuse the planner. Design tools the way you would design an API for a junior engineer:
- One clear verb per tool; avoid a single
do_everything(action, payload)entry point. - Return summarised, typed results — IDs and a handful of fields, not full records.
- Make errors instructive:
"customer_id not found; call search_customers first"beats a stack trace. - Make writes idempotent and require an explicit confirmation argument.
Retrieval is still the hard part
Long context windows did not kill retrieval, they changed its shape. Stuffing 400K tokens into every call is slow and expensive, and accuracy drops in the middle of long inputs. The pattern that holds up is hybrid: keyword (BM25) plus vector search, then a reranker, then a strict token budget per turn. Chunk on document structure — headings, sections, code blocks — not fixed character counts, and always carry the source URL through so answers can cite it.
| Layer | Purpose | Typical budget |
|---|---|---|
| System + tools | Role, policy, tool schemas | 1–3K tokens |
| Retrieved context | Grounding documents | 4–12K tokens |
| Conversation | Recent turns, summarised history | 2–8K tokens |
| Headroom | Tool results during the run | remainder |
Evals, or you are flying blind
You cannot ship model changes safely without a test set. Build one from real traffic: 50–200 recorded cases with a known good outcome. Score them on task success, not prose quality. Run the suite on every prompt change, every model upgrade, and nightly against production samples. Teams that skip this discover regressions from their users, weeks late.
Three scoring styles cover most needs: exact match for structured outputs, rule checks for policy compliance (did it refuse, did it cite, did it stay under length), and model-graded rubrics for open answers — with a human spot-check of the grader itself.
Cost and latency control
Route by difficulty. A small fast model handles classification, extraction and routing; the expensive reasoning model handles the hard 10–20%. Cache aggressively: prompt caching on stable system blocks, plus a semantic cache for repeated questions. Stream tokens so perceived latency drops even when total time does not. And set a hard per-request budget — a runaway loop that calls tools 60 times is a billing incident, not a bug report.
Guardrails that matter
Treat model output as untrusted input. Never let a model's text reach a shell, a database query, or an email send without validation against a schema and an allowlist. Prompt injection through retrieved documents is a real attack path in 2026: a page in your knowledge base can carry instructions aimed at your agent. Defences that work are structural — separate the data channel from the instruction channel, strip or neutralise instruction-like text in retrieved content, and require human approval for irreversible actions.
Observability
Log every run with the prompt version, model, tool calls, token counts, latency and outcome. Without traces you cannot answer the only question that matters after an incident: what did it actually see before it did that? Sample transcripts weekly and read them — the failure modes you find by reading are the ones dashboards never surface.
Key takeaways
- Bounded jobs with measurable success beat general-purpose assistants.
- Tool ergonomics and retrieval quality drive accuracy more than model choice.
- No eval suite means no safe upgrades; build one from real traffic.
- Route cheap-to-expensive, cache hard, and cap per-request spend.
- Model output is untrusted input — validate before any side effect.
Working on an agent design? Sketch the tool surface with Stackvora AI, or read related architecture guides in the knowledge base.