Most companies treat agentic AI as an engineering problem. Pick the model, tune the retrieval, wire up the tools, ship it. Then the pilot stalls. Usage fades after a few weeks, teams drift back to their spreadsheets, and leadership decides the technology isn’t ready yet.
Usually, the technology is fine. The organization isn’t ready.
I’ll be honest about where I’m coming from. I’m not the person in this room who builds the best agents. I’ve spent two decades in tech, from auditing and consulting at PwC Nigeria to automation testing in server manufacturing to cloud infrastructure program management. My most recent lesson came from teaching more than 200 program managers in a global AI infrastructure supply chain organization to hand parts of their governance work to AI tools and agents. Some took to it in a week. Some never opened the tool again. The difference had almost nothing to do with the agent.
That’s the gap this session is about: whether people know when to delegate to an agent, how to check what it gives back, and how to rebuild their work around it. I’ll share what worked, what didn’t, and the agent-assisted systems we built to replace manual enrollment tracking, stakeholder updates, and reporting.
I’ll also walk through a measurement framework adapted from the Kirkpatrick Model of training evaluation. It tracks AI adoption at four levels: reaction, capability, behavior change, and business results. Most organizations stop at the first one. They count logins and course completions and call it adoption. Very few ever prove the fourth.
You’ll leave with:
A quick way to tell whether a stalled agent project has an architecture problem or an adoption problem
A four-level framework for checking whether agents are changing how work gets done, not just getting opened
A function-by-function approach to redesigning workflows around agents
Practical guidance for leaders building AI fluency in non-technical teams, and for anyone who wants to be the person who makes agents actually work