Build or buy AI agents: the full math, after launch

The prototype is the cheap part

Building an agent that works in a demo has become easy. There are open frameworks, ready-made examples and models available through APIs. A curious developer can, in a few days, have an agent that reads an email, checks a spreadsheet and replies with something sensible.

The problem is that the demo happens under ideal conditions. The data is clean, nobody sends a corrupted attachment, the ERP isn’t down and the customer doesn’t write in three fragmented messages. In production, all of that happens every week.

That’s why comparing the cost of building with the cost of buying by looking only at initial development leads to a skewed decision. Development is usually the smallest slice of an agent’s total cost over a year.

The costs that don’t make the spreadsheet

When a company decides to build in-house, four costs tend to show up later and were rarely in the budget:

• Upkeep. Integrations change. The ERP’s API gets a new version, the WhatsApp provider changes a rule, the AI model gets retired. Someone has to keep track and adjust, with no end date.
• Monitoring. An agent can fail without throwing an error. It replies, it just replies wrong. Noticing that takes logs, alerts and someone looking at them regularly.
• Audit. If the agent approved a discount, cancelled an order or replied to a patient, you need to know why. That calls for a searchable decision history, with care for privacy laws like GDPR whenever personal data is involved.
• Concentrated knowledge. Often the agent lives in the heads of one or two people. If they leave or change roles, the agent becomes a black box nobody dares touch.

None of these costs is a reason not to build. They’re reasons to put everything into the math before deciding.

Who answers when it breaks

This is the question that most separates the two paths. Picture a customer service operation where the agent stops replying on a Friday night because a certificate expired. Who gets the alert? Who has access to fix it? Who tells the team they’ll need to handle things manually until Monday?

In the in-house model, the answer has to exist before launch: an on-call rotation, documentation on how to restart each part, defined access permissions. If the answer is “the person who built it”, you have an operational risk with a first and last name.

In the outsourced model, the answer has to be in the contract. Response time, hours covered, what counts as an incident, how communication happens. Hiring someone to build without defining who supports it just moves the problem somewhere else.

The right question is less “who builds it?” and more “who wakes up when the agent stops?”.

When building in-house makes sense

There are scenarios where building with your own team is the best choice. Some signs:

• You already have an engineering team with real slack, one that won’t abandon the agent at the quarter’s next new priority.
• The agent is a core part of your product, not just your internal operations. In that case, the knowledge needs to stay in-house.
• You have people with experience putting systems into production, with monitoring, testing and version control, not just writing code.
• The company is willing to invest a few weeks in groundwork before seeing the first agent working.

If all four signs are there, building usually pays off. If two or more are missing, take a careful look at the other side.

When buying makes more sense

Hiring someone to build and maintain tends to be the best path when the agent serves operations: customer service, finance, sales, legal, logistics, or any department with tasks that repeat. In those cases, what matters is a working agent and someone accountable for it, not owning the code.

It also makes sense when the company wants to try several agents in different departments before deciding where to invest more. A partner who has already done similar integrations shortens the path and avoids mistakes that are expensive the first time around.

To avoid swapping technical dependence for vendor dependence, a few questions help during evaluation:

• Do the code, prompts and configuration belong to the company or the vendor? And if the contract ends?
• Are the agent’s decision logs accessible to your team, or only on request?
• How does switching AI models work if the current one gets expensive or is retired?
• Who approves changes to the agent’s behavior before they reach production?
• What’s the response time for incidents, and what’s covered outside business hours?

A practical way to compare

To compare the two paths honestly, build a simple table over a 12 to 24 month horizon. Put a cost item on each row and a path in each column.

• Initial development hours, at the real hourly cost of whoever does the work.
• Monthly upkeep hours: adjustments, integration updates, fixes.
• Infrastructure and monitoring tools, including log storage.
• AI model usage costs, which are similar on both paths.
• Opportunity cost: what your team doesn’t do while it maintains the agent.
• Cost of downtime: what it costs the operation to go a day without the agent.

That last row tends to change the conversation. An agent that serves customers or processes orders has a high cost of downtime. That tips the scale toward whoever has the structure to respond fast, whether that’s your team or a partner with a formal commitment.

Compare the cost of running the agent for two years, not the cost of getting it live.

The hybrid path

The choice doesn’t have to be binary. Many companies start by outsourcing the build and the upkeep, learn from their first agent in production and gradually bring part of the work in-house. Others keep their internal team focused on the product and leave the operational agents to a partner.

What makes the hybrid path work is transparency from the start: accessible code, up-to-date documentation, logs your team can read. With that, the decision to bring it in-house stays open for later, when you have real data instead of estimates.