Enterprise generative AI has moved through three waves in quick succession. First came chat assistants that answered questions. Then came copilots embedded in tools, drafting emails, code and reports for a human to accept. The current wave is agentic AI: systems that plan multi-step work, call tools and APIs, and take actions with varying degrees of independence. Every major software vendor now markets agents, and boards are asking why their companies do not have more of them.
The gap between ambition and outcome is wide. Gartner predicted in June 2025 that over 40% of agentic AI projects will be canceled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls, and estimated that only about 130 of the thousands of vendors claiming agentic capabilities were offering the real thing. The same research forecast that by 2028, 15% of day-to-day work decisions will be made autonomously and a third of enterprise software applications will include agentic AI. Both things can be true: agents will matter a great deal, and many current projects will fail. This article explains how to land on the right side of that divide.
What Makes a System “Agentic”
The word agent is used loosely, so it helps to be precise. A system is meaningfully agentic when a language model does more than generate text: it decides which step to take next, selects and invokes tools, observes the result, and iterates toward a goal. Four capabilities separate an agent from a chatbot with plugins:
- Planning: decomposing a goal into steps, and revising the plan when a step fails.
- Tool use: calling APIs, databases, search, code execution or other agents, with structured inputs and outputs.
- Memory and state: tracking what has been done in a task and, optionally, retaining information across sessions.
- Action with consequences: writing to systems of record — creating tickets, issuing refunds, changing configurations — rather than only reading.
That last capability is where both the value and the risk concentrate. An agent that only reads and drafts is a sophisticated copilot. An agent that writes to production systems is a new kind of software actor, and it needs to be engineered and governed like one.
Why Agentic Projects Stall
The failure patterns are remarkably consistent across industries:
- Agent washing. A deterministic workflow or a chatbot is relabeled as an agent, adding cost and unpredictability without adding capability. Many processes are better served by a well-designed workflow with one or two model calls.
- Fuzzy goals. “Automate customer service” is not a task an agent can be evaluated against. Successful projects target a bounded job with a clear definition of done.
- Underestimated integration. The model is rarely the hard part. Reliable, permission-aware access to CRM, ERP, ticketing and knowledge systems is.
- Runaway cost. Multi-step reasoning, retries and large contexts multiply token consumption; a demo that costs cents per run can cost dollars per run at production complexity.
- Compounding error. If each step is 95% reliable, a ten-step task succeeds far less often than any single step suggests. Long, unconstrained chains degrade quickly.
- Missing controls. Security, audit and compliance teams are brought in late, discover that an agent has broad credentials and no audit trail, and halt the rollout.
Choosing the Right Use Cases
The best early agent use cases share a profile: high volume, multi-step but bounded, dependent on several systems, tolerant of a short human review, and measurable. Examples include triaging and enriching inbound support tickets, reconciling invoice exceptions, preparing first-draft responses to security questionnaires, investigating routine IT incidents, and assembling research packs for analysts.
Score candidate use cases on five criteria before committing:
- Value: hours saved, cycle time reduced, revenue protected — expressed in numbers the business already tracks.
- Determinism: could a rules-based workflow do 80% of this? If yes, build the workflow and use the model only for the judgment steps.
- Reversibility: can a wrong action be detected and undone cheaply? Irreversible actions require stronger gates.
- Data and tool readiness: do APIs exist, are they documented, and can access be scoped per task?
- Evaluability: can you assemble a test set of realistic tasks with known good outcomes?
Model the unit economics before you build
Agent economics are driven by cost per completed task, not cost per model call. Estimate the average number of steps, the tokens consumed per step including retrieved context and tool outputs, the retry rate, and the share of tasks that escalate to a human anyway. Compare the fully loaded cost per task — inference, platform, monitoring and the human review time that remains — with the cost of the current process. Many promising ideas look different once escalations and review time are counted honestly; others look better, because the agent removes the slowest hand-offs rather than the cheapest keystrokes. Revisit the model after the pilot with measured numbers, and set a budget ceiling per task that the orchestrator enforces at run time.
Set Autonomy Deliberately
Autonomy is a design parameter, not a binary. A practical ladder has five levels, and most enterprise agents in 2026 should operate at levels two or three:
- Suggest: the agent researches and proposes; a human performs every action.
- Act with approval: the agent prepares actions and executes them after explicit human confirmation.
- Act within limits: the agent executes low-risk actions autonomously inside policy thresholds (for example refunds under a set amount) and escalates the rest.
- Act and report: the agent executes broadly and humans review samples and exceptions after the fact.
- Fully autonomous: no routine human involvement; reserved for low-impact, easily reversible tasks with mature monitoring.
Promote an agent up the ladder only when evidence supports it: measured accuracy on realistic tasks, a low rate of overridden decisions at the current level, and monitoring that would detect a regression quickly. Autonomy can also be granted per action type rather than per agent: the same agent might act freely when updating a ticket field but require approval before changing a user’s access rights.
Treat autonomy as something an agent earns with evidence. Start by letting it suggest, measure how often humans override it, and widen its authority one bounded step at a time.
Reference Architecture for an Enterprise Agent
A production agent is a system of components, each of which needs ownership and testing.
Orchestration layer
The control loop that sends context to the model, parses its decisions, executes tools and enforces step limits, timeouts and budgets. Prefer explicit graphs or state machines for the parts of the process you understand, and let the model choose freely only where flexibility genuinely adds value. Hybrid designs — a deterministic workflow with agentic sub-steps — are usually more reliable than a single free-roaming agent.
Tool and integration layer
Tools should be narrow, well described and safe by construction: “create_refund(order_id, amount)” with server-side validation is far safer than a generic HTTP client. Standard protocols such as the Model Context Protocol (MCP) make it easier to expose enterprise systems to multiple agents consistently, but they do not remove the need to design each tool’s permissions carefully.
Knowledge and memory
Retrieval over governed knowledge sources supplies facts; task state records progress; long-term memory, if used, must be scoped per user and task and be inspectable and erasable.
Model layer
Use a model gateway so you can route steps to different models — a frontier model for planning, a smaller fine-tuned model for classification or extraction — and swap providers without rewriting the agent.
Guardrails, identity and observability
Input and output filtering, policy checks before any write action, per-agent identities with short-lived and task-scoped credentials, and end-to-end tracing of every model call and tool invocation. These are not optional extras; they are what lets security and audit teams approve the system.
Security: Design for the Agentic Threat Model
Agents widen the attack surface because they read untrusted content and can act on it. The OWASP GenAI Security Project published its Top 10 for Agentic Applications in December 2025, and it is a useful checklist. Its risks include agent goal hijack, tool misuse, identity and privilege abuse, agentic supply-chain vulnerabilities, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation and rogue agents. Practical controls that address most of them:
- Treat every document, email, web page and tool response the agent reads as potentially hostile, and keep it separate from instructions.
- Apply least agency: give each tool only the permissions its task needs and validate parameters server-side.
- Give each agent its own identity and short-lived credentials; never run an agent on a shared admin account.
- Sandbox code execution with network egress denied by default.
- Show humans the actual action to be executed at approval time, not just the agent’s summary of it.
- Maintain an inventory of agents with an owner, purpose and expiry date, and test a kill switch.
Evaluation and Operations
Agents need evaluation at two levels. Task-level evaluation asks whether the agent reached the right outcome: was the ticket routed correctly, was the reconciliation right? Trajectory-level evaluation examines how it got there: did it call the right tools in a sensible order, stay within budget, and avoid unnecessary actions? Build a test set of realistic tasks, including adversarial and edge cases, and run it on every change to prompts, tools or models.
In production, monitor completion rate, escalation rate, human override rate, cost and latency per task, tool error rates and policy violations. Trace every run so that a surprising outcome can be replayed step by step. Treat prompts, tool definitions and model versions as versioned configuration with controlled releases and fast rollback.
Make the operating model explicit
Every agent needs a named business owner who is accountable for its outcomes, and a technical owner who is accountable for its behavior. Agree in advance who can pause it, who reviews sampled actions, how exceptions are fed back into the test set, and when an agent that is not delivering is retired. Without these decisions, agents tend to linger in a half-trusted state where humans double-check everything, which delivers the cost of automation without the benefit.
Worked Example: An IT Service Desk Agent
Consider a company whose service desk handles a steady stream of access requests, password issues and software installation tickets. The team designs an agent with a narrow mandate: triage incoming tickets, gather missing information, resolve a defined set of routine requests, and route everything else with a clean summary.
- Phase 1 (suggest): for six weeks the agent classifies tickets and drafts resolutions, while technicians act. The team measures classification accuracy and how often drafts are accepted unchanged.
- Phase 2 (act with approval): for request types where drafts are consistently accepted, the agent executes the resolution — such as adding a user to an approved group — after one-click technician approval, with the exact change displayed.
- Phase 3 (act within limits): for a short list of low-risk, reversible actions, the agent acts autonomously and posts a summary to the ticket; privileged groups and production systems always require approval.
Architecturally, the agent uses a deterministic intake workflow, a small model for classification, a larger model for diagnosis and drafting, and a handful of narrowly scoped tools exposed through an internal MCP server with its own service identity. Every run is traced, and weekly reviews sample autonomous actions. When a technician overrides a decision, the case is added to the regression suite. The outcome the team reports to leadership is not “we deployed an agent” but specific numbers it measured itself: resolution time, technician hours redeployed, and override rates by request type.
Outlook: Where Agentic AI Goes Next
Three trends will shape the next 18 months. First, interoperability standards — MCP for connecting agents to tools and the Agent2Agent (A2A) protocol for agent-to-agent communication, both now under neutral open-source governance at the Linux Foundation — are reducing integration cost and making multi-vendor agent ecosystems realistic. Second, inference costs keep falling and smaller specialized models are increasingly handling routine agent steps, which improves the economics of high-volume use cases. Third, regulation is catching up: the EU AI Act’s transparency duties already apply to agents that interact with people, and agents used in areas like employment or credit decisions will fall under high-risk obligations from December 2027.
The organizations that benefit most will not be those with the most agents, but those with an agent platform — shared identity, tooling, guardrails, evaluation and observability — that lets them launch new agents quickly and retire failing ones cheaply.
Conclusion
Agentic AI is real, and it is also overhyped. The difference between the projects that scale and the ones that get canceled is rarely the model. It is the discipline of choosing bounded, measurable jobs; modeling cost per task honestly; setting autonomy deliberately and widening it with evidence; building narrow, secure tools; and investing in evaluation and observability from day one. Start with one high-volume process, design it as a workflow with agentic steps, and let the data — not the demo — decide how much authority the agent earns.
How Hanoi Technology Can Help
Hanoi Technology designs and builds production agents — from use-case scoring and tool integration to guardrails, evaluation suites and tracing — as projects or with a dedicated team.