Build an AI Agent or Buy One? The Real Cost of Each Path

The demo happens on a Friday. A senior engineer has spent two weeks wiring a language model to the Gmail API and HubSpot. Inbound leads get read, classified, summarized, and pushed into the CRM with a suggested reply. It works, live, in front of the leadership team. Everyone is convinced. The build vs buy AI agent question feels settled before it was ever really asked: why pay a vendor for something your own team just built in two weeks?

Eighteen months later, that prototype is often the most fragile system in the company. The prompt file has grown to a thousand lines of special cases. The Google OAuth consent screen needs re-verification. The model it was built on has been deprecated and the replacement behaves differently in ways nobody has tests for. The engineer who built it took a job somewhere else, and the person who inherited it is afraid to touch it.

That gap, between the two-week demo and the eighteen-month reality, is the entire build vs buy decision. This article is an attempt to price that gap honestly: what building actually costs line by line, where maintenance and drift come from, when building genuinely wins, and when it never pays back no matter how good your engineers are.

Why the build vs buy AI agent question keeps coming back

Ten years ago, "should we build our own CRM" was a question only a confused company asked. The build vs buy AI agent question is different, and it keeps resurfacing for a specific reason: the demo is misleadingly cheap.

Building a CRM from scratch obviously takes a year, so nobody starts. Building an AI agent prototype takes days, so everybody starts. Frameworks and model APIs have collapsed the cost of the first 20 percent of the work to nearly zero. What they have not collapsed is the other 80 percent: authentication, reliability, evaluation, observability, permissions, and the permanent tax of keeping the thing working while everything underneath it moves.

So the question is not "can we build this?" You almost certainly can. The question is "should we own this forever?" Ownership, not construction, is what you are actually deciding. If you have not yet worked out whether you even need an agent rather than plain deterministic automation, start with automation vs AI and where the line actually sits, because a surprising number of "agent" projects turn out to be a cron job wearing a trench coat.

What building actually costs, line by line

Here is the honest bill of materials for taking an agent from demo to production. None of these items appear in the Friday demo.

The prototype. One to three engineer-weeks. Read from a source, call a model, write to a destination. This is the cheap part and the only part most build-vs-buy conversations ever price.

Authentication, per tool. Every SaaS tool the agent touches needs OAuth, token refresh, scope management, and secret storage. Some are trivial. Some are not: as of mid-2026, Google still requires app verification for restricted Gmail scopes, a process that involves a third-party security assessment and can take weeks. Multiply this by every tool the agent will ever touch, because you will not stop at one.

Reliability engineering. Retries with backoff. Idempotency, so a retried step does not send the same email twice. Rate-limit handling for every API, each with its own quirks. A queue, because synchronous chains fall over. Partial-failure handling: what happens when step three of five fails at 2 a.m., and who finds out? This is unglamorous work and it is most of the real codebase.

An evaluation harness. You cannot safely change a prompt in production without regression tests, and you cannot write regression tests for probabilistic output without building an eval suite: recorded cases, scoring logic, a way to compare runs. Teams that skip this end up in the worst possible state, where everyone is afraid to change the prompt because nobody knows what will break.

Observability. Run history, per-step logs, token cost tracking, a way for a non-engineer to answer "what did the agent do to this record and why?" Without this, every complaint from sales becomes an engineering investigation.

Permissions and audit. Least-privilege scopes, an audit trail of every action taken in every connected tool, and answers ready for the security review, because the moment the agent touches customer data, your auditors and your customers' auditors will have questions.

Model migration. Providers deprecate models on roughly annual cycles. Each migration changes behavior, which means re-running evals, re-tuning prompts, and re-earning trust. This is not a one-time cost. It recurs for the life of the system.

Do the arithmetic with your own numbers, but the shape is consistent: the prototype is two weeks, production hardening is two to four months, and then maintenance settles in at some permanent fraction of an engineer. A fully loaded senior engineer in the US runs somewhere around $200,000 a year or more. If keeping the agent alive takes even 20 percent of that person indefinitely, you are carrying a $40,000-a-year line item before you count the opportunity cost of what they were not building instead.

Maintenance and drift: the bill that compounds

Upfront cost is at least visible. Drift is the cost that catches teams off guard, and it arrives from four directions at once.

Model drift. The model you built against will change. Deprecations force upgrades; upgrades change behavior. A classification prompt tuned for one model version quietly starts making different judgment calls on the next one. If you have evals, you catch it in a day. If you do not, you catch it when someone notices a quarter of leads were routed wrong for three weeks.

API drift. HubSpot revises API versions. Jira Cloud changes payloads. Slack tightens scopes. Stripe evolves its event model. Every connected API is a subscription to future breaking changes, and the maintenance surface of your agent scales with the number of integrations, not with how clever the agent is. A vendor amortizes that surface across thousands of customers. You carry it alone.

Process drift. The workflow the agent automates does not hold still. Sales adds a pipeline stage. Finance renames the QuickBooks accounts. The agent does not crash; it keeps confidently doing the old thing. Silent wrongness is the signature failure mode of unmaintained agents, and it is worse than an outage because nothing pages anyone.

Prompt rot. Every edge case gets patched with another paragraph of instructions. Two years in, the prompt is an archaeology site: layers of fixes for problems nobody remembers, where removing any line feels dangerous and adding one has unpredictable side effects.

None of these are hypothetical failure modes; they are the default trajectory of any integration-heavy system. The teams that survive them are the ones that budgeted for them on day one. The teams that did not are heavily represented in the graveyard of stalled AI pilots.

When building wins

Building is the right call more often than platform vendors admit, and it is worth being precise about when.

The agent is the product. If the agent is what your customers buy, you build. Full stop. You need control over every behavior, and the maintenance burden is just cost of goods sold.

Deep proprietary logic. If the core of the work is judgment encoded in your own data and rules, think underwriting models, claims triage on internal document formats, a pricing engine with ten years of tuning, then no platform's primitives will express it. The glue around it might be bought, but the judgment layer is yours to build.

Environments vendors cannot reach. On-prem requirements, air-gapped networks, data-residency rules that no SaaS vendor satisfies. If the data cannot leave, the agent must come to the data.

Genuine scale with an existing platform team. If you already run ML infrastructure, an eval culture, and an on-call rotation, the marginal cost of owning one more system is real but manageable, and at thousands of internal users the economics can favor owning.

One honest test before you claim any of these: write down, before writing code, who owns the agent in year two, what the eval suite looks like, and which on-call rotation it joins. If those three questions have no answers, you are not choosing to build; you are choosing to prototype and hoping. It also pays to be clear-eyed about the technology's actual ceiling, which is why what AI agents still cannot do is worth reading before committing either way.

When building never pays back

The flip side is equally specific. Some builds are underwater from the first commit, and they share a profile.

Commodity glue work. Lead triage from Gmail into HubSpot. Invoice chasing across Stripe and QuickBooks. Sprint summaries out of Jira. Weekly pipeline reports. A morning digest of what changed across your tools. These workflows are near-identical at every company, which means vendors can amortize the integration and maintenance cost across their whole customer base, and you cannot. Building commodity glue in-house means paying full price for something the market sells at a fraction of it.

Integration-heavy, logic-light. If the agent's difficulty lives in connecting eight SaaS APIs rather than in any proprietary reasoning, you are signing up for eight subscriptions to breaking changes in exchange for logic a platform expresses in a sentence. The maintenance math never converges.

No platform team to inherit it. In a company under roughly 50 people with no dedicated platform engineers, an internal agent has a bus factor of one by construction. When that person leaves, the agent becomes an unowned liability that either quietly rots or gets turned off.

The spec is still moving. If the team cannot yet write down exactly what the agent should do, buying is how you iterate cheaply, in configuration, in days. Building bakes this week's guesses into code that costs real money to change. Prototype on a platform first; earn the right to build by discovering a requirement no platform can meet.

The build vs buy AI agent decision, in one table

Read the table as a weighting exercise, not a verdict. If your project's value concentrates in the "proprietary logic depth" row, build. If it concentrates almost anywhere else, the buy column compounds in your favor every month.

If you buy: what actually matters in evaluation

Buying badly is its own way to lose the build vs buy bet, so the evaluation deserves the same rigor you would apply to an architecture review.

Demand citations. Every answer the system gives about your business should point at its source: the email, the CRM record, the database row. An agent you cannot audit is an agent you cannot trust with anything that matters.

Demand approval gates. Actions inside your tools, sending the email, updating the deal, filing the ticket, should happen on your instruction with your explicit approval, with autonomy reserved for read-side surfaces like briefings and monitoring. Anything that writes to customer-facing systems unattended should make you nervous.

Demand run history and versioning. Workflows need retries, version history, and a full log of every run. This is the observability you would have had to build; make sure you are actually getting it.

Test depth on your five tools. Ignore the logo wall. Connect the five tools your team lives in and run your ugliest real workflow through them in the first week.

Price the whole thing. Per-task pricing looks cheap until usage grows. Prefer pricing where AI usage carries no markup and where you can see exactly what a seat costs at scale.

For what it is worth, this checklist is the one Skopx is built against: chat with nearly 1,000 connected tools where every answer cites its source, workflows you create by typing one sentence that assemble on a canvas and run with retries, versions, and full run history, and actions that execute only with your approval. Team is $16 per seat per month with 2.3 million AI tokens included per seat, Solo is $5 per month with your own key at provider rates, and there is zero markup on AI usage either way. Customer data never trains models, with AES-256 at rest, per-organization row-level isolation, and SOC 2 controls in place. You can see what a one-sentence workflow looks like in practice and judge the claims against your own stack. And whatever vendor you evaluate, work through the questions worth asking before buying an AI agent first; the broader buyer's guide to AI agents covers the category-level tradeoffs.

The middle path: buy the plumbing, keep the logic

The framing of build versus buy as a binary is itself the most common mistake. The strongest teams split the stack.

Buy the orchestration layer: the OAuth handling, the retries, the run history, the integration maintenance, the model migrations. This is undifferentiated heavy lifting, identical at every company, and exactly what platforms amortize well.

Keep the proprietary judgment: if you have a pricing model, a scoring system, a decision engine that constitutes real competitive advantage, keep it as an internal service your team controls, and let the bought layer handle the glue around it.

Sequence it deliberately: buy first to learn the true shape of the problem while iteration is cheap. Most teams discover the platform covers the whole job. The minority who hit a genuine wall now know precisely which component justifies building, and they build one sharp, well-scoped system instead of a sprawling one. That is a far better outcome than the usual pattern, where an ambitious build absorbs two quarters and then joins the pilot graveyard.

FAQ: build vs buy AI agent

How much does it really cost to build an AI agent in-house?

Use this formula with your own numbers: build weeks times fully loaded weekly engineering cost, plus a permanent maintenance fraction times fully loaded annual cost, plus model API spend. For a typical integration-heavy internal agent, expect two to four months to production after the prototype, then 10 to 30 percent of an engineer indefinitely. The maintenance term dominates over any horizon longer than a year, and it is the term the Friday demo hides.

How long does building a production AI agent take?

The prototype takes one to three weeks. Production, meaning OAuth across every connected tool, retries and idempotency, an eval suite, run logging, and a passed security review, typically takes two to four months of focused work. Teams that ship the prototype straight to production skip that gap and then pay for it in incidents and silent misbehavior instead.

Does using an open-source framework like LangChain change the math?

Less than expected. Frameworks compress the prototype phase, which was already the cheap part. Per their public positioning as of mid-2026, orchestration frameworks give you abstractions for chaining model calls and tools; they do not maintain your OAuth apps, absorb third-party API changes, run your evals, or take your on-call pages. The 80 percent of cost that lives in ownership is untouched. Check the current documentation of any framework you are considering rather than taking either its marketing or this paragraph on faith.

Is buying an agent platform just lock-in?

There is switching cost, but compare it honestly to the alternative. Leaving a platform means exporting your data and rebuilding workflow definitions elsewhere: real work, measured in days or weeks. Leaving your own build means either a rewrite or continued ownership of a system nobody wants. In-house code is lock-in too; it just locks you to your own past decisions and to whoever still understands them. Reduce platform risk by preferring vendors with data export and transparent pricing, not by defaulting to build.

Can we start by buying and build later if we outgrow it?

Yes, and this is usually the correct sequence. Buying first costs a subscription and teaches you the real shape of your requirements. Building first costs months and bakes in guesses. If you genuinely outgrow the platform, you will hit a specific, nameable wall, and that wall becomes a precise spec for a narrow build. Most teams never hit it. The ones that do build better systems for having waited.

The short version

Build when the agent is your product, when the value lives in proprietary judgment no platform can express, or when your environment is one vendors cannot enter, and only when a named owner, an eval suite, and an on-call rotation exist before the first commit. Buy when the work is glue across SaaS tools, when you have no platform team to inherit the system, or when the spec is still moving. When in doubt, buy first, learn the true requirement cheaply, and build only the narrow piece that proves you need it. The prototype was never the cost. Ownership is the cost, and the build vs buy AI agent decision is simply the question of who you want to pay it to.