Build, Buy or Combine: Choosing Who Owns Each AI Layer

Buy when an existing product fits your workflow and mandatory controls; build when distinctive business rules or integration requirements justify sustained engineering ownership; combine when standard capabilities fit but your decision logic must remain custom. For enterprise AI, the useful unit of choice is usually a workflow layer—not the entire system. Separate what generates an answer, what authorizes an action and who keeps the service running before selecting a delivery model.

Divide the workflow into ownership decisions

Start with one bounded workflow, such as preparing a customer-service case for review. Map its layers: intake, knowledge access, model processing, business rules, approvals, system updates and monitoring. For each layer, record who supplies it, who can change it and who responds when it fails.

Buy means adopting a packaged capability and configuring it within supported limits. It is a reasonable choice when the process is conventional, supported integrations cover the work and the product exposes the controls you require. Configuration, testing and operational ownership still remain.

Build means owning custom application behavior, whether your team or an engineering partner implements it. It does not necessarily mean training a model. You can build a differentiated workflow using purchased model services. Choose this route only if you can fund maintenance, security work and future integration changes—not merely the first release.

Combine means purchasing reusable capabilities while building selected workflow components. It is useful when a standard interface or model service fits, but entitlement checks, evidence requirements or approval rules do not. Its main burden is integration ownership: someone must diagnose failures across organizational boundaries.

Architecture complexity is a separate choice. An agent is a model-driven component that can select tools and steps; orchestration coordinates those components. Microsoft’s agent design guidance recommends starting with simpler approaches because additional coordination brings latency, cost and failure modes. A custom build may need only one model call inside ordinary application code.

Eliminate unacceptable options before scoring value

Apply mandatory requirements first. An attractive price should not compensate for missing access controls or an unusable recovery process.

Ask each proposed delivery team to demonstrate:

• Data boundaries: where inputs, outputs and logs go, who can access them and how retention is controlled.
• Action boundaries: which system checks permissions and prevents unapproved changes.
• Operational control: how you inspect failures, disable automation and continue manually.
• Change control: how model or product updates are tested before affecting users.
• Exit capability: which records, configurations and custom components can be exported or replaced.

Prompt injection—malicious instructions embedded in content processed by a model—makes action boundaries particularly important. OWASP’s prevention guidance recommends layered defenses, including permission checks on tool calls, restricted privileges and human oversight for high-risk actions. Buying software does not eliminate this responsibility; building software does not automatically satisfy it.

For options that pass, compare first-year and steady-state costs. Include implementation, licensing, model usage, review labor, support, integration maintenance and migration effort. Use cost per correctly completed case, not just cost per model request.

Worked example: preparing warranty cases

Illustrative example—not an AIoverflow deployment: a manufacturer wants incoming warranty requests summarized, checked against purchase records and prepared for a service representative. People must approve replacements, and the legacy order system contains custom eligibility rules.

The team considers three designs:

• Buy: use the case-management product’s AI features. Reject this option if its integration cannot apply the required eligibility rules or preserve the supporting evidence.
• Build: create the intake interface, evidence collection, eligibility service and review queue. This offers control but assigns the team ownership of every application component.
• Combine: retain the existing case interface, purchase model processing and build a narrow eligibility service plus an approved-update connector.

Suppose the combined option passes the mandatory requirements. At 4,000 monthly cases, assume platform and model charges total $1,200, maintenance costs $2,000, and review averages three minutes per case at $30 per hour. Monthly operating cost is $9,200: $1,200 + $2,000 + $6,000. If 3,800 cases finish correctly, that is approximately $2.42 per correct completion, before initial implementation costs.

These assumed numbers do not prove value. They expose what to measure: review effort can outweigh model charges. Compare every candidate with the same volume, correctness definition and manual baseline.

Test exceptions and ownership before committing

For the warranty example, use a held-out test set—cases not used while configuring the system—including missing receipts, conflicting records and hostile attachment text. Our guide to building an evaluation set from business records explains how to assemble representative evidence.

Illustrative acceptance gates could require:

• At least 95% of routine drafts accepted without material correction.
• Every tested missing-evidence case routed to review.
• Zero unauthorized updates across permission and injection tests.
• Draft preparation within 30 seconds for 95% of cases.
• Demonstrated export and reconstruction of ten case histories outside the proposed product.

These are proposed thresholds, not industry benchmarks; zero observed security failures is not proof of immunity.

If the eligibility service times out, hold the proposed update, retain the evidence and route the case to manual handling. Do not let the model infer eligibility. Assign one service owner to coordinate recovery, even when suppliers own individual components.

Choose the lowest-burden option that passes these tests and has funded operating ownership. If the boundaries remain unclear, contact AIoverflow to map the delivery choices against your workflow, controls and operating capacity.