An AI agent pilot takes a few weeks to impress. The chat responds, pulls information from the catalogue, and seems to understand the user. Then comes the moment to connect it to real orders, internal permissions, and cases nobody defined in the brief. That is where it stalls.
The model is not the problem. Today's models handle the kind of tasks a mid-size company needs to automate. The problem shows up at the edges: the customer asking for something outside the catalogue, the order stuck in an intermediate state, the refund that needs two approvals. A pilot was not designed for that. A production system was.
What breaks when the pilot meets real data
The first crack is always the same: data lives everywhere. The ERP holds financial records, the CRM holds contacts, the order platform holds history, and the ticket system holds open incidents. The pilot ran on a clean API with four endpoints. Reality has twelve systems, three date formats, and two teams that disagree on who owns each field.
The second crack is permissions. An agent that answers whatever any employee asks is useless in a company with departments separated by confidentiality rules. You need to define what each role sees, what actions the agent can execute, and where it needs human approval. This is not a technical detail. It is a business decision that nobody made during the pilot.
The third crack is edge cases. The customer returning a custom product. The order that has been in "under review" status for three days. The invoice that does not match the delivery note. These cases do not appear in the demo because the demo was built around the happy path. In production, they represent 30% of real volume.
What pilots that reach production do differently
Teams that get an agent to production share a pattern: they start small and connect real data from day one. They do not pick "an assistant for everything." They pick one concrete case with clear boundaries: a copilot for the support team that checks orders and shipping status, or a catalogue assistant for sales that looks up product specs and stock.
They connect the agent to real data, not mocks. If the pilot depends on simulated data, you are not validating the solution. You are validating an interface. Permissions get defined before deployment, not after. What each user can see, what the agent can do without approval, and what escalates to a person. This goes into a one-page document before anyone writes code.
They measure what matters. Not just response speed. They track how many queries the agent resolves without escalation, how often users correct the response, how much time it saves the human team. Without those numbers, you cannot tell if the agent works or just looks like it works.
They design for failure. When the agent does not know the answer, it transfers to a person with the full context. When an external system does not respond, it logs the error and notifies the team. It does not try to hide the gap. An agent that says "I don't know, let me transfer you" builds more trust than one that invents an answer.
At Luxion we help companies take this step without the hype: we pick the case with the best effort-to-result ratio together, build a prototype connected to real data, and show how it works before committing to a full project.