AI Agents Explained: What Agentic AI Really Is (2026)

AI Agents in 2026: The New Reality for UK IT Leaders

Two shifts mark 2026 out as the year agentic AI moved from pitch deck to engineering discipline. The first is protocol standardisation. Anthropic introduced the Model Context Protocol (MCP) in November 2024 as an open way for agents to talk to tools and data sources, and it now underpins how most production agents reach outside their own model weights rather than relying on bespoke, one-off integrations. The second is permission formalisation. A 2026 agent permission-model specification requires a conforming agent to publish a machine-readable manifest at /agent/permissions.json and a plain-English summary at /agent/permissions, backed by a scope catalog at /agent/scopes.json, a consent policy at /agent/consent-policy, and a revocation endpoint at /agent/revoke.

That combination turns 'is this safe to deploy' from a sales conversation into something a security team can actually inspect. If a vendor cannot show you what their agent is allowed to do, what it remembers between sessions, and how you switch it off, treat the product as immature — regardless of how fluent its demo sounds. This piece works through the mechanics behind that judgement: the loop that makes something an agent rather than a chatbot, what changes for infrastructure, and a sober list of what agents handle reliably today.

The Agent Loop: Model, Tools, Memory and Permissions

Ciena described the pattern well in a March 2026 analysis: an agentic workflow behaves like an operating system, spawning threads, managing memory, calling tools, reaching external services through APIs, and iterating through reinforcement loops until the task resolves or hits a permission wall. Strip away the analogy and four components repeat in every serious agent architecture: a model that reasons over the task, a tool layer it can call, a memory store it reads and writes, and a permission boundary that gates what it's allowed to touch. Of the four, the model is the reasoning engine — the part deciding which tool to call, how to interpret what comes back, and whether the task is finished — everything else in the loop exists to give that reasoning engine something safe and useful to act on.

Memory is not one thing. Microsoft Foundry published a memory-store resource on 21 May 2026 describing persistent, structured memory that an agent carries across sessions — distinct from the short-lived working memory of a single conversation. Published 2026 guidance treats these as separate layers with separate write and erase rules, which is exactly the detail worth interrogating before an agent gets access to customer or financial records: can this specific memory be scoped, and can it be deleted on request?

Tool access is enforced earlier than most people assume. An August 2026 analysis of production agent systems found that blanket-denied tools are stripped out of the model's own view at the point the tool pool is assembled — the model never even sees the option, rather than being trusted to decline it. Configuration for all of this is typically declared in a single block covering tool allow-lists and disallow-lists, the underlying model, effort level, permission mode, connected MCP servers, hooks, maximum turns, skills, memory scope, a background-execution flag, and an isolation mode.

In practice, the tool layer means connectors to whatever systems already run the business rather than anything exotic. Published 2026 examples include ledgers and accounting systems, purchase-order databases, log and metrics stores for read-only diagnostics, and the APIs that let an agent call out to any of them — increasingly reached through MCP servers rather than bespoke point-to-point integrations. The tool pool available to a given agent is simply whichever of these connectors its permission manifest allows it to see.

AI Agent vs Chatbot vs RPA: A Clear Technical Distinction

The practical test for 'is this an agent' is simple: can it take actions in software, and does it retain state across steps? A chatbot answers a question and forgets it. An agent can read a ledger, call an API, write a record, and remember what it did the next time it's invoked. That single distinction — action plus persistent state — separates agentic AI from both classic chatbots and rule-based RPA, and it's why the governance questions around memory, tools and permissions don't apply to either older category in the same way.

• •AI agent — handles multi-step tasks needing judgement across systems, but demands strict permissioning
• •RPA — reliable for fixed, rule-based workflows against a stable UI or API; breaks when interfaces change
• •Chatbot — good for single-turn conversational Q&A; cannot act on systems, needs full human review
• •Traditional automation — safe for scheduled batch jobs with no reasoning required, but rigid by design

What Agents Change for UK Infrastructure Teams

Deploying a handful of agents changes the shape of your workload before it changes anything else. Human chat traffic is bursty; agent traffic is not. An agent working through a multi-step task holds a session open, calls tools repeatedly, and often runs unattended, which pushes towards always-on inference capacity and materially higher concurrency than a chatbot deployment of the same size. Teams sizing that capacity are increasingly turning to dedicated on-premise AI inference planning rather than assuming public API rate limits will absorb the load.

The second change is identity. Every agent that calls a tool, reads a database, or writes to a system needs credentials — and those credentials belong to the agent, not the human who configured it. That's a new category of machine identity needing its own lifecycle: issuance, scoping, rotation and revocation, tracked separately from human accounts. This is covered in more depth in our piece on machine identity security in the age of AI agents, but the short version for procurement is simple: ask how many machine identities a deployment creates, and who owns revoking them.

Worked Example: A Bounded Agentic Workflow in Practice

The most reliable agent deployments today are narrow and repetitive, not open-ended. A November 2025 playbook on production agent workflows sets out a finance-operations example worth walking through end to end. The agent reconciles invoices against a ledger, matches each invoice to its purchase order, and produces a mismatch CSV for anything that doesn't line up. It drafts a plain-English summary of what it found, then routes exceptions to a human for approval — it does not post corrections to the ledger itself.

Notice what the agent never does unsupervised: write to the system of record. The same playbook is explicit that the most reliable pattern is for agents to produce structured outputs — CSV or JSON files, proposed database updates, and status summaries — and leave the actual write to a human-approved step. Map that shape onto IT operations and you get a workable incident-response pattern: an agent pulls logs and metrics (read-only), proposes a restart or a config rollback (reversible), and drafts the fix — but a human signs off before anything irreversible happens, such as deleting data, rotating production credentials, or messaging customers.

Governance and Risk Tiers: Making Agents Auditable

A May 2026 production guide on agentic AI formalises the pattern above into three tiers: Tier 0 covers read-only tasks, Tier 1 covers reversible actions, and Tier 2 covers sensitive actions that require human approval and a deterministic policy check before execution. The same guide recommends splitting credentials to match — read-only keys for an agent's exploration and analysis work, with write keys issued only inside controlled runners that enforce the Tier 2 approval step.

Sitting alongside the tiering, current security guidance for production agents recommends tool sandboxing, least-privilege access, human-in-the-loop approval for actions like sending money or deleting data, comprehensive audit logging, and rate limiting. Every agent action should be logged with a timestamp, the user, the intent, and the outcome — the minimum audit trail an infrastructure team will need for incident response and, in a UK context, for demonstrating control to auditors after the fact.

Governance controls don't remove every practical difficulty, either. Ciena's operating-system analogy cuts both ways: an agent that spawns threads, calls multiple tools, and iterates through reinforcement loops has more moving parts to trace when something goes wrong than a single-turn chatbot ever did, and that complexity compounds further once several agents are coordinating rather than one agent working alone. Audit logs — timestamp, user, intent, outcome — are the primary tool for reconstructing what happened after the fact, but they're a record of the failure, not a substitute for the harder engineering work of designing agent workflows that fail in predictable, bounded ways in the first place.

UK/EU Compliance and the Procurement Checklist

For UK buyers, the interesting questions about agentic AI are rarely about the model. They're about governance and operations: can memory be scoped to a specific purpose and erased on request; are actions least-privileged and logged in a way you can actually audit; and are machine identities managed as their own category, separate from human user accounts? These are the questions that determine whether an agent deployment survives contact with a data-protection review, not how articulate its outputs sound in a demo.

• •Ask for the permission manifest and scope catalog, not a verbal summary of what the agent 'can' do
• •Confirm memory retention and erasure rules are documented separately from session state
• •Require human approval and a deterministic policy check for any Tier 2 (irreversible) action
• •Confirm machine identities used by the agent are issued, rotated and revoked independently of human accounts
• •Treat vendors who can't produce a revocation endpoint or an audit-log format as pilot-only, not production-ready

ROI, TCO and the Strategic Outlook

Because reliable agent use cases today are bounded — reconciliation, drafting, classification, routing, and read-only diagnostics — the honest ROI conversation is about time saved on those specific workflows plus the incremental infrastructure and governance cost of running them, not a blanket productivity multiplier. Budget for three things beyond the model itself: always-on inference capacity to keep an agent responsive during multi-step tasks, the machine-identity and permissioning tooling described above, and audit-logging infrastructure to keep every Tier 2 approval traceable. Teams sizing the compute side can use an AI GPU calculator as a starting point before committing to a deployment scale.

The direction of travel is towards multiple, specialised agents coordinating rather than one generalist agent doing everything — a progression documented across 2026 guidance as systems move from single-model calls towards multi-agent orchestration, each agent scoped to its own tools, memory and permission tier. For UK IT leaders, the sober takeaway is that the technology to run this safely already exists in published form — permission manifests, scope catalogs, revocation endpoints, risk tiers. The remaining work is procurement discipline: insisting vendors expose it, rather than taking capability claims on trust.

Sources

Every figure in this article traces to the sources below.

• •EITT — AI agents 2026 guide (MCP origin, security controls, audit logging)
• •GeoDocs — Agent permission model specification
• •Microsoft Foundry — Agent memory-store resource
• •arXiv — Production agent systems analysis (tool filtering, config)
• •Ciena — Agentic AI rewriting compute and networking
• •PromptEngineering.org — Playbook for reliable agentic workflows
• •ICMD — 2026 playbook for agentic AI in production (risk tiers, credentials)