Mike HeapMike is an experienced Product Manager who focuses on all the “non-development” areas of My AskAI, from finance and customer success to product design, copywriting, testing and more.
Created time
Jun 29, 2026 04:14 PM
Title length (<60)
Author
Last optimised
Ecomm?
Tags
Image
Publish date
Jun 30, 2026
Video
Slug
dont-build-your-own-ai-support-agent
Featured
Type
Article
Ready to Publish
Ready to Publish
If support matters to your business, building your own AI support agent doesn't add up. The pitch sounds simple: pick a good model, point it at your help center, wire it into your helpdesk, and you're done. That picture is the problem. A real support agent is three separate engineering projects, and a build typically gets you 20-50% of the functionality, which you then own and maintain forever.
We've spent three years and millions of tickets on the first of those three layers alone, and we're still chasing edge cases. So here's the buy-vs-build math, and the one case where I think a build actually pays off.
Why building looks like the obvious move
TL;DR: A working prototype really does come together in a weekend, which is exactly why teams underestimate the job. A demo and a production support agent are different beasts, and MIT found 95% of company AI pilots stall before they pay off.
I want to give the build case its due, because on paper it's a good one. The models are commodities now, so the part that used to be hard looks solved. A decent engineer can stand up a retrieval chatbot over your help center in a weekend, and it'll answer the easy questions in the demo (I've built exactly this kind of thing myself).
You own the data, the prompts and the roadmap. There's no per-resolution meter ticking, no lock-in, and an agency will quote it as a fixed project with an end date (on a slide, that's a compelling story). All of that is real, and the prototype genuinely is cheap and quick.
That's exactly why so many teams start down this road. It's also where I'd pump the brakes (gently).
A prototype and a production support agent are different beasts (I learned that the expensive way). MIT's 2025 State of AI in Business study found that 95% of company AI pilots stall before they deliver any measurable return, and the gap between a thing that demos well and a thing that runs your support queue is where they die.
Why one AI support agent is really three projects
TL;DR: A production agent is three engineering projects in one: the answering AI, the content and retrieval loop, and the helpdesk integration. Each is a forever job, and a build typically leaves you owning 20-50% of the functionality with the rest still to do.
Here's the part the weekend demo hides: a production AI support agent is three engineering projects. Each one is a forever job that never quite ends.
The first is the AI that actually answers, and I promise it's the deceptively hard one. The model is the easy part; the real work is the orchestration around it. How you handle the question the docs half-answer, the customer who asks three things at once, the weird input that shows up one time in a thousand.
We've iterated over millions of tickets across three years to get our answering pipeline right, and we're still fighting for small gains on quality and that long tail. The demo answers the easy question. The other 80% of the work is everything the demo doesn't show you.
The second is the content and context loop, the layer I most underestimated the first time round. That means pulling knowledge out of Google Drive, Notion, your website and your help center, working out how to fetch the right piece at the right moment, running the loop that flags where the agent is failing, and building the tasks and actions so someone non-technical can manage them without a developer. It's an ongoing product in its own right; you don't set it up once and walk away.
The third is the helpdesk integration. Intercom, Zendesk, HubSpot, Freshdesk and Gorgias all change their APIs, add and remove features, and have downtime, so you need fallbacks (and a few of them are no fun to build on).
A lot of these problems surface only now and then. The difference is that when we hit one, we fix it once, for every customer at the same time. A solo build hits the same edge case alone, with nobody having hit it first: a ticking time bomb that goes off the day your one engineer who understood the integration is on holiday.
Add it up and a build gets you maybe 20-50% of the functionality, which you then own and maintain forever. We know the number because we've paid it (fun fact: building AI agents on top of OpenAI cost us over $50,000 and more than 1,000 hours), and that was before any of the forever-maintenance on layers two and three.
The independent data points the same way. That same MIT study found that buying from a specialist vendor succeeds about 67% of the time, while internal builds succeed only about a third as often. If you value your engineers' time at any sensible rate, the math doesn't close.
Where building your own actually makes sense
TL;DR: Build a simple FAQ bot over a clean help center yourself. The only other real case for building is a financial-services team that already builds agents in-house and runs a bespoke, siloed setup.
I'm not going to pretend a build never makes sense (a take with no boundary is just a sales pitch). If what you genuinely need is a simple FAQ bot, a thin retrieval layer over a clean help center with no write-back into the helpdesk, no actions and no improvement loop, then build it. The math only really turns against you, I'd say, when support is core and the agent has to resolve things rather than just answer them.
There's a second, narrower exception worth flagging plainly. For a some companies that already have in-house experience building agents, a build might not be the worst idea, because a lot of these businesses have bespoke setups and data silos that an off-the-shelf product has to bend around anyway.
The two conditions matter together, though: the existing build experience and the genuinely bespoke environment. On its own, a complicated, siloed setup makes a build harder; it's rarely a good reason to start one (we see this play out constantly).
Build your own if…
- You only need a simple FAQ bot over a clean, well-maintained help center
- You're a team that already builds agents in-house, with a genuinely bespoke, siloed setup
- The support agent itself is a strategic differentiator you want to own outright
- You're treating it as a learning project and the stakes are low
Buy a platform instead if…
- Support is core and the agent has to resolve tickets and take real actions for customers
- You'd rather your engineers shipped the product your customers pay you for
- You want a predictable, forecastable cost from day one
- You don't have a team that wants to own three engineering projects forever
How to actually run the buy-vs-build math
TL;DR: Price all three layers across their full lifetime, apply the 20-50% test, and ask whether a support agent is really your differentiator. Buying runs a few hundred to a few thousand dollars a month (around $0.10 a ticket for us) against a $50,000-plus build.
Here's the same decision laid out side by side.
What you're comparing | Build your own | Buy a platform |
Upfront cost | $50,000+ and 1,000+ hours (our own build) | A few hundred to a few thousand a month |
Time to live | Months, if it ships at all | Days |
The three layers | All three are yours to build | Already built and maintained |
When an API changes | Your engineers fix each one | Fixed once, for every customer |
Functionality you get | 20-50% of a full platform | The whole product |
Odds it succeeds (MIT) | About a third as often as buying | About 67% of the time |
If you're weighing this up, price the build properly and the rest follows.
Cost all three layers across their whole lifetime. The weekend demo is layer one's easy slice; the real bill is layer two plus layer three plus the maintenance tail (the changing APIs, the improvement loop, the 2am page when an integration breaks). Then apply the 20-50% test: list everything the demo doesn't do yet, like actions, write-back into the helpdesk, escalation logic and the loop that catches failing answers, and ask who owns closing that gap forever.
Then ask the opportunity-cost question, because MIT found misaligned internal investment is one of the biggest reasons builds fail. Is an AI support agent actually your differentiator, or is it table stakes you'd rather buy so your engineers can ship the product customers pay you for?
And I'd put one more question to any build plan: what happens the day Zendesk or Intercom changes its API? When you buy, that's someone else's job, fixed once for everyone. When you build, it's your weekend.
For comparison, buying is the boring-but-effective option: somewhere between a few hundred and a few thousand dollars a month (for us, around $0.10 a ticket), and you can run a full 30-day trial with every feature unlocked and unlimited tickets before you commit a penny. Stack that against $50,000, 1,000 hours, and a maintenance bill that never stops, and the decision usually makes itself.
How do I run the buy-vs-build math for my own team?
Paste this into your AI tool of choice, fill in the brackets, and it'll work the decision through with you (it can't judge answer quality on your real data, so treat the output as a rough first pass and get a real quote before you commit).
You are helping me decide whether to build or buy an AI customer support agent.
My situation:
- Helpdesk: [your helpdesk, e.g. Zendesk, Intercom, Gorgias]
- Monthly ticket volume: [number]
- In-house engineering time I could give this: [hours per week]
- Is a support agent a strategic differentiator for us, or table stakes? [answer + why]
Work the decision through with me:
1. Cost the BUILD across all three layers, including ongoing maintenance, not just a prototype:
- Layer 1: the answering AI (orchestration, edge cases, ongoing answer-quality work)
- Layer 2: the content + retrieval loop (knowledge ingestion, the failing-answer loop, no-code tasks)
- Layer 3: the helpdesk integration (API changes, downtime, fallbacks)
2. Apply the 20-50% test: list what a weekend prototype would NOT do yet (actions, write-back,
escalation logic, the improvement loop), and who owns closing that gap forever.
3. Cost the BUY option at roughly $0.10 to $0.50 per ticket for my volume.
4. Tell me which way the math points, and flag anything you can't estimate as
"unverified, get a real quote" instead of guessing.FAQs
Should you build your own AI customer service agent?
If support matters to your business and the agent has to resolve tickets rather than just answer FAQs, no. Building it yourself means taking on three separate engineering projects (the answering AI, the content and retrieval loop, and the helpdesk integration) and maintaining them forever. A simple FAQ bot over a clean help center is the exception: that's genuinely buildable, so build it.
How much does it cost to build an AI support agent from scratch?
More than the prototype suggests. Our own build on top of OpenAI ran past $50,000 and 1,000 hours, and that was before the ongoing cost of maintaining the content loop and the helpdesk integrations. MIT's 2025 research found most internal AI builds never reach production at all, so the real number has to include every build that stalls before launch, which is most of them.
Can you build an AI customer service agent for free?
You can build a free-ish prototype: commodity models and an open-source retrieval setup will answer easy questions over a weekend. The cost lives in the other two layers and in keeping the whole thing running (the improvement loop, the helpdesk integrations that shift underneath you, and per-token model bills that are hard to forecast because they scale with how chatty your customers are). Free at the demo, expensive forever after.
Is it better to build or buy an AI customer service agent?
For most teams, buy. Building only pays off when the agent is a genuine strategic differentiator, or in the narrow case of a financial-services company that already builds agents in-house and has a bespoke, siloed setup. MIT's data backs the default: buying from a specialist vendor succeeds roughly 67% of the time, internal builds about a third as often.
