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 the deciding factor.
The comparison most teams run is build cost against subscription cost. That comparison is winnable on paper and wrong in practice, because the build is the smallest number in the problem.
An agent that watches an inbox, pulls a record, drafts a reply, and routes the exceptions is a short project for a competent engineer. That same agent still being correct two years from now is a different commitment, and it is the one that should decide whether you build.
Why the build estimate is the wrong number
A working prototype tells you the idea is sound. It does not tell you what you have signed up for. Four things move underneath a live agent, and none of them appear in a build estimate.
Four things that keep moving after launch
1. Models retire on the provider's schedule, not yours
Every major model provider publishes a retirement schedule, and the windows are shorter than most operating plans. OpenAI commits to at least six months' notice before retiring a generally available model, at least three months for specialized variants, and as little as two weeks for preview models. Its own guidance on that last category is blunt:
We don't recommend using preview models for business-critical production workloads unless you can migrate on short notice.
That line comes from OpenAI's deprecations page. Anthropic's model deprecation page tells the same story from the other side: its current status table lists six retired Claude API models, and every one of them was retired between February and August 2026. Claude Sonnet 4 and Claude Opus 4 were announced for retirement on April 14, 2026 and shut 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.
None of that is a criticism. Publishing dates in advance is the responsible behavior, and all three providers do it. It just means a live agent has a recurring migration on its calendar whether anyone scheduled one or not.
A model swap is also rarely a one-line change. Prompts tuned against one model's behavior drift on the next, tool-calling behavior shifts with it, and the honest cost of a migration is re-testing every workflow that agent touches.
2. The integrations move too
An agent is only useful because of the systems it touches, and those publish their own retirement schedules. Slack deprecated its widely used files.upload API method, then moved the deadline to November 12, 2025. Every CRM, help desk, accounting system, and calendar in your stack runs some version of that cycle.
Integration failure is quieter than model failure. An endpoint changes its response shape, the agent keeps running, and it produces slightly wrong output that nobody notices for a week. Detecting wrong output is harder than detecting no output, and it is the part teams almost never staff.
3. Permissions change when people do
An agent holds access to real systems. Someone joins, someone leaves, a vendor changes its admin model, security 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 wrote separately about what access an AI agent should have. The point here is narrower: that decision does not stay made.
4. The business rules drift
The workflow the agent was built for changes. You add a service line, change a routing rule, restructure a team, adjust who approves what. The agent keeps applying last quarter's rules until a person edits it. This is the most common reason a working agent quietly stops being useful, and it has nothing to do with AI. It is the same reason internal tools rot.
The real question: who owns the worst week?
Strip the spreadsheet away and the build-versus-buy decision is one question. On the Tuesday when a 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 it?
Build means it is yours, permanently. Buy means it is the provider's, if the agreement actually says so. Everything else in this decision is downstream of that answer.
When building your own AI agents is the right call
We sell the alternative, and these are still the conditions under which we would tell you to build.
- You already employ engineers who will plausibly still be here in two years, with capacity that is not already committed to the roadmap.
- The workflow is part of what you sell. If the agent is the product, or a differentiating piece of it, do not hand it to anyone else.
- You have a data constraint that survives a real review. A contractual or regulatory limit counts. A reflex does not.
- You need to iterate faster than any vendor cycle, because the workflow itself is genuinely experimental and changes weekly.
- You will fund it as a permanent line item, not as a project with an end date.
If four of those five are true, build it. You will get a better result than any outside provider can give you, because you control the whole loop.
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, reconciliation prep. If you are still choosing, start with which workflow to automate first.
- Your engineers are fully committed. Every hour spent on internal tooling comes out of the product, and you can name what it costs.
- You want a named owner for uptime, updates, and issue investigation, rather than an internal volunteer who took it on once.
- You need it working in weeks, not after a hiring cycle. Scope still drives the schedule, but you are not waiting on recruiting.
- Consequential actions need approval gates that are designed, not remembered. Communications, money, access, and personnel decisions should stop at a person by construction.
The half-build that usually fails
There is a third outcome nobody plans for and plenty of companies land in. An internal champion builds a working agent on a platform in their own time. It quietly becomes load bearing. Then they change roles. Nobody documented the prompts, nobody owns the API keys, and a live workflow now depends on something that appears in no team's scope.
This is the most expensive of the three outcomes, because you paid the build cost and kept all of the operating risk. It is the same failure pattern as pilots that stall on the way to rollout, arriving one workflow at a time.
There is a hybrid that does work. You own the workflow definition, the success criteria, and the approval gates. A managed provider owns the environment, the integrations, the model migrations, and the monitoring. That split holds because each side owns the part it can actually control.
The operating ownership scorecard
Score each row from 1 to 5, multiply by the weight, and add up the result. Higher totals point toward buying. This is a planning heuristic we use to structure the conversation, not a validated benchmark, and it is most useful for showing where a 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, buy the operating layer.
- 53 to 75: buy a managed service, and spend your engineering time on the product.
If two people in the room score the same row three points apart, that disagreement is more valuable than the total. It usually means nobody has actually agreed who owns the workflow.
Six questions to ask a managed provider before you sign
Ask us these too. A provider who cannot answer them plainly is selling you a build with a subscription attached.
- 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?
The last one deserves a straight answer from us. VantaSoft runs a managed operating service, not a source-code handoff. You keep your data and your systems. You do not walk away owning the environment we operate. If owning the code matters more to you than owning the outcome, that is a real reason to build, and we would rather you hear it now than after an Order Form.
How VantaSoft handles the operating side
For the sake of a concrete comparison, here is what the buy side looks like at VantaSoft. Discovery defines the roles, workflows, integrations, capacity, and human-oversight rules. We configure the agents and a managed environment specific to your company, run internal QA, then give you testing access and resolve what comes back. You approve regular use in writing, and after launch we monitor, apply routine updates, investigate issues, and hold 30, 60, and 90-day value check-ins.
Monitoring, routine software updates, issue investigation, email support during Pacific Time business hours, and minor in-scope configuration changes are included in the subscription. Larger workflows and new integrations are scoped as change orders. Plans start at $200 per month. Discovery comes first. A one-time setup fee based on the scope of your agents, workflows, and integrations applies. Setup and monthly billing begin after you approve your Order Form. Enterprise pricing is customer-specific. If you want the full breakdown of what an agent actually costs, including what the same thing costs to build in house, we wrote that up separately.
Frequently asked questions
Is it cheaper to build our own AI agents?
Cheaper to start, usually. The build is the smallest cost in the problem. What decides the total is who pays for model migrations, integration changes, access reviews, and rule updates for as long as the agent runs. Compare two-year operating cost, not first-version cost.
How long does it take to build an AI agent in house?
A working prototype is fast, often days. Production readiness is the long part: scoped access, approval gates, error handling, evaluation, and a person who owns it. Any timeline that ignores those is measuring the prototype, not the system.
Can we start with a managed service and bring it in house later?
Yes, and it is a reasonable plan when 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; the managed environment is not something we hand over.
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 have a name attached and that person has capacity, keep it. If the answer is the person who built 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 need a workflow owner: someone who can say what good output looks like, which exceptions must reach a person, and when the rules change. That role is not technical, and it cannot be outsourced.
How is this different from the usual build versus buy decision?
The general software version of the build versus buy question turns on whether your process is genuinely unusual. Agents add a second axis: the platform underneath them changes on someone else's schedule, so the maintenance floor is higher than it is for ordinary internal software.
Decide who owns the second year
Almost every team that regrets this decision made it on the build number. The build number is knowable and comforting and it is not the commitment. Name the person who owns the agent eighteen months from now, and the answer usually arrives on its own.
If you want help scoring a specific workflow, Start Automating. It starts with 30 minutes on your workflows, and you will leave with a clearer view of the operating burden whichever way you decide.
