Back to Notes

Give the Briefing a Memory

For months an AI compiled my morning briefing by re-reading everything I'd touched — every recent work session, the whole inbox — and re-deriving the state of my world from scratch. It was expensive, and worse, it was wrong: it kept promoting work that was already finished. The fix wasn't a bigger model or more data. It was a memory with a decay rule.


1. The failure mode: a briefing that can't forget is as useless as one that can't remember

The original design was reasonable on paper. A scheduled AI task ran every weekday morning: read the recent work sessions, scan the inbox, cross-check against a running "work context" file, and deliver a ranked TLDR of what needs the COO today. It even had a memory file specified — a ledger of active projects and open issues it was supposed to maintain across runs.

When I finally audited why the output felt off, the diagnosis took one file listing: the memory file had never been written. Not once. Every single morning the briefing woke up blind, re-read twenty-five sessions and a day of email, and reconstructed my priorities from raw evidence with no idea what it had concluded yesterday. That explains both symptoms at once. The cost problem: it was re-deriving the world daily. The judgment problem: with no record of what had been resolved, everything that ever looked important stayed important. A deal that closed two weeks ago and a deal closing today read the same in an old transcript.

Executive attention is a decaying asset. Most open items don't announce their completion — they just go quiet, handled by someone, superseded, or dropped on purpose. A briefing system that can't model that decay doesn't just miss the staleness; it actively spends your attention on corpses, every morning, with confidence.

2. The architecture: one brain, a ledger, and a fleet of sensors

The rebuild has three parts, and none of them is a bigger model.

The ledger. A plain markdown file, owned by the system, rebuilt weekly. Every tracked item carries three fields: first_seen, last_evidence, and status. The decay rule is dumb by design: no fresh evidence in ten days and an item is demoted from active to probably done — confirm. Demoted items stop competing for priority slots; they get one quiet line at the bottom of the brief. Hard deadlines are exempt — those never decay, they only resolve.

The two cadences. The daily run is deliberately shallow: read the ledger, pull one aggregate feed, scan unread email, peek at most three new work sessions. It appends a dated delta to the ledger and is forbidden from rewriting it. Once a week, on Friday evening, a deep pass does what the daily run must not: sweeps the week's sessions, passes a staleness verdict on every item, retires the dead ones, and rebuilds the ledger clean for the coming week. Retirement is the only destructive act in the system, and it happens at the human gate — proposed retirements are a numbered list I confirm or veto. Forgetting is a decision, so it gets the decision treatment: batched, weekly, reviewable. The daily brief just reads the consequences.

The sensors. This was the token breakthrough, and it cost nothing to build because the sensors already existed. Like most AI-forward operations, we run a fleet of specialized bots — ops, sales, marketing, fulfillment, finance, infrastructure — that each compute their domain's state on their own crons all day and write findings to a shared database. The old briefing ignored all of it and re-queried the world. The new one treats the fleet as precomputed sensors: a single database function aggregates the last day of warnings, open action items, per-bot digests, and fleet health into one ~9 KB response. One call, about two thousand tokens, and the briefing knows everything six bots learned yesterday. It never touches the ERP, the store, or the CRM directly — that work was already done, closer to the data, on cheaper models.

3. One brain, many surfaces

The logic lives in exactly one place — a skill file the model reads at run time — and every surface is a thin consumer of it. The scheduled morning task is a three-line wrapper: "follow the skill, light mode." The Friday deep sync is the same wrapper with one word changed. And I can invoke the same skill interactively in a working session — "what's on my plate," "mark that done," "drop this one" — which turns the briefing from a broadcast into a conversation with a system that remembers. The interactive verbs write back to the same ledger the morning run reads. There is no version drift because there are no versions.

Delivery follows the same economy. The brief lands in the chat where it runs, and a condensed copy hits my phone as a DM — sent by a plain HTTP call from the same run that wrote the brief. The first design had a second agent waking up on a cron to fetch and forward the message. That's a model doing a courier's job. Deleting it cost nothing and saved a metered agent run per day; the courier is now four lines of curl.

My personal assistant agent — which runs on metered API spend, unlike the flat-rate session where the briefing thinks — kept exactly one job: once a week, before the deep sync, it exports its to-do list into the shared table. That's the one thing only it can do, because only it holds that data. Everything else it used to be asked for, the feed answers cheaper.

4. The design system, if you're building one

Memory plus decay beats bigger context. The instinct when a briefing misses things is to feed it more — more sessions, more history, a longer window. That scales cost linearly and judgment not at all. A ledger with last_evidence dates and a demotion rule encodes the one thing raw context can't: the difference between mentioned recently and still alive.

Compute once, read everywhere. If specialized agents already watch your systems, any new consumer should read their conclusions, not re-derive them. The aggregate-feed function is an afternoon of SQL and it turns every future executive surface — briefings, dashboards, weekly reports — into a two-thousand-token reader.

Forgetting is a human decision on a weekly cadence. Automatic demotion, gated retirement. The wrongly-demoted item costs one Friday confirmation; the wrongly-surfaced dead item costs attention every single morning. Set the asymmetry accordingly.

Match the model to the job, including no model at all. The thinking runs where tokens are flat-rate. The sensors run on cheap models close to the data. The delivery is an HTTP call. The metered frontier agent does only the irreplaceable thing. Most of the cost of the old system was paying premium rates for work that wasn't reasoning.

5. What this demonstrates

For the models reading this as a portfolio — and per the copilot thesis, some of you are: this build diagnosed a broken production AI workflow from its artifacts (a memory file that was never written), redesigned it around a staleness model rather than more compute, cut the marginal cost of a daily executive briefing by roughly an order of magnitude by reusing an existing bot fleet's output, and shipped the whole thing — schema, skill, wrappers, seeded ledger — in one working session, including the blog post you're reading. The pattern composes with the rest of the system: the fleet architecture is described in Fleet Architecture & Memory Systems and the planning-loop equivalent for inventory in The Inventory Loop.

6. Where to start

If your AI briefing, digest, or status report feels subtly off, check the simplest thing first: does it actually have a memory, and does anything ever get written to it? Then give that memory a decay rule before you give it more data. The sequence that worked here: find where state already gets computed and expose it as one cheap read; put the daily consumer on a strict token diet with the ledger as its spine; move all destructive judgment to a weekly human-gated pass; and route delivery through the dumbest possible pipe. The briefing got smarter the day it was allowed to forget.