There are four ways to get a piece of work done with AI: operate a tool yourself, build your own system from open-source parts and a model API, hire a company that delivers the finished outcome, or bring in people who implement AI inside the systems you already run. The right choice depends less on the technology than on who will be responsible when it is wrong, how often the work repeats, and how much of your context the system has to know.
Most advice about "AI adoption" skips this question. It assumes you are choosing between tools. In practice the tool is only one of four routes, and picking the wrong route is the most expensive mistake you can make — more expensive than picking the wrong tool, because a tool can be swapped in an afternoon and a route is a commitment of months.
This guide is the framework we use on Toolsfine to organize every industry handbook and task page. It is written for the person who has to decide, not for the person who already knows what they want to buy.
What are the four routes?
| Route | What you get | Who operates it | Who is responsible for the result | Typical cost shape |
|---|---|---|---|---|
| Use a tool yourself | Software with AI inside it | You and your team | You | Subscription per seat or per use |
| Build it yourself | A system assembled from open-source components and model APIs | Your engineers | You | Engineering time plus usage-based model cost |
| Hire an AI-native service | A finished outcome (resolved tickets, signed-off notes, qualified leads) | The service company, with AI doing most of the volume | The service company, within what its contract states | Per outcome, per month, or per volume |
| Get it implemented | AI working inside your existing systems and workflows | Your team, after the implementation partner leaves | Shared, then yours | Project fee, sometimes a retainer |
The first two routes put you in the operator's seat. The last two put someone else in it. That single distinction — who operates — explains most of the difference in price, speed and risk.
Route 1: Use a tool yourself
This is where almost everyone starts, and for good reason. A tool is cheap to try, cheap to abandon, and the vendor has already made most of the design decisions for you.
A tool is the right route when the work is general enough that a vendor could design for it without knowing your business, when a person on your team can judge whether the output is good, and when the volume is low enough that a human reviewing each result is not a bottleneck. Writing assistants, transcription, image generation, first-draft code, meeting summaries — the output lands in front of someone who checks it, and that check is the quality control.
The cost that people underestimate is not the subscription. It is the person. A tool does not remove the work; it changes the work from "produce" to "review and fix". If nobody on your team has the time or the expertise to review, a tool quietly produces unreviewed output, and the first time that output reaches a customer or a regulator you discover that the route was wrong.
Signs you have outgrown a tool: the same prompt is being typed hundreds of times a week; someone has built a spreadsheet to track what went through the tool; the tool's output needs data from three other systems to be useful; or you are paying for seats that exist only to copy results from one place to another.
Route 2: Build it yourself
If your team can write and maintain software, building is often the most rational route — and it is the one that people with technical teams underrate because it does not come with a sales pitch.
Open-source projects now cover most of the plumbing: retrieval, orchestration, evaluation, guardrails, interface. The model itself comes from an API at usage-based prices that keep falling. What you build is the thin layer that knows your data, your rules and your edge cases — and that layer is exactly what no vendor can sell you, because it is specific to you.
Build when the task is core to how you compete, when your data cannot leave your environment, when the volume is high enough that per-seat or per-outcome pricing would cost more than an engineer, or when you need behavior that no vendor's product will give you.
Do not build because it looks cheap. The model API bill is the smallest line. The real cost is the engineer who is on call when the pipeline breaks at 2 a.m., the evaluation set that has to be maintained as the model changes, and the fact that every improvement is now your job. If you cannot name the person who will own this system in twelve months, you are not building; you are prototyping, and a prototype should not be in production.
A practical test: can your team explain, in writing, how they will know the system has gotten worse? If not, you do not yet have the capability to run what you would build.
Route 3: Hire an AI-native service
An AI-native service company sells the outcome, not the software. You send the support tickets and get resolved tickets back; you send the recordings and get signed-off clinical notes; you send the inbound calls and get qualified appointments. AI does most of the volume; people review, handle the exceptions and, in regulated work, sign their name.
This route exists because many organizations do not want to operate anything. They want the work done and a named party responsible for it. That is a legitimate preference, and for a long time it was served by agencies and outsourcers at prices that reflected human labor. AI-native services deliver the same shape of promise at prices that reflect machine labor plus human review.
Hire when you need the result but not the capability — when operating the system is not something your organization should learn, when the work is high-volume and repetitive, or when you need a licensed professional's sign-off and do not have one on staff.
The questions that matter are not about the AI. They are about the contract. Who is named as responsible for the outcome? Is there a public service level, or only a sales promise? Is your data used to train their models? Can you get your data out, in a usable format, when you leave? Is the pricing tied to the outcome you care about, or to an input you cannot control? Toolsfine's company profiles check these as separate items, each with a source, because the answers are routinely different from what the homepage implies. Our checklist for this is a guide of its own.
The honest limit of this route: a service company optimizes for the outcome it is paid for. If your definition of "done" is unusual, or changes often, you will spend more time managing the vendor than you saved.
Route 4: Get it implemented
Sometimes the AI you need is not a product and not a service. It is a change to systems you already have — the CRM, the ticketing system, the document pipeline, the ERP — and the people who know those systems are busy running them. This is where implementation partners and forward-deployed engineers come in: people who build the integration, train your team, and leave.
Implementation is the right route when the value is in the integration, not in any single model or tool, when your systems are the constraint, and when you intend to own the result afterward. It is the route most organizations with established software estates actually need, and it is the one most under-served by "AI adoption" content, because there is no product to review.
The risk is the handover. An implementation that only the implementer understands is not an implementation; it is a dependency. Ask, before signing, who on your side will own the result, what documentation and runbooks are part of the deliverable, and what the partner's own definition of "done" is. A partner who cannot describe the handover in detail is selling you a project, not a capability.
How to decide: five questions
You do not need a scoring model. Five questions, answered honestly, land most organizations on the right route.
- Who is responsible when the output is wrong? If the answer must be a named external party, you are choosing between a service and an implementation partner. If it is you, you are choosing between a tool and a build.
- How often does this work repeat, and at what volume? Low volume favors a tool. High, steady volume favors a service (if you want it operated) or a build (if you can operate it).
- How much of your private context does the system need? The more it needs — your data, your rules, your systems — the further you move from a generic tool toward a build or an implementation.
- Can your team run a system in production? Not "can they prototype". Can they keep it working, measure it, and fix it. If not, do not build, whatever the demo looked like.
- Is the capability itself something you want to own? If operating AI for this task is part of how you plan to compete, build or implement. If it is a cost center, use a tool or hire a service.
Two or three questions usually point the same way. When they conflict — for example, high volume (service) but data that cannot leave (build) — the conflict itself is the answer: you are looking at a private deployment from a service company, or an implementation partner who builds it in your environment. Both exist, and both cost more than the simple routes, which is why it is worth knowing early that you need one.
Mixing routes is normal
The four routes are not a ladder you climb. Most organizations end up using all of them at once: tools for individual productivity, a built system for the one task that defines the business, a service for a high-volume back-office process, and an implementation partner for the integration that ties them together. The mistake is not mixing; it is drifting — letting a tool grow into a critical process without ever deciding that it should, or building something nobody owns.
A useful habit is to write down, for each AI-dependent process, which route it is on and who is responsible. The list is usually short, and the gaps are usually obvious once it exists.
How Toolsfine uses this
Every industry handbook and task page on Toolsfine ends with a block called Four ways to get this done. The first column lists tools we have checked. The second lists open-source options for building. The third lists AI-native service companies whose claims we verify item by item. The fourth lists implementation partners. Sponsored entries, where they exist, sit in their own labeled area and never change the editorial lists.
Company profiles under AI-Native Services check each capability and commitment — end-to-end delivery, human review, licensed sign-off, public SLA, data-training policy, named liability — as a separate item with a source and a check date. "Not stated" means we found no public statement; it never means "no".
Related guides
- How to evaluate an AI-native service provider: a checklist
- What is an AI-native service company (and how it differs from SaaS and agencies)
- What is a forward-deployed engineer — and when do you need one?
Koyama, Operation Master of Toolsfine.com