Build vs. buy vs. agency: who should build your AI agent
Three real paths to an AI agent, and the honest tradeoffs of each, from a team that gets hired for the third one.
The question behind the question
Nobody actually wants “an AI agent.” They want a ticket queue that doesn’t pile up, a research process that doesn’t eat an analyst’s week, an ops team that isn’t drowning in the same five requests. The agent is the mechanism, not the goal, and that matters because it changes how you should evaluate the three ways to get one built.
Option one: build it in-house
This is the right call when the agent touches your core product, the thing customers actually pay for, and when you already have engineers who understand both your domain and the current state of agent tooling. In-house building keeps everything inside your own context and your own codebase, with no handoff risk.
It’s the wrong call when the team doesn’t have anyone who’s actually shipped an agent to production before. The gap between a LangGraph tutorial and a system that survives real traffic, retries, and cost blowouts is wider than it looks, and most in-house first attempts spend their first few months rediscovering lessons that are already well understood elsewhere. If this is the path, budget real time for the boring parts, not just the model-calling logic (we wrote more on what that actually involves in the boring parts of an AI agent that actually matter).
Option two: buy an off-the-shelf tool
Right call when your need is genuinely generic: a support widget, a generic meeting-notes summarizer, a standard CRM enrichment flow. Dozens of vendors have already built and hardened exactly that, and paying a subscription beats paying for a custom build of something that isn’t differentiated.
Wrong call when your workflow has real specifics: your SOPs, your edge cases, your systems that don’t have a pre-built integration. Off-the-shelf tools are built for the median customer, and the parts of your process that actually cost you time are usually exactly the parts that are not median. We see this constantly: a team buys a generic tool, configures it for three weeks trying to bend it to their actual process, and ends up with something that handles 60% of cases and silently mishandles the rest.
Option three: hire an agency
Right call when the agent needs to be production-grade, specific to your actual workflow, and you don’t have in-house capacity to build and maintain it yourselves, or you want expert judgment on the build without hiring a permanent team for a project with a defined scope.
The honest failure mode on this path isn’t the build, it’s the handoff. A lot of agencies ship something that works in the demo and leaves with the client holding a system nobody on their team understands. That’s why we scope engagements at six weeks (see why six-week projects beat six-month ones) and hand over a repository the client owns outright, with documentation a new engineer can actually use, not a black box tied to us staying involved.
A rough decision rule
If the agent is core differentiated product and you have the in-house expertise: build it. If the need is genuinely generic and well-served by an existing category: buy it. If the need is specific to your workflow, needs to be production-grade, and you don’t have spare in-house capacity to build and maintain it: that’s an agency’s job, and the right agency should make itself replaceable, not indispensable.
What we actually tell people
More often than you’d expect, we talk a prospective client out of a full agent build and toward a buy or an in-house fix instead, because that’s genuinely the better call for their situation (see why most “AI features” should be a button). If an agency’s first move in every conversation is “yes, we should build you a custom agent,” that’s worth noticing. The right answer to “who should build this” is sometimes nobody, because it doesn’t need to be an agent at all.
