There is a quiet line most companies cross without noticing. An AI tool goes from reading and suggesting to actually doing — updating a record, sending an email, issuing a refund, posting a journal entry. Before that line, a bad output is an inconvenience. After it, a bad output is a transaction your team has to unwind.
Most of the governance advice floating around right now is written for enterprises with legal departments and model risk committees. That's not useful if you're running a 40-person company and someone just connected an agent to your CRM. What you need is something smaller and more concrete: a job description for the agent, written before it gets a login.
A chatbot answers. An agent acts.
The distinction matters because it changes what can go wrong. A chatbot that hallucinates gives one person one wrong answer, and that person usually notices. An agent that hallucinates takes an action inside a system of record, and nobody notices until the month-end reconciliation or the angry customer call.
So the first question isn't "how accurate is the model?" It's "what happens downstream when it's wrong?" Accuracy is a property of the model. Consequence is a property of your architecture — and that part is entirely within your control.
Write the job description first
If you were hiring a contractor to do this work, you'd define the role before handing over system access. Do the same here. A usable agent job description answers five things:
- Scope: which specific tasks, on which specific records, in which systems
- Inputs: what data it's allowed to read, and what it must never touch
- Tools: the exact set of actions it can take — not "access to the CRM," but "update the notes field on open opportunities"
- Limits: thresholds it cannot cross without a human (dollar amounts, record counts, customer tiers)
- Escalation: what it does when it's unsure, and who receives that handoff
Write this in plain language on one page. If you can't fill in all five sections clearly, you don't yet understand the task well enough to automate it. That's a finding, not a failure — it usually means the underlying human process is undocumented too.
Sort actions by whether you can undo them
The most useful filter we apply isn't risk in the abstract. It's reversibility. Sort every action the agent might take into three piles.
Reversible and cheap: updating an internal note, drafting a reply that sits in a queue, tagging a record. Let the agent run these autonomously. The cost of a mistake is a few seconds of cleanup.
Reversible but visible: sending an external email, changing a quote, reassigning an owner. These need a review step at first — not forever, but until you have evidence the agent handles the edge cases. "Draft, don't send" is an underrated setting.
Irreversible or financial: issuing credits, posting to the ledger, deleting records, changing pricing. Keep a human in the loop. Not because the agent is incompetent, but because the audit trail matters more than the time you'd save.
This framing moves the conversation away from vague anxiety and toward a specific list of toggles you can actually set.
Give it its own identity
One of the most common mistakes we see: the agent runs under a shared admin account or, worse, an employee's personal credentials. Now every action it takes is indistinguishable from human activity in the logs. When something goes sideways, you can't tell who did what, and you can't revoke access without locking out a person.
Give the agent its own service account with its own permission set — scoped to exactly the objects and fields in the job description, nothing more. Every action it takes should be attributable. This single decision turns a mysterious incident into a ten-minute investigation.
The same principle applies to reversal. Before you deploy, know the answer to: "If this agent does the wrong thing 200 times overnight, how do we find and undo all 200?" If the answer involves manually clicking through records, you've scoped too broadly.
Pick a first job with a small blast radius
The instinct is to point agents at the biggest bottleneck. Resist it. Your first deployment is as much about building organizational trust as it is about saving hours.
Look for work that is high-volume, low-variance, internally visible, and easy to correct — enriching records, routing inbound requests, summarizing tickets into a standard format, flagging anomalies for review. These jobs let your team observe the agent working before it touches anything customers or auditors see. Confidence earned there is what makes the next, bigger deployment possible.
Then measure the thing that actually matters: not how many tasks it completed, but how many required rework. A high completion rate with a high correction rate is a net loss in disguise.
The governance is the product
The companies getting real value from AI agents aren't the ones with better models. They have the same models everyone else does. What they have is clear scoping, clean permissions, attributable actions, and a defined escalation path — the unglamorous infrastructure that lets them expand an agent's responsibilities without holding their breath.
That work looks a lot like the work of designing any good operating process, because that's exactly what it is. If you're standing at the line between an AI tool that suggests and one that acts, let's talk through the scoping before you cross it.