← Back to Blog
Article
July 29, 2026

How to Tell Your Agent What Changed on Every Loop

Bigger context windows made 'just include everything' feel free. It isn't. Full-state dumps bury the one thing the agent needs on every loop: the delta.
Michael Tiffany

My agent has a strange disability: it wakes up every session knowing exactly how to do its job and nothing about what happened since the last time it did it. The instructions persist but the world doesn't. So on every loop I get to choose between re-explaining my week from scratch or dumping every file, log, and message into context and hoping the model spots the three things that changed. If you've been searching for how to keep your AI agent up to date between sessions, here's the short answer: don't hand it the world, hand it the diff. A brief, timestamped summary of what changed since the last loop, with pointers to where the details live, beats a full-state dump on cost, on reliability, and on the feeling that you're working with a colleague rather than onboarding a new hire every morning.

Let's build that diff. By the end of this piece you'll have a named framework (I call it the Wake-Up Diff), a simple version you can set up today with one text file, a DIY version for people who want automation across many data sources, and a two-week N-of-1 experiment for proving to yourself which opening context makes your agent sharper. At the bottom there's a copy-paste prompt that will run the whole experiment for you.

Why doesn't dumping everything into context work?

When context windows hit a million tokens, the lazy consensus in agent-building became "when in doubt, include it," which treats context like disk space when it behaves much more like attention. If giant windows were the answer, why do the labs shipping them keep publishing research about how badly models use them? Nelson Liu and colleagues showed that model performance follows a U-shaped curve across long inputs, strong at the beginning and end and significantly degraded for information stuck in the middle, in "Lost in the Middle: How Language Models Use Long Contexts" (Liu et al., TACL, 2024). Kelly Hong, Anton Troynikov, and Jeff Huber at Chroma then evaluated 18 frontier models and found that performance grows increasingly unreliable as input length grows, even on tasks a model handles easily at short lengths, in "Context Rot: How Increasing Input Tokens Impacts LLM Performance" (2025). Anthropic's own engineering guidance, "Effective context engineering for AI agents" (2025), frames the constraint as a finite attention budget and defines the goal as the smallest set of high-signal tokens that gets the outcome you want.

Here's the part the benchmarks don't even capture: a full-state dump forces the model to perform change detection, and change detection is the hard part. When you paste today's snapshot of your world into context, you're asking the model to answer "what's different?" by comparing against a memory of yesterday's snapshot that it does not have. I spent twenty years in security, and nobody in a security operations center re-images the whole network every morning to find intrusions, you watch the event stream, because the delta is where the signal lives. Software teams learned the same lesson decades ago, which is why code review means reading the diff and not the repository. Feeding your agent the repository on every loop is a silly way to spend a million tokens.

What is a Wake-Up Diff?

A Wake-Up Diff is the four-move pattern that replaces the dump, and the first move is embarrassingly small: keep a cursor, meaning a recorded timestamp of the agent's last successful check. The second move is to query the delta, everything that changed strictly after the cursor. Git users know this as git log --since; Martin Fowler formalized the general idea as event sourcing back in 2005, observing that when you store changes as a sequence of events, current state becomes something you can derive rather than something you must re-transmit.

The third move is the one people miss, and it's the load-bearing one: brief in headlines, not articles. The diff should say that something changed and where the details live, without including the details. "121 step-count records landed overnight; the team progress file changed at 21:23" is a headline, and it costs a couple dozen tokens; the agent fetches the contents only if the task at hand calls for them. Awareness is not ingestion. This single distinction is what keeps the opening context flat at a few hundred tokens no matter how loud your week was. The fourth move closes the loop: advance the cursor so the next scan starts where this one ended.

If this smells like a military decision cycle, your instincts are working. John Boyd's OODA loop begins with Observe, and his own 1996 sketch in The Essence of Winning and Losing draws observation being fed by "unfolding circumstances," which is to say by change. A fighter pilot doesn't re-derive the battlespace on every loop; the pilot updates a running picture with what's new, which is the tempo advantage Boyd spent his career arguing wins fights. Your agent is flying the same loop at a gentler altitude.

How do you set this up, the simple way and the DIY way?

The simple way takes ten minutes and one text file, and I'd start here even if you intend to automate later, because it teaches you what your diffs should contain. Create a file called WHATS-NEW.md somewhere your agent can read it. End every session by having the agent append two to five timestamped headline lines covering what changed: decisions made, files produced, threads opened, one line each, with a pointer to details ("2026-07-09 14:02 | chose Postgres over SQLite for the tracker; reasoning in notes/db-decision.md"). You append lines too, whenever the world changes outside the agent's view ("2026-07-09 | hosting migration started; invoice thread in email"). Start every session with a single standing instruction: read the entries after your last-read marker, then move the marker. Prune anything older than about thirty days into a one-paragraph summary block. What this gets you is continuity for nearly zero tokens; where it falls short is that you are the only sensor, so anything you forget to log is invisible, and the scheme strains once changes arrive from more sources than you can transcribe by hand.

The DIY way is automation, and the prerequisite is boring: timestamps on everything. If your data lives in files, find . -newermt "$(cat .cursor)" or git log --since will get you shockingly far, and a small script that turns the results into headline lines is an afternoon's work. If your data lives across services (health platforms, calendars, message queues, other agents' outputs), what you want is one summarizing call that returns changed record types with counts plus changed file paths since your cursor. Biased heads up, since this is my company: Fulcra publishes an open-source skill called fulcra-situational-awareness (MIT-licensed, in the fulcradynamics/agent-skills repo) that does this with a single CLI call, data-updates "1 day", returning a summary like {"StepCount": 121} alongside the paths of any files that changed. The design is copyable even if you build your own from scratch, and two of its choices are worth stealing regardless. First, the skill asks the user's permission before adopting the scanning habit and records the answer, which sounds like mere politeness but is really cadence design: you are deciding, deliberately, when your agent looks around (session start at minimum, an hourly heartbeat if it runs unattended). Second, it rolls detail up by type, reporting "121 step-count records" rather than 121 records, so the diff's size tracks the variety of change rather than the volume.

How do you prove the diff beats the dump?

Generic advice about agent memory fails for the same reason generic advice about anything fails: there is no generic setup, because your loop cadence, data sources, and tempo of change are yours. So run the comparison yourself. Here is the protocol.

  • Hypothesis: Opening each agent session with a Wake-Up Diff produces better continuity than opening with a full-state dump, at a fraction of the token cost.
  • Variables: Change only the opening context. Week one, paste your full current state (notes, recent files, whatever you'd normally dump). Week two, provide only the headline diff since the last session. Hold constant the task, the model, and roughly the time of day you run it.
  • Tracking method: After every session, log four numbers in a plain spreadsheet: missed updates (things that changed that the agent failed to notice), re-litigations (settled decisions the agent re-asked about or re-argued), turns until first genuinely useful output, and opening-context token count.
  • Evaluation criteria: Signal is a consistent direction across at least five sessions per arm; a single weird session is noise, because some days the task itself is the problem. If the diff arm wins on re-litigations and tokens but loses on missed updates, your headlines are too terse rather than the approach being wrong.
  • Iteration: If the diff wins, tune granularity next: try rolling detail up further, or adding one level of drill-down pointers. If the dump wins, lengthen your headline lines before abandoning the pattern, and check whether your cursor is silently skipping a data source.

FAQ

Don't million-token context windows make this unnecessary? The evidence points the other way: models retrieve least reliably from the middle of long inputs (Liu et al., 2024), and Chroma's 2025 evaluation of 18 models found reliability degrading as input grows even on simple tasks. A bigger window raises the ceiling on what you can include, not on what the model uses well.

My agent has built-in memory. Isn't that the same thing? Built-in memory stores what the agent decided to remember about your conversations; a Wake-Up Diff covers what happened in the world outside them, including things no conversation touched. They're complementary, and memory features are typically siloed inside one product while a diff file travels with you.

How much detail belongs in a diff entry? Give each change one line covering what changed, when, and where the details live. If an entry needs a paragraph, that paragraph belongs in a linked note and the entry should point to it.

Does this work when I run more than one agent? It works better, because a shared changelog becomes the coordination surface: each agent appends its headlines and reads the others', which is the same inbox pattern multi-agent teams use to avoid trampling each other's context.

The future is personal and private.

Fulcra was designed by people who get privacy and know the importance of an infrastructure solution that can be the secure private datastore for the rest of your life. Here data is yours, under your control, and only shared with the people and tools you choose to share it with.