How Open-Inspect and Causely close the loop on autonomous remediation

TL;DR

Open-Inspect gives a background agent somewhere to run: a full development environment, triggered by an event, with no human at the keyboard. Causely gives that agent a causal diagnosis instead of a pile of telemetry to interpret. The Cloud & Platform Operations team at Fountain wired both together for proactive production ops, and the pattern is now documented in a runnable example.

On June 12, 2026, we ran a live session with Cole Murray, creator of Open-Inspect, and Martin Roberts, Cloud & Platform Operations lead at Fountain. The topic was proactive remediation: agents that fix issues before anyone notices, not agents that wait for a page. Watch the recording for Martin's walkthrough of the production setup. This post provides more detail on the mechanics behind this setup and includes a link to a working example.

What does Open-Inspect run?

Open-Inspect is an open-source background coding agent, built by Cole Murray and modeled on Ramp's internal Inspect tool. It gives an agent a full development environment (Node.js, Python, git, browser automation, VS Code) and lets that agent pick up work from a webhook, a cron schedule, a Slack message, or a monitoring alert, then run unattended until the task is done.

Two important aspects of Open-Inspect are relevant to ops use cases. First, sessions persist: an agent can run for minutes or hours and be re-triggered later on the same thread, which fits an investigation that doesn't resolve in one shot. Second, the security model is single-tenant by design. Every user in a deployment shares the same GitHub App installation and repository access. That works for a trusted internal team where everyone already has access to the same repos. Everyone sharing that deployment shares the same GitHub App access. Organizations with multiple teams that need separate boundaries can run separate deployments, one per team, rather than pooling everyone into one.

Open-Inspect decides where an agent runs and what it's allowed to touch. It has no opinion on why and when to act. This is the context it needs to receive from another source.

What does Causely add to a background agent?

An agent with a working development environment and repository access still must be told what to act on. It's similar to the point we made in our blog about Claude Managed Agents: an agent that can reach every system in your environment still isn't one you'd trust to act on a guess.

The Causely MCP server gives your agent a specific, mechanistic diagnosis, such as Postgres idle-in-transaction accumulation or Redis cache miss storm, that is distinct from the symptoms it produces. A peer-reviewed study we published showed that agents working from Causely's causal context reached a diagnosis 2-3x faster than agents reasoning over raw telemetry.

How does Causely make agents faster?

The reason agents leveraging Causely diagnose problems faster is that they never need to rebuild the environment's dependency structure at query time. Not only dependencies between entities in the environment, but also the symptoms that may be observed and the potential causes that could produce those symptoms given the topology at that moment in time. Read the full benchmark study for the methodology here.

How does the integration work?

Open-Inspect answers where and how an agent can act. Causely answers when and what it should act on. An agent with both can efficiently move from an issue to a verified fix without a human bridging the gap.

Causely runs continuously over the environment, ingesting telemetry locally and maintaining a semantic understanding of the system. When it identifies an issue, a webhook fires carrying both the issue and the diagnosis. That notification routes to the specific background agent with repo access for that environment. The agent calls get_issue_details to retrieve the causal context behind it and other Causely MCP tools, likeget_logs, if it needs more evidence. Then it opens a PR.

The agent never starts from a raw alert. The webhook already carries a diagnosis, not a symptom. get_issue_details and get_logs add depth to that diagnosis. They don't build it from scratch. The output is a PR, and a human reviews the fix to verify the change before it ships.

Fountain runs this exact sequence: webhook, get_issue_details, get_logs if needed, PR. An engineer reviews and merges from there. Martin described fixing issues before the traditional alert would have fired, let alone before any end-user escalation:

"An agent works right away. It receives the request and, within seconds, identifies the root cause with help from the Causely MCP tool. Within minutes it has the pull request ready. That is much, much faster than how any ops team can function while working on the problem".

— Martin Roberts, Cloud & Platform Operations lead at Fountain

What to do next

• Watch the full webinar for Martin's production walkthrough and the live Q&A.
• Read the causely-oss example and adapt the trigger pattern to your own alerts.
• If you're building a custom agent instead, start with Causely MCP Skills for the tool-selection logic Open-Inspect's example already uses.

FAQ

What's the difference between Open-Inspect and Causely? Open-Inspect is a background agent execution system: it decides where an agent runs and what it's allowed to touch. Causely is a causal reasoning system: it determines what issues need to be acted on and when. Open-Inspect provides the environment; Causely provides the diagnosis. Neither replaces the other.

Can a background agent remediate an issue without a causal model? It can work for specific events and runbooks that you have defined in advance, and it can work for localized, code-level problems. But in environments with many dependencies and complex topology, a background agent seeking to remediate an issue without a causal model is just as likely to make the situation worse as it is to fix the root cause. A causal model ensures the agent acts on the cause of the observed anomalies, rather than on the symptoms themselves.

Is Open-Inspect safe to deploy across multiple teams? Open-Inspect is single-tenant by design: everyone in a deployment shares the same GitHub App installation and repository scope. It's built for a trusted internal team with shared repository access, not for isolating multiple organizations or teams with different permissions within a single deployment.

How do I trigger a background agent from a production alert? Open-Inspect sessions can be triggered by webhooks, so a monitoring alert can start a session directly. The session then queries Causely for a diagnosis before taking any action, rather than starting from the raw alert payload. The causely-oss example documents this trigger pattern end-to-end.