How to Choose an AI Agent for Your Business

Choose an AI agent by starting with the job, not the tool. Pick one process where a person currently reads something messy and decides, confirm that a plain rule could not do the same job, then decide whether to buy a product, rent a platform or have one built. Judge the supplier on proof, ownership and what the agent does when it cannot finish. The right agent is the smallest one that removes measurable hours.

The reason this is hard is that everything is now called an agent. A chatbot with a knowledge base, a scheduled script that calls a language model, a full system that reads your inbox and updates your CRM: all three are sold under the same word, at prices that range from a monthly subscription to a five-figure build. The demo looks the same in every case. The failure modes do not. Most businesses that come to us have already been pitched the most expensive form for a job one of the cheaper forms would have covered. This post is the decision we walk through with them, written down so you can run it before you take a meeting.

What are you actually choosing when you choose an AI agent?

Four things, in this order: the job the agent does, the form it takes, who builds and maintains it, and the controls that sit around it. The model it runs on comes a distant fifth. Buyers tend to start with the model because that is what the marketing leads with, and it is the one decision that matters least, because the model is the easiest part to swap later.

The job decision is where the money is made or lost. An agent earns its keep on one narrow, repeated task where the input is messy enough that a person currently has to read it and decide. If the task can be described as a fixed rule, it is not agent work, and putting an agent on it buys you a slower, dearer and less predictable version of a script. We have written up the three ways to automate a process because getting this first decision wrong is the most expensive mistake available.

The form decision is buy, rent or build. A product does one job the same way for thousands of businesses. A platform gives you the parts and expects someone on your side to assemble and own them. A build encodes your exact process into your exact systems. Each has a natural home, covered below.

The supplier decision only starts once the first two are settled, because the right supplier for a product is the vendor, the right supplier for a platform is whoever will own it internally, and the right supplier for a build is an agency or a developer you can hold to a scope. Choosing the supplier first and letting them pick the job is how businesses end up with an agent that demos well and does nothing for the P&L.

The controls decision is the one nobody puts on the slide, and it is the one that decides whether the agent is still running in a year. An agent is not a better automation. It is a different tool with a different failure mode: a rule that breaks stops, while an agent that goes wrong produces fluent output that looks exactly like every other day’s output. The controls are whatever turns that silent failure into a visible one.

Which job should the agent get first?

Give the agent one job where a person reads unstructured input and makes a routine decision, at a volume high enough to measure. Routing incoming enquiries, pulling fields off documents that arrive in a different layout every time, drafting a reply with the details already filled in, and chasing what has not come back are the usual candidates. Each is a few hours a week, and each is countable before and after.

The test for whether a job belongs to an agent at all is whether a rule could do it. Reading an email and deciding whether it is a quote request, a complaint or spam is judgement, and judgement is agent work. Moving the resulting record from one system to another on fixed rules is automation work, and it should stay deterministic because that is what makes it predictable. Most real projects need both, and the mistake is putting the agent on the second half because the agent was what got sold.

The engineering advice from the people who build the underlying models points the same way. Anthropic, having worked with dozens of teams building agents, is direct about where to start:

“When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all. Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense.”

Anthropic, Building effective agents (Anthropic)

That trade is the whole decision in one sentence. An agent costs more per task and takes longer per task than a rule. It is worth paying that price only where the rule cannot do the job. If you are not sure which of your processes clear that bar, what an AI agent can actually do for a business walks through the jobs that do, and where the hours come back.

One more thing about the job: pick the one you can measure, not the one that sounds most impressive. “Handle customer service” is a strategy. “Classify and route the 400 enquiries a month that currently take someone an hour a day” is a job. The second one can be priced, built, checked and reported on. The first cannot, and a supplier who accepts it as a brief is telling you something about how they scope.

Should you buy a product, rent a platform, or have one built?

Buy a product when the job is generic and a vendor already does it for many businesses like yours. Rent a platform when you have someone who will own it, because a platform is a kit, not a result. Have one built when the job is specific to your process and your systems, which for most small and mid-sized businesses is more often than the platform vendors suggest. Building one internally from scratch, with nobody whose job it is, is the option to avoid.

The evidence on how businesses adopt AI backs that ordering. MIT’s NANDA initiative studied enterprise generative AI deployments in 2025 and found that for 95% of companies in the dataset, generative AI implementation is falling short. The interesting part is not the headline number. It is how the successful minority got there:

“Purchasing AI tools from specialized vendors and building partnerships succeed about 67% of the time, while internal builds succeed only one-third as often.”

Sheryl Estrada, reporting the MIT NANDA findings (Fortune)

The same reporting notes that MIT found the biggest ROI in back-office automation, which is exactly the unglamorous work the first section pointed you at. Two things follow for a buyer. Partnering beats going it alone by a wide margin. And the returns sit in operations, not in the customer-facing showpiece.

Here is the practical version of the three forms:

• A product is the right choice when your job is one a vendor has already solved at scale and your process does not need to be special. Meeting transcription, a support chatbot answering questions from your help pages, invoice capture into your accounting package. You pay a subscription, you get what everyone gets, and you cannot change how it works. Fine, if what everyone gets is what you need.
• A platform is the right choice when you have a technically capable person who will own the agent as part of their job, not as a side project. The platform supplies the building blocks. Your person supplies the design, the testing, the monitoring and the fixing when the vendor changes something. Without that person, a platform subscription is a hobby that bills monthly.
• A build is the right choice when the job is specific to how your business runs: your document layouts, your systems, your rules about who approves what. A build is scoped to one measurable outcome, wired into the tools you already use, and handed over with the checks and logging that a product cannot give you because a product does not know your business. This is the form our own AI agent work takes.

A common pattern is a business on a product subscription that has outgrown it, paying per task for a generic result, and looking at a platform as the next step. The better next step is usually a build, because the thing they have outgrown is the genericness, and a platform does not fix that unless someone assembles it into something specific.

What should you ask a supplier before you hire them?

Six questions. Which of my processes would you not put an agent on? What does the agent do when it cannot finish a job? What will we measure, and what is today’s number? Who owns the code, the accounts and the data when we are done? Where does our data go? What does it cost to run each month after the build? A supplier who answers all six plainly is worth a scope. One who deflects the first two is not.

Which of my processes would you not put an agent on? This is the fastest way to find out whether the supplier is selling agents or solving problems. The honest answer names at least one of your processes and explains why a rule, a form or a spreadsheet would do it better. If the answer is that everything benefits from AI, you are talking to a vendor with one product.

What does the agent do when it cannot finish? Every agent will hit a case it cannot handle: a document it cannot read, an enquiry that fits no category, a system that is down. The question is whether it stops, flags and hands off to a person, or whether it guesses and moves on. A supplier who has built agents in production will describe the hand-off path in detail, because designing it is most of the build. A supplier who has only built demos will not have thought about it. Ask how well it handles the moment the automation hits a wall, because that moment is where the real cost of a bad agent lives.

What will we measure, and what is today’s number? The agent is being bought to move a number: hours a week, errors a month, days to invoice. The supplier should ask you for the baseline before quoting, and should be able to say how the number will be reported after go-live. If the proposal has no baseline, the result cannot be shown, and a result that cannot be shown is a result that did not happen.

Who owns it when we are done? The code, the accounts the agent runs under, the prompts, the documentation and the data it has accumulated should all be in your name, written so another developer could pick them up. Our own position is that we would rather a client stayed because the work holds up than because leaving is difficult, and any supplier should be prepared to say the same in writing.

Where does our data go? This is a compliance question before it is a technical one. Australia’s privacy regulator is explicit that choosing an AI product requires due diligence, and that the due diligence does not end at purchase:

“When looking to adopt a commercially available product, organisations should conduct due diligence to ensure the product is suitable to its intended uses. This should include considering whether the product has been tested for such uses, how human oversight can be embedded into processes, the potential privacy and security risks, as well as who will have access to personal information input or generated by the entity when using the product.”

Office of the Australian Information Commissioner, Guidance on privacy and the use of commercially available AI products (OAIC)

The same guidance adds that AI products should not be used simply because they are available, which is a regulator’s way of saying what the first section said: start with the job. A supplier should be able to tell you where the model runs, what is logged and for how long, and who at a vendor can read it. For a law firm, a medical practice or an accountant the honest answer may be that some material should not leave the building at all. We have written up what it takes to run a private AI agent for that case, and it is the reason a data question belongs in the first meeting rather than the last.

What does it cost to run? The build price is the visible number. The running cost is the model usage, the hosting, the platform subscriptions and the maintenance, and it is the number that decides whether the agent is still worth having in year two. A supplier who has run agents for clients can estimate it from your volumes. One who cannot has not done the sums on their own work.

What are the red flags?

A guaranteed outcome before any scoping, a demo in place of a validation on your own cases, no described path for when the agent fails, a pitch that leads with the model name, pricing per “AI employee” with no scope attached, and a contract you cannot leave with your own system intact. None of these makes a supplier dishonest. Each is a place to push, and the answer tells you how they work.

The guaranteed outcome is the easiest to spot. No one can promise what an agent will save you before they have seen the process, the volumes and the mess in the data. A supplier who quotes a number in the first call is quoting a number they will explain away later.

The demo-in-place-of-validation is subtler, because demos are genuinely persuasive. The check is simple: ask for the agent to be tested against a batch of your real cases, including the ugly ones, before it goes live, and ask what the pass rate was. A supplier who builds for production will already have this step in their process. IBM’s own explainer on agents names the risk that the step exists to catch:

“Agents that are unable to create a comprehensive plan or reflect on their findings, might find themselves repeatedly calling the same tools, causing infinite feedback loops.”

IBM, What are AI agents? (IBM)

That failure is not theoretical. An unchecked agent does exactly this at three in the morning when a document it cannot parse arrives, which is why a production build carries limits on how long it can run, logging of every action, and a person who is told when it stops.

The model-name pitch is the one that has grown fastest. A supplier who leads with which frontier model they use is answering a question you did not ask. The most capable model is rarely the right pick for a routing or extraction job: it is slower and dearer per call, and the difference in accuracy on a narrow, well-specified task is usually small. The right question is which model clears your accuracy bar at the lowest cost per task, and a supplier should be able to show you the comparison on your own cases.

The “AI employee” pricing is a framing problem. An agent does one job, or a small set of related jobs. Pricing it as a headcount replacement invites you to compare it with a salary, which makes almost any price look reasonable and tells you nothing about what it will actually do. Ask for the scope in jobs and volumes, and price it against the hours those jobs currently take.

What does a good first engagement look like, and what does it cost?

A good first engagement is small, scoped to one job, and measured against a baseline taken before anything is built. It starts with a short scoping pass that says where AI earns its place and where it does not, then a design you approve, then a build of weeks rather than months, validated on your real cases. AI and automation projects start at $1,990 on a fixed quote, with no hourly billing, and every project is scoped individually from there.

That is how ours runs, in five steps: scoping of a few days that ranks the jobs and rules out the rest, design, a build of one to four weeks depending on scope, validation against real cases from your business with a deliberate focus on the failure modes, and ongoing maintenance, because models and the tools around them change and a system that performs well today drifts.

Whoever you hire, the scoping step is the part to insist on. It is short, it is cheap relative to the build, and it produces the thing every later decision depends on: a ranked list of the jobs in your business where an agent would pay for itself, and an honest list of the ones where it would not. The best AI project is often smaller and sharper than the buyer expected, and it is better to learn that in week one than in month three.

The measurement is what makes the engagement honest. Every build we do is scoped around one number: hours returned, errors avoided or cost removed. The clearest example on our own site is an online retailer whose order handling now runs without anyone touching it, reporting $100,000+ saved annually in operational costs, 90% of orders fully automated end-to-end and 20+ hours saved per week on manual work (Compound Co). Most of that system needed no AI at all. The agent handles the part where a person had to read and decide; fixed rules handle the rest. That split is the point of the whole decision.

If you are weighing an agent and are not sure which form, which job or which supplier, the scoping conversation is the right place to find out, and if we are not the right fit we will tell you. You can start a conversation or see how we scope and price a build. Whichever supplier you end up with, take the six questions into the room. An agent chosen for the right job, in the right form, with the controls around it, does not add a tool to your business. It removes hours, and the hours compound.

Frequently asked questions

What is the difference between an AI agent and an automation?

An automation follows fixed rules and produces the same output for the same input every time. An AI agent uses a language model to read unstructured input, such as an email or a document, and make a judgement about what to do next. Agents suit tasks where the input is messy and a person currently has to read it. Automations suit everything with a clear rule, and they should stay rule-based because that is what makes them predictable and cheap to run.

Do I need an AI agent or just a better automation?

Ask whether the task can be written as a rule. If it can, you need an automation, and an agent would be a slower and more expensive way of doing the same thing. If the task requires reading something and deciding, such as classifying enquiries or extracting fields from documents in varying layouts, an agent is the right tool. Most real business processes need both, with the agent on the judgement step and rules on everything around it.

How much does an AI agent cost for a small business?

It depends on the form. A product is a monthly subscription. A platform is a subscription plus the time of the person who owns it. A custom build is a project fee plus running costs for model usage and hosting. At Compound Co, AI and automation projects start at $1,990 on a fixed quote and are scoped individually, and the first step is always a short scoping pass that ranks the jobs by what they would return.

Should I buy an AI agent product or have one built?

Buy a product when the job is generic and a vendor already does it well for many businesses like yours. Have one built when the job is specific to your process, your document layouts and your systems, and when you want the code, accounts and data in your own name. A platform sits between the two and only makes sense when someone on your team will own it as part of their job.

What should I ask an AI agency before signing?

Ask which of your processes they would not put an agent on, what the agent does when it cannot finish a job, what number will be measured and what it is today, who owns the code and accounts afterwards, where your data goes and who can see it, and what the agent costs to run each month after the build. Plain answers to all six are the sign of a supplier who builds for production rather than for demos.