The demonstration is always impressive: the agent reads the open items, decides which to chase, drafts the message and posts the follow-up. What the demonstration does not show is the question every auditor asks within a week of go-live, which is who did that, under whose authority, and how would we know if it were wrong.
An agent acting in a business system is a user, and it needs the things users have: an identity of its own rather than a shared service account, an authorisation scope that matches its job rather than the convenience of the integration, and a record of what it did that survives the conversation it did it in. Organisations that skip this are not taking a technology risk so much as a governance one — the agent works, and nobody can explain it afterwards.
Scope is where the most damage is quietly done. It is far easier to grant an agent broad access and constrain its behaviour in the prompt than to grant narrow access and extend it deliberately. The first approach produces a system whose safety depends on instructions that are not enforced anywhere; the second produces one where the limits hold even when the model behaves unexpectedly.
The trail matters as much as the scope. Every action an agent takes in a business system should carry the same evidence a human action carries: what was read, what was decided, what was changed, and which version of the agent did it. This is what allows an exception to be investigated rather than argued about, and it is also what allows the agent to be improved, because you can see the cases where it went wrong.
None of this slows down a deployment noticeably if it is decided at the start. Retrofitted after the first incident, it is a project of its own — and it arrives at the point where confidence in the whole programme is already spent.
