What Is Agent Context?
Agent context is everything an AI agent reads before it takes a step: the instructions and conversation in the model's prompt, the results of tool calls, retrieved documents and memories, and the operational state the step depends on, such as balances, permissions, limits and actions other agents have already taken. Some of it is placed in the model's context window. The rest is read by tools and by the code around the model. An agent step is only as correct as the agent context it read at the moment it ran.
Updated
What is agent context?
The term has a narrow sense and a wide one. In the narrow sense, it is what goes into the model call. Anthropic's guide to context engineering defines context as "the set of tokens included when sampling from a large-language model (LLM)" and calls it "a critical but finite resource for AI agents." Security research uses the term the same way. A July 2026 paper on agent data injection attacks says an AI agent "maintains an agent context, which contains all relevant information for a given task (e.g., user prompt, tool responses)," and splits it into instructions and agent data. The paper's concern is that trusted and untrusted data sit mixed in that one context.
LangChain draws the boundary wider. Its context engineering docs separate model context, "What goes into model calls (instructions, message history, tools, response format)," from tool context, "What tools can access and produce (reads/writes to state, store, runtime context)." The second half is where agents meet live systems.
Tacnode works with the wide sense: it treats an agent step that acts on incomplete, inconsistent or outdated context as a case of the context gap, the same failure as in any real-time decision. The emphasis moves from the tokens to the state behind them: structured operational state, derived signals such as counts and risk tiers, and semantic retrieval, which must all describe the same moment when the step runs. When many agents act on the same mutable state, each agent's actions are part of the others' agent context, and Tacnode can hold that shared state directly, with transactional writes.
How agent context works
Agent context can be split into six parts, and each goes wrong in its own way:
| Part | Example | Usually lives in | How it goes wrong |
|---|---|---|---|
| Instructions | System prompt, policy text | The prompt | Policy changed after the prompt was built |
| Conversation and memory | Earlier turns, saved preferences | Prompt, memory store | Contradicts newer facts, or gets lost in a long window |
| Tool results | API responses, query results | The prompt | Read from a cache or replica that trails the source |
| Retrieval | Similar cases, documents | A vector index | Index refreshed on its own schedule |
| Operational state | Balance, permissions, open orders | Databases and caches | Changes between the read and the action |
| Other agents' actions | Approvals, reservations, spend | Logs and queues | Not visible yet when this agent reads |
A worked failure, with illustrative timings. A support agent is asked to waive a late fee, and policy allows one waiver per customer per year. The step reads the policy (retrieval), the account (a call to the account service) and the waiver count (a feature rebuilt nightly). Forty seconds earlier, a human agent in the chat channel waived the same fee, in the chat system's own table.
Each input was correct for its source when it was read. Together they describe a customer who never existed: an unpaid fee and no waivers this year. The agent waives the fee again. A larger window or a better prompt would not have helped; the agent needed to read the waiver from where it was written, at the same moment as the rest.
Why agent context matters in real-time systems
Most context-engineering advice is about the window: what to include, what to compress, and how to avoid the drop in recall over long inputs sometimes called context rot. For agents that act on shared state, the failure often happens earlier: the facts were already stale, or inconsistent with each other, before they entered the window. Concurrency makes it worse, because every action one agent takes changes what the others should read next.
Not every agent has this problem. An agent that only retrieves slowly changing reference documents needs a good index, not fresh state, and pgvector covers it. The problem starts when the agent commits actions against state that other actors change in the same seconds. Context rot vs. context lag compares the two failure modes.
FAQ
Related terms
Decision context is everything an automated decision reads and everything earlier decisions committed, as it stands at the moment the decision executes.
Context lag is the delay between a fact changing at its source and the system an automated decision reads from reflecting it. Also called stale context.
Shared context means every service and agent in a decision system reads one internally coherent snapshot of state, instead of private copies that diverge.
Multi-writer contention is two or more actors reading and writing the same mutable state in the same short window. It is not multi-tenancy or partitioning.
Lost in the middle is the tendency of language models to use information at the start or end of a long prompt better than information placed in the middle.
Derived context is state computed from events rather than stored directly — aggregates, velocity counts, features, embeddings — that decisions consume.