A chatbot answers questions. An agent takes actions — creates the quote, updates the vendor record, issues the credit note. That difference sounds like a technical upgrade. It isn't. It's an HR decision. The moment software can write to your ERP, you've effectively hired someone, and most companies onboard that someone worse than they'd onboard a summer intern.
The failure mode we see isn't hallucination. It's access. Somebody wires an agent to an API key that happens to have admin rights, because that's the key that was already sitting in the config file. The demo works. Then three weeks later nobody can explain why forty records changed overnight.
Start With the Task, Not the Tool
Before you pick a model or a platform, write down the job in one sentence a non-technical manager could approve. "Draft purchase orders for recurring consumables when stock falls below reorder point, and route them to the ops lead for approval." That sentence tells you everything: which systems the agent touches, which direction the data flows, where a human stays in the loop, and what the agent must never do.
If you can't write that sentence, you don't have an agent project yet. You have an exploration — which is fine, but explorations belong in a sandbox with read-only credentials, not in production with write access.
The sentence also exposes scope creep early. "And also handle non-recurring purchases" is a different job with different risk. Hire a second agent. Narrow agents are easier to test, easier to debug, and far easier to turn off when something looks wrong.
Permissions Are the Product
In a well-designed agent system, the model is maybe a quarter of the work. The rest is the boundary around it.
Think in terms of tools rather than credentials. Instead of giving an agent your ERP login, give it three specific functions: `look_up_stock_level`, `create_draft_po`, `notify_approver`. Each one does exactly one thing, validates its own inputs, and refuses anything outside its remit. The agent can't invent a fourth capability, because there isn't one to reach for.
This is where ERP platforms like Odoo help more than people expect. Mature business systems already have a user and role model, record-level rules, and an audit log — infrastructure built for exactly this problem, just designed with humans in mind. An agent should get its own user account, its own role, and its own permission set. Not a shared service account. Not the integration user that six other scripts are already using.
A few boundaries worth setting on day one:
- Value thresholds. Below a certain amount, the agent acts. Above it, a person approves.
- Volume limits. More than N actions in an hour should trigger a pause and an alert, not a faster loop.
- Reversibility. Prefer drafts, proposals, and staged changes over direct commits to live records.
- Blast radius. Scope access to the specific records the job requires, not the whole table.
Design for the Bad Day
Every agent will eventually do something wrong — misread an edge case, act on stale data, loop on a malformed response. The question isn't whether, it's how quickly you'll notice and how cheaply you'll undo it.
That means logging every action in business terms, not just technical ones. "Agent created PO-10432 for $1,240 to Vendor X at 02:14, triggered by stock level 4 against reorder point 10." An operator should be able to read that line and judge whether it was right. Model-level traces are useful for engineers; business-level logs are what let the ops lead trust the system.
It also means an obvious off switch that doesn't require a deployment. A toggle in the admin interface. A flag your ops team controls. If disabling the agent requires engineering, people will hesitate — and hesitation is how small problems become incidents.
The Review Cadence Nobody Schedules
You'd review a new hire at thirty days. Do the same here. Pull a sample of the agent's actions and have the person who owns that process grade them. Where was it right? Where was it technically correct but contextually wrong? What did it escalate that it should have handled, and what did it handle that it should have escalated?
That review is how you earn the right to widen the scope. Agents should graduate into more authority the way people do — by demonstrating judgment on a narrow task first. Companies that skip this step tend to swing between two bad outcomes: an agent with too much access and no oversight, or a pilot that never leaves the demo because nobody can get comfortable enough to switch it on.
Where to Start
Pick one task that is repetitive, rule-heavy, and currently done by someone too expensive to be doing it. Give the agent one job, three tools, a threshold, a log, and an off switch. Run it for a month with a human reviewing output. Then decide whether to widen it or kill it.
If you're weighing where agents fit alongside your ERP, your CRM, and the integrations between them — and how to do it without handing a model the keys to your whole business — that's exactly the kind of design work we do. Reach out and let's map your first one.