Production agents fail less because of weak models than because of wrong context delivered at the wrong moment, and InfoQ proposes treating context as a control plane. The core question is what an agent should know, when it should know it, how long to remember it, and what to forget. A dedicated context engine should select, filter, rank, compress and safeguard information before it reaches LLM inference. For business, this shifts work from prompt craft to systems engineering.
From retrieval to context control
The article distinguishes three layers: context, knowledge and memory. Context is described as a control plane, the governing layer carrying organizational, behavioral and situational data about who, what and why. Knowledge is the official textbook: policies, governance, core business logic and databases. Memory bridges historical data and real-time signals into a reasoning-ready state for the current task. Wrong context sharply raises the probability of hallucination.
The context engine sits inside that control plane and acts as an orchestrator around the model. It pulls from knowledge, organizes material in memory, and decides what the agent needs in a given millisecond. Before generation it authenticates inputs, validates them against business logic, removes personally identifiable information and sandboxes data. The analogy used is a software compiler: raw, historical and live data are translated into structured state. That creates a more deterministic foundation for probabilistic reasoning.
The design must reconcile historical memory with real-time input. Historical memory covers prior interactions, past decisions, user preferences, domain rules, documentation and accumulated observations, giving continuity. Real-time input covers the current task, latest events, live telemetry, fresh tool outputs and environmental changes, keeping the agent grounded. The example is a DevOps agent triaging an outage: a runbook from a vector store is only half the task without the error log stream from the last five seconds. Both batch and streaming sources must be fused asynchronously.
What this means for production agents
For companies moving from chatbots to autonomous agents working across tools, sessions, users and live systems, the consequence is architectural. Over-indexing on history makes an agent stale, replaying yesterday assumptions into present reality. Over-indexing on live signals makes it reactive and forgetful, missing broader meaning. Small teams gain a clearer division between durable state and transient events, while large organizations get a pattern for governing many agents through one context layer rather than hardcoding rules into each application.
The second consequence concerns cost and reliability of retrieval. The article criticizes the SELECT * mindset where more data looks better, typical of standard RAG pipelines that dump fragmented chunks into the prompt. Its illustration is ten unedited wiki pages burying the relevant signal and wasting compute cycles. The alternative is knowledge curation through background workers and ML pipelines that distill, aggregate and rank data by relevance. One cited pattern summarizes a million entries into one entry every 12 hours into graphs or condensed summaries.
The marker to watch is whether vendors and platform teams productize context engines with filtering, ranking, compression, PII handling and batch-stream fusion, rather than selling larger context windows alone. Adoption of curated knowledge pipelines on a 12-hour or similar cadence, plus demonstrated fusion of episodic and sensory memory in incidents like outage triage, would confirm the shift. Absence of those controls would leave agents expensive, noisy and prone to hallucination.
