AI agents for business

An AI agent is software that is given a goal, a set of tools and a set of rules, and works out for itself which steps to take. A normal automation follows the same path every time. An agent reads the request in front of it, looks things up in your systems, decides what should happen next and prepares that action. I design and build agents for UK businesses on one condition: a person approves anything that leaves the business or changes a record that matters.

If you only want an AI model added at one step of a fixed process, my AI automation service is the closer fit. For an assistant that answers staff questions from company documents, see custom GPT and AI assistant development.

What an agent does that a fixed workflow cannot

Most business automation is a chain of fixed steps: a form is submitted, a contact is created, an email goes out, sales get a notification. That works when every case looks alike. It breaks down when the right next step depends on what the request says and on what your systems already know. Is this person an existing customer? Do you cover their postcode? Is the item in stock? Is last month’s invoice still unpaid?

An agent handles that kind of request by calling tools. Each tool is a small, defined capability, such as “find this contact in the CRM” or “list free slots in the diary”. The agent, built on a large language model, chooses a tool, reads what comes back and decides what to call next. The mechanism is usually called function calling, and the Model Context Protocol is a newer standard for exposing tools to a model. In practice, a member of staff stops collecting facts from four screens and starts reviewing a prepared case with a recommendation attached.

Who this suits, and when an agent is the wrong tool

An agent is worth considering when the same kind of request arrives often enough to cost real staff time, when deciding what to do means checking two or more systems, and when the judgement involved can be written down clearly enough for a new employee to follow.

It is the wrong tool more often than the sales pitches suggest. If the steps never change, a fixed workflow is cheaper, quicker to run and easier to audit, and I will say so. If your core systems cannot be reached by software at all, the agent has nothing to work with. And if every case carries legal, medical or financial risk for the person on the other end, the human review becomes the whole job and the agent adds little.

Agent, chatbot, assistant or workflow

Jobs I would consider giving an agent

These are examples of the shape of work agents handle well, not a menu. The right first job is usually the one your staff grumble about most.

The limits written into every agent

The design question I spend longest on is what the agent must not do. These limits, usually called guardrails, are enforced through permissions and code, not only through instructions to the model, because instructions on their own can be ignored or overridden.

• No money moves without a person. Refunds, payments, discounts and credit notes are proposed by the agent and carried out by a human.
• Nothing external goes out unapproved at first. Every email or message waits in an approval queue, which is the human-in-the-loop step. Whether any type of message can later go automatically is your decision, made on evidence from the logs.
• Read-only unless writing is essential, and no deleting. Each tool gets the narrowest access that does its job, through its own key. An agent can flag a record for removal but cannot remove one.
• Incoming text is data, never instructions. Emails, attachments and web pages can contain wording designed to steer a model, a technique known as prompt injection. The agent’s tools and permissions are set so that such text cannot widen what it is allowed to do.
• Hard stops on steps and spend. Each task has a ceiling on tool calls and cost, so a confused agent hands over to a person instead of going round in circles.
• Decisions that affect people stay with people. UK GDPR has specific rules for decisions made solely by automated means that have legal or similarly significant effects on someone, such as turning down a job applicant or refusing credit. The safeguards include a route for the person to get human review and to contest the outcome. I design agents so that this kind of decision is always made by a person, with the agent only preparing the case. The Data (Use and Access) Act 2025 amends these rules, so check the ICO’s current guidance on automated decision-making for your use.

How I run an agent build

1. Map the decision. I sit down with whoever does the work today and write out how they decide, including the exceptions they handle from memory. I also gather a set of real past cases, with personal data removed or kept to the minimum, to test against later.
2. Design on paper. A short specification lists every tool, the access each needs, the points where a person approves, what is logged and when the agent must stop and hand over. You sign it off before anything is built.
3. Build in a test environment. The agent runs on test data or read-only connections. The platform follows what you already use: an agent step inside n8n or Make, or code that calls a model provider directly.
4. Test against past cases. I run the agent on the collected cases and compare its recommendations with what your team actually did. Where they differ, you and I work out whether the agent or the original decision was wrong, and adjust.
5. Run it alongside your staff. The agent works on live requests but only proposes, while your team carries on as normal and compares the two. This is where confident but wrong answers surface, and where the instructions get their final edits.
6. Go live with approval. Staff approve each proposed action from a queue in the inbox or chat tool they already use.
7. Review the log, then hand over. After the first weeks of live use, you and I go through what was approved, edited and rejected. That record decides whether any step can safely become automatic.

Where agent projects go wrong

• Starting from a demo, not a process. An impressive run on a handful of tidy examples says nothing about the awkward cases that make up real work.
• No record of what happened. Without a log of each step and the reason for it, nobody can answer a customer complaint or a subject access request about the agent’s work.
• No owner. Prices, policies and staff change. If nobody is responsible for updating the agent’s instructions and tools, its advice drifts out of date.
• Personal data sent to a model provider unchecked. You remain the controller of your customers’ data, and the provider normally acts as your processor under its data terms; the split is explained in data controller and data processor. Where data is processed, how long it is kept and whether it is used for training all need checking before go-live, not after.

What you receive

• A map of the decision process and the signed-off specification, including the permission list for every tool
• The working agent, connected to your systems through accounts and keys that you own
• The test set of past cases and the results of running the agent against it
• An approval queue and a complete activity log
• A runbook covering how to pause the agent, change its instructions, replace its keys and add a badly handled case to the test set
• A description of the data flows to support your data protection impact assessment
• A handover session for the person who will own the agent day to day

Cost and pricing

There are two separate costs. The build is priced once the mapping stage has shown how many tools and approval points the agent needs, and the quote is written in pounds sterling and agreed in writing before the build starts. The running cost is what the model provider charges for usage, plus any platform subscription. Providers bill per token processed, often in US dollars, so the monthly figure moves with volume and the exchange rate. I estimate it from the test runs before you commit, and set a spending limit in the provider account.