Custom AI agent vs off the shelf: which one your business needs
The short answer: start with off the shelf for anything that lives inside one tool and touches nobody's data but the user's own. Build a custom agent the moment the work has to read your systems, write back to them under your permissions, remember state between steps and leave a log you can audit. Most companies we work with end up with both, and the mistake is to expect one of them to do the other's job.
This guide is about agents specifically. The wider software question, when to build an internal tool and when to buy SaaS, is in our build vs buy guide. And if you are still unsure whether you need an agent at all, read chatbot vs AI agent first.
Last updated: September 9, 2026
Custom vs off the shelf: the comparison
| Off the shelf | Custom agent | |
|---|---|---|
| Data access | What the vendor's connector exposes, usually read-only | Any system you have, read and write, down to the field |
| Permissions | The user's own, or the vendor's admin model | Scoped per tool: read this calendar, write to this table, nothing else |
| Memory and state | Per conversation, sometimes per user | Real state: a task can wait for approval and resume tomorrow |
| Integration depth | Surface: summarise, draft, search | Deep: opens the record, fills the fields, triggers the next step |
| Who owns the prompts and code | The vendor | You |
| Vendor lock-in | High: the workflow lives in their product | Low: the model is a swappable component |
| Cost structure | Per seat, monthly, whether used or not | One-time build, then per-use model cost and maintenance |
| Time to first value | Same afternoon | Weeks for a first working version |
| Who maintains it | The vendor, on their roadmap | You, or whoever built it, on your schedule |
| Where it fails | Can't reach the system where the work actually is | Nobody owns it after launch |
What does "off the shelf" mean for AI agents?
Four different things, and it helps to separate them because they fail differently.
The general assistants: ChatGPT Team and Enterprise, Microsoft Copilot, Gemini for Workspace. A capable model with a chat window, file upload, and a growing set of connectors to mail, calendar, documents and a handful of business apps. They are excellent at the work that starts and ends in a conversation: drafting, summarising, answering from a set of documents, turning a messy note into a plan.
The agent features inside the tools you already pay for: monday's AI blocks, HubSpot's Breeze agents, the AI assistants in Fireberry, Zendesk and Intercom. These see the data inside that one product and act on it there. An Intercom agent answers a support ticket from your help centre. A HubSpot agent drafts the follow-up from the deal record. Inside their walls they are good, and getting better.
Vertical SaaS bots: products built for one job in one industry, like an appointment bot for clinics or a lead-qualification bot for real estate. Quick to switch on, and shaped around the average customer in that industry, which is rarely you.
And the agent builders: no-code studios where you assemble an assistant from a prompt and some connectors, hosted by the vendor. Closer to custom than the other three, with the vendor still owning the runtime and the connector list.
What all four share is the boundary. They act where the vendor has already built a door. If your work lives in an ERP the vendor never heard of, in a folder of scanned PDFs, or across 4 systems that each hold a piece of the record, the off-the-shelf agent stops at the wall and hands the rest back to a person.
What is a custom AI agent?
A model plus your tools, your data, your permissions and your logs. The model is the least special part; we mostly use Claude, and swapping it for another is a configuration change. Everything around it is what makes the agent yours.
The tools are the actions the agent is allowed to take, written as a closed list: look up a customer in the CRM, read an invoice from the shared drive, create a task in the project system, send a WhatsApp message through your business number. Each tool is code that talks to your system, and the agent can only do what a tool lets it do.
The data is whatever the tools reach. Your database, your documents, the history in your ticketing system, the price list in the spreadsheet nobody has migrated yet.
The permissions are scoped per tool. An agent that needs to read a calendar gets read access to that calendar. If it should draft invoices and never send them, the send tool doesn't exist. This is the part off-the-shelf products rarely let you shape, because their permission model is built for a human user with a login.
The logs are every step the agent took, what it read, what it decided and what it wrote, stored where you can read them. When somebody asks why a customer got that message on Tuesday, the answer is in the log, and you can read it yourself.
In practice the agent runs inside an orchestration layer such as n8n, where the trigger, the approval steps and the handoffs to people are visible on a canvas your team can read. Where a step is heavy on data we write it in Python. The AI agents service page describes how we build them.
Should you build a custom AI agent or buy one?
Buy when the work starts and ends inside one product and the product already has the connectors. Build when the work crosses systems, needs write access under specific permissions, has to hold state across steps, or has to be auditable.
Here is the decision rule as a table. Score your use case honestly.
| Question | If yes | If no |
|---|---|---|
| Does the work live entirely inside one tool you already pay for? | Off the shelf, use that tool's agent | Keep going |
| Is it enough for the agent to read and draft, with a person doing the writing? | Off the shelf | Keep going |
| Does it need to write records into 2 or more of your systems? | Custom | Off the shelf might do |
| Does it need permissions narrower than "whatever the logged-in user can see"? | Custom | Off the shelf might do |
| Does a task run longer than one conversation, with waits and approvals? | Custom | Off the shelf might do |
| Do you need a log of every action, for compliance or for your own sanity? | Custom | Off the shelf might do |
| Does the process change often, in ways you want to control yourself? | Custom, you own the prompts | Off the shelf is fine |
| Is the volume real, 50 or more items a day? | Custom pays back | Off the shelf, or nothing yet |
Two "custom" answers from the middle rows and you're in custom territory. If every answer lands on off the shelf, buy the seats today and come back in 6 months when your team has found the wall.
My own rule is shorter: if the sentence describing the work contains the name of a system the vendor never heard of, it's custom.
How is each option priced, and what shape does the cost take?
Off the shelf is a per-seat subscription. Every person who uses the agent is a seat, every month, whether they used it that month or not. The price is predictable, and it grows with headcount whatever the amount of work done. For a team of 8 that uses the tool daily, that shape is fine. For a process that runs 2,000 times a month without a person in the loop, per-seat makes no sense, because the agent has no seat.
A custom agent is a one-time build, then two recurring lines: model usage (per token, so per unit of work) and maintenance (someone keeping it alive when a system changes). Its cost grows with the work done, and stays flat as headcount changes. That is why it wins at volume and loses at "we'd like 5 people to have an assistant".
The line that decides most cases is maintenance. A vendor maintains their product for you, on their roadmap and their schedule. A custom agent is maintained on yours, by whoever you choose, and if you choose nobody it decays. We wrote more about this in hire vs automate, because the same question, who owns it in a year, decides both.
Which one do most companies end up with?
Both, and in a fairly consistent shape. The general assistant goes to everyone as a personal tool for drafting and summarising. The agent features inside the CRM or the helpdesk stay switched on for the things they already do well. And 1 or 2 custom agents carry the processes that cross systems and run without a person in the loop.
An example at industry level. A distributor gives the sales team a general assistant for writing and research. Their CRM's built-in agent drafts follow-ups from the deal record. The custom agent reads incoming purchase orders from email, matches them against the price list and the stock in the ERP, creates the order, and flags anything that doesn't reconcile to a person before it ships. The first two took an afternoon to switch on. The third took weeks, and does the work the other two can't reach.
The seam between them matters. The custom agent should be reachable from where people already work: a WhatsApp number, a button in the CRM, a Slack channel, an email address. If using it means opening a separate tool, adoption dies.
How does each option fail?
Off the shelf fails at the wall. The agent can summarise the ticket and can't open the order. It drafts a beautiful follow-up and someone still pastes it into the other system. The permissions are whatever the user has, so either the agent sees too much or it's too locked down to help. And the roadmap is the vendor's: the connector you need is "coming next quarter" for 3 quarters running.
Lock-in is the quieter failure. After a year the prompts, the workflows, the corrections your team made and the connector settings all live inside one product's configuration. Leaving means rebuilding.
Custom fails at ownership. The build lands, works, and 6 months later a supplier changes an invoice layout and nobody notices for a fortnight. Or the agent was built around one person's understanding of the process, that person left, and the agent is now a black box. Or scope creep: the agent that was going to read purchase orders gets asked to also handle returns, then credit notes, and becomes a system nobody can reason about.
The fix on the custom side is the same each time: one named owner on your side, a readable orchestration layer, logs, and a scope that stays small until the first one has run for a quarter.
What should you decide first?
Whether the work crosses a system boundary. Everything else follows from that one fact. If it doesn't, switch on what you already pay for and stop reading. If it does, the next question is who on your side will own the agent, and only after that is it worth talking about which model or which tools.
Our wider guide to AI agents for businesses walks through how to pick that first process.
Frequently asked questions
Is ChatGPT enough for my business, or do I need a custom agent?
ChatGPT Team or Enterprise is enough for work that starts and ends in a conversation: writing, summarising, research, answering questions from uploaded documents. You need a custom agent when the work has to read from and write to your own systems, run without a person typing, or hold state across steps. Most businesses use ChatGPT for the first kind and a custom agent for the second.
How long does it take to build a custom AI agent?
A first working version of a single-process agent usually takes a few weeks, from mapping the process to running it on real data with a person reviewing the output. Most of that time goes on the integrations and on the exceptions the process turns out to have, and much less on the model.
Does a custom agent lock me into one AI model?
No, and that is one of the reasons to build. The model sits behind one interface and the tools, prompts and logs are yours, so switching from one provider to another is a configuration change. Off-the-shelf products lock you into their runtime instead.
Can an off-the-shelf agent access my CRM or ERP?
Sometimes, through the vendor's connector, and usually read-only or with permissions equal to the logged-in user. If your CRM is one of the big ones and the work is drafting or looking things up, that is often enough. If the agent has to write records, work across two systems, or act under narrower permissions than a user has, a custom agent is the reliable route.
Who maintains a custom AI agent after it's built?
Whoever you decide, and you should decide before the build. Often it's a mix: someone on your team owns the rules and the prompts through a readable orchestration layer, and the builder handles changes to the code when a system's API shifts. An agent with no named owner stops working within months.
Can I start with off the shelf and move to custom later?
Yes, and it's usually the right order. Use the general assistant and your tools' built-in agents until your team can point at the exact wall they hit. That wall is the spec for the custom agent, and it will be a far better spec than anything written before the team had used AI daily.
Next step
If you can describe the work in two sentences and name the systems it touches, we can tell you in one conversation whether it's off the shelf, custom, or the usual mix. Talk to us and bring the process itself.