Key findings

• Compare operating models, not just model quality or subscription price.

• Treat data rights, permissions, auditability, and exit as core requirements.

• Include evaluation, monitoring, review, and maintenance in total cost.

• Prefer hybrid architecture when it preserves business control without recreating commodity infrastructure.

• Run the same representative test set against every serious option.

Define what build and buy actually mean

A bought agent may be a feature inside a CRM, a configurable workflow platform, or a managed agent service with connectors and governance controls. A built agent may still use a hosted foundation model, cloud database, identity provider, and observability service. The real decision is which layers the business will own: user experience, orchestration, prompts, retrieval, tools, permissions, evaluations, hosting, and model weights.

Write the target workflow before discussing architecture. Specify users, data, tools, actions, volume, quality requirements, latency, failure handling, and human approvals. This prevents a vendor feature list or engineering preference from defining the problem. It also reveals whether AI is necessary. If deterministic rules solve most cases, buy or build that simpler automation and reserve model calls for genuinely ambiguous work.

Buy for standard work and fast time to value

Buying is usually strongest when the workflow is common across companies, such as summarizing meetings, drafting support replies from a knowledge base, or enriching standard CRM records. Mature products can provide identity integration, connectors, administration, support, and updates that an SMB would otherwise have to engineer and maintain. A limited pilot can begin quickly if the vendor already fits the existing stack.

The tradeoff is constrained control. The product may expose only broad permissions, limited telemetry, fixed retrieval behavior, or a shallow evaluation interface. Pricing can change with seats, actions, tokens, or premium connectors. Product updates may alter behavior without fitting the business release cycle. Buying therefore requires technical and contractual diligence, not just a successful demonstration.

Build for differentiated workflows and enforceable control

Building is justified when the workflow encodes proprietary operating knowledge, crosses several internal systems, needs precise authorization, or must satisfy requirements a packaged product cannot demonstrate. Ownership lets the team enforce structured outputs, isolate tenants, insert deterministic policy checks, choose models by task, and design human approval around the actual consequence of an action.

Custom ownership also creates an operating obligation. Models and provider APIs change; retrieval indexes become stale; prompts regress; connectors fail; and evaluations need new production cases. The business needs engineering, security, product, and domain ownership beyond the initial launch. If one contractor is the only person who understands the system, the company has replaced vendor lock-in with key-person risk.

Use total cost of ownership, not year-one price

For a bought product, include licensing, usage charges, implementation, premium connectors, data migration, security review, training, support tier, overage, and exit. For a custom system, include discovery, engineering, cloud and model usage, evaluation data, human review, monitoring, incident response, upgrades, and on-call ownership. Apply the same forecast volume and quality target to both options.

Estimate the cost of failure as well as the cost of operation. A cheaper agent with weak access controls or no exportable audit trail can create disproportionate exposure. Conversely, a bespoke platform for a low-risk commodity task can consume more management attention than it saves. Use ranges and sensitivity analysis because token use, review rate, and exception volume often change after contact with real work.

Compare security, privacy, and control boundaries

Map where prompts, retrieved documents, tool results, outputs, memory, and logs are processed and retained. Confirm whether customer data is used for provider training, which subprocessors receive it, where it is hosted, how deletion works, and which controls are available for sensitive data. Review incident notification, authentication, role design, encryption, vulnerability management, and independent assurance evidence.

For agents, inspect effective permissions rather than connector names. Can the agent read all mail when it needs one shared inbox? Can it send, delete, export, or change access? OWASP warns that excessive agency and prompt injection can turn legitimate tools into attack paths. Whether built or bought, authorization must remain deterministic, tool inputs and outputs must be validated, and irreversible actions should require approval.

Evaluate integration, quality, and exit with evidence

Create a representative evaluation set before the shortlist. Include normal cases, hard cases, restricted requests, malicious instructions, missing data, and downstream failures. Run the same cases on each option and score task quality, serious errors, latency, review effort, traceability, and variable cost. Require a sandbox and test the exact connector and permission configuration intended for production.

Ask how to export prompts, configuration, logs, evaluation records, documents, embeddings, and user feedback. Clarify ownership of custom work and whether the vendor will delete derived data after termination. UK government procurement guidance explicitly recommends lifecycle planning, explainability, ongoing evaluation, knowledge transfer, and strategies to avoid black-box systems and vendor lock-in.

Use a weighted decision matrix

Weight criteria according to the workflow, not a generic template. A low-risk internal drafting assistant may prioritize speed and usability. An agent that writes to finance or customer systems should place more weight on authorization, auditability, rollback, data protection, and support. Score only demonstrated capabilities. Mark unverified claims as unknown rather than giving partial credit.

A practical default is buy the commodity, build the differentiator. Use a managed model and standard infrastructure, but keep business rules, tool allowlists, approval logic, evaluation sets, and portable data under company control. Choose fully packaged software when it passes the evidence gate with materially lower operating burden. Choose custom only when the additional control or differentiation is worth sustained ownership.

Sources and methodology

This article synthesizes the primary sources below as of the publication date. Forecasts and recommendations are directional scenarios, not guarantees; they should be tested against your workflow, data, risk tolerance, and current vendor documentation.

UK Government: Guidelines for AI procurement (accessed 2026-07-30)

UK Government: Assessing if artificial intelligence is the right solution (accessed 2026-07-30)

National Institute of Standards and Technology: NIST Cybersecurity Supply Chain Risk Management Due Diligence Guide (accessed 2026-07-30)

OWASP Foundation: OWASP AI Agent Security Cheat Sheet (accessed 2026-07-30)

UK National Cyber Security Centre: Guidelines for secure AI system development (accessed 2026-07-30)