AI that acts, not just answers
An assistant that drafts is one thing. An agent that sends the email, updates the record or raises the purchase order is another, and the question stops being whether its output is good and becomes what it is allowed to do on its own.
Most of the AI in businesses so far has been advisory. It drafts, summarises and suggests, and a person decides what happens next. The newer tools do more. They can be connected to email, the CRM, the ERP and the file store, and they can take actions: send, update, create, approve.
That is genuinely useful, and it moves the risk. When a tool only answers, a bad answer costs the time it takes someone to notice. When a tool acts, a bad action has already happened.
The question that changes
With an assistant, the question is whether its output is good enough. With an agent, the question is what it is allowed to do without a person, and what happens when it is confidently wrong.
Most of the work is permissions, not prompts. An agent acts with the access it has been given. If it runs as a user with broad rights, it can do anything that user can do, including things nobody intended it to try.
Draw the approval line by consequence
A useful way to decide is to sort the actions an agent could take by how hard they are to undo.
Reading and preparing. Gathering information, drafting a reply, filling in a form for review. Low risk, and where most of the time saved is.
Reversible changes inside the business. Updating a record, tagging an email, creating a task. Reasonable to automate once it has proven itself, with a log of what changed so it can be put back.
Anything that leaves the building or moves money. Sending an email to a customer, placing an order, paying an invoice, changing bank details, sharing a file externally. A person approves these, every time, until there is a very good reason otherwise.
Anything that changes access or security. Granting permissions, changing passwords, altering configuration. Not an agent’s job.
What good deployment looks like
Its own identity. The agent runs as its own account with its own narrow permissions, not as the person who set it up. That way you can see what it did, limit what it can do, and switch it off without switching off a person.
Least privilege, deliberately. Access to the mailbox it needs, not every mailbox. Write access to the fields it updates, not the whole system.
A full log. Every action, with what prompted it and what it changed. When something looks wrong, the log is how you find out whether the agent did it and why.
A way to stop it. A single, known switch. Someone should know where it is.
Careful with what it reads. Agents can be steered by instructions hidden in the content they process: an email, a document, a web page. An agent that reads external content and can also take actions needs the tighter approval line above, because the person instructing it may not be you.
Start narrow
The deployments that last pick one repetitive task with a clear definition of done, run it with a person approving every action, and widen its freedom only as the record shows it can be trusted. The ones that struggle start with a general agent connected to everything and try to work out the limits afterwards.
Where we sit
We build and govern this kind of automation under the same identity, logging and access rules as the rest of an environment. An agent is a new kind of user, and it should be managed like one: a clear role, only the access that role needs, and an audit trail.