How to move from a chatbot to a governed AI agent

A chatbot answers; an agent acts. The move is about the actions, not the conversation. List every action the agent will take, give each a depth and an owner, connect read-only first, certify each agent on your own past cases, and record every verdict. Keep the chatbot's scripts as a fallback until the agent has earned its depth.

What actually changes when a chatbot becomes an agent?

A chatbot's worst outcome is a wrong answer. An agent's worst outcome is a wrong action: a refund issued, an address changed, a card blocked, a payment sent. The conversation may look the same to the customer, but behind it the system now writes to your records.

That is why the question in whether an AI agent is just a chatbot with tools matters. Adding tools to a chatbot without adding bounds gives you a system that can act with no one having decided what it may do. The governance has to arrive before the tools do.

The owner also changes. A chatbot is often owned by digital or marketing, because it is part of the website. An agent that acts on accounts belongs to the operations team whose work it does, and that team should own it from the first step.

What are the steps?

1. Product owner and operations lead: inventory what the chatbot does today. Questions it answers, flows it runs, where it hands over to people, and the top reasons customers abandon it. The abandonment reasons are usually the actions customers wanted.
2. Operations lead: list the actions the agent should take, one line each: "update the customer's address", "send a statement", "block a card". Write who owns each in the business.
3. Operations lead and risk: set a starting depth for each action. Information and status: depth 1. Changes the customer could make themselves online: depth 3 eventually, depth 2 at first. Money and anything hard to undo: held, at most.
4. Agent builder: write the brief for each capability: what it does, which sources it may use, which systems it touches, and when it must stop and hand over.
5. IT: connect read-only. The agent reads accounts, cases and policies before it may change any of them.
6. Agent, depth 1 and 2: shadow. It drafts the action it would take on live conversations while people act. Compare.
7. Risk and operations: certify each agent on real past cases, scored against a floor, before it may act.
8. Operations lead: go live one capability at a time, with held actions routed to named people and every verdict recorded.
9. Operations lead: retire the chatbot flows each capability replaces, once the agent's depth has held steady through a full review cycle.

Which controls make it safe?

Depth. The agent is certified to one depth. Each action needs its own. A customer-service agent might read balances at depth 1, send statements at depth 3, and draft refunds at depth 2.

A record of every verdict. Allowed, held or refused, with the bound that decided. Chatbot transcripts show what was said; they do not show why an action was or was not taken.

Sources with provenance. The chatbot's knowledge base was often a set of web pages. An agent that changes records should rely on systems of record for facts about the customer, and treat anything the customer says as declared until checked.

Disclosure. Customers should know they are dealing with an AI system, as they should with the chatbot. What changes is that they should also know when the agent has done something, through a confirmation from the system of record.

Fast reduction. If its certificate lapses, or a run clears no depth, the agent drops to depth 1 the same day.

The wider move from trial to live service, including sign-offs and cut-over, is covered in moving an AI agent from pilot to production.

What are the signs it is going wrong?

Tools are added faster than bounds. If the development team can connect a new system to the agent without operations deciding its depth, governance is behind.

Success is still measured as containment. "Conversations handled without a person" was the chatbot's measure. For an agent, the measure is actions taken correctly. An agent that contains more conversations by taking risky actions is getting worse.

The held queue has no owner. Held actions wait for people. If no named person works the queue daily, customers wait and staff start asking for depth to be widened to make the queue go away.

Chatbot habits carry over. The old scripts promised things like "I have passed this to the team". If the agent says the same while nothing is passed, customers are misled. Every statement about an action must match what the record shows.

Internal audit hears about it last. Audit will ask how the agent is governed, and the answer should not be assembled under pressure. Brief internal audit on how AI agents are governed early, ideally before the first capability goes live.

How long should the move take?

As long as the agent takes to earn the depth each capability needs. The first capability might be live in weeks if it is routine and the systems are ready. Others will take longer, and some should never go beyond drafting. The sequence in train, shadow, certify, widen applies to the agent as a whole.

Where Pryme fits

In Pryme, the chatbot's knowledge becomes part of the agent's sources, and Agent Studio turns each action into a capability with its own brief. Attest certifies each agent on your past conversations and cases before it may act, and the minimum chain decides each action at the moment it happens.