Build, Buy, or Assemble: The Agency AI Stack Decision

Every agency principal weighing AI tooling in 2026 eventually asks the same question in the same wrong shape: build it ourselves, or buy something off the shelf? The framing survives because the people answering it have a stake in one side. Vendors selling subscriptions want you to buy. Dev shops selling engagements want you to build. Almost nobody answering the question has actually operated all three paths long enough to price them honestly.

We have. Kelva has bought off-the-shelf AI tools and hit their walls. We have built a standalone product from scratch and paid for the operations nobody warned us about. And we have assembled a production stack on an orchestration platform that neither buys nor builds in the traditional sense — it rents intelligence and owns process. This piece prices all three paths at the level an agency principal actually needs before committing budget, and shows the decision framework we use with our own clients, including the parts where we tell them not to hire us.

Build vs Buy Is a False Binary

The binary framing persists because it's commercially convenient for everyone selling into it, not because it describes reality. A SaaS vendor's entire pitch collapses if "assemble" is on the table, because assembly means you're not locked into their per-seat pricing. A development agency's day rate looks a lot less attractive next to a path that costs a fraction of a full build. Both sides have a reason to keep the conversation at two options.

The third path — assembly — is not a hedge between the other two. It's a distinct ownership position with its own economics. Assembling an AI stack means running an orchestration platform (the workflow engine that sequences steps, holds state, and handles retries), connecting it to rented model APIs (you pay per call, you don't own or maintain the model), and encoding your own process logic on top — the sequence of research, generation, validation, and delivery steps that make a workflow match how your agency actually works, not how a generic tool assumes every agency works.

This is not the same thing as no-code hype. No-code tools promise that anyone can drag a few blocks together and get production software. What assembly actually requires is closer to what building requires, minus the parts that don't differentiate you: you don't write a language model, you don't maintain GPU infrastructure, you don't build a scheduler or a retry engine, because an orchestration platform already did that work and does it better than a first attempt would. What you do own is everything that makes the workflow yours — the branching logic, the brand-voice injection, the validation rules, the failure handling. You rent the commodity layer and own the differentiated layer. That's the whole idea, and it's why the ownership split matters more than the build-vs-buy label ever did.

We've written the deeper case for the orchestration layer itself in our guide to n8n for agencies — why an agency needs a platform at all, and what fourteen production workflows running on one actually look like day to day. If you're weighing which orchestrator to standardize on, n8n vs Make for PR agencies compares the two head to head. This piece stays one level up: which parts of your stack should live on that platform, which parts should stay a subscription, and which parts, rarely, are worth building outright.

What Buying Actually Gets You

Off-the-shelf AI tools deserve a fair hearing before anyone dismisses them, because for a real slice of agency work, buying is simply the right answer and no honest framework says otherwise. A single-user writing assistant, a research tool, a design generator — for one person working on one brand voice with standard output, an off-the-shelf subscription wins on every axis that matters: zero setup time, someone else's engineering team fixing bugs, a support line to call, and a monthly bill you can cancel without unwinding an integration.

The walls show up specifically at the point where agency work stops looking like individual work and starts looking like agency work. Three walls, in the order agencies hit them.

Multi-client voice separation. A general-purpose writing tool has one configuration: your prompt, your settings, your account. An agency serving eight clients needs eight distinct voices, each with its own vocabulary, tone constraints, and things it will never say, switched correctly every time without a person manually swapping context. Off-the-shelf tools built for a single user were never designed to hold eight separate personas cleanly, and the workaround — eight separate accounts, eight separate logins, eight separate monthly bills — is not a technical failure so much as a business-model mismatch nobody built the pricing tier for.

Volume pricing. Per-seat and per-generation pricing models assume moderate, individual usage. Agency production volume is neither: it's bursty, concentrated in a handful of people who touch the tool dozens of times a day during a crunch and barely at all the rest of the month, and it scales with client count rather than headcount. The math that looked reasonable in the sales demo turns punishing the moment a tool is asked to carry the actual throughput of client production work.

Workflow depth. A demo shows one clean pass: prompt in, output out. Real agency work has approval loops, revision cycles baked into the client relationship, and rules that differ client to client — this account needs legal sign-off before publish, that account has a three-round revision ceiling before it escalates. Off-the-shelf tools generally do not model any of that, because modeling it requires exactly the kind of branching, conditional logic that a workflow platform is built for and a single-purpose SaaS tool is not.

None of this is a knock on any specific product. This section is about the category, not the vendor: buy where the task is single-user and standard, and expect to hit a wall the moment volume, voice count, or workflow branching enters the picture.

What Building Actually Costs

Everyone prices the cost that's easy to price. Development gets a number attached early — a scope, a day rate, a delivery date — because it's the part of the project that looks like a project. Nobody puts a number on operations until they're living inside one, which is exactly backwards, because for anything meant to run for more than a demo, operations is the larger and longer-running cost.

Operations means monitoring whether the thing is still working, responding when it isn't, absorbing the churn every time a model provider deprecates a version or changes an API contract, and — the part that never makes it into a proposal — having a specific person who owns the pager at nine in the evening when a client-facing pipeline goes quiet. None of that shows up in a development quote, because a development quote prices the thing that ships, not the thing that keeps running.

We learned exactly how expensive that gap is the hard way. A scheduled monitoring pipeline we depended on went silent — completely silent, no errors, nothing in the logs — for twenty-two days before anyone noticed. The code was intact. The credentials were valid. Nothing had crashed. The trigger that was supposed to fire on schedule simply stopped firing, and because the thing that should have caught the failure shared the same infrastructure as the thing that failed, there was nothing watching from outside to say so. Twenty-two days of silence, undetected, because the system looked healthy from every angle we were checking it from.

The fix wasn't a smarter internal check. A monitor that shares infrastructure with what it's monitoring can be taken out by the exact event that breaks the thing it's supposed to catch — that's precisely what happened to us. The fix was an external watchdog running on entirely separate infrastructure, checking the primary system's health from outside its blast radius, with each side alerting if the other one goes quiet. Two independent systems watching each other beats one system watching itself, because "watching itself" is the exact failure mode that cost us three weeks of blind spot.

That single incident is the honest shape of what "build" actually costs. It's not a story about bad code — the code that shipped was fine. It's a story about the maintenance surface that opens up the moment something you built is expected to keep running unattended, indefinitely, without anyone remembering to check on it. Multiply that by every dependency, every model-version deprecation, every third-party API that changes its contract without much notice, and the operations bill for a built system compounds in ways a development quote never captures.

None of this means building is always wrong. It means building is priced wrong by almost everyone who quotes it — development first, operations as an afterthought, when it should be the other way around. Building is the right call when the tool itself is the thing you intend to sell: when the maintenance burden is the cost of having a product, not an unplanned tax on an internal convenience. If the workflow is something a client or the market will pay for directly, the economics of owning the operations change completely, because you're not absorbing that cost quietly — you're pricing it into what you sell. We go into the demo-to-production gap in more depth in Production vs Demo: What a Real PR Comment Engine Needs — the short version is that writing the thing was the easy 10%, and everything that makes it survive contact with a real deadline is the other 90%.

The Assemble Path

Assembly is what we've built our production stack out of, and it's the path most agency capability should take — not because we sell it, though we do, but because it's the only one of the three that matches how agency work actually behaves: repeatable enough to automate, varied enough that no off-the-shelf tool models it cleanly, and not itself the product we're trying to sell.

In practice, assembly means an orchestration platform sequencing the steps, model APIs doing the parts that need judgment or language generation, and our own process encoded as the connective logic between them — the branching, the validation, the brand-voice injection, the routing to the right person when something needs a human. Standing that up took real setup work: choosing the platform, learning its patterns, building the first few workflows slowly enough to get the shape right before repeating it. Running it takes ongoing attention, but attention of a specific, bounded kind — we're not maintaining a language model or a scheduler, because the platform already does that reliably. We're maintaining the parts that are actually ours.

The clearest number we have on what that buys is case-study production — the same pattern underlies our AI case study generator. Producing a case study by hand — gathering sources scattered across email, calls, and notes, drafting a first version, running it through internal review, revising, formatting — runs ten to fourteen hours of active work spread across two to four days. That's the honest baseline, not a strawman built to make the after-number look dramatic. Automating the mechanical stages of that pipeline — source gathering, fact extraction, first draft — brings the automated portion down to roughly thirty minutes, with a human editor still reviewing, correcting, and signing off before anything ships. We measured this across our first twenty production case studies and it has held since: a real, sustained collapse in the hours that used to disappear into coordination and first-draft mechanics, with every judgment call — what story to tell, how it reads, what the client will actually approve — left exactly where it belongs, with a person. The full seven-stage breakdown, with the exact handoff points between automation and editor, lives in The Agency Case-Study Pipeline.

Assembly does not solve everything, and it's worth being precise about what it leaves unsolved. You still own the seams — the points where one workflow hands off to the next, where a validation rule needs updating because a client changed their approval process, where a model API's behavior shifts slightly and a downstream check needs retuning. That ownership is real work, ongoing, and it needs a specific skill set on your team: someone who can read a workflow, understand where it branches, and fix it without treating the whole thing as a black box. Platform literacy is a genuine hiring consideration, not a footnote — a team with zero comfort in a workflow tool will feel the learning curve before they feel the payoff. Our guide to self-hosted AI infrastructure covers the architecture layer underneath all of this in more depth, for teams weighing exactly how much of the stack to run themselves.

The Decision Framework

Strip away the vendor incentives on one side and the dev-shop incentives on the other, and the decision comes down to three questions asked in order, not three options weighed all at once.

Differentiation, first. Buy what doesn't differentiate you. If a capability is something every agency in your category needs in roughly the same shape — a research assistant, a general writing tool, a scheduling utility — paying a vendor to have already solved it well is rational, not a compromise. Assemble what does differentiate you: the workflows that encode how your agency specifically operates, your specific brand-voice rules, your specific client approval chains. That's where owning the process logic pays for itself. Build only what you intend to sell. If the tool itself is the product — something clients or the market will pay for directly — the case for owning the full stack, operations tail included, changes completely, because you're pricing that cost into revenue rather than absorbing it as overhead.

Volume, second. Below a certain threshold of monthly use, buying wins on the math regardless of any other factor — there's no volume at which paying setup and platform costs to save a few dozen tool-calls a month makes sense. Above that threshold, the per-seat or per-generation pricing that made buying attractive starts working against you exactly as your business grows, which is a strange thing to accept from a pricing model.

Data sensitivity, third. When the material running through a workflow is client-confidential — the kind of thing a client's own data-handling terms or a regulatory framework like GDPR governs (see GDPR and AI: what you can send) — the calculus tilts toward infrastructure you control, independent of the first two axes. This isn't a call to avoid vendors broadly; it's a call to know, specifically, what data crosses which boundary before a workflow goes live, and to weigh that against how differentiating and how high-volume the task is.

We sell assembly, and it would be dishonest to present this framework without saying so plainly, in the same section where we're presenting it. That's the disclosure the consultancy content answering this question tends to leave out. We don't. And having an angle doesn't mean the framework bends to fit it: we tell most prospects with a single, low-volume, non-differentiating use case to buy something off the shelf for their first attempt, because that's the honest answer for where they are, and a client who buys the right small tool today is a better long-term relationship than one we oversold on assembly they didn't need yet. When a team outgrows that first tool — usually somewhere around the second or third client running through it, or the first approval loop the vendor's tool can't model — that's the point where assembling the next layer actually makes sense.

Pricing the Three Paths

None of this means anything without honest numbers, so here's a summary-level range for a representative agency use case — ongoing content production for a multi-client roster — across all three paths. These are ranges, not quotes; every agency's specifics will move the number, and where we're estimating rather than reporting our own bill, we say so.

Buying off-the-shelf tools scales with seats, and multi-client voice separation means multiple seats — the bill grows with your client roster, not your usage. What that buys: zero setup time, someone else's uptime and bug-fixing, and a bill you can cancel with a month's notice. What it excludes: multi-client voice separation past a couple of clients, and any workflow logic beyond a single generation step.

Building a comparable capability from scratch — a real production tool, not a prototype — runs into real development budget before a line of maintenance is spent, and that number alone understates the total by omitting the operations tail this piece has argued is the larger cost. We don't itemize a build budget here on purpose — the line-by-line breakdown, including the parts almost everyone underprices, deserves its own treatment. What we can say plainly from firsthand experience is that the development line item is the smaller of the two numbers, and any build budget that doesn't carry a comparable ongoing operations line is priced to surprise whoever signs off on it.

Assembling sits between the two, and it's the path we can speak to most directly because it's what we run: a moderate setup cost to design and build the first several workflows properly, an ongoing platform and API bill that scales with usage rather than seat count, and an operations load that's real but bounded — bounded because the platform absorbs the parts (scheduling, retries, execution history) that would otherwise be the expensive part of a from-scratch build. The honest tradeoff against buying is setup time and the need for someone on the team who's comfortable inside a workflow platform; the honest tradeoff against building is that you don't own the orchestration layer itself, which is fine, because owning it was never where the value lived.

Evaluating Vendors When Everyone Demos Well

Every AI vendor's demo looks good. That's what a demo is for. The problem is that a demo is built to show a happy path with clean input, one user, one context — precisely the conditions that don't describe agency production work. The gap between a convincing thirty-minute demo and a tool that survives eight clients, inconsistent input, and a Tuesday afternoon with three deadlines at once is exactly the gap this piece has spent its length describing, and it's invisible in the sales call.

Three questions surface more of that gap than a full feature checklist:

"Show me this running with three different voice or brand profiles active at once, not switched between demos." A tool built for multi-client work handles this without ceremony. A tool that wasn't will visibly struggle, hedge, or reveal that "profiles" means re-entering settings each time.

"What does the bill look like at our actual monthly volume, not your example numbers?" Ask for the calculation against your real usage pattern, in writing, before signing — the gap between the marketed price and the volume-adjusted price is where most buy-path budgets go wrong.

"Walk me through what happens when this fails mid-run — who finds out, and how fast?" The answer tells you whether the vendor has ever operated the tool under real load, or only ever shipped it.

A formal vendor evaluation needs a fuller checklist than a gut check. These three are the ones worth asking before that deeper process even starts.

Frequently Asked Questions

Is it cheaper to build our own AI tools or buy them?

Almost always cheaper to buy, if the comparison only counts development against a subscription bill. The comparison that actually matters counts operations — monitoring, incident response, model-version churn, the person who owns the pager — against the subscription bill, and that's a different, much closer number. Building only wins that comparison when the tool is something you intend to sell, because then the operations cost is priced into revenue instead of absorbed as overhead.

What does "assembling" an AI stack mean?

An orchestration platform to sequence and run the steps, rented model APIs to do the language and judgment work, and your own process — the branching logic, brand-voice rules, validation, and handoffs — encoded as workflows on top. You own the layer that makes it yours; you rent the layer that's a commodity everywhere else.

When should an agency build custom AI tools?

Only when the tool is the product — when a client or the market will pay for it directly, and the ongoing operations cost is something you're pricing into that revenue rather than quietly absorbing as internal overhead. For every use case where the tool exists to support your own production, not to be sold, assembly or buying will beat a from-scratch build on total cost almost every time.

How much does an assembled AI stack cost to run?

A moderate one-time setup cost to design and build the first workflows properly, then an ongoing bill driven mainly by API usage rather than seat count, plus a bounded amount of internal time to maintain the seams between workflows. What drives the number up or down: how many distinct client voices and workflows you're running, how much volume passes through each month, and how much of the maintenance you handle in-house versus with outside help.

The Framework in Three Sentences

Buy what doesn't differentiate you. Assemble what does. Build only what you intend to sell — and price the operations tail honestly before you commit to it, because that's the number almost everyone gets wrong. If you're past the point where an off-the-shelf tool covers your multi-client volume and you want the assembly path built around your own process instead of a generic template, talk to us.