Build your own AI agents vs buy: what a DIY agent stack really needs

A working prototype takes an afternoon: a model API, a prompt, a couple of tool functions, and the agent drafts an email. That afternoon is why so many businesses think they should build. The trouble starts in week three, when the agent needs to remember a client's rules, wait for approval, call a customer, recover from an API change and show you what it did yesterday. That is the part of an AI execution layer that takes the real effort.

This is a fair comparison, written by people who build agent infrastructure for a living. We think most operators should buy. Some should build, and we explain who.

The components of a DIY agent stack

Here is what a production agent stack for a small business needs, beyond the model call. Each row is a real piece of engineering with its own failure modes.

None of these is exotic. Together they are a product, and someone has to own it.

Costs that DIY budgets usually miss

Model lifecycle maintenance

Model providers retire old models on a schedule. Anthropic, for example, publishes a model deprecations page and commits to at least 60 days' notice before retiring publicly released models; on 30 September 2026 it notified developers that Claude Sonnet 4.5 would be retired on the Claude API on 30 November 2026. Every retirement means re-testing your prompts and tools on the replacement. If you run agents across several providers, multiply that work.

Integrations that drift

Your CRM ships an API change, your mailbox provider tightens OAuth rules, a chat platform changes its bot policy. Each one breaks something at an inconvenient time. Someone has to notice, fix and redeploy.

Security review

An agent that reads email can be manipulated by what it reads. Defending against prompt injection, scoping permissions and keeping secrets out of prompts is ongoing work, not a one-off. Our security team's guide to least-privilege access for AI agents is a good checklist whether you build or buy.

Being on call

When the agent that receipts payments stops at 6pm on a Friday, who gets the alert? In a DIY stack, it is whoever built it.

When building is the right call

Build if most of these are true:

• Agents are part of the product you sell, so the infrastructure is a competitive asset.
• You have engineers with ongoing capacity, not a contractor who leaves after launch.
• Your core process is unusual enough that no product models it well.
• You need to run inside a specific environment (your own cloud account, an air-gapped network) that vendors can't meet.
• You are willing to own monitoring, model upgrades and security review indefinitely.

When buying is the right call

• You are an owner-operator or small team whose product is something else: property management, therapy, trades, consulting.
• The work is common business admin: email, CRM, invoicing prep, follow-ups, research, calls.
• You want approvals, logs and channel access on day one, not in month four.
• Nobody in the business wants to be paged when an integration breaks.

Buying has its own risk: you depend on a vendor. That is manageable if you can export your data and instructions and leave on short notice. Our AI vendor lock-in checklist covers what to confirm before you sign up anywhere.

The middle path: buy the layer, build the edges

For most businesses the best answer is both. Use a platform for the shared layers (orchestration, approvals, channels, memory, logging, telephony) and build the parts that are unique to you: a connector to your industry system, an internal dashboard, a custom report. In Cortex, Fulcrum Code does exactly this kind of edge work from a chat request: it builds the integration or internal tool, deploys it and reports back. Our software writers cover the process in building software with an AI coding agent.

Individual results vary. The pattern is what matters: the founder owns the direction and the approvals, and doesn't own the infrastructure.

Questions to settle before anyone writes code

1. Which five tasks will the agents do first, and what does done look like for each?
2. Which of those actions must wait for a human approval, and who approves?
3. Who owns the stack after launch, including nights and weekends?
4. How will you know quality has slipped after a model change?
5. Where are logs kept, for how long, and who can read them?
6. What does it cost per month at your expected volume, including model usage, hosting, telephony and the engineer's time?
7. How will you measure whether it is working? (Our hours-saved method is a starting point.)

If questions 3 and 6 make you uncomfortable, that is your answer. Look at what the Cortex platform already provides and build only what is left over.