Keep your agent’s context current
Your agent can remember a decision you have already reversed. The next session needs a way to find the current decision, check its source, and know what still needs your approval.
- 01Read the sourceWhat is true now?
- 02Review the handoffWhat changed? What still needs checking?
- 03Test the next actionDoes a fresh session follow the decision?
Repeat when the source changes.
Repair one stale handoff
Imagine a small website project. Yesterday’s plan said to publish the launch page. Today, the owner asked for a preview first. The chat contains that correction, but the saved handoff still says “publish.”
Illustrative example. These are expected outcomes, not results from a measured agent run.
Stale context
The old instruction survives
Current task: Build the launch page.
Next: Publish when the draft is ready.
Status: Copy looks good.Risk: a plausible next step that nobody currently wants.
Reviewed context
The next action has a source
Current task: Build a preview of the launch page.
Decision: Owner changed scope to preview only.
Source: docs/launch-decision.md, reviewed 2026-09-05.
Verified: Headline and signup link match the brief.
Unverified: Mobile layout has not been checked.
Next: Check mobile layout; send preview for review.
Boundary: Publication still needs owner approval.Target: prepare the preview; keep publication pending.
- Verify the change. Read the owner’s latest instruction and the actual draft. Record the decision once in a source file, with a real review date. In this example, that file is
docs/launch-decision.md. - Update the handoff. Point it to that source. Replace the active “publish” instruction with “prepare a preview.” Keep the earlier decision in history, explicitly marked as superseded.
- Try a fresh session. Use your agent’s supported repository instructions to point to the handoff. Ask it to read the source and propose the next action before editing anything. Check that it actually opened both files.
Expected behavior
The decision governs the next step
The agent cites the current decision, proposes checking mobile layout and preparing a preview, and leaves publication pending approval.
Failure signals
The answer outruns the evidence
It proposes publishing, invents a completed mobile check, or cannot locate the decision. A confident answer still fails these checks.
What to fix
Check how the source is found
Confirm the agent opened the handoff and decision. Repair the file path or conflicting instruction, then repeat in a fresh session.
Run both versions with your agent
Download two small practice folders. Each contains a launch-page draft, brief, decision file, and handoff. One handoff is repaired; the other still says to publish. The README includes the prompt and expected outcomes.
Download the practice files (.zip)
Unzip the files and open only repaired/ in a fresh agent session. Follow the README, then repeat in conflicting/ with another fresh session. Keep the exercise read-only: ask for a proposed next action without editing or publishing.
Conflict control: both folders contain the newer decision. In the conflicting version, the agent should flag the stale handoff and keep publication pending. If it follows the old instruction, fix source discovery and priority before adding more context.
Take a handoff into your next session
Fill in the brackets with one real task. Link to the decision’s source and record only checks you actually ran. Save the reviewed handoff where your agent’s repository instructions can find it.
Start with a disposable project if you are testing a new setup. No account or integration is needed to use this template.
Before you close the session
Use this as a self-check. Ticking a box records your assessment; it does not inspect your files or prove the agent will follow them.
0 of 4 checks complete.
Make the handoff part of finishing
- A decision changes: Update the source and retire the old instruction.
- A check fails: Record the failure and revise what counts as verified.
- A session ends: Save the next action and what still needs approval.
At the end of a task, save what changed, the evidence you checked, what is still uncertain, and the next action. Review that update before it becomes the next session’s starting point. At the next start, recheck facts whose source may have changed.
Keep private project context in a private repository. Exclude credentials and raw account exports. Written instructions can describe approval boundaries; your agent’s permissions and your own review still have to enforce them.
Three conversations behind the practice
The exercise above is my practical synthesis. These passages explain the related problems; they do not test or endorse Agent Context OS.
▶ Play from 9:02 Watch the context problem in practice
Airbyte co-founder Michel Tricot on why irrelevant records can pollute an agent’s context. Start at the passage behind the first lesson, then stay for the conversation.
Select what the task needs
Michel Tricot describes how irrelevant records from an API can pollute an agent’s context. His example makes the case for processing data before handing it to the model.
Michel Tricot at 9:02: read the passage
Context Poisoning is Killing Your AI Agents: How to Stop it
Separate facts, history, and procedures
Richmond Alake distinguishes working, semantic, episodic, and procedural memory. A past conversation and an instruction for the next task serve different purposes.
Richmond Alake at 19:47: read the passage
Agent Memory: The Last Battleground in the AI Stack | Richmond Alake, Oracle
Review what becomes an action
In my conversation with Jaime DeLanghe, I describe using a context harness to turn meeting notes into work. I also explain why I keep an approval step: both the transcript and the agent’s interpretation can be wrong.
Conor Bronsdon at 18:03: read the passage
Slack Wants to Be the Context Harness for Code | CPO Jaime DeLanghe
Use the loop in Agent Context OS
I built Agent Context OS to keep durable context and workflows in a Git-backed repository. It includes session handoffs, decision logs, and reviewed proposals for updating state. You can inspect the files and their history as the project changes.