WHAT ARE AI AGENTS AND HOW DO THEY WORK?

An AI agent is software that takes a goal, plans its own steps toward it, uses tools and evaluates the result. The concept became the most discussed technology topic of 2026, and it emptied out just as fast: a large share of products marketed as agents are ordinary automation. Below we cover the technical difference separating an agent from a chatbot and from classic automation, the parts of the architecture, why MCP became shared infrastructure, measured enterprise adoption data and the honest limits. Popular statistics that could not be verified were deliberately left out.

What Is an AI Agent? Three Things That Separate It From a Chatbot

A chatbot produces an answer to a question and stops there; an agent takes a goal and works until it reaches it. There are three structural differences. First, autonomy: the agent decides which step to take, without waiting for instructions at each one. Second, tool use: the agent interacts with external systems, searching, reading files, running code, calling APIs and writing data; it does not merely produce text, it acts. Third, the feedback loop: the agent sees the result of its work, notices errors and adjusts its plan accordingly. Calling a product an agent without those three empties the concept. We covered how AI works in general in our what is artificial intelligence article; the difference here is that the model stops being a box that returns answers and becomes the deciding part of a system.

Workflow or Agent? Anthropic's Architectural Distinction

The most useful distinction in the field comes from Anthropic, and it settles most decisions in practice. By the Building effective agents article, workflows are systems where language models and tools are orchestrated through predefined code paths, while agents are systems where language models dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks. The difference is concrete: in a workflow you draw the path, in an agent the model chooses it. The same source lists five common workflow patterns: prompt chaining, routing, parallelisation, orchestrator-workers and evaluator-optimiser. The practical conclusion is that if you can map the problem in advance, a workflow is cheaper, faster and more predictable; if the path is genuinely uncertain, you need an agent. Most businesses that think they need an agent actually need a well-designed workflow.

The Difference Between Classic Automation and Agents

RPA has been handling invoice processing and data entry for years, so a fair question arises: is an agent just a new name? The difference lies between rules and judgement. RPA runs on rigid predefined rules and breaks when a field moves on screen or an unexpected case appears. An agent adapts to the changed situation, tries an alternative path and decides with partial information. What you pay in exchange is predictability: RPA returns the same output for the same input every time, an agent may not. So the two are not rivals but solutions to different classes of problem. For high-volume work with clear rules and low error tolerance, RPA remains the right tool. Where input is unstructured, judgement is required and exceptions are as frequent as the rule, agents come forward. The most effective setups often combine both: the agent decides, the RPA executes the repeated step.

Agent Architecture: Model, Tools, Memory, Planning

An agent contains four parts. At the core sits the language model, where reasoning and decisions happen. The tool layer is the agent's hand reaching into the outside world: search, file system, database, API calls and code execution. The memory layer has two kinds; short-term memory carries the context of the current task, long-term memory stores what was learned from previous work. The planning layer breaks the task into sub-steps and sets the order. The fifth and most often skipped part is verification: a mechanism that checks the agent's own output, catches errors and retries when needed. In Anthropic's description, agents begin work with a command from a user, plan and operate independently once the task is clear, and return to the human for additional information or decisions when needed. The critical design decision sits exactly there: defining upfront where the agent returns to a human determines the system's reliability.

MCP: How Shared Infrastructure for Agents Emerged

Connecting every agent to every tool separately was a problem that does not scale, and the answer came as a protocol. The Model Context Protocol (MCP), announced by Anthropic in November 2024, was defined as an open standard enabling secure, two-way connections between data sources and AI-powered tools. The official documentation describes it with the analogy of a USB-C port for AI applications; the architecture consists of host, client and server participants, the data layer is built on JSON-RPC, and the server side exposes three primitives: tools, resources and prompts. What matters most is the pace of adoption: MCP was donated in December 2025 to the Agentic AI Foundation under the Linux Foundation, with Block and OpenAI joining Anthropic as founders and Google, Microsoft and AWS among supporters. Google's A2A protocol for agent-to-agent communication was likewise handed to the Linux Foundation in June 2025. The agent ecosystem is moving toward shared protocols rather than one company's closed standard.

Where Agents Actually Work in 2026

Setting promises aside, it is worth looking at areas genuinely running in production. The most mature is software development: by GitHub's Octoverse 2025 report, more than a million pull requests were created by coding agents between May and September 2025. The second area is research and synthesis, where gathering information from multiple sources, comparing it and producing a report fits agent architecture well. The third is certain layers of customer support, especially requests answerable from a knowledge base but requiring several systems to be queried. The fourth is data processing and reporting, and the fifth is content production pipelines and campaign operations in marketing. The common thread is this: agents work where the steps are uncertain but the outcome is verifiable. Using an agent on work whose correctness you cannot check only makes the error invisible.

Enterprise Adoption: Separating Measurement From Forecast

Care is needed with the numbers, because measured data and marketing forecasts are tangled together in this field. On the measured side sits McKinsey's 2025 State of AI survey: based on roughly two thousand respondents across 105 countries, 23 percent of organisations are scaling an agent system in at least one function and 39 percent have begun experimenting. Deloitte's figure is a forecast: it states that a quarter of companies using generative AI would launch an agent pilot in 2025, rising to half by 2027. A warning is essential here: the widely circulated claim that 95 percent of generative AI pilots fail rests on a study that has not been peer reviewed and whose source could not be verified, so it is not used here. Likewise, resolution rates published by specific vendors about their own products are not repeated, since they have not passed independent audit. Distinguishing vendor claims from survey data is the most valuable skill in this space.

Gartner's Cancellation Forecast and the Reasoning Behind It

The most striking warning came from Gartner. In its press release of 25 June 2025, the firm predicts that over 40 percent of agentic AI projects will be cancelled by the end of 2027, citing rising costs, unclear business value and inadequate risk controls. The same release assesses most projects as early-stage experiments driven by hype, and bases the forecast on a survey with more than three thousand participating organisations investing in agents. The prediction should be read as a warning rather than a prophecy: what cancelled projects share is not inadequate technology but a business problem that was never clearly defined. The practical conclusion is to write down, before starting, which metric will improve and by how much. A pilot without a measurable target is a candidate for the cancellation list six months later.

Agent Washing: Telling Real Agents From Rebranded Automation

Gartner also gave the phenomenon a name in the same release: agent washing, the rebranding of existing products such as assistants, RPA tools and chatbots without substantial agentic capability. Its estimate is striking: of the thousands of vendors claiming agentic solutions, only around one hundred and thirty are assessed as offering genuine agentic capability. To tell them apart, ask the vendor these questions. Does the product generate its own step plan, or do we define the steps? Which tools can it reach, and does adding a new one require code? What happens when a step fails, does it retry or stop? When does it return to a human, and who sets that threshold? How does it keep a record of what it did? If the answers revolve around predefined scenarios, what you have is a workflow. That is not a bad thing, but buying a workflow at agent prices is.

Real Limits: Error Accumulation and Cost

The most serious technical problem with agents is error accumulation. Because an agent works across many steps, a small error at each carries into the next and grows along the way. In Anthropic's article on building a multi-agent research system, the situation is stated plainly: minor system failures can be catastrophic for agents, and a single failed step can send an agent onto entirely different trajectories. The same source gives the cost side: agents consume roughly four times the tokens of chat interactions, and multi-agent systems around fifteen times. So agent architecture is not a free upgrade but a serious cost line. The measures Anthropic recommends are clear: extensive testing in sandboxed environments, appropriate guardrails, stopping conditions such as maximum iterations, and human feedback at checkpoints. A working prototype does not mean it will work in production; the gap between the two stages is wider than expected.

Security: Prompt Injection and Authorisation

The most critical vulnerability specific to agents is prompt injection, which ranks first on OWASP's list of large language model risks. The problem is this: when an agent reads external content such as a web page, an email or a document, instructions hidden inside that content can steer the model. An agent browsing the web on your behalf may mistake a hidden command on a malicious page for an instruction and move toward leaking data or performing an unwanted action. The risk grows with the agent's authority: an agent that only reads is not in the same risk class as one that can send email or make payments. The practical measures are: least privilege, giving the agent only the permissions its job requires; human approval on irreversible actions; logging the data the agent reaches and the actions it takes separately; and marking external content as data so it is not interpreted as instruction. We covered the general security frame in our article on cyberattack types.

Where Should a Business Start With Agents?

The right starting point is not the most exciting use case but the most measurable one. The steps run like this. First choose a repetitive, time-consuming task whose outcome is verifiable; on unverifiable work you cannot notice the agent's mistakes. Then check whether a workflow could solve it, because if it can, you do not need an agent and the workflow is cheaper and more predictable. If an agent is needed, keep the scope narrow, start with a single task and keep the authority you grant to a minimum. Define three things upfront: the success metric, the stopping condition and the points where a human steps in. Limit the pilot's duration and budget in advance. Finally, keep records: if you cannot see which step the agent took and why, you can neither improve nor defend the system. A pilot you cannot measure is one you will have to end six months later.

Where Are Agents Heading? An Assessment Without Hype

Both extremes are wrong: neither the claim that agents will take over every job nor the claim that it is all a bubble fits the data. What is measured is this: in areas where results can be tested, such as coding, agents are producing serious volume in production, while a significant share of enterprise projects are cancelled over unclear business value. Three directional trends are visible. First, standardisation: protocols like MCP and A2A being handed to independent foundations means the ecosystem is not locking into a single vendor. Second, cost awareness: token consumption stops agents being a cheap add-on and turns architectural decisions into economic ones. Third, the persistence of human oversight: the sector's prevailing recommendation is not full autonomy but a human in or on the loop. The right question for your own business is not whether to use an agent but which of your tasks has uncertain steps and a verifiable outcome. If you have such a task, an agent makes sense; if not, waiting is a legitimate decision too.