Build vs Buy AI: Copilot, Automation Platform, Custom Agent or Custom Model?

Before deciding whether to build your own AI, establish what the business needs it to do.

There are four different choices to compare:

1. Should we use a packaged AI product?
2. Should we configure an automation or agent platform?
3. Should we build a custom AI application or agent?
4. Should we train or materially customise a model?

Those options have different economics, control, risk and capability requirements.

The useful question is:

Which layer of the solution creates genuine business differentiation, and which layers should we avoid owning?

The four options

1. Packaged AI or copilot

Examples include AI features built into productivity, CRM, support, analytics and development platforms.

Best when:

• the workflow is common across many businesses;
• speed matters more than uniqueness;
• the vendor already has access to the relevant application context;
• the organisation wants low implementation overhead;
• standard controls are sufficient.

Typical trade-off: fast value, limited differentiation.

2. Automation or agent platform

A platform can provide workflow orchestration, connectors, model access, approvals, observability and administration without requiring the business to engineer everything from scratch.

Best when:

• workflows need integration across several systems;
• business rules and AI reasoning need to coexist;
• the team wants configuration flexibility;
• the organisation can accept platform constraints;
• the use case does not require unusual infrastructure.

Typical trade-off: more flexibility than packaged AI, but meaningful vendor dependence.

3. Custom AI application or agent

Here the business builds the workflow, user experience, orchestration and integrations while consuming external models or managed AI services.

Best when:

• the workflow is strategically distinctive;
• proprietary process or data creates an advantage;
• packaged tools cannot support required controls;
• the experience must integrate deeply with internal systems;
• the organisation needs ownership over decision logic and product behaviour.

Typical trade-off: stronger control and differentiation, higher engineering and operating responsibility.

4. Custom model development

Training a new model, fine-tuning an existing model or maintaining specialised model infrastructure may be justified in narrower cases.

Best when:

• model behaviour itself creates material differentiation;
• proprietary data can genuinely improve the required capability;
• latency, privacy, deployment or cost constraints cannot be met another way;
• the organisation has the technical capability to evaluate and operate the model;
• the scale justifies the investment.

Typical trade-off: maximum ownership, maximum responsibility.

Most businesses do not need to train a frontier model to improve an invoice workflow. Civilization remains technically safe from another unnecessary foundation model.

Start with the workflow, not the model

Map the work before choosing the technology.

Document:

• trigger;
• inputs;
• decisions;
• rules;
• human judgment;
• systems touched;
• exceptions;
• output;
• business outcome.

Then ask which parts are deterministic and which genuinely benefit from AI.

A workflow might look like:

Email arrives → classify request → extract fields → validate against CRM → draft response → approve exceptions → send → log outcome

Only some steps may require AI. Others are better handled with normal software rules.

This matters because “AI project” can become a label applied to a problem that is mostly integration and process design.

Decision factor 1: differentiation

The stronger the strategic differentiation, the stronger the case for owning more of the solution.

Ask:

• Would a competitor using the same packaged tool get essentially the same capability?
• Is our advantage in the workflow, data, interface or model?
• Does customisation change the customer value materially?
• Are we building a capability the business intends to compound over time?

If the capability is generic, buy aggressively.

If it is core to how the business competes, consider owning the layers that create the advantage.

Decision factor 2: data

Custom AI often sounds attractive because the organisation has “lots of data”.

That is not enough.

Relevant questions are:

• Is the data actually related to the target task?
• Is it sufficiently accurate and current?
• Can it legally and ethically be used?
• Is it structured or retrievable enough for the workflow?
• Does the system need the data at inference time rather than during model training?

Many use cases need retrieval and access control, not model training.

A custom agent connected to governed internal knowledge can be more useful than a fine-tuned model that still lacks current customer records.

Decision factor 3: integration complexity

Packaged AI works best inside the application boundary the vendor controls.

Custom work becomes more likely when the system must coordinate across:

• ERP;
• CRM;
• support systems;
• document repositories;
• custom databases;
• messaging platforms;
• payment or transaction systems;
• internal approval tools.

But integration complexity is also where custom projects become expensive.

Count the systems, permissions, failure modes and ownership boundaries before counting the AI features.

Decision factor 4: risk and governance

The choice changes with consequence.

A writing assistant can tolerate more uncertainty than an agent authorised to issue a refund or update a legal record.

Evaluate:

• data sensitivity;
• decision consequence;
• required explainability;
• human review;
• transaction limits;
• audit requirements;
• vendor security posture;
• model change management;
• exit options.

NIST's AI RMF is useful because it frames AI risk as lifecycle work: govern, map, measure and manage. That mindset should influence architecture whether the system is bought or built.

Decision factor 5: speed to value

Buying usually wins the first month.

Building may win later if the use case is distinctive enough.

Model the time to:

• obtain approval;
• configure data access;
• integrate systems;
• test real cases;
• train users;
• launch safely;
• improve after launch.

A packaged tool that can be deployed quickly but cannot access the necessary workflow context may deliver less value than a slower custom implementation.

Speed is only useful if it reaches the outcome.

Decision factor 6: total cost of ownership

Compare more than licence fee versus development quote.

Packaged AI costs can include

• per-user licences;
• usage tiers;
• premium connectors;
• admin effort;
• integration work;
• vendor lock-in;
• process changes.

Custom AI costs can include

• discovery;
• engineering;
• model/API usage;
• infrastructure;
• evaluation;
• observability;
• security;
• maintenance;
• vendor/model changes;
• incident support.

Custom model costs can add

• data preparation;
• training infrastructure;
• specialist talent;
• benchmark creation;
• deployment optimisation;
• retraining;
• model governance.

Build-versus-buy should be evaluated over the expected useful life of the capability.

Decision factor 7: exitability

Ask what happens if:

• the vendor changes pricing;
• a model is deprecated;
• quality falls;
• a platform feature is removed;
• the business wants to switch providers;
• the use case expands beyond platform constraints.

Architect for sensible portability where the commercial value justifies it.

That can mean:

• separating workflow logic from model calls;
• using a model abstraction layer;
• keeping source data in systems you control;
• documenting prompts and evaluations;
• avoiding proprietary formats for core business knowledge where feasible.

Perfect portability is expensive. Strategic portability is useful.

A practical decision matrix

Hybrid is normal

A serious AI system can combine all four layers.

For example:

• Microsoft 365 Copilot for employee productivity;
• an automation platform for standard workflows;
• a custom customer-service agent for differentiated service logic;
• managed external foundation models underneath;
• a specialised classifier for one narrow high-volume task.

There is no prize for ideological purity.

Own the parts that create advantage or necessary control. Buy the commodity layers.

A staged approach reduces regret

Stage 1: prove the workflow

Use the fastest safe approach to test whether the problem is real and whether AI improves the outcome.

Stage 2: measure operating value

Track quality, time saved, completion rate, customer effect, human overrides and cost.

Stage 3: identify constraints

Determine what is blocked by the packaged tool or platform.

Stage 4: custom-build only where the constraint justifies it

Do not custom-build merely because developers can.

Stage 5: reconsider model ownership last

Only move deeper into model customisation if there is evidence that model behaviour, cost, latency or deployment requirements materially justify it.

Questions leadership should ask

1. What business outcome are we buying or building for?
2. Which workflow step actually needs AI?
3. What part of this capability differentiates us?
4. Which data must the system access?
5. What actions can it take?
6. What evidence proves acceptable performance?
7. What is the three-year operating cost?
8. Which vendor dependencies matter?
9. How do we exit or switch?
10. What internal capability must exist after launch?

If those answers are clear, the technology choice becomes much easier.

Further reading

• NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
• GOV.UK Service Manual, Using commercial-off-the-shelf products and services: https://www.gov.uk/service-manual/technology/commercial-off-the-shelf-products-and-services

Abrasim's Automation & Technology Readiness Assessment uses the same principle: identify the valuable workflow, test feasibility and risk, then choose the least complicated architecture that can deliver the required outcome.