Groundcover routes production debugging from Claude and Codex to its own agent

An engineer asks a coding agent why a service it helped change is failing in production. The agent can review a pull request and work out from the code how the software is meant to behave, but its view usually ends at deployment ^[3]. Shahar Azulay, groundcover's co-founder and chief executive, said agents "can't tell you what already did happen in production unless they have access to the evidence." ^[4]

Groundcover calls its answer agent-to-agent observability ^[2]. Under the label there are two entry points. An agent that already knows which evidence it wants pulls logs, traces and Kubernetes events straight from groundcover's MCP tools ^[6]. An agent with a vaguer problem files an asynchronous Agent Task and gets a job ID back right away ^[7]. It then moves on while groundcover's agent investigates in the background; later it gets back either a finished root cause analysis or a draft dashboard, whichever the request called for ^[8].

Both paths are narrow. Either the agent fetches records it can already name, or it files a request and waits for a conclusion written by another vendor's agent.

The buyer is a team that already runs one of the named coding agents and does not want to teach each of them to read telemetry. Azulay said an agent can delegate the digging to groundcover without having to "become an observability expert." ^[5] Claude and Codex are named in the announcement, and Cursor and Amazon Web Services' Kiro can connect through MCP as well ^[9]. The data has to be in groundcover first. A single sensor captures application and infrastructure behavior without every service being instrumented, and everything runs in a bring-your-own-cloud design that keeps telemetry in the customer's own cloud account ^[15][14]. Engineers who do not live in a coding agent get the same agent through Agent Mode, or through @groundcover in a Slack incident thread ^[10][11].

Customers pay by the node ^[16]. Because data volume does not drive the bill, groundcover says, teams are not penalized for keeping more data at higher fidelity, and it argues an agent needs that depth to investigate accurately ^[17]. SiliconANGLE's account does not include a per-node price or any usage data from customers, and the launch gives no figure for how long Agent Tasks take to answer. It does say the company has raised $160 million to date, including a $100 million Series C led by One Peak in July ^[13].

Nothing in the launch says who reviews the agent's root cause analysis. The customer has to assign that job.

We would sort recent incidents on two axes. The first is whether the investigator knew which logs, traces or events to open first. The second is whether the answer could wait for a background job. Known evidence belongs with the MCP tools whether or not the answer can wait. Vague evidence with time to wait is the case Agent Tasks were built for. Vague evidence with no time to wait is the cell to test before trusting.

The simplest test is a short replay: a handful of closed incidents from the vague-and-can-wait cell, run as Agent Tasks, with each root cause analysis compared against what the team concluded at the time. If that cell is nearly empty in a team's history, the asynchronous path has little to do for it, and the MCP tools are the part to evaluate.