Agentic AI vs. chatbots: what actually changes when software can act

01.Answers are cheap to get wrong. Actions are not.

A chatbot's worst case is a wrong answer that a person reads and ignores. The person is the safety check. They see the answer before anything happens.

An agent's worst case is a wrong action that nobody sees: a refund issued, an order approved, a record overwritten. There is no person between the decision and the effect. So the question stops being "is the answer good?" and becomes "is the action safe?"

That is a different question, and it needs different answers. A good reply to a customer email can still be attached to a bad action, such as sending the refund to the wrong account. Reading the reply would not tell you.

Three things change when software can act.

02.1. Permissions become product design

Every agent needs a clear list of what it may read, what it may change and what it must hand to a human. Write this list before you write a prompt.

Think of it as a job description for a new junior hire. A new hire in accounts does not get admin rights on the ERP on day one. They get read access, then limited write access, then more as they earn trust. Agents deserve the same path.

In practice this means:

• A separate service account per agent, never a shared login.
• Read-only access to start.
• Write access limited to the specific records and fields the task needs.
• A list of actions that always go to a person, such as payments, deletions and messages to customers.

If you cannot write the list in one page, the agent's job is too broad. Split it.

03.2. Testing moves from answers to outcomes

With a chatbot you read replies and judge the tone and accuracy. With an agent you test whether the purchase order was approved correctly, not whether the reply sounded right.

That means test cases built from real past decisions. Pull a few hundred cases your team has already handled. Record what they decided. Run the agent on the same inputs and compare. Pay most attention to the awkward ones: missing fields, odd formats, two rules that conflict, a request that looks routine but is not.

Two habits help:

• Shadow mode first. Let the agent decide on live cases without acting. Compare its decisions with the human ones for a few weeks.
• Keep the failures. Every miss becomes a permanent test case. Over time the test set becomes the most valuable asset in the project.

04.3. Logs become your safety net

If an agent can act, every action needs a record: what it saw, what it decided and why. Without that, the first bad decision is also the first one you hear about from a customer.

A useful log entry holds the input, the rule or reasoning applied, the action taken, the system it touched and the time. It should be easy to search by order, by customer and by agent. It should also be hard to edit.

Logs do three jobs. They let you debug a wrong decision. They let a reviewer sample decisions each week. And they let you answer an auditor or a customer who asks "why did this happen?"

05.Where agents pay off first

High-volume, rule-heavy decisions with a clear right answer most of the time: invoice matching, ticket routing, approval of routine requests, data clean-up.

Leave judgement-heavy, rare and high-stakes decisions with people, and let the agent prepare the case for them. An agent that gathers the history, summarises the issue and proposes an action saves a senior person twenty minutes without taking the decision away from them.

A rough test: if a competent new starter could do the task with a one-page guide, an agent probably can too.

06.How to start

Pick one workflow. Measure how long it takes today. Automate the routine 60 to 80% of cases and route the rest to a person with full context. Prove it, then add the next workflow.

A simple first month looks like this:

• Choose one workflow with high volume and clear rules.
• Record how long it takes now and how often it goes wrong.
• Write the permission list and the escalation rules.
• Build the agent in shadow mode and compare its decisions with people.
• Switch on the low-risk cases, keep the review queue, and review a sample every week.

07.A worked example: a routine request versus an awkward one

Take an agent that approves equipment requests under a set value. A request arrives for a laptop, within budget, from a manager with the right authority, for an approved supplier. The agent checks four rules, finds all four met, approves and logs it. This takes seconds and a person never sees it.

Now a second request arrives. Same laptop, same value, but the requester is on leave and the request came from a colleague's account. Every field is valid. The agent does not know the requester is away. This is the awkward case. A rules check passes it and a careful human would pause. If your test set only contains clean requests, the agent will approve this one.

So you add a rule: requests raised on behalf of someone else go to a person. You add the case to the tests. Next time it is caught. This loop, repeated weekly, is how an agent gets better after launch. It also shows why the owner matters. Someone has to notice the pattern and decide what the rule should be.

08.Trade-offs to decide up front

• Speed against safety. A lower approval threshold means more cases handled alone and a higher chance of quiet errors. Start tight and loosen it with evidence.
• One big agent against several small ones. One agent is simpler to run. Several are easier to test and to switch off one at a time. We usually prefer several.
• Model judgement against fixed rules. Use fixed rules where the policy is clear. Use the model for reading messy text. Do not ask a model to decide what a rule already settles.

09.Common mistakes

• Starting with the hardest process. Pick a boring one. Boring processes have clear rules and plenty of examples.
• Giving the agent broad access "to make it easier". It is easier until the first incident.
• Judging by a demo. A demo shows the best case. Judge by the awkward ones.
• No owner. Someone must read the decisions and tune the rules every week.
• Skipping the kill switch. You should be able to stop an agent in minutes, without a deployment.

10.What to do next

If you already run a chatbot, you have the hard part: data access, a prompt habit and a team that has shipped something. Add one tool with read-only access and see what it would have done. Then widen the scope slowly.

Agents are not magic. They are software that makes decisions, so they need the same care as any system with write access to your business. Treat permissions, tests and logs as part of the product and the rest gets easier.

We help teams do exactly this with senior AI engineers who can join in 72 hours.