Gartner predicted in 2025 that 40% of enterprise applications would feature task-specific AI agents by the end of 2026, up from less than 5% in 2025. The same firm also expects over 40% of agentic AI projects to be canceled by the end of 2027, citing cost, unclear business value and weak risk controls. Both can be true at once, so the interesting question is what the teams that reach production do differently.
From chatbots to agents
The shift across enterprises in California, Texas and New York is from answer-the-question chatbots to do-the-task agents: triaging support tickets, reconciling invoices, drafting and routing documents, running multi-step research. Customer support is a common first deployment because the return is easy to see and the failure modes are contained.
A working definition helps. An agent is a model that decides which tool to call next, observes the result and continues until the task is done or it hands off to a person. That loop is what makes agents useful. It is also what makes them much harder to test than a single prompt.
Why agent projects stall
Most agent projects die between demo and production for a small set of reasons:
- No evaluation harness — nobody can say whether this week's prompt change made things better or worse.
- No observability — when a run goes wrong, there is no trace of which tool was called with which input.
- Fragile tool calling — it works in a notebook, but real APIs time out, return partial data or change shape under production traffic.
- No owner for "done" — the business process owner was never asked what a correct outcome looks like.
Teams that do reach production tend to have invested in the unglamorous reliability layer first, before adding capability.
What to deploy first
- Contained, high-volume tasks — support triage, document classification, data-entry reconciliation.
- Human-in-the-loop by default — the agent proposes, a person approves, until the evaluation data earns autonomy.
- One well-prompted agent before multi-agent architectures. Most "multi-agent" needs are a single agent with good tools.
- Read before write — let the agent gather and summarize before it is allowed to change records or send messages.
Scoring candidate workflows
| Criterion | Good sign | Warning sign |
|---|---|---|
| Volume | Hundreds or thousands of runs a month | A handful of runs a month |
| Definition of done | A checkable outcome, such as a ticket routed or an invoice matched | "Better insights" |
| Data access | Clean APIs to the systems involved | Screen scraping or manual exports |
| Cost of error | Reversible, or reviewed before it matters | Irreversible actions on customers or money |
| Ownership | A named process owner who reviews results | Nobody accountable after launch |
Score your candidates on this grid and start with the one that has the most good signs, not the most impressive demo.
Build it so it survives production
The reliability layer is the product: an evaluation set built from real cases, telemetry on cost per successful task, and guardrails. See our evaluation playbook and agent framework guide for the engineering decisions, and orchestration patterns for when one agent genuinely is not enough. At minimum, have:
- An evaluation set of a few hundred real cases with expected outcomes, rerun on every change to prompts, tools or models.
- Tracing on every model and tool call, with inputs and outputs you can replay.
- Hard budgets per run: maximum steps, tokens and wall-clock time.
- Permissions scoped per tool, so no agent holds credentials broader than its task needs.
- A kill switch and a manual fallback path that the operations team has actually practiced.
A realistic path from pilot to production
- Weeks 1–2: pick one workflow from the grid, collect real historical cases, and agree with the process owner what a correct outcome looks like.
- Weeks 3–6: build a single agent with read-only tools, run it in shadow mode on live cases, and compare its proposals with what people actually did.
- Weeks 7–10: switch on write actions behind human approval, track approval and correction rates, and fix the most common failure categories.
- After that: relax approval for the lowest-risk actions only when the data supports it, and keep adding every new failure to the evaluation set.
The timeline is illustrative; the order is the point. Shadow mode comes before write access, and approval comes before autonomy.
The governance questions to expect
Security and legal teams in large US companies tend to ask the same questions before approving an agent: what data leaves the company, which vendor processes it and on what terms, how actions are logged, and who approves an agent gaining new permissions. Having written answers ready shortens procurement considerably. The NIST AI Risk Management Framework gives both sides a shared vocabulary for mapping, measuring and managing those risks.
FAQ
Should we build on a framework or write the loop ourselves?
For a first agent, a thin loop you fully understand is often easier to debug. Frameworks help once you need tracing, retries and state management across many agents; our framework guide covers the trade-offs.
When can the human step out of the loop?
When evaluation data on real traffic shows the agent's error rate on a task is acceptable for the cost of an error, and you have monitoring to catch drift. Remove approval step by step, starting with the lowest-risk actions.
How Velura Labs builds agents
We map agent work to agentic systems with evaluation and observability built in, often paired with custom LLM applications and RAG & knowledge systems for grounding. If you are unsure which workflow to automate first, start with an AI Strategy & Roadmap; that decision is worth more than the build. Talk to us about the first agent worth shipping.