The demos are genuinely impressive. An agent that researches a vendor, drafts the RFP, routes it for approval, and follows up on outstanding responses — without a human touching it between steps. You watch it run and you think: this is the thing we've been waiting for. Then you try to deploy it inside a real organization and something goes wrong on day three that nobody anticipated, and suddenly you're in a very familiar conversation about scope and timelines and whether the vendor oversold the capability.
The vendor didn't oversell the capability. The capability is real. What nobody sold you — because nobody could — was the org.
The agent needs to understand what you actually do
Agentic AI isn't a chatbot with better memory. It takes actions. It makes decisions across systems. It operates inside processes that were designed by specific people, for specific reasons, at a specific moment in time — and then evolved organically for years in ways that no one fully documented. The agent doesn't care about any of that. It follows the logic it was given and executes faithfully against it.
The problem is that the logic it was given was written by people who were in a hurry, working from their best understanding of how the process works — which is almost never the same as how the process actually works. The gap between the two is where agentic deployments go sideways.
I watched this play out in more ways than I can count — both when I was an executive running IT operations inside a multinational BPO and when I was an advisor to senior leadership at a Fortune 100 financial institution. Every time, the pattern was the same: we were implementing a new technical solution or workflow automation, the automation did exactly what the rules said it should do, and every time there was a tribal-knowledge edge case or an unwritten organizational constraint that created a failure scenario large enough to derail the entire implementation. That's just as true with agentic AI as it was with old-school RPA. The difference is that with RPA, the fix was a logic adjustment — you found the missing branch, you added the rule. With agentic AI, the fix is a mindset shift. The system is capable of handling the edge case. The organization has to become capable of describing it.
Permissions are the real architecture problem
Every conversation about agentic AI eventually becomes a conversation about permissions, and most organizations are not ready for it. Not because their security teams are obstructionist — though that's the story the implementation teams tell — but because nobody has ever needed to answer the question this precisely before.
When a human does the work, permissions are loosely defined and socially enforced. Marcus in procurement knows he can approve anything under $50K but he calls Sarah for anything involving a vendor they've had problems with, because that's just how things work here. The agent doesn't know that. The agent has whatever the RBAC policy says Marcus has, and it will use every bit of it, because that's what it was told to do.
Operationalizing an agent means translating that informal permission landscape — the one that lives entirely in people's heads and in unwritten organizational norms — into something explicit enough that a system can act on it reliably. That's not a technical project. It's an organizational archaeology project. It takes time. It requires the people who actually do the work, not the people who manage them, explaining how decisions actually get made. And it requires leadership that's willing to sit with the discomfort of discovering that some of their processes have been running on institutional improvisation for longer than anyone realized.
The agent will do exactly what you describe. The hard part is describing it accurately.
Speed is not the advantage you think it is
There's enormous pressure — from boards, from operating partners, from CEOs who watched a competitor announce something — to get agentic capabilities into production fast. The argument is usually framed as competitive: every quarter you wait is a quarter someone else is getting the efficiency gains. That framing isn't wrong, but it's incomplete in a way that causes real damage.
The failure mode isn't a failed deployment. It's a deployment that appears to succeed for sixty days, generates a case study, and then quietly produces a category of error that takes another six months to identify and unwind. That outcome is worse than a slower, better-understood rollout, both operationally and organizationally. Because the second failure — the one that happens after the announcement — creates scar tissue that makes the next initiative harder. The people who warned that things were moving too fast don't say anything in the post-mortem. They just become immovable in the next conversation about moving quickly.
The organizations I've seen handle this well share one orientation: they treated the context-gathering phase as the actual work, not as overhead to clear before the real work began. They mapped the process in detail before they modeled it. They ran human-in-the-loop structures — where the agent requests explicit permission from a human before taking an action — until that action had been performed enough times without correction that it could safely be granted autonomy. They involved the people doing the work, not just the people describing the work. None of that is glamorous. None of it shows up in a vendor roadshow. All of it is why it worked.
The workforce question doesn't go away if you don't answer it
Agentic AI is displacing work. Not job titles — work. Tasks that a person was doing on Tuesday are tasks an agent is doing on Wednesday, and the person is now doing something else, or they're being asked to do more, or they're quietly wondering what the arc looks like from here. Avoiding that conversation doesn't make it not happening. It just means the people closest to the deployment are carrying it alone, and that creates exactly the kind of quiet organizational resistance that kills the next rollout.
The technical implementation is the easy part. The algorithm is mature. The integrations are solvable. What takes real time — and can't be accelerated without cost — is understanding, precisely enough to act on it, what you're actually asking the agent to do, inside a real organization with real history and real people who are paying attention to what this means for them.
Before you scope the next agentic initiative, ask the people doing the work today to walk you through every exception they handle in a week. Every workaround. Every time they pick up the phone instead of following the documented process. That list is your real requirements document. But don't stop there, because the list is never complete — the organization keeps evolving after you've deployed.
What you can do is put a human directly in the path of the agent's operation. Let the agent request permission before it acts. Let the people who know the exceptions catch them in real time, not in a post-mortem. The agent learns from each correction. The edge cases get handled organically, the same way they were before — except now the system is absorbing them rather than depending on tribal knowledge that walks out the door when someone leaves. When the agent has earned enough autonomy to operate without supervision, the human moves on to the next process that needs training. That's not a workaround for insufficient documentation. That's the model.