Build, buy or extend AI: choose the work your team should own

At an AI investment meeting, “we can build it” answers a feasibility question. The enterprise AI lead still has to answer the ownership question: which capabilities will the organisation maintain, and why are they worth that commitment?

A custom application may be justified by a distinctive workflow or a control requirement. A packaged product may already handle the task well. Extending an existing platform can occupy useful ground between them, particularly when the data and users are already there. The comparison becomes meaningful only when all three proposals must complete the same job.

Fix the task before comparing delivery models

Consider a hypothetical internal service that helps account managers prepare a customer renewal brief. It must summarise approved documents, identify the source of each material statement and flag missing information. An employee checks the brief before using it. The service cannot send a proposal, update the CRM or approve a discount.

Those boundaries make the options comparable. A demonstration that produces fluent prose from one clean document is not equivalent to a service that handles conflicting dates, stale records and restricted content. Include those cases in the acceptance material, alongside routine requests. A conventional search and document template should also remain in the comparison if it can achieve the required result at acceptable effort.

Separate the valuable business logic from the technical machinery. In this example, knowing which commitments belong in a renewal brief may be distinctive. Operating a general-purpose chat interface probably is not. Spend custom engineering on the requirement that changes the outcome.

Buying moves implementation work, but leaves a business decision

A packaged service can bring a supported interface, model access and administrative controls. The buyer still needs to select suitable content, configure access and establish how employees will check the result. Integration and exception handling may remain substantial even when no model code is written internally.

Microsoft’s documentation for Copilot in Microsoft 365 says it surfaces organisational information that the user has permission to view. For the renewal-brief service, that makes the existing permission model part of the buying decision. If an account manager can already see material they should not use, buying the assistant does not settle that underlying access question.

Test the packaged route against the required workflow before requesting bespoke features. Where it succeeds, the organisation may gain more from improving content ownership and user adoption than from replacing the product with custom orchestration. Where it fails, identify the precise constraint: source access, output structure, evidence quality, a required integration or the ability to control an action.

Extend where the platform’s boundaries fit

Microsoft distinguishes declarative agents from custom engine agents. Declarative agents use Copilot’s orchestrator and models, with supplied instructions, knowledge and actions. Custom engine agents allow the builder to bring their own orchestration and models. The difference is a concrete example of how “extend” can mean different levels of responsibility even within one ecosystem.

For the fictional renewal brief, a declarative extension could be worth testing if the main need is to constrain instructions and connect approved knowledge. It would need to meet the same source, permission and missing-information tests as any other option. This is a candidate design, not a claim that a particular configuration has passed those tests.

If the workflow needs an orchestration behaviour or model choice outside that boundary, the custom route may earn its complexity. First explain why the additional control improves a business requirement. The ability to choose more components also creates more components to integrate, monitor and change.

Microsoft’s extensibility cost guidance separates user licensing, consumption and hosting, with treatment depending on the agent and licence arrangement. An existing platform subscription therefore needs a capability-specific cost check. Include external APIs and services used by the extension rather than assuming that “inside the platform” means the complete workflow is already paid for.

Build around the requirement that earns the investment

Here, building means owning a custom application or workflow; it need not mean training a foundation model. The team can still buy model access, hosting and other components. It must decide how those components work together and how failures reach someone able to respond.

For a custom proposal, ask who will maintain retrieval, permission checks, prompts, output validation, monitoring and the user interface. Who investigates a wrong answer after a source update? Who changes the application when a model or connector is retired? A delivery team that exists only until launch is not an operating model.

Compare all options over the same period and at the same workload. Include implementation, licences, model and retrieval usage, infrastructure, human review, support and future changes. Measure accepted briefs, not just successful API calls. A low-cost response that requires extensive correction can be expensive at the task level.

Do not assign a speculative saving to every minute the tool appears to release. Establish whether the saved time changes throughput, service quality or a funded capacity requirement. Keep that benefit case distinct from the cost of operating the chosen delivery model.

Before committing, test one likely change: a new source, a revised approval requirement or a change of provider. Establish what can be exported, what needs rebuilding and whether another team member can operate the result. Buying, extending and building all create dependencies; the useful comparison makes those dependencies visible.

Choose the smallest ownership commitment that meets the workflow and its expected changes. Then use the enterprise AI platform evaluation guide to make the shortlist demonstrate the complete task. That is where an attractive architecture becomes a supportable business service.