The steering-committee question is usually too simple: should we build this AI capability or buy it?
That framing forces a whole deployment into one procurement box. A production workflow contains several layers, and the best owner for one may be wrong for another. The platform can be bought. Differentiating workflow logic can be built. A partner can help with the first implementation. Long-term operation can remain with the client.
Build, buy, and partner are composable ownership choices.
Official vendor programs make that allocation visible. Microsoft FastTrack distinguishes remote guidance from hands-on custom implementation. Salesforce’s partner finder recognizes an FDE partner category for advanced Agentforce work. Google Cloud describes partner-leveraged delivery. Anthropic’s public FDE program role includes choices to team, subcontract, co-deliver, route, or hand off pursuits. McKinsey’s 2026 research adds market context around changing build-versus-buy behavior and the importance of workflow redesign.
These current sources do not prove that one route is better. They show that providers themselves distribute responsibilities across direct teams, partners, and customers.
Start with five ownership decisions
Platform
Who provides and operates the underlying model, application, data platform, or agent infrastructure?
Buying is attractive when the capability is standard, productized, supportable, and not a source of durable differentiation. Internal teams should be cautious about rebuilding commodity infrastructure merely to preserve a feeling of control.
Workflow
Who translates product capability into the organization’s decisions, rules, users, and exceptions?
This is often where differentiation lives. A purchased product still requires customer-owned definitions of authority, review, escalation, and success. Outsourcing every workflow decision can leave the organization with a configuration it cannot confidently change.
Integration
Who connects identity, data, systems of record, permissions, logs, and downstream actions?
A standard connector may remain a product responsibility. A narrow custom interface may fit an internal team or specialist. A multi-system program with broad organizational change may require a larger integrator. The question is not only who can write the code; it is who can carry the dependencies and support boundary.
Operation
Who owns incidents, model changes, evaluation regressions, access reviews, and user support after launch?
Vendor support, partner stabilization, and client operations are not interchangeable. No first deployment is complete until contracts, runbooks, and escalation paths name the actual owner.
Learning and transfer
Who captures evaluation results, decisions, reusable patterns, and product feedback? What remains when the first deployment team leaves?
Transfer affects architecture, repositories, access, training, evidence, and staffing from the beginning. It is not a documentation sprint at the end.
Use a decision matrix, not a slogan
The following is ScottFelten.com analysis, not a statistically validated scorecard.
| Condition | Build internally | Buy / self-serve | Vendor field team | Partner for a bounded deployment |
|---|---|---|---|---|
| Strategic differentiation | High | Low | High when product learning matters | High in one bounded workflow |
| Workflow ambiguity | Team can resolve | Low | Novel and product-relevant | High but containable |
| Internal capacity | Strong | Sufficient for configuration | Limited in novel capability | Small senior gap blocks progress |
| Integration breadth | Controlled | Standard | Deep in vendor platform | Depends on partner and scope |
| Desired transfer | Internal by default | Product documentation | Varies by model | Explicit acceptance workstream |
Use the table to expose assumptions, not to produce a mechanical score.
A composable first-deployment pattern
Consider a hypothetical enterprise team automating a document-intake decision. This is an illustration, not client evidence.
The company buys an approved model and workflow platform. Its product owner defines the decision policy, exception boundary, and success measures. A bounded implementation partner maps the current workflow, integrates two named systems, helps create an evaluation set, and produces a runbook. The client’s technical owner accepts the repository, access model, evaluation process, and production-support boundary before taking control.
Nothing requires the partner to claim affiliation with the platform vendor. Nothing requires the client to build commodity infrastructure. Responsibility follows context and the desired end state.
The pattern can fail. If data rights are unresolved, no operating owner exists, or the first release cannot be bounded, the right next step may be a diagnostic or stop. If the workflow is standard and the internal team is capable, self-service may be better than embedded help.
There are also reasons not to partner. A partner adds coordination cost. Weakly defined responsibilities can create another handoff rather than close one. The client should not outsource core product judgment, accountable business decisions, or long-term operation by accident.
Write the ownership brief first
Before procurement, create a one-page first-deployment brief:
- the consequential workflow and target users;
- what will be bought;
- what must be built because it is differentiating or contextual;
- what a vendor or partner will carry;
- who owns integration and production operation;
- what evidence supports expansion;
- what must transfer; and
- what conditions stop the work.
Use the brief in sequence. First, diagnose the missing responsibility. Second, assign the long-term owner. Third, choose the route—internal, self-service, direct vendor, partner, or stop. Fourth, define the acceptance and transfer evidence. Only then should the team select the tool and commercial container. This order prevents a product decision from becoming an accidental operating model.
Make the decision reversible where possible. A bounded first deployment should avoid a permanent operating dependency before the workflow has earned expansion. Preserve the client’s data boundary, keep evaluation artifacts portable, document material architecture choices, and define access removal. Those controls do not eliminate switching cost. They make the cost visible enough to govern and give the sponsor a real proceed, change-route, or stop decision at the end of the first boundary.
Build versus buy is not wrong. It is incomplete. Select the ownership model first, then use the smallest credible combination that can produce a working solution or a defensible stop.