AI agents for business: build, buy or customise

Many organisations now have someone asking whether an AI agent could take over a slow, repetitive process. The demonstrations look convincing, and the products are easy to try. The harder questions come later: what the agent is allowed to touch, where its data comes from, and who checks its work before it acts.

AI agents for business are software systems that use a language model to plan a task, call tools such as a CRM or a ticketing system, check the result and continue until a goal is met. The choice between buying, configuring and building one depends mostly on whether the agent can reach governed data and tools safely.

This guide is for the person who has been asked to decide whether, and how, the organisation should use AI agents. It sets out the three routes to an agent, what each costs in effort and control, what building one involves, and the data it needs. It also covers how to design checkpoints into the workflow, which use cases justify a custom agent, and which processes are better served by simpler automation.

What an AI agent does in a business

An AI agent is software that is given a goal rather than a single instruction. It uses a language model to decide the next step, calls a tool to carry that step out, reads the result and decides again. A tool might be a search over your documents, a query against a warehouse, an update to a CRM record or a draft email. The loop continues until the goal is met or the agent hands the work to a person. Our guide to how generative AI agents are built covers the architecture in more detail.

This differs from rules-based automation. A rules-based workflow follows the same path every time and stops when an input does not match. An agent can adjust its path when it meets new data or an obstacle. That flexibility is the reason to use one, and it is also the source of most of the risk. An agent that can choose its own next step can also choose a wrong one.

What agents are good at in practice

• Customer support: answering questions from a knowledge base, gathering details and drafting a resolution for a person to approve.
• Finance and operations: chasing unpaid invoices, matching payments to accounts and preparing a first draft of a cash-flow view.
• Sales: researching target organisations, summarising what is known about an account and drafting tailored outreach.
• Internal knowledge work: finding the right policy, contract clause or procedure and explaining it in context.

The common thread is multi-step work that needs judgement within clear limits. The wider idea of systems that choose their own steps is covered in our explainer on agentic AI and when it is worth building.

Off-the-shelf, configured or custom agents

There are three routes to an agent. Each trades effort against control, and the right one depends on how specific your process is and how much of your own data the agent must reach.

Off-the-shelf agents

Off-the-shelf agents are products built for one job, such as support triage, meeting notes or lead research. You subscribe, connect your accounts and start. They are quick to try and need little engineering. The limit is that the vendor decides how the agent behaves, what it logs and how it connects to your systems. If your process matches the product closely, this is often the sensible choice.

Configured agents on a platform

Many CRM, productivity and service platforms now include agent builders. You configure an agent with instructions, connect it to the data the platform already holds and set which actions it may take. This suits organisations whose work already sits in one platform. Control is greater than with a standalone product, but the agent sees only what the platform sees, and anything outside it needs a connector. Our guide to choosing AI automation tools that fit your data sets out the criteria for comparing these options.

Custom AI agents

Custom AI agents are built for your process, on your data, with your rules. You choose the model, the tools, the permissions, the checkpoints and the evaluation. The effort is higher, and you need someone to own the agent after go-live. In return you get an agent that works across systems, follows your business logic and can be audited from end to end.

• Effort: low for off-the-shelf, moderate for configured, highest for custom.
• Control over behaviour and logging: limited for off-the-shelf, partial for configured, full for custom.
• Reach across systems: one product, one platform, or whatever you connect through governed access.
• Ownership after launch: the vendor, shared with the platform, or you and your delivery partner.

The model is rarely the deciding factor. What decides the route is whether the agent can reach governed data and tools safely.

What building AI agents involves

Building AI agents is mostly integration and governance work. The prompt and the model choice take less time than most teams expect. The bulk of the effort goes into the following areas.

• Defining the task: the goal, the inputs, what a finished result looks like and when the agent must stop.
• Choosing tools: the specific actions the agent may take, each with a narrow, documented interface.
• Connecting data: governed access to the records and documents the agent needs, and nothing more.
• Writing the business logic: the rules the agent must follow, held outside the prompt where possible so they can be tested.
• Evaluation: a set of real cases with known good outcomes, run before launch and after every change.
• Monitoring and ownership: logs of every step, alerts when behaviour changes and a named owner.

Evaluation deserves particular attention. A language model can state something false with complete confidence, and an agent can then act on that statement. Grounding the agent in your own records and checking its outputs against them reduces this risk. Our guide to detecting and preventing AI hallucination explains the techniques.

Building also involves deciding what the agent must not do. A clear list of refused actions, such as sending money, deleting records or contacting a client's customers without approval, is as important as the list of permitted ones. Both lists should be enforced in the tools themselves, not only described in the instructions.

Enterprise AI agents and the data they need

Enterprise AI agents work across departments, so they meet the data problems every organisation already has. Customer records differ between the CRM and the finance system. A product code means one thing in sales and another in operations. Documents are out of date or stored in several places. A person works around these gaps from experience. An agent will not, and it will act on whichever version it finds first.

This is why we treat the data foundation as part of any agent build. An agent needs three things from your data.

• One version of the truth: data held in one governed store and cleaned in stages, from bronze to silver to gold, so the agent reads the same figures your teams trust.
• One agreed definition of each business term: a semantic layer that tells the agent what a term such as overdue or active account means in your organisation.
• A governed route to reach it: access controls, business logic and auditable lineage between the agent and the data, so it can read and act without copying records somewhere ungoverned.

Model Context Protocol (MCP) is one standard way to provide that route. An MCP server exposes specific tools and data to a model, with permissions applied on the server side. The agent asks for what it needs and receives only what it is allowed to see. Our guide to what AI-ready data means and how to test it sets out how to check whether your data is ready for this.

An agent amplifies whatever it sits on. Over strong data it saves time. Over weak data it makes mistakes faster.

Designing the agent workflow with checkpoints

An AI agents workflow should be designed as a sequence of steps with defined points where a person or a rule checks the work. The level of checking should match the cost of a mistake.

Match autonomy to risk

Low-risk, reversible steps, such as searching documents or drafting a summary, can run without approval. Steps that change a record, contact someone outside the organisation or move money should need approval until the agent has a measured track record. Some steps should always need a person. Our guide to keeping a human in the loop explains the patterns for review, escalation and override.

Build in the controls

• Permission scopes: give each tool the narrowest access that does the job.
• Limits: cap the number of steps, the time and the spend for each run.
• Escalation: when the agent is unsure or meets a case outside its rules, it hands over with the context it has gathered.
• Logging: record each decision, tool call and result so any outcome can be traced.
• A stop control: a way for the owner to pause the agent at once.

Where an agent coordinates several systems, the order of steps and the handling of failures matter as much as the model. Our explainer on workflow orchestration for AI covers retries, timeouts and alerts.

Use cases that justify a custom agent

A custom agent justifies its effort when the work is frequent, spans several systems and depends on your own rules and data. Typical examples follow.

• Support resolution: an agent reads the ticket, checks account and device data, searches governed documentation and drafts or sends a resolution. At 1NCE, AI automation for customer engagement resulted in 60% of tickets handled to a human standard.
• Document-heavy operations: an agent extracts data from contracts, certificates or job sheets, checks it against existing records and routes exceptions to a person.
• Account and portfolio reporting: an agent assembles figures from several systems into a standard pack, with each number traced to its source.
• Order and exception handling: an agent investigates a delayed order across ERP, carrier and inventory data, then proposes the next action for approval.

In each case the value comes from reaching several governed sources and applying business logic consistently. An off-the-shelf product rarely reaches all of them, and a platform agent rarely reaches beyond its own platform.

When simpler automation is the better choice

Not every process needs an agent. If the steps are the same every time and the inputs are structured, a rules-based workflow is cheaper to run, easier to test and more predictable. If the task is a single step, such as classifying an email or extracting fields from an invoice, one model call inside an existing workflow is usually enough. Our guide to AI automation and where it pays off explains how these options compare.

• Use rules when the path is fixed and the inputs are predictable.
• Use a single AI step when one judgement is needed inside an otherwise fixed process.
• Use an agent when the path varies, several tools are needed and the agent must decide the order.

Choosing the simpler option is not a compromise. It is often the right answer, and it leaves budget for the process that does need an agent. We will say so when an agent is not the right fit for a process.

How to start small

The safest first agent does one bounded job well. Start with a task that is high in volume, low in risk and easy to check.

• Pick one workflow with a clear owner and a metric you already track.
• Write the playbook: the steps a skilled person follows, the exceptions and the point at which they would ask for help.
• Check the data the agent needs: where it lives, who owns it and whether it agrees across systems.
• Connect only the tools that workflow needs, with narrow permissions.
• Run the agent in draft mode first, with a person approving every action.
• Measure against the metric, then widen the agent's autonomy step by step.

A first win that pays for itself makes the case for the second. If you want a structured view of readiness before choosing a workflow, our free AI readiness assessment scores strategy, people, data and change on the spot, with no email gate.

Where this leaves you

The build, buy or customise decision is less about the model than about reach and control. An off-the-shelf agent suits a process that matches the product. A configured agent suits work that already sits inside one platform. A custom agent suits frequent, multi-system work that depends on your own rules, and it needs governed data, narrow tools, checkpoints and an owner.

Whichever route you choose, check the data first, design the checkpoints before launch and start with one workflow you can measure. Where the path is fixed, use simpler automation and keep the agent for the work that needs it.

Our AI workflow automation and agents service designs and builds agents on governed data, with the checkpoints, logging and ownership described above, and our AI development service ships them to production. We scope the data foundation first, build the agent on it and stick around past go-live. If you are weighing an agent for a specific workflow, Talk to us and we will tell you plainly whether an agent, a simpler automation or neither is the right fit.

Frequently asked questions