An agent is not a chatbot

A chatbot answers questions. If it answers badly, someone reads a bad answer and shrugs. An agent does more: it issues an invoice, changes an order’s status, emails a customer, books a slot. If it gets it wrong, the invoice is already with the customer.

That difference changes everything you need to think through before deploying one — and most conversations about agents are still had as if this were a better chatbot.

An agent is a new hire, not a new feature

The simplest test: would you give someone in their first week the banking password and the right to email every customer unchecked? No. They would get a narrow remit, limited permissions and someone looking over their shoulder until you trust their results.

An agent deserves exactly the same. Not because it is stupid — because it is new, and you do not yet know where it goes wrong.

Four things an agent must have

A remit. One task, described so that you can say what is in it and what is not. “Handling complaints” is too much. “Classifying new complaints and drafting replies for approval” is right for a start.

Permissions. The agent gets access only to the systems and operations its task needs. Reading is cheap, writing is expensive, sending anything outside is the most expensive of all. Grant each of these separately and deliberately.

An approval point. Where a mistake costs — money, a customer, a legal commitment — a person approves before the action leaves the company. Over time, as results hold up, the approval point moves from “every action” to “exceptions and a random sample”.

A log. Every action recorded together with what the agent saw and why it decided as it did. Without a log you cannot fix a mistake, explain a decision to a customer or answer an auditor’s question.

Why this is an argument for owning the stack

An agent that works in your systems needs access to them. If those systems are eleven SaaS products, the agent gets eleven API keys with permissions defined by the vendor, not by you. Some will not let you grant “read-only on this one table”. Some do not log who changed what through the API.

When the process and the data are yours, you draw the agent’s boundaries — at the level of operations, not “has access or does not”. That is not ideology. It is whether you can safely hand an agent anything at all.

How to start without regretting it

1. Pick a process where people today mostly retype and sort.
2. The first version of the agent sends nothing — it prepares, and a person clicks.
3. Measure how many prepared actions get approved without edits.
4. When that share is high and stable, hand the simple cases to the agent entirely and keep routing the hard ones to a person.
5. Review the log every week. The agent’s mistakes tell you where your process was unclear.

That last point is the hidden value: deploying an agent forces a company to write down how it actually works. Many teams discover that half their tribal knowledge was never written anywhere. The barbarians had rules too — they were just carved in stone, not in someone else’s terms of service.