The organization that gets the most value from agentic AI  won’t be the one that has the most agents. It will be the one that rethinks how its decisions get made.

An agentic AI framework provides the structure around that work. I think of the framework as defining how an agent operates within the enterprise and the boundaries around what it can or cannot do.

In my work leading AI and machine learning at Pfizer, I’ve seen how important it is to connect these technologies to real business and scientific needs. In life sciences, where AI applications can support everything from regulatory documentation to drug discovery, selecting the right framework requires careful consideration of the intended outcome and the risks involved. 

For chief data officers (CDOs) and AI leaders, the use case and the role the agent is expected to play should guide the technology choices that follow.

Start With the Outcome in Mind

Teams can launch an agent program without being clear about the decision the agent is supposed to support or how its output will be used. Before evaluating technology, I seek clear answers to a few questions: 

• What problem are we trying to solve?
• Where does the agent fit within the existing workflow?
• Who owns the outcome?
• Where can the agent work autonomously, and where should a person remain involved?
• How will we know whether the workflow has improved?

I also recommend starting small. A few well-defined, high-value workflows give teams a chance to establish risk-based stage gates and learn where agents need more or less freedom before expanding their use.

In life sciences, I see some of the greatest acceleration today in operational work where there is a lot of data, documentation, and repeatable processes. Earlier discovery work is more complex and still depends heavily on human expertise. 

Core Components of an Agentic AI Framework

Once those questions are clear, an agentic AI framework needs to account for six core components: 

1. A clear goal: The agent needs a defined role within a larger business, operational, or scientific workflow.
2. The model layer: Different models may be better suited to different tasks. An organization may use one model for structuring unstructured data, another for scientific information, and another for higher-level reasoning.
3. Governed data and tools: Agents need controlled access to enterprise knowledge, systems, and approved tools.
4. Orchestration: The framework needs to coordinate steps, preserve context, and account for the logic and dependencies within the workflow.
5. Identity, permissions, and guardrails: The agent’s access and ability to act need clearly defined boundaries.
6. Human oversight: Experts need the ability to review important decisions and trace how an agent reached a result.

The balance among those components depends heavily on the use case. For example, an agent contributing to an assessment of a serious adverse event or clinical efficacy carries a very different level of risk than one preparing a section of a protocol or analysis plan for expert review. I would base the level of autonomy on what happens if the agent gets something wrong. 

Give the Agent Enough Context To Use the Data

Agentic AI builds on the data foundations already needed for generative AI. Enterprise data still needs to be trusted and governed, and agents need to be able to find and access it securely. But access alone doesn’t give an agent enough context to use the information correctly. 

Clinical research provides a useful example. A data point may come with important context about where and how it was collected. Lineage, provenance, relationships to other concepts, and data quality may also affect how an agent should interpret the information. 

Workflow context matters, too. In drug development, an orchestration agent needs to understand the dependencies between stages of clinical development. Access to all of the necessary tools does not teach the agent the sequence in which the work has to happen. The framework has to account for those dependencies.

For CDOs, the question is not only whether agents can access enterprise data, but whether they have the context needed to interpret it and use it appropriately within the workflow. 

Build, Buy, or Use a Hybrid Approach?

The build-versus-buy decision can change as a capability matures.

When a use case depends heavily on proprietary data, internal processes, or specialized domain expertise, an organization may need to incubate the capability internally. Over time, capabilities that were once highly specialized can become standardized enough for external platforms to support them.

Document generation is one example. Organizations once built many of those capabilities themselves. As commercial options have matured, buying or piloting an existing solution has become practical for more use cases.

For an established enterprise problem with mature external options, I would explore what is already available before committing resources to building it. Specialized workflows may lead to a different decision.

A hybrid approach may mean buying some components while building the orchestration around the organization’s own data and workflows. 

I would revisit the decision over time. Something worth building internally today may become a commodity later.

Increase Autonomy as the Organization Learns

Giving an agent too much freedom too soon creates avoidable risk.

Many commercially available agents already ask users for permission to access a database, write to a location, or open a file. Some also allow users to approve those requests for the rest of a session. 

During early testing, I would pay attention to what the agent is asking to do before removing those checkpoints. Going through those requests over several iterations can help teams see where the agent needs tighter boundaries and where more autonomy may be appropriate. 

I would use those early deployments to establish stage gates for autonomy. Lower-risk actions may need little intervention. A consequential action in a regulated process may require human approval before the agent proceeds.

The evaluation also has to follow the agent through the workflow. For higher-risk use cases, I want to be able to trace:

• Which tools the agent chose
• Which sources grounded the response
• Where the data came from
• Whether the results are reproducible 

Unexpected conditions matter as well. Teams need to understand what the agent does when the workflow does not proceed as planned.

A correct final answer doesn’t necessarily tell me whether I would trust the process that produced it.

Measure Whether the Workflow Actually Improved

I put a lot of weight on stakeholder experience when evaluating an agentic AI implementation.

The people who will use the agents should be involved early. Co-development brings their subject matter expertise into the project and gives the team feedback while there is still time to change the workflow. 

When users are consistently unhappy with the experience, I take that seriously. Something may be wrong with the business case, the data, the tools, or the way the work has been designed.

Technical measures depend on the use case. Precision and recall may matter for one application; false positives and false negatives may matter for another. Teams using AI-based evaluation can compare those results with human evaluators to see where the assessments agree and where they diverge.

Once token usage, licensing, and other expenses are factored in, some AI use cases may cost more than having human experts perform the work. Cost should be evaluated alongside the technical measures when deciding whether an agentic AI implementation is worth scaling.

Technical performance alone would not be enough for me to scale an implementation. I would also want to know whether the people using the agent find it useful and whether the improvement is worth what the organization is spending to achieve it. 

When the Agent Gets Faster, Look at the Rest of the Process

An agent may change more than the task it was introduced to perform. If work that once took 30 days can be completed in three, the downstream workflow has to be ready for the result much sooner. Improving one step can move the bottleneck somewhere else in the process. 

The rest of the organization and its processes may need to be redesigned to keep up. The people and processes downstream need to be ready to operate at the new pace. 

The organizations that succeed will not necessarily be the ones with the most agents, but the ones that use them in the right places and rethink how work and decisions are made.