We build tailored AI agents for a living, so you'd expect us to tell you to build. We won't. Roughly a quarter of our scoping phases end with us recommending an off-the-shelf product instead of an engagement with us. That recommendation costs us revenue and earns us the next call, which is a trade we'll take every time.
Here is the framework we actually use.
When buying wins
Off-the-shelf agents win when the workflow is a commodity. If a hundred other companies do the task the same way you do — meeting notes, generic email triage, standard-format invoice capture — a product team somewhere has already spent more engineering hours on it than any custom build could justify.
The tells that buying is right:
- The workflow follows an industry-standard shape with little local variation.
- Your data arrives in standard formats a vendor can ingest without custom pipes.
- Being merely as good as your competitors at this task is fine.
- The tool can fail occasionally without regulatory or contractual consequence.
If all four hold, buy. Configure it well, measure it, move on.
When building wins
Tailored agents win when the workflow is the business. Nobody sells an off-the-shelf product for the way your estimators price repeat-family work, or the way your care managers assemble a prior-auth packet for a specific payer mix.
The tells that building is right:
- The process is proprietary — it encodes judgment your company developed over years and competitors don't have.
- A compliance boundary constrains where data can go. Generic SaaS agents and CMMC or HIPAA obligations mix badly.
- The agent must reach deep into your systems — ERP, DMS, custom databases — not just skim an inbox.
- Wrong answers carry real cost, so you need acceptance criteria a vendor contract can enforce, not a feature list.
The hidden costs nobody quotes
Buying hides costs in the gaps: the workflow bends to fit the tool, exceptions fall back on people, per-seat pricing scales with your headcount instead of your value, and your process knowledge accrues inside someone else's product. Switching later means starting over.
Building hides costs in the tail: someone must operate the system after launch — monitor accuracy, handle model changes, retrain on new data. A build without an operations plan becomes shelfware in about two quarters. That's why our engagements are structured as Scope → Build → Operate, and why we treat the operate phase as the product, not an add-on.
A worked scoring example
Score each factor 1–5, where 5 favors building. Weight the ones that matter most to you. Here's a real shape we see often — a distributor considering a customer-response agent:
| Factor | Weight | Score | Notes | | --- | --- | --- | --- | | Process uniqueness | 3 | 2 | Order status and returns look like everyone else's | | Data standardization | 2 | 2 | Commerce stack has clean APIs | | Integration depth | 2 | 3 | Needs order history, one system | | Compliance boundary | 3 | 1 | No regulated data in scope | | Cost of wrong answers | 3 | 2 | Escalation to a human is cheap |
Weighted score: 25 out of a possible 65. Verdict: buy. The same company scored its quoting workflow at 54 — proprietary pricing logic, deep ERP integration, expensive errors — and that one we built.
The point isn't the arithmetic. The point is that writing the scores down forces the argument into the open, where a demo can't win it by being shiny.
The honest answer is usually "both"
Most operations we scope end up with a portfolio: two or three bought tools for commodity work, one or two tailored systems for the workflows that differentiate the business. The mistake isn't buying or building — it's making the call per-vendor-pitch instead of per-workflow.
If you want the scoring exercise run on your actual workflows — including the ones where we'd tell you to buy — book a consult. Thirty minutes, no deck.