Most AI agent projects die somewhere between the demo and the third week of production. The demo works. Everyone claps. Then it books an invoice against the wrong vendor, or emails a customer something slightly wrong, or quietly does nothing for four days because an upstream field changed. The team loses confidence, the agent gets switched off, and the conclusion is "the AI wasn't ready."
Usually the AI was fine. What was missing is everything you'd give a new hire on day one: a defined job, a boundary on what they can touch, a clear rule for when to ask for help, and someone reviewing the work for a while. We've found that if you onboard an agent the way you'd onboard a person, most of the failure modes disappear.
A prompt is not a job description
A prompt describes a task. A job description describes a role: what outcome you own, what inputs you'll receive, what you're allowed to decide alone, what you escalate, and how your work gets checked.
Write that down for the agent before you write a line of code. One page. If you can't fill it in, the process itself isn't well enough defined for a human to do consistently either — which is the real finding, and worth knowing before you spend money on automation.
The useful test: could you hand this document to a competent temp and expect a reasonable first week? If not, the agent will fail in the same places the temp would.
Scope the job to a decision, not a department
"Handle customer support" is not a job you can hand to an agent. "Read inbound emails, identify order-status questions, look up the order in the ERP, and draft a reply for review" is.
The difference is that the second version has a single decision at its center with a verifiable right answer. That's what makes it testable, reviewable, and safe to expand later. Narrow scopes also make failure cheap — when something breaks, you know exactly which step to inspect.
Start with the decision your team makes dozens of times a week and complains about. Not the strategic one. The repetitive one.
Decide what it can read, write, and spend
This is where most implementations get sloppy. An agent connected to your systems with a broad API key and write access everywhere is an intern with a company credit card and the keys to the accounting system.
Apply the same least-privilege thinking you'd apply to any user account:
- Read-only first. Let it observe and draft for a week or two before it writes anything.
- Write to draft states only. Draft invoices, unposted journal entries, unpublished records, unsent replies. In Odoo and most modern ERPs, that boundary already exists — use it.
- Cap the spend. Token budgets, rate limits, and a hard ceiling per run. Runaway loops are a real operational cost, not a theoretical one.
- Log every action with its inputs and outputs, so a human can reconstruct any decision after the fact.
None of this is exotic. It's the access control you'd already apply to a person in that seat.
Build the escalation path before the happy path
The agent's most important behavior is knowing when to stop. Define the conditions that trigger a handoff to a human, explicitly and in business terms: unknown vendor, amount above a threshold, missing purchase order, conflicting records in two systems, low confidence in the extraction, anything touching a named account.
Then make the handoff actually useful. "I need help" in a Slack channel nobody watches is not an escalation path. The agent should route the item to a specific queue, with the context it gathered, the action it was about to take, and the reason it stopped. A human should be able to resolve it in seconds without re-doing the research.
This is the part that builds trust. A team will forgive an agent that asks too often. They won't forgive one that guesses.
Review the work like you'd review a new hire
For the first stretch, sample and check output daily. Then weekly. Then monthly spot checks. Track two things: how often the agent handled the case end to end, and how often a human had to correct it — and why.
Those correction reasons are your roadmap. They tell you which edge cases to encode, which upstream data problem to fix, and when the scope is safe to widen. Skipping this step is how organizations end up with agents nobody trusts and nobody can explain.
The human is still the point
The goal isn't headcount reduction. It's giving your best people back the hours they currently spend re-keying, looking things up, and copying data between systems — and putting a repeatable structure around work that used to depend on who was in the office.
That only works when the agent sits inside your actual systems: your ERP, your CRM, your site, your ticket queue, wired together so the agent has clean data to act on and a real place to write its results. Agents don't fix fragmented systems; they expose them.
If you're weighing where an agent could genuinely help — and which processes need tightening first — we'd be glad to talk it through. Reach out and we'll walk through your workflows and tell you honestly which ones are ready.