Build vs buy an AI agent platform: which layers to own and which to standardize

They built the differentiator, then rebuilt the platform five times

A financial-services firm develops a proprietary credit-risk capability. The domain model, decision logic, evaluation data and reviewer experience are real intellectual property. It's too important to hand to an opaque product, so the first team builds everything around it too: identity propagation, tenant scoping, schema validation, workflow state, model routing, policy adapters, approval records, retry logic, execution logs and cost tracking.

It ships, and it works.

Within eighteen months, four more teams build AI applications for claims, supplier onboarding, contract review and customer operations. Each reuses some code and rewrites the rest. Now there are five interpretations of approval expiry, tenant scope, retries, model fallback, evidence retention and versioning.

An auditor asks a simple question: which shared control stops a paused case from resuming after the requester's authority expires?

There isn't one. Five teams own five implementations, each reasonable, none authoritative.

Building the risk capability was the right call. Nobody decided to build and run five versions of governed execution. That responsibility came in through the side door, because build vs buy treated the application as one indivisible thing.

Should you build or buy an AI agent platform?

Neither, as a single decision. Build the parts that differentiate you, standardize the controls every agent needs, and extend the shared layer where your business rules legitimately vary.

The binary question hides that an AI application holds several kinds of responsibility with very different strategic value. A proprietary model can be a competitive advantage. So can a pricing rule or a customer experience. Those justify direct ownership.

Identity propagation, policy enforcement, approval binding, durable waits, retry reconciliation, lineage and cost attribution are different. You need them because the application is consequential, long-running, multi-tenant and changing. Their value comes from being consistent and provable everywhere, not from being different in every app.

The stakes are real. Gartner expects over 40% of agentic AI projects to be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. McKinsey's April 2026 research finds fewer than 10% of organizations have scaled agents to tangible value. Rebuilding the control layer per team feeds all three of Gartner's causes.

Which layers should you build yourself?

Build what makes you different: domain logic, differentiating models, evaluation data, the business rules that embody how you compete, and the apps your users and customers touch.

Own a capability when its behavior creates strategic value, or when handing it off would give away control of the business proposition. That includes proprietary decision logic, domain-specific models, high-performance kernels, specialized data representations, evaluation assets and customer-facing experiences.

Ownership means more than keeping the source code. It means owning correctness, evaluation, security, lifecycle, staffing, incident response and compatibility with everything around it.

Be deliberate. A capability isn't differentiating just because you happened to write it first. A custom retry library rarely is. A custom underwriting model often is.

Which layers should you standardize?

Standardize identity, policy enforcement, approvals, durable state and evidence. Every agent needs them, inconsistency creates risk, and rebuilding them per team multiplies the cost of every audit and upgrade.

These layers aren't unimportant because they're not differentiating. They're what turns a differentiated capability into trustworthy enterprise behavior. Rebuilt per application, they create control duplication: several implementations of the same obligation, evolving at different speeds, each needing its own testing and evidence.

Standardizing doesn't have to mean buying one product. You can build an internal platform, adopt an external one, or combine them. The requirement is one governed contract and one accountable owner per obligation.

This is the same logic as shared ("common") controls in NIST's Risk Management Framework: implement once, inherit everywhere, assess once. (See AI agent identity and delegated authority for why the identity layer especially shouldn't be rebuilt per agent.)

Extend through declared interfaces, not escape hatches

A good platform doesn't force every application into one data model, policy, workflow, interface, model provider or deployment. You need extension points for domain schemas, policies, queries, connectors, sub-workflows, evaluators, custom code, model adapters, UI components and deployment targets.

But an extension must not become a way around the shared layer. A custom step that receives ambient credentials, writes straight to a database, causes side effects without an operation ID or emits no evidence is flexible, and makes the application ungovernable.

Code and platform don't compete. Teams will always need custom algorithms and integrations; a platform that can't accommodate them pushes teams to build around it, which is how the stitched stack starts. (See the hidden cost of a stitched AI stack.)

Owning a component isn't owning the relationships

A domain team owns the risk model. A data team owns features. IAM owns authentication. Security owns policy content. A platform team owns the runtime. None of that says who owns what they mean together.

The application still needs one authority for questions like: which proposal did the model produce, which policy evaluated it, what did the reviewer approve, which version resumed, and what effect actually committed? That's the cross-cutting layer's job. Write it down as a contract between the platform and application teams:

Does buying a platform mean lock-in?

It can, but the deepest lock-in is semantic, not technical. Insist that the application's meaning (definitions, contracts, policies, state and evidence) stays explicit and exportable, and that the platform runs where you choose.

Lock-in is usually discussed as dependence on proprietary APIs or hosting. Those matter. Harder to escape is meaning that exists only in generated code, hidden config, undocumented workflow state or proprietary logs.

Ask for:

• The complete application definition, not just generated code.
• Machine-readable schemas, mappings, identifiers and units.
• Custom code, models and tools that enter through contracts and can be rebound.
• Explicit durable-state formats, operation IDs and migration rules.
• Policies, decisions and authority context you can inspect and export.
• Evidence you can retain independently, with access controls.
• Cost records normalized and linked to cases and outcomes.
• Deployment in your own data center or cloud account.

Portability doesn't mean reducing the platform to the lowest common denominator. It means advanced behavior stays explicit enough to understand, test, migrate or deliberately keep.

When does building your own platform make sense?

When you have unusual scale, latency, deployment or regulatory needs nothing available meets, when the platform itself is strategic IP, or when you can staff it as a product for years.

An internal platform isn't done when the first runtime works. It's a product with users: roadmap, documentation, security, testing, upgrades, compatibility, support, incident response, capacity, migration tooling and deprecation. Without the staffing and product discipline to run that for years, the control you gain by building becomes a dependency on a small internal team.

Buying doesn't remove responsibility either. You still evaluate the platform's contract, supply chain, extension behavior, evidence, portability and change process. Responsibility moves; it doesn't disappear. And an internal build should meet the same contract, portability and evidence bar you'd demand of a vendor.

Compare the portfolio, not the first application

The first custom application looks cheap because it doesn't yet carry the cost of shared controls, documentation, migration, audit and operations. Five teams rebuilding the same controls tells a different story: duplicated development, security review, testing, evidence work, incident response and upgrades.

Compare options on the full cost per valid, authorized, evidenced outcome across the portfolio, not lines of code, model calls, seats or licenses.

Common anti-patterns

Ten rules for build vs buy

1. Decide per layer, not per application.
2. Own what differentiates: domain logic, models, evaluation data and your apps.
3. Standardize identity, policy, approvals, durable state and evidence.
4. Extend through declared interfaces, never around the shared layer.
5. Name an owner for every cross-component relationship.
6. Write down what the platform guarantees and what teams provide.
7. Keep a governed core without consolidating every component.
8. Demand semantic portability, not just file export.
9. Run an internal platform as a long-lived product, or don't build one.
10. Compare options on cost per governed outcome across the portfolio.

The result: own the outcome, not every mechanism

The goal isn't to maximize internal code or minimize vendors. It's to put ownership where it creates value and standardization where inconsistency creates risk and recurring cost. A proprietary model stays proprietary. A unique workflow stays with its domain. Specialized stores and model providers stay replaceable.

What the application can't do without is one authority connecting those parts from intent to effect. Don't outsource your business meaning. And don't mistake rebuilding common control machinery for competitive advantage.