Anyone introducing an AI agent has three routes: buy a finished product with an AI feature, rent an agent platform and configure it yourself, or have an agent built for your own process. The choice decides less about the entry price than about who owns the solution in the end.
This article is an in-depth expert contribution from our content cluster. Discover the complete overview on our main page:AI Automation & Intelligent Agents →
- Three routes, three different dependencies: buying ties you to a product, renting to a platform, building to your own ability to operate it. You have to choose one of them.
- The decision is made by the process, not the budget: if your procedure is the same as everywhere, buy. If it is your differentiator, commission it.
- All three routes need operations: a bought agent drifts in content too. It is just that when you buy, nobody automatically checks it for you.
1. What is being compared
This question is often treated as a variant of the classic make-or-buy decision. That falls short, because AI agents add two properties ordinary software does not have. The solution changes its behaviour without anyone changing anything — because models evolve or get deprecated. And it fails silently, because it keeps answering even once its basis has fallen away.
Those two points shift the calculation compared with any other software procurement. This article therefore deals specifically with AI agents. The general strategic version — rent SaaS or build with n8n and custom development — is covered in Make or Buy 2026 and remains valid there unchanged.
2. Route 1: Buying — the finished product with an AI feature
The simplest route is not to procure an agent at all, but a product that already does the job: a helpdesk system with AI answer suggestions, accounting software with document recognition, a CRM with a summarisation feature.
Comparison: what buying delivers and what it costs
- Usable immediately: no development, no months-long rollout project.
- The vendor maintains the model: model changes and quality assurance are their problem, not yours.
- Predictable price: usually per user or per transaction, with no project costs.
- The cheapest route when it fits: for standard tasks, building your own is nearly always waste.
- Your process has to adapt: the product knows the standard case, not yours.
- No control over data processing: the vendor determines location and scope.
- No competitive advantage: your competitors can buy the same product.
- You cannot look inside: why an answer came out that way is often not traceable.
3. Route 2: Renting — configuring the agent platform yourself
The middle route: a platform on which agents can be assembled without programming — upload a knowledge base, describe the behaviour, connect a channel. For a first attempt this is often the fastest entry, and that is exactly what it is good for.
The wall arrives at the second step
The first use case succeeds quickly. But as soon as a special rule appears, an internal system has to be connected or a result needs checking, the toolkit ends — and the effort spent was a dead end.
What you built usually cannot come with you
Prompts, configuration and the prepared knowledge base live in the platform's format. Vendor lock-in does not arise on day one but after the third use case.
Your knowledge base sits outside the building
To be useful the agent needs your content — price lists, contracts, internal instructions. On this route you upload exactly that to a third party. That can be fine, but it has to be a deliberate decision.
4. Route 3: Commissioning — the agent for your own process
The third route is an agent tailored to your process: your systems connected, your rules applied, your data where you decide. Technically that usually means a workflow environment such as n8n plus a knowledge base connected to the language model via RAG.
It is the most demanding route and not always the right one. It pays off when at least one of these applies:
1. The process is your differentiator
If you do something differently from competitors and that is precisely why customers come, a standard product cannot represent it by definition — it only knows the average.
2. Your own systems have to be connected
As soon as an ERP, inventory system or a grown database is involved, the reach of finished products ends. This is the most common concrete trigger for building.
3. Data may not leave the building
With personal, contractual or otherwise protected content, the processing location becomes a duty to demonstrate compliance. Only when building do you determine it entirely.
4. The transaction occurs very frequently
At high volume the calculation tips: usage-based product prices grow with you, a process built once does not grow at the same rate.
With me this route runs at a fixed price: one scoped use case as an AI sprint for €2,900 in 14 days, larger undertakings as Automation Scale from €5,900. When it is unclear beforehand whether it carries at all, the process check for €690 comes first — explicitly including the possible outcome of not doing it.
5. The four test questions
-
Is the process different at your company than everywhere else?
If not: buy. A standard procedure does not justify building your own, however interesting the technology is.
-
Where do the data the agent needs actually flow?
Not the question of what it outputs, but what it requires in order to work. Exactly that leaves your building when you buy or rent.
-
What can you take with you in two years?
Prompts, test cases, the prepared knowledge base: do you own them, in a format you can export? Asking this before signing is the cheapest insurance there is.
-
Who notices when the agent answers incorrectly?
The most important and least frequently asked question — and the reason none of the three routes works without operations.
A workflow aborts when something goes wrong. An agent keeps answering — even once its basis has fallen away. That applies to bought products just as much as to custom-built ones.
I know this point is real from my own operations: in Pragma-Code's AI visibility monitor an automatic fallback silently removed the source grounding after a rate limit. The system reported no error and kept delivering answers — just without the basis that was the whole point. It surfaced during a content spot check. That is precisely why agent operations is a separate product line with me, with a monthly quality sample against fixed test cases, from €390 per month.
6. The route nobody proposes: no language model at all
A considerable share of what gets requested as an AI agent needs no AI. When a process has fixed rules — a given question, a given answer, a clear responsibility — a rule-based solution is superior: it is cheaper, faster, it cannot hallucinate, and it is auditable without extra effort.
That is exactly why I offer a website assistant without a language model as its own service. The test question is simple: can you write the answers down in advance? If so, you do not need a model that reinvents them every time.
7. Decision guide
Buy
A standard task with an established product available, no particular data protection requirements, no need for custom logic. The cheapest route when it fits.
Rent
For experimenting and learning, with simple processes and non-critical content. Knowing that the second use case may hit a wall.
Commission
Your own process, your own systems, your own data sovereignty, or high volume. At a fixed price, with a clearly scoped use case instead of an overall vision.
No AI at all
When the answers can be written down in advance. Rule-based is cheaper, auditable and cannot invent something wrong.
8. Testing without committing
The three routes are not mutually exclusive in time. The most expensive mistake is not choosing the wrong route but choosing it before anyone knows whether the use case carries at all. A pilot answers that for a fraction of the cost — if it is scoped correctly.
What a usable pilot has to deliver
-
It answers one question, not several
"Can a model reliably answer the ten most common customer questions from our documents?" is a testable question. "Can we automate our customer service?" is not — it can neither be confirmed nor refuted.
-
It works with real cases, not selected ones
Take the last fifty genuine enquiries, unfiltered, including the unclear and the rude ones. A pilot fed only clean examples says nothing about live operation.
-
It has a pass criterion agreed in advance
Before starting, write down which result means continuing — and which does not. Without that number every pilot ends with the verdict "promising in principle", and then the decision is made not by the result but by whoever is loudest in the room.
-
It must be allowed to fail
A pilot whose result nobody internally is permitted to reject is not a test but a rollout with an extra step. If the project is already politically decided, skip the pilot and build straight away.
A pilot can be built on any of the three routes: as a trial account on a finished product, as a clicked-together process on a platform, or as a small, scoped custom build. For the third variant I offer the prototype approach — working software instead of a presentation, so the decision is made against something usable rather than an idea of it.
Expert tip: the test cases outlive the pilot
Whatever the pilot concludes, the collection of real enquiries with their correct answers is the most valuable outcome. It is the yardstick for every later quality check, and it belongs to you regardless of the route you finally choose. Building that collection is the one piece of work that is lost in no scenario.
Quick check before deciding
9. The question that outlasts all three routes: who owns the answer?
Regardless of whether you buy, rent or commission: when an agent tells a customer something wrong, they are your customers and it is your name. Accountability to the outside world cannot be procured along with the tool — it stays with you, even when the model comes from one vendor and the platform from another.
Three things follow that should be settled before rollout, and none of the three sourcing routes supplies them automatically.
First: where does the agent's remit end? There have to be topics where it does not answer itself but hands over — price commitments, legal statements, anything carrying liability. That boundary belongs in the configuration, not in hope.
Second: is it recognisable that this is not a human? Beyond regulatory requirements on labelling AI, it is simply a matter of conduct: someone who believes they are talking to an employee judges a wrong answer differently — and reacts accordingly once they notice.
Third: what happens to what the agent cannot do? The handover path to a human is not an edge case but the most important part of the process. An agent that keeps talking under uncertainty instead of handing over does more damage than none at all.
These three points cost little to implement and decide whether a working agent also becomes a defensible one. They are also why choosing one of the three routes is not the end of the work but its beginning.
Conclusion
Buying, renting and commissioning differ less in price than in the dependency you take on. Buying ties you to a product and its view of the process. Renting ties you to a platform and puts your content there. Commissioning ties you to your own ability to operate the result.
So the best route is rarely the technically most ambitious one but the one that fits the process — and in a surprising number of cases it is the fourth: realising that this task needs no language model at all.
Have a vision?
Let's check together how we can make your idea take flight.
Book your free strategy call nowExtended Specialized Glossary
Cognitive Agent
An AI system that independently breaks a task into sub-steps, uses tools and evaluates intermediate results.
RAG
Retrieval Augmented Generation — enriching a model's answer with content from your own knowledge base so it becomes verifiable.
Vendor Lock-in
Dependency on a provider that arises when switching becomes technically or economically disproportionate.
