How Much Context Does an AI Agent Really Need?

The ROI of Better Context

AI agents become expensive when they spend model time reconstructing relationships that already exist across production systems. Every source-specific payload consumes context, adds latency, and increases inference cost before the agent can answer the actual question.

The business case for unified production context is broader than token savings. It means more investigations per budget, faster feedback in incident and delivery workflows, and less model capacity spent joining infrastructure data.

Anyshift resolves production relationships before inference, so the model receives a compact, task-relevant view instead of carrying every available source object. We ran a live infrastructure benchmark to measure whether that architectural choice produced meaningful operational ROI.

Why the Graph Uses Fewer Tokens

The optimization comes from moving the join before inference. With separate MCPs, Kubernetes and AWS arrive as two unjoined payloads plus their tool schemas. The model must carry both sources and reconstruct the dependency path itself.

With Anyshift, the graph starts from the task's node, traverses only relevant relationships, and returns one reachable subgraph: node → pods → workloads → services and node → EC2 → EKS → VPC. The model receives the joined dependency path instead of the source payloads and schemas. For this task, mean model-token usage fell from 116,451 to 21,824, an 81.3% reduction.

What the Live Benchmark Found

We tested both approaches against the same live EKS environment. Across six matched runs where each setup completed the full evaluation rubric, the unified graph approach used 83.5% fewer model tokens per task and returned sooner.

Every matched run favored Anyshift on token use. The mean difference was 90,186 tokens per task, with a paired bootstrap 95% interval of 76,330 to 110,929 fewer tokens and an exact paired p=0.03125.

The Full Live Test Program

The three tests below include two matched-outcome deep dives and one directional ablation. Across the primary study, Datadog extension, specialist fallbacks, and progressive ablation, we completed 84 final live agent sessions across eight task designs.

This article focuses on the two task cells where Anyshift and the separate MCP setup completed the same evaluation rubric in every matched repetition, plus the progressive ablation. Other task cells were excluded from the paired comparison because they surfaced Graph SDK/API coverage or freshness gaps rather than equivalent outcomes.

Test 1: Should This Readiness-Probe Patch Merge?

The proposed patch changed a Kubernetes readiness probe from the named port http to hard-coded port 8081. The agent had to compare that patch with current runtime evidence, decide whether it was safe, explain the production consequence, and recommend a correction.

Both approaches reached the same decision in every run: block the patch. The difference was how much production context the model had to carry before it could get there.

Anyshift connected the proposed 8081 value to live readiness failures, the real 8080 listener behind the named port, and the affected workloads. The agent received the relationship instead of a collection of unrelated resource documents.

Test 2: What Fails With This Kubernetes Node?

The second question started with a node name and asked for the full operational blast radius. The answer needed the affected checkout workloads, the backing EC2 instance, the EKS and VPC placement, and a conclusion about single-point-of-failure risk.

Anyshift traversed the node's live relationships and returned a compact answer: 21 pods across 15 workloads and 11 services, mapped through its EC2 instance to the EKS cluster and VPC. Both approaches completed the task in every matched run.

Test 3: What Happens When Three MCPs Accumulate?

We ran a progressive live ablation on one cross-source incident task. The agent had to combine Kubernetes rollout evidence, AWS placement, and current Datadog APM dependencies. Each setup ran three times against the same environment and rubric.

Against the full Kubernetes + AWS + Datadog setup, the Graph SDK/API used 88.0% fewer model tokens, completed 63.6% faster, and reduced estimated cost by 62.0% under GPT-5.5 pricing and 62.6% under Claude Sonnet 4.6 pricing.

This test is directional rather than a matched-outcome comparison: specialist MCPs verified current-source details that the Graph SDK/API did not expose. With three pairs per setup, the exact two-sided sign-flip test is p=0.25.

How We Ran the Benchmark

Why Cost Fell Less Than Tokens

The model runner reported uncached input, cached input, and output tokens separately. The MCP-heavy sessions reused substantial cached context, so removing 83.5% of gross tokens did not remove 83.5% of estimated spend.

The cost scenarios use published standard rates as of July 13, 2026: GPT-5.5 at $5 per million uncached input tokens, $0.50 per million cached input tokens, and $30 per million output tokens; Claude Sonnet 4.6 at $3 per million input tokens, $0.30 per million cache reads, and $15 per million output tokens.

These figures reprice the observed token traces. We did not rerun the benchmark with GPT-5.5 or Claude Sonnet 4.6.

The Takeaway

The graph reduced agent overhead by resolving production relationships before inference. In matched tasks, that meant fewer tokens per task, faster completion, and lower estimated cost without changing the outcome.