What Is an AI Agent? A Complete, Honest Definition

The word agent is doing a lot of heavy lifting in 2026. Vendors use it to mean a chat window. Analysts use it to mean an autonomous workforce. Engineers use it to mean a Python loop calling an LLM with tool definitions. They are not all describing the same thing — and the gap between the loosest and the strictest definition is the difference between a demo and a system you would actually trust to run a business process.

This essay is the definition we wish existed when we started building agents for production. It is opinionated, because the loose version of the definition is what gets companies into trouble. If you want to deploy an AI agent that works on Monday, breaks predictably on Tuesday, and gets better by Friday, you need a precise mental model of what an agent is — and just as importantly, what it is not.

Definition

Strip away the marketing and an AI agent is the combination of five things. Remove any one and you no longer have an agent — you have a tool, a script, a chatbot or a workflow.

1. A goal. Not a prompt. A goal — an outcome the agent is trying to bring about. "Resolve this support ticket." "Process this invoice." "Qualify this lead."
2. A reasoning core. One or more language models that interpret the goal, plan the steps, choose the next action, and decide when the work is done.
3. Tools. Concrete capabilities the agent can invoke — read an email, query a database, call an API, send a Slack message, update a CRM record, generate a document. No tools means no agency; it is just a writer.
4. An environment to perceive and act on. Inboxes, ticketing systems, databases, calendars, customer messages — the real systems where work actually happens. The agent observes state, takes an action, then re-observes the new state.
5. A specification. An explicit, written set of rules: who the agent is, what it owns, how it should think, how it should communicate, what it must never do, and when it must hand off to a human. We will call this the agent.md.

That is the test. Goal + reasoning + tools + environment + specification. Anything less is something else — useful, perhaps, but not an agent.

What is NOT an agent

A surprising amount of what is sold as "AI agents" in 2026 fails this test. Categorising the impostors clearly saves a lot of wasted budget.

• A chatbot. Generates conversational text. Doesn't act on the world. Doesn't loop on a goal. Useful, not an agent.
• An LLM with a system prompt. A reasoning core without tools or environment is a writer with a personality, not an agent.
• A Zapier / Make / n8n automation. Has tools and an environment, but no reasoning core — it follows fixed rules and breaks the moment input shape changes. Automation is complementary to agency, not equivalent to it.
• RPA bots. Same problem. They click buttons. They do not reason about whether the buttons should be clicked.
• "AI features" inside a SaaS app. Almost always tool-shaped: a human triggers an action, the AI helps, the human approves. Useful, but the human is still the agent. The software is the assistant.
• An LLM call inside a fixed workflow. If the LLM only ever runs in step 3 of a pre-defined sequence, you have a smart automation. The reasoning is constrained to one slot. There is no autonomous loop.

None of these are bad. They are just not agents. Calling them agents is how procurement budgets get spent on the wrong category of thing.

Anatomy of an agent

Every production agent we have built — across customer support, operations, marketing, finance and sales — has the same internal anatomy. The implementation details vary; the parts do not.

1. Identity and specification

Who the agent is. Its name, its role, its scope, its tone. This sounds soft until you watch what happens to an agent without one: drift, inconsistent decisions, contradictory replies across channels, the slow disintegration of trust. Identity is the constraint that makes the rest of the system coherent.

2. Reasoning core

The model (or orchestrated set of models) that does the thinking. Modern agents typically use a sequence: a fast model for classification and routing, a stronger model for the hard decision, a verifier model to check the output. Which model you pick matters less than how you structure the calls.

3. Memory

Two types, both required:

• Short-term memory — the context of the current task: the email being processed, the customer's recent history, the relevant policy.
• Long-term memory — what has happened before with this customer, what worked, what didn't, which patterns repeat. Usually a vector store or structured database, or both.

An agent without memory is a fish in a bowl: it forgets you the moment the conversation ends. That is fine for a quick summariser. It is fatal for anything that compounds over time.

4. Tools

A registry of capabilities the agent can invoke — each one a function with a clear name, description, input schema and side-effect contract. Modern agent frameworks expose tools through standardised interfaces (OpenAI tools, Anthropic tool use, MCP servers). The principle is the same regardless of the framework: tools are how the agent reaches into the world.

5. Planner / orchestrator

The control loop. Most production agents do not hand the entire task to a single model call and pray. They run an explicit loop: observe → plan → act → observe → re-plan, with explicit termination conditions. Some plans are linear scripts; some are dynamic ReAct-style loops; some are graph-based (LangGraph, state machines). The shape of the planner is one of the most important architectural choices you make.

6. Guardrails and policies

Hard rules that constrain the agent regardless of what the model wants to do. Rate limits. Allowed and forbidden actions. Approval thresholds (anything over £X requires a human). Content policies. Escalation rules. These live outside the prompt — in code — because anything in the prompt can be argued with.

7. Observability

Every decision logged. Every tool call traced. Every escalation explained. Every output sampled for quality. Without observability you cannot tell whether your agent is getting better or worse, and you certainly cannot debug it when it goes sideways. This is the part that separates a demo from a system.

8. Feedback loop

Outcomes flow back into the agent. Customer satisfaction scores, human override rates, escalation reasons, exception patterns — all reviewed weekly, fed into prompt updates, tool changes and policy refinements. An agent that doesn't learn from the field is a depreciating asset.

The agent specification (the "agent.md")

Every production agent needs a single source of truth that defines what it is and how it behaves. We call this the agent.md — borrowing from the README convention of software engineering. Whether you literally store it as a markdown file, a database row, a YAML config, or a structured prompt template doesn't matter. What matters is that it exists in one place, is explicit, and is versioned.

A complete agent.md covers eight sections. Skip any of them and you will pay for it later, usually in production.

Identity

Name, version, owner. The agent's "who am I". A trivial section to write and a non-trivial one to omit — without it, multiple teams will refer to "the support agent" meaning subtly different things.

Role & purpose

One paragraph. What outcome does this agent exist to produce? What is the single most important thing it must get right? If you cannot write this in 100 words, you have a scoping problem, not a writing problem.

Core responsibilities

The bounded list of things the agent owns end-to-end. Three to seven items, written as outcomes ("resolve tier-1 support enquiries within SLA") rather than activities ("reply to emails").

Thinking model

How the agent should prioritise and trade off. "When customer satisfaction conflicts with policy compliance, policy wins, but flag for human review." This is the part that most teams write implicitly inside a sprawling system prompt. Pulling it out into a separate, named section is one of the highest-leverage things you can do.

Behaviour rules

Specific operating rules: never fabricate. Never quote a price not in the price list. Always cite the source. Never apologise on behalf of a person without permission. The bigger this list grows, the more often you should ask whether your prompt is doing too much work that should sit in code.

Communication style

Tone, register, length, formatting, what good output looks like. Include 2–5 worked examples — examples teach a model far better than adjectives. "Professional, direct, never cute" with three sample replies beats five paragraphs of style guidance.

Decision framework

The if-this-then-that backbone. When does the agent act, when does it ask, when does it escalate? Explicit thresholds and conditions belong here. Implicit ones become bugs.

Do / don't constraints

Two short, blunt lists. The "do" list is what makes this agent valuable. The "don't" list is what keeps it out of trouble. The "don't" list is almost always more important.

The autonomy spectrum

Not every agent should be — or should ever be — fully autonomous. The right level of autonomy depends on the cost of an error and how easily it can be reversed. There are five practical levels:

The path that works in practice: start at L1, earn your way to L4. Almost no business workflow ever genuinely needs L5. Everyone wants L5. Everyone should deploy L4 with a kill-switch.

Single agent vs multi-agent systems

At some point your "support agent" needs to do something the "operations agent" already knows how to do. Two paths open up. The wrong one is the one most teams take by default.

The wrong path: one mega-agent

Cram every responsibility into a single agent with a 12,000-token system prompt covering support, sales, operations, finance and marketing. It will work for the first few cases. It will then begin to mix tones, leak knowledge between domains, and make confidently wrong decisions because the priorities of the marketing agent contradict the priorities of the support agent.

The right path: one agent per role, coordinated through protocol

Each agent has a single, coherent identity and a sharply scoped role. Agents talk to each other through structured handoffs (a router agent, a planner agent, or a shared task queue), not by sharing a brain. The trade-off is operational complexity in exchange for behavioural clarity. The trade-off is almost always worth it the moment you have more than one domain.

The middle path: an agent with sub-skills

Sometimes a role legitimately spans many sub-tasks (a "support agent" naturally classifies, drafts, escalates and updates the CRM). Here a single agent with multiple tools is correct. The test: do the sub-tasks share priorities, tone and constraints? If yes — one agent. If no — multiple agents.

How a real agent is built

Stripped to the essentials, the build sequence for a production agent looks like this. We have done this dozens of times; the order matters.

1. Pick one workflow. Not a category. Not a department. One specific, costly, repetitive workflow with a clear input, a clear output and a measurable outcome.
2. Map the human path. What does the human currently do, in order, with which systems, on which inputs, producing which outputs? What are the exceptions, and how often do they occur?
3. Write the agent.md. All eight sections. Before any code. The act of writing it is what reveals the parts of the workflow you didn't actually understand.
4. Define tools. List every action the agent will need to take, with input schemas and side-effect contracts. If a tool can do something irreversible, that fact lives in the tool's contract, not in a hopeful sentence in the prompt.
5. Build the planner. Choose linear, ReAct, or graph-based depending on how branching the work is. Start with the simplest planner that could work.
6. Wire guardrails in code. Anything that must not happen lives outside the prompt: spend limits, approval rules, content filters, escalation triggers.
7. Run in shadow mode. The agent produces outputs; a human still decides. Compare against the human baseline for 1–2 weeks. Quality, speed, edge cases, escalation rate.
8. Promote to L4. Move to autonomous operation with sampled review. Hold the kill-switch. Watch the metrics.
9. Iterate weekly. Review escalations, update the agent.md, refine tools, tighten guardrails. Treat the agent as a junior employee in their first 90 days.

Governance, safety and observability

An agent that nobody is watching is not in production — it is in flight. The non-negotiables for governance:

• Full action logs. Every tool call, every input, every output, every decision rationale. Keep them. Index them.
• Sampled human review. Even at L4, a fixed percentage (start at 10%, lower as confidence builds) of outputs go past a human reviewer.
• Drift detection. Track accuracy, escalation rate, customer satisfaction, average tokens per task, and average tool calls per task. Drift in any of these is an early warning.
• Kill switch. A single button that takes the agent offline and routes work back to humans. Test it. Use it. It is not a sign of failure; it is a sign of maturity.
• Versioning. Every change to the agent.md, every prompt edit, every tool change, versioned. The question "what did the agent know on Tuesday?" should always have an exact answer.
• A clear owner. One human is on the hook for the agent's performance. If nobody owns the agent, nobody will fix it when it drifts. This is the single most overlooked governance control.

Common mistakes

• Confusing a chatbot with an agent. If there are no tools and no environment, you do not have an agent — you have a writer.
• Letting the system prompt do all the work. Identity, rules, decision logic, tone and tool choice all crammed into one giant prompt. The first time you need to change one, you'll change the others by accident. Pull them apart into a real agent.md plus code.
• Skipping the specification. "We'll write the agent.md later." You will not. And by the time you try, three engineers will have invented three different versions, and your behaviour will already be inconsistent.
• Going to L5 too fast. The fastest way to lose trust in an agent is to let it do something irreversible early. Earn autonomy.
• Building one mega-agent for the whole company. Coherent identities cannot span unrelated domains. The marketing voice will leak into your support replies and you will spend a quarter trying to figure out why.
• No observability. If you cannot answer "what did the agent do, and why?" within 30 seconds for any case in the last 30 days, you do not have a production system, you have a hope.
• Treating the agent as finished. A live agent is closer to a junior employee than a piece of software. The first 90 days are the most important.

Where this is going

The next two years are not about smarter models, although those will arrive. They are about better agent architectures: clearer specifications, sharper tools, stronger planners, deeper memory, real interoperability protocols (MCP, A2A) so that agents from different vendors can coordinate without being bolted together with glue code.

The companies that win will not be the ones with the best model — every model will be available to everyone. They will be the ones with the best specifications: the cleanest agent.md files, the tightest tool contracts, the most disciplined governance. AI agency, like human agency, rewards clarity of role and constraint of scope.

If you take one thing from this essay: an agent is not what the model is — it is what the system around the model is. Write the specification first. The rest follows.

For the broader context of why this matters at all, see The Fourth Labour Revolution and our definition of an AI workforce. For an honest look at how autonomy plays out across roles, see cognitive vs manual labour.