“Three clicks instead of 30” – is commentary about a leading Electronic Medical Record (EMR) application. Healthcare’s complex order and action creation requires highly trained providers to navigate pre-defined screens and repetitively input data. A typical scenario might follow like the one found in this applied use case. These complex flows are not unique to healthcare. This blog post explores:

1. How Agentic AI can improve this situation
2. How Agents depend on APIs
3. The new capabilities required for Agent API consumption
4. The role of reusable APIs

Current challenges in large enterprises: a lack of system composability

Today’s Enterprise systems (EMR, CRP, ERP, HCM) commonly feature a database, business logic layer, and user interface.  Many systems exposed APIs but if healthcare EMR platforms are an indicator, these are frequently limited.  New functions and flows must be coded by programmers and often the workflow is dictated by the application rather than by the users. 

In short, these systems aren’t very composable. Limitations on system composability become a limiter for organizational composability. Changing these systems is both slow (relatively) and costly. This speaks to why there should be so much excitement around the emergence of Agentic AI and how it could be used to evolve existing platforms – or replace those that can’t evolve.

Enterprise systems have rich functionality, but they are driven by valuable human resources. For example, in healthcare; doctors or other practitioners clicking buttons and typing on keyboards. In many cases systems dictate to organizations the flow that they must follow for the system to function correctly.

Consider medical encounters, sales calls, or call center interactions. The information needed, the follow-up actions for each encounter or call vary significantly. The provider, salesperson, or representatives must select the appropriate screens to enter new actions. They may need to wait for responses, such as test results, to navigate to a screen to start a new action (such as creating a referral). And these persons are dealing with dozens of cases all the time, some of which may be active for days or even weeks forcing them to continually follow up.

This speaks to a lack of system composability limiting users’ control over the system design or its predefined workflows. IT departments probably can’t affect change on this either since it would require changes to the base product. A change request could be submitted to the vendor and eventually it might get implemented. The time waiting for changes like these eats into ROI (return on investment) and limits organizational flexibility.

Agentic AI and APIs can enable Innovation and Flexibility

AI Agents coupled with robust APIs (such as the healthcare standard FHIR APIs) can simplify this work. Maybe, just through describing the desired flow, an AI Agent can compose the desired flow, make the necessary requests, track the state and launch new requests as needed, perhaps by leveraging other agents whose function has been previously tested. This allows users to compose new functionality, on the fly, leveraging reusable APIs. This also represents a shift in thinking away from developing AI Models to developing AI systems.

This vision shifts so much power, and responsibility, to the user but requires agents to be consistent and reliable and the API environment to be robust and support Agent demands.

API Requirements to support Agents

The advent of AI Agents brings substantial requirements on APIs. The agent is challenged with parsing a natural language request into a workflow and then must understand the documentation and capabilities of the APIs to instantiate it. This task becomes more and more difficult if the agent needs to parse multiple APIs that overlap in functionality and use to find the “best” one for it to use.

Some practical advice to help Agentic AI use APIs effectively:

1. A standard such as FHIR can certainly help.
2. Additionally, an API catalog must identify the reusable API, the most robust and clearly documented APIs.
3. API documentation is crucial but often incomplete or lacking in essential details like attribute documentation or GraphQL schema. Even with clean documentation, agents need to comprehend it. In healthcare “Benefits” is a term that is often used interchangeably with “Plan”. These kinds of overloading and other semantic anomalies Agents to have contextual language models that will allow it to understand this type of nuance within an API specification. As Agentic APIs emerge changes to OpenAPI specifications will be required to describe not just the static information about the API but the tasks the API will manage dynamically.
4. API Utilization is another consideration. Agents are going to create further volume demands on APIs and can process responses faster than a human. An agent isn’t a user reading a user interface and searching for buttons to click. APIs need to be optimized to support these new demands. If an Agent discovers an API that is over utilized – what is its recourse?

Agent behaviour will only be as predictable as their underlying APIs

These needs to clearly and more deeply document APIs, to promote the APIs you want Agents to consume, to provide information about the utilization of APIs are likely to drive changes to API Management and Catalog platforms. It is likely that the OpenAPI specification will need to evolve to provide Agents with metadata and that human readers haven’t considered to date.

The Arrazo Specification is one evolving OpenAPI that expresses sequences of API calls and dependencies between them. Another indicator that Agents may look for is an indicator of consistency, accuracy, confidence or completeness. Agent behavior will only be as predictable as their underlying APIs. Two agents using two APIs may give differing results leading to uncertainty and doubt (see my previous article reference of the pricing APIs).

While we’ve been discussing Agents consuming APIs that are presumably developed by humans, we should also start to consider what happens when agents create the APIs for other Agents. There is no reason for an Agent to necessarily write human readable code after all.

Enhancing API Maturity for Agentic AI: Orchestration, HATEOAS, and Future-Proofing API Catalogs

The next concern is creating APIs that can aid the Agent in its orchestration tasks. Consider scenarios where a constraint isn’t met in the request or where the Agent is waiting for a result before it can proceed. A 412 error indicates precondition failure, and, a description of the precondition that needs to be met can be returned as well. How will the agent know what to do next?

The REST architectural style specifies how an API could handle this – Hypertext as the Engine of Application State (HATEOAS). Use of HATEOAS represents the third level of maturity in the Richardson Maturity Model – but developers frequently do not aim for this maturity level. While leveraging various frameworks can help, it is hard work to create APIs that support HATEOAS. Accepted practice seems to be pass this to a consumer developer to figure out.

But agents are going to need these directions in their API responses which may finally drive the industry to invest more into APIs that reach this higher maturity. In our scenario, we would like the Agent to be told where to go to request information about medication dispensation and, once it has found that, where to go to update the state of the constraint, and finally, it can request the prescription again.

Enterprises need a complete and mature API catalog

Building on this maturity theme, organizations should assess the completeness of their API catalog. FHIR is an incredibly rich and complete specification. In many cases the healthcare industry has implemented these APIs in response to the Center for Medicare Services (CMS) has regulatory mandates. While this has driven investment in these APIs most vendors and organizations still have only a subset of the capabilities. There are a lot of read-only APIs, for example, but few that can process a request to create a record. Other vendors have implemented smaller cross sections of the standard but have both read and write capabilities on the APIs that are implemented. Other industries without these regulatory pressures may have even less complete API catalogs.

Compliance, reporting, security, and versioning considerations

The FHIR specification doesn’t cover HATEOAS or hypertext, making it likely that APIs that extended to include this capability wouldn’t even be compliant. Similar gaps exist in other industry standards, suggesting that vendors in other industries may only partially implement their APIs mapping to resources.

Achieving a comprehensive and mature API catalog requires engagement of API tooling providers or internal IT investment. These high-quality APIs will be valuable assets, and organizations shouldn’t view them as a one-time investment. To realize gains from the investment, measuring agent and human-driven reuse will be key.

While we are looking at how organizations can leverage agents and APIs to improve the composability and affordability of their products, you can be certain that there are others that are using Agents to exploit any weaknesses in your APIs. New strategies to secure APIs against agents may need to be defined and implemented.

Managing API versions may become more important. In the attached scenario, agents focus only on the latest version since they die after completing tasks. However, Agents have the potential to become reusable. In this case, the ability to update version of Agents to map to new version of APIs becomes important and somehow synchronizing API updates with the Agents is a new requirement.

In our visionary use case, an end user describes his flow and the agent creates it real-time. To ensure reliability it may make more sense to use AI to train and deploy reusable agents that implement sections of workflows that can be controlled by a central command and control system. An end user can then select these reusable agents and order them to achieve a series of tasks orchestrated by the “command agent”. This gives greater flexibility to the end user to define the workflow they want while reducing or eliminating a reliance on explicit coding.

This approach makes sense considering current Agent consistency and reliability. Agents might look for the robust, high-quality API or connector but, if one was missing, they can get human guidance for alternatives. This wouldn’t be possible if the Agent was trying to create a workflow on the fly. Reusable Agents can also be thoroughly tested before being released into production environments, validating functionality and compliance.

If Agents are going to be reusable, dependent on different versions of API and with multiple versions of the API itself it suggests that there is a need for an Agent catalog and a portal to find and use these agents analogous to what we see with APIs today. Taking this thought a step further, it’s not hard to imagine that current API catalog products would be a platform that can be extended for this purpose. In addition to sharing the catalog, this would allow visibility of what APIs an agent was utilizing, and an end-to-end lineage.

As Agentic AI platforms evolve, monitoring and tracking all acting agents and their issues is crucial. Tracking Agents back to an end user and allow an end user to view all their agents will be vital. An audit trail for agent actions is essential in regulated industries. An informative article about some of the problems and solutions for AI security can be found here.

Summary

As Mark O’Neill describes it, AI represents and existential moment for APIs. We’ve explored several areas where APIs need to evolve including:

• High-quality reusable APIs, with enhanced specification capabilities – API developers need to spend the time to develop complete API documentation. Meaningful semantic consistency within the domain and context. Standards can help with the consistency of the APIs consumed which means less time training of models to understand variances when a number of overlapping, proprietary APIs are involved.
• Raise maturity of APIs to include HATEOAS which will provide clues to agents this will help agents to create workflows and react to errors and other conditions.
• API catalogs must identify the API best suited for Agent use.
• Need to see changes to existing standards to support capabilities such as HATEOAS or Agentic APIs. We are seeing changes already to the OpenAPI specification
• Investment by vendors and organizations to implement APIs that manipulate their resources beyond just reads.

APIs are investments that enable businesses beyond “that thing IT does to glue things together.” APIs promote composability and a collection of Agents that can similarly be composed will likely promote faster organizational composability.