SecondBrain
Ask the Brain
Index/Conceptupdated Sat May 30 2026 08:00:00 GMT+0800 (Philippine Standard Time)

Build vs Buy (Agents)

build-vs-buyenterprise-aicioagents

Build vs Buy (Agents)

When does an enterprise build its own agentic capability vs buy a vendor product?

The decomposition (Praveen, Agentic AI in the Enterprise (Praveen Akkiraju, CXOTalk))

The build/buy line breaks down along front-end vs back-end:

Front-end / standardized workflows Back-end / data-heavy / industry-specific
Variability Low (workflow looks similar across enterprises) High (depends on data, compliance, vertical)
Examples Customer support, finance reporting, marketing collateral Security ops, IT ops, supply chain orchestration
Lean toward Buy Build (using frameworks + LLM APIs)
Why Vendor amortizes the harness across customers Need deep integration with your data platform; off-the-shelf can't capture your moat

Don't reinvent the system of record

Both Praveen Akkiraju and Boris Cherny are skeptical of "rebuild Salesforce/Workday/SAP from scratch with AI." The system-of-record value (data integrity, integrations, compliance, scale) doesn't disappear because you can vibe-code a CRUD app. Cost-of-tokens calculus also pushes against full rebuilds.

"Does it make sense for an enterprise to bottoms-up build a brand new CRM or ERP? Is that worth the tokens? Where's the real value for you as an enterprise?" — Praveen

The hybrid pattern that's working

Praveen's example (Stampli, AP-reconciliation): take an existing software platform, identify where in the workflow an agentic step adds the most value, and insert it surgically. Don't rebuild — instrument.

CIO-level guidance (CIO Agenda 2026 (CXOTalk))

  • Move from project-oriented to product-oriented IT — gives the org a function (product management) that can make build/buy calls based on roadmap and P&L, not ticket queues
  • AI Council, cross-functional, often led by CEO not CIO

The founder / startup-side lens (Sandeep)

You're Not Behind (Yet) Learn AI Agents (theMITmonk) adds the go-to-market counterpart to Praveen's enterprise-architecture view. The Narrow Agents thesis: "For every software company that exists today, there will be an agent company trying to dethrone it. The winners won't build the broadest agents first. They'll build the one that understands one workflow, one market, and one kind of user pain better than everyone else."

This lines up with Praveen's "back-end / build" column — domain-specific, high-variability, deep-in-the-data — but reads it as the competitive opportunity, not just an in-house architecture choice. The build target for a startup ≈ the back-end build for an enterprise.

2026-06-27 — Brovich's Use / Compose / Build map (AWS Events keynote)

Steven Brovich in A Leaders Guide to Advanced Team Structures (AWS Events) gives a unit-economics-anchored decomposition that sits between Praveen's enterprise-architecture view and Sandeep's startup-side view. Three "worlds" along a leverage-vs-differentiation axis:

World Posture Leverage Differentiation When
Use End-to-end managed (someone else operates the AI; you consume) Highest Lowest Commoditised workflow
Compose Frontier APIs stitched into your context (their intelligence + your workflow) Medium Medium Most enterprise use cases
Build Train / fine-tune your own Lowest Highest (and highest cost, lowest speed) Only at points that truly differentiate

The two key insights Brovich's frame adds:

  • Workflows cut across worlds. Don't try to live in one. Let economics + actual differentiation drive which world each part of your workflow lives in. The healthy path: Day 1 frontier-does-everything → Month 6 some shifts to use, some to compose → Year 2 high-volume/high-differentiation moves to build.
  • The pricing scissors are the unit-economics under the trichotomy. Training cost +2.4×/yr, inference cost −10×/yr; gap opens 12–24×/yr. Only a handful of companies can afford to train frontier; cost to use one approaches zero. "Almost nobody should be building."

This sharpens Praveen's front-end/back-end split (where to insert AI) into a unit-economics decision (which posture to take per workflow). Both decompositions are useful — the front-end/back-end view tells you where to apply AI in a system; the use/compose/build view tells you how much of the stack to own.

Sources