The conversation in most leadership teams right now goes something like this: we want to deploy agentic AI, we want to move fast, and we want to see results in the next quarter. The technology teams are excited. The vendors are ready. The roadmap is set.
What is missing from that conversation, in most organizations, is an honest accounting of the analysis work required to make agentic AI actually work.
That work is significant. And because it does not show up in the vendor demo or the architecture diagram, it tends to be underestimated until it surfaces as a problem.
The Iceberg Nobody Sees
Agentic AI looks, from the outside, like a technology project. You choose a platform, configure some agents, connect them to your systems, and watch the automation happen. The visible part of the project is the tooling.
Below the surface is a different story. Before any agentic system can operate reliably in an enterprise environment, someone has to do a substantial amount of work that has nothing to do with the technology itself.
That work includes: documenting the knowledge structures the AI will rely on, mapping every process the AI will touch and every decision it will make, defining what good looks like for each AI output, designing human oversight for the decisions that carry real risk, anticipating the exceptions and edge cases the system will encounter, redesigning the human work that happens alongside and after the AI work, and building a feedback loop so the system can be monitored and improved over time.
This is analysis work. Deep, time-consuming, stakeholder-intensive analysis work. And it is the part of an agentic AI project that most organizations do not see coming.
Now, notice I said “before this is operational”, I did not say before we start building. This analysis happens while building, collaborating, iterating, interacting, incrementing, and testing together.
Knowledge Structures: The Foundation Everything Else Depends On
Start with knowledge. An agentic AI system operates based on its understanding of the problem space it is working in. That understanding comes from the content it was trained on, plus the context you provide it through documentation, prompts, and structured data.
In an enterprise environment, the knowledge that matters is rarely well-documented. It lives in the heads of subject matter experts, in decades of informal practice, in the exceptions that everyone knows about but nobody has written down. When you try to build an agentic system on top of that undocumented knowledge, you get a system that behaves inconsistently, makes errors that seem inexplicable, and requires constant human correction.
The BA’s role here is to surface that knowledge, validate it, structure it, and translate it into a form the AI can use. This is elicitation and documentation work at its core, but it requires a level of rigor that many organizations have not invested in for years.
It also requires knowing what you do not know. One of the most important things a BA can do in the early stages of an agentic AI project is identify the gaps: the decisions the system will need to make where the organization does not yet have a clear answer for what the right outcome looks like. Some experiments and building can happen during this time, as the team is learning and structuring the knowledge.
Process Definition: More Rigorous Than You Think
Agentic AI changes processes. In some cases it eliminates steps. In others it creates new decision points, new handoffs, and new dependencies that did not exist before. The process a team has been running informally for years suddenly needs to be defined with enough precision that an AI system can navigate it.
This is harder than it sounds. Most processes, when you look at them closely, have more variation and more informal judgment than anyone realized. The rule is documented one way, but in practice people make exceptions based on context that nobody ever wrote down. The AI will not make those exceptions unless you design them in.
BAs who approach process definition for agentic AI deployments need to go deeper than they might for a traditional system implementation. The questions are different: not just what is the process, but what decisions does the process involve, what information does each decision require, what does a wrong decision look like and how consequential is it, and where in the process does a human judgment call add value that an AI cannot replicate.
Human Work Redesign: The Part Everyone Ignores
When an agentic AI takes over part of a workflow, the human work does not disappear. It changes. In some cases it becomes more supervisory. In others it becomes more exception-focused, handling the cases the AI was not designed to manage. In others it shifts upstream or downstream.
Most agentic AI projects plan carefully for the AI side of the workflow and spend almost no time designing the human side. This is a mistake. The human work that exists after AI deployment is often more complex and more cognitively demanding than the work it replaced. The people doing it need clear guidance, good tools, and a real understanding of what the AI is doing and why.
BAs are positioned to do this redesign work. Mapping the new human role, identifying the skills and information people need, and designing the handoffs between AI and human work is requirements and process work that belongs in the BA’s scope.
Risk Analysis: Not a Checkbox
Every agentic AI deployment carries risk. Some of that risk is technical. Most of it is business risk: the risk that the AI makes decisions that are wrong, biased, or outside the boundaries of what the organization intended.
Managing that risk starts with analysis. What are the most consequential decisions this system will make? What happens if those decisions are wrong? How will the organization detect a problem? Who is responsible for intervening? What is the escalation path?
These are not questions that get answered in a risk section of a project plan. They require dedicated analysis, stakeholder input, and deliberate design of the controls that will keep the system operating within acceptable boundaries.
In many organizations, nobody is doing this analysis. The technical team is focused on building the system. The business team is focused on the expected benefits. The risk that something will go wrong in production, and that nobody will catch it until it has already caused damage, is underweighted.
BAs who can do this analysis and communicate the findings clearly to leadership will be among the most valuable people in any agentic AI project.
What This Means for the BA Role
The analysis work described here is not optional. Organizations that skip it will deploy agentic AI systems that underperform, generate errors, and require expensive remediation. The analysis is what separates a reliable, trustworthy agentic deployment from one that creates as many problems as it solves.
For BAs, this is both a challenge and an opportunity. The challenge is that this work requires capabilities many BAs have not yet developed: enough AI fluency to understand what the system is doing, enough technical vocabulary to work effectively with AI teams, and enough confidence to advocate for the analysis work even when leadership wants to move fast.
The opportunity is that this work is exactly the kind of deep, strategic, human-centered analysis that AI cannot do for itself. It requires human judgment, organizational context, stakeholder relationships, and analytical rigor. It is the work that makes AI deployments trustworthy.
BAs who develop these capabilities will not be displaced by agentic AI. They will be the people organizations depend on to deploy it well.
I go deep on all of this in my Maven course series, including the specific analysis frameworks for agentic AI projects, oversight design, knowledge structure development, and human work redesign. Find me at maven.com/angela-wick.