What is an AI agent? Examples for businesses.

An AI agent is software that uses a language model to carry out a task in several steps across your systems. It reads what comes in, decides which step to take next, calls a tool such as your CRM, ERP or inbox to take it, and checks the result. It works inside limits you set.

This article is for managers who keep hearing the word and want to know what it means for their operation, and for people about to build their first agent in a no-code tool. For the second group, the section on building one yourself says where that works and where it stops working.

Every agent has the same parts, whatever tool or framework it is built with:

• A language model that reads the input and decides the next step.
• Tools: the specific actions the agent may take, such as looking up an order, reading a PDF or drafting a reply. An agent can do nothing its tools do not allow.
• Instructions that set out the goal, your rules and what to do when a case is unclear.
• State: a record of the case so far, so the agent can pick up where it left off after waiting for data or an approval.
• Limits: approval steps, a cap on steps and spend per run, and a log of everything it did.

The word is used loosely, for chatbots with a search function and for fixed workflows with one model call in the middle. A quick test: does the software choose its own next step, and can it take that step in another system? If both answers are yes, it is an agent.

A chatbot answers questions in a conversation. An automation runs the same fixed steps every time, following rules someone wrote down. An AI agent uses a model's judgement to choose its steps and tools to carry them out in your systems. Which one you need depends on how much judgement the work takes.

Most real processes mix rules and judgement. A supplier invoice, for example, needs reading and a judgement against the purchase order, then gets booked through steps that never change. We build the fixed steps as plain automation and give the model only the steps that need it, because rules cost less to run and are easier to check.

If you can write every step of your process as a rule, you do not need an agent. Our guide on how to automate business processes shows how to choose between rules and AI for each step.

Agentic AI is the general term for AI systems that work towards a goal in several steps: they plan what to do, use tools to act in other systems and check each result. The model at the centre is usually a generative AI model. An AI agent is one such system, built for a specific task.

In business, agentic AI mostly shows up as agentic workflows: a process such as invoice approval, run across several systems by an agent. We build them as an explicit sequence of states, so every step can be traced, retried and reviewed, and high-impact actions wait for a person. Our page on agentic workflow automation covers when the approach fits and how we build it.

Many software products now carry the label agentic. Before you compare them, apply the quick test from the first section of this article to each one.

Useful business agents mostly do the work between systems: reading what arrives, looking up facts in two or three places and preparing the next action for a person. The three examples below are illustrative. Each is a typical case of the processes we build agents for, and each shows what the agent does and what a person still decides.

Intake: from email and attachment to a clean record

For example, a wholesaler receives purchase orders as PDF attachments, each customer with its own layout. Someone opens every email, retypes the lines into the ERP and chases the customer when an article number is wrong.

An agent reads the email and the PDF, extracts the order lines and delivery date, and checks each line against the ERP: does the article exist, is the price the agreed one, is there stock? Orders that pass are prepared for entry. The rest go to a person with the problem named and a drafted question to the customer. The same pattern fits referral intake in a hospital department.

The shared inbox: sorting, looking up and drafting

A typical customer service inbox mixes delivery questions, returns, address changes and complaints. Most replies need data from the order system or CRM before anyone can write them.

An agent classifies each email by intent and urgency, pulls the order or account data it needs and writes a draft reply inside the helpdesk ticket. A person checks, edits and sends it. Refunds and cancellations are prepared by the agent and go through after approval. When the edit rate for a category stays low, that category can move to direct sending, while complaints stay with people.

Exception handling: working out what went wrong

Exceptions are the cases that fall out of the normal flow: a shipment that misses a milestone, an invoice that does not match its purchase order, a payment that fails. Each one sends someone through several systems before they can act.

At a freight forwarder, for example, an agent picks up a delayed shipment, checks the carrier status, the customs documents and the delivery terms agreed with the customer, and works out the likely cause. It drafts an update for the customer and proposes a rebooking. A planner reviews the evidence and approves, changes or rejects the proposal before anything is rebooked.

The three share a profile. The work repeats often, follows rules someone can explain, needs data from several systems and has an outcome you can check. Agents are a poor fit when volume is so low that a well-designed form would do, or when the rules change every week and nobody owns them.

You can build a useful AI agent yourself in a no-code agent builder when it reads and drafts, works with one or two systems that have ready-made connectors, and a person checks every output. Have it built when it writes to systems of record, handles personal or regulated data, or needs tests, audit logs and someone responsible when it fails.

What building an AI agent involves

The steps are the same in a no-code tool and in code:

1. 01Pick one process and write it down. The trigger, the steps, the rules, the known exceptions and what a finished case looks like. If nobody can say what should happen with an exception, settle that before you build.
2. 02Collect past cases. Gather real examples with the outcome a person produced. They show how varied the input is, and they become your test set.
3. 03Define the tools. List every action the agent may take, whether it reads or writes, and its limits, such as a maximum refund amount. Give the agent its own credentials with only those rights.
4. 04Write the instructions. The goal, your rules, the output format and what to do when a case is unclear, which is usually to hand it to a person.
5. 05Decide the approval steps. Mark which actions wait for a person, and what that person needs to see to decide quickly.
6. 06Test, then run alongside the team. Run the agent on the past cases first. Then let it draft on live work while people review, and widen what it does as the results hold up.
7. 07Monitor it. Log every run, watch where reviewers edit or reject, and rerun the tests after any change to the instructions, the model or the tools.

Our AI agent spec template puts these decisions in one document before the build starts.

When a no-code agent builder is enough

No-code agent builders and automation platforms with AI steps are a good place to start. They fit when:

• The agent reads, summarises, classifies or drafts, and a person acts on the result.
• It works with one or two common systems that have ready-made connectors.
• Volume is modest and a wrong output takes a few minutes to correct.
• Someone on your team owns the flow and has time to fix it when a connector changes.

A first version built this way also shows what the process needs, which makes a later build easier to scope.

When to have an AI agent built

The picture changes once the agent acts without a person in between or the process has to stand up to an audit. Have it built, by your own engineering team or a supplier, when:

• It writes to systems of record such as your ERP, core banking system or patient record, or sends anything to customers.
• It needs systems without ready-made connectors: older software, internal databases or file exports.
• It handles personal or regulated data, and you have to show where the data goes and who approved what.
• You need a test set that runs before every change, and logs that explain a decision months later.
• The flow has grown to so many branches that nobody can change it safely.

If you are unsure whether your organisation is ready for an agent at all, the AI readiness checklist helps you score the process, the data and the ownership before you choose a route.

An agent needs limits wherever an action is hard to undo or leaves your organisation: payments, refunds, messages to customers and changes to records. Three controls do most of the work: tools scoped to what you permit, approval steps before high-impact actions, and a log of every run that shows what the agent did and why.

• Scoped tools. The agent can only call the actions you give it, with limits written into the tool itself, such as a maximum amount or a fixed list of recipients. Actions it should never take have no tool at all.
• Approval steps. High-impact actions pause and show a named person the proposed action and the evidence behind it. That person approves, edits or rejects, and the decision is recorded.
• Logging. Every run records its input, each model and tool call and every approval, so you can answer questions about any case later.

We start agents in drafting mode, with people reviewing, and give them more room as the results justify it. Our article on human-in-the-loop AI agents covers approval checkpoints, risk tiers, audit trails and fallbacks in depth.

Test an agent on real cases from your own history before it handles live work. Take past cases with the outcome a person produced, run the agent on them and compare: did it reach the same result, call the right tools and hand over the cases it should have? Rerun the same set after every change.

A test for an agent checks more than the final output:

Include normal cases, known exceptions and a few inputs written to mislead the agent. Once it runs, reviewers' edits show where it struggles, and every confirmed failure becomes a new test case. Our guide to LLM evals before every release explains how to build the test set, grade outputs and block a release that scores worse.

When we build AI agents for clients, the test set comes first, made from the client's own historical cases, and no change to instructions, model or tools reaches production without passing it.

What does an AI agent cost?

The cost of an AI agent depends mainly on the number of systems it works with, the quality of their APIs, how many exceptions the process has and how much of it needs a review screen. Model usage is usually the smaller part. Running the agent adds monitoring and changes as your process moves.

A no-code agent costs a subscription and your team's time. For an agent we build, we agree scope and timeline in a written plan after discovery.

Is an AI agent safe?

An AI agent is safe to use in business when its limits are designed in: tools scoped to what you permit, approval before high-impact actions, a log of every run and a test set that every change has to pass. Without those, an agent can act on a wrong reading of a document before anyone notices.

Also check where the model runs and what the provider stores. We can keep processing in the EU through EU-hosted providers or your own cloud account.