AI Agents Need More Than Dashboards: Rethinking Observability for Financial Services

Your observability platform was built for humans. What happens when AI agents become the users?

For years, observability has helped engineers understand what's happening inside production systems.

An alert fires. An engineer opens a dashboard, investigates logs, connects traces to metrics, and uses experience to figure out what went wrong.

But what happens when the engineer isn't the one doing the investigation?

AI agents are increasingly capable of writing code, diagnosing problems, and taking action inside software environments. That creates a fundamental shift in how organizations need to think about observability.

The next generation of observability platforms won't just help people understand what's happening. They'll need to provide the context AI agents require to make decisions and act.

And for financial services organizations, that raises difficult questions about data access, accountability, compliance, reliability, and cost.

In a recent episode of A Platform for Modern Finance, host Logan Lyles sits down with Adam Hicks, Senior Solutions Architect at Groundcover, and Justin Billig, CEO and Co-founder of Tensure, to explore what happens when AI agents become users of enterprise platforms.

Their conversation reveals an important distinction:

Giving AI agents access to more data isn't enough. They need the right context, the right permissions, and a platform designed to support their actions safely.

Watch the full episode of A Platform for Modern Finance

Listen to the full episode on Apple or Spotify

‍

Why isn't traditional observability enough for AI agents?

Traditional observability relies on three primary signals: logs, metrics, and traces. Events often provide an additional layer of operational information.

These signals help engineers reconstruct what happened across applications, infrastructure, and services.

But the information isn't always connected.

An engineer investigating an incident might open a trace, identify a slow API request, check database metrics, examine infrastructure logs, and connect the dots.

Experienced engineers can do this because they understand the system's architecture. They know how the pieces fit together.

AI agents don't automatically have that understanding.

As Hicks explains, the challenge isn't simply making telemetry available. It's giving an agent a meaningful representation of how production systems relate to one another.

A spike in API latency might actually be caused by database I/O contention, storage performance, or another infrastructure dependency.

An agent looking at disconnected signals may struggle to make that connection efficiently.

It can attempt to reconstruct the relationships itself, but doing so may require extensive queries, additional reasoning, and significant token consumption.

The result is a new observability problem: tools designed to help humans investigate incidents can create unnecessary complexity and cost when agents become the primary consumers.

Adam explains why AI agents need more than access to separate telemetry signals and how semantic relationships help them understand production environments.

‍

What operational context do AI agents need?

For AI agents to investigate and troubleshoot production systems effectively, they need more than a collection of measurements.

They need to understand the relationships between those measurements.

That includes:

• Which applications depend on particular services or infrastructure
• How APIs, databases, and storage systems interact
• Which changes occurred before a performance problem
• How telemetry signals relate to the same transaction or incident
• What actions are permitted within a particular environment

Hicks describes the importance of a knowledge graph, or semantic representation, that allows agents to navigate these relationships.

The distinction matters.

Knowing that an API is slow is one piece of information.

Understanding that the API's latency is related to database throughput, which is affected by an underlying infrastructure issue, is the context needed to investigate the cause.

Technologies like OpenTelemetry help standardize instrumentation and correlate signals through identifiers such as trace IDs.

But correlation alone doesn't necessarily provide the complete operational picture an agent needs.

Hicks argues that observability platforms need to make those relationships more directly accessible, rather than forcing each agent to reconstruct them from raw telemetry.

For financial institutions operating complex, interconnected systems, that could determine whether AI becomes an effective operational assistant or simply another expensive investigation tool.

‍

Who is accountable when AI agents take action in production?

Giving an agent access to production data is one challenge.

Allowing it to act on that data introduces another.

Who is responsible when an AI agent makes a production change?

Is it the agent itself? The engineer who initiated the task? The team responsible for the platform?

And what happens when one agent launches dozens of additional agents to complete a task?

Billig points out that traditional IT accountability assumes a human is responsible for an action.

That person understands the consequences of making a mistake. They can exercise caution, request approval, or reconsider a decision.

AI agents don't naturally operate with the same institutional experience or sense of accountability.

For financial services organizations, this creates important requirements around identity, authorization, and traceability.

Technology leaders need to know who initiated an action, which agent executed it, what permissions were delegated, and why a change occurred.

These aren't entirely new governance questions. But autonomous software changes the scale and speed at which they need to be answered.

Billig describes how organizations are currently using delegated permissions, tying agents to an existing person or role.

That provides a starting point for governance.

But as agents begin creating other agents and executing more complex workflows, organizations will need more deliberate controls.

Justin discusses accountability, traceability, and why platforms must evolve to support both human and AI users.

‍

What does unified observability look like in practice? The Riskified example

One of the most practical examples from the conversation comes from Riskified.

According to Hicks, Riskified was dealing with three separate observability systems.

Developers who wanted to understand what was happening in production had to move between different tools to investigate traces, logs, and metrics.

That created significant context-switching.

It also made it harder for developers to stay inside their primary working environment.

Groundcover helped Riskified consolidate its observability environment and provide an interface through which AI agents could access the unified telemetry.

Instead of manually navigating multiple observability tools, developers could work with agents that retrieved operational information from a more centralized source.

Hicks shares a particularly useful description of this shift:

"The agent is becoming the new dashboard."

The point isn't necessarily that dashboards disappear.

It's that developers increasingly want answers where they're already working.

Instead of opening several applications to investigate an incident, they can ask an agent to examine production behavior and provide the relevant context.

For platform engineering leaders, the lesson extends beyond observability.

Fragmented tools already create cognitive load for humans. For AI agents, fragmentation becomes an architectural obstacle.

A platform that connects operational data and makes it accessible through consistent interfaces can improve the experience for both.

Adam shares what Groundcover learned from Riskified's observability consolidation and why developers increasingly want answers delivered inside their existing workflows.

‍

How can financial institutions preserve observability data without losing control?

Financial services organizations face a difficult trade-off.

AI agents need detailed production telemetry to investigate problems effectively.

But that telemetry may contain sensitive information, and collecting, storing, and processing large volumes of it can become expensive.

Traditional observability pricing models may encourage organizations to sample data, shorten retention periods, or limit what they collect.

Security and compliance requirements may introduce additional constraints around where telemetry is stored and what information must be removed or protected.

The problem is that reducing the available data can also reduce the context agents need.

Hicks illustrates this challenge through Nimbus, a financial services customer.

According to Hicks, Nimbus had been sampling and scrubbing telemetry because of a combination of cost considerations and regulatory concerns.

That created gaps in the information available for investigation.

Groundcover's bring-your-own-cloud deployment model allowed Nimbus to operate its observability environment within its own infrastructure, changing both the data-control model and the economics of retaining telemetry.

This gave the organization greater flexibility over the data it could preserve while addressing some of its concerns about sending sensitive operational information outside its environment.

That doesn't mean infrastructure becomes free or that data privacy obligations disappear.

But it changes the trade-off.

Instead of treating every additional unit of telemetry as a vendor ingestion charge, organizations can evaluate collection and retention based on operational value, infrastructure cost, and governance requirements.

For regulated organizations, this raises a useful question:

Are observability costs and data-handling constraints forcing us to discard the very context our AI agents need to operate effectively?

Adam explains how Nimbus approached telemetry fidelity, data control, and observability cost in a regulated environment.

‍

How do eBPF and contextual observability support AI agents?

Another part of the observability challenge is collecting useful data without creating additional work for development teams.

Traditional instrumentation can require engineers to add and maintain application instrumentation or SDKs.

Hicks explains how Groundcover uses extended Berkeley Packet Filter (eBPF) technology to collect telemetry from cloud-native workloads at the system level.

This can reduce the need for application-level instrumentation in supported scenarios while providing information about how applications interact with their underlying infrastructure.

It also creates opportunities to associate signals with shared operational context closer to the point of collection.

Combined with a unified telemetry environment, that can make it easier for agents to investigate relationships between applications and infrastructure.

The technical distinction is important, but so is the business outcome.

Engineering teams shouldn't have to spend disproportionate amounts of time maintaining instrumentation or navigating observability tooling just to understand how their software behaves.

The more the platform can make that information accessible through standardized interfaces, the more engineers can focus on improving the applications themselves.

‍

What should CIOs, CTOs, and CISOs ask before giving AI agents access to production data?

More complete observability doesn't automatically mean more unrestricted access.

In fact, the more operational context an agent can consume, the more important access controls become.

During the episode, Billig raises several questions that financial services leaders should address before expanding agent autonomy:

• What data can the agent see? Is all of that information necessary for its task?
• Where does the data go? Can operational context leave the environment where it was collected?
• How is the agent's identity managed? Are permissions appropriately provisioned and constrained?
• How is access audited? Can the organization reconstruct which agent accessed information and why?
• Can the agent take action? Does read access create a path toward modifying production systems?
• What happens when something goes wrong? Can the organization contain, reverse, or recover from the agent's actions?

Hicks adds another consideration: how the information is exposed.

Interfaces such as Model Context Protocol (MCP) can enable agents to access tools and data.

But providing an agent with unrestricted queries against raw telemetry isn't necessarily the most useful or safest approach.

The quality and structure of the interface matter.

An agent should receive information in a format that preserves relevant relationships and allows it to reason efficiently, while respecting its authorization boundaries.

For financial services organizations, agent readiness requires more than granting access to existing tooling.

It means designing how agents receive context, exercise permissions, and interact with operational systems.

‍

How does platform engineering change when the user is an AI agent?

For years, platform engineering has focused on reducing the cognitive load on developers.

Internal developer platforms, self-service workflows, and golden paths are designed to help engineers deliver software without repeatedly navigating complex infrastructure and approval processes.

Those same principles become important when AI agents begin consuming the platform.

But the platform's role expands.

Billig describes a shift in which the internal platform starts looking less like a developer portal and more like an operating system for how agents get things done.

It becomes the layer that defines not only what agents can do, but what they're allowed to do.

That includes permissions, approved workflows, observability access, deployment controls, and mechanisms for recovery.

Importantly, these controls shouldn't recreate the same manual bottlenecks platform engineering was designed to eliminate.

Billig argues that platform teams need to operate like product teams.

Their goal should be to anticipate common needs and make those capabilities available through self-service rather than requiring a ticket for every request.

Golden paths and standardized workflows provide that foundation.

As AI agents join humans as platform users, those pathways can also help define how autonomous actions should be executed.

The broader lesson is that platform engineering doesn't become less important as AI agents become more capable. It becomes part of the infrastructure that makes their autonomy manageable.

‍

Why do AI agents need production feedback and reliable rollback capabilities?

AI-assisted software development is changing how quickly teams can generate and modify code.

But writing code is only part of delivering reliable software.

Developers still need to know whether the code behaves correctly under real-world conditions.

Hicks argues that application performance should be treated as a product feature, not simply an operational concern.

That means production observability becomes part of the development feedback loop.

An AI coding agent might generate a feature that passes functional tests but causes API latency to increase under load.

Without access to performance telemetry, the agent may have no way to identify or correct that problem.

Giving agents structured observability data from testing and QA environments creates an opportunity to validate performance earlier.

But increased autonomy also requires stronger recovery capabilities.

Billig emphasizes that agents will make mistakes, just as humans do.

And as autonomous systems increase the volume and speed of changes, platforms must be designed to handle failures.

That means supporting repeatable deployments, rollback, redeployment, and recovery.

The goal isn't to assume AI agents will always make the right decision.

It's to create an environment where their mistakes can be detected, contained, and corrected

Justin explains why repeatable deployments, rollback capabilities, and recoverability become essential as AI agents take on more responsibility.

‍

What should financial services technology leaders take away?

Three important lessons emerge from the conversation.

First, AI-ready observability requires connected context.

Traditional logs, metrics, and traces remain important, but AI agents need to understand relationships across services, infrastructure, and production behavior. Simply exposing more raw telemetry is not the same as providing useful operational context.

Second, agent autonomy requires explicit governance and recoverability.

Financial institutions need to understand what their agents can access, what they're authorized to do, who is accountable for their actions, and how those actions can be audited or reversed.

Third, platform engineering becomes the foundation for safe AI operations.

Standardized workflows, self-service, shared observability, identity controls, and resilient deployment practices provide the structure needed for humans and agents to operate together.

As Tensure and Groundcover are exploring through their partnership, the next stage of platform engineering isn't simply about helping developers ship software faster.

It's about helping organizations prepare for a world where software can investigate, decide, and act.

For financial services leaders, the objective remains familiar: modernize without losing control.

But the definition of control is changing.

‍

Frequently Asked Questions

What is AI agent observability?

AI agent observability can refer to monitoring the behavior of AI agents themselves, including their actions, tool calls, and performance. In this episode, the focus is different: enabling AI agents to consume application and infrastructure observability data so they can investigate, troubleshoot, and potentially act on production systems.

Why do AI agents need more than logs, metrics, and traces?

Logs, metrics, and traces contain valuable operational information, but they don't always explain how different systems and events relate to one another. AI agents benefit from structured context that connects services, dependencies, infrastructure, and application behavior, allowing them to investigate problems more efficiently.

What is the role of a knowledge graph in AI observability?

A knowledge graph, or comparable semantic representation, helps describe relationships between systems and operational signals. For example, it can help an AI agent understand how API latency relates to database performance or infrastructure dependencies rather than treating those measurements as unrelated data.

How can financial services organizations give AI agents secure access to observability data?

Organizations need to control which data agents can access, manage agent identities and permissions, audit their actions, and determine whether operational information can leave approved environments. They also need interfaces that provide useful context without exposing unnecessary information or capabilities.

How does platform engineering support autonomous AI agents?

Platform engineering provides standardized interfaces, self-service workflows, golden paths, governance controls, and resilient deployment capabilities. These foundations can help AI agents operate within defined boundaries while preserving developer productivity, system reliability, and organizational accountability.

Why does observability cost matter for agentic AI?

Agents may need to examine substantial amounts of telemetry to investigate incidents and understand production behavior. Sampling, restrictive retention policies, fragmented data, and inefficient access patterns can reduce the context available to them. Organizations need to evaluate both the cost of retaining operational information and the cost of agents consuming it.

Watch the full episode of A Platform for Modern Finance to hear Adam Hicks, Justin Billig, and Logan Lyles discuss agentic observability, the Riskified and Nimbus examples, platform engineering, and what financial institutions need to consider before giving AI agents greater autonomy.