Agentic AI: what it is, what it can do and the limits to set

Agentic AI describes systems that pursue a goal by planning steps, using tools and acting across applications. Where a chat assistant answers a question, an agent is given an objective, such as resolving a delayed shipment, and works out for itself which systems to check, which messages to send and which records to update.

Interest is high and activity is real, but scale is still rare. McKinsey’s 2025 survey found that 62% of organisations are at least experimenting with AI agents and 23% are scaling an agent system somewhere in the business. Yet no more than 10% are scaling agents in any single function. The picture is one of widespread trial and narrow deployment.

This report explains what distinguishes agents from earlier automation, where they are proving useful, why scaling is slow, and the controls that organisations should put in place before giving an agent any real authority.

How agents differ from automation and chat

It helps to place agents alongside the tools most organisations already know. Each step along this line adds capability and adds risk.

• Workflow automation follows fixed steps defined in advance. It does the same thing every time and fails predictably when inputs change.
• Chat assistants answer questions and draft content. They inform a person, who then decides and acts.
• Copilots work inside a specific application, suggesting actions that a person accepts or rejects.
• Agents decide what to do next, may call several systems in sequence, and may change records, send messages or commit spending without a person approving each step.

That autonomy is both the value and the risk. An agent can handle a multi-step task that would otherwise need a person to switch between five screens. It can also take a wrong turn early and compound the error across every later step, at machine speed.

Where organisations are today

The McKinsey figures describe a pattern we see in our own work. Many organisations have agent pilots running in innovation teams or within a single department. Far fewer have moved an agent into a core process with real volumes, real customers and real money.

Several factors explain the gap. Agents need access to several systems, which raises security and integration questions that pilots often sidestep. Their behaviour is harder to predict than fixed automation, which makes risk and compliance teams cautious. And the cost of running them, in computing and in oversight, is not always clear until volumes rise.

This is not a reason for pessimism. Earlier waves of technology followed the same curve: broad experimentation, a period of learning about controls and costs, then focused deployment where the value was clearest. The organisations that will scale agents well are those using the current period to build the governance, integration and measurement they will need, rather than simply adding more pilots.

There is also an organisational reason. Scaling an agent means someone must own its decisions. In many organisations, nobody has yet agreed who is accountable when an agent makes a mistake: the process owner, the technology team or the vendor. Until that question is answered, sensible leaders hold back.

Risks specific to agents

Agents inherit the familiar risks of AI, such as inaccurate output and bias, and add several of their own. Understanding these shapes the controls described in the next section.

• Compounding errors: a mistaken assumption early in a task carries through every later step.
• Over-broad access: an agent given wide permissions for convenience can reach data or actions far beyond its purpose.
• Manipulated inputs: instructions hidden in an email, document or web page can steer an agent towards actions its owner never intended.
• Runaway volume: a loop or misread instruction can trigger hundreds of actions before anyone notices.
• Unclear accountability: when an agent acts, it may be hard to say afterwards who approved what, and why.

None of these risks is a reason to avoid agents. Each is a reason to design boundaries, approvals and logging before launch rather than after the first incident.

Where agents help

Good candidates are multi-step tasks with clear goals and clear boundaries. The goal can be checked, the systems involved are known, and the actions available are limited and reversible.

Chasing late shipments

An agent monitors orders past their expected delivery date, checks carrier tracking, contacts the supplier or carrier for an update, records the response and alerts the customer service team when a delay will affect a customer. Each step is routine; together they consume hours of staff time.

Reconciling payments

An agent matches incoming payments against open invoices, investigates mismatches by checking remittance advice and correspondence, proposes the most likely allocation and flags genuine discrepancies for a person to resolve.

Preparing routine reports

An agent gathers figures from several systems, checks them against the previous period, notes significant changes and drafts the commentary for a manager to review and approve.

Resolving common support requests

An agent handles password resets, order status questions or address changes end to end, verifying identity, updating records and confirming with the customer, while passing anything unusual to a person.

What these examples share is a high volume of similar cases, a known set of systems, actions that can be reversed if wrong, and an outcome that is easy to check. Tasks that lack these features, such as negotiating with a key supplier or deciding a disputed insurance claim, are poor candidates regardless of how capable the underlying model appears in a demonstration.

Limits to set before launch

Before an agent touches live systems, define its boundaries in writing. The principle is least privilege: the agent receives only the access it needs for its specific task, and nothing more.

At first, require approval for anything irreversible or customer-facing. Refunds, cancellations, messages to customers and changes to master data are obvious examples. As evidence builds, some of these can be relaxed. It is much easier to grant autonomy than to rebuild trust after an agent has sent a thousand incorrect emails.

Treat an agent like a new employee with a tightly scoped role and a supervisor.

The analogy is useful in practice. A new employee in accounts receivable would not be given authority to write off debts in their first week. They would shadow, then act with supervision, then act alone within limits. Agents deserve the same progression.

Evaluation and monitoring

Agents should be tested on realistic cases before release, including unusual ones. Build a set of test scenarios from real history: straightforward cases, edge cases, ambiguous instructions and situations where the right answer is to stop and ask. Measure how often the agent reaches the correct outcome and, just as importantly, how it fails.

In operation, monitor a small set of measures continuously.

1. Success rate: the share of tasks completed correctly without intervention.
2. Override rate: how often people reverse or change what the agent did.
3. Cost per task, including computing and human review time.
4. Incidents: errors that reached customers, suppliers or financial records.
5. Escalations: cases the agent handed to a person, and whether that was the right call.

Keep the ability to switch an agent off quickly, and test that switch. If an agent starts behaving unexpectedly because an upstream system has changed, the process owner should be able to pause it within minutes and fall back to the manual process.

Review these measures weekly in the early months, with the process owner and a representative of the team that handles escalations in the room. Their view of where the agent helps and where it creates extra work is often more revealing than the numbers alone. Agree in advance which thresholds would trigger a pause, a reduction in autonomy or an expansion, so that decisions are made on evidence rather than on the mood of the latest meeting.

A sensible start

Pick one workflow with a clear goal, known systems and limited, reversible actions. Run the agent in suggestion mode first: it proposes what it would do, and a person decides. Compare its proposals with what people actually did over several weeks. Where they agree consistently, grant limited autonomy for that type of case. Where they disagree, investigate and improve.

Expand step by step, one action type at a time, with the evidence in front of the process owner at each stage. Organisations that follow this path move more slowly at first, but they reach scale with fewer incidents and far more confidence than those that grant broad authority on the strength of a demonstration.

Source: McKinsey, The state of AI in 2025.

Frequently asked questions

What is the difference between an AI agent and a chatbot?

A chatbot answers questions and a person acts on the answer. An agent plans and takes actions itself, such as updating records or sending messages, across one or more systems.

Which tasks should AI agents not do unsupervised?

Anything costly, irreversible or affecting people, such as refunds, cancellations, customer communications and changes to master data, at least until strong evidence of reliability exists.

How do we know an agent is ready for more autonomy?

Run it in suggestion mode and compare its proposals with human decisions. Grant autonomy for case types where agreement is consistently high and errors are reversible.

Explore Generative AI, copilots and agentic automation