Build vs Buy for Your First Production Agent

Part of the Beyond Copilot, Claude and ChatGPT: actually embedding AI into your company series.

What this article gives you

By the end, you will have a decision framework for whether to build an agent in-house or buy a vertical product, a clear picture of what building actually costs beyond the model call, and a set of questions to put to any vendor before you sign. The decision is not binary for most organisations. Most land on a hybrid, and understanding why helps you design that split intentionally rather than accidentally.

This article deepens the thread started in embedding AI beyond assistants into your company. If you have not yet identified which workflow you are targeting first, read how to pick your first AI agent use case before continuing. The build-or-buy question only makes sense once you know what the agent has to do.

What building actually entails

The model call is maybe fifteen percent of the work. The rest is infrastructure that most teams discover only after the prototype impresses someone in a demo.

Here is what that infrastructure looks like in practice:

flowchart TD
    A[Define task scope] --> B[Model integration]
    B --> C[Tool and API wiring]
    C --> D[Auth and permissions layer]
    D --> E[Evaluation harness]
    E --> F[Observability and logging]
    F --> G[Human escalation path]
    G --> H[Production deployment]
    H --> I[Ongoing maintenance and model updates]

Integration. Your agent needs to read and write data in systems that were not designed for it. CRM, ticketing, ERP, internal APIs. Each connection requires auth, rate-limit handling, and a contract for what happens when the downstream system is unavailable.

Permissions. An agent that can write to a CRM needs scoped credentials, audit logging, and a clear answer to the question “what is the worst thing this agent can do if it halves off course?” That answer shapes the permission model. The RBAC vs ABAC comparison for agents is worth reading before you design this layer.

Evaluation. Without a test suite you cannot tell whether a model update improved or degraded your agent. Agent evals 101 covers how to build that suite. Most teams skip it and then cannot diagnose regressions. Agent evaluation as a discipline is still maturing, but the core principle is unchanged: define what task completion looks like before you ship.

Maintenance. Models change. APIs change. Edge cases accumulate. A production agent is a software system, not a deployment. Expect one to two engineers allocating twenty to thirty percent of their time to keeping it current.

Getting your first agent live covers the full production checklist in detail.

When buying wins

Vertical agent products have a head start of twelve to eighteen months of production data in a narrow domain. In customer support, SDR workflows, and coding assistance, that matters.

Notion bought Decagon’s customer support agent and achieved a 34% faster ticket resolution rate with a 3.4% human escalation rate across millions of annual inquiries. That outcome required no proprietary model training. Decagon had already absorbed the failure modes of high-volume product support across many customers before Notion signed.

Duolingo deployed the same vendor’s agent and deflected 80% of support volume without expanding headcount. The deflection rate is what matters here: it represents a specific, measurable threshold, not a general claim about AI capability.

The pattern holds in coding. According to a December 2025 survey by Zapier, 49% of customer support teams have deployed AI agents in production, and 72% of enterprises are using or testing agents. The tools driving that adoption are mostly vertical products, not bespoke builds.

Buy when:

• The workflow is a commodity. Customer support triage, outbound SDR sequencing, and code review are solved problems in narrow vertical products.
• You lack production data in that domain. Vertical vendors have already tuned against failure modes you have not encountered.
• Time to production matters more than differentiation. A bought agent can be live in four to eight weeks. A built agent takes four to eight months for the same scope, assuming no rework.

When building wins

Building makes sense in three situations.

Proprietary workflow. If the process the agent runs is itself a competitive advantage, buying means handing that process to a vendor who can learn from it. Morgan Stanley built DevGen.AI in-house to review and modernise legacy code, including COBOL and Perl translation. The result was 280,000 developer hours saved across 9 million lines of code reviewed. No vertical product exists for that specific combination of legacy stack, internal tooling, and institutional context.

Proprietary data advantage. If your data is materially better than anything a vendor could access, a custom-trained or custom-fine-tuned agent can outperform a general vertical product in your domain. The advantage has to be real and measurable, not assumed. JPMorgan’s 450-plus active agent use cases in production include investment banking presentation generation in thirty seconds and real-time fraud detection at scale, both dependent on internal data assets that no external vendor holds.

The agent is the product. If you are building an AI-native product or service and the agent capability is what customers are paying for, buying a vertical tool gives you no defensible differentiation. You will eventually need to own the stack.

Build when any of these three conditions hold and when you have the engineering capacity to maintain what you ship. The second condition is load-bearing. Only 11% of enterprises have an agent running in production at genuine scale, with 88% of deployments never reaching production. The gap between prototype and production is where build decisions go wrong.

The hybrid pattern most mid-size companies land on

flowchart TD
    A[Identify all candidate workflows] --> B{Commodity or differentiating?}
    B -- Commodity --> C[Buy vertical agent product]
    B -- Differentiating --> D{Proprietary data or workflow?}
    D -- Yes --> E[Build in-house]
    D -- No --> F[Buy and customise]
    C --> G[Operate and measure]
    E --> G
    F --> G
    G --> H[Feed learnings into next build decision]

Buy the support agent. Buy the SDR agent. Build the one that runs against your proprietary data, your internal API chain, or the workflow that is the reason customers choose you over the next option.

This split does two things. It gets value into production quickly while the build is underway. And operating a bought agent teaches your team what production looks like before they own all the failure modes themselves.

For AI agents in customer service, the bought-agent pattern is now the default for mid-size companies. The build effort goes into what those companies cannot buy.

Questions to ask any agent vendor

Reliability claims need evidence. Before you commit, ask for:

• Task completion rate on a named, published benchmark, not a proprietary demo scenario.
• Escalation rate in production at a comparable customer. A rate below five percent in support is achievable; demand a named reference, not an anonymised case study.
• Mean time to resolution in production, not a sandbox. The gap between demo and production performance is the most common source of disappointment.
• Model update policy. When the underlying model changes, how long before you are notified? What regression testing does the vendor run before pushing updates to your deployment?
• Data handling. Does your conversation data train future model versions? What is the contractual answer, not the sales answer?

Good vendors answer these questions with specifics. Vendors who deflect them are telling you something about what their production performance looks like.

You will want the same observability over a bought agent that you would apply to a built one. Knowing whether your agents are doing their job covers the monitoring layer that applies regardless of who wrote the agent. Tools like Prefactor sit in this category, providing the evaluation and observability layer across both bought and built agents.

Agent observability and AI agent governance are not optional steps you add after the agent is working. They are part of what makes the agent production-grade in the first place.

Where to start

Map your candidate workflows against the three build conditions above before you talk to any vendor or allocate engineering time. Then take the agent readiness assessment to identify where your organisation’s current capabilities and gaps sit. The assessment takes about ten minutes and gives you a starting point for the conversation with your team.