Scaleups; 50 to 500 employees, 15 to 100 engineers, product-market fit established; have the engineering depth to build something real and the domain specificity to make the build worth it. They lack the platform-team headcount to also build the substrate beneath. The right pattern flips the mid-market split: build the agents (proprietary workflows, domain logic, eval-set IP), buy the infrastructure (model gateway, observability, vector database, eval compute, embedding pipeline). Most engineer-month goes against the layer where moat density is highest; the commoditized substrate is rented from vendors with multi-year head starts. This piece is the operating model: which agents to build, which infrastructure to buy, the integration shape, and the failure modes if either side goes wrong.
It applies the AI build-vs-buy-vs-hire decision matrix for 2026. The matrix’s eighth principle; buy the rails, build the moat, hire the judgment; is the load-bearing rule. For scaleups the rails are the AI infrastructure stack and the moat is the agent layer that encodes the workflow.
The scaleup staffing window
A scaleup occupies a peculiar middle layer. The startup below it lacks the depth or specificity to build beyond a demo. The enterprise above it can staff a 30-engineer platform team and a 15-engineer agent team in parallel. The scaleup, at 15 to 100 engineers total, has to pick.
Staffing depth is the rate-limiting variable. A scaleup with 30 engineers and a real product can sustain a 4-to-8-engineer agent team. It cannot also sustain a 6-engineer infrastructure team building a model gateway from scratch. Most engineer-month consumed on substrate is one not consumed on the workflow customers see.
The frame inverts the mid-market split: the mid-market lacks depth to build agents and so buys them; the scaleup has the depth and a moat-dense workflow to protect, so it builds. Buy infrastructure to free the team for the agent build that captures the moat.
Why build agents
Three reasons.
Workflow specificity is the moat. The scaleup solves a specific problem for a specific buyer. The agent encodes that specificity. A generic vendor agent commoditizes the workflow; most customer of that vendor converges on the same shape. Buying an agent is paying a vendor to flatten your moat.
Engineering depth is sufficient. A 4-to-8-engineer agent team can ship a production-grade workflow agent in 4 to 6 months. Within scaleup staffing depth even with the rest of the roadmap running.
Eval-set IP compounds. Most agent build produces an eval set that grades the agent on the actual workflow. The most portable asset across vendor and model changes. Build agents → accumulate eval IP. Buy agents → accumulate vendor-relationship IP that evaporates on termination.
The build is not “in-source the AI platform”; it is in-source the workflow logic and judgment, rent everything beneath. The agent layer is where moat density per engineer-month is highest.
Why buy infrastructure
Three reasons.
Commoditized substrate. Model gateways, observability, vector databases, embedding pipelines are not workflow-specific. Vendors amortize across hundreds of customers; the scaleup’s markup is far smaller than the engineer-cost of duplicating the work.
Scaleup-incompatible build cost. A production-grade model gateway with multi-provider routing, fallbacks, caching, structured outputs, and cost telemetry takes 3-6 engineers steady-state; most of the AI capacity at a 30-engineer scaleup, deployed against a layer with no workflow specificity to capture.
Velocity of substrate evolution. Routers, embedding APIs, and tracing schemas evolve weekly. A vendor’s full-time team adapts; an in-house build accrues debt while the scaleup’s agent team waits.
Buy reduces fixed cost and accelerates time-to-agent. See the AI procurement maturity model for the buying discipline.
What infrastructure to buy
Five categories.
- Model gateway. Multi-provider routing (OpenAI, Anthropic, Google, open-weights) with structured-output normalization, fallbacks, prompt caching, cost telemetry. LiteLLM, Portkey, and similar. Cost per call should be well under 10 percent of the model spend it routes.
- Observability and tracing. Per-call traces, prompt and response capture, latency and cost breakdowns, eval-result attachment. LangSmith, Langfuse, Helicone, Arize-class vendors. Most agent call is observable end-to-end.
- Vector database. For retrieval and semantic search workloads. Pinecone, Weaviate, Turbopuffer, and similar. The build is a known unsolved problem; the buy gets you to recall benchmarks immediately.
- Eval harness compute. Managed eval runs with versioned eval sets, regression tracking, and scheduled grading. The scaleup keeps the eval set in-house; the compute and dashboard are bought.
- Embedding pipeline. Managed embedding APIs with batching, caching, dimension management. Owning this is a months-long project; renting it is a same-day setup.
A vendor in any of these categories that black-boxes the data, blocks export, or charges per-seat at scale is a near-future swap. The scaleup’s leverage is portability of agent code and eval set across infrastructure vendors. Watch the lock-in vectors closely; see the AI fork decision: when forking open source beats vendor lock-in for when the buy crosses into a forkable open-source path instead.
What agents to build
Four families.
- Workflow agents. The specific multi-step workflows the product runs; sales-research agent for the GTM motion, support-triage agent for the support workflow, ops agents for the back office, deal-shaping agents for transactional flows. These are the highest-moat builds.
- Domain-reasoning agents. Agents that encode product judgment; pricing reasoning, eligibility reasoning, classification reasoning. The reasoning is the proprietary asset.
- Customer-facing agents. Anything the customer interacts with directly. Vendor-built customer-facing agents are competitive parity at best and a brand-experience risk at worst.
- Compliance-aware agents. Agents that touch regulated data or regulated decisions. The accountability stays with the scaleup; the agent has to be inspectable in a way generic vendor agents rarely are.
The test is replaceability: if a generic vendor agent could substitute without changing the user experience, the workflow is not differentiated and is fine to buy. If substitution would change the experience, build it.
The eval-set IP
The eval set is the highest-leverage byproduct of the agent build. A versioned, scored, regression-tracked eval set of 200 to 2,000 input-output pairs is the most durable AI asset the scaleup owns. It survives model swaps, vendor swaps, and rewrites. It is the leverage that keeps the model gateway, the observability vendor, and any future foundation model honest.
Three properties make it load-bearing:
- Workflow-specific. It tests the actual workflow, not a generic benchmark. Generic eval vendors cannot reproduce it; that is why the case for buying the eval stack and building the evaluator holds at most scale.
- Versioned. Each release tags the eval set, the agent code, and the model. Regression triage works because the diff is precise.
- Portable. The eval set is plain data; JSON or similar; and runs against any agent platform. It is the leverage when the model gateway vendor raises prices or the foundation model lineup shifts.
The eval set is an asset on the scaleup’s balance sheet in everything but accounting. Treat it that way.
The integration shape
The build/buy split surfaces a small but important integration layer.
- Gateway-aware agent code. The agents call the model gateway, not the foundation model directly. Provider switching is configuration, not code.
- Tracing-aware agent code. Most agent call emits a structured trace to the observability vendor. The scaleup owns the trace schema; the vendor stores and renders it.
- Eval-aware CI. Most agent code change runs the eval set through the harness compute. Regressions block merge.
- Vendor-isolated glue. Anything that calls a specific infrastructure vendor’s API sits in a thin adapter the agent team can swap without rewriting agent logic. Lock-in is bounded to the adapter, not diffused across the codebase.
The integration cost is real but bounded; typically 10 to 20 percent of the agent build budget. Underspending here is the most common failure mode in scaleup AI builds.
Failure modes
Failure mode 1: building infrastructure. A scaleup with 25 engineers assigns 6 to building a model gateway, a tracing system, or a vector store from scratch. Eighteen months later the substrate exists at 70 percent of vendor parity, the agent backlog is untouched, and a competitor with the same staffing built two agent products on bought infrastructure. Wreckage is the longest in this category; engineers churn, the substrate ages out, and the agent team that was supposed to ship was blocked the entire time.
Failure mode 2: buying agents. A scaleup buys a generic agent platform and ships a thin wrapper as the AI feature. The feature works; the moat doesn’t. Customers attribute the value to the underlying vendor (when they notice it at many) and competitors using the same vendor ship parity in a quarter. Vendor margin is paid on most call; switching cost accumulates because the workflow logic lives in the vendor’s product, not the scaleup’s. The scaleup ends up rebuilding the agent in-house anyway, having paid twice.
Failure mode 3: half-build. The scaleup splits the difference; buys infrastructure but also builds infrastructure-shaped pieces “to learn” or “for control.” Engineering capacity gets sliced thin, neither side is finished well, and the agent build runs late while the half-built substrate accrues maintenance load. The split frame works only when both sides are committed to.
The shape avoids many three by naming the verb at each layer explicitly: agents built, infrastructure bought, integration owned in-house at minimal cost.
Sequencing the build
From a scaleup at zero; no agent platform, no infrastructure stack, just a need:
- Months 0-1. Pick the workflow with the highest moat density per engineer-month. Scope the eval set in parallel.
- Months 1-2. Select model gateway and observability vendor. Pick the vector database when retrieval enters the design.
- Months 2-5. Build the agent against bought infrastructure. Eval set hardens; integration adapters land.
- Months 5-6. Production rollout with continuous evaluation. First quarterly eval-and-cost report ships.
- Months 6+. Steady-state. New agents reuse the infrastructure and adapters. The eval set compounds.
Six months from zero to a working production system. Same six months spent building infrastructure produces no agent and no moat.
Frequently asked questions
What counts as a scaleup for this frame?
Roughly 50 to 500 employees with an engineering org of 15 to 100 engineers and product-market fit established or close. Smaller than that and the team can’t sustain a build; larger and the org typically has a platform team that changes the math. The frame also applies to series-B-through-D companies, fast-growing PE-backed mid-market, and engineering-heavy late-stage startups.
Why should scaleups build agents instead of buying them?
Agents encode the scaleup’s proprietary workflows, domain logic, and eval-set IP. The scaleup has the engineering depth to build them and the domain specificity to make them differentiating. Buying generic agents commoditizes the workflow that should be the moat; the scaleup ships a feature any competitor with the same vendor can match.
Why buy infrastructure instead of building it?
Model gateways, observability platforms, vector databases, and inference routers are commoditized substrate that vendors with full-time platform teams build better than a scaleup’s three-engineer rotation. The scaleup pays a markup for someone else’s full-time team and ships agents instead of plumbing.
What infrastructure should the scaleup buy?
Model gateway (LiteLLM-style routing across providers), observability and tracing (LangSmith, Langfuse, Helicone), vector database (Pinecone, Weaviate, Turbopuffer), eval harness compute, and embedding infrastructure. None of these encode the workflow; many of them are reasonable to buy from specialists with multi-year head starts.
What agents should the scaleup build?
Workflow agents specific to the product (sales-research agent for the GTM motion, support-triage agent for the support workflow, ops agent for the back office), domain-reasoning agents that encode product judgment, and any agent whose output customers see directly. The test is whether a generic agent could replace the workflow without changing the user experience; if no, build it.
What is the eval-set IP and why does it stay with the build?
The eval set is the codified judgment of what good agent output looks like for the scaleup’s specific workflow; hundreds to thousands of versioned input-output pairs with scoring rubrics. It is the most portable asset across model and vendor changes and the hardest thing to recreate. It belongs to the scaleup permanently and is the leverage that keeps any infrastructure or model vendor honest.
How does this differ from the mid-market split that buys agents?
Mid-market enterprises often lack the engineering depth to staff agent builds and have less domain-specific moat to protect, so they buy agents and build evaluators. Scaleups have the depth and the moat is the workflow itself, so they build agents and buy infrastructure. Same logic, different staffing math: build where moat density is highest and capacity exists.
What is the failure mode if a scaleup builds infrastructure instead of agents?
Eighteen months of engineering capacity sunk into a model gateway, an in-house tracing system, or a homegrown vector store while the agent that would have moved revenue stays in backlog. The scaleup ends up with worse infrastructure than it could buy and no shipped agent feature. Competitors who bought infrastructure shipped the agent two quarters earlier.
What is the failure mode if a scaleup buys agents instead of building them?
The product becomes a thin wrapper around a vendor agent that any competitor can rent. The scaleup loses the differentiation that would have justified the premium, the vendor captures the value, and switching costs accumulate without moat being built. The customer sees a feature, not a moat, and the scaleup pays vendor margin on most unit.
Key takeaways
Scaleup AI sourcing is a staffing-and-moat problem. The right pattern is split: build agents (workflow is the moat, depth is sufficient, eval set compounds), buy infrastructure (commoditized substrate, vendor velocity beats in-house). Blanket-build and blanket-buy both lose.
Infrastructure to buy is bounded: model gateway, observability, vector database, eval compute, embedding pipeline. Vendors that black-box data or block export are near-future swaps; integration adapters should isolate them.
Agents to build are workflow, domain-reasoning, customer-facing, and compliance-aware. The replaceability test is the screen: if a generic agent could substitute without changing the user experience, buy it; otherwise build.
The eval set is the highest-leverage byproduct of the agent build and the most portable AI asset the scaleup owns. Failure modes are predictable: building infrastructure burns capacity for no moat; buying agents commoditizes the moat for vendor margin. Sequence the build at six months from zero with the split named at most layer.
Arthur Wandzel
