I run an AI agent called Kai through OpenClaw. It helps with my SEO work at the agency where I lead SEO: drafting content, outreach, tracking projects. It's been running since January 2026 and at this point it knows more about my day-to-day work than most people I've worked with.
It also has a big problem. Every time I reset a session or the context window fills up, Kai loses track of what we were doing, including decisions from twenty minutes earlier and the plan we'd agreed on. I'd end up re-explaining things, and sometimes we'd redo work or contradict earlier decisions because the context wasn't there anymore.
I'd been living with that since I first set Kai up, but I didn't have a framework for fixing it until I sat down one day and watched 11 AI engineering videos back to back.
The videos
I'd fallen behind on AI news, so on April 2nd I started dropping YouTube links to Kai and having it summarize each video while I watched, pulling out anything relevant to our setup. We got through all 11 that day.
The topics ranged from foundational research (Kimi AI's attention residuals architecture) to very practical stuff (Claude Code's leaked source revealing their internal memory system). The same advice kept showing up across unrelated videos: write state down more often, and don't trust context to survive.
Three findings stood out.
Finding 1: The 50% context cliff
Two independent sources, a video on the CRISPY framework by Dexter Horthy and a Claude Code setup guide, identified the same threshold: when a model's context window hits 40-60% capacity, reasoning quality drops sharply. The model starts writing duplicate code, breaking features it already fixed, or rushing to finish tasks prematurely.
One video called it the "dumb zone." A third, on long-running agent harnesses, described the same thing as "context anxiety."
Karpathy's video on agentic reliability put numbers to it: a 10-step process where each step has 90% reliability gives you about 35% end-to-end success. For an agent running every day, that makes failures expected behavior rather than edge cases.
I'd been treating context degradation as an occasional annoyance, when it's a structural problem with compounding failure rates.
Finding 2: Claude Code already solved this (sort of)
A security researcher leaked Claude Code's full TypeScript source: 500,000 lines across 1,900 files. Inside is a background process called "Autodream" that consolidates memory files. It waits until 24 hours have passed and at least five sessions have accumulated, then spawns a forked agent that goes through four phases: orient itself with existing memories, gather new signals from logs, consolidate into topic files, and prune the index to under 200 lines.
I already had something similar. Kai runs a "sleep protocol" every night that consolidates memory.
What I didn't have was anything between sessions. Overnight consolidation doesn't cover the state that builds up on a busy Tuesday afternoon when I'm switching between three clients and making decisions every fifteen minutes. That state lived entirely in the context window, and when the window reset, it was gone.
Finding 3: The harness matters more than the model
A Stanford/MIT paper called Meta Harness showed that modifying only the code around a model (the memory, retrieval, tools and prompts) produces a 6x performance gap on the same benchmark with the same model weights. The harness, everything other than the model, may matter more than the model does.
My agent's harness had a gap between session start and session end, where decisions, plans and deliverables existed only in the context window.
The fix
The fix was simple: six mechanical triggers that force an immediate write to the daily log file.
- Plan made. We agree on an approach for something. It gets written down right away, not at session end.
- Decision made. I pick option B, or deprioritize something, or approve a draft. Logged with reasoning.
- Deliverable completed. Article written, email drafted, code finished. What was delivered, where it lives, what's next.
- Context switch. Moving from one client to another. Checkpoint current state before switching.
- Blocker hit. Something's broken or we're waiting on external input. What we tried, what failed, what we need.
- Sub-agent dispatched or returned. What task was sent out, what came back.
Each checkpoint is one timestamped line in the format [HH:MM] [TYPE] [project] — summary. That's enough for the next session to reconstruct what happened after a reset without me re-explaining anything.
The nightly sleep protocol then collapses those raw checkpoints into a narrative summary and prunes them, so the daily log doesn't balloon over time.
Why it had to be mechanical
I ran the proposed protocol past my second agent (Victor, who acts as a reviewer) before implementing. His most useful feedback was to make the triggers mechanical instead of judgment-based.
If Kai has to evaluate "is this worth writing down?" during a fast-moving work session, it'll skip checkpoints during crunch, which is when you need them most. So the rule is binary: if a plan or decision was made, it gets written, with no judgment about importance.
Victor also caught a practical issue: if multiple agents are writing to the same checkpoint file, they'll overwrite each other. The fix was to have one agent (the primary session) own the checkpoint file while everyone else writes to the daily log.
What it looks like
These are the real checkpoint lines from the day I implemented it:
[13:40] [DECISION] [OpenClaw] — Implemented real-time checkpoint protocol in AGENTS.md
[13:40] [PLAN] [Personal] — Blog post on mikekhaytman.com about checkpoint protocol + video learnings
Those two lines took seconds to write. If I'd reset the session right after, the next instance of Kai would have known what happened and what to do next.
The instruction budget problem
One of the videos introduced a concept called the "instruction budget": models reliably follow about 150-200 instructions, and past that they start silently skipping steps. My agent's core instructions file (AGENTS.md) is already dense. Adding a 20-line protocol for checkpoints would eat 10% of that budget.
Victor's solution was to compress the whole protocol into four lines with the same coverage and a fraction of the budget. The triggers are listed in a single sentence, and the format and the heuristic get one line each.
The general lesson is that when you're adding rules for an AI agent, shorter is better, because every instruction you add slightly dilutes every other one.
The bigger picture
My main takeaway from the 11 videos was that the scaffolding around the model is the bottleneck. Memory systems, evaluation loops, task routing and checkpointing are where reliability comes from, and a smarter model won't fix a system that forgets what it was doing ten minutes ago.
I also realized I'd been building some of the same patterns AI labs build internally without having names for them. My sleep protocol is close to Anthropic's Autodream, my skill files resemble the industry-standard AgentSkills format, and my sub-agent routing resembles Claude Code's hidden coordinator mode.
The checkpoint protocol was a small, boring change: no new code and no configuration changes, so nothing to break on the next update. It's a rule that says to write things down as they happen. It's been the most impactful change I've made to my agent setup in weeks.
What I'm implementing next
The video binge surfaced a few more ideas I haven't built yet:
Adversarial evaluation. Right now, when Kai writes something, Kai also reviews it, which is like grading your own homework. The fix is a separate evaluator agent with fresh context, prompted specifically to be skeptical. I've been doing this manually by asking Victor to review Kai's work, but formalizing it as a protocol would catch problems earlier and more consistently.
Definition of done files. For recurring deliverables (client articles, outreach emails, tech SEO audits), write a concrete checklist for the evaluator agent to check against, so the question becomes "does this meet these 12 specific criteria?" instead of "is this good?"
Skill file audit. I have about 40 custom skill files. Common best practice is to keep descriptions on a single line (formatters break multi-line), stay under 150 lines per skill, include edge cases and examples, and make descriptions "pushy" because skills tend to undertrigger. I haven't audited mine against any of that.
Those are for next week. The checkpoints are live and already working.