AI Agents in the Back Office: What We Let Them Do, and What We Don’t
Photo: Gilgen Logistics AG, via Wikimedia Commons · CC BY-SA 4.0
The word "agent" has had a busy year. What it means in practice is fairly simple: an AI system that does not just answer a question but takes several steps on its own. It reads an email, looks up the customer in the ERP, checks stock, drafts a reply, and maybe updates an order. Each step on its own is ordinary. Letting software chain them together without someone watching every step is the new part.
For a back office this is genuinely useful. A lot of administrative work is exactly that kind of chain: look something up here, copy it there, check it against something else, write a message. It is also the kind of work where one wrong step, repeated a few hundred times, turns into an expensive problem.
Read, search, draft: yes
We are comfortable letting agents do almost anything that does not change the outside world. Reading incoming messages. Searching the ERP, the shared drive and previous orders. Comparing an order against a drawing. Drafting a reply, a quote or an order line. Preparing a summary for the person who has to decide.
If an agent gets one of those steps wrong, the damage is limited to a draft that someone has to correct. Annoying, not dangerous. And the time saved on the steps it gets right is real.
Send, pay, commit: not without a person
The line sits where an action becomes hard to undo. Sending an email to a customer. Confirming an order with a supplier. Changing a price in the ERP. Booking a payment. Deleting anything at all. For these, the agent prepares and a person confirms.
- The agent can draft the email. A person sends it.
- The agent can propose the purchase order, with its reasoning attached. A person releases it.
- The agent can suggest a price change. Someone with the authority to change prices approves it.
- The agent can flag a record as a likely duplicate. A person merges or deletes it.
Over time, some of these can move across the line. If a certain type of confirmation email has been approved unchanged five hundred times, it may be reasonable to let it go out automatically, with regular sampling. But that should be a deliberate decision, made by someone, based on a record of how well it has gone. Not a default.
Automation on the factory floor has always come with guards, stops and limits. Software agents need the same things. They are just harder to see.
Photo: falco, via Wikimedia Commons · CC0
Guardrails that are not optional
- Least access. The agent gets the permissions the task needs and nothing more. Read access to the ERP does not come with write access by default.
- Limits. A maximum number of actions per run, a maximum value it can touch, and a full stop when something unexpected happens.
- A complete log. Every step the agent took, what it saw, and why it did what it did. Readable by a person, not only by a developer.
- An off switch. Someone must be able to stop it quickly, and everyone should know who that someone is.
The practical question
Not "can the agent do this?", because increasingly the answer is yes. The question is "if it does this wrong a hundred times before anyone notices, what does that cost?" The answer tells you where the person needs to be.
Start narrower than you think
The temptation with agents is to hand them a big, vague job: handle the inbox, manage the orders. They do much better with a narrow, well-defined task and clear boundaries. Handle incoming requests for quotation on standard products. Prepare, do not send. Flag anything with an attachment.
That is less exciting in a demo. It is also the kind of setup that still works six months later, which in the end is the only kind worth having.