On a Friday afternoon, the operations team gets twenty similar incidents: duplicate orders, stock that does not reconcile and several customers waiting for answers. Someone suggests “putting in an AI agent” to classify cases, draft replies and open tasks in the ERP. The idea sounds reasonable until the important question appears: who decides what the agent may do, and what it must never do?
Operational AI does not fail because it lacks intelligence; it fails when a company asks it to solve a process the company has not governed.
My thesis is simple: an AI agent for operations only deserves production if it reduces friction without introducing ambiguity. If your process is already fragile, automating fragility only makes the error move faster.
The real problem is not “using AI”, it is delegating decisions without design
In a mid-sized business, an AI agent can be useful for narrow, repetitive tasks: classifying incidents, extracting data from emails, proposing responses, flagging anomalous orders or preparing summaries for a manager. But that only works if the process has clear boundaries.
Three signs you are not ready yet:
- Teams resolve incidents differently depending on who is on shift.
- There is no stable taxonomy of reasons, statuses or priorities.
- Nobody knows which exceptions require mandatory human review.
If the agent learns from inconsistent histories, it will amplify that inconsistency. If the master data in the ERP is dirty, the agent will not fix it; it will turn it into a confident answer.
What a useful agent can actually do in operations
A well-scoped agent does not replace a person. It shortens the time between an event and the right action.
Realistic examples:
- Reads a customer email, identifies the order and suggests the incident type.
- Checks the ERP and the logistics system before drafting a reply.
- Opens a task with the minimum context needed for a human operator to act.
- Escalates automatically if it detects high amounts, sensitive returns or inventory errors.
The key is that the agent does not “decide everything”. It should behave like an assistant with limited permissions and verifiable outputs. In practice, that means:
- structured inputs
- actions allowed by case type
- logs for every step
- human review at the right thresholds
If you cannot audit why it took a route, it is not ready for production.
A realistic scenario: fewer emails, more control
Imagine a distribution company with Shopify, an ERP and email-based support. Every day it receives incidents about incomplete orders, address changes and questions about shipping status. The team takes too long to triage because the information is scattered.
A well-designed agent can do three useful things:
- Extract order, customer, warehouse and status from several systems.
- Classify the incident according to business rules.
- Draft a reply and create an internal task.
The value is not in “responding like a human”. The value is in giving the operator a reasonable proposal with consolidated context.
But even here there are limits: if the ERP and ecommerce platform disagree, the agent should not hide the mismatch with a polished answer. It should flag it.
The uncomfortable part: automating too early often makes operations worse
The controversial decision is this: sometimes it makes sense to prevent the agent from doing fewer things than it technically could.
That is uncomfortable because teams want visible efficiency. But in real operations, the cost of an autonomous mistake is often higher than the time saved. An agent that can refund, change an order or close a ticket without validation can turn a small problem into a finance, logistics and customer service incident.
Before automating an action, ask:
- Is it reversible?
- Does it have financial or regulatory impact?
- Does it depend on a rare but critical exception?
- Can we explain after the fact why it happened?
If any answer is uncomfortable, the agent should suggest, not execute.
Criteria to know whether you are ready
A serious operational agent project should start with a narrow, measurable case. Not with “AI for everything”.
I would use four criteria:
- high repetitive volume
- low risk per individual case
- reasonably accessible data
- stable business rules
And I would add three operational signals before production:
- human review rate below a reasonable threshold
- a real reduction in triage time
- zero ambiguity about who owns the final action
If the team does not trust the output, the system is not ready even if the demo is impressive.
The right question is not whether an AI agent can do the work. It is whether your operation is ready to live with an assistant that moves fast, but must stay within boundaries. At Codefuente, that is usually where we start: deciding what to automate, what to monitor and what should remain human.