There is a moment in almost every enterprise AI rollout where the demo stops working. Not the demo on stage. The one three weeks later, when the agent meets the actual company.
In the demo, the model answered beautifully because someone curated its world: one document, one question, one happy path. In the company, the same model inherits everything at once. Four systems that disagree with each other. Files with three versions of the truth. An approval chain nobody wrote down. Exceptions that live in someone's inbox.
The model does what models do with ambiguity. It guesses. Confidently.
The failure is structural, not technical
The instinct is to blame the model and wait for a smarter one. But a smarter model inheriting the same unbounded mess produces more convincing guesses, which is worse. The failure is structural: the work was never defined as a surface the agent could operate on.
A real workflow has a shape:
- Entities that exist whether or not anyone is looking at them.
- States those entities move through, and transitions that are allowed or forbidden.
- Owners who answer for specific decisions.
- Files and messages that belong to one piece of work and not another.
- Approval gates that are supposed to block, not decorate.
When none of that is explicit, the company runs on shared memory and goodwill. People absorb the ambiguity. An agent cannot. It fills the gaps with statistics.
"More context" is the wrong direction
The common fix is to feed the model more: more documents, more history, more integrations. This assumes the problem is missing information. It usually is not. The problem is undifferentiated information.
A buyer evaluating one supplier response does not need the other supplier's offer in scope. A reviewer approving an exception does not need the whole exception history of the company. Giving the model everything does not make it informed. It makes it unaccountable, because no one can say what it should have ignored.
The question is never how much context the model can hold. It is who decided what belongs inside.
The boundary comes first
The work that matters happens before the agent shows up: deciding what one unit of work contains. Its entities. Its states. Who approves what, and what a rejection means. Which files are evidence and which are noise. What the agent is allowed to write, and what it can only propose.
Once that boundary exists, several things stop being mysterious:
- The agent's suggestions can be tied to the record, message, or file that supports them, because the set of admissible evidence is finite.
- Review stops being a vibe and becomes a gate: a specific person accepts or rejects a specific action, and the workflow actually waits.
- Failure gets legible. When the agent is wrong, you can see which part of the boundary was wrong, and fix the model of the work instead of prompting harder.
None of this limits what AI can do. It limits what it can do unsupervised, which is the condition for letting it do anything at all in an operation that has consequences.
What to look at in your own operation
If you suspect your workflow would break an agent, you do not need a pilot to find out. Look at three things:
- Can you name the owner of the process, the one who answers when it goes wrong? If the answer has the word "depends" in it, an agent will inherit that ambiguity.
- Does the data of the process live in one place with one shape, or in exports, threads, and spreadsheets that disagree?
- When something needs approval today, does anything actually stop until it is approved?
Companies where those answers are uncomfortable are not bad candidates for AI. They are normal. But the order of operations matters: the boundary has to exist before the agent does. Build it the other way around and you get the three-week demo, again.