AI Agents Explained: The Plain-English Technical Guide
Home » AI Agents Explained: The Plain-English Technical Guide

AI Guides

AI Agents Explained: The Plain-English Technical Guide

What is an AI agent, and how is it different from a chatbot? This guide explains agents in plain English, then goes through the technical choices that decide whether one works: off-the-shelf or custom, RAG, hallucination testing, orchestration, data readiness, model choice and observability.

Book a free AI Capacity Assessment
Take the AI Readiness check
Consultant at work, illustrating the shift from billable hours to value-based delivery with AI agents

The short version

  • A chatbot answers questions. An agent does the work, because it is connected to your systems.
  • Grounding and “I don’t know” are what make an agent’s answers dependable.
  • Gartner estimates only about 130 of the thousands of “agentic” vendors are genuine. Ask what it is connected to.
  • Data readiness and integration, not the AI model, are the usual reasons projects stall.
  • If you cannot see what the agent did, you cannot run it safely.

In this guide

What is an AI agent?

An AI agent is software that uses an AI model to carry out a task inside your own systems. It reads what it needs, works out what the task requires within rules you set, takes an action such as drafting a reply, booking a slot or updating a record, and logs what it did so a person can check it.

Those four steps, read, decide, act and record, happen in the same order every time. Most problems with AI in business come from a missing step. With no read, the agent guesses. With no rules, it improvises. With too many permissions, it can do things it should not. With no record, nobody can tell what happened.

“AI agent development” is the work of building one for a specific workflow: scoping the task, connecting the systems it needs, setting its rules and permissions, testing it, launching it with oversight, and monitoring it afterwards. The agent is the smaller part of that job. The scoping, the connections and the controls take most of the effort.

AI agents versus chatbots

A chatbot sits on your website and replies from a script or a set of FAQs. It knows nothing about your clients, your diary or your invoices, so the most it can do is point people elsewhere. An agent is connected to the systems you already use, such as email, calendar, CRM and case or practice management software, and that connection lets it act.

ChatbotAgent
What it doesAnswers questionsDoes the work and records it
Connected to your systems?Usually notYes, with limited permissions
What you must checkWhat it saysWhat it says and what it can do
Controls that matterContent and hand-offPermissions, approvals and logs

The difference is worth testing, because the market blurs it. Gartner has described “agent washing”, where vendors rebrand existing assistants, robotic process automation and chatbots as agents. It estimated that only about 130 of the thousands of vendors claiming agentic capabilities were genuine. The simple question to ask any supplier is: what is it connected to? Our article on AI agents versus chatbots covers this in more detail.

Off-the-shelf tools or a custom agent?

This is not a choice between good and bad. Each suits a different job.

  • Off-the-shelf assistants are priced per user, and one UK 2026 buyer’s guide puts them at roughly £15 to £60 per user per month. They suit individual drafting, summarising and research. They are not connected to your systems, so they cannot act inside your workflow, and you carry the governance.
  • Connected, custom agents are wired into your systems for one process and usually cost a one-off project fee plus ongoing support. They suit work that repeats at volume, spans several systems, and needs an audit trail.
  • Configured automation built with no-code platforms sits in between. It can be cost-effective for simple, rules-based flows, but someone still has to design it, test it and keep it working.

A fair rule of thumb: use off-the-shelf tools for personal productivity, and consider a custom agent when the work is frequent, patterned and tied to your systems. Our article on off-the-shelf tools versus custom agents sets out the trade-offs, and our cost guide covers the numbers.

Grounding and RAG: answering from your own sources

The safest answer an AI can give is “I don’t know”. Grounding is how you get it. A grounded agent answers from a defined set of sources, such as your policies, price list or client records, instead of everything the model has ever read. This approach is usually called retrieval-augmented generation, or RAG: the system looks up the relevant passage first, then writes its answer from that passage.

Two rules make it dependable. If the answer is not in the sources, the agent says so and hands over to a person. And it shows where the answer came from, so anyone can check.

RAG is only as good as its retrieval. If the wrong passages are fetched, the answer will be wrong even though it sounds sure. That is why sources need to be current, organised and permission-aware, so the agent can only retrieve what the person asking is allowed to see.

Hallucination testing

Hallucinations, where a model produces confident but unsupported statements, are a design and testing problem, not a reason to avoid the technology. The professional bodies are clear that accuracy remains your responsibility, as the SRA’s 2026 warning notice on AI misuse shows, so testing is not optional.

A sound approach has two layers:

  • Before launch. Write a set of realistic test requests, including awkward ones: missing information, an angry client, and questions the agent should not answer or cannot know. Check each response against what a competent person would do. Keep this set as a regression suite, and rerun it whenever the prompt, the model or the sources change.
  • After launch. Keep checking live outputs, sampling them and flagging cases where an answer is not supported by the retrieved text.

It helps to test two things separately: whether the agent retrieved the right material, and whether its answer stayed faithful to it. They fail for different reasons and are fixed in different ways. Agree the pass marks, including how it should behave when it does not know, before testing starts.

Then run shadow mode: the agent works alongside your team on real work, but nothing it produces goes out. People compare its drafts with what they actually did, and you fix the differences before anyone relies on it.

Orchestration: how the steps fit together

Orchestration is the logic that sequences the steps: which system to read first, which rule applies, when to call a tool, what to do when something fails, and when to pass the task to a person. Good orchestration is mostly plain engineering.

  • Use fixed rules where the rules are clear, and the model only where language or judgement is needed.
  • Build in hand-over. Every agent needs a defined way to stop and ask.
  • Handle failure. Time-outs, missing data and unavailable systems should produce a safe outcome, not a guess.
  • Keep approvals explicit. We use three levels: act alone, draft then ask, and never alone. See our governance guide.

A single agent doing one workflow well is usually the right start. Several coordinated agents across systems make sense later, once the first has earned trust.

Data readiness

An agent can only work with what it can reach. Before any build, check:

  • Is the data accessible? The systems the agent needs must allow controlled access, normally through an integration.
  • Is it current and consistent? Duplicate records, free-text fields and stale documents produce poor answers.
  • Is ownership clear? Someone must be responsible for keeping each source correct.
  • Can access be limited? Each agent should get only the specific data, in the specific system, for the specific job.

This is the part that most often decides whether a project works. In RSM’s 2026 survey, professional services firms reporting moderate or limited success with AI pilots most often cited data quality (45%) and integration (41%).

Choosing a model

There is no single best model. The right one depends on the task, and the choice should be made on your own tests, not on a leaderboard. Consider:

  • Task fit: long documents, structured extraction, conversation and drafting each favour different strengths.
  • Accuracy on your cases: run the shortlist through your test set.
  • Data handling: where data is processed and stored, how long it is kept, and whether it is used for training.
  • Cost and speed: cost per task at your volumes, and response time where it matters, such as on live calls.
  • Portability: keep your prompts, test sets and data in a form you own, so you can switch models if prices, terms or quality change.

Observability: seeing what the agent did

You cannot run what you cannot see. Observability means recording enough about each action that a person can reconstruct what happened. At minimum, log the request, the data retrieved, the decision, the action taken, who approved it and when.

Use those logs to track the things that matter operationally: volume handled, hand-over rate, error and correction rate, and time saved. Set alerts for unusual behaviour. Review the logs regularly, because processes change and agents need retraining when they do.

Logs are also your evidence. The NCSC notes that an attacker exploiting an agent gains whatever access the agent has, so knowing precisely what it did, and being able to limit what it can do, is part of security as well as quality. They are what you show a regulator, a client or an insurer who asks how your AI is supervised.

From build to live

We take every agent through the same four stages, so it makes its mistakes in private:

  • Test cases. Realistic and awkward requests, checked against what a competent person would do.
  • Shadow mode. It runs alongside your team on real work, with nothing going out.
  • Supervised launch. Live, with approvals on for anything that leaves the business.
  • Monitoring. Watched after launch and retrained when your processes change.

An agent that skips the first three stages is a demo, not a deployment.

Frequently asked questions

Are AI agents safe for a regulated firm?

They can be, if they are built with limited permissions, human approval for anything that leaves the business, and a full record of what they do. The risk lies less in the AI and more in how much access it has and whether anyone checks it. See our governance guide.

How long does it take to build one?

Our published build times run from 7 to 21 business days depending on the tier, with the final price and timeline confirmed at quote stage.

Will an agent replace my staff?

ONS data shows fewer than one in 15 adopting UK businesses reported reducing headcount because of AI. In our builds, the agent takes on repetitive, multi-step admin, and people keep the judgement, the advice and the client relationship.

What is the difference between an AI agent and an AI enquiry assistant?

An enquiry assistant is one kind of agent, focused on handling incoming messages: acknowledging them, asking qualifying questions, offering a booking and summarising for a person. Wider agents also work across your internal systems.

Related reading

See what an agent could do in your firm

Law firms and accountancy practices can book a free 30-minute AI Capacity Assessment. Everyone else can take the free 8-question AI Readiness check to see how connected their business already is.

Book a free AI Capacity Assessment
Take the AI Readiness check

Sources

Descriptions of RAG, testing and observability reflect widely used industry practice and our own build method.

More guides

Next steps

Related articles