Arkwright explainer
Build vs buy AI agents: the practical decision
Buying is often right for common workflows. Building is justified when context, permissions, differentiation, or ownership matter.
- Decision shape
- Build, buy, or configure
- Best for
- Operators choosing a path
- Read time
- 5 minutes
Decision guide
Build, buy, or configure
Use this when the team is split between SaaS, custom work, and a configured middle path.
The practical question
Should this capability be bought, built, configured, or left alone for now?
Use this when
- You need to decide whether custom work is justified.
- A vendor tool looks close, but not quite close enough.
- You are weighing speed, control, lock-in, and long-term ownership.
How to read it
- 01Start with the scoring axes.
- 02Run the concrete vendor-vs-custom example.
- 03Use the final checklist without assuming custom build is the answer.
What to weigh up
You will leave with
- Separate build, buy, and configure instead of treating the choice as binary.
- The pros and cons of each path against business constraints.
- A clearer view of exit cost, ownership, and data sensitivity.
Scoring criteria
- Score the workflow against strategic weight, process fit, data sensitivity, and change rate.
- Use the decision tree as a shortcut, then test it with a worked support-agent example.
Trade-offs
- Buy: faster and cheaper when vendor fit is high, but lock-in and pricing curves matter.
- Build: stronger control when constraints require it, but higher up-front cost and ownership burden.
- Configure: often the pragmatic middle path when an existing platform covers most of the job.
Score the decision
Four questions before you write a brief
Score each axis honestly. The right answer is rarely uniform: most SME workflows lean buy on one or two axes and build on another. The shape of the answer is the brief.
Is this workflow core to how you make money or differentiate?
Leans buy
If it is supporting, not core — buying is usually right.
Leans build
If it is core, owning the workflow keeps the edge with you.
Does your process match a vendor playbook reasonably well?
Leans buy
High fit — bought tools are faster and cheaper.
Leans build
Low fit — bending the vendor flow costs more than building.
Is the data you are passing into the agent sensitive or regulated?
Leans buy
Low sensitivity — vendor isolation is usually sufficient.
Leans build
High sensitivity — ownership and residency are easier in custom.
How often do the rules behind the workflow change?
Leans buy
Stable workflow — vendor cadence is fine.
Leans build
Frequent change — in-house iteration is faster.
The shortcut tree
Four questions, one recommendation.
Use this as a sanity check on the longer scoring exercise.
- 01
Is the workflow standard and vendor lock-in acceptable?
Buy.
Pick a vendor with documented APIs and a clean exit path.
- 02
Does the agent need deep context, custom permissions, or differentiated logic?
Build.
Own the workflow, the accuracy checks, and the audit trail.
- 03
Does an existing platform get you most of the way with less risk?
Configure.
Use the platform, extend the gaps with custom thin layers.
- 04
Are you unsure on most axes?
Start bought, plan to graduate.
Buy what proves the value. Build the parts that prove out as differentiated.
Worked example
Customer-support agent: vendor tool vs custom build
A B2B SaaS team with ~400 paying customers. Support ticket volume rising 25% YoY. Existing helpdesk in place.
Input
Inbound support requests across chat and email with a documented knowledge base.
Process
- 01Buy path. Vendor AI support tool connected to the existing KB. 4-6 weeks to a defensible deflection rate. Per-resolution pricing. Tight integration with the existing helpdesk.
- 02Build path. Custom agent grounded in the KB, integrated with the product DB for account-specific answers, escalation policy controlled in-house. 10-14 weeks. Higher up-front cost, lower per-resolution cost, full control over data and routing.
- 03When to buy. Most B2B SaaS teams at this scale should buy. The vendor solves 80% of the use case with less risk.
- 04When to build. If the support flow needs deep product-DB context, regulated data handling, or differentiated tone, the custom build pays back over an 18-month horizon.
Output
A clear-eyed view on which path actually fits your operating constraints, not which one is the most fashionable.
What to watch
A build justification that leans on 'we want full control' without naming the constraint that requires it. That is usually a build-by-default impulse, not a decision.
Read before deciding
Caveats
- Do not build because it feels more advanced.
- Do not buy without an exit path for your data and process.
- Do not ignore the team who will own exceptions.
- Do not skip the configure-first option just because it is less interesting.
FAQ
Common questions
Arkwright next step
Run the scoring against one real workflow.
Bring a workflow you are weighing. We will score it with you and give you a defensible path — including the option to not build at all.
Related explainers