AI Agents for Business Process Automation: Build or Buy?

The build-or-buy question used to be answered by cost. Buying was cheaper because building meant a year of engineering. AI-accelerated delivery has changed that arithmetic enough that cost alone no longer decides it, and the better question is now about fit: does this process look the same in your business as it does everywhere else, or is the way you do it part of why customers choose you?

That single distinction resolves most agent decisions. This article works through it in detail, covers the hybrid pattern that suits most mid-sized operators, and sets out the controls that make autonomous action safe enough to deploy. Our delivery approach is described on the AI agents and automation page.

What an agent is, in operational terms

Strip away the marketing and an agent is three things: a model that can reason over context, a set of tools it is permitted to call, and a loop that lets it take a step, observe the result and take another. The interesting part is not the model, it is the tool permissions. An agent with read access to your CRM is an assistant. An agent that can update records, send emails and issue refunds is a member of staff, and should be governed like one.

Where agents genuinely outperform rule-based automation

• Unstructured input: documents, emails and calls where the format varies by sender
• Long-tail branching, where writing every rule would take longer than the process saves
• Judgement-shaped tasks with a reviewable output, such as drafting, triaging or summarising
• Cross-system work that would otherwise require a human to be the integration layer

Conversely, if a process is fully deterministic and high-volume, a plain script remains the correct answer. It is cheaper per run, easier to test and does not fail creatively. Using a model where an if-statement would do is one of the most common sources of unnecessary cost we see in audits.

The case for buying

Buy when the process is generic, the vendor's version is already good, and the data involved is not a competitive asset. Meeting transcription, calendar coordination, expense categorisation, first-line IT triage and inbox summarisation all fall here. The vendor has seen millions of examples of these workflows, they will out-invest you in the details, and there is no strategic value in owning the implementation.

What to check before you buy

1. Data residency and training use: is your data used to improve their model, and can you opt out
2. Export: can you retrieve everything the agent produced if you leave
3. Integration depth: does it write into your systems or only read from them
4. Per-seat versus per-action pricing, and what happens to the bill when usage triples
5. Audit logging: can you reconstruct exactly what the agent did and why

The last point is the one most often skipped. If a tool cannot show you the reasoning and the tool calls behind an action, you cannot defend that action to a customer, an auditor or a regulator, which quietly caps how much authority you can ever grant it.

The case for building

Build when the workflow encodes something specific to your business: your pricing logic, your compliance obligations, your service model, your data. In these cases the generic tool does eighty percent of the job and the missing twenty percent is the part that matters, and configuring around the gap produces a fragile arrangement that breaks whenever the vendor ships an update.

The signals that point to build

• You are paying staff to bridge two tools the vendor will never integrate
• The process touches data you cannot send to a third party for contractual or regulatory reasons
• Your version of the workflow is a differentiator customers notice
• You are already paying for three overlapping tools to cover one process
• The per-seat cost scales with headcount while the value scales with transactions

The economics have shifted here more than people realise. When architecture drafting, code generation, test coverage and QA are all AI-assisted, a bespoke agent layer over existing systems is a matter of weeks. We covered how that compression changes scoping in building AI software with AI, and what it recovered in practice in how we removed 80 hours of weekly admin.

The hybrid pattern most operators should use

In practice the right answer is usually both, arranged in layers. Buy the commodity capabilities. Build the orchestration and the proprietary steps. Keep your data in a layer you own, so that any individual vendor can be swapped without a migration project.

What that looks like architecturally

A unified data layer holds the operational truth. Bought tools read from and write to it through an integration surface you control. A custom orchestration layer decides which agent handles what, applies your business rules, enforces approval gates and writes the audit trail. The bought tools become interchangeable components rather than systems of record, which is exactly the position you want to be in when a vendor changes pricing or gets acquired.

This is also the arrangement that keeps inference costs controllable, because the orchestration layer can route simple classifications to a small cheap model and reserve the expensive one for genuinely hard reasoning. Teams that send everything to the largest available model are usually paying several times what the workload requires.

Making autonomous action safe

The question that decides deployment is not accuracy, it is reversibility. Score every action on two axes: how confident the system is, and how expensive the action is to undo. Cheap and reversible actions can proceed autonomously at moderate confidence. Expensive or irreversible actions require human approval regardless of confidence.

The controls worth building in from day one

1. Confidence thresholds per action type, tuned from real outcomes rather than guessed
2. Approval queues that present the agent's reasoning alongside the proposed action
3. A complete audit trail: inputs, tool calls, outputs and the human decision
4. Spend and rate limits per agent, so a loop cannot run up a bill overnight
5. A kill switch that disables tool access without taking the whole system down
6. An evaluation set of real historical cases, re-run whenever a prompt or model changes

The evaluation set is the one teams skip and later regret. Without it, every prompt change is a guess, and you will eventually improve one behaviour while silently breaking another. It costs a day to assemble and it is the difference between a system you can iterate on and one you are afraid to touch.

A decision sequence you can run this week

1. List the processes consuming the most staff hours, with an honest hours-per-week figure for each
2. For each, mark whether the process is generic or specific to how you operate
3. For the generic ones, trial a bought tool against a real week of work, not a demo dataset
4. For the specific ones, define the smallest agent that removes the largest single step
5. Score each candidate action for reversibility and set the approval gate before you build
6. Ship one, measure hours recovered over four weeks, then decide on the next

Almost every audit we run finds the same shape: a handful of processes carrying most of the load, and a long tail that is not worth automating yet. The discipline is doing the top one properly, proving the hours, and resisting the urge to launch six agents at once.

The bottom line

Buy the parts of your operation that look like everyone else's. Build the parts that do not, and own the data layer underneath both. If you want a concrete read on which of your processes fall on each side, talk to us with a list of where the hours go and we will map it against build, buy and leave-alone before anything is committed.