“AI agent” is one of the most overused words in sales quotes today, so it is worth defining before someone defines it for you in a price list. An AI agent, in one sentence: a program that is given a goal, not a question, and works out for itself the steps that lead to that goal, using tools in your systems, within the permissions someone deliberately granted it. Most readers, though, arrive with a different question: is the thing my supplier is offering actually an agent — and if it is, what am I signing up for?
This text is for the people who decide on projects and write requirements, not for developers. There is no tool ranking here and no model recommendation. There is an anatomy: what an agent is made of, where each part can fail, and what to check before you sign. The difference from a chatbot is set out separately in AI agent vs chatbot — here it gets two sentences. Facts about standards and regulations were read from the sources on 6 September 2026.
AI agent — what it is: the definition, and what it does not tell you
An AI agent is a program that is given a goal and picks its own route to it. The language model plays the planner: it looks at the goal, at the list of available tools and at what is already known, then names the next step. The program carries that step out — reads a customer record, searches a catalogue, creates a draft document — and hands the result back to the model, which decides what comes next. This runs until the goal is reached or the case has to go to a person. All of it happens within permissions granted in advance, and leaves a trace in the activity log.
That definition says what an agent is. What it is not matters just as much:
- It is not a better chatbot. A chatbot’s output is the text of a reply; an agent’s output is a changed state in your systems — a record, a draft, a status. We leave it there.
- It is not a workflow with an LLM node. Automation that calls a model for one task inside a fixed sequence of steps — classify this email, pull the data out of this invoice — is still automation. A person decided the order of the steps while building it; the model did not decide it while working.
- It is not a “digital employee”. An agent has a scope, a list of permissions and a log, not a job description. Quotes that reach for this metaphor usually skip the question of who approves what it does.
The practical test that tells an agent from a chatbot in a quote — what has to be done after it gets something wrong — is in the comparison piece and we will not repeat it. The rest of this text is about the parts: what an agent is made of, and where each part can fail.
What an AI agent is made of: five parts, and one the quotes stay silent about
An agent is not a model. It is six decisions, and the model is the last of them. Here they are in the order in which they have to be made.
1. The goal and the end criterion
An agent’s goal is an instruction with two additions: a completion criterion and an escalation condition. “Prepare a draft quote for approval, or flag the enquiry as needing a human and give the reason” — that is a complete goal. “Handle quote enquiries” is not, because nothing says when the work is finished or when the agent should give up. A goal with no end criterion is the commonest way agents fall into a loop: they keep trying further steps because nothing tells them that is enough.
2. The model
The language model is the agent’s planner: it reads the goal, the list of tools and the results of the steps so far, then proposes the next step. Two things the glossaries leave out. First, the model does not change by doing the work — after a thousand cases it is exactly the model it was on the first. What looks like learning is memory that people build; that is point five. Second, the model is the last decision in the project, not the first: you choose it against measured quality and cost on your own cases, once the permission lists already exist. A quote that opens with the name of a model opens at the end.
There is an agent many readers already use: coding tools such as Claude Code — which, per Anthropic’s documentation, reads a project’s code, edits files and runs commands — are agents in exactly the sense a business AI agent is. Only the set of tools differs.
3. Tools
A tool is a function the model can call, plus the description the model reads to decide when to use it: “read the customer record”, “look up a product code in the catalogue”, “create a draft document”. In practice the list of tools is the agent’s list of permissions, which is why we split it in two from the start: read tools and write tools. The first can be long, the second should be short — the second is what sets the risk.
Tools are increasingly exposed to agents through MCP (Model Context Protocol), an open standard describing how a server offers a model tools, resources and prompts. Anthropic released it on 25 November 2024 and on 9 December 2025 handed it to the Agentic AI Foundation at the Linux Foundation; the current version of the specification dates from 28 July 2026. According to Anthropic, more than 10,000 active public MCP servers were running in December 2025 — that is the vendor’s figure, not an independent one. For a company the significance is practical: a connection to a CRM or ERP described once can work with different models and platforms. The AI Agent node in n8n, which uses tools like these, is covered in our guide to n8n.
The standard also names a risk ordinary automation did not carry. The MCP specification recommends that the client application ask the user for consent to every tool call, and tells implementers to treat tool descriptions as untrusted unless they come from a trusted server. That is a recommendation for implementations, not a requirement of the protocol — whether the client you are buying really does ask has to be checked with the supplier. The reason is simple: the model reads everything a tool returns — the body of an email, a product description, a comment on a ticket — and if someone hides an instruction in there, the model may treat it as a command. That is prompt injection through tool results. It affects any solution in which a model reads untrusted content, fixed-sequence workflows included; an agent enlarges the consequences, because it chooses for itself which tools to reach for next. Hence two rules: a read scope as narrow as the task allows, and human consent for write operations.
4. The decision loop
An agent works in a cycle: plan → act → observe → decide. The cycle ends in one of three ways: the goal has been reached, the agent has reached an operation that needs human consent, or it has exceeded its budget of steps or time. That third condition has to be set deliberately, and going over budget must end in escalation with a stated reason — never in silent retries.
Every turn of the loop should leave an entry in the log: a timestamp, the tool used, a digest of the input and the result, and the reason the model gave. At case level the log records the final outcome, the human decision and any corrections made. Without that record you know only that the agent did something — you cannot reconstruct why, nor sensibly decide where to relax supervision after the pilot. The log is the only source of data for a decision to widen permissions, which is why it is part of the agent rather than an add-on.
5. Memory
An agent’s memory has two levels. Short-term memory is the context of the current case: the goal, the steps so far and their results; it disappears when the case closes. Long-term memory is what the agent consults between cases: a knowledge base, case history, agreements with the customer. Long-term memory is written and maintained by people or by explicit rules — an agent remembers nothing by itself. This is precisely the part that looks like learning from outside. How such a knowledge base is built and tested is a separate topic.
The sixth part: permissions and the human in the loop
This is the part quotes stay silent about most often, and without it the other five are a prototype. It is four lists: what the agent may read, what it may write, which operations always wait for human consent, and where the record of its actions lives. Every agent we build starts in “it prepares, a person approves” mode; relaxing supervision is a decision made on pilot data, not an assumption in the quote. A quote without those four lists is not describing an agent, only a promise.
Three levels of autonomy: AI assistant, agent with approval, narrow-scope agent
In practice the word “agent” covers three different things, and it is worth knowing which one a quote means.
Level 1: an AI assistant for business. It has read tools only. It gathers information from your systems and prepares a reply, a draft or a proposal — and stops there; the click belongs to a person. Cheapest to build, and a mistake stops with the person looking at the screen. For many companies this is the right first project, even when the quote says “agent”.
Level 2: an agent with approval. It has write tools, but every write goes into an approval queue: the draft waits in a folder, the CRM entry waits to be accepted. Every first agent project starts here, because only this level produces data on how often the agent proposes something correct.
Level 3: a narrow-scope agent. A tightly defined list of reversible actions runs without human consent — decided separately for each category, on the numbers from the pilot. Irreversible actions — sending something to a customer, a payment, a deletion, a status change that sets something else in motion — never move to this level, whatever the results.
The question “will an agent replace an employee” has a plain answer within this split: the agent takes over the repetitive part of the work — the searching, the retyping, the assembling — while approving and handling exceptions change owner rather than disappear. At level two a salesperson stops writing drafts and starts checking them; that is different work, and less of it, but not none.
What this looks like in a company: three examples
Quote enquiries in B2B distribution — an example with numbers
This is an example with numbers, not an account of an implementation — the figures are illustrative and show what you would have to count for yourself.
A B2B distributor receives 400 quote enquiries a month into a shared enquiries inbox. The data sits in three systems: the inbox, the CRM (customers and their individually negotiated price lists) and the ERP (a catalogue of 12,000 product codes, and stock levels). Today a salesperson spends 10–15 minutes on one enquiry; at 12 minutes that is 400 × 12 min ≈ 80 hours a month on drafting alone.
Goal: “prepare a draft quote for approval, or flag the enquiry as needing a human and give the reason”. End of work: a draft in the queue, or an escalation with a reason.
Tools (seven): read the message; find the customer (CRM, read); fetch the customer’s price list (CRM, read); look up a product code (ERP, read); check stock (ERP, read); create a draft quote in the “for approval” folder (write); add a “draft” note in the CRM (write). Never: sending anything to the customer, changing a price in a price list, creating an order, deleting anything.
Loop: usually 6–9 tool calls per enquiry; a budget of 15 steps or 3 minutes; going over either means escalation with a stated reason.
Memory: the case context plus a small, read-only base of agreements with customers, maintained by the sales team (“customer X always wants the price with delivery included”).
The human in the loop: a four-week pilot running in parallel with the existing process; every draft is approved or corrected by a salesperson (about 2 minutes a draft → 400 × 2 ≈ 13 hours). Thresholds set before the pilot, for example: “if after four weeks fewer than 70% of drafts go through without corrections, we stay with the assistant; categories above 90% we consider for relaxed supervision — but sending to the customer stays behind human consent regardless”. You set those thresholds yourself, against what a mistake costs you; they are not industry benchmarks and should not be read as any.
The log: every entry holds what we described in part four, and the list of corrections from the pilot becomes the line between “does it itself” and “goes to a person”. What drives the cost of a project like this — the number of systems, the state of the data, the level of certainty required — is set out in how much an AI agent costs.
Assembling the paperwork for a warranty claim
Goal: assemble the documentation for a reklamacja — the Polish statutory complaint a customer files over a faulty product — or say what is missing. The agent reads the ticket, the order history, the warranty terms and the attachments. Where it looks on the second step depends on what it found on the first: if the ticket has an invoice number, it goes to the order history; if it does not, it searches by customer and date; if a photograph of the damage is missing, it drafts a request for one. Sending that request waits for an employee’s consent, and the decision to accept the claim belongs to a person — always. The agent shortens the assembling; it does not settle the case.
An assistant for the planner in the production office
An example of level one. The assistant reads open work orders, material availability and similar past orders, then prepares a proposed running order for the planner, with reasons: what can start immediately, what is waiting on material, where resources clash. It writes nothing — the planner reads the note and changes the schedule themselves. This is often the right first agent in a manufacturing company: it starts in the production planning office, on data already in the system, not on the shop floor.
Where an agent’s data goes, and what about the AI Act
If an agent touches personal data — and a customer record, a warranty claim or an email from a business partner is personal data — the decisions are the same as in any project with a language model: which data leaves the company, who it reaches, on what lawful basis, and where the model runs. The model provider’s role is established separately for each processing operation; how we do that, and how we split the roles between you, us and the provider, is on our page about security and GDPR. An agent adds one question: since it decides for itself which system to look into, the read scope has to be limited technically, not only by instruction.
The AI Act in two sentences. If an agent talks to people — replies to a customer, writes to a business partner — Article 50 has applied since 2 August 2026, that is, the duty to disclose that the person on the other end is dealing with a machine; we always disclose it. The remaining duties follow from how the use case is classified, not from the mere fact of using an agent — we keep a dated timeline, and what applies today, on the page about our AI Act technical compliance sprint.
This describes the technical and organisational side, not legal advice — the legal assessment belongs to your lawyer or data protection officer.
Three tests before you build an agent
The question “how do you build an AI agent in a company” has less to do with technology than the quotes suggest. Before anyone picks a platform or a model, three tests are worth running. Each has a clear result.
- The one-page test. Can the process owner write three lists on a single page: what the agent may read, what it may write, what it must never do? If the write list is empty, you need an assistant (level 1) — cheaper and faster. If nobody can write that page, the process is not ready for any system, agentic or otherwise; it has to be described first.
- The undo test. For every item on the write list: how is it undone, who notices the mistake, and how fast? Anything with no undo lands on the list of operations behind human consent. If the whole value of the project sits in an action that cannot be undone and cannot wait for approval, this is not a job for a first agent — and an honest supplier says so before the contract, not after the pilot.
- The fifty-case test. Can you pull 50 historical cases and mark, for each, what the correct outcome was? The result of the test is a spreadsheet: 50 rows, a column of input data, a column of verdicts. Without that sample a parallel pilot has nothing to compare its results against, and “it works well” stays an impression. That same sample is the only honest way to choose a model: several candidates, the same 50 cases, measured agreement and cost.
If the three tests pass, the build has a natural order: the page of lists, the sample of fifty cases, the approval queue and the log, then the tools — increasingly through MCP — and the loop on a platform such as n8n or in code. The model is chosen last, against measured quality on your sample. That is how you get an AI agent you can keep running, rather than one you can only demonstrate.
When this is not a job for an agent
The anatomy also yields a list of disqualifiers — separate from the question of whether an agent beats ordinary automation:
- Nobody owns the three lists. If there is no one to say what the agent may read and write, there is no one to approve or correct it either.
- The key action has no undo and cannot wait. An agent with no approval queue is a system running unsupervised from day one, and we do not build those.
- There are no fifty cases. The process is too rare or too young to sample — so there is no way to measure whether the agent works, and the pilot will end in an impression.
- The process changes every month. An agent fixes rules in place; if there are none yet, it will fix chaos in place, and every change will mean corrections to the lists, the tools and the sample.
- The task is one of those we do not take on — systems running without approval from day one, cold-email machines, scoring candidates in recruitment. The full list, with reasons, is on the what we don’t do page.
And if the order of the steps can be written down in advance, no agent is needed — when an agent makes sense and when it is overkill is settled on the service page, not here.
What next
An AI agent is not a model but six decisions, of which the model is the last: a goal with an end criterion, tools split into read and write, a loop with a budget and a log, memory maintained by people, four permission lists — and only then a model chosen against measured quality on your sample. What a project like that looks like from the permission lists through to the pilot, and what comes out of each stage, is set out on the page about AI agent implementation.
Describe your process to us in a few sentences. We will tell you whether we see an agent, an assistant or ordinary automation in it — including when the answer is “not worth it yet”.