Decision matrix
Which kind of system fits your task?
The defaults describe one common case: sorting inbound customer emails and updating the right record. Change the weights to describe your own task.
1 · Set what matters to you
2 · Where your weights lean
- ChatbotPartial fit
- Rule-based automationGood fit
- Workflow with AI stepsStrong fit · leads
- AI agentGood fit
Your weights lean towards Workflow with AI steps. Your task has a fixed path and messy input. Put a model where the reading happens and keep every action on deterministic, validated steps.
3 · The matrix, cell by cell
| Criterion · your weight | Chatbot | Rule-based automation | Workflow with AI steps | AI agent |
|---|---|---|---|---|
| People ask questions and expect answersWeight: Ignore | Strong fit What it is for: a conversation that answers from your content. | Poor fit Not built for questions at all. | Partial fit Can draft a reply inside a step, but there is no open conversation. | Good fit Can answer, and can also go and look things up across tools. |
| The work starts from messy textWeight: High | Good fit Reads free text well, but only within a conversation. | Poor fit Breaks on wording it was not written for; keywords miss intent. | Strong fit Strong: a model step reads, classifies or extracts, then fixed steps act. | Strong fit Strong: reads messy input and decides what to do with it. |
| The steps are the same every timeWeight: High | Partial fit Follows a script loosely at best; it is built to converse, not to run steps. | Strong fit Ideal: the same trigger and the same steps on every run. | Strong fit Ideal: the path is fixed and only the reading is done by a model. | Partial fit Overkill: it re-plans work that could be a fixed path. |
| The steps change from case to caseWeight: Low | Partial fit Can ask a clarifying question, but does not plan multi-step work. | Poor fit Every variation has to be written as another rule. | Partial fit Handles a few known branches; open-ended variation is out of scope. | Strong fit Its real use: the next step depends on what the last one found. |
| Every run must be explainable afterwardsWeight: Medium | Good fit Transcripts show what was said; citations show where answers came from. | Strong fit Fully deterministic: the run log shows which rule fired and why. | Good fit Each model step’s input and output is logged against a fixed path. | Partial fit Harder: the path differs on every run, so traces and step limits matter. |
| It must act in other systemsWeight: High | Partial fit On its own it only talks; actions need a workflow or agent behind it. | Strong fit Strong: calls APIs, updates records and sends messages reliably. | Strong fit Strong: deterministic steps do the writing, after validation. | Strong fit Strong, within an allow-list of tools and scoped permissions. |
| A wrong action would be costlyWeight: Medium | Good fit Low risk while it only answers and hands anything consequential to a person. | Good fit Predictable, but it acts confidently on input it misread. | Good fit Validation rules and confidence thresholds can stop a misread before it acts. | Partial fit Needs human approval before any high-impact action. |
| Cost and speed per run matterWeight: Low | Good fit One or two model calls per message. | Strong fit No model calls: the cheapest and fastest option. | Good fit One model call per AI step; the rest is plain code. | Partial fit Several model calls per task, so slower and more costly per run. |
| It needs to be live soonWeight: Low | Good fit Weeks, mostly content preparation and testing. | Strong fit Often days for a simple flow. | Good fit Weeks: the path plus an evaluation of the model steps. | Partial fit Longest: tools, guardrails, approvals and a trace-based evaluation. |
Ratings are our judgement for typical designs of each kind. A well-built system of the “wrong” kind can beat a poorly built one of the “right” kind, so treat the result as a way to frame the decision.
Four kinds of system, told apart by who decides the next step
A chatbot holds a conversation. It answers from your content, asks clarifying questions and hands over to a person, but on its own it does not change anything in your systems.
Rule-based automation runs steps you wrote in advance: when this happens, do that. There is no model involved, which makes it fast, cheap and exactly repeatable, and also blind to anything it was not told to expect.
A workflow with AI steps keeps the fixed path and adds a model where reading is needed: classify this email, extract these fields, draft this reply. Anthropic’s engineering guide calls these workflows, systems where models and tools are orchestrated through predefined code paths.
An AI agent is given a goal and a set of tools, and the model decides which tool to call next based on what it has found so far. The same guide describes agents as systems where the model dynamically directs its own process and tool use, and notes that agentic systems often trade latency and cost for better task performance.
A quick test: try to write down the steps a person follows. If you can, it is workflow work, whether or not a model reads the input. If the honest answer is “it depends on what I find”, it may be agent work.
The task properties that decide it
A conversation or a job?
If someone is waiting in a chat window for an answer, you need a conversational front end. If the work arrives as an email, a form or an event and nobody is waiting live, you need a job that runs to completion. Many projects need both, joined by a handover.
How messy is the input?
Rules read structured fields perfectly and free text badly. The moment the input is an email, a scanned PDF or a WhatsApp message, a model has to do the reading. That decides whether a model is involved, not who controls the path.
Does the path change?
This is the real dividing line between a workflow and an agent. Research tasks, multi-system investigations and requests that need several lookups before anyone knows what to do suit an agent. Sorting, routing, extracting and updating usually follow the same path every time and suit a workflow.
What does a mistake cost?
The more an action costs to undo, the more the design should look like a workflow with validation, and the more any agent involved should stop for approval. OWASP names this risk excessive agency: too much functionality, too many permissions or too much autonomy, and recommends human approval for high-impact actions and authorisation enforced in the downstream system rather than by the model.
Cost and speed per run
Rules cost almost nothing per run. A workflow pays for one model call per AI step. An agent pays for every planning step and tool call, and a hard task can take many of them. At high volume, that difference decides the design on its own.
One task, four designs
A customer writes in to change the delivery address on an order. Here is what each kind of system would do.
| Design | What happens | Where it breaks |
|---|---|---|
| Chatbot | Explains how to change an address, links the form and offers a person | The customer still does the work, or waits for an agent |
| Rule-based automation | Spots the word “address”, tags a ticket and routes it to the team | Misses requests worded differently; does not make the change |
| Workflow with AI steps | Extracts the order number and new address, checks the order has not shipped, updates it, confirms by email; otherwise routes to a person | Needs a clear rule for every exception it should not handle |
| AI agent | Looks up the order, checks the carrier, decides whether to update or ask the carrier, drafts the reply for approval | More cost and more to test, for a task a workflow already covers |
Mixing them is normal
Real systems combine the four. A chatbot collects the details and hands a structured request to a workflow that makes the change. A workflow calls an agent for the one step that genuinely needs investigation, then resumes its fixed path. Rules sit in front of everything to catch the cases that need no model at all. Designing the boundaries between them is most of the engineering.
The questions we ask in discovery
- Walk us through the last few cases a person handled. Did they follow the same steps each time?
- Where does the work arrive, and is anyone waiting live for the result?
- Which systems must be read, and which must be changed?
- What is the most expensive mistake this system could make, and how would you undo it?
- Who must approve which actions today, and should that stay the same?
- How many cases a day, and how quickly must each one finish?
- What does a person do with the cases nobody can classify?
How we decide
- Write the procedure down with the people who do it today, including the exceptions.
- Mark each step as rule, model reading or judgement. Rules stay rules.
- If the path is fixed, build a workflow and put models only on the reading steps, with validation before any write.
- If a step genuinely needs investigation, scope an agent for that step alone, with an allow-list of tools, a step limit and approval on costly actions.
- Test on real past cases, compare the result with what the person did, and launch with a person reviewing until the results hold up.
When MiniAI Labs is the wrong choice
If your task is a simple trigger and action between two popular apps, you may not need anyone. A no-code tool your team configures in an afternoon costs less than our time.
If you want a general autonomous agent that runs part of your operations without review, we will not build it. We build agents with allow-lists, step limits and human approval for costly actions, and we decline designs without them.
If the systems involved have no API and no export, the first project is integration, not AI. A systems integrator who works with those platforms may be the better first hire.
Limits of this comparison
- Ratings are our judgement for typical designs; build quality can matter more than the category.
- The default weights describe one example task, email triage with a record update, and are not a recommendation for yours.
- Vendors use these words loosely; some call any chatbot an agent. This page uses the definitions in its first section.
- Voice adds constraints of its own, such as a latency budget on every turn of the call.
Sources
- Building effective agents (opens in a new tab) · Anthropic Engineering · accessed
- LLM06:2025 Excessive Agency (opens in a new tab) · OWASP Gen AI Security Project · accessed