Build, buy or partner for an AI agent? Ask these questions first

“Should we build or buy?” sounds like a technical choice. For an AI agent, it is really a decision about what the organisation must own, what it can depend on, and where accountability sits when an action is wrong.

The useful answer is often not one of three pure forms. A team may buy model and orchestration infrastructure, build the policy and workflow layer that differentiates its service, and partner for integration or evaluation. The sourcing decision should therefore be made component by component, against one defined workflow, rather than as a vote for an entire platform.

Start with the advantage you cannot outsource

Write down why this workflow matters. If the supposed advantage is simply access to a capable model, it is unlikely to be durable. If it comes from a distinctive operating method, proprietary but appropriately used data, deep integration, or a better human-agent division of work, identify which artefacts preserve that advantage.

For a claims-handling agent, the differentiating assets might be the decision policy, exception taxonomy, evidence trail and handoff experience. Model hosting, generic retrieval and message transport may be commodities. This distinction matters because a supplier can provide a component without owning the business judgement embodied in the workflow.

The UK guidelines for AI procurement advise buyers to begin with the problem and public benefit rather than fitting a problem to AI. The same discipline applies outside government: define the operational change first, including the option of ordinary software or process redesign.

Compare responsibility, not feature counts

Use a matrix that makes each sourcing path answer the same questions. Score with evidence, and record “unknown” instead of converting uncertainty into a reassuring number.

The matrix prevents a polished product capability from cancelling out a weak evidence or exit position. Weight the dimensions according to consequence. In a recommendation-only research aid, configurability may dominate. In an agent that changes customer accounts, authority enforcement, audit evidence and recovery deserve more weight.

Price the complete operating path

Buying can reduce the work of creating infrastructure. It does not remove the work of specifying the workflow, integrating systems, evaluating behaviour, training people, handling exceptions and governing change. Building can preserve control, but creates a maintenance and staffing obligation. Partnering can add scarce expertise, but creates handoffs and knowledge-transfer risk.

The OECD’s discussion of build-versus-buy choices in digital public procurement draws the same economic contrast: commercial platforms can offer more predictable recurring costs, while internal development may retain intellectual property and reduce some forms of dependence. Neither property settles the decision. Estimate costs across discovery, implementation, evaluation, migration, operation, incidents, change and exit.

Use ranges rather than false precision. Include a sensitivity case for usage growth, model-price change, additional review, degraded automation and migration. A cheap successful run is not the unit that finance ultimately funds; the organisation funds a service that includes failed runs, human correction and control work.

Treat evidence access as a contractual requirement

An agent cannot be accepted or responsibly operated if the buyer cannot observe the states relevant to its decisions. Before selection, specify the evidence needed to investigate behaviour: version identifiers, inputs and retrieved context where lawful, tool requests and responses, policy decisions, human interventions, final system state, latency and cost.

This is not a demand for a supplier’s proprietary internals. It is a demand for enough customer-specific evidence to determine whether the deployed workflow met its requirements. The NIST AI Risk Management Framework calls for test sets, metrics and system performance to be documented in conditions similar to deployment, followed by monitoring in production. A supplier’s general benchmark is not a substitute for that local evidence.

Ask who may retain evidence, for how long, and under what data controls. Require notification and reevaluation triggers when models, safety systems, tool interfaces or other material dependencies change. If a buyer cannot test a significant change before it reaches the workflow, that is an operating constraint to price and govern.

Make switching a tested capability

Portability is not equivalent to a clause saying data can be exported. A viable exit may require workflow definitions, prompts, policies, schemas, evaluation cases, outcome records, integration documentation and operational knowledge. The receiving system must be able to use them without reconstructing the service from screenshots.

Government Open Standards principles connect interoperability and open formats to lower lock-in and simpler migration. GAO’s review of private-sector cloud acquisition practices similarly identifies interoperability, data portability and application compatibility as ways organisations mitigate lock-in. These do not require avoiding every proprietary capability. They require understanding the trade: a specialised feature may be worth dependence if its value exceeds the switching cost and the organisation retains a credible contingency.

Run a small exit rehearsal before committing. Export a representative workflow, its configuration and evaluation pack. Estimate the effort to reproduce an accepted result on an alternative. Record what does not transfer and who owns remediation. A plan that has never been exercised is a hope, not a control.

Choose by the operating model you can sustain

The decisive constraint is frequently organisational. Building requires product, engineering, evaluation and operational capacity that remains after the launch team moves on. Buying requires strong product ownership, supplier management and technical acceptance capability. Partnering requires clear decision rights, knowledge transfer and an internal owner able to challenge the partner.

Name the long-term owners before awarding the work:

• the workflow owner accepts outcome and risk;
• product owns requirements and user experience;
• engineering owns integration and technical operation;
• security and privacy own their control decisions;
• procurement and legal own the negotiated commercial mechanism within their remit;
• a supplier or partner owns only the obligations explicitly assigned to it.

If these roles cannot be filled, narrow the agent’s authority or postpone the sourcing decision. No route transfers accountability away from the organisation choosing to use the system.

Make the decision reversible where uncertainty is high

Use staged commitments. Begin with a bounded paid discovery or trial using representative cases and agreed acceptance criteria. Separate proof of technical connection from proof of workflow value. Gate broader authority on evidence, not elapsed time or money already spent.

A defensible recommendation should state which components will be built, bought or partnered; why each choice fits the workflow; what evidence supports it; what remains uncertain; the total-cost range; and the exit path. Revisit the choice when volume, consequences, supplier terms or internal capability materially change.

The point is not to minimise external dependence. It is to put each dependence where it creates more value than risk, while keeping the organisation able to evaluate, operate and change the workflow it remains accountable for.