We don’t have a model problem, we have a handoff problem. It’s what a practitioner says after the third failed pilot, once the review meetings stop blaming the language model and start tracing where work actually changes hands.

Agentic AI refers to AI systems that pursue a goal across multiple steps. They plan, choose tools, take actions in other software, check the results, and adjust, all with limited human direction. A chatbot answers one prompt at a time, and a robotic process automation (RPA) script repeats a fixed sequence of clicks. An AI agent is given an outcome, such as “resolve this supplier dispute” or “reconcile these accounts,” and works out the sequence itself. That flexibility is what makes agentic AI valuable for enterprise automation, and it is also what makes it hard to deploy responsibly.

The sections below cover five questions that decide whether an agent survives contact with real operations: how much autonomy to grant, what the data plumbing must look like, who is accountable when an agent errs, what the first ninety days in production should contain, and how to measure whether any of it worked.

Autonomy Is a Spectrum, Not a Switch

The most useful early decision in any AI transformation program is not which model to use. It is how much independence each workflow should receive, and the answer varies by workflow, not by company.

A practical way to think about it is four levels. At the first level, the system assists: it drafts, summarizes, or suggests, and a person does the work. At the second, it acts under supervision: it performs the steps, but a person approves each consequential action before it takes effect. At the third, it acts with conditional autonomy: it proceeds on its own within defined limits, such as a payment ceiling or a confidence threshold, and escalates anything outside them. At the fourth, it operates autonomously within a bounded domain, and humans review samples and outcomes instead of individual decisions.

Traditional intelligent automation sat mostly at the third level for narrow, stable tasks, because RPA was only dependable when inputs were predictable. Agentic systems extend that reach into messier territory. An invoice that arrives with a missing purchase order number would have broken a script. An agent can look up the likely purchase order, check the vendor’s history, and draft a query to the requester. This is why the same invoice-processing workflow might justify different autonomy levels at different stages: extraction can run autonomously, matching can run under conditional autonomy, and payment release can stay supervised.

A few observations tend to hold across deployments.

The first is that autonomy should follow reversibility. Actions that are easy to undo, such as drafting an email or tagging a ticket, can be granted independence early. Actions that are hard to undo, such as moving money, changing a customer record of legal significance, or sending external communications on behalf of the company, should earn independence slowly, with evidence.

The second is that confidence is not the same as correctness. An agent can produce a fluent, well-structured, wrong answer with perfect composure. Thresholds based on the model’s own stated confidence are weak controls on their own. Stronger controls check the output against something external, such as a rules engine, a database record, or a second agent assigned to verify.

The third is that the right level changes over time. A workflow that starts under supervision can graduate to conditional autonomy once its override rate has stayed low for long enough, and it should be demoted again if the underlying process, policy, or data changes. Autonomy is something the system earns repeatedly, not something granted once at launch.

Teams that skip this framing usually end up in one of two failure modes: an assistant so restricted that it saves no time, or an agent so free that nobody trusts its output. The spectrum gives them a vocabulary for the space between.

Plumbing Before Prompts

A language model can reason well and still be useless if it cannot reach the right systems with the right permissions. Most of the work in enterprise agent projects happens below the model, in the layers that connect it to business reality.

Start with data readiness. An agent that answers questions about customers needs a consistent definition of “customer.” In many enterprises, the sales system counts a customer as a signed contract, the finance system counts a billing account, and the support system counts anyone who ever opened a ticket. A human analyst resolves these differences from memory and context. An agent will pick one, or blend them, and present the result with confidence. Before deployment, the semantic differences that matter to the workflow need to be documented and, where possible, resolved in a governed layer such as a master data model, a metrics layer, or curated knowledge sources the agent is allowed to retrieve from.

Next is integration. Agents act through tools: application programming interfaces, database queries, document stores, ticketing and ERP systems. Each tool needs a clear contract about what the agent may read, what it may write, and what happens on failure. Legacy systems without clean interfaces are common in large enterprises, and they push teams toward brittle workarounds such as screen automation. Those workarounds are sometimes unavoidable, but they should be recorded as technical debt and not mistaken for architecture.

Then comes workflow orchestration. A single agent handling a long process end to end tends to become unreliable as the process gets longer, because errors compound across steps and the context becomes crowded. Multi-agent systems address this by dividing the work among specialists, such as one agent that extracts data, one that validates it against policy, and one that drafts the output, coordinated by an orchestration layer that routes tasks, tracks state, and enforces order. The orchestration layer is often where the real engineering value sits, since it decides how work moves, where it pauses for review, and how it recovers from a failed step.

Identity and access are the part most often left until too late. An agent should have its own identity with the minimum permissions its task requires, not a borrowed administrator credential. Its actions should be logged under that identity so that an investigator can later answer a simple question: what did the agent do, using what information, and on whose behalf?

Finally, agent observability. Traditional software monitoring tracks uptime and latency. Agent monitoring needs to capture the reasoning trail: which tools were called, with what inputs, what came back, and what the agent concluded. Without traces, debugging becomes guesswork. An unexplained bad outcome in an agentic workflow cannot be reproduced the way a code bug can, so the recording has to happen while the agent is running.

None of this is glamorous, and none of it appears in a demo. But in practice, the gap between a convincing prototype and a dependable production system is almost entirely made up of these layers.

Who Answers When the Agent Is Wrong?

Every enterprise deployment eventually faces this question, and it is better to answer it in a design document than in an incident review.

The standard response is human-in-the-loop design: a person reviews or approves what the agent does. That is a sound principle, but it fails in a predictable way. When reviewers are shown hundreds of agent outputs a day, and ninety-five percent are correct, attention fades. Approvals become reflexive. The control still exists on paper, but it no longer catches errors. This is sometimes called automation complacency, and it is well documented in other fields where humans supervise machines.

Better designs treat human attention as a scarce resource and spend it where it matters.

One approach is risk tiering. Low-risk, reversible actions run without review. Medium-risk actions are sampled, so a reviewer checks a fraction of them and the sampling rate rises if error rates climb. High-risk actions always route to a named approver with the context needed to decide, not just a yes-or-no button. The tiers should be defined by consequence, such as financial exposure, regulatory impact, or customer-facing visibility, not by how the technology feels.

Another approach is structured escalation. When an agent is uncertain, blocked, or outside its authority, it should know how to stop and hand off cleanly: summarizing what it found, what it tried, what it recommends, and what decision it needs. A good escalation message saves the human time. A bad one forces them to redo the work, which quietly destroys the business case.

A third is separation of duties between agents. An agent that performs a task should not be the only one that checks it. A verification agent, a deterministic rules check, or a reconciliation against an authoritative source can catch classes of error that self-review misses. This mirrors long-standing financial controls, where the person who initiates a payment does not also approve it.

Accountability also has to be named. Guardrails and AI governance policies describe what an agent may do, but someone still owns the outcome. Typically that is the business process owner, supported by a technical owner for the agent and a risk or compliance function that sets the boundaries. When responsibility is spread across all three without a single accountable name, incidents tend to produce meetings but not fixes.

Several concrete controls belong in nearly every production deployment. There should be a kill switch that can halt the agent immediately. Every consequential action should produce an audit record. Prompt, tool, and model changes should go through change management like any other production change. And there should be a tested rollback path, so that actions taken in error can be reversed or compensated for. None of this slows a well-run program down. It is what allows the program to expand its scope without every expansion becoming a negotiation.

The First 90 Days in Production

Pilots often succeed for reasons that do not carry over: a motivated team, curated data, forgiving users, and a sponsor watching closely. The first ninety days in production are where those advantages fade, so it helps to plan the period in three phases.

The first phase, roughly weeks one through four, is shadow mode. The agent runs alongside the existing process, produces its outputs, but takes no live action. Humans continue to do the work as before, and the two results are compared. This phase is for finding out how the agent behaves on real inputs, including the ugly ones, such as scanned documents with handwritten notes, half-filled forms, and requests that contradict policy. It also produces the baseline error data that later autonomy decisions will rely on. The common temptation is to skip this phase because the pilot went well. That is usually a mistake. The pilot’s inputs were chosen, and production inputs are not.

The second phase, roughly weeks five through eight, is supervised action. The agent begins acting, but a person approves consequential steps. Here the team tunes the escalation rules, refines the prompts and tool permissions, and watches the override rate, meaning how often humans change or reject what the agent proposed. Override reasons are especially valuable, because they point at whether the gap is in the data, the instructions, the policy, or the model. This is also when the workload shifts for the people involved. They stop doing the task and start supervising it, which is a different skill and should be trained for.

The third phase, roughly weeks nine through twelve, is bounded autonomy. For the workflow segments where evidence supports it, the agent operates with conditional autonomy within defined limits. The remaining segments stay supervised. A good exit criterion for this phase is not “the agent has been live for ninety days.” It is a set of pre-agreed thresholds: an error rate below a stated line, an escalation rate within an expected range, no unresolved incidents above a defined severity, and a documented review by the process owner and the risk function.

A few practical details make the difference during this window. Keep a log of every incident and near miss, and review it weekly. Freeze unnecessary changes to the agent’s model and prompts during evaluation windows, so that cause and effect stay readable. Tell the affected employees what the agent will and will not do and how to flag problems. Adoption problems in enterprise AI are frequently people problems, and people who learn about a new system from its errors tend to distrust it permanently.

Ninety days will not make the agent perfect. It should produce something more useful: a documented understanding of where the agent is dependable, where it is not, and what it costs to run.

Measurement Has to Outlast the Pilot

Pilot metrics tend to flatter. They count tasks completed, hours saved, or accuracy on a test set. These are real measurements, but they are not a business case, and they rarely survive scrutiny from a finance leader.

Measuring return on investment for agentic automation starts with a baseline taken before deployment. Without it, any later improvement is a claim, not a finding. For each workflow, the baseline should cover cycle time from request to resolution, cost per transaction including supervision and rework, error and exception rates, and the volume of work waiting in queue. After deployment, the same measures are tracked against that baseline.

Several distinctions keep the numbers honest.

Hours saved are not dollars saved. If the time recovered is absorbed into the same team’s day without changing headcount, throughput, or quality, the saving is real but not yet realized. The business case should say what the recovered capacity is used for, such as handling more volume, shortening response times, or reducing backlog, and measure that.

The costs on the other side of the ledger are easy to miss. Model usage fees, orchestration and integration engineering, observability tooling, human review time, and the ongoing effort to maintain prompts, tools, and evaluations all belong in the total. For some workflows, the review overhead consumes a surprising fraction of the gross benefit, which is why the override rate and the review time per item deserve to be tracked as first-class numbers.

Quality needs its own measures. These include accuracy against a maintained evaluation set, the rate of escalations that were unnecessary, the rate of problems that were not escalated but should have been, and the customer or stakeholder outcomes downstream. The evaluation set should be refreshed regularly with new cases from production, particularly the failures, since a static test set slowly stops representing reality.

Drift is the final reason measurement must continue after launch. Policies change, vendors update their formats, upstream systems are modified, and the underlying model may be updated by its provider. Any of these can shift an agent’s behavior without anyone touching its configuration. Continuous monitoring, with alerts tied to the key measures, is how a team finds out in days instead of quarters.

A simple discipline helps: review every production agent on a fixed schedule, such as quarterly, against four questions. Is it still delivering the measured benefit? Is its error profile stable? Has its scope crept beyond what was approved? And is the autonomy level still justified by the evidence? An agent that cannot pass that review should be adjusted or retired. Retiring a failing agent is a sign that governance works, not a sign that the program failed.

The longer the work runs, the more a different question starts to dominate. As agents take over the routine decisions, the cases that reach people become the hard ones: ambiguous, novel, high-consequence. The people handling them will have had less practice on the easy cases that once built their judgment. If the apprenticeship that produces expert reviewers is the work being automated, who will be qualified to supervise the agents five years from now, and how will anyone know?

Frequently Asked Questions

What is agentic AI in an enterprise context?
Agentic AI describes AI systems that pursue a goal across multiple steps by planning, using tools, taking actions in business systems, and checking results with limited human direction. In an enterprise, this means agents that can handle workflows such as invoice processing, customer case resolution, or account reconciliation. The key difference from earlier tools is that the agent decides how to reach the outcome, not just which scripted steps to repeat.

How is agentic AI different from RPA?
RPA follows fixed, rule-based sequences and tends to break when inputs vary or systems change. Agentic AI uses language models to interpret unstructured inputs, adapt its approach, and handle exceptions that a script cannot anticipate. In practice, many enterprises combine them, using RPA or direct integrations for stable, high-volume steps and agents for judgment-heavy ones.

What is human-in-the-loop AI and when is it required?
Human-in-the-loop AI is a design in which a person reviews, approves, or can override an AI system’s actions. It is most important for high-impact, hard-to-reverse, or regulated decisions, such as releasing payments, changing legal records, or communicating externally. Lower-risk actions can often be sampled instead of reviewed individually, which keeps the oversight meaningful.

How long does it take to move an AI agent from pilot to production?
A well-scoped agent can reach production in a few months, with the first ninety days in production typically divided among shadow mode, supervised action, and bounded autonomy. The timeline depends more on data readiness, system integration, and governance approvals than on the model itself. Rushing past shadow mode is a common cause of failed rollouts.

How do you measure ROI for agentic automation?
Measure against a pre-deployment baseline for cycle time, cost per transaction, error rate, and backlog, and subtract the full cost of running the agent, including model usage, engineering, and human review. Track how recovered capacity is actually used, since saved hours only become savings when they change output or cost. Continue measuring after launch, because drift in data, policies, or models can erode results.

What are the main risks of deploying AI agents?
The main risks are incorrect actions taken with unwarranted confidence, excessive permissions, unclear accountability, and reviewers who stop paying attention. Others include data quality problems, silent drift after model or process changes, and costs that grow faster than benefits. Guardrails, scoped permissions, audit trails, a tested rollback path, and a named business owner address most of them.

A wide editorial illustration of a conductor’s baton guiding several small, simple robotic figures through connected stages of a workflow, with human figures at a few checkpoints holding clipboards. Flat vector style, deep navy, soft teal, and warm coral palette, generous negative space on the left for a title overlay, no text or logos, 16:9 aspect ratio.