Build your own AI agents when you employ engineers who will still own them in two years and the workflow is part of what you sell. Buy a managed service when the workflow matters but is not your product, and nobody on your team wants to be on call for it. Cost is rarely what decides it.
Most teams compare the cost of building with the cost of a subscription. Building often wins that comparison on paper, but the build is the smallest cost in the decision, so the comparison points you the wrong way.
A competent engineer can build an agent that watches an inbox, pulls a record, drafts a reply and routes the exceptions in a short project. Keeping that agent correct for the next two years is a separate commitment, and that commitment is the one that should decide whether you build.
Build and buy are also the two ends of a wider range. The four ways to get an AI agent for business adds a chat tool with your apps connected and a hosted builder platform to the comparison, and says who maintains each one.
Why the build estimate is the wrong number
A working prototype shows that the idea is sound. It does not show what you have committed to. Four things change underneath a live agent after launch, and a build estimate covers none of them.
Four things that keep moving after launch
1. Model providers set the retirement schedule
Every major model provider publishes a retirement schedule, and the notice periods are shorter than most operating plans. OpenAI commits to at least six months' notice before retiring a generally available model and at least three months for specialized variants. Preview models can get as little as two weeks, and OpenAI's guidance on them is direct:
We don't recommend using preview models for business-critical production workloads unless you can migrate on short notice.
That line is from OpenAI's deprecations page. Anthropic's model deprecation page shows what this looks like in practice: its status table lists six retired Claude API models, all of them retired between February and August 2026. Anthropic announced the retirement of Claude Sonnet 4 and Claude Opus 4 on April 14, 2026 and shut them off on June 15, 2026, roughly two months later. Google's Gemini deprecation page lists gemini-2.0-flash, released February 5, 2025, with a shutdown date of June 1, 2026.
This is not a criticism. Publishing dates in advance is the responsible thing to do, and all three providers do it. It does mean a live agent has a recurring migration on its calendar, whether or not anyone scheduled one.
Swapping models is rarely a one-line change. Prompts tuned to one model behave differently on the next, and tool calls can change along with them. The real cost of a migration is re-testing every workflow the agent touches.
2. Integrations change too
An agent is useful because of the systems it connects to, and those systems publish their own retirement schedules. Slack deprecated its widely used files.upload API method and later moved the deadline to November 12, 2025. The CRM, help desk, accounting system and calendar in your stack each go through some version of that cycle.
Integration failures are quieter than model retirements. When an endpoint changes the shape of its response, the agent keeps running and produces slightly wrong output that nobody notices for a week. Wrong output is harder to detect than no output, and teams almost never assign anyone to catch it.
3. Permissions change when people do
An agent has access to real systems, and the people and vendors around those systems change. Someone joins or leaves, a vendor changes its admin model, or your security team asks a reasonable question. If nobody owns the agent's access, it drifts toward whatever was easiest to configure at setup, which is almost always broader than the job needs. We cover what access an AI agent should have in a separate article. The point here is narrower: you will have to make that decision again as people and systems change.
4. Business rules change
The workflow the agent was built for changes over time. You add a service line, change a routing rule, restructure a team or change who approves what, and the agent keeps applying last quarter's rules until someone edits it. This is the most common reason a working agent stops being useful. The cause has nothing to do with AI; internal tools decay for the same reason.
Who owns the worst week?
Set the spreadsheet aside and the build-versus-buy decision comes down to one question. Picture a Tuesday when the model your agent depends on is retired, an integration starts returning an unexpected payload, and the person who wrote the prompts is on leave. Whose problem is that?
If you build, it is your problem for as long as the agent runs. If you buy, it is the provider's, provided the agreement says so. The rest of the decision follows from that answer.
When building your own AI agents is the right call
We sell the alternative, but under these conditions we would still tell you to build:
- You already employ engineers who are likely to still be with you in two years, and they have capacity the roadmap has not already claimed.
- The workflow is part of what you sell. If the agent is the product, or a part of it that sets you apart, keep it in house.
- You have a data constraint that holds up under a real review. A contractual or regulatory limit counts. A reflexive objection does not.
- The workflow is still experimental and changes weekly, so you need to iterate faster than any vendor's cycle allows.
- You will fund it as a permanent line item rather than a project with an end date.
If four of the five are true, build it. Because you control the whole loop, you will get a better result than an outside provider can give you. The next decision is which runtime you build on, and what actually decides Hermes Agent against OpenClaw covers the two most likely answers.
When a managed AI agent service is the right call
- The workflow matters but is not your product: lead follow-up, project status collection, inbox triage, research briefs or reconciliation prep. If you have not picked one yet, start with which workflow to automate first.
- Your engineers are fully committed. Every hour they spend on internal tooling comes out of the product, and you can name what that costs.
- You want a named owner for uptime, updates and issue investigation instead of an internal volunteer who took it on once.
- You need it working within weeks rather than after a hiring cycle. Scope still sets the schedule, but you are not waiting on recruiting.
- Consequential actions need approval gates that are built into the system instead of gates someone has to remember. Decisions about communications, money, access and personnel should stop at a person by design.
The half-build that usually fails
Plenty of companies end up in a third outcome that nobody plans for. An internal champion builds a working agent on a platform in their spare time, and the business gradually comes to depend on it. Then that person changes roles. Nobody documented the prompts, nobody owns the API keys, and a live workflow now depends on something that sits in no team's scope.
This is the most expensive of the three outcomes, because you paid to build and still carry all of the operating risk. It follows the same pattern as implementations that stall on the way to rollout, one workflow at a time.
A hybrid does work. You own the workflow definition, the success criteria and the approval gates, and a managed provider owns the environment, the integrations, the model migrations and the monitoring. The split holds up because each side owns the part it can control.
The operating ownership scorecard
Score each row from 1 to 5, multiply by the weight and add up the results. A higher total points toward buying. We use this as a planning heuristic to structure the conversation. It is not a validated benchmark, and it is most useful for showing where your team disagrees with itself.
| Question | Weight | Score 1 | Score 5 |
|---|---|---|---|
| Is this workflow part of what you sell? | 3 | It is the product, or differentiates it | It is internal overhead |
| Who is on call for it in 18 months? | 3 | A named engineer with capacity | Nobody has been named |
| Is engineering capacity uncommitted? | 2 | Real spare capacity exists | Fully committed to the roadmap |
| What does a quiet week of wrong output cost? | 2 | Low consequence, easy to catch | Expensive and hard to detect |
| How many external systems must it touch? | 2 | One system you already control | Three or more third-party services |
| How fast do the business rules change? | 1 | Weekly, still experimental | Quarterly, largely settled |
| Is there a data constraint that survives review? | 1 | A real contractual or regulatory limit | None that holds up |
| How soon do you need a working version? | 1 | Two quarters is acceptable | Weeks |
The weighted total runs from 15 to 75.
- 15 to 30: build it in house and staff it as a permanent responsibility.
- 31 to 52: use the hybrid. Own the workflow definition and the approval gates, and buy the operating layer.
- 53 to 75: buy a managed service and spend your engineering time on the product.
If two people score the same row three points apart, that disagreement tells you more than the total. It usually means nobody has agreed who owns the workflow.
Six questions to ask a managed provider before you sign
Ask us these too. If a provider cannot answer them plainly, you are buying a build with a subscription attached. Once you have settled on buying and are down to two or three names, nine questions and a scorecard for choosing an AI agent development company extends this list and gives you a way to score the answers side by side.
- Who performs the migration when the underlying model is retired, and is it included or a change order?
- What happens when one of our integrations changes its API, and who notices first?
- What do you monitor, and how would we learn that an agent produced wrong output rather than no output?
- Which actions require human approval, and is that enforced by the system or by the prompt?
- What access does each agent hold today, and what is the process for changing it?
- If we leave, what do we keep?
You should get a straight answer to the last one, so here is ours. VantaSoft does not hand over source code. If you leave, you keep your data and your systems, but not the managed environment we set up and maintain for your agents. If owning the code matters more to you than owning the outcome, that is a good reason to build, and we would rather you hear it now than after an Order Form.
What buying from VantaSoft looks like
For a concrete comparison, this is how buying works at VantaSoft. In discovery we learn your processes and the tools the agent will work in. We build the agent for that work, connect it to your systems and launch it in the messaging platform your team already uses, whether that's Slack, Microsoft Teams or something else. Three coaching sessions get your team started, and after that we keep the agent hosted and up to date.
The build starts at $1,000 one time. Its price depends on the agents, workflows and integrations involved, and we quote it after discovery, before anything is billed. Hosting and maintenance starts at $200 per month and covers your own managed environment, monitoring and routine updates, email support during Pacific business hours and small changes as your work evolves. Billing starts once you approve your Order Form. For the full breakdown of what an agent costs, including what the same thing costs to build in house, see our separate article.
Frequently asked questions
Is it cheaper to build our own AI agents?
It is usually cheaper to start. The build is the smallest cost involved, though. The total depends on who pays for model migrations, integration changes, access reviews and rule updates for as long as the agent runs, so compare the two-year operating cost rather than the cost of the first version.
How long does it take to build an AI agent in house?
A working prototype often takes only days. Getting it ready for production takes longer, because it needs scoped access, approval gates, error handling, evaluation and a person who owns it. A timeline that leaves those out is measuring the prototype rather than the system.
Can we start with a managed service and bring it in house later?
Yes, and that is a reasonable plan if you expect to hire. Agree up front on what transfers, because a managed service and a code handoff are different products. At VantaSoft, the workflow definitions, the approval rules and your data are yours. We do not hand over the managed environment.
We already built an agent that works. Should we keep it?
Ask who is on call for it and what happens when the model it uses is retired. If both answers name a person, and that person has capacity, keep it. If the answer is the person who built it, working on it in their spare time, you have the half-build described above.
Do we need engineers to buy a managed AI agent service?
No, but you do need a workflow owner: someone who can say what good output looks like, which exceptions must reach a person and when the rules change. The role is not technical, and you cannot outsource it.
How is this different from the usual build versus buy decision?
For software in general, the build versus buy question turns on whether your process is unusual. Agents add a second factor. The platform underneath them changes on someone else's schedule, so the minimum maintenance load is higher than it is for ordinary internal software.
Decide who owns the second year
Teams that regret this decision almost always made it on the build cost. That number is easy to estimate and reassuring, but the commitment is what comes after it. Name the person who will own the agent eighteen months from now, and the answer usually becomes clear.
If you want help scoring a specific workflow, start automating with VantaSoft. It begins with 30 minutes on your workflows, and you will come away with a clearer view of the operating burden whichever way you decide.
