AI Assistant, Workflow Rule or Agent: Picking the Cheapest Thing That Works

Someone on the team says a process is painful and asks for AI. Before anyone builds anything, there is a cheaper question: does this need a model at all?

The order to work through is a workflow rule first, then an AI assistant, then an agent. A rule is the right answer whenever the task can be written as if this, then that. An assistant fits when a person is in the loop and wants help. An agent is for work that runs without a person watching each step, and it is the most expensive of the three to build, review and trust.

The three things, plainly

A workflow rule is a condition and an action. When a task is marked done, notify the owner. When a form arrives with this field set, route it to that queue. No model, no variation, no surprises. It does exactly one thing forever.

An AI assistant is a model a person asks for help. Summarise this. Draft that. Explain what this document says. The person is present, the person decides what to do with the answer, and a bad answer costs a few seconds.

An agent does a piece of work end to end. It gathers context, decides what to do, and produces something without a person at each turn. Someone reviews the result rather than the steps.

The cost goes up sharply across those three, and most of the added cost is not the tooling. It is the review, the testing, the approval design and the ongoing question of whether it is still behaving.

The decision path

Work down this list and stop at the first yes.

1. Can you write the rule in one sentence with no "usually" in it? Then it is a workflow rule. "When an invoice is over thirty days old, flag it" needs no intelligence. Adding a model here makes an occasionally wrong version of something that could be always right.

2. Does the task need language understanding but a person is already there? Then it is an assistant. Someone is writing an email and wants a draft. Someone is reading a long thread and wants the gist. The person is the safety mechanism and no design work is required to make them one.

3. Does the work need to happen when nobody is looking, and does it involve judgement across several sources? Now you are in agent territory. And the follow up question is whether the judgement is one you would let a new joiner make unsupervised. If not, the agent needs an approval step, which brings back the cost of a person.

4. Is the volume high enough to justify all of that? A task that happens four times a month rarely earns the testing and review overhead an agent needs, so work out what you would pay per approved output before deciding. Do it by hand.

Why the least clever option usually wins

A rule has properties an agent does not. It is testable in full. It behaves the same on Tuesday as it did in March. When it breaks, it breaks loudly and in one place. Nobody has to review its output because there is nothing to review.

An agent has none of that. Every output needs checking, behaviour shifts when the underlying model or the data changes, and failures are quiet: a plausible wrong answer looks like a right one.

That is not an argument against agents. It is an argument for using them where the flexibility is actually needed, and not where it just feels modern.

The common mistakes

Building an agent for a rule. The tell is that the prompt is a list of conditions. If the instructions are the logic, write the logic.

Building a rule for a judgement. The mirror error. The rule grows exceptions, then exceptions to exceptions, and after two years nobody understands the branch that fires on the fifteenth. When the exceptions outnumber the base case, the task had judgement in it all along.

Reaching for an agent because integration is hard. An agent can read a mess of systems that were never connected, which is real value. Be honest that you are paying a model to paper over an integration problem.

Skipping the assistant. Plenty of pain is a person spending twenty minutes on something a model does in one, with them still in the chair. That is the cheapest win available and it needs almost no governance, beyond the usual questions about where your prompts are stored.

Where a shared record changes the maths

Part of what makes agents expensive is that they usually have to be told everything. If project status lives in one tool, leave in another, and client history in a third, the agent needs plumbing to every one, and the plumbing is where the cost and the risk sit.

SicherOne puts project management, HR and AI agents on one set of records, which removes some of that. It also raises the separate question of whether to buy modules one at a time or all at once. And it means the boring option stays available: with the data in one place, a lot of the work people wanted an agent for turns out to be a rule and a report.

The question to ask first

Not "where could we use AI". Ask which recurring task costs the most time, then work down the list above. The most useful outcome of that conversation is often a rule nobody had bothered to write, and a saving that arrives next week rather than next quarter.