Vendor selection: build vs buy vs orchestrate agentic AI

"Do I really need a $300K enterprise AI platform, or can my own team wire this together over a couple of weeks?"

That's the procurement question every operator is sitting with. The vendor pitches all sound the same. The Hacker News crowd says "build it yourself." The Gartner reports rank everyone in the leaders quadrant. Nobody has named the third option that most companies actually need.

The third option has a name. It's called orchestrate. Here's the framework, the costs, and the 5 questions that pick between them.

TL;DR

• Three paths, not two. Build from scratch. Buy an enterprise platform. Orchestrate off-the-shelf APIs with a thin workflow layer you own. Most teams should orchestrate.
• Cost ranges: build $80K to $400K up-front + $40K/year maintenance. Buy $80K to $400K/year subscription with vendor lock-in. Orchestrate $5K to $30K up-front + $1K to $5K/month.
• The 5 questions that pick the path: workflow uniqueness, team capability, time-to-value pressure, vendor risk tolerance, integration depth.
• The biggest failure modes: buy-then-shelf the platform, build-from-scratch the workflow that already exists as an API, orchestrate without a verification layer.
• For most 30-to-300-person companies in 2026, orchestrate is the right default for 70% of agentic workflows. Build for the 20% that are truly your competitive moat. Buy for the 10% where vendor liability and compliance matter more than flexibility.

What "orchestrate" actually means

Strip the buzzword. Here's what orchestrate looks like in practice.

You don't build a sourcing agent from scratch. You compose three off-the-shelf services: an enrichment API, an LLM API for filtering, and a scheduling API. You write a 400-line workflow file in Python or TypeScript that calls them in order, handles errors, and logs to a database you own.

The agent code is yours. The data is yours. The workflow logic is yours. The expensive primitives (the enrichment, the LLM, the calendar) you rent from APIs that charge per call.

You did not build the enrichment engine. You did not buy a $200K platform that bundles enrichment, LLM, calendar, and 40 other features you'll never use. You orchestrated three primitives into a workflow that fits your business.

That's the path. It has been around for a decade as a software pattern. It is uniquely well-suited to agentic AI because the primitives (LLMs, vector DBs, schedulers, enrichment APIs) are now cheap, stable, and well-documented, while the workflow layer is where your business logic actually lives.

The 3 paths, compared

Here is the table most procurement decks don't show you.

Read the table once. Then ask: which row matches the workflow I'm actually trying to ship?

For most 30-to-300-person companies, the orchestrate row matches 70% of the workflows on their list. The build row matches the 20% that are genuinely differentiated. The buy row matches the 10% where the vendor is taking on regulatory or operational risk you don't want.

The 5 questions to pick the path

Run any candidate workflow through these 5 questions.

1. How unique is this workflow to your business?

If the workflow is identical to what 10,000 other companies are doing (general HRIS, general CRM, general accounting): buy. The market has commodity solutions and you should use one.

If the workflow is mildly customized but the bones are shared (lead qualification, support ticket triage, content review): orchestrate. The primitives exist. The composition is yours.

If the workflow is your competitive moat (a proprietary scoring algorithm, a unique customer-segmentation logic, a one-of-one product feature): build. Don't outsource your edge.

2. What's your team's actual capability?

If you have 1 senior engineer and the rest of the team is non-technical: orchestrate is the ceiling. Building from scratch will eat 9 months and ship nothing. Buying is an option if the vendor handles implementation.

If you have a credible 3-engineer team that can ship in production: orchestrate or build, depending on workflow uniqueness.

If you have no engineering team at all: buy or hire an outside partner to orchestrate for you. Don't pretend to build.

3. How much time-to-value pressure are you under?

If the board wants a deliverable in 4 weeks: orchestrate or buy. Build is off the table.

If you have 6 months and the workflow is core to your strategy: build or orchestrate. Buy is off the table because vendor implementation typically eats the same 6 months and locks you in.

If you have 12+ months and the workflow is a moat: build. You have time to do it right.

4. How much vendor risk can you tolerate?

Buy = highest vendor risk. The vendor can raise prices 40% on renewal. The vendor can deprecate the feature you depend on. The vendor can get acquired and pivot.

Orchestrate = medium vendor risk. Any single API can deprecate. Most are swappable in days because your workflow layer is yours and the surface area to a single API is narrow.

Build = no vendor risk on the workflow itself. You still have model risk if your build depends on a foundation model API.

5. How deep is the integration with your existing systems?

Shallow integration (1 to 2 other systems): all three paths work.

Medium integration (3 to 6 systems): orchestrate or build. Buy starts to break because vendor connectors are inconsistent.

Deep integration (10+ systems and bi-directional data flow): build or orchestrate. Buy is rarely the answer because the vendor connectors will not match your specific schema needs.

Real cost example: a sourcing workflow

A 60-person SaaS company needs an outbound sourcing agent that hits LinkedIn, GitHub, and an alumni database, ranks against a rubric, and ships morning shortlists.

Build path. 2 engineers, 14 weeks, $180K loaded labor. Annual maintenance $60K. Time to first value: 14 weeks.

Buy path. Enterprise outbound platform at $4,200/month / $50K/year. Setup fees $15K. Time to first value: 8 weeks. Vendor handles the search but the rubric is constrained to what their UI exposes.

Orchestrate path. Senior engineer, 3 weeks, $14K loaded labor. APIs: enrichment $400/month, LLM $200/month, scheduler $50/month. Total annual $7.8K + small ongoing maintenance. Time to first value: 3 weeks. Full control of the rubric.

Three paths. Three very different cost-time-flexibility profiles. For this specific workflow, orchestrate wins on every axis that matters to a 60-person SaaS company.

For a Fortune 500 with regulatory requirements on candidate-data handling, the answer might flip to buy. For a unique scoring algorithm that's a real differentiator, the answer might flip to build.

The path is per-workflow, not per-company.

The failure modes for each path

The patterns we see often enough to call them rules.

Build failure: the team that ships nothing. Three engineers spend 6 months building an agent stack. The stack works in dev. Nobody on the business side has adopted it. The agents do work that nobody asked for in the format the engineers thought was right. Three months later it's deprecated. Total spend $200K, total value $0.

Build failure: re-creating an API. Engineers spend 8 weeks building enrichment functionality that costs $400/month from an API. The build is technically interesting. It is also a waste of 8 weeks. If a primitive exists as an API at sub-$5K/year, do not build it.

Buy failure: the unused contract. Procurement signs a $250K enterprise platform contract. Nobody on the team uses it. After 12 months, the contract is up for renewal and the team has built their own workflow on the side. The platform was the wrong shape for the actual work.

Buy failure: the integration black hole. You buy a platform. The platform requires 6 months of professional services to integrate. By the time it's integrated, the workflow has changed. You pay the vendor again to re-integrate. This is a treadmill.

Orchestrate failure: no verification layer. The team orchestrates 4 APIs into a workflow that mostly works. Nobody is watching the agent's outputs. After 3 months, the agent has been quietly producing wrong outputs and nobody noticed. Always pair orchestrate with a verification queue.

Orchestrate failure: integration debt. The workflow grows from 400 lines to 4,000 lines over 12 months. Nobody documented why each branch exists. The original author leaves. The new owner cannot safely modify it. Solution: treat the orchestrate layer like real production code. Tests. Docs. Code review. Versioning.

For how this fits the broader pattern, see the cornerstone post on agentic-AI-first business.

What about the open-source agent frameworks?

A reasonable question. There are several open-source agent frameworks in the market in 2026. They sit between build and orchestrate.

They reduce build time by giving you scaffolding (memory, tool use, state management). They do not give you the business logic. The business logic is still the orchestrate layer you own.

Use them where they save real time. Skip them where the abstraction is heavier than the workflow you're building. A 400-line workflow does not need a framework. A 4,000-line agent system probably does.

The decision is not "framework vs no framework." It is "which framework, if any, lets my senior engineer ship the orchestrate layer faster without losing control of the workflow."

The procurement playbook

The 5-step playbook for any agentic AI procurement decision in 2026.

Step 1. Define the workflow in 1 page. What's the input, output, success criteria, error tolerance, integration depth. Not "AI sourcing." Specifically: "for each open requisition, surface 8 to 14 candidates per night from LinkedIn + GitHub + alumni DB, ranked against a 5-criteria rubric, with reasoning logged per candidate, scheduled to my recruiter's morning email."

Step 2. Run the workflow through the 5 questions above. Land on build, buy, or orchestrate.

Step 3. Get 2 quotes / estimates for the chosen path. For buy, this is two vendor proposals. For orchestrate, this is two engineers scoping the work. For build, this is two contractor or in-house staffing plans.

Step 4. Pilot for 30 days. Real workflow, real data, real outputs. Do not commit to anything beyond 30 days until you have measured outputs.

Step 5. Renew or kill. If pilot worked, commit for 12 months. If pilot was mixed, switch paths. The biggest mistake is committing to a 3-year buy contract on the back of a 90-minute demo.

What you can do in week one

The realistic sequencing for a team starting from scratch.

Day 1. List the 8 workflows you most want to automate. Pick the one with the clearest input, clearest output, and lowest customer-facing risk.

Day 2. Run that one workflow through the 5 questions. Land on a path.

Days 3 to 14. If orchestrate: 1 senior engineer ships a working version. If buy: get 2 vendor demos and run a 30-day pilot. If build: scope and staff the project, do not start it without that scoping.

Week 4. Measure. Adjust.

Month 2. Apply the same framework to workflow #2.

You don't need a 6-month "AI strategy" engagement. You need to run the framework on workflows one at a time and let the path emerge.

If you want this decision run for your business by an operator who's built all three paths multiple times, see the blueprint catalog or email christine@operatoriq.io. Email only, no calls.

Next up

This wraps the 5-post batch on the operational side of agentic-AI-first businesses (HR, engineering, economics, comp, vendor selection). Next batch covers the data infrastructure layer, the observability layer, and the security and compliance layer. After that we get into lived-experience posts on what actually happened when we shipped our own org as an agentic-AI-first company.

If a specific workflow is on your mind and you want to know which path it should take, email christine@operatoriq.io with a one-paragraph description. Email only, no calls.

Cheers, Christine