DEV Community: Opsphere

Beyond Copilots: What AI Agents Need to Understand Cloud Operations

Opsphere — Fri, 23 Oct 2026 00:29:52 +0000

Why useful infrastructure investigations depend on operational context, clear boundaries, and verifiable evidence.

Giving an AI agent access to infrastructure tools creates possibilities. It also raises an engineering question: how can that agent investigate a real cloud environment while respecting permissions, operational boundaries, and security requirements?

This question shapes our perspective at Opsphere.

As José Julián Ariza, CEO of Opsphere, joins the AI Congress Barcelona session on AI agents, multiagent systems, and orchestration, we want to share the practical challenge behind that discussion.

Engineers need more than an agent that can call tools. They need help understanding what is happening in production, why it might be happening, and what evidence supports the next decision.

Tool Access Is the Beginning

Consider an engineer investigating a slow application.

An agent might be able to retrieve logs, inspect infrastructure, and review a recent deployment. Those capabilities provide useful observations.

Turning them into an investigation requires knowing how the observations relate.

Which environment serves the affected application? Does the deployment belong to the service under investigation? Are the errors recent? Is the apparent dependency actually part of the affected request path?

Without those relationships, an agent can collect accurate information and still reach an incorrect conclusion.

Operational understanding requires both reliable observations and enough context to interpret them.

Real Environments Have Boundaries

Production infrastructure contains distinctions that matter: separate accounts, environments, services, teams, and permission scopes.

An investigation must preserve those boundaries.

An engineer asking about a production endpoint should receive findings grounded in that environment. Evidence from a similarly named service in another account could lead the investigation in the wrong direction.

Permissions also shape what an agent can establish. If access to a relevant system is unavailable, that limitation should remain visible. Missing evidence should become an explicit gap in the investigation.

The distinction between observation and action matters equally. Permission to inspect a resource does not automatically authorize changing it. A workflow that retrieves logs has different consequences from one that modifies configuration or restarts a service.

Useful agents need a clear scope for both the information they can access and the operations they can perform.

An Explanation Needs Evidence

Suppose errors increase shortly after a deployment.

The timing makes the release worth investigating. It does not, by itself, establish the cause.

The agent should examine whether the affected requests reached the new version, whether the changed code could explain the symptoms, and whether a dependency was already degrading.

A useful investigation makes its reasoning inspectable:

What was directly observed?
Which explanation does that observation support?
What evidence contradicts the explanation?
What information is still missing?
Which check would help resolve the uncertainty?

These questions turn a plausible narrative into something an engineer can assess.

The distinction becomes especially important under pressure. A confident explanation can influence a production decision even when its supporting evidence is weak.

Engineers need to understand how a conclusion was reached and what remains unverified.

Multiagent Systems Need Shared Investigative Discipline

Multiple agents can divide investigative work. One might examine infrastructure state, another review deployment history, and another inspect application errors.

That division is useful when each contribution remains tied to the same incident scope.

The agents need to work against compatible environments and time windows. Their findings need identifiable sources. Contradictions need to survive the handoff so the overall investigation can address them.

Agreement alone is insufficient. Several agents may repeat the same assumption or rely on the same incomplete source.

Orchestration therefore involves more than assigning tasks. It must preserve the relationships between questions, evidence, findings, and unresolved uncertainty.

The result should help an engineer follow the investigation without reconstructing every step.

What We Are Building Toward at Opsphere

At Opsphere, our direction is grounded in this operational challenge: helping engineers use AI to understand complex cloud environments and make better-informed decisions.

That means treating context, access boundaries, and evidence as central parts of the engineering problem.

The questions guiding this work are practical. Can the investigation identify the right environment? Can findings be traced to operational information? Can the engineer distinguish an observation from an inference? Does the workflow make its limitations clear?

These are useful criteria for evaluating AI agents in cloud operations, alongside the tools they can access and the tasks they can coordinate.

A Practical Standard for Progress

Moving beyond copilots should produce a concrete improvement in how engineers investigate systems.

An engineer should be able to ask a scoped operational question, inspect the supporting evidence, understand the uncertainty, and decide what to do next.

That is the direction we are working toward at Opsphere—and the perspective we bring to the conversation at AI Congress Barcelona.

More context. Less friction. Better engineering decisions.

Your API Is Failing. The Explanation Is Spread Across Five Tools. Meet Opsphere.

Opsphere — Fri, 16 Oct 2026 17:13:26 +0000

Ever received an alert that tells you exactly what is failing, only to discover that figuring out why means opening half your stack?

First, you check the errors. Then the latest deployment. Then Kubernetes. Someone asks whether anything changed in infrastructure, and now you’re digging through AWS too.

Every tool has useful information.

Connecting it is still your job.

And while you’re piecing everything together, someone asks the question that always arrives a little too early:

“Do we know what happened yet?” 😅

That’s the problem Opsphere aims to solve: gathering scattered operational signals so teams can understand what’s happening in production.

What is Opsphere?

Opsphere is an operational intelligence platform for development, DevOps, and SRE teams. It connects infrastructure, observability, deployment, and code systems to investigate problems using the context those tools already hold.

An error might live in Sentry, the related code change in GitHub, and the service’s runtime state in Kubernetes.

Opsphere queries those sources and connects relevant information.
Operational data stays in its source systems, while Opsphere retains context and investigation knowledge. It operates in read-only mode by default. Platform overview.

Put simply, it aims to reduce the work of manually reconstructing the same story across several browser tabs.

First problem: every tool tells part of the story
Imagine this hypothetical scenario.

An endpoint starts returning errors after a deployment. The immediate reaction seems obvious: investigate that deployment.

That’s a reasonable starting point. But the connection still needs evidence.

A dependency could have stopped responding. The service could be running out of resources. A network change could be involved.

Opsphere’s approach is to structure that investigation: query current information, compare multiple hypotheses, and separate observations from inferences. Its findings include supporting evidence, calculated confidence, and conditions that still need verification. Investigation approach.

That’s the part I find interesting.

A convincing explanation can waste your time if it sends you looking in the wrong place. You need to be able to inspect what supports it.

“Errors started after the deployment” is useful.

“The deployment caused the errors” requires more work.

Second problem: bringing context into your workflow
Querying a tool through an assistant is useful. Investigating a failure that crosses several systems takes more coordination.

The public Opsphere plugin connects operational tools to an AI agent through a remote MCP gateway. MCP provides a way for compatible clients to access those capabilities.

That brings operational queries into the developer’s working environment.

For the hypothetical incident above, a request could look like this:
Investigate this service’s errors since the latest deployment. Compare possible causes and identify what evidence is missing to confirm each one.

That’s an illustrative request, not a result from a live test.
What I’d want from the response is concrete: sources checked, observations, contradictions, and next steps.

With that information, I can decide what to verify next. I can also explain to the team why we’re investigating one possibility before another.

Third problem: the next investigation starts from scratch
Resolving an incident doesn’t guarantee that the team retains what it learned.

Sometimes there’s a document. Sometimes there’s a very long chat thread. Sometimes there’s one person who remembers which service depends on which.

Opsphere describes investigation memory and relationships between services, environments, repositories, and accounts. Relevant context can be retrieved when a new problem appears. Operational context.

The practical appeal is straightforward: the next investigation starts with useful background already available.

There’s an important boundary here, though. Two incidents looking similar doesn’t prove they share a cause. Previous findings should help shape the questions. Current evidence still needs to support the answer.

What I’d check in a real trial

Before evaluating a tool like this, I’d try it against an incident whose cause was already known.

Does it find the relevant signals? Can it distinguish a suspicion from a confirmed cause? Does it acknowledge missing permissions or data? Can I follow its references and review the conclusion?

Those answers would tell me more than a demo where everything lines up on the first attempt.

Opsphere targets a familiar source of friction: connecting information during an investigation. That’s where I’d measure its value.

You can explore Opsphere’s platform and inspect its plugin on GitHub.

During your last incident, what took longer: finding the right information or proving how it connected to everything else?