Skip to main content
Two agents on the same model, the same tools, and the same incident can differ by an order of magnitude in usefulness. The difference is context. This is where “garbage context in, garbage autonomy out” becomes an engineering discipline.

2.1 Why context beats model choice

Frontier models are increasingly interchangeable for operations reasoning; what is not interchangeable is what they are given to reason about. An agent that knows your topology, your deploy history, your conventions, and your past incidents will out-diagnose a smarter model that knows none of them. The industry has converged on a name for this discipline — context engineering: the systematic design of what enters the context window, how it is structured, and when it is evicted or refreshed. Two findings from current practice anchor the discipline. Bigger windows did not solve it: model performance degrades as context bloats with irrelevant material, so curation beats accumulation. And in multi-agent systems, context is the multiplier on cost — routing each agent only what its task needs is the difference between viable and unviable economics.

2.2 The five context sources of an operations agent

  1. Topology and inventory. What exists and how it connects: services, dependencies, infrastructure resources, ownership. This is the skeleton every hypothesis hangs on — “what changed upstream of the symptom?” is unanswerable without it. It must be discovered and refreshed, not hand-maintained; stale topology is worse than none because it is trusted.
  2. Change history. Deploys, config changes, infra mutations, feature flags — time-ordered and attributable. The majority of incidents correlate with a change; an agent without the change stream investigates with one eye closed.
  3. Operational knowledge. Runbooks, SLO definitions, architecture notes, conventions (“we always drain before scaling down”), known failure patterns. Imperfect is fine; absent is not. This is tribal knowledge made machine-readable — and it compounds.
  4. Incident memory. Past investigations, what the root cause was, what fixed it, what didn’t. Retrieval over this corpus is how the second occurrence of a failure gets resolved in minutes instead of hours — the compounding the Field Guide promised, delivered mechanically.
  5. Live telemetry. Metrics, logs, traces, events — pulled on demand by tools during the loop, never bulk-loaded. The context layer decides what is worth pulling; the tool layer pulls it; summarization decides what survives into the next step.
Figure 1 — The context stack: durable knowledge (topology, changes, runbooks, memory) assembled per task; live telemetry pulled on demand; everything filtered by a context budget.

2.3 Assembly: the context budget

Treat the context window like a production resource with a budget and an allocation policy. A workable starting allocation for an investigation step: a stable system core (identity, policies, output contracts); the task frame (the incident record so far, pinned so it cannot scroll away); retrieved knowledge (top-k runbooks and similar incidents, re-ranked, with citations back to source); and a working set of tool results (recent results verbatim, older results as agent-written summaries with pointers to the full data). Retrieval discipline matters more than retrieval technology: high-recall retrieve then aggressive re-rank to a precise top-few beats dumping fifty chunks and hoping — the “lost in the middle” failure is real and measurable. Eviction is the other half. Long investigations must compact: the agent summarizes its own trajectory (“checked X, ruled out Y because Z”) and drops raw excerpts, keeping pointers so any claim can be re-expanded and audited. Compaction is also where fabrication sneaks in — summaries must be traceable to the evidence they compress, which is an evaluation target in Chapter 7.

2.4 Memory: what to write, what to decay

Persistent memory is where an agent deployment becomes un-copyable — and where it can quietly rot. Engineering rules that survive contact with production:
  • Write conclusions, not transcripts. Persist the incident summary, root cause, fix, and verification — not the 300k-token trajectory. Structure it (entities, symptoms, cause, resolution) so retrieval hits on the pattern, not the prose.
  • Provenance on every memory. Who wrote it (human, agent, import), from what incident, when, and with what confidence. Unattributed memory is how one bad conclusion poisons a hundred future investigations.
  • Decay and challenge. Memories age: topology changes invalidate old causal paths. Time-decay relevance, and let contradicting evidence flag a memory for review instead of silently coexisting with it.
  • Human-curated tier. Keep a small, high-trust layer — conventions, standing decisions, “never do X on the payments cluster” — that only humans edit and that always outranks learned memory. This is also a policy surface, not just a quality surface.

2.5 Discovery: context as onboarding

The fastest-moving platforms treat context acquisition as a product phase, not a documentation request. On connection, the system discovers: it walks the cloud accounts and clusters read-only, builds the topology and inventory, ingests the change stream, and drafts its own system map for human confirmation. Discovery is what makes an agent useful on day one and safe later — a system that understands the estate can predict blast radius before it ever requests write access. It is also the engineering foundation under a strategic direction the whole category is heading toward: operations where the human does not prompt at all, because the system already knows the estate well enough to bring findings, plans, and evidence to the human for approval. The context layer is what makes that credible rather than reckless.
IN PRACTICE — DISCOVERY BEFORE AUTONOMYCloudThinker’s onboarding runs Connect → Discover before anything else: read-only credentials, an automated walk of the estate (clusters, services, databases, cost surfaces), and a generated system map plus first findings — deep investigation and a fix plan produced entirely on read-only access. Write access, and the trust ladder that governs it, comes only after the human has seen the system’s understanding of their world. The evaluation question for any platform: what does it know about your estate one hour after connection, and can it show you?
KEY TAKEAWAYContext is the moat and the failure mode. Engineer it like a subsystem: five sources, a budgeted assembly policy, traceable compaction, provenance-tagged memory with decay, and automated discovery. When an agent underperforms, audit its context before you blame its model.