Building an AI agent is the cheap part: the cost arrives in month fourteen

Can a competent product team build its own AI agent? Yes, and in less time than it usually estimates. With a model over an API, a channel connected and the instructions well written, there's something running in two or three weeks. That part isn't hard, and it stopped being hard a while ago.

The question almost nobody asks in that meeting is a different one: who's going to be operating it in month fourteen.

Which part of the work happens once, and which part never ends?

The prototype happens once: pick the model, connect the channel, write the instructions, integrate the first system. It's real work and it's bounded.

What never ends is the other part, which is five fronts at once. The new cases that show up in production and that nobody anticipated. The evaluations that have to run to know whether a change improved something or broke it. The channel's changes, which on WhatsApp include prices and policies Meta updates on its own schedule. The model provider's changes, deprecating versions on a calendar of its own. And the business knowledge, which goes stale by itself: every new price, every internal policy that changes, every product that leaves the catalogue.

None of the five shows up in the initial estimate, because all five are consequences of being in production, not of building.

Why month fourteen and not month two?

Because the first year is covered by enthusiasm. In the early months the agent is a project with an owner: the person who built it looks at it every day, fixes by hand whatever looks off, and knows by heart why each instruction says what it says.

Around the one year mark, three things happen together. That person rotates to another project, because a product team has a roadmap to serve. The model version it was built on enters a deprecation schedule. And the instructions have accumulated twelve months of patches nobody documented. The result isn't an outage: it's a slow degradation nobody measures, because nothing was ever defined to measure it with.

What does it take for quality not to depend on somebody watching?

A set of evaluations that runs the way regression tests run in any serious system. Real cases frozen with their expected answer, executed on every change of instructions and every change of model. Without that, changing a prompt is deploying blind.

That's the difference between a one-off number and a sustained one. At Takenos, the support agent resolves 7 out of every 10 conversations with no human involved, at roughly a minute per ticket. Any team can hit 70% in a good week. What's hard is that 70% still being there in month fourteen, with a different model underneath, with the catalogue changed and without the person who built it.

When is building it in house the right call anyway?

There are three clear cases, and saying them makes the rest more credible.

When the agent is the product the company sells. If the competitive advantage lies in the conversation itself, outsourcing it is outsourcing the product.

When a genuinely dedicated team exists, not a borrowed one. Dedicated means somebody whose job, in their job description, is operating this, and who doesn't get pulled off it when the roadmap gets tight.

When the process is so specific that the value sits in a detail nobody from outside will understand before twelve months in the industry.

If none of the three applies, what's being evaluated isn't build versus buy. It's build versus build and then maintain.

What's the question that settles the decision?

Not "can we build it?", because the answer is almost always yes. The question is who's going to be on call the day the provider deprecates the model version they're running, and which set of cases they'll verify the migration against.

If that answer has a name and a budget, building is a reasonable decision. If it doesn't, the agent is already built and the problem is only starting.