The word "agent" is being applied to three different things, and the confusion is expensive. A chatbot answers. A workflow automation executes a path you defined. An agent decides its own next step and acts on your systems — and that last property is the whole of the opportunity and the whole of the risk.
The distinction that matters
| Chatbot | Workflow automation | Agent | |
|---|---|---|---|
| Decides the path | No | No — you did | Yes |
| Uses tools / systems | Rarely | Yes, fixed set | Yes, chooses which |
| Runs multiple steps | No | Yes, fixed sequence | Yes, variable sequence |
| Fails | Visibly | Loudly | Quietly, and plausibly |
| Right when | Questions repeat | The path is known | The path varies per case |
Read the last two rows carefully. If your process always follows the same steps, an agent is the wrong tool — you want a workflow automation, which is cheaper, faster, auditable and cannot invent a step. Agents earn their cost only where the sequence genuinely differs case by case.
What agents do well today
Four patterns hold up in production in small firms:
1. Multi-source gathering before a human decision
"Prepare the credit review for this customer": pull payment history from the accounting system, open orders from the sales table, the dispute log, and the last three months of correspondence, then produce a one-page brief. The agent decides what to fetch and in what order; the human decides the outcome.
2. Exception handling with a variable path
A delivery is short-shipped. Depending on the item, customer and cause, the right response may be a replacement, a credit note, a supplier claim, or a call. An agent can read the case, choose the path, prepare the documents and route to an approver.
3. Long-running follow-through
Chasing an outcome across days and channels — a quote, a claim, a permit, an overdue payment — deciding at each point whether to wait, escalate or change channel. This is where agents genuinely outperform both humans (who forget) and fixed automations (which cannot adapt).
4. Research and document assembly
Reading a tender pack, cross-referencing your capability statements and past submissions, and assembling a compliance matrix with gaps flagged.
What agents cannot do — and will confidently appear to do
- Operate on data you do not have. An agent cannot tell you your true cost per unit if that number lives in three disagreeing places. It will produce an answer anyway. That is the failure mode.
- Make decisions with legal or safety consequence. Statutory filings, safety certification, employment decisions, credit approval. Draft: yes. Decide: no.
- Replace a process you have never defined. If two of your staff would handle a case differently and neither is wrong, the agent will pick one at random and you will discover it in a customer complaint.
- Do arithmetic you should be doing in a database. Matching payments to invoices is a join. Sending it to a language model adds cost, latency and error.
- Be trusted without a log. If you cannot reconstruct why it did what it did, you cannot use it anywhere that matters.
The failure mode you must design against
A chatbot fails visibly — it gives a wrong answer, a user notices, trust adjusts. An agent fails quietly: it takes a reasonable-looking action, in the right format, at the right time, that happens to be wrong. It sends a well-written follow-up to a customer whose account is in dispute. It marks a job complete because a document existed. It orders against a supplier you stopped using in March.
Nothing in the output looks abnormal. This is why the engineering effort in a working agent deployment goes into constraints, not capability.
The five guardrails
- Read-only first. Run the agent for two to four weeks with no write access at all. It proposes; a person executes. You will find the errors in this phase, and they will surprise you.
- Approval gates on anything external or financial. Any message to a customer, any commitment, any payment, any record marked final passes a human. One click, but a human.
- Hard limits it cannot exceed. Maximum value per action, maximum actions per hour, allowed recipients, allowed systems. Enforce these in the surrounding code, not in the prompt — a limit stated in a prompt is a suggestion.
- A complete, readable log. Every step, every tool call, every input and output, retained. When something goes wrong at 4pm on a Friday, this is the difference between a ten-minute fix and switching the system off.
- A stop switch that a non-technical manager can reach. One button, clearly labelled, that halts everything. If only the developer can stop it, you do not control it.
How to start — an eight-week path
- Weeks 1–2: choose the right case. It must run 20+ times a month, have a genuinely variable path, have checkable output, and carry a low cost of error. Internal beats customer-facing for a first deployment.
- Weeks 3–4: write the decision rules down. On paper, as a human would follow them. If you cannot, stop — you have found a process-definition problem, and the agent would have hidden it.
- Weeks 5–6: build read-only. The agent gathers, reasons and proposes. Everything goes to a queue for a person. Measure agreement rate: what proportion of its proposals does the reviewer accept unchanged?
- Week 7: review the log, not the demo. Read fifty runs end to end. Look specifically for confident errors. Fix the constraints, not the prompt.
- Week 8: grant write access to the lowest-risk action only — internal status update, draft created, task assigned. Keep the approval gate on everything external for at least another month.
What it costs
For an SME, a first agent on a well-defined internal case is typically KES 250,000–700,000 to build, plus KES 15,000–40,000 a month to run, including the model usage and the person who reviews the queue. Budget 15–20% of build cost annually for maintenance: agents are more sensitive than fixed automations to changes in the systems around them.
Two cost traps. First, model usage scales with retries, and an agent that loops on a hard case can burn a week's budget in an afternoon — cap it. Second, the review queue is a permanent running cost, not a temporary one. If your business case assumes the queue goes to zero, the business case is wrong.
The honest summary
Agents are the right tool for a narrower set of problems than the current enthusiasm suggests — cases where the path genuinely varies, the data already exists in a readable form, and the output can be checked cheaply. Within that set they do things no previous automation could. Outside it, they are an expensive and less predictable way to do what a rule would have done.
Start read-only, on something internal, with a log you actually read. The firms getting value from agents in 2026 are not the ones that deployed fastest. They are the ones that constrained them properly before they were allowed to touch anything.
