Local Context
for Autonomous Agents
Put telemetry, logs, and topology beside the agent. Use PromQL and files to keep retrieval reliable and model context focused.
Checkout latency is rising. An agent needs to compare revisions, inspect connection errors, and trace the downstream dependency. Before it can investigate, it has to navigate several observability tools, their schemas, and their failure modes.
We can design that environment differently: make the relevant data locally available, behind a small, stable interface. Telemetry through PromQL. Logs through files. Topology through a versioned snapshot. Let ordinary code prepare the evidence, so the agent can spend its turns interpreting it.
Available to the agent does not mean inside the prompt#
A workspace can hold millions of log lines while the model reads twenty. The distinction is between execution context—data the agent can access—and model context—tokens it must process to decide what to do next.
Loading every tool definition and every intermediate result into model context blurs that distinction. In one published configuration, Anthropic counted roughly 55,000 tokens across 58 tools from five MCP servers, before the conversation began. Similar tools also increase the opportunities to choose the wrong interface or supply the wrong arguments.
MCP remains useful for connecting systems. The avoidable cost comes from eagerly presenting the whole integration surface to the model. Tool discovery and programmatic execution already offer ways to reduce it: Anthropic’s code-execution approach loads definitions as needed and processes intermediate data outside the prompt. Cloudflare’s Code Mode likewise lets an agent compose MCP operations through code.
Local context takes a complementary step: materialize the working data near the agent, so successive questions can reuse it without successive provider calls.
Collect once, investigate repeatedly#
In my work on agent infrastructure, this led to an embedded time-series store. The broader architecture is a local context layer; the database is one part of it.
A deterministic collector loads the relevant services and recent time window. Provider adapters own authentication, pagination, retries, and normalization. They preserve metric types, units, and labels. Logs can be partitioned into newline-delimited JSON files; topology and deployment configuration can be captured as versioned JSON.
“Deterministic” describes the collection procedure: explicit resources, time ranges, and transformations. Live data can still change. Reproducing a query requires a captured dataset and fixed evaluation semantics.
The same pattern applies beyond observability: a research agent can query a local paper index and read PDFs; a coding agent can search a checked-out repository and inspect test artifacts. The collector changes; the separation between accessible data and selected model context stays useful.
The agent gets a manifest of coverage and freshness, a catalog of available metrics, and a compact access interface. Our telemetry design uses temporary local chunks, memory mapping, and an embedded PromQL engine. Complete chunks are published atomically for readers; there is no separate database daemon to operate per session.
The useful contract is small enough to understand at a glance:
| Evidence | Local representation | How the agent reads it |
|---|---|---|
| Telemetry | Indexed time series | PromQL selectors, rates, and aggregates |
| Logs | NDJSON files by service and time | rg / jq, with bounded excerpts |
| Topology & config | Versioned JSON snapshots | Read files and follow dependency edges |
| Coverage | Manifest and metric catalog | Check time windows, labels, freshness, and gaps |
From a 5XX spike to a shared dependency
An illustrative workspace with a fifteen-minute window. Query results and observations are examples, not production measurements.
- New revision
- 8 errors/s
- Control revision
- 0.1 errors/s
Locate the failing revision
- What happens
- A local PromQL query shows that checkout 5XX responses concentrate in the new revision. Its request rate is comparable to the control.
- What it means
- The deployment is a lead. The error rate alone does not identify the failing dependency.
- What the system does
- Return a small aggregate, then inspect matching logs in the same window.
Inspect the example record
{
"snapshot": "checkout-window-07",
"evaluation_time": "10:15 UTC",
"query": "sum by (revision) (rate(http_requests_total{service=\"checkout\",status=~\"5..\"}[5m]))",
"result_unit": "errors/second",
"result_rows": 2,
"additional_provider_calls": 0
}- Repeated error
- pool_timeout
- Affected dependency
- orders-db
Follow the pool timeouts
- What happens
- The mounted log file contains connection-pool timeouts for orders-db. The agent reads a bounded excerpt and keeps the path for follow-up queries.
- What it means
- The bottleneck may be connection acquisition inside checkout. A database-related error does not by itself establish a database outage.
- What the system does
- Search the existing file, then compare pool occupancy with database health.
Inspect the example record
{
"file": "/context/logs/checkout/10-00.ndjson",
"command": "rg -n -m 20 'pool_timeout' /context/logs/checkout/10-00.ndjson",
"output_byte_limit": 8192,
"additional_provider_calls": 0
}- Database query latency
- Stable
- Checkout pool
- At capacity
Separate the cause from its upstream impact
- What happens
- The topology snapshot connects storefront to checkout and checkout to orders-db. Database query latency stays flat, while the new checkout revision exhausts its pool. Storefront sees the resulting timeouts.
- What it means
- Connection handling in checkout is a stronger hypothesis than a slow database. Upstream errors are part of the impact, not independent proof of another failure.
- What the system does
- Record the evidence and request a historical baseline only if the local manifest says it is missing.
Inspect the example record
{
"topology": "/context/topology/services.v42.json",
"query": "max by (revision) (db_pool_in_use{service=\"checkout\"})",
"missing_baseline": "targeted fetch through collector",
"retrieval_failure": "explicit coverage gap",
"additional_provider_calls_for_loaded_data": 0
}Remove remote failure modes from the inner loop#
Once a window is loaded, querying it cannot fail because a provider token expired, a remote API was rate-limited, or pagination broke halfway through that query. Those concerns belong to ingestion and refresh, where ordinary code can handle them consistently.
This removes avoidable tool-call failures from repeated analysis. It does not make every query correct: an agent can still select the wrong metric, misread a counter, or overlook missing coverage. A smaller interface should expose those errors clearly. The Prometheus query model provides useful semantics for time selection and evaluation; a local implementation must document the subset it supports.
Keep the working set bounded. Prefetch likely evidence, hydrate missing ranges deliberately, and give queries output and resource limits. A manifest should say what is absent or stale. Read-only source data and separate scratch space keep exploration from altering the evidence.
Measure the whole investigation#
Compare tool-definition tokens, result tokens, failed remote calls, time to first useful evidence, and task success. Include initial hydration and refresh costs. A faster local query is valuable only if the complete investigation improves.
The architectural payoff is a clean separation: collectors handle data movement, local interfaces handle selection, and the model handles interpretation. Rich context can remain within reach without occupying the entire conversation.
The same arrangement supports checkpoint replay for long-horizon evaluation: give the agent a workspace reconstructed for a particular moment, then observe what it decides.