Building an AI agent has never been easier, which is exactly why the build-versus-buy decision has gotten harder. A competent engineer can assemble a working prototype that reads email, calls a model, and drafts a reply in a couple of weeks. The demo is genuinely impressive. The estimate that follows is genuinely wrong.

It is not wrong about version one. Version one usually lands close to plan. It is wrong because version one is a small fraction of the three-year cost, and the remainder is made of items that do not appear in the initial scope because they are not visible until you are running in production.

This is not an argument that building is always wrong. It is an argument for costing it honestly.

What the build estimate usually contains

Prototype, integration to the mail system, integration to the TMS, a rules layer, a review interface, testing, deployment. Real work, reasonably estimated, and typically the majority of what gets presented.

What it usually omits

• Evaluation infrastructure — Why it gets missed: Feels like testing, is actually a system · When it bites: First model change
• Continuous accuracy sampling — Why it gets missed: Nobody owns it at design time · When it bites: Month 3
• Prompt and rule maintenance — Why it gets missed: Assumed to be one-time · When it bites: Continuously
• Model upgrade migration — Why it gets missed: Assumed to be free · When it bites: Every major release
• Integration drift — Why it gets missed: Upstream systems change · When it bites: Ongoing
• On-call and incident response — Why it gets missed: No runbook exists · When it bites: First production incident
• Escalation and audit tooling — Why it gets missed: Considered a nice-to-have · When it bites: First customer dispute
• Security review readiness — Why it gets missed: Not a build task · When it bites: First enterprise customer asks
• Knowledge concentration risk — Why it gets missed: Not a line item at all · When it bites: When that engineer leaves

The last row is the one that damages organizations most and appears in no spreadsheet. In a logistics company, the person who built the agent is usually one of very few people who understand it. Their departure converts a working system into an unmaintainable one, and the replacement cost is not a hire — it is a rebuild.

The evaluation problem is the real cost

If there is one item that separates a prototype from a production system, it is evaluation infrastructure.

A deterministic system is tested against expected outputs. An agent has to be evaluated against a golden set — a curated corpus of real inputs with known-good outputs, run automatically on every change, with results tracked over time. Building that is a project. Maintaining it is permanent work. And without it, you cannot safely change a prompt, a rule or a model version, because you have no way to know whether the change improved things or quietly broke a category.

Teams that skip it discover the consequence at the first model upgrade: no way to tell whether behaviour changed, so either you do not upgrade — and fall behind on capability and cost — or you upgrade and find out from customers.

This is the same discipline that makes pre-production QA meaningful, and it does not become less necessary after launch.

When does building an AI agent make sense?

Building makes sense when the workflow is genuinely proprietary — a real competitive differentiator no vendor addresses — and you have permanent engineering capacity to maintain evaluation infrastructure, handle integration drift, and manage model migrations. For standard logistics communication workflows, those conditions rarely hold.

The honest test is not "can we build this?" Most teams can. It is:

1. Is this workflow a differentiator, or is it table stakes? Quote responses and status updates are table stakes. Something specific to your network design might not be.
2. Do we have permanent capacity, not project capacity? Maintenance is forever, and it competes with everything else on the roadmap.
3. Can we absorb a model migration every year or so without it consuming a quarter?
4. What happens when the person who built it leaves?

Answering the last one truthfully resolves a lot of these decisions.

The hybrid that usually wins

The framing as a binary is often the mistake. The pattern that works in practice: buy the agent platform, build the parts that are actually yours.

Your rules, your escalation boundaries, your account-specific exceptions, your integration into your systems of record — those are configuration and connection work, they encode genuine operational knowledge, and they belong to you. The evaluation harness, the model abstraction layer, the audit infrastructure, the security posture and the migration burden are undifferentiated heavy lifting.

That split also preserves the thing that matters most: the operational knowledge captured during onboarding is yours regardless of who built the runtime. That knowledge is the durable asset. The runtime is not.

Costing it properly

If you are going to build, cost it over three years with these included:

• Year 1: build, plus evaluation infrastructure, plus audit and escalation tooling.
• Years 2-3: maintenance at a realistic percentage, model migrations, integration drift, continuous sampling labour, on-call.
• Risk-adjusted: the cost of a rebuild if the key engineer leaves, weighted by the probability that they do.

Compare that against a subscription plus the configuration work you would do either way — because you do the rule definition, exception encoding and workflow scoping in both scenarios. That work is not avoided by buying; it is the part that makes either approach succeed.

For teams under ten people, this calculation is not close. For enterprises with real platform teams, it is a genuine decision that turns on whether the workflow is differentiating.

Frequently asked questions

Is it cheaper to build if we already have engineers? Existing engineers are not free capacity — they are currently building something else. The relevant cost is the opportunity cost of what they stop doing, plus permanent maintenance that never goes away.

What if we want control over our data? Data control is a contractual and architectural question that both approaches can address. It is worth asking vendors directly rather than treating it as an automatic argument for building.

How often do model migrations actually happen? Frequently enough to matter. Each one requires re-validating behaviour across your workflows, which is straightforward with an evaluation harness and a serious undertaking without one.

Can we start by buying and build later? Yes, and it is often the sensible sequence. Buying first surfaces what your workflows actually require, which makes any subsequent build decision informed rather than speculative.

The bottom line

Version one is the cheap part. Evaluation infrastructure, continuous sampling, integration drift, model migrations, on-call and key-person risk are where three-year cost actually lives, and none of them appears in the prototype estimate.

Buy the runtime, build the rules and exceptions that encode your operation, and cost any build over three years with maintenance and migration included — not over one quarter with the demo in front of you.

Debales deploys AI agents for freight quoting, order processing, ETA updates, and multi-channel customer communication — with evaluation, audit and escalation infrastructure included, so your team configures rules instead of maintaining a platform. Book a demo.