Your team can build the agent. Should it?

Build versus buy is not about whether the team can make a prototype. It is about whether maintaining that infrastructure six months from now is differentiating: permissions, traces, a cost limit, evals, and someone on call. You build what is product. You buy or split what is plumbing.

The question is not "can we build an AI agent?". It is "is it differentiating to maintain this infrastructure six months from now?". In meetings we almost never argue about whether the team can make a prototype. The debate starts when the roadmap is already tight and someone says "we'll do it ourselves".

That sentence is reasonable. Many SaaS teams can build a first version. What rarely makes it onto the slide is the maintenance: permissions per tenant, traces, a cost limit, evals, and someone on call when the model changes. We break that down in the jump from demo to production and in the agent's TCO (total cost of ownership: what it costs to deploy and operate it, not just the model). Here we stay with the decision: build, buy, or split.

The real competitor is internal development

The outside vendor is not the most frequent rival. It is the internal team with an intern, a weekend, and a "we already have it". That path produces excellent demos. It also produces systems nobody wants to inherit in month 6.

We are not going to tell you that you cannot build it. If your team ships product every week, it can stand up an agent that talks to your API. The useful conversation is another one: is that layer what your customers pay for, or is it plumbing that any SaaS with agents ends up repeating? Gregor Hohpe sums it up in Buy vs. Build Revisited (AWS): "build what differentiates you and buy the rest" is a good starting point, not the end of the decision. The nuance that gets skipped most often is opportunity cost. Pulling the person who builds the product so they can rebuild observability, permissions, and cost limits is not paid only in salary. It is paid in what stops shipping.

If the agent is the product (the customer is buying that autonomy), building makes sense. If the agent is one more feature inside a SaaS that already has a roadmap, building the full platform is usually a second product disguised as a spike.

What the team can (and should) build

There are pieces the vendor should not own. They are the ones that make the agent your agent and not a generic chat over a PDF.

The use case and the metric. Which flow, what counts as success, who the user is. Without that there is no build vs buy that holds: you are buying or building fog.

The tools on your domain. Endpoints, real permissions, business objects, the errors only your product knows. That is differentiating. A generic harness does not know what "close an invoice" means in your tenant.

The product judgment. What the agent can write, what it asks confirmation for, what it never touches. That is not delegated to a platform. It is decided at home.

The data and the golden set. Anonymized real cases, regressions, the "this is what a hit looks like". Whoever owns that evaluation owns the improvement. Whoever does not depends on the vendor and on luck.

If your team only has time for one of these, let it be the use case plus the tools. The rest of the plumbing (agent identity, traces, cost limit, rollback) is what gets underestimated most often and costs the most to redo.

What is usually commodity

Commodity does not mean "cheap" or "dumb". It means it does not differentiate you against the competitor who is also putting an agent into their SaaS.

Orchestration and runtime. Queues, retries, timeouts, sandboxes, the tool call loop. Every team ends up building something similar. The difference is in operating it, not in inventing it.

Agent observability. Correlated traces, prompt and model versions, cost per trajectory. You need it. It is not what the customer chooses when they compare two products.

Cost control. Limits per tenant, per thread, per day. Alerts. Kill switch. Without this the unit economics break. Building it once for one agent is fine. Building it again for the second is already debt.

Connectors and MCP over standard APIs. Useful. Rarely the moat. If your advantage is "we have MCP", any competitor has it next quarter.

The model layer. Routing, fallback, switching providers. Important so you do not marry one API. It is not the product you sell, unless you sell exactly that.

Buying commodity does not take ownership of the case away from you. It takes away the work of standing the scaffolding back up every time an engineer leaves or the model changes price.

Opportunity cost and a packed roadmap

The "it's cheaper to do it inside" argument almost never compares the same things. It compares an internal prototype with an external product. The prototype does not come with evals, on-call, or a cost limit. The product, if it is serious, does.

Hohpe presses the same point: the real cost of building is not the payroll of whoever writes the first prompt. It is what that profile would stop shipping in the product that pays the bills today. In a SaaS with a packed roadmap, that opportunity cost is usually a multiple of the visible spend.

Three symptoms that "we'll do it ourselves" is eating the quarter:

The agent has no owner with a name. It lives in a Slack channel and in the head of whoever made the demo.

Every week of platform is a week the feature the customer already asked for does not ship.

The pilot has been going for months because "one more thing is missing" and that thing is always plumbing: permissions, traces, a cost limit, a rollback.

Time to market here is not vanity. It is how many learning cycles you lose while you rebuild something the user will not see. A well-split hybrid (you own the case, a platform owns the operations layer) usually shortens that without handing the domain to the vendor.

Lock-in, open source, and an exit

Fear of lock-in is legitimate. It is also badly framed if it only applies to the software you buy.

Building it yourself also binds you. Hohpe says it without wrapping: migrating off an internal system can be just as hard, or harder, than leaving a commercial package. You stay trapped in your own monolith, in the two people who understand it, and in the debt that internal flexibility kept accumulating.

Buying binds you another way: data in an opaque format, skills you cannot export, a runtime that does not run outside. The useful question is not "is there lock-in?" (there always is). It is "what is the exit and in how many weeks?".

A serious exit usually looks like this:

Swappable models. Do not build the product around a single inference provider.

Tools and skills as your code. If you change harness tomorrow, the contract with your API comes with you.

Exportable traces and evals. If you cannot take the failure history with you, you do not have learning: you have a rental.

The option to run it on your infra. Hugging Face is clear when it talks about open models: a "private" plan on a hosted API still runs on someone else's servers. Local or self-hosted means hardware you control. They are not the same, and you should not decide architecture as if they were. The post is on their blog about open models locally.

Open source is not a talisman. It is an exit lever. If the code that operates the agent can be audited and, if it comes to that, hosted, lock-in drops. If "open" is only the model and the rest is a black box, the risk has moved, it has not disappeared. At Devic that lever is in open source: the case stays yours; the layer can be inspected and, when needed, operated inside.

Hybrid matrix: four quadrants, one decision

Forget the binary. Most teams that reach production do not choose build or buy. They choose which part of each.

High differentiation, standing team. Build the agent and the platform. You are an agent company that also has a SaaS, or you have platform engineering with an explicit mandate. Buying here would slow you down.

High differentiation, saturated team. Build the case, the tools, and the judgment. Buy runtime, observability, and cost limits. This is the most frequent quadrant in a B2B SaaS that wants an agent in product this quarter, not next year.

Low differentiation, hurry. Buy or, better, do not do it yet. A "questions about the manual" agent that does not move a metric does not justify a home-grown platform or an expensive vendor. Narrow the case.

Low differentiation, high maintenance. Do not build it and do not buy it as a product. Deterministic automation, a workflow, a read copilot. The TCO of an autonomous agent here usually exceeds the value it creates.

The matrix does not replace numbers. If you cannot say the cost per successful action, you are choosing by ideology. Go back to the TCO business case before you fight over the vendor.

Checklist: build, buy, or split?

Before you commit a quarter, the team should be able to answer.

Is the agent what the customer buys from you, or is it a feature inside the product you already sell?

Is there an owner with a name six months from now, not only whoever made the demo?

Which part is differentiating (case, tools, data) and which part is scaffolding (traces, cost limits, runtime)?

Does the opportunity cost fit: what stops coming out of the roadmap while you build it?

What is the exit? Models, skills, traces, a self-host option. In weeks, not in "we'll see".

Are you comparing an internal prototype with a product, or two systems that can be operated?

If two or more are missing, you do not need a cheaper vendor or a faster intern. You need to split the problem. The hybrid approach is not indecision. It is not rebuilding the plumbing to prove that you can.

When Devic is not a fit

There are cases where you should not buy from us, and it is worth saying them.

If the agent is the product and you already have a platform team that will operate it as its own P&L, building is coherent. You do not need an external layer.

If you only need a weekend prototype for an internal demo, you do not need a platform. You need a narrow scope and the honesty not to sell it as production.

If the flow is stable, verifiable, and does not require a model, a deterministic function wins. An agent there is theater.

If you require a runtime we do not expose or a data model we cannot export to your shape, do not force the fit. Bad lock-in starts when a technical "no" is ignored.

Where we usually do fit is the saturated quadrant: the case and the tools are yours, and you do not want to rebuild observability, permissions, and a cost limit for every agent. That is the product harness, with tool calls as the unit. If exit and infra control matter more than time to market, the path is open source.

Once you have the checklist answers, the rest is an architecture decision, not a pride decision. And if you want to check them against your API, your margin, and your real team, they get looked at with those numbers on the table, not with a "we'll do it ourselves" slide.