How Context Shapes Every Decision an Agent Makes
An agent does not consult a hidden second brain between turns. On each reason step, it only "knows" what you place in the context window for that call: system rules, tools, user goal, prior messages, and tool results you chose to keep.
That makes context the real control surface of agent behavior. Change the window, and you change the next decision - even with the same model weights.
Summary
- Every agent decision is a function of the current context package; tool results and history only matter if they are present, legible, and not drowned in noise.
- Insight: Most "random" agent behavior is explainable as missing constraints, truncated observations, contradictory instructions, or context bloat that pushed the goal out of view.
- Key Concepts: context window, trajectory, pinned instructions, observation legibility, truncation, summarization, attention competition, tool schema tokens.
- When to Use This Model: Designing prompts, trimming tool outputs, debugging wrong tool choice, or budgeting tokens across multi-turn runs.
- Limitations/Trade-offs: Perfect context management cannot fix broken tools or impossible goals. Over-summarization can drop the one fact that mattered.
- Related Topics: LLM context limits, short-term memory, RAG, stopping conditions, runaway loops.
Foundations
Think of the model call as a closed-book exam where you write the open notes page yourself every turn. If the notes omit the order id, the model cannot look it up from "memory" outside those notes. If the notes include two conflicting policies, the model will sometimes pick the wrong one.
In the agent loop, perceive is exactly this notes assembly. Reason is the exam answer (tool call or final text). Observe edits the notes for next time.
context_t = system + tools + goal + history_slice + memories + tool_results_kept
decision_t = Model(context_t)
context_{t+1} = context_t + decision_t + new_observation (minus trims)Nothing in that formula is mystical.
Production quality is mostly discipline about what enters and leaves context_t.
Mechanics & Interactions
What usually occupies the window
| Component | Role | Risk if mismanaged |
|---|---|---|
| System policy | Non-negotiable rules | Missing → unsafe/wrong behavior |
| Tool schemas | What actions exist | Too many / vague → bad selection |
| User goal | Success target | Buried → agent optimizes something else |
| Conversation | Clarifications, prefs | Noise or contradictions |
| Tool results | Evidence | Huge dumps / bad errors → thrash |
| Retrieved memory/RAG | Extra facts | Irrelevant chunks dilute goal |
| Scratch plans/thoughts | Intermediate structure | Can crowd out evidence if untrimmed |
Legibility beats volume
A 50-line clean JSON observation beats a 5,000-line HTML scrape. The model can only act on what it can parse as salient.
# Prefer compact, structured observations
observe = {
"tool": "get_order",
"ok": True,
"order_id": 1042,
"status": "shipped",
"eta": "2026-07-18",
}
# Not: raw HTTP dump with headers, cookies, and ads HTMLPin what must never fall out
As trajectories grow, middle content is easy to lose to truncation or summarization. Pin critical items by re-inserting them each turn:
- Goal statement
- Success criteria / definition of done
- Safety constraints
- Active plan step (if any)
Many hosts keep a short working_memory message rewritten every iteration.
Truncation strategies
When over budget, choose consciously:
- Drop oldest tool raw payloads first
- Keep latest errors (they explain current blockage)
- Summarize multi-page research into bullets with citations
- Never drop the user goal or hard policy without an explicit design choice
Blind "keep the last N messages" can delete the only successful lookup from step 2.
Attention competition
Even inside a limit that "fits," too many tools and too much prose compete. Symptoms:
- Model calls a vaguely named tool that was listed first
- Model answers from parametric knowledge instead of a buried tool result
- Model follows an outdated plan sentence instead of a new observation
Reduce competitors: fewer tools, sharper descriptions, shorter history.
Tool schemas are context too
Every tool definition costs tokens on every reason call (unless the API caches them). Ten overlapping tools are a context smell and a decision smell.
Memory and RAG injectors
Retrieval is just more context. Bad retrieval is worse than none because it steers the agent with confident irrelevance.
Gate retrieval with task type and score thresholds. See memory/RAG sections later in this guide for storage mechanics; here the rule is: retrieved text still has to earn its seat in the window.
Advanced Considerations & Applications
Context as a product of stop policy
If you stop at max turns, the final context is the whole story of failure or success. Saving that package (redacted) is the best debugging artifact you have.
Multi-agent context
Handoffs fail when agent A passes prose without the structured facts agent B needs. Pass state objects (ids, constraints, open questions), not only chat transcripts.
Caching and sticky prefixes
Some providers cache stable system+tool prefixes. That encourages keeping policy stable and putting volatile trajectory at the end. Verify cache behavior at build for your provider.
Progressive disclosure of tools
Instead of 40 tools always present, expose tool groups by phase (read tools first, write tools after plan approval). That is context design, not only safety design.
| Context policy | Strength | Weakness | Best fit |
|---|---|---|---|
| Keep full trajectory | Max fidelity | Hits limits fast; costly | Short multi-turn runs |
| Sliding window last-N | Simple | Drops early goals/facts | Low-stakes chatty agents |
| Summarize + pin critical | Scales better | Summary errors | Research / long tools |
| State object + minimal chat | Clean for apps | More engineering | Production workflows |
Debugging with "context diffs"
When a bad decision happens, diff context_t against a good run:
- Was the tool result present?
- Was an error truncated to empty?
- Did two policies conflict?
- Did retrieval overwrite the user constraint?
This is faster than arguing about model IQ.
Common Misconceptions
- "The agent remembers everything from earlier in the company." It only remembers what you store and re-feed as context or retrieve deliberately.
- "Larger context windows fix agent quality." They raise the ceiling but also let you accumulate more noise if you are undisciplined.
- "If it fit in the window, the model used it." Fitting is necessary, not sufficient; placement, structure, and competition matter.
- "System prompts are set-and-forget." They compete with later long tool dumps; pin restatements when runs are long.
- "More retrieved docs mean better grounding." Irrelevant docs are adversarial context.
- "Hiding tool results from the model protects safety." If the model must decide next steps, it needs accurate observations; hide secrets from logs/UI separately.
FAQs
What is "context" for an agent step?
The full prompt package sent to the model for that reason call: instructions, tools, messages, and any injected memory or retrieval.
Why did the agent forget the user's constraint mid-run?
Likely truncation, summarization loss, or burial under large tool outputs. Pin constraints each turn.
How should I format tool results?
Short, structured, task-relevant fields first. Truncate long text with explicit markers that content was cut.
Should thoughts/reasoning stay in live context?
Log them fully offline; keep only short summaries live if they help. Full CoT can crowd out evidence.
How many tools is too many in one context?
When descriptions overlap or selection error rates rise in evals. Often a handful of sharp tools beats a kitchen sink.
Does message order matter?
Yes. Models are sensitive to recent tokens and to clear structure. Keep the active goal and latest observation easy to find.
What's the difference between context and memory?
Context is what is in the window now. Memory systems are stores that may write into that window on demand.
Can I fix bad context with a stronger model?
Stronger models tolerate mess better, but they still fail on missing facts and still cost more on bloated windows.
How do I budget tokens across a multi-turn agent?
Cap per-turn tool payload size, total run tokens, and reserve a finalize turn. Measure tokens per phase in logs.
Why does the agent answer without calling the tool that had the data?
The data may be absent, unreadable, or less salient than parametric priors. Improve observation placement and instruct "prefer tool evidence."
Should errors be removed from context to "stay positive"?
No. Clear errors prevent identical retries. Remove only after the model has adapted or you force finalize.
How does this relate to prompt injection?
Injected content becomes context too. Treat tool outputs and retrieved docs as untrusted text that must not override system policy.
What's a practical working-memory size?
Enough to restate goal, constraints, key ids, and open questions in a few hundred tokens. Not a second novel.
Where should I learn about hard window limits?
See LLMs Behind Agents pages on context windows and token costs for provider-bound limits (verify at build).
Related
- Inside the Agent Loop: Perceive, Reason, Act, Observe - perceive phase is context assembly
- Agent Loop Basics - messages as working memory
- Reasoning Traces: How Agents "Think" Before Acting - optional content that also consumes budget
- Why Agents Loop Forever: Debugging Runaway Agent Behavior - failure modes when context is noisy or incomplete
- Agent Loop Best Practices - operational context habits
- How an LLM's Context Window Bounds What an Agent Can Do - hard token limits
- Context Discipline Rules for Predictable Agent Behavior - rule-form checklist
Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana
@solana/web3.js+@solana/spl-token.