Stop re-briefing your AI agent every run

Every scheduled AI run pays a re-briefing tax. The agent wakes up, re-reads the repository, re-discovers the deployment steps, re-derives the decision you already made last week, and burns a few thousand tokens getting back to where the last run ended. Multiply that by a daily schedule and you are paying for the same onboarding meeting every single morning.

The underlying model is not the problem. The problem is that each run starts with an empty context window and no handoff from the previous one. Fix the handoff and the tax disappears.

Think of it as the agent's notebook

Humans doing recurring work keep a notebook: what is the current state, what is next, what blew up last time. Your agent needs the same thing, written in a format it can read. The notebook has four sections:

Current state. Where things stand right now. Which step of the pipeline is done, which configs are live, what the last run actually changed.

Next action. Exactly one thing the next run should do first. Not a roadmap, a single concrete step. If the next run can start working in under a minute of reading, the notebook is doing its job.

The graveyard. Every failed approach, with the error and the lesson. "Tried the v2 API for exports, it 404s on accounts created before March, use v1." This section alone can save more tokens than everything else combined, because retrying dead ends is the most expensive mistake a scheduled agent makes.

Facts about the environment. Repo paths, service names, the order operations must run in, who to notify on failure. Anything the agent currently re-discovers by reading files.

Keep the notebook short. A page of dense notes beats fifty pages of logs. Logs tell you what happened; the notebook tells you what matters.

A concrete shape that works

Here is a minimal JSON layout you can start with tonight:

{
  "updated": "2026-09-25T23:30:00Z",
  "current_state": "Nightly report pipeline is green. Last successful run: 2026-09-25.",
  "next_action": "Add the new EU region to the report query before the next run.",
  "open_items": [
    {"item": "EU region in report query", "status": "todo"},
    {"item": "Alert threshold review", "status": "blocked", "blocked_by": "waiting on ops"}
  ],
  "graveyard": [
    {"attempt": "Parallelized the export step", "result": "Rate-limited by the API, reverted to serial"}
  ],
  "notes": "Export API allows 60 req/min. Do not parallelize."
}

One file, one schema, in a path every run knows. The agent reads it first, works, then writes it back before exiting.

Make the load step unavoidable

The write step is easy to remember. The load step is what gets skipped, because a run that is in a hurry goes straight to work. Put the read instruction where the agent cannot miss it: the system prompt, or the first line of the scheduled prompt template.

Something like: "Before doing anything else, read agent-state.json and summarize the current state and next action in two sentences." The summarization matters. It forces the model to actually process the state rather than letting it sit in context as decoration.

When two runs step on each other

Sooner or later a schedule fires while the previous run is still alive, or two agents share one notebook. Pick one rule and write it down:

• Last write wins. Simplest. Fine when one agent runs on a schedule and overlaps are rare.
• Merge on load. Each run reads the notebook, applies its own updates, writes back the union. Needs the structured format above so merging is mechanical, not interpretive.
• Lock it. For dangerous overlap, like two runs deploying simultaneously. A timestamped lock file; a run that sees a fresh lock exits quietly.

Log which rule fired. The only truly bad option is resolving conflicts silently and hoping for the best.

Where to keep the notebook

A file on disk is enough for one agent on one machine, and you should start there. When the setup grows, a database row works for shared state across schedules.

If you would rather not build and host any of this, a hosted memory layer like Vilix AI keeps that run state in the cloud and serves it to any connected AI tool over MCP. Tradeoff is the obvious one: your agent's context lives on hosted infrastructure, so if you need everything on-prem, keep the notebook local.

Start with one file

You do not need a memory architecture. You need one JSON file, a read-first instruction, and a write-before-exit instruction. Add it to your most annoying scheduled agent this week and watch the re-briefing tax drop to near zero. The agents that compound knowledge between runs are the ones that stop feeling like interns on their first day, every day.