There’s a question I hear from almost every HCM leader after an Oracle AI agent rollout, and it’s not about functionality. It’s not about configuration. It’s this: “Is anyone actually using it?”
I’ve been in enough post-go-live conversations to know that question rarely gets a confident answer. You can build a well-architected AI agent, publish it, hand it off to end users, and still have no real visibility into whether it’s driving value or quietly sitting in the background untouched. Oracle’s 26A release changes that, through a new BIP report called Fusion AI Agents Adoption and Usage.
I’ve spent time working through the report structure and what it actually reveals, and I want to share what I think every Oracle HCM practitioner needs to know about it, starting with the questions it now allows you to answer that you simply couldn’t before.
What This Report Actually Does
The report gives you a consolidated view of two things: who is using your AI agents, and how much work those agents are actually doing.
It pulls from Fusion AI Agent Studio and classifies every workflow by how it came to exist. Whether someone used an Oracle seeded template directly, derived a custom version from a template, or built something entirely from scratch. That classification alone tells you a lot. It shows whether your organization is a fast follower, a customizer, or a builder, and that has real implications for how you approach support, governance, and future investment.
Three Questions This Report Helps You Answer
Are people actually using my agents?
The INTERACTION_COUNT metric is your primary signal. It counts distinct conversational sessions, each one representing a real end-to-end agent invocation. A high count means the agent is part of daily work. A low count means it’s either undiscovered, misaligned with what users actually need, or not yet trusted.
One thing worth watching: interaction count includes both developer testing and end-user activity. I always read it alongside COMPLETED_EXECUTION_COUNT to separate genuine adoption from background noise. If your interaction count is high but completed executions are low, that gap is worth investigating before it becomes a credibility problem for the platform.
How sophisticated are my agents?
This is where the report gets genuinely interesting, especially for architects. Metrics like REASONING_STEP_COUNT, FUNCTION_CALL_COUNT, and TOOL_CALLS_EVENT_COUNT tell you how complex the agent’s actual runtime behavior is. A high reasoning step count means the agent is doing real work, evaluating conditions, branching logic, making decisions. A low count often means you’ve built something that’s closer to a search tool than an intelligent agent.
For anyone making the internal case for continued AI investment, these metrics matter. They give you a way to translate technical sophistication into something a CHRO or CIO can understand. This agent doesn’t just retrieve information. It reasons.
What is this actually costing to run?
INPUT_TOKEN_COUNT, OUTPUT_TOKEN_COUNT, and AVG_TOKENS_PER_INTERACTION are your cost and efficiency signals. Two agents serving similar use cases can have very different token profiles depending on how their prompts are designed and how much context they carry into each session.
This is where post go-live work gets interesting. Finding high-token, low-completion agents and tightening their prompt design isn’t a detail. It’s a real cost management opportunity that most teams overlook after deployment.
What I Look for First
When I open this report on a new environment for the first time, I run through a few things in my head.
I start with adoption type distribution. What percentage of agents are seeded templates used directly versus custom-built? A heavy lean toward templates isn’t a problem on its own, but it can signal that the organization hasn’t yet built the internal confidence to go further. A heavy lean toward custom-built agents is a sign of maturity, but it also raises governance questions if those agents lack clear documentation and ownership.
Then I go straight to error rate by agent. The ERROR_RATE_PERCENT column surfaces reliability problems before they become trust problems with end users. Anything above 5% goes on my immediate investigation list.
After that I look for token outliers. Agents with a disproportionately high AVG_TOKENS_PER_INTERACTION relative to how often they’re used almost always have a prompt design issue. Either they’re pulling in too much static context or they’re not scoping user input tightly enough.
Finally, I check LAST_TELEMETRY_TS. This field doesn’t get enough attention. An agent that was active three months ago and has gone quiet is a candidate for retirement or re-promotion. Stale agents sitting in your catalog create confusion and quietly erode confidence in the platform.
Why This Goes Beyond the Technical
Oracle AI Agent Studio isn’t just a product feature. It’s Oracle’s direction for where HCM automation is heading. The organizations that will get the most from it aren’t necessarily the ones building the most agents. They’re the ones that govern, measure, and keep improving what they’ve already built.
This report gives you the measurement layer. What you do with it is the real governance question.
The best Oracle HCM environments I’ve worked in treat AI agent telemetry the same way they treat payroll run statistics or benefits enrollment data: as operational metrics with regular review cycles, clear ownership, and a response process when something looks off.
That shift in mindset, from “we deployed it” to “we operate it,” is what separates teams that realize lasting value from AI and teams that simply add it to a slide about what they’ve implemented.
Getting Started
The technical setup is straightforward. Download the catalog zip from the Oracle post, unarchive it into your HCM Shared Folders under Custom, then Human Capital Management, relink the data model, and run the report. Oracle’s documentation covers the steps clearly.
The harder part, and honestly the more valuable part, is deciding what you’ll do with what you find.
About the Author: Sudarshan Mondal is an Oracle HCM Cloud architect with 24+ years of experience helping global organizations transform how they manage their people. He has designed and delivered HCM Cloud implementations across Healthcare, Higher Education, Energy, and Financial Services, covering Core HR, Payroll, Compensation, and Benefits. He writes about enterprise technology, workforce strategy, and the evolving role of HR in large organizations. All content on this site reflects his personal opinions and does not represent the views of his employer or any affiliated organization.
Sudarshan Mondal 
Leave a comment