What an AI agent is
An AI agent is software that uses a large language model to plan and carry out multi-step tasks. Instead of only answering a question, it can look things up, call APIs, update a CRM record, create a ticket or send a draft for approval. The model decides which step to take next; your code defines which tools it may use and what needs a human sign-off.
Where agents work well today
| Area | Example agent | Human role |
|---|---|---|
| Customer support | Reads a ticket, checks order status, drafts a reply and suggests a refund | Approves refunds and sensitive replies |
| Sales operations | Researches inbound leads, enriches the CRM, books follow-ups | Reviews high-value accounts |
| Finance | Matches invoices to purchase orders and flags exceptions | Approves payments |
| IT & internal ops | Handles access requests and common how-to questions | Approves access changes |
| Research | Collects and summarises information from many sources | Validates conclusions |
How we keep agents safe and reliable
- Narrow scope: each agent has a clear job and a limited set of tools
- Least-privilege permissions on every API and data source
- Approval steps before money moves, records are deleted or customers are contacted
- Full audit trail of every reasoning step and tool call
- Evaluation suites and monitoring for success rate, cost and errors
- A simple off switch and fallbacks to human handling
Technology
Anatomy of a production AI agent
Behind every reliable agent is ordinary, careful software engineering. The agent receives a goal and context, such as a new support ticket and the customer’s history. It has a list of tools it may call, each with a clear description, input schema and permission scope — “look up order status”, “issue refund up to $50”, “draft reply”. A planning loop lets the model choose the next tool, observe the result and decide what to do next, within a maximum number of steps.
Around that loop sit the controls that make agents safe in a business: approval queues for sensitive actions, timeouts, spending limits, structured logs of every step, and evaluation suites that replay real past cases to check the agent still behaves correctly after any change to prompts, tools or models. When the agent is unsure, it hands over to a person with a summary of what it found — which is often valuable on its own.
Choosing the first workflow to automate
- High volume — it happens dozens or hundreds of times a week
- Clear success criteria — you can tell whether the outcome was right
- Information is available digitally — in tickets, emails, CRMs or documents
- Low cost of a mistake, or an easy approval step before actions take effect
- A team that is keen to try it and give feedback
Workflows that tick these boxes typically show measurable time savings within a few weeks of a pilot.
Agent patterns compared
“AI agent” covers a range of designs, from a single model call with a couple of tools to several cooperating agents. More autonomy brings more capability, but also more cost, latency and room for error. We start with the simplest pattern that solves the problem and add autonomy only where it clearly pays off.
| Pattern | How it works | Best for | Trade-offs |
|---|---|---|---|
| Tool-calling assistant | One model chooses from a small set of tools in a single conversation | Answering questions with live data, simple lookups and updates | Limited planning; easy to test and cheap to run |
| Workflow with AI steps | A fixed, coded workflow where AI handles specific steps such as classification or drafting | Repeatable business processes with clear stages | Predictable and auditable; less flexible with unusual cases |
| Planning agent | The model breaks a goal into steps, executes tools and adjusts as it goes | Research, investigation and multi-step back-office tasks | More capable; needs strong guardrails, budgets and evaluation |
| Multi-agent system | Specialised agents hand work to each other under a coordinator | Large tasks with clearly separable roles | Highest complexity and cost; justified only for genuinely broad tasks |
In our experience most business value comes from the first two patterns.
Tools and permissions: designing what an agent can touch
An agent is only as safe as the tools it is given. Every tool is a small, well-defined function with typed inputs, clear descriptions and its own permission checks — never a generic “run any query” or “call any API” capability. Read-only tools are separated from tools that change data, and anything that sends money, emails customers or deletes records goes through an approval step.
- Least privilege: each tool uses a service account scoped to exactly what it needs
- Input validation on every tool call, independent of what the model “intended”
- Rate limits and spending caps per run, per user and per day
- Human approval for irreversible or customer-facing actions
- Complete logs of prompts, tool calls, results and decisions for audit
- A kill switch that disables the agent or individual tools instantly
How we evaluate an agent before and after launch
Agents fail in different ways from ordinary software: they may pick the wrong tool, loop, misread a result or give a confident but wrong answer. We build an evaluation set of realistic tasks — including awkward and adversarial ones — with the expected outcome for each. Every change to prompts, tools or models is run against this set before release, so improvements in one area do not silently break another.
| What we measure | Why it matters |
|---|---|
| Task success rate | Does the agent reach the right outcome? |
| Tool accuracy | Does it call the right tools with the right inputs? |
| Escalation quality | Does it hand over to a person when it should? |
| Cost and time per task | Is it cheaper and faster than the current process? |
| Safety violations | Does it ever attempt an action outside its policy? |
After launch, a sample of real runs is reviewed every week and failures are added to the evaluation set.
A typical delivery plan
-
Process mapping1–2 weeks
Document the current workflow, systems, decision rules and exceptions with the people who do the work today.
-
Prototype2–3 weeks
Build the agent with read-only tools against test data and run it on the evaluation set.
-
Shadow mode2–4 weeks
The agent runs alongside your team, proposing actions that people approve or correct.
-
Supervised rollout2–4 weeks
Low-risk actions become automatic; higher-risk ones stay behind approval.
-
Operate and improveOngoing
Monitor cost, quality and escalations; extend to new cases as confidence grows.
Timelines are typical for a single, well-defined workflow.
Questions to ask before you build an agent
- Which specific task will it do, and how is that task measured today?
- What happens when the agent is wrong — and who notices?
- Which systems does it need, and do they have usable APIs?
- Which actions must always need human approval?
- What does a run cost, and what is the budget at expected volume?
- Who owns the agent after launch?
Agents are often built on top of retrieval-augmented generation for knowledge and business process automation for the surrounding workflow.
Getting started
We usually start with one well-defined workflow that runs dozens or hundreds of times a week, measure time saved and accuracy over a pilot, then expand. If you are earlier in your AI journey, start with generative AI development or our wider AI and data engineering services.
This page is part of AI Development & Data Engineering Services — see the full overview for related services, approach and pricing.