Build vs buy AI agents, and the fourth option nobody sells you

The four options side by side

The row that decides it is usually the last one.

Build it with your own team

Hire two or three engineers, or redeploy them, and own the thing. The cost people model is salary. The cost that bites is attention.

An agent answering questions over your data is one part model work and four parts the things nobody demos: retrieval that finds the right document, an eval suite that catches a regression, monitoring, a citation trail, and an abstain path for questions the data cannot answer. A strong general backend team builds the impressive version in three weeks, then stalls for six months on the part that makes it safe to show a customer.

Almost right is the expensive failure mode, and every option has to answer for it. In Stack Overflow's 2025 developer survey, 66 percent of the 25,332 developers who answered named "AI solutions that are almost right, but not quite" as their biggest frustration with AI tools, and 45 percent said debugging AI-generated code takes longer than expected. They were describing coding assistants, not agents in a business process, but the shape carries: what an AI system costs you is the nearly-right answers nobody catches, which is the subject of stopping AI from making things up.

Build in-house when AI is part of what you sell and people on staff have already shipped and operated a retrieval or agent system. Not when this is your first and you are hiring for it. Your own production workflow is the most expensive classroom there is.

Buy an off-the-shelf platform

This option gets written off too quickly, usually by people who benefit from writing it off. Most of what a mid-size firm wants from an AI agent is not unusual: support triage, meeting notes, search over a tidy document set, a sales assistant on a CRM. A vendor with five hundred customers doing that has already hit edge cases you have not thought of, on someone else's budget.

The ten-minute test: name three things your version must do that the product page does not mention. Cannot reach three, buy the product. Reach three, and two usually turn out not to matter.

It breaks when the workflow that sent you looking is the one nobody else has. You bend the process to fit the tool, and the people doing the work feel it. The MIT report tracked the drop: 60 percent of organizations evaluated large-scale AI systems, 20 percent reached a pilot, 5 percent reached production. One interview describes a firm that spent 50,000 dollars on a contract analysis tool; the lawyer it was bought for went back to a general chatbot because "our purchased AI tool provided rigid summaries with limited customization options".

Price the lock-in before you sign. The same report interviewed seventeen procurement and sourcing leaders and put the window at about eighteen months before switching costs get hard to unwind. One CIO put it plainly: "Once we've invested time in training a system to understand our workflows, the switching costs become prohibitive." Ask in writing what you get on the way out: documents, but also prompts, feedback history, and the labelled examples your team spent a year on.

Hire an engineering firm

An outside team builds it alongside your people, in your stack, then keeps it running: the shape of an in-house team without the hiring cycle, plus someone who has already done the unglamorous parts elsewhere. That is the case for it. The case against matters more.

When an engineering firm is the wrong answer

Your workflow is standard. Do not pay build prices for what a product already does. A firm taking that brief sells a slower, dearer version of a tool you could have running on Thursday.

You already have the people. If your engineers have shipped and operated a retrieval system, an outside team buys you a longer feedback loop and a second set of opinions. Give them the quarter.

Nobody on your side can be freed up. Embedded work only works if one person who owns the workflow answers questions the same week they are asked. Otherwise the outside team guesses, at full rate.

The contract stops at handover. A build-only deal drops a system your team cannot debug into production and leaves. If nobody who wrote it is on the hook for the 2am page, you bought a demo with a longer lead time.

You need a guarantee. If the process must be right every time, no engineering firm can sell you that, and any that implies otherwise is lying. Grounding and citations make mistakes visible and traceable instead of silent. They do not make mistakes impossible.

The budget covers the build but not the year after. Left alone, an AI system decays: the document set drifts, a model version is retired, the eval suite rots, and March's accuracy is not November's. If you can only fund the build, fund something else, and read what an AI agent costs to build and run first.

Build nothing

The right answer more often than the other three, and the one nobody is paid to recommend. Six signals, any one enough to stop.

1. No ground truth. Nobody can point at the document, row or table where the correct answer lives. If a careful person with a week and full access could not produce it, an agent has nothing to retrieve and will fill the gap with something plausible.
2. No owner. No named person whose week gets better or worse depending on whether this ships. Projects without an owner do not fail loudly; they get deprioritised at week nine.
3. The workflow needs a guarantee. Payroll, a regulatory filing, anything where "usually right" is a legal problem rather than an inconvenience. An AI system can cite its source and abstain. It cannot be made certain.
4. A rule already solves it. If the logic can be written as if-then conditions, write it that way: cheaper, faster, testable, and it will not drift when a model version changes.
5. A report already solves it. A surprising share of "we need an AI assistant" requests are one person asking a question a saved query would answer every morning, for free.
6. Nobody can define good. If the team cannot write down five real questions and their correct answers before work starts, there is no eval, and no way to tell whether a change made things better or quietly worse.

Build nothing is rarely permanent. Usually it means not yet: fix the data, name the owner, or narrow the workflow until a right answer exists somewhere a machine can reach.

The decision rule

Run it in order. Stop at the first line that answers.

1. Write down five real questions, their correct answers, and the document each comes from. Cannot do it? Option four. Go fix the data.
2. Could a written rule or a saved report answer all five? Option four.
3. Search for a product that already does it. If you cannot name three things your version must do that it does not, option two.
4. Do your engineers have shipped-and-operated retrieval or agent experience, and can you keep them on it after launch? Option one.
5. Otherwise option three, and the job changes from picking a shape to picking a team: the twelve questions to ask an AI development company separate a real engineering team from a reseller.

Where we sit, said plainly

Ilayer sells option three. We embed with your team, build inside your stack, and stay on the hook for what runs. A scoped first piece takes four to six weeks at a price agreed before we start, and the code lives in your repositories under your license so your team can run it without us.

We turn work away on the criteria above. If your workflow is standard, a product will serve you better. If nobody can name the document a right answer comes from, we will say so before you spend anything. For a second opinion on which of the four fits, tell us the workflow that hurts.