Customers Stories: Why MCPs are not enough for an AI SRE

TL;DR

Two customer investigations show how a context graph was key to helping agents retrieve the right data by tracing changes and shared dependencies.

Some context is unavailable if the events were not retained

An agent can read a resource’s current configuration without knowing how it changed before an incident. If no source retained the relevant history, a tool call cannot retrieve it. Anyshift also needs that history to have been ingested and retained. The investigation below shows what retained events and resource relationships can reveal, and what remains unknown.

Investigation #1: In a recent customer investigation, users reported intermittent 404 errors when loading images. The agent needed to find what the affected delivery paths had in common and check whether a recent infrastructure change could explain the failures.

What if the agent queried Datadog events? Its search_datadog_events tool could retrieve relevant CloudTrail events if they had been ingested and retained. That could surface a web ACL creation or configuration event, with the time and resource identifiers recorded by the source. This is an alternative retrieval route, not a tool run from this investigation.

What would still be missing? The connection to the failing image paths. In the actual investigation, Anyshift followed resource relationships and found two CloudFront distributions protected by the same web ACL, the configuration that defines WAF filtering rules.

The agent then retrieved the web ACL’s history and a group of 14 correlated events, including configuration events referencing two rule groups in another AWS account. This connected a shared dependency to recent changes; it did not establish that those changes caused the 404s.

Via source tools: retrieve changes, then reconstruct the dependency path.

1. Find the changes

• Search retained events around the incident
• Retrieve web ACL and rule-group events

Event times + resource IDs

→

2. Read resource links

• Find the image-delivery distributions
• Check which web ACL protects each one

CloudFront + WAF records

→

3. Connect the evidence

• Match resource IDs across sources and accounts
• Compare changes with shared dependencies

Alternative plan, not replayed

What the investigation retrieved: past events and shared protection.

Retained events + observed resource links

Shared protection confirmed; cause of the 404s unconfirmed. Validate the triggering change and request-level blocking evidence.

An event becomes useful when the agent can connect it to the services it concerns. Here, retained history and cross-account relationships revealed a shared security dependency. They narrowed the investigation without establishing that the change caused the failures.

Map event-to-service connections with 3x fewer tokens

Investigation #2: In another customer investigation, a user asked Anyshift to map how events reached their production services.

As part of that investigation, they needed to identify which EventBridge rules triggered the relevant Lambda functions and what events those rules matched.

Here is the token breakdown for that lookup: Anyshift’s measured results versus an estimated AWS MCP plan that retrieves rules and targets separately, then joins and filters them on the fly.

Compare AWS API MCP to Anyshift Graph API

List all 61 rules, then fetch each rule’s targets via MCP.

1. “ListRules”
via MCP

• Names61 × ≈22 ≈ 1,340
• Event patterns61 × ≈30 ≈ 1,850
• JSON + overhead: ≈2,190

≈5,380tokens

+

2. “ListTargetsByRule”
via MCP

• Target ARNs + overhead≈282 tokens per response
• 61 responses × ≈282

≈17,230tokens

=

Returned to the agent

• Rules: ≈5,380
• Targets: ≈17,230

≈22,610tokens

Query stored connections and return only matches for the selected Lambda functions.

1. Query and filter the graphFind rules targeting the selected Lambda functions.

Across 61 rules, the query returns 37 matching rule–Lambda connections.

4,747tokens

→

2. Read the results

• Graph Query Results: 4,747
• Query response: 723

5,470tokens

75.8% fewer response tokens relative to the central estimate. Much of the gap comes from repeated tool wrappers: projected AWS data alone accounts for 5,339 tokens. This is specific to the modeled call_aws path.

This was a small lookup within one AWS service. Cross-domain investigations add more records and relationships to reconcile. A shared graph moves that matching work out of the agent’s context window, so it can retrieve the relevant connections instead of reconstructing them from separate responses.

Give agents a connected view of production

Debugging production means working across infrastructure, application code and monitoring data, all changing over time. Tool access is the starting point. The agent also needs to know how those sources fit together and what was true at the time of the incident.

That is why we build around a graph. It provides a shared index of resources, dependencies and retained events, letting agents query across sources without rebuilding every relationship during each investigation. Selecting relevant evidence before it reaches the model can reduce token costs and unnecessary context. The same connected view can support an incident investigation or a review of a proposed change’s production impact.

MCP can expose that graph to the agent. The goal is to give each agent the context its task requires, with recorded links it can follow and gaps it can recognize. Missing history stays missing, and correlation still needs verification.