AI Agent or Custom Software? Ask What It’s Standing In For

• An AI agent earns its place in one situation: the input is messy, but your team already agrees what the right outcome looks like.

• It can’t stand in for the things that are usually missing: one place the data lives, rules someone wrote down, and a named person who owns the result.

• You have four options, not two. Fix the process, switch on automation in tools you already pay for, build conventional software, or put AI on one step.

• Most workflows that get pitched an agent end up as a mix, and the AI part is usually the smallest piece.

• Before anyone quotes you, take ten recent cases and write down the right outcome for each. If your own people disagree, no agent will settle it for you.

You’ve got a workflow that eats your team’s week, and someone keeps telling you an AI agent will fix it. Maybe it’s a vendor with a polished demo. Maybe it’s your own leadership team, who’ve read that every competitor has one. Either way, the pitch is attractive: no requirements document, no long build, a monthly subscription and something working by next quarter.

Set against that, custom software sounds slow and expensive. So the choice gets framed as AI agent or custom software, quick and flexible against slow and certain. That framing skips the question that actually decides it: what is the agent being asked to cover for?

The pressure is real, and it’s recent. In Statistics Canada’s second-quarter 2026 analysis, 19.2% of Canadian businesses reported using AI to produce goods or deliver services over the previous year, triple the 6.1% it measured two years earlier. When adoption moves that fast, “we should have an agent” starts to feel like a plan. It isn’t one yet.

An agent is good at a narrow, real job. It’s bad at quietly replacing a system you don’t have, rules nobody wrote down, or an owner nobody appointed. Point it at one of those and it doesn’t close the gap. It hides the gap behind fluent output. It’s the argument in why legacy companies fall behind in the AI era, applied to one workflow: AI amplifies whatever is already there.

Here’s the honest case for an agent. Ordinary software follows steps someone wrote in advance. An agent uses a language model to decide what to do next, so it can cope with input nobody anticipated: a rambling customer email, a scanned form in a layout you haven’t seen, a request that bundles three questions into one.

OpenAI’s practical guide to building agents names three situations where that’s worth it: decisions that involve nuanced judgment and exceptions, rulesets that have grown so intricate they’re costly to maintain, and work that depends on reading natural language or documents. Then it adds the line most sales pitches leave out: “Otherwise, a deterministic solution may suffice.” Deterministic here means software that does the same thing every time it sees the same input.

Anthropic’s guide to building effective agents, published in December 2024, is blunter. It recommends “finding the simplest solution possible, and only increasing complexity when needed,” and says that might mean not building agentic systems at all. It also notes that agentic systems “often trade latency and cost for better task performance.” Both companies make money when you use agents. Both tell you to make sure you need one first.

Look closely at OpenAI’s second criterion, because it’s the one that gets stretched. Rules that are written down but sprawling are a fair reason to try a model. Rules that were never written down are a different problem. If the logic lives in the head of the one person who has done the job for nine years, an agent won’t learn it. It will guess, plausibly, and you won’t see which guess it made until a customer does.

The pitch frames it as two options. In practice a workflow problem has four answers, and they aren’t mutually exclusive.

The order matters more than the choice. Each option assumes the one above it is done. Automation assumes a settled process. Custom software assumes you know which rules it should enforce. An agent assumes there’s a reliable place to read from and write to, and a clear picture of what correct looks like. Most of what gets sold as an agent project is really a gap in one of the first three rows.

That’s why the answer is usually a mix: a system of record holds the data, ordinary automation moves it, and a model handles the one step where someone currently has to read and interpret.

You don’t need a technical background to work out which row you’re in. You need ten recent, real cases from the workflow: the last ten customer requests, supplier invoices or intake forms, whatever it handles. Not hand-picked ones. The last ten.

If you haven’t mapped the workflow at all, start there. The three-step plan for upgrading how your business works walks through mapping one. Then give the ten cases to two people who handle this work and have each write down, separately:

• What came in. The actual input, in whatever messy form it arrived.

• The right outcome. What should have happened, not what did.

• Where they looked. Every system, spreadsheet, inbox or colleague they checked to get there.

• The rule they used. In one sentence. “It depends” is also an answer.

• The cost of getting it wrong. A mildly annoyed customer, a wrong invoice, an access change, a legal record.

Then put the two sheets side by side and read them like this:

• They disagree on the right outcome. Fix the process first. An agent working this workflow would land on one of their answers, and you wouldn’t know which.

• They agree, and the rule fits in a sentence. That’s ordinary automation or conventional software. An agent here is a slower, more expensive way to apply a simple rule.

• They agree, but checked three places to get there. You have a data problem. An agent reading three systems inherits every disagreement between them. Connecting or consolidating the data is the project.

• They agree, the outcome is checkable, but reading the input took judgment. That’s the step where AI earns its place.

• Getting it wrong costs money, access or a legal record. A person approves that step, whatever you build.

Ten cases won’t give you statistics. They give you something more useful at this stage: evidence of which kind of problem you have, in your own team’s words.

This example is fictional. It describes no Rigoris client, and the case counts are invented to show the method.

A 60-person plumbing and heating company gets an inbox full of customer emails every day. A vendor proposes an agent that reads each one and either replies or creates a job. The operations manager runs the ten-case test first.

Six of the ten emails ask where a technician is or when a job will be finished. Both dispatchers give the same answer for all six, but each had to check the scheduling tool, a shared spreadsheet and a text thread with the technician, because the schedule in the tool is rarely current. Two emails are billing disputes, and the dispatchers resolve them differently, because there’s no written policy on when a return visit is free. The last two are new requests with a photo and a rambling description, and both dispatchers agree on the job type once they’ve read them.

So the inbox splits three ways. The status questions are a data problem: the schedule needs to be the one place technicians update, and then a customer status page or an automatic text answers most of those emails with no AI at all. The billing disputes are a process problem: someone writes the return-visit policy. The new requests are the genuine interpretation step, and an AI that drafts the job for a dispatcher to confirm is a sensible fit.

The agent didn’t disappear from the plan. It shrank to the one step it was good at, and the bigger project turned out to be the schedule.

Suppose the test points at a genuine AI step. It’s still not a subscription you switch on and forget. The model underneath can be updated by its provider, the documents it reads can change format, and the cases it handles will drift. Someone in your business has to notice when its answers get worse.

Ask whoever is proposing it four questions before you agree to anything:

• Which system does it read from and write to, and which one wins when they disagree?

• What does it do with a case it can’t place, and who sees that case next?

• How will we know it’s getting worse before a customer tells us?

• Who owns it after go-live, on your side and on ours?

If the answers are vague, the agent is being sold as a shortcut past the first three rows of the table, not as a tool for the fourth. This is how we approach AI work ourselves: the workflow first, then whether a model belongs in it at all. Our AI workflow automation page covers how we draw the line between what a model may suggest and what the system is allowed to do.

A demo shows you an agent handling the cases the vendor chose. The ten-case test shows you the cases your business actually gets.

Pull the last ten this week. Give them to the two people who handle the work most, and ask each to write down the right outcome without talking to the other. Where they agree and the input was hard to read, you’ve found work for AI. Where they disagree, you’ve found the real project, and it’s cheaper to settle now than after someone has automated it.