--- title: "Your AI agent competes with the product roadmap" description: "Building the agent in house doesn't compete with the budget: it competes with what the product team was going to build. How to do that math first." url: https://studiochat.io/blog/el-agente-propio-compite-con-el-roadmap locale: en translations: { es: https://studiochat.io/es/blog/el-agente-propio-compite-con-el-roadmap.md, pt: https://studiochat.io/pt/blog/el-agente-propio-compite-con-el-roadmap.md } site: https://studiochat.io --- [ Back to blog](/blog) The quarterly plan gets an item called "support agent" and the discussion goes straight to whether the team can build it. It can. That was never the hard question. The hard question is what it competes with. A product team doesn't have a technical capacity problem: it has a capacity problem, full stop. Whatever enters the quarter displaces something else, and that something else almost never gets named in the meeting where the decision is made. ## [What does the agent displace when it enters the roadmap?](#what-does-the-agent-displace-when-it-enters-the-roadmap) It doesn't displace a sprint, which would be easy to accept. It displaces a permanent fraction of the team. The project has an end date and the queue it leaves behind doesn't: new cases that show up in production, adjustments when the catalogue changes, reviews when the model provider ships a new version, corrections when the business changes a policy. That queue doesn't appear in the plan because it was born after it. A team that reserved three sprints to build it ends up reserving part of every sprint, forever, without having decided to. ## [Why doesn't that math get made explicit?](#why-doesnt-that-math-get-made-explicit) Because the agent enters the organization as a project and stays as a system. Those are two things with different budgets. A project gets approved once, has a scope and ends. A system in production has an on-call rotation, has an owner and has a fixed share of the team's capacity, forever. Most decisions to build an agent in house get approved with the logic of the first and paid for with the logic of the second. ## [What does it look like two quarters later?](#what-does-it-look-like-two-quarters-later) It looks like the agent losing priority to the product, which is exactly what should happen at a healthy company. The product is what gets sold. When something has to give, the product wins, and the agent moves to maintenance. The problem is that an agent in maintenance doesn't break: it degrades quietly. It keeps answering, with slightly older information each week, and nobody finds out until a customer complains about something the website says differently. No alarm goes off when knowledge gets old. ## [How do you do that math properly before deciding?](#how-do-you-do-that-math-properly-before-deciding) By changing the unit. Instead of estimating the project in weeks, estimate the operation as a percentage of one person per month, and put it in the plan as a fixed line that doesn't get touched. The concrete question for the committee is this: what percentage of the team's capacity are we willing to reserve for this, every month, for the next two years? If the answer is zero, the decision is already made and it's better said now than in fourteen months. ## [When is building it anyway the right answer?](#when-is-building-it-anyway-the-right-answer) When the agent is part of the product being sold. If the conversation is the main experience, or if the differentiator lies in how the agent behaves, that's your own roadmap and it shouldn't be in anybody else's hands. Also when the process it handles is so specific to the business that explaining it to somebody outside costs more than building it. That exists, and it's a legitimate reason. What isn't a reason is that the team is capable. Every product team I know is capable. The question is what they stop doing while they do it, and that math is rarely written down in the meeting where it gets approved. Does anybody have that line in their plan, with a fixed percentage and an owner? I'd be very interested to see how they wrote it. Frequently asked questions ### How much team capacity does keeping an agent in production consume? It varies a lot with how many processes it covers and how many systems it touches, but the way to estimate it isn't in project hours: it's as a fixed fraction of one person per month, sustained. If that line isn't in the plan, the work still happens, it just gets taken from something else. ### Isn't it enough to build it and review it now and then? It depends how often the business changes. If the catalogue, the prices and the policies change every month, the agent needs the same rhythm of updates, because its knowledge is a reflection of all that. ### Can you start by building in house and switch later? Yes, and it's more common than the other way round. What matters is having the instructions, the knowledge base and the test cases in an exportable format from the start, so that switch is a decision rather than a rebuild. Share [ X](https://x.com/intent/post?text=An%20in-house%20AI%20agent%20competes%20with%20the%20product%20roadmap%2C%20and%20usually%20loses&url=https%3A%2F%2Fstudiochat.io%2Fblog%2Fel-agente-propio-compite-con-el-roadmap) [ LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstudiochat.io%2Fblog%2Fel-agente-propio-compite-con-el-roadmap) [ WhatsApp](https://wa.me/?text=An%20in-house%20AI%20agent%20competes%20with%20the%20product%20roadmap%2C%20and%20usually%20loses%20https%3A%2F%2Fstudiochat.io%2Fblog%2Fel-agente-propio-compite-con-el-roadmap)Copy link Cristian Pereyra Cristian Pereyra · Co-founder · Engineering, StudioChat Want agents like these working for your team? [Talk to us now](https://cal.com/studiochat)