The quickest way to sink an AI agent project is to let the agent do something wrong in front of a customer in its first week. Staff stop trusting it, managers start checking everything twice, and the tool quietly falls out of use.

The fix is not a better demo. It is a slower start. Treat the agent like a capable new hire: let it read and learn before it speaks for the company, and widen its authority only when it has earned it, on evidence you can point to.

Here is a four-stage playbook for rolling out a first agent: what it may do at each stage, what to measure before moving on, and who owns the call.

Groundwork: set the guardrails before day one

Some controls belong in place before the agent touches anything:

  • Its own accounts. Give the agent separate logins for the inbox, the accounting system and the shared drive, never a borrowed employee account. Every action is then attributed to the agent, and you can cut off its access without locking out a person.
  • Least privilege. Grant only what the current stage needs; at first, read access alone. The OWASP guidance on "excessive agency" makes the same case: give an agent only the permissions the task needs, enforce limits in the systems themselves rather than trusting the model, and have a person approve high-impact actions.
  • An audit log. Record what the agent read, what it proposed, who approved it and what it changed. If you can't quickly answer "why did this happen?", you aren't ready to let it act.
  • A kill switch. A named person should be able to pause the agent at once, by disabling its accounts or dropping it back to draft-only, without calling a developer. Test it before launch.

Stage 1: read-only

What the agent may do: look things up and draft. It can search your policies, price lists, past tickets and contracts, answer staff questions, and prepare a reply or a quote. It cannot send, save, approve or change anything.

In a support inbox, the agent drafts a suggested reply to each email, and staff use it, edit it or ignore it. For invoice matching, it pairs each supplier invoice with its likely purchase order and receiving record and flags mismatches, but nothing in the books moves.

This stage often exposes gaps in your own information, such as out-of-date price sheets, conflicting policies and knowledge that lives in one person's head. Those are worth fixing anyway.

What you measure before moving on:

  • Accuracy on real cases, not test questions. Have someone who knows the work grade a sample of drafts as right, fixable or wrong.
  • How often, and how heavily, people edit drafts. Light touch-ups are a good sign. Full rewrites mean the agent is missing knowledge or context.
  • What it does when it doesn't know. Admitting a gap beats guessing with confidence.

Who owns it: the lead for that process, such as the support manager or the controller. They, not IT or the vendor, decide when drafts are good enough.

Stage 2: suggest and approve

What the agent may do: prepare a complete action and wait for a person to approve it with one click. The reply sits ready to send, the quote waits as a draft in your quoting tool, the invoice match is staged for posting. Nothing happens until someone clicks approve, and the approver's name goes in the log.

Approval must be fast and sit where people already work, or they will route around it.

What you measure: approvals without edits, reasons for rejections, and escalations, both where the agent rightly said "this needs a person" and where it should have but didn't. Sort rejections by type to see which kinds of work the agent handles cleanly and which it keeps getting wrong.

Who owns it: the same process owner, with approvers as the front line who will notice first when quality slips.

Stage 3: act within limits

What the agent may do: carry out specific low-risk, well-tested actions without waiting for approval, inside hard limits. Everything else stays at stage 2.

Good candidates are narrow and reversible: answering "where is my order?" with tracking details from your system, or posting an invoice that matches its purchase order and receiving record exactly and falls under a cap you set. Poor candidates are anything that commits the company, such as discounts, refunds, credit terms or a quote with non-standard pricing. Those can stay at stage 2 for good.

Every automatic action needs:

  • Caps on amounts, daily volume and who the agent may contact, enforced in the systems themselves, not only in the agent's instructions.
  • Logs of what it did and why, which someone actually reads.
  • An easy undo (recall the message, reverse the posting, reopen the ticket) that a non-technical person can use.
  • A fallback to stage 2 whenever the agent is unsure or a case falls outside the rules.

What you measure: errors found in spot checks, how often undo gets used, complaints tied to agent actions, and missed escalations.

Who owns it: the process owner stays accountable. A named operator watches the logs and holds the kill switch.

Stage 4: review and widen

Put a recurring review in the calendar. The process owner looks at the measures and a sample of logged actions, then decides, task by task, whether to widen, hold or pull back.

Widening should be boring. Move one task type up one stage, not the whole agent. Each newly connected system, such as your CRM, starts again at read-only, even if the agent acts alone elsewhere.

Pulling back should be just as normal. If accuracy slips after a price change or a new product line, drop the affected tasks to suggest-and-approve until the information is fixed. That is the system working as designed.

At 2MDA.AI we follow this order, and we pair it with a central company knowledge base, because an agent can only be as accurate as what it reads.

How to talk to staff about it

Staff will judge the agent less by what it can do than by what they think it is for. If they suspect it is there to watch them or replace them, they will find reasons it doesn't work.

  • Say what it is for, plainly. "It drafts the routine replies so you have more time for the hard tickets" lands better than a slide about transformation.
  • Be clear about what is logged. The audit log records the agent's actions and who approved them. Say so, and say what it won't be used for: edit rates exist to improve the agent, not to grade people.
  • Check your obligations. In Ontario, employers with 25 or more employees must have a written policy on electronic monitoring of employees. If approval logs or usage data could be used to monitor staff, make sure that policy covers it. For federally regulated employers, the Privacy Commissioner's workplace guidance calls for monitoring that is reasonable, proportionate and minimally intrusive, a sensible test for everyone else too.
  • Give staff the controls. Approvers are the ones who make the agent better. Make it easy to flag a bad answer, and tell people what changed because of their flags.

Takeaway

An agent earns trust the way a new colleague does: by being right, visibly, on real work, before getting more authority. Start read-only, move to one-click approval, let it act alone only on narrow, capped, reversible tasks, and review regularly. Give it its own accounts, the least access it needs, a complete log and an off switch. Go slower at the start, and you can go further later.