Write your first session brief

If you adopt one habit from building with AI agents, make it this one. It takes five minutes, it feels almost too small to matter, and it's the difference between work that compounds and work you keep re-explaining.

It's the session brief — a short note you write at the end of a working session. Here's how to write your first one, and why it pays back so far out of proportion to its size.

Why sessions lose memory

An AI agent has no memory between sessions. The moment a session ends — you close the laptop, take a call, hit the context window limit — everything the agent understood about the work is gone. Next session, it starts blank. It's the defining constraint of long-running agent work: the model doesn't carry state across runs, so anything not written down is lost.

That's the leak. All the understanding built up over an hour of good work — what you tried, what worked, what's half-done — drains away the instant you stop. The session brief is the plug.

What a session brief captures

A session brief answers one question: if I came back to this cold, what would I need to know? Four short parts cover it:

• What changed — what you and the agent actually did this session.
• Why — the reasoning behind the choices, so nobody re-litigates them later.
• What's verified — what you tested and confirmed works (and, honestly, what you didn't).
• What's next — the obvious next move, so the next session starts in motion.

That's the whole shape. Four lines to four short paragraphs, depending on the session.

Stuart Leo

The question is never "is the work finished?" It's "if I came back to this cold, what would I need to know?"

A real one, annotated

Here's one for a session on that yoga booking site:

## Session brief — booking form (2026-06-08)

What changed: Built the booking form and wired it to the
capacity check. Form rejects bookings past class capacity.

Why: Capacity overflow was the top risk — handled it before
styling so the rule is locked in.

Verified: Submitted 11 bookings against a 10-seat class;
the 11th was rejected. Empty-email submit is blocked.
NOT yet tested: the 12-hour cancellation rule.

Next: Build the cancellation flow and the non-refundable
window. The capacity logic is in lib/booking.ts if needed.

Notice what it does. It states what's verified and what isn't — so the next session doesn't assume the cancellation rule works. It points at the file. It names the next move. Tomorrow's agent reads this and is productive in seconds, not after twenty minutes of re-orientation.

Where it lives in the contextbase

A session brief isn't a throwaway note. It's part of your contextbase — the written knowledge your project keeps in git. Drop briefs in a predictable place (docs/02-working/session-briefs/, dated YYYY-MM-DD-topic.md) and commit them with the work.

Committed, they do double duty: memory for the next agent, and an async hand-off for any human collaborator — no standup required, because the state of the work is written down.

The compounding effect after 20 sessions

One brief is a note. Twenty briefs are a history — a running record of how the project actually evolved, every decision and dead-end captured in order. The next session never starts from zero, and neither does a new person. The understanding that used to evaporate now accrues.

That's the trade: five minutes at the end of a session buys you a running start at the next one. Pay it every time and the starts keep getting faster.

Start here: run your first session, see how a contextbase fits together, or learn how to stop your agent forgetting.