Frontend teams have become pretty good at monitoring what happens after an application reaches production. We track JavaScript errors, API failures, latency and Core Web Vitals. When something changes after a release, these signals help us determine whether the application is healthy.

But there is one gap I think frontend teams often overlook. An application can look completely healthy in those dashboards while an important workflow is unusable for someone navigating with a keyboard or assistive technology.

Imagine a checkout flow where a recent UI change makes the final button unreachable by keyboard. The page still loads. The API responds successfully. There are no new JavaScript exceptions, and performance metrics look normal. Every traditional signal says the application is working, yet some users can no longer complete the purchase.

That is why I have started thinking about accessibility as more than a compliance or pre-release testing concern. If an accessibility regression prevents someone from completing a critical workflow, that is also a production reliability problem.

Where traditional frontend observability falls short

Most frontend observability focuses on technical health. We want to know whether pages load quickly, requests succeed and deployments introduce errors. These are useful signals, but they mainly tell us whether the software is functioning as the system expects.

Accessibility failures are different because they often do not produce obvious technical errors. Removing an accessible name from an icon button will not necessarily throw a JavaScript exception. Replacing a semantic button with a clickable div might leave mouse interaction working normally. A focus-management regression inside a modal can make the interface extremely difficult to navigate while having no effect on page performance.

This creates a blind spot. Our monitoring can tell us that the button rendered and that clicking it successfully triggered an API request. It may not tell us that a keyboard user cannot reach that same button.

Automated accessibility checks in CI are an important first line of defense, and I use them as an early guardrail. But I would not treat a passing CI check as proof that the production experience is accessible. Production applications contain changing data, feature flags, third-party scripts and combinations of components that may not be represented in isolated tests.

Automated tools also have limits. They can identify many structural problems, but they cannot detect every accessibility or WCAG conformance failure. CI should therefore be an important checkpoint, not the end of accessibility verification.

Monitor accessible journeys, not just healthy pages

One way I think frontend teams can close this gap is by applying the same idea behind synthetic monitoring to accessibility.

Instead of checking only whether a page loads, we can test whether important user journeys remain usable. Can someone navigate the primary controls using only a keyboard? When a dialog opens, does focus move somewhere sensible? Can a form be completed without relying on a mouse? Do important controls still expose useful names and roles?

Consider the checkout example again. Traditional synthetic monitoring might verify that the page loads, products appear and the checkout API responds. An accessibility-aware journey could go further by navigating through the same flow with keyboard interactions and verifying that focus reaches the controls required to complete the purchase.

I would not try to automate every accessibility requirement this way. The goal is to identify a small number of critical workflows and ask a simple question: Can a user still complete the task?

For applications with a design system, I would extend the same thinking to shared components. A regression in a button, dialog, form field or navigation component can spread across many screens at once. Testing keyboard behavior, semantics, accessible names and focus expectations at the component level can catch problems closer to their source instead of discovering the same regression page by page.

This creates two useful layers of protection. Design-system checks help protect the building blocks, while synthetic journeys help verify that those building blocks still work together in real application flows.

Make accessibility part of release health

Frontend teams already look at signals after deployment to decide whether a release is healthy. We watch error rates, latency, failed requests and performance changes. I think accessibility signals can become part of that same conversation.

That does not mean creating another huge dashboard or turning every automated accessibility warning into a production incident. The useful approach is to focus on impact.

If a release introduces a minor issue in secondary content, the team may address it through the normal development process. If the same release prevents keyboard users from completing checkout, submitting a form or navigating a primary workflow, that deserves a different level of attention.

This is where accessibility-aware release health becomes valuable. Teams can define a small set of expectations around critical journeys and shared components, then watch for regressions just as they would watch other frontend reliability signals.

The need for this approach is becoming harder to ignore. The 2026 WebAIM Million analysis found an average of 56.1 detected accessibility errors per home page, a 10.1% increase from 2025. It also found that the average home page contained 1,437 elements, a 22.5% increase in a single year. As interfaces become larger and more dynamic, relying only on occasional accessibility audits becomes increasingly difficult to scale.

If users can’t complete the workflow, the system isn’t healthy

Frontend observability has given us increasingly sophisticated ways to understand what applications are doing in production. But our definition of application health should not stop at whether JavaScript executed, APIs responded or pages rendered quickly.

A system can pass every one of those checks and still fail the person trying to use it.

Accessibility testing during development remains essential, but production-oriented signals can help close the gap. Synthetic user journeys can tell us whether critical interactions still work. Design-system regression tests can protect shared components. Accessibility-aware release checks can help teams recognize when a deployment has affected a critical workflow.

For me, the principle is simple. If users cannot complete an important task because of an accessibility regression, I do not think we should describe the application as healthy just because the traditional dashboards are green.

That is not only an accessibility problem. It is a frontend reliability failure.

I’ve had a version of the same conversation probably 30 times in the past year. A VP of engineering or a senior SRE describes their observability stack — the dashboards they’ve built, the alerting they’ve tuned, the Datadog or Grafana setup they’ve spent months getting right. And then they describe the last major incident. How the alert fired in seconds. How the dashboard showed exactly where the degradation was. And how their team still spent two to three hours figuring out what caused it before they could fix anything.

The framing I hear most often goes something like this: “We can see everything. We just can’t explain it.”

That gap between seeing and explaining is worth digging into, because it’s quietly become one of the more expensive problems in operations.

What observability was built to answer

Observability tools are excellent at what they were designed for. They surface what is happening inside systems — latency spikes, error rates, resource exhaustion, dependency failures — and they do so at scale, in real time. That capability is foundational. Without it, you wouldn’t know something broke until a customer told you.

But observability was built around a specific question, what is happening inside the system right now? It answers that question well. A different question, why is this happening and what triggered it, sits mostly outside its reach.

Those sound similar. They are not the same question.

“What is happening” lives in the infrastructure layer: metrics, traces, logs. The observability stack captures it. “Why is it happening” often lives outside the infrastructure entirely, in a deployment that went out two days ago, in a support queue that started spiking before the alert fired, in a change record that engineering approved last sprint. That context isn’t in the telemetry because it was never meant to be.

The investigation that precedes the fix

When a customer-facing incident occurs, the information that would explain it is rarely concentrated in one place.

Engineering is looking at the infrastructure signal. They know what the system is doing, but not which customers are affected or what those customers reported before the monitoring alert fired.

Support has the cases, the complaints written in plain language by people describing symptoms they can’t name technically. Support often knows something is wrong before engineering does, but the deployment history isn’t a system they can search.

Somewhere in Jira or a CI/CD pipeline is a record of what changed and when, with a timestamp, an author, and a scope. That record doesn’t know about the support cases or the anomaly.

So somebody has to connect all of it by hand. That means reading the customer complaints, cross-referencing the deployment history, holding multiple systems in their head simultaneously until the pattern surfaces. That is what the investigation actually is; not problem-solving, but reconstruction.

It takes hours. And it runs entirely before the resolution process can begin. Mean time to resolution (MTTR), the metric most teams are tracking and trying to improve, measures what happens after the investigation ends. The investigation itself is outside the frame.

Who actually does this work

This is the part I think gets systematically under-reported.

The manual correlation work does not fall to anyone with spare capacity. It routes to whoever knows the system well enough to read across these different views simultaneously. The engineer who remembers what shipped last week and why it was unusual. The support lead who can translate a customer’s description of a problem into a technical hypothesis. The person who has been around long enough to recognize the pattern.

That person gets pulled from whatever they were doing. Not because they are available, but because the investigation requires them specifically.

In my experience this is not an edge case. It is a structural feature of how incident response works when the relevant signals are distributed across systems that do not talk to each other. The investigation always finds the person with the most context. And that person is never the most available; they are the most consequential.

The hours they spend reconstructing a timeline are hours they are not doing the other things only they can do. That cost is real and it compounds. It shows up in velocity. In recurrence. In the quiet attrition of senior people who have been in the war room one too many times. It does not show up in MTTR or any incident metric most organizations track.

Two kinds of work

There is a distinction that rarely gets made in incident response conversations: the difference between investigation work that requires human judgment and investigation work that is, at its core, data assembly.

Deciding whether to patch or roll back requires judgment. So does knowing which customers are actually affected and which alerts are noise. These are high-context calls that require judgment that takes years to develop.

Cross-referencing timestamps across Jira, Salesforce, and a deployment dashboard to determine which change shipped before which customer complaint started; that is data assembly. It is tedious and time-consuming. It is what consumes the first two to three hours of almost every serious incident.

The problem is these two types of work have always arrived bundled together. The person who can make the judgment call also has to do the assembly, because no system was built to do the assembly for them. So your most experienced engineer — the one whose judgment you actually need — spends the majority of the investigation doing work that is far below their capability. Work that is numbing, not demanding. Work that clears their day and produces, at the end of it, a starting point for the actual decision.

That’s the waste that rarely gets named. Not the hours themselves, but the quality of what those hours contain.

What changes when they’re separated

The signals that would explain why an incident happened are already sitting in your systems. The customer cases, the deployment records, the infrastructure signals. They were there before the alert fired.

The investigation cost is a correlation problem, not a data problem. The data exists. It has just never been assembled automatically.

This is where a newer category of tooling is starting to take shape, sometimes described as operational intelligence: software that sits across observability, ticketing, and deployment systems and does the cross-referencing automatically, before a human ever opens a second tab.

When that assembly work is separated from the judgment work, the picture changes. The engineer in the war room arrives with a structured view of what happened, the deployment, the cases, the timeline. Their job becomes confirming it, refining it, and deciding what to do next. That’s the work they’re actually good at, and the reason they became engineers in the first place.

The organizations that get ahead of this won’t necessarily have better engineers or better observability stacks. They’ll have recognized that the investigation itself is a workflow, not an inevitability, and that data assembly and human judgment are separable. As AI-driven correlation tools mature, that separation is where the real leverage in incident response is likely to come from.

The observability stack tells you an incident is happening. What teams need next is the context that explains why. One of those capabilities has matured significantly over the past decade. The other is where the work is now.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

For a long time, I thought of observability as something mainly owned by backend, platform or site reliability teams. Frontend engineers built the interface, handled browser behavior and called APIs. When something failed deeper in the system, another team looked at server logs and infrastructure dashboards.

That division works until the application is technically available, but the user experience is not.

A page may load while its most important data arrives several seconds late. A request may succeed after multiple retries, leaving the user staring at a spinner. One cloud service may slow down while the rest of the page continues working. From an infrastructure perspective, nothing may qualify as an outage. From the user’s perspective, the application is already failing.

As I gained more experience building applications that depended on cloud services and APIs, my view of frontend ownership changed. A frontend team does not need to operate every service it depends on, but it does need enough visibility to understand how those services affect the experience it delivers.

Observability gives frontend engineers that visibility. It helps connect what happens in the browser with what happens across the systems behind it. More importantly, it gives teams evidence they can use not only to debug problems, but also to make better decisions about how the frontend should behave when dependencies are slow, unavailable or inconsistent.

The browser sees a different version of the system

Server-side monitoring tells us what happened inside a service. It does not always tell us what happened across the user’s complete journey.

A backend dashboard might show that an API responded in 300 milliseconds. The browser may still take much longer to display useful content because of network latency, JavaScript execution, rendering work or additional requests. A successful response can also produce a broken experience if the returned data is incomplete or the interface fails while processing it.

This is why client-side telemetry matters. Browser error reporting can capture exceptions that never reach a server. Performance measurements can show how long users wait for content to become visible or interactive. Request data can reveal which dependencies are slow, unreliable or frequently retried.

Standard browser APIs provide useful starting points. The W3C User Timing API allows developers to mark and measure meaningful operations in an application. A team can measure how long it takes to load a dashboard, complete a search or render a critical section of a page.

Web Vitals can also help teams examine loading performance, responsiveness and visual stability using measurements tied more closely to the user experience. These metrics are useful because they move the conversation beyond whether a request succeeded. They help answer whether the page became useful quickly and respond when the user tried to interact with it.

The goal is not to collect every browser event. That can produce a large amount of data without producing much insight. It is better to begin with a small set of questions.

How long does the user wait before the main content appears? How often does a form submission fail? Which request prevents a page from becoming usable? Are users on certain devices or network conditions affected more often?

These questions make telemetry easier to design and easier to interpret. “The API is available” is a service-level statement. “The user can complete the task without an unexpected delay” is an experience-level statement. Frontend observability helps connect the two.

Logs and traces connect the frontend to its dependencies

Client-side logs are most valuable when they include enough context to reconstruct what the user was doing. A useful error record might include the application version, route, operation, request status and a correlation identifier. Browser information may also help when an issue affects only certain environments.

At the same time, frontend telemetry should be designed carefully. Logs should avoid form contents, authentication tokens, passwords and other sensitive information. Collecting more data does not automatically make an investigation easier. The right context is more useful than a large amount of unstructured information.

Correlation identifiers are particularly helpful. When the frontend includes an identifier with a request and that identifier continues through downstream services, teams can connect a browser failure to backend logs and distributed traces. Instead of comparing timestamps across several dashboards, engineers can follow one request across the system.

A distributed trace can show that a user action triggered an API gateway, an application service, a database call and another cloud dependency. It can also show where the request spent most of its time or where an error first appeared.

OpenTelemetry provides a vendor-neutral approach for generating and connecting telemetry such as traces, metrics and logs. It also supports JavaScript and browser instrumentation, which makes it relevant to frontend teams that want to connect browser activity with backend services.

Frontend engineers do not need to become observability platform specialists. They do need agreement with backend and platform teams on basics such as trace propagation, naming conventions, safe logging fields and where telemetry can be reviewed during an investigation.

Consider a page that occasionally loads without its main data. The frontend may record that a critical request timed out after several seconds. A correlation identifier from that request may lead to a trace showing that the gateway responded normally, but a downstream dependency exceeded its timeout.

Without connected telemetry, the report might remain, “The page sometimes does not load.” With connected telemetry, the team has a specific failure path, a measurable delay and enough evidence to decide what needs to change.

That evidence can support two actions. The service team can investigate the slow dependency. The frontend team can improve the experience by adding a timeout state, retry option or partial fallback. Observability makes both responses more precise.

Observability should influence architecture, not only debugging

The immediate benefit of observability is faster incident investigation. The larger benefit is better architectural decision-making.

When telemetry repeatedly shows that one dependency is slow, the frontend team can reconsider how tightly the interface depends on it. The page might render primary content first and load secondary information later. Cached data might be acceptable for a noncritical section. A timeout might lead to a smaller fallback instead of blocking the entire screen.

Observability can also expose hidden coupling. If unrelated components fail whenever one shared request slows down, the page may have been designed as a single loading unit. Breaking the experience into independently recoverable sections can make the interface more resilient.

The same evidence can improve retry behavior. Automatic retries may help with a temporary network failure, but they can also add more traffic to an already slow service. Telemetry can show whether retries recover requests, how long the recovery takes and whether users leave the page before it succeeds.

Service-level visibility matters as well. Frontend teams should understand the availability and latency expectations of the services they use. They should also understand what those services return during partial failures.

If a dependency may respond slowly, the interface needs a loading strategy. If data may be stale, the interface needs to communicate freshness. If a service is optional, the page should not collapse when it is unavailable.

Good observability also improves conversations between teams. Instead of saying, “The page feels slow,” frontend engineers can explain which user action is affected, how often it happens and where the delay appears. Debugging becomes a discussion based on evidence rather than guesswork.

A practical starting point can be small. Capture unhandled browser errors. Measure a few important user journeys. Record failures for critical network requests. Propagate a correlation identifier across frontend and backend systems. Review those signals with the teams that own dependent services.

From there, instrumentation should grow in response to real questions. Add a measurement when a workflow is difficult to understand. Add a trace when a request crosses several systems. Add a dashboard when a signal is important enough to review regularly.

Frontend observability is not about turning every frontend engineer into an operations engineer. It is about recognizing that the browser is part of the production system and often the only place where the complete user experience is visible.

When frontend teams can connect what users experience with the services behind it, they can debug more effectively, design interfaces that degrade gracefully and make better architectural decisions. Observability becomes more than a way to explain incidents. It becomes an input into how frontend systems are designed.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

A few years ago, I sat in a postmortem that I still think about. We’d had a production incident where a routine deploy had quietly shipped with the wrong configuration, and it took us longer to notice and roll back than anyone was comfortable admitting. But when we traced the root cause, almost none of it was the feature code. It was the scaffolding around it: a Kubernetes manifest no longer matched our cluster, a CI pipeline whose green checkmark didn’t actually verify the thing we assumed it did, and a secrets-management step that three different services each did three different ways. The code itself had been fine for a week. Everything around the code is what failed us.

I have seen some version of that retro at nearly every company I’ve worked at over the last 15 years across a large IT services firm, a medical-device maker, a healthcare-technology company, a cloud-migration startup, and now a large SaaS platform. The names and the tech stacks changed. The pattern didn’t. Smart engineers spending a startling share of their week not on the problem they were hired to solve, but on the accidental complexity of shipping it.

For a long time, I assumed the answer was better documentation, or a stricter DevOps culture, or just hiring people who were more comfortable with YAML. I was wrong on all three counts. What actually changed my mind was reframing the problem entirely: the friction wasn’t a knowledge gap or a discipline gap. It was a product gap. Nobody owned the developer’s experience of shipping software the way a product manager owns a customer’s experience of using an app. And the discipline that closes that gap now has a name: platform engineering, which Gartner describes as having “emerged in response to this increasing cognitive load resulting from the complexity of modern software tools and architectures.” Gartner isn’t shy about how fast it’s spreading, either: the firm predicts that “by 2026, 80% of large software engineering organizations will establish platform engineering teams,” up from 45% in 2022. If that number is even close to right, the interesting question is no longer whether to build a platform team but whether you’ll build a good one.

The moment “DevOps” quietly stopped scaling

I want to be careful here, because “DevOps is dead” is a lazy headline and I don’t believe it. The principles behind DevOps include shared ownership, automation, and tight feedback loops. These are as right today as they were when the movement started.

What broke, in my experience, was the operating model. The original promise was “you build it, you run it.” Every team owns its own deployment, its own observability, its own on call. That works beautifully when you have a handful of teams and a shared oral tradition. It falls apart when you have 50 teams, because now you have 50 slightly different ways of doing the same undifferentiated work. 50 ways to define a service. 50 subtly wrong Kubernetes configurations. 50 on-call rotations paging fifty engineers about the same class of problem at 3 a.m.

The cognitive load of “run it yourself” grew faster than most teams could absorb. That framing of cognitive load as the thing you’re actually optimizing for comes from “Team Topologies,” a book that reshaped how I think about org design more than any purely technical text I’ve read. Its fourth principle is blunt about the limit: “Teams can only handle so much complexity before breaking down,” and “competent teams become ineffective when leaders keep adding to their plate without taking anything away.” That last line described my own teams so precisely it stung. “Team Topologies” also gave me the vocabulary I’d been missing. It names four fundamental team types, and it defines a platform team as “a grouping of other team types that provide a compelling internal product to accelerate delivery by stream-aligned teams”. Read that definition again: a compelling internal product. Not a shared-services desk, not a Terraform repo with a wiki. A product. That single word is the whole argument.

Treating the platform as a product changes everything

Here’s the shift that took me embarrassingly long to internalize: if the platform is a product, then developers are its customers, and you don’t get to tell your customers they’re holding it wrong.

That one reframing has downstream consequences that surprised me.

The first is that adoption has to be earned, not mandated. Early in my time working on internal tooling, I helped build a platform capability that we were quite proud of, and then we did what infrastructure teams love to do: we announced it, and assumed people would come. They didn’t. Teams routed around it, because the golden path we’d paved was, frankly, gravel. The lesson landed hard. A platform that developers have to be forced onto is not a platform, it’s a tax. When we went back and rebuilt it so that the paved path was genuinely the easiest path. This is the same instinct behind Backstage, the developer portal that was built at Spotify and is now a CNCF project; its own pitch is that it “restores order to your microservices and infrastructure” so product teams can ship quickly. Order you have to opt into isn’t order. The tool wins when choosing it is the lazy option.

The second consequence is that “self-service” has to mean what it says. It’s an overused word, so I hold it to the CNCF’s definition from its platforms white paper: “A platform should be self-serviceable. Users must be able to request and receive capabilities autonomously and automatically.” Autonomously and automatically. If a developer has to file a ticket and wait on my team to provision a database, I haven’t built a platform instead I’ve built a slower version of the help desk. The same white paper states the north star plainly: “An essential goal of a platform is to reduce the cognitive load on product teams.” I’ve started using that sentence as a litmus test. For any capability we’re tempted to add, I ask whether it removes load from a product team or quietly adds some. A surprising number of well-meaning platform features fail that test.

The third consequence is that you have to measure the platform the way you’d measure any product and resist measuring the things that only flatter the platform team. “How many clusters are we running” is an output my team cares about and nobody else does. The metrics that matter describe the developer’s lived experience, and the most durable set I know of comes from DORA, the long-running research program into software delivery performance. Its metrics have evolved from the original “four keys” have grown to five. The core throughput measures still ask exactly the right questions: change lead time (“the amount of time it takes for a change to go from committed to version control to deployed in production”), deployment frequency, and failed deployment recovery time, balanced against a change fail rate. I’ve found those double as a remarkably honest scorecard for a platform team, precisely because they refuse to reward busywork. You cannot game your way to a good lead time by shipping more internal tools nobody uses.

The fourth consequence is the hardest culturally: a platform product needs a roadmap, user research, and the willingness to say no. I’ve watched platform efforts collapse into a junk drawer of one-off requests, each reasonable on its own, that together add up to an incoherent pile of tools nobody can hold in their head. Saying no to a well-intentioned request is a product-management skill, and platform teams that never develop it end up rebuilding the very sprawl they were created to eliminate. The best platform leads I’ve worked with spend as much time talking to their internal users as any consumer-facing PM does.

What I’d tell my younger self

If I could go back to that retro years ago, I’d say a few things to the version of me who thought this was a documentation problem.

Start with the paved road, not the platform. You don’t need to build an internal developer portal in quarter one. You need to find the single most painful, most repeated piece of undifferentiated work is the distance between “here is my container” and “it is running safely in production”. Earn the next piece of scope by delivering that one well. Platforms that begin as grand architectures tend to die as grand architectures; the ones that survive start as one genuinely useful paved road that people choose on their own.

Resist the urge to abstract away everything. The goal of a good platform is not to hide Kubernetes so completely that no one understands what’s happening beneath them; that just trades one kind of fragility for another. The goal is to remove the toil while leaving the understanding intact. When the abstraction leaks you want engineers who can reason about what’s underneath, not a room full of people who only ever knew the buttons. I’ve paid for both mistakes: platforms too thin to help, and platforms so thick that an incident turned into an archaeology dig.

And treat “developer experience” as a first-class business metric, not a morale nicety. Every hour an engineer spends fighting the delivery pipeline is an hour not spent on the thing your customers actually pay you for. When I frame platform investment that way to leadership as reclaiming a meaningful fraction of my most expensive people’s time that’s when the conversation stops being about cost and starts being about leverage. It is genuinely one of the highest-return investments an engineering organization can make, and it almost never shows up as a line item that looks like one.

The platform team is not the group that keeps the lights on. It’s the group that decides how fast everyone else can move. Once I started treating it as the most important product my organization ships internally, almost every other decision got easier. I just wish it hadn’t taken me a missed release and a room full of frustrated engineers to see it.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

One percent of AI-active developers now generate 46 times more AI-written lines of code per day than the median active user, according to the Cursor Developer Habits Report. The bottleneck is no longer writing software. It is understanding what happens after that software ships.

Every new service, dependency, feature flag, generated abstraction, and deployment path increases the number of ways a production system can fail. AI has compressed the time it takes to create that complexity. It has not compressed the time it takes to understand it.

The result is a production environment that changes faster than engineers can rebuild a mental model of it. AI can help in this situation because most debugging practices were designed for a slower world.

Debugging yesterday and today

For decades, debugging was largely a spatial problem. A failure in Service A belonged to the team that owned Service A. They knew the deployment history, the operational quirks, the useful log queries, and the odd behaviors that never made it into the runbook. Incident response reflected that assumption. Teams owned services. Runbooks were scoped to those services. On-call rotations mirrored organizational boundaries.

That model still works when failures stay local. If a deployment introduces a memory leak, or a bad configuration causes a service to crash, the symptom and the cause usually live in the same place. The owning team can investigate, identify the issue, and restore service. Those incidents are becoming a smaller share of production failures.

AI-generated code is not inherently less reliable than human-written code. The change is volume and speed. Teams can now introduce more code, touch more systems at once, and evolve architectures faster than before. As systems become more interconnected, failures increasingly surface somewhere other than where they start.

A single-hop incident is local. The service experiencing the failure is also the service causing it. Investigation stays inside one team’s boundary.

A multi-hop incident looks different. The checkout API begins timing out. Nothing appears wrong inside checkout. Latency is normal. Error rates are low. The actual problem is a queue consumer silently dropping messages because a schema change deployed two days earlier was only partially backward compatible. The queue team sees healthy throughput. The data platform team never receives a page because nothing in its service violates an alert threshold. Every team is right about its own system, yet nobody can explain why customers cannot complete purchases.

The problem is not a lack of evidence. Modern production systems produce more telemetry than any human can use during an incident. The problem is knowing which evidence matters, which signals are coincidental, and how separate clues connect into a causal chain.

The role of AI in production ops

That changes the role AI should play. AI should not be treated as a magic on-call engineer. A frontier model does not know your architecture. It does not remember prior incidents. It does not know which dashboards lie, which services fail together, what changed last week, or which dependencies matter most. On its own, it reasons inside a vacuum.

The useful version of AI in production is more specific. It can assemble context, test hypotheses, trace dependencies, compare the current incident against past incidents, and rule out explanations that do not fit the timing or blast radius. It can do the work that currently eats the first 20 minutes of an incident: gathering evidence, checking recent changes, mapping dependencies, and narrowing the search space.

Humans still make the decisions that require judgment. They decide whether the evidence is strong enough to act, whether a rollback is worth the risk, whether to wake another team, and whether the safest move is mitigation or deeper investigation. But they should not have to spend half the incident reconstructing a system the organization already operates.

That is the larger productivity shift.

If AI can absorb more of the troubleshooting tax, engineers can focus on the work that actually compounds. They can simplify fragile architectures. They can improve instrumentation in the places where incidents repeatedly go dark. They can design safer degradation paths, sharper alerts, better rollback patterns, and evals that catch semantic failures before customers do. They can feed production knowledge back into development, so code assistants and review processes understand which services are risky, which patterns have caused outages, and which dependencies deserve extra scrutiny.

This is the work engineers rarely get enough time to do because they are stuck resolving the same classes of incidents again and again.

Letting the engineers engineer

The goal is not to remove engineers from production. The goal is to stop wasting their judgment on work the system should already be doing. AI should make incidents shorter, but that is only the first-order benefit. The larger benefit is giving senior engineers more time to prevent future incidents instead of being pulled into every confusing one.

As AI accelerates software creation, production operations need the same kind of acceleration on the other side. Not just faster debugging. Better allocation of human attention.

The AI code avalanche will not be managed by asking engineers to troubleshoot forever at machine speed. It will be managed by making production systems more legible, more resilient, and less dependent on whichever expert happens to be awake.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

The demo videos always end at the same moment. A figma frame turns into a passing test in twelve minutes. Someone in the room says the word “productivity.” The recording stops.

The parts that come after that moment are the parts I actually get paged about. Who owns the ticket the agent opened at 3:14 a.m.? Which model call produced the assertion in test case 47? What closes the 17 draft tickets a stuck run left behind before the next sprint planning notices them? None of that shows up in the demo. All of it shows up on the on-call rotation. After 20 years of leading test automation across consumer-scale platforms, I have a strong bias about which slide in the deck predicts whether a pipeline ships or stalls. It is never the architecture slide. It is the runbook.

This piece is about the runbook. I built an unattended agentic test pipeline over the Model Context Protocol — a five-agent SDLC (product manager, QA engineer, automation engineer, developer, pull-request reviewer) coordinating through MCP servers for Jira, Figma, Confluence, TestRail and GitHub, with hosted Claude as the orchestration model and an open-weights Hermes-3 as a validation baseline — and I ran it as an independent research project long enough to learn which production constraints the agent literature glosses over. What follows is the short list of things I now insist on before I let any agentic pipeline touch a shared system.

Composition contracts, or why the agent lied to itself

The most expensive failure mode I have seen in a multi-agent pipeline is not the model getting an answer wrong. It is agent A getting an answer right and agent B misreading it.

I watched this happen inside a run last month. The requirements agent produced a clean output with a field called acceptance_criteria that was a list of strings. The ticket agent expected acceptance_criteria to be a single markdown blob. Neither agent was wrong in isolation. Both were passing their own unit tests. What the pipeline produced was a Jira ticket whose acceptance criteria read, in full, the four characters [” — the JSON serialization of an empty first element. The test-plan agent read that, generated one test, marked it green and moved on. It took me until the pull-request stage to notice.

This is a composition fault. It is the natural failure mode of any system where independent components hand off structured data across a boundary they don’t jointly own. Distributed systems people have written about this for years — Martin Fowler’s tolerant reader pattern is the classical treatment — but the LLM literature mostly still treats it as a prompt problem. It isn’t. You cannot fix it with a better system prompt. You fix it with a typed handoff contract that both agents agree to before they run, plus a validator between them that fails loud when the shape drifts.

The heuristic I now use: Every agent-to-agent boundary gets a schema and a validator. Every agent gets a golden-input regression suite that catches contract drift before it reaches a downstream agent. Neither of those is glamorous. Both are the difference between a pipeline that produces work and a pipeline that produces a very expensive game of telephone.

If you want to know whether a team’s agentic pipeline is going to survive the first quarter, ask them what the contract is between agent one and agent two. If the answer is “the model figures it out,” budget for the cleanup.

Provenance, or the audit trail nobody wrote

The second thing I insist on now is that every artifact the pipeline produces has to answer three questions without a human doing archaeology: which agent produced it, which model call produced it and which upstream inputs the agent was looking at when it did.

This sounds like a nice-to-have. It is not.

Somewhere around week three of running the pipeline I hit a subtle case: the requirements agent was quoting a Confluence page back to itself. The MCP server for Confluence had returned an empty result on a first call, the agent had written a placeholder requirement, the second call had succeeded, the agent had retrieved its own placeholder and by the third pass it was citing that placeholder as source truth. The ticket said, entirely in earnest, that the requirement came from the design owner. It hadn’t come from anywhere. It had come from itself, four minutes ago.

You cannot debug that class of failure with logs of what the model said. You need logs of what the model was looking at. That means capturing the tool-call ID for every MCP call, stamping every artifact with the set of tool-call IDs it derived from and refusing to accept any retrieved fact into a downstream stage that cannot be traced to a real external source. I call it the prove-the-source rule. It’s boring. It’s a two-line requirement in the runbook. It is also the single guardrail that has saved me the most on-call time.

There is a nice side effect. When editors, reviewers or auditors ask where a decision came from, the pipeline can show them. That matters if you work anywhere near a regulated stack, and increasingly it matters everywhere else — the AI transparency and provenance framing in NIST’s AI Risk Management Framework is going to become the default expectation faster than most teams are budgeting for.

Cleanup and ownership, or why I now write the shutdown script first

The last thing that will surprise a team shipping their first agentic pipeline is the debris.

A pipeline that runs unattended for a week will leak. It will leak draft Jira tickets whose parent stories were never approved. It will leak GitHub branches for test suites that were never merged. It will leak TestRail runs that started, produced two results and never got a summary. It will leak Confluence page comments the agent posted while asking itself a clarifying question. None of these are bugs. They are the natural output of an autonomous system that starts more work than it finishes.

I learned this by accident. About six weeks into the project I ran a query on Jira for tickets created by the automation user in the past thirty days. I was expecting maybe 20. It was 91. 68 of them were [DRAFT] in the title and had not been touched by any human. I closed them by hand one afternoon, and while I was doing it, I understood that the pipeline had a silent second job I had never designed for: garbage collection.

Now every pipeline I run has three things I write before I write the first agent. A shutdown script that closes any artifact the current run has orphaned. A nightly reconciliation pass that closes any artifact any prior run has orphaned. And a single named owner — a human, on the org chart, with a Slack handle — for every downstream system the pipeline can write into. When the pipeline creates a Jira ticket, the ticket has a real assignee. When the pipeline opens a pull request, a specific reviewer is on the hook. When the pipeline files a TestRail run, someone gets pinged if it goes stale. The pipeline is not allowed to touch a system that does not have a named owner. That rule alone would have saved me the ninety-one-ticket afternoon.

There is one anti-pattern here I want to name outright. Do not, under any circumstance, let the agent close its own artifacts. I tried it. The agent, tasked with cleanup, closed the wrong thirty tickets and then confidently wrote a summary saying it had closed the right ones. Cleanup is a human loop or a deterministic script. It is not a model call.

The pipeline works. It saves real time on the right kind of work. It also costs real time on a shape of work most teams don’t put in the estimate: Contract validators between agents, provenance stamping on every artifact, a shutdown script, a reconciliation pass, a human owner for every downstream system and an unshakable rule against the model doing its own cleanup. None of that is glamorous. None of it is what the demo shows. All of it is the runbook, and the runbook is what determines whether a pipeline is a lab experiment or something the on-call engineer trusts enough to sleep through. The teams that write the runbook first ship. The teams that write it after the first Sunday incident spend the next two quarters catching up.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

AI agents are being connected to real systems faster than most organizations are learning how to secure them. That should concern us.

The first wave of AI security discussion has been useful, but limited. The industry has learned the vocabulary: prompt injection, indirect prompt injection, tool misuse, data leakage, excessive agency, unsafe retrieval, and broken authorization boundaries. These terms are important because they give teams a way to talk about risk. 

But vocabulary is not containment.

The harder problem is what happens after a dangerous behavior is discovered. A team may adjust a prompt, restrict a tool, add a guardrail, or change the surrounding application logic. That may solve the immediate issue. What it does not automatically solve is the next release, the next model change, the next tool integration, or the next developer who unknowingly breaks the assumption behind the original fix.

This is where AI agent security still feels immature. In traditional software engineering, serious bugs become regression tests. The lesson is captured in code so the same failure cannot quietly return later. Security should work the same way. Agentic systems need a way to preserve discovered failures as repeatable checks.

That is the gap the OWASP Agent Security Regression Harness is trying to address. As a community-led open-source initiative within OWASP, this project aims to turn security insights into practical engineering work.

Agent security is becoming a systems problem

A chatbot can give a bad answer. An agent can take a bad action. That difference changes the security model.

Once an AI system can call tools, inspect repositories, query databases, open tickets, summarize internal documents, interact with APIs, or trigger workflow automation, the boundary is no longer just the model. The boundary includes permissions, tool design, application logic, data flow, logging, authorization, and the assumptions developers made when they connected everything together.

The risk is not limited to strange model behavior; the risk is system behavior. An agent that reads untrusted content and treats it as instruction is not merely confused—it has crossed a trust boundary. An agent that leaks private context through a tool call is not just producing a bad response; it is exposing data through an action path. These are the kinds of failures teams will face as agents move from prototypes into production.

The security industry has seen this pattern before. Cloud platforms and CI/CD pipelines increased leverage, making teams faster but making configuration errors more consequential. Agentic AI is another increase in leverage. That is why a one-time review is insufficient. Regression testing exists for exactly this kind of problem.

The missing workflow in agentic AI

Security teams do not need another reminder that AI agents can be manipulated. They need a workflow that turns manipulation into evidence. A hidden instruction inside a support ticket should not remain a warning; it should become a scenario that can be rerun. A tool call that leaks context should become a check with a clear failure condition.

The value lies not only in finding the first failure, but also in preserving the lesson. Production incidents become postmortems, serious bugs become tests, and security findings become backlog items. AI agent security should not be exempt from that discipline simply because the system includes a model.

The challenge is that agents are harder to test than traditional code. A brittle test that expects one exact sentence will fail in real-world conditions. Useful agent security tests must focus on outcomes. Did the agent cross a boundary? Did the agent call an unsafe tool? Did it disclose protected data? The OWASP Agent Security Regression Harness provides a standardized way to work on these questions in the open, focusing on practical, reproducible tests.

Why OWASP matters for AI

OWASP is valuable when it turns security problems into shared practice. The OWASP Top 10 did not eliminate web application vulnerabilities; its value was giving teams a common language and a practical reference point. AI agent security now needs the same kind of shared structure.

The field is moving quickly, and fast-moving fields tend to produce two unhelpful extremes: one side turns everything into hype, while the other turns everything into fear. A regression harness is a more useful answer because it is narrow and practical. It does not claim to solve every AI security problem, nor does it replace threat modeling or architecture review. It simply provides a necessary method for teams to prove that their controls hold after the system changes.

OWASP project stewardship

Open-source security projects need clear technical direction to turn a broad concern into something engineers can understand, run, and maintain. Under the leadership of OWASP Project Lead Mert Satilmaz, the OWASP Agent Security Regression Harnesshas moved past a theoretical idea into a functional tool. Satilmaz is a widely known leader in the AI security community, and this is reflected in the practical direction he has set for the project and the engineering skill involved.

The project benefits from a focus on release discipline, contributor workflows, and wide adapter coverage—supporting everything from the OpenAI Agents SDK to LangChain/LangGraph. By generating machine-readable results, it allows security teams to integrate these checks directly into CI pipelines. This approach treats agent security as a systems engineering problem rather than just a model behavior problem.

The method is the contribution

One OWASP project will not solve agent security by itself. That is not the point. The important part is the method the project represents.

AI security needs to become less dependent on warnings, one-off demonstrations, and claims that are difficult to verify. It needs more repeatable scenarios, clearer evidence, and better ways to test system behavior under security constraints. Teams should not be satisfied with saying a weakness was fixed. They should be able to prove the relevant control still holds after the system changes.

The best security work often looks boring from a distance: a harness, a test case, a clean project structure, and a workflow that lets another engineer reproduce the problem. AI agents will continue to become more capable and more connected to sensitive systems. Security teams need methods that are as practical as the technology is powerful. Regression testing is one of those methods, and adopting this workflow is an important step toward making secure AI a reality.

Leadership wants to scale AI. Budgets are tripling. Adoption is up.

Then the CFO asks the question every board now asks: which of these initiatives is actually profitable?

Most organizations cannot answer that question, not because they lack visibility into cost, but because the cost data they have was never designed to produce that answer.

Applying lessons learned from managing cloud spend won’t be a fix for the AI and ROI quandary. True, cloud taught a generation of CFOs that billing without business context is noise. So to get cloud ROI, they stitched two data sources together: cost data plus business data. AWS reveals which account, which region, which tag, which resource. Merge in customer and product mappings on top and the ROI of the cloud spend comes into focus.

But AI is harder. It requires three data sources: cost, business, and telemetry—the automatic collection of data from disparate sources that helps to clarify the whole picture of what happened and why. An executive or engineering lead can have AI invoices and customer revenue. But they have no way to connect them to business value. The token count on the OpenAI invoice does not specify which customer triggered which call, which feature it served, or whether the prompt produced a business outcome. That data does not exist in the provider’s billing.

AI providers won’t fix this problem

The situation is not likely to change anytime soon because AI providers are not in the business of attributing an enterprise’s costs to that enterprise’s customers. Instead, AI providers are in the business of selling tokens. The granularity they expose is the granularity their billing systems require, not the granularity a CFO requires.

Not convinced? Compare what AWS gives you to what an AI provider gives you.

AWS billing exposes resource IDs, account hierarchies, region, SKU, tag metadata, usage by the minute. Every dollar can be attributed to a workload, a team, a customer segment if it was tagged correctly. The data is rich enough that mature FinOps teams built unit economics on top of it years ago.

An AI provider invoice gives you tokens consumed by model, with optional grouping by API key. That is the resolution. No request-level attribution. No customer ID. No feature mapping. No prompt outcome. No retry identification. Multi-step agent workflows collapse into a token count. Imagine a large bank receives a multi-million dollar AI invoice each month. But it has no visibility into what parts of the business were responsible for what parts of the cost so cannot allocate them.

If an enterprise wants to know what AI cost drove which customer or feature, it has to capture that data itself, inside an application, before the call leaves it. 

Three required sources

Building AI ROI measurement requires three data sources, stitched together in a single model.

1. Cost data, normalized across providers. Every AI provider delivers cost differently. OpenAI invoices in one taxonomy, Anthropic in another, fine-tuning vendors and inference platforms each in their own. Cloud GPU costs sit in AWS or Azure billing. Vector database costs land in Pinecone or Snowflake invoices. None interoperate by default. Normalization is necessary but not sufficient. It will put all your AI costs in one schema. It does not tell you what they produced.
2. Application-layer telemetry. This is the source most organizations are missing, and the one that makes AI ROI structurally different from cloud ROI. It requires instrumenting AI calls inside your application across six categories: request-level tracing tied to a customer or session ID; feature attribution tied to the product surface that triggered the call; agent-step capture for multi-step workflows; retry and fallback identification so recovery costs don’t get attributed to primary calls; model selection logging that records which model was chosen and why; and outcome capture that ties each call to whether it produced business value. None of this data exists in the provider’s billing. All of it has to be captured at the moment the call is made and stored in a system that can be stitched to the cost data.
3. Business data. Revenue, customer segments, product hierarchies, and feature usage. The same business data already feeding your CRM and analytics stack, mapped to the customers and features the telemetry layer attributes calls to.

Stitched together, the three sources produce the unit economics every AI investment decision now requires: cost per customer interaction, margin per feature, profitability per agent workflow, ROI per model choice. None of these can be calculated from billing data alone. None can be calculated from telemetry alone. They require all three sources, modeled together in a way that maps cost to outcome.

Why agentic AI makes this urgent

Single-call inference is the easy case. One request, one cost, one customer, one outcome.

Agentic workflows are different. An agent decomposes a task into multiple steps. Each step calls a model. Some steps fall back to a different model when the first fails. Some steps retry on a poor result. Some steps invoke external tools that themselves cost money. A single user request can produce dozens of inference calls across multiple providers, with the cost compounding in ways the provider invoice cannot disaggregate.

If telemetry does not capture agent-step granularity, no one will know which steps are profitable. Aggregate costs will show up three weeks later in the invoice. By then, the workflow has been running at scale, customers are onboarded, and unprofitable paths have been retried thousands of times.

When agents make the calls, the volume of cost-generating events without business context attached grows by an order of magnitude. The window for instrumenting this before it becomes unmanageable is closing.

What changes when the three sources come together

Once the three sources are stitched together, the AI investment conversation changes.

Five different ways to build the same AI capability stop looking equivalent. They converge on adoption metrics and diverge by 10x on cost. The team picks the approach that delivers a similar business outcome at one-fifth the cost, because the team can finally see the difference. Product teams design features with margin awareness from the architecture phase, not from the post-launch budget review. Engineering teams choose model architectures with cost-per-outcome data alongside latency and quality. Leadership evaluates AI initiatives the way they evaluate any other capital allocation: on unit economics, not on the engagement chart. Aggregated invoices track the cost per customer interaction. Engagement metrics reveal margin per feature. Gut-instinct model selection is checked against real cost-per-outcome model selection results. 

Within seconds, everyone can see which AI features are profitable, which should scale, and which should be killed. This is the insight everyone is looking for and companies that achieve it will optimize the benefits of AI.

The build trap

AI costs are compounding now. The board is not waiting 18 months for an internal project to reach production.

The temptation to build it anyway has never been sharper. AI coding tools have changed what a small engineering team can ship in a quarter. The instrumentation layer looks tractable. The cost normalization looks like a weekend project. The semantic model feels like something a senior engineer could draft over a sprint.

It is a trap. Three reasons.

Volume is the first. A production AI footprint generates millions of telemetry events per hour, and that volume scales with agentic adoption. Real-time ingestion, correlation, and attribution at that scale is not the same problem as vibe coding a prototype in an afternoon. It is a permanent operational system that has to be right every minute of every day.

The vendor landscape is the second. Cost data arrives in delayed billing windows from providers with non-interoperable schemas. Schemas change without notice. New AI providers enter the landscape monthly, each with its own taxonomy and metering. The system is not built once. It is maintained against a moving target that moves faster than most internal release cycles.

The third is what the first two add up to: this is business-critical infrastructure. The CFO and the board are going to make capital allocation decisions on the data this system produces. When schema drift goes unnoticed for two weeks, when an agent telemetry stream stops correlating to a vendor that quietly changed its billing API, the cost of being wrong is not a sprint of cleanup. It is a quarter of misallocated capital.

The build-vs.-buy question for engineering leaders has changed. It’s not “can we build this?” The honest answer is yes. The real question is whether the marginal hour of your strongest engineers is best spent stitching cost data to telemetry to business outcomes, or building the AI products that produce the revenue the cost data is measuring.

The capability is reproducible in weeks. The choice is whether to spend the next 18 months building it, or the next 18 months acting on it.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

A year ago, most enterprise AI systems generated recommendations. Today, AI systems are approving transactions, routing shipments, updating records, interacting with customers, and triggering downstream software actions with little or no human involvement.

For CIOs, that shift changes the central governance question. The challenge is no longer simply whether an AI model is accurate. It is whether the organization can explain, audit, and defend the decisions the system makes.

When an AI assistant suggests a meeting time or summarizes a document, mistakes are inconvenient. When an autonomous AI system issues a refund, reprices a product, modifies a customer record, or initiates a financial transaction, mistakes carry operational, legal, and reputational consequences.

When those consequences arrive, “the model decided” is not an acceptable explanation.

This is the accountability gap emerging at the center of enterprise AI adoption. Organizations are deploying increasingly autonomous systems while relying on technology that often provides little visibility into how decisions are made. The result is a growing mismatch between the level of authority organizations grant AI and their ability to understand or justify its actions.

Black-box AI may have been acceptable when AI primarily generated predictions. It becomes far more problematic when AI begins taking actions on behalf of the business.

The lesson software already learned

Fortunately, the technology industry has faced a similar challenge before.

As enterprise software systems became more distributed and complex, troubleshooting failures became increasingly difficult. Engineers could no longer rely on intuition to understand what happened when something broke. The solution was observability: the practice of instrumenting systems so their internal state could be understood through logs, metrics, traces, and monitoring.

The goal was not to predict every possible failure in advance. It was to create enough visibility that teams could reconstruct what happened after the fact and identify the root cause.

Enterprise AI now requires a similar discipline.

But AI observability must go beyond traditional software observability. It is not enough to know what action occurred. Organizations also need visibility into why the system believed that action was appropriate.

An auditable AI system should be able to answer questions such as:

• What information did the system rely on?
• Which tools or data sources did it access?
• What alternatives did it consider?
• What verification steps were performed?
• How confident was it in its conclusion?
• What events led to the final action?

These questions are rapidly becoming essential operational requirements rather than technical nice-to-haves.

Why visibility matters more as AI gains autonomy

As AI systems become more autonomous, failures become harder to detect and diagnose.

A human reviewing a single AI-generated recommendation can often spot obvious mistakes. A network of AI agents coordinating multiple tasks across business processes presents a different challenge. Decisions can build upon one another. A flawed assumption early in a workflow can propagate through subsequent actions, creating confident but incorrect outcomes.

The challenge is rarely identifying that something went wrong. Eventually, an error surfaces through a customer complaint, a failed transaction, an audit finding, or an operational disruption.

The challenge is determining why it happened.

Which information influenced the decision? Which tools were consulted? Which safeguards worked as intended? Which ones failed?

Without visibility into the reasoning process, troubleshooting autonomous AI workflows can become significantly more difficult than debugging traditional software systems.

For CIOs responsible for enterprise reliability, compliance, and governance, that lack of visibility creates unacceptable operational risk.

Moving toward glass-box AI

The answer is not to slow AI adoption. The answer is to make AI systems observable.

Increasingly, organizations are seeking AI systems that behave more like a glass box than a black box. The objective is not to expose every parameter inside a neural network. Rather, it is to provide a clear, auditable record of how decisions were reached and why actions were taken.

The most promising approaches share two common characteristics.

The first is verification. Instead of treating a single model’s output as ground truth, systems incorporate independent validation steps before actions are executed. Multiple agents, external checks, business rules, or verification workflows help identify errors before they become operational incidents.

The second is explainability. Effective systems maintain a decision trail that captures inputs, intermediate reasoning steps, tool usage, verification activities, and outputs in a form that human reviewers can understand.

Together, these capabilities create something that has long been expected of human decision-makers but is often missing from AI systems: the ability to show your work.

The regulatory and business reality

The push toward AI observability is not being driven solely by technologists.

Regulators increasingly expect organizations to demonstrate oversight of automated decision-making systems. Emerging AI governance frameworks place growing emphasis on transparency, traceability, accountability, and human oversight.

Customers are moving in the same direction. Whether the decision involves pricing, service, eligibility, or support, people increasingly want the ability to understand and challenge outcomes that affect them.

The result is a convergence of operational, regulatory, and market pressures around a single requirement: organizations must be able to explain what their AI systems are doing.

Three questions every CIO should ask

Before deploying autonomous AI systems, technology leaders should be able to answer three basic questions:

1. Can we reconstruct the complete decision path that led to an action?
2. Can we verify critical outputs before actions are executed?
3. Can a human auditor understand why the decision occurred?

If the answer to any of those questions is no, the organization may be granting more authority to AI than it can responsibly govern.

Accountability will become a competitive advantage

The organizations that succeed with autonomous AI will not necessarily be those that automate the most processes or deploy the largest models. They will be the organizations that combine automation with accountability.

Black-box systems made sense when AI primarily generated predictions. As AI increasingly acts on behalf of businesses, customers, and employees, visibility becomes essential.

The future of enterprise AI will belong not to systems that merely act, but to systems whose actions can be examined, understood, and trusted.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.