API usage used to be predictable in the sense of who was using it — you could typically assume a human intent behind it, and with this, a human understanding and context. Even automated solutions were ultimately an extension of the human user. They might have worked faster and across more resources, but they were ultimately directed by a human to do human-like things.

In the agentic reality of today, however, this expectation has gotten fuzzier. Agents can make decisions and inferences in ways that aren’t often easy to track and aren’t always aligned to human intent. Their decisions and resultant actions can often feel human-like, and as long as things work that’s fine. But the second it goes off the rails, you’re now in the complex situation of having to troubleshoot an entirely opaque situation with no idea what is automated, what is human, and what is agentic.

This isn’t a theoretical issue either. APIs are seeing more agentic traffic than ever before, and as much as tooling has rushed to meet the ingest part of this problem, there’s still quite a lot of work that must be done to meet the next part of the issue: observability. In the context of AI agents, observability refers to gaining knowledge into how (and why) the agents are actually doing what they’re doing, often in the form of logs, traces, API calls, and other metrics.

Today, we’re going to dig into some steps you can take to improve your observability into AI agent interactions. This is an ever-growing field, so things will certainly change. But the tips below currently represent ways to immediately improve this process at scale.

1. Keep a Definitive API Catalog and MCP Registry

Simply put, you cannot observe what you haven’t cataloged — and when it comes to API observability, this first step is absolutely critical to getting a grip on how these things work within your systems. In an agentic setup, the problem isn’t just knowing what APIs exist — it’s also knowing how they connect and what is wrapping them.

Think of this first step kind of like inventory management. How do you know how much flour or butter you’re using in your kitchen on a weekly basis? How do you know when you need specific groceries? You probably keep some sort of shopping list and a mental list of items you’re producing. Now imagine you’re trying to discover if someone is sneaking into your kitchen and using all your flour and butter. If you don’t even know what you have in the pantry in the first place, it’s going to be impossible to actually track that — let alone do something about it.

Accordingly, the first step toward observability is establishing what you are actually observing interactions around. Treat your APIs and MCP instances as first-class catalog entries alongside core definitions and tooling. An API catalog, or MCP registry, will be the basis for everything else we’re about to discuss.

2. Map Where Agents Are Actually Using APIs in Workflows

Once an MCP catalog is created, your next step should be actually detecting agentic workflows and figuring out how they’re using your APIs. An interesting pattern in agentic systems is that AI doesn’t always use your systems in predictable ways.

For instance, an agentic system may ultimately be trying to get a resource update, but it may keep pinging your catalog or your hypermedia context as a sort of context checker, validating that it’s going to the right location over and over. In those cases, you have an API which should really be cached — but only because the use pattern is so different from the way that humans might use it that it becomes justified.

Some of this is going to be guesswork, of course. But in the process of looking at agentic utilization of your system, you can get a lot of context about not just how they’re using your systems — but how they think you want them to use the system. This can lead to further introspective development, identifying pieces of your flow and system which are misleading or can otherwise be improved to get the agents to work in the way that you want them to.

This is another big step in adding more contextual understanding to your arsenal — you can’t fix what you don’t understand, so getting an idea of how your systems are being used in reality is extremely helpful.

3. Correlate API Calls Across Workflows

When it comes to observability, agent-driven calls might require different treatment compared to human-originated calls. This presents a unique problem for APIs, and it’s one you need to attack the right way.

Consider a human who makes ten workflow calls to your service in a day. Those workflows are likely different from one another — they may be getting different data points, hitting different services, and ultimately serving entirely different intents. Even if you assumed that one or two of those workflows were ultimately in the service of the same end goal, the calls are uniquely aligned with a specific intent and outcome.

With agents, this is not necessarily true. An agent may get to the middle of a workflow, decide that their pathway is not resulting in what they want it to, and then restart with an entirely new workflow against entirely new modes and endpoints. To your system, this is a new workflow — but to the agent, this is the same process with a new pathway.

The solution here is to track across workflows by using solutions like workflow attestation or agent ID tracing. Whatever system you use, enforcing that specific agents have a unique identifier, or at least using an origin tracer like IP or device fingerprinting at the gateway level, will help you connect disparate requests, thereby improving visibility and unifying what seems like noise into helpful information.

4. Leverage Heuristics and Funneling to Identify Traffic

Something API providers need to understand is that only a small percent of traffic will be confidently identifiable by runtime monitoring. Accordingly, your best play for the perimeter is to leverage heuristics and funneling to identify traffic.

Firstly, you need a human baseline. You could establish this by filtering out known agents and automated systems, and see what it looks like to be a human using your API. If needed, you can start with a microgroup of developers internally. But at any rate, you need to start with an idea of what non-agent traffic looks like.

From here, you could then funnel traffic to more agent-friendly endpoints more directly. Over time, if you find you are correlating API calls that are human in the agent pool or vice versa, you can always change this funneling process at the gateway level — this is going to be a highly iterative process, however.

As an aside, part of what makes this work is having comprehensive monitoring across your entire stack. So as you work through this process, this makes a good opportunity for validating your systems at scale.

Part of this funneling process should also include granular permissions and identity issuance and management. You can no longer just mark everything as an ingest — you must get granular. Treat this entire section as a flexible and living system — over time, you want to validate your systems, and be willing to fail fast if they’re not meeting your expectations with real in-situ data and use.

5. Log Tool Usage and Intent

At this point, it’s also important to start delineating what is an agentic use case versus an agentic tool, and what the intent behind that request is. For example, an agent might be orchestrating various tools, often provided via MCP, in order to get to a specific use case. These are not different agents, and they all serve a central use case, but it’s easy for them to get lost in the tracking and processing as simple “agent traffic.”

Some of this can be handled at the MCP level. For instance, all MCP API calls should transfer a header that is required for continued use. This header can then be used to trace and track over the entire agentic workflow. Other pieces of this can be traced during the authentication and authorization flow, but be cautious to ensure that if you use both to catch traffic at all points, the system must be the same: you must unify the identification method universally.

6. Set Risk Thresholds and Monitor for Anomalies

Once you have your general observability system in place, you need to also make it smarter. Just knowing that you have agentic traffic only does so much. You should also be logging tool usage and intents where possible. Some agentic traffic is going to be routine and low-risk — and having full observability as to every single time an agent asks what their agent ID is will drive you nuts.

What is higher risk is when those agents make decisions, escalate requests, or try to access resources. Those risks should carry variable risks of their own. For instance, trying to access a stable resource that is publicly available is certainly different from trying to access a user profile setting.

Importantly, that detection should be tied to action. Providing triggers for human operators to know an escalated request has happened can be vital to getting a human in the loop, but can also allow you to track and monitor behavioral anomalies over time, resulting in a self-reinforcing system that gets better and more accurate over time.

Looking Toward the Future

Ultimately, this process must be an iterative one. You’re not going to get this perfect from day one, and even if you do, the agent space is changing so rapidly that you’re only going to get it right for a relatively strict period of time. As such, you must constantly re-evaluate this solution and make sure that your observability is actually reflecting what you need it to for the operational realities of today.