Build vs buy an AI agent system: an honest decision framework

What build vs buy actually means for AI agents

You are not choosing whether to build a model. You will rent that either way. The real split is the layer above it: the code that picks an agent, feeds it the right context, calls a tool, checks the result, retries the bad ones, and logs what it did. Call it the runtime. The runtime is what you build or buy.

That layer is small on day one. A loop, a prompt, two tools. It grows when real use hits it. A user asks the same thing twice and gets two answers. A tool call times out and the agent says it worked. Someone leaves and no one can say why the agent was told to skip step three. None of that is a model problem. All of it lives in the runtime.

So write the question down in the form that can be priced: who owns the runtime, who owns the data path, and who is on call when it breaks at 2am on a Sunday. A demo answers none of those. A year of use answers all three.

• The model: rented in both cases. Not a build vs buy question.
• The runtime: the loop, the tools, the state, the gate. This is the choice.
• The data path: what the agent may read, and where the text lands.
• The pager: who wakes up, and who can fix it while awake.

Why the demo takes a week and the system takes two quarters

A working demo is cheap now. One good engineer can wire an agent to a tool, put a chat box on it, and show it doing real work in a week. The demo is honest about one thing: the model can do the task. It is silent about the other ten things the task needs to be a system.

The gap shows up in an order you can predict from the mechanism, not from a survey. First the agent gets the wrong data, so you add search. Then it gets the right data but says it in the wrong shape, so you add a schema. Then it works for one user and breaks for the next, so you add per-user state. Then it does the same job twice and sends two emails, so you add keys and a gate. Then someone changes a prompt and three things get worse, so you add evals. By that point you have written a small platform and no one on the team calls it that.

That is the cost people miss. Not the first week. The next forty, spent on plumbing that has nothing to do with your product. If you are going to pay it, pay it on purpose, for a reason you can say in one sentence.

The parts of building that never make it into the estimate

Ask a team what it costs to build an agent system and you get the model call and the UI. Here is the rest of the list. Each line is real work, each one has a known shape, and each one is skipped in the first plan.

Read this list as a budget, not as a warning. Every item is doable. Four of them are the reason the second quarter looks nothing like the first.

• Auth. Not your app login. The agent needs a token for each tool it touches, scoped per user, with a refresh path. Human accounts and agent accounts age at different rates, and the refresh is the part that breaks on a holiday.
• Memory. What the agent knows across turns, across days, and across people. A chat log is not memory. You need a write path, a read path, a size cap, and a rule for what to drop first.
• Evals. A test set of real cases, a way to score them, and a habit of running them before a prompt ships. Without it, every prompt edit is a guess and you learn the result from a user.
• Retries and keys. Models time out. Tools return half a result. You need to know which calls are safe to repeat, and hold a key so the same job cannot send the same invoice twice.
• Observability. One trace per run: the prompt, the tool calls, the tokens, the cost, the end state. If you cannot open one bad run and read it top to bottom, you cannot fix anything.
• The gate. The step where a human says yes before the agent sends, posts, pays, or deletes. Cheap to add early, painful to retrofit once a dozen call sites exist.
• The second engineer. One person can hold a runtime in their head. Then they go on leave, or leave. The system is only as alive as the number of people who can change it safely, and that number needs to be at least two.

A worked cost comparison, with the assumptions written down

Below is a first-year cost model for one line of work, such as a content line or a support line, used by ten people. The unit is engineer-weeks, not money, because your loaded cost per engineer is a number you know and I do not. Multiply the column by your own rate and add the token bill, which you pay on your own account in both cases.

The numbers are assumptions. They are not a study, a survey, or a benchmark. I have written each one as a claim you can argue with, and the model is only useful if you replace them with your own. If your team has already built auth for tools, cut that row to zero. If you have no eval habit at all, the build column is worse than what I wrote, not better.

Read the total as a range, not a figure. With the assumptions above, the build column comes to about four times the buy column, and the gap is not the agent logic. It is auth, evals, and the trace. Change an assumption and the ratio changes with it, which is the point of writing them down.

• Assumption 1: one line of work, ten users, four tools, one host. Not a whole company.
• Assumption 2: your engineers are good and have not built an agent runtime before.
• Assumption 3: you pay the model tokens yourself in both columns. That bill does not change with the decision.
• Assumption 4: buying still costs you real weeks. Nobody installs a system and walks away.
• Assumption 5: first year only. Year two is mostly upkeep on the build side and mostly price on the buy side.

What buying an AI agent platform actually costs you

Buying is not free and the price is not the invoice. Three costs matter and none of them show up on a pricing page.

Lock-in is the first. The question to ask is not whether you are locked in. You are, a bit, in every case. The question is the size of the exit: if this vendor doubled its price or shut down next month, how many weeks to be running again. If the answer is a week, the lock-in is cheap. If the answer is a quarter and nobody can name the steps, you are buying a dependency, not a tool.

Fit is the second. A bought system encodes someone else's idea of how the work goes. That is most of its value, and it is the thing that will grate. If your work is normal, a stranger's shape fits fine and saves you months. If your work is the whole reason your company wins, a stranger's shape will cost you the edge and no amount of config will put it back.

The data boundary is the third, and it is the one that gets a deal killed in review. Where does the text go. Who can read it. Is it used to train anything. Can you point at a document that says so. A vendor who answers that in one page is telling you they have been asked before. A vendor who sends a sales call instead has told you something too.

• Exit cost: weeks to be running on something else. Ask for the steps, not a promise.
• Fit cost: the work you will reshape to match the tool. Real, and worth it when the work is generic.
• Data cost: where the text sits, who reads it, what it trains. Get it in writing before the pilot, not after.
• Upgrade cost: a vendor change you did not ask for can break a prompt you depend on. Ask how they version it.

When building your own AI agent system is the right call

Build when the runtime is the product. If what you sell is agents doing a job for a customer, the loop is your margin and your moat, and handing it to a vendor means renting the thing you are supposed to own. Same answer if the agent touches a system so odd that no vendor has ever seen its shape.

Build when the constraint is hard and legal. Some data cannot leave a boundary, and the sentence saying so came from a regulator, not from a preference. In that case the build cost is not a choice, it is the price of being allowed to operate, and the comparison table above is the wrong tool.

Build when you already have the platform. If you run a tool bus, an eval harness, a trace pipeline and an on-call rota, most of the rows in the cost table are already paid. The marginal cost of one more agent line is small, and buying would mean a second control plane beside the one that works.

One warning on all three. Teams pick build for a fourth reason they do not say out loud: building is more fun than buying, and the first week of an agent build is the most fun week of the year. That is not a reason. Write the reason down, show it to someone who will not be writing the code, and see if it survives.

• The runtime is what you sell.
• A rule you did not write forbids the data leaving.
• You already own the platform pieces and the rota.
• You have a second engineer who can hold it. Not a plan to hire one.

When buying is the right call, and how to buy well

Buy when the work is real but generic. Drafting, research, record keeping, the weekly report, the first pass at a spec. These jobs look the same in most companies, and the parts you would build, memory and evals and the gate, would end up looking like everyone else's. Paying for the shape is the cheap move.

Buy when the team is small. Below a certain size, one engineer on a runtime is your entire engineering capacity for a quarter. That is not a build decision, it is a decision to stop shipping your product for three months.

Buy when the thing you actually need is speed of learning. A bought system tells you within two weeks whether an agent helps this line of work at all. That answer is worth more than a better runtime, because the answer is often no, and finding out for two weeks of effort instead of two quarters is the whole point.

Buying well means buying with an exit. Keep your prompts and your eval set in your own repo. Keep the token account in your name. Ask, before you sign, what you walk out with: the text, the config, the history, in a format you can read without their app. If a vendor cannot answer that, the price on the page is not the price.

The middle path: buy the runtime, own the judgment

Most good answers are not a clean side. The split that holds up is this one: buy the parts that are the same in every company, own the parts that are only true in yours.

The parts that are the same: the protocol to reach tools, the auth dance, the trace format, the retry rules, the approval step, the roster of agents for a normal line of work. None of that is your edge. Writing it again teaches you nothing a vendor's docs would not have.

The parts that are only yours: the constraint the work must respect, the tone, the list of things the agent may never do, the eval cases that come from your own bad days, and the record of what happened. Keep those in your repo, in plain files, under review like code. Then a vendor change is a bad afternoon and not a rebuild.

There is a cost to the middle path, and it is coordination. Two owners means two release cycles and a seam between them, and seams are where bugs live. You pay that in exchange for a cheap exit. In my experience it is the right trade for anything that is not the core of the business, and the wrong one for anything that is.

• Own: the constraint, the tone, the never-do list, the eval set, the record.
• Buy: the protocol, the auth, the trace, the retries, the gate, the roster.
• Keep the token account in your name, whichever side you land on.
• Keep prompts in files, in git, with a diff. Not in a vendor text box.

The exit test: the only number that settles the argument

When a build vs buy debate stalls, it is usually because both sides are pricing the entry. Price the exit instead. Pick the vendor you are considering, then answer this in writing: if they were gone on Monday, what would we do, in order, and how long would it take.

Run the same test against your own build, with the lead engineer gone instead of the vendor. The build side often has the worse answer, for a structural reason: the vendor at least wrote docs, while the runtime knowledge sits in one head and not in a repo.

If the system you are buying speaks the Model Context Protocol, the mechanical part of the exit is small, because the config is a few lines you own. A server entry reads like the block below, and the spec is public.

Three lines of config. Swapping that url is the mechanical part of an exit, and it is the easy part. The hard part is everything that lived in the vendor and not in your repo: the prompts, the eval cases, the memory, the audit trail. Whatever you cannot paste into a new config is the real lock-in, and it is worth measuring in weeks before you sign anything.

• mcpServers:
• your-os:
• url: https://mcp.example.com/api/mcp
• Exit test, written answer required: who does what, in what order, in how many weeks.
• Run the same test on your own build with the author of the runtime removed.

Failure modes on both sides, and what causes them

Both paths fail in ways you can see coming. These are the ones that recur, with the cause rather than the symptom, because the symptom always looks like the model being bad.

The pattern under most of them is the same: someone treated an agent as a feature when it was a system, or as a system when it was a feature. Match the weight of the decision to the weight of the thing.

• Build: the agent works for the author and no one else. Cause: prompt tuned against one person's data, never run on a shared test set.
• Build: cost triples in month three with no change in use. Cause: no per-run token trace, so nobody saw the retry loop.
• Build: the system freezes after the author leaves. Cause: one owner, no docs, prompts in a database instead of files.
• Build: an agent sends the same message twice. Cause: retries without keys, and no approval step on anything that leaves the building.
• Buy: the pilot goes well and adoption dies at week six. Cause: bought for a problem nobody in the room actually had, measured by demo instead of by work done.
• Buy: the tool is fine and the answers are wrong. Cause: the data boundary was never set up, so the agent is reasoning about a stale copy.
• Buy: a vendor update breaks a workflow on a Tuesday. Cause: no pinned version, no eval set of your own to catch it.
• Both: nobody can say if it helped. Cause: no baseline measured before the pilot started.

Where Agentik sits in this decision

Since this is our blog, the honest disclosure. Agentik {OS} is a buy-side option with a specific shape: official operating systems installed on the MCP host you already pay for, which today means Claude, Claude Code, Cursor, ChatGPT, Codex, or Hermes. The host runs the model and pays the tokens. We never buy your tokens, which means the cost line that scales with use stays on your own account and your own bill.

In the terms of this article, that puts us on the middle path. You buy the roster and the protocol: Growth OS compiles 48 agents, Librarian 22, Builder 21, Content 9. Work that publishes, sends, spends, or resets waits for a human approval. One MCP tool, talk, answers a turn and returns a compact pack, about 2 KB on Growth OS against about 110 KB for the full roster, which is how the host stays cheap to run. Pricing is $19.99 lifetime for one OS, or $19 a month for three, $99 for ten, $199 for unlimited.

Where we are not the answer: if the runtime is your product, buy nothing, including from us. If the data cannot leave your boundary, a hosted endpoint is the wrong shape. If your work is strange in the way that makes you money, a published roster will fit badly, and we would rather you knew that before the invoice than after. The install path is in the Docs, and /docs/mcp has the per-host config.

What this framework does not settle

The cost table is a model, and every model is wrong in the same way: it prices the work you can name. The line it cannot price is organisational. A bought system that the team quietly refuses to use costs more than a build that three people love, and no table will tell you which one you have. The only way to find out is to put the thing in front of the people who will use it and watch what they do in week six, not week one.

This framework also assumes the ground stays still for a year, and it does not. Model prices move, context windows move, and a capability that needed a custom build in one quarter arrives as a feature in the next. That cuts toward buying small and reversibly rather than building for a future spec. It is a bias, and I am stating it as one rather than pretending it fell out of the analysis.

Last limit, and it is the flat one: I cannot tell you what a vendor will do, and neither can the vendor. Contracts, exit clauses and data terms are how you handle that, and they are not an engineering decision. Bring the person who reads contracts into the room before the pilot, not after the pilot went well.