Build an AI agent, or buy an AI tool
The honest test is not whether you could build it. It is whether the process is specific enough to you, and runs often enough, to be worth owning forever.
Build-versus-buy for AI gets argued on capability, which is the wrong axis. Almost anything can be built now, and that is precisely the problem: the constraint moved from what is possible to what is worth maintaining.
The two questions that decide it
Is the process specific to you? Not "is it important to us". Specific. If three companies in your industry run it roughly the same way, a product either exists or will, and a vendor working on it full time will outpace whatever you maintain on the side. If your version is genuinely unusual, no product is coming, and the question becomes the second one.
How often does it run? This is the number people skip. Multiply it by the time each run takes and you have the ceiling on what automating it can ever be worth. Where that ceiling sits below the build cost, no amount of model quality rescues the case, and the answer is no before anyone quotes.
What building actually commits you to
A build is a dependency you now own. The initial delivery is the part that gets quoted; the list below is the part that does not.
- The integration surface. Every system the workflow touches is a contract that can change underneath you. Vendors deprecate endpoints on their schedule, not yours.
- The model underneath. Providers retire versions and ship new ones with different behaviour. Something tuned carefully against one model is work you will redo.
- The edge cases you have not met yet. Production finds them at a rate a pilot never will, and each one is a decision about what the system should do when it is unsure.
- The person who understands it. If that is one contractor, you have bought a dependency with a notice period.
None of this is a reason not to build. It is a reason to price the build including the second year, which almost no proposal does.
The middle option people forget
Most of what gets scoped as a build is better served by configuring a product you already run, with a small amount of custom work at the edges. A workflow tool you already pay for, doing eighty per cent of the job, with one integration written properly, beats a bespoke system doing all of it, because the eighty per cent stays supported by someone else.
This is the option nobody pitches, because there is very little to invoice for it.
A test you can apply before anyone quotes
Write down what a person does today, how long it takes, and how often. Three facts. If you cannot fill all three in, the project is not ready. Not because AI cannot help, but because nobody will be able to establish afterwards whether it did.
With those three facts, the payback maths is arithmetic rather than argument, and it usually settles build-versus-buy without a meeting.
What to do this week
Take the AI idea currently furthest along in your organisation and answer the two questions on it. Is the process specific to you, and how many times a month does it run. If the answer to the second is a number nobody knows, that is the finding, and it is worth more than the project.
Where this goes next
Before building anything, check what your existing stack already does: most of the AI you need, you are already paying for. If a build is genuinely the answer, the reason most of them stop at pilot is in why AI pilots do not reach production, and the workstreams a build actually commits you to are in what software implementation actually covers.
Deciding which of your ideas should be built, and saying which should not, is AI consulting.