Executive committees are asking what an AI agent can do for their business, and a good share of agent projects won't make it: Gartner (2025) expects more than 40% of agentic AI projects to be cancelled by the end of 2027, and according to S&P Global (2025), on average, organisations scrap 46% of their AI proofs of concept before production. Many of those failures start with a fuzzy picture of what an enterprise AI agent is, what it can do and how to deploy one without breaking things.

Definition: an AI agent, the short version

An enterprise AI agent is a software system that combines a large language model, access to tools (APIs, ERP, CRM, knowledge base), short and long-term memory, and a reasoning loop. It works toward a business outcome under supervised autonomy, with named people accountable for what it does.

Within that definition, the goal, the tools and the loop are what set an agent apart from a plain assistant.

Everything else is engineering: connector quality, access rights, observability and, above all, governance, meaning the rules that decide what the agent may do without asking.

Chatbot, RPA, agent: clear up the confusion

Board and executive committee slides still put chatbot, RPA and AI agent in the same column, even though they follow different logics.

What sets the agent apart is that it decides for itself which action to take on your systems, whereas RPA runs a sequence written in advance. That capacity to act, under governance, deserves its own line in the AI roadmap.

What the difference means for budget and risk

The distinction shows up in the budget first. With a chatbot, the effort goes into writing scenarios; with RPA, into maintaining scripts; with an agent, into systems integration and governance. Failures look different too: a chatbot admits it doesn't know, an RPA bot stops dead on a changed screen, and an agent can return a plausible, wrong answer without flagging anything. An agent has to be supervised on the quality of its decisions as well as its uptime, which is why governance belongs in the scoping phase, before the first pilot.

Questions that qualify an agent project

Before funding a project labelled "agentic", a few checks settle the matter:

If the answer to the second question is no, you are looking at an assistant. That has value, but it is budgeted and governed differently from an agent.

The capabilities that define an AI agent in 2026

Long-context reasoning

According to the models overview in Anthropic's documentation, checked on 16 September 2026, the latest Claude models accept up to one million tokens of context. The agent keeps its reasoning consistent across all of it, and a window that large changes what use cases look like: you can hand it an entire supplier contract, an internal compliance handbook and a pricing policy, then ask for a reasoned decision with references.

Window size does not remove the need to choose what goes in. An agent fed contradictory or outdated documents reasons less well, so well-designed architectures retrieve the relevant material (RAG) instead of loading everything on every request.

Tool use and the MCP protocol

The agent calls functions: read an email, open a ticket, query a SQL database, trigger a Salesforce workflow. MCP, the protocol that standardises those connections, was open-sourced by Anthropic on 25 November 2024 and donated on 9 December 2025 to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. In that announcement, Anthropic lists ChatGPT, Gemini, Microsoft Copilot and Visual Studio Code among the products that have adopted it.

At Koneetiv we install MCP by default, because it cleanly separates business logic from the integration layer: a connector written for the CRM serves every agent that needs it, and access rights are managed in one place. When a system exposes no API, the fallback is computer use, where the agent drives the interface like a user and becomes sensitive to screen changes. Our grid for choosing between computer use and API sets out the questions to settle, traceability included.

Short-term and long-term memory

Short-term memory keeps the thread of a conversation (linked tickets, open requests). Long-term memory, usually backed by a vector RAG, stores decisions, policies and customer profiles. That is what lets a customer service agent recognise a key account, its history and its contract without being briefed again on every request.

That memory is also a risk surface. Whatever an agent retains follows the same classification and retention rules as the rest of your data, GDPR included, and must be erasable on request.

Planning and the control loop

The agent plans before it acts: it breaks a goal into sub-tasks, runs them, checks the results and retries when needed. That control loop is what separates plain text completion from an agent. On complex workflows (financial close, enhanced KYC, supplier sourcing), it chains long sequences of orchestrated steps autonomously, under human supervision.

Verification is a link teams often neglect. Without an explicit success criterion, such as a total that must balance, a mandatory field filled in or a business rule respected, the agent can accept a plausible but wrong result and move on to the next step.

Governance: what blocks the move to production

Deloitte's State of AI in the Enterprise, 2026 edition, finds that 21% of companies have mature governance for their agents. What we see on engagements points the same way: getting agents from pilot to production depends on governance first, well ahead of model quality. The same blind spots come up project after project:

How the LOOP™ methodology covers those blind spots

Koneetiv's LOOP™ methodology (Living Oversight & Operations Protocol) handles these points by default. It sorts every possible action of every agent into four zones, each with its own level of trust:

On top of that come 3 escalation levels (information, validation, block), a living registry that names the owners of each agent, and alignment with ISO 42001, the NIST AI RMF and the EU AI Act, so the setup is audit-ready from the pilot phase.

Zones are assigned action by action

The same finance agent can generate a report in the green zone, submit a large invoice for approval in the orange zone and be denied access to payroll data in the black zone. That granularity opens autonomy where risk is low without extending it everywhere, and our guide to classifying agent actions by trust zone walks through the method.

The prerequisite people forget: the AI Act

The timeline moved in July 2026. According to the European Commission, the Digital Omnibus on AI entered into force on 27 July 2026. Obligations for high-risk systems in sensitive areas (such as biometrics, critical infrastructure, education, employment, migration) now apply from 2 December 2027, and those for AI built into regulated products from 2 August 2028. The transparency rules of the EU AI Act have applied since August 2026: people must know when they are dealing with an AI.

For a high-risk system, compliance means a complete setup (registry, risk management, logging, human oversight, transparency, robustness) that takes time to run in, and the Digital Omnibus delay mostly buys time to build it properly. On the personal data side, France's data protection authority, the CNIL, has published recommendations on applying the GDPR to the development of AI systems.

Under the AI Act, a customer service agent usually falls under transparency obligations only. An agent used in HR (hiring, evaluation), credit scoring or biometrics is high-risk, and for that agent compliance is a precondition for going live. During a Claude Ignite scoping, each priority use case is qualified together with its foundations, the AI Act included.

How to start

The classic mistake is jumping straight into a technical POC without scoping the problem. The first step can be free: the AI maturity assessment returns a score out of 100 and a 6-axis radar, so you arrive at scoping knowing where you stand. The Koneetiv journey then follows a frame, execute, steer sequence:

  1. Frame: a Claude Ignite audit maps your systems, processes and data, selects 3 to 5 priority use cases scored on value and feasibility, builds a quantified business case for each and delivers a roadmap with Go/No-Go milestones.
  2. Execute: Claude Ops deploys agents on your processes in five phases (IT and data audit, strategic framing, module implementation, training and certification, managed support and ongoing governance), while Claude Work equips your people, starting with a pilot team.
  3. Steer: Claude Cockpit, an outsourced Chief AI Officer, owns strategy, LOOP™ governance and the steady activation of new use cases.

CIO Boost, which equips development teams with Claude Code, and Salesforce Headless, which puts Claude in front of Salesforce as its interface, complete the setup, bringing the number of entry points to six.

Choosing the first process to hand to an agent

To rank candidates, a simple grid does the job: score each process on value (volume handled times unit gain), on feasibility (available data, integrations required) and on risk, read through the LOOP™ zone its actions would fall into. A single disqualifying score is enough to push a candidate back: a high-value process whose data remains out of reach, or whose actions would mostly fall into the red zone, waits behind smaller use cases that are ready to start.

Koneetiv's 16 agent modules are laid out by business function in the AI agent library, which helps set expectations before scoping.

Our analysis of which enterprise use cases reach production sets out the use-case families that get there and the selection criteria to check up front.

Mistakes that delay production

On the method side, the most frequent mistakes are easy to spot early:

Next step: book a Claude Ignite audit. You come away with quantified priority use cases, a milestone roadmap and a recommendation on the next entry point.

Field insights on moving to production are collected in our AI agents in production section.