Build vs Buy: Custom AI Agents vs a Platform

Four months ago, a VP of Engineering at a 45-person startup pulled two senior engineers off the product roadmap to build an internal AI agent framework: an orchestrator, a skill registry, a handful of role-scoped prompts for backend and infra work. The pitch was reasonable at the time, avoid vendor lock-in, tailor everything to their stack. Four months and roughly $180,000 in loaded salary later, the framework handles three of the twelve workflows it was scoped for, has no test suite, and the engineer who designed the orchestrator core just gave notice. This is not a hypothetical, it is the default outcome of treating build vs buy AI agents as a one-time technical decision instead of an ongoing cost with compounding risk, and it is the exact scenario Apex is built to scope before the first engineer gets pulled.

Why ChatGPT and Cursor can't make this call for you

Ask ChatGPT or Claude.ai whether you should build a custom AI agent framework or adopt a platform, and you get a balanced-sounding list: pros of building (control, no lock-in), pros of buying (speed, maintenance offloaded). It reads like a consultant's slide and it is exactly as useless, because it has no visibility into your actual codebase, your actual team size, or your actual security posture. It cannot tell you that your half-built orchestrator has no secrets management, because it has never seen the repository. It cannot tell you that the engineer who owns the framework is your only Kubernetes expert and is currently interviewing elsewhere. A generalist chatbot answers the question you typed, not the question your engineering org actually has, which is closer to: given this specific codebase, this specific headcount, and this specific compliance deadline, what does each path cost in real hours and real dollars, starting today?

Cursor and GitHub Copilot are the wrong tool for a different reason. They are excellent at writing the orchestrator code once you have decided to build it, autocomplete for the skill-registry class, a fast first draft of the agent loop. But an autocomplete layer has no opinion on whether you should be writing that code at all. It will happily help you build month five of an internal framework with the same fluency it would help you build month one, without ever surfacing that a team of three is now four months into a project a platform could have replaced in a week. The build-vs-buy decision has to happen before the keystroke, not during it, and neither a chat window nor an editor plugin is positioned to make that call.

Apex scopes the decision, not just the build

Apex is Tonone's engineering lead agent, and the job it does best is the one most AI tools skip entirely: presenting a real scope with real estimates before anyone commits engineering time. For a build-vs-buy call, that means Apex treats "should we build this ourselves or adopt a platform" as the brief itself, the same way it would scope a feature. It runs apex-recon against whatever internal framework already exists, even a half-built one, reads the actual code, counts the actual test coverage, and identifies the actual bus factor, how many people currently understand the orchestrator well enough to maintain it. Then apex-plan produces the comparison you actually need: a Small option (adopt the platform as-is), a Medium option (adopt the platform, wrap one or two proprietary internal skills), and a Large option (continue the in-house build, properly staffed and hardened), each with time and dollar estimates grounded in what apex-recon found, not a generic industry rule of thumb.

Tonone's Apex scopes the build-vs-buy decision itself, small, medium, and large options for building in-house versus adopting the platform, with time and dollar estimates attached to each.

Forge prices the infrastructure the build path always underestimates

The build-vs-buy conversation usually stalls on engineering hours and never gets to infrastructure, which is where the real ongoing cost of a home-grown system hides. Forge is Tonone's infrastructure engineer, and it runs forge-cost against whatever the in-house option would require: a hosted orchestrator service, a vector store for skill retrieval, logging and observability for agent runs, redundant compute if the framework needs to stay available during business hours. That audit produces a specific monthly figure, not a vague statement that cloud costs will go up. When the same team runs forge-audit against their half-built framework, it typically surfaces what four months of feature-focused development skipped: no rate limiting on the orchestrator's external calls, secrets stored in a config file committed to a private repo six weeks ago, no least-privilege scoping between the framework's service account and production data. None of that shows up in a pros-and-cons list. It shows up in an audit.

Warden catches the compliance gap before an auditor does

The second pain point in this decision rarely shows up until it is expensive: a security or compliance review for a home-grown system that nobody outside the two engineers who built it ever signed off on. It is easy to see how this happens. The framework started as a prototype, then it started handling real customer workflows because it worked well enough, and at no point did anyone schedule a formal security review, because there was no natural moment for one, no procurement process, no vendor security questionnaire to trigger it. Warden, Tonone's security engineer, runs warden-recon and warden-audit against the in-house framework and produces exactly the inventory a SOC 2 auditor or an enterprise customer's security questionnaire will ask for: where secrets live, whether IAM follows least privilege, whether there is an audit log for agent actions that touch customer data, whether dependency versions carry known CVEs. Teams that skip this step almost always find out about the gap during due diligence for a funding round or an enterprise deal, at the worst possible time to discover that the internal agent framework has no access controls and the only person who can explain how it works is out of office. Running the audit before that moment, as part of the build-vs-buy decision itself, turns a nasty surprise into a line item you can price and fix or hand off entirely.

Warden's compliance audit exists to catch the home-grown agent framework nobody signed off on before a SOC 2 auditor or an enterprise security questionnaire does.

A worked example: the build-vs-buy scope Apex actually produces

Take the startup from the opening, call it Fenwick Systems, 45 engineers, four months and $180,000 into an internal agent framework that covers three of twelve target workflows. The VP of Engineering hands Apex the brief: "Should we keep building agent-framework internally, or move to a platform?" Apex does not answer with an opinion. It runs apex-recon against the existing agent-framework repository first: 3,200 lines of orchestration code, zero automated tests, one committed engineer (the one who just resigned), no secrets manager, a single environment with no staging separation. Forge's forge-cost audit prices the infrastructure the Large option would require to productionize properly: a managed vector store, redundant orchestrator instances, logging pipeline, roughly $2,400 a month at current workflow volume. Warden's warden-audit flags four unresolved items: plaintext API keys in a config file, no rate limiting, no audit trail, and two dependencies with open CVEs.

With that grounding, apex-plan produces the actual scope, not a hypothetical:

Apex, Build vs Buy Scope: agent-framework
Recon: 3,200 LOC orchestrator, 0% test coverage, 1 owner (resigning),
no secrets manager, no staging environment.
Forge: in-house infra at production scale, ~$2,400/mo.
Warden: 4 open findings, plaintext keys, no rate limiting, no audit
log, 2 CVEs in dependencies.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
S, Adopt platform as-is
  Retire agent-framework. Migrate 3 working workflows to Tonone
  agents. Remaining 9 workflows built on existing agent skills.
  Time estimate:   ~3d migration + 1 week team ramp-up
  Dollar estimate: ~$0 infra (usage-based token cost only)
  Risk:           Low. No bus-factor risk, no in-house maintenance.

M, Adopt platform + wrap 2 proprietary skills
  Retire orchestrator core, keep 2 internal integrations that touch
  a proprietary pricing engine as custom skills on top of the
  platform.
  Time estimate:   ~1.5 weeks
  Dollar estimate: ~$400/mo (proprietary integration hosting only)
  Risk:           Low-medium. 2 custom skills need a documented
                  owner, plan for a second engineer to cross-train.

L, Continue in-house build, properly staffed
  Fix Warden's 4 findings, add test coverage, hire a second engineer
  to remove single-owner risk, harden for production.
  Time estimate:   ~6-8 weeks to reach current platform parity
  Dollar estimate: ~$95k (2 more months loaded salary) + $2,400/mo
                  ongoing infra
  Risk:           High. Repeats the four months already sunk, adds
                  a second salary, and the framework still only
                  covers 3 of 12 workflows on day one of this option.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Recommendation: S, unless the proprietary pricing integration is a
hard requirement, in which case M.
Next: approve a tier, then Apex hands the migration plan to the
team and flags Warden's 4 findings for remediation regardless of
which option is chosen.

That last line matters as much as the recommendation. Warden's findings do not disappear if Fenwick picks the Small option, the plaintext keys and missing audit log exist independent of which path they choose, and Apex surfaces that instead of burying it under the winning option. This is the difference between a build-vs-buy conversation run as a Slack debate and one run as a scoped engineering decision: the risks that exist regardless of the choice get named, not lost.

When building in-house is still the right call

None of this means build is always wrong. A handful of situations genuinely favor it: a workflow so proprietary that no platform will ever encode it (a physical process control loop tied to custom lab hardware, for instance), a regulatory requirement that mandates the model and orchestration layer run entirely inside a private network with no external calls of any kind, or a team that already has three or more engineers with deep orchestration experience and spare roadmap capacity, not borrowed from a deadline-driven project. Apex's job in those cases is the same, not to talk a team out of building, but to scope what building well actually costs, so the Large option in the plan above is a real commitment with a real budget and a named owner, not a project that quietly absorbs engineering time for a year with no one accountable for finishing it. The failure mode this piece is really about is not building in-house. It is building in-house without ever having scoped what that decision costs against the alternative, and finding out four months and $180,000 later.

Build vs buy, compared directly

The comparison below is scoped to what actually matters for this decision: not general coding ability, but the specific capabilities a team needs to make and act on a build-vs-buy call for AI agent tooling.

Forge's cost audit prices the self-hosted alternative in real infrastructure dollars, not a slide with a shrug.

Install and try

Tonone is free and MIT-licensed. Install it once and Apex, Forge, Warden, and the rest of the roster are available in your Claude Code session. You pay only for the Claude Code token usage during the work, including the scoping itself, which is exactly the number apex-plan shows you before you commit to a tier.