Recently, I was part of a build or buy debate. I like these conversations when they are honest, because the answer is rarely ideological. It depends on how unique the need is, how mature the team is, how much control the business needs, and whether the organization is ready to operate what it builds.
If I need a car, I probably buy one. If I need a very specific race car and I already have the engineering skill, testing track, tools, mechanics, supply chain, and budget, building may make sense. If I secretly need to build a factory for one car, the decision changes quickly.
Agentic AI makes this harder
The tricky part with agentic AI is that an impressive demo is relatively easy. Operating an agent safely at enterprise scale is not.
A demo can route a ticket, summarize an incident, find a cost anomaly, or generate a data pipeline suggestion. Production asks harder questions. Can it handle volume? Can it recover safely from failure? Can it respect identity and authorization? Can it keep customer data inside the right boundary? Can we audit the action six months later when someone asks why it happened?
I do not treat those as afterthoughts. Those are the system.
The decision should move through evidence
The questions I put on the table
I want the decision to consider functional fit, required customization, security, privacy, data residency, reliability, scale, performance, regulation, audit, governance, internal skills, time advantage, full life cycle cost, vendor lock in, model lock in, and platform lock in.
That list sounds long because production is long. Architecture reviews, vendor assessments, and research can create an initial hypothesis. But I do not want a hypothesis to become a decision too early.
Before the trial, write the requirements
Before I start a trial, I split requirements into three buckets. First, what must the solution do for the user? Second, what quality must it meet for the business? Third, what security, risk, and regulatory controls are mandatory?
| Bucket | What I ask for | Why it matters |
|---|---|---|
| Functional | Workflows, integrations, approvals, exception handling. | The agent must solve the real work, not a happy path. |
| Quality | Latency, volume, uptime, recovery, cost per outcome. | The system must survive normal production pressure. |
| Risk | Identity, authorization, data boundaries, audit, retention. | The business needs proof that the system is controllable. |
A real evaluation shape
Imagine a FinOps agent that recommends cloud savings. A bought product may already understand cloud billing, rightsizing, reserved commitments, anomaly detection, and approval workflows. Building may make sense if your pricing model, internal chargeback rules, account hierarchy, or approval policy is unusual enough that a standard product constantly fights your operating model.
I would not decide from a dashboard demo. I would run the trial with representative billing data, real account ownership, known past incidents, policy exceptions, and a few failure scenarios. I would measure answer quality, but also latency, explainability, false positives, skipped opportunities, human review time, integration effort, security controls, audit trail, and run cost.
My favorite signal is cost per trusted outcome. A cheaper tool is not cheaper if engineers spend every week validating its recommendations by hand.
When I lean buy
I lean buy when the workflow is common, the vendor has already solved painful integrations, the controls are strong, the exit path is acceptable, and the team needs speed more than unique control. In those cases, building can become an expensive way to rediscover what the market already learned.
I still want proof. I want to see the vendor handle our data shape, our identity model, our audit needs, our volume, and our exception cases. The moment the product needs too many workarounds, it stops being a product and becomes a dependency with custom operations.
When I lean build
I lean build when the workflow is part of the company's advantage, the data is sensitive, the policy logic is unique, the integration surface is deeply internal, or the risk controls need to be owned directly. In that case, buying the agent may save time at the edge while creating long term friction in the core.
This connects to my earlier view in API first, automation first, data first. If the company has clean APIs, strong automation, and governed data, building an agent on top of that platform is much more realistic. If those foundations are weak, building usually exposes the weakness faster.
The decision I want
I do not force an immediate build or buy answer. I force clarity on what we need, what we measured, what we learned, and what risk we are accepting.
The best decision is not the one that sounds bold in a meeting. It is the one that performs under realistic workload, failure, security, audit, and cost conditions. That is how I try to keep the conversation grounded: not build by default, not buy by default, and never demo by default.