AI handoffs without amnesia: continue from files, not chat

Imagine asking a colleague to put together a quote. Halfway through, they leave for a meeting. Someone else sits down at the desk. They missed the earlier discussion, and there is no note. They can ask everything again, or they can guess. A right guess is luck. A wrong one means doing it over.

Working with AI, this happens every day, and more often than it does with people. This post explains how we let AI hand off work without losing the thread. The answer is not to make it remember more. It is to make memory unnecessary.

Why AI always forgets

Start with a fact that is often misunderstood: a language model has no memory of its own. On every turn, the system sends the whole context back into the model — the rules, the conversation so far, the results from tools. The model sees only what was sent this time, then produces the next piece of text or the next tool call.

Context has a length limit. The longer a conversation runs, the more is sent and the more it costs. When it fills up, it gets compressed into a summary. Compression loses detail. When the conversation ends, even the summary is gone.

So "the AI will remember" is true, at best, inside one conversation. Open a new chat tomorrow, switch to another AI tool, or give the same job to a second AI in parallel, and the earlier memory does not come along.

Four fields that say where things stand

Every piece of work lives in its own folder with a small identity file. Inside it is a group of status fields. Four matter most: where it stands, the next step, who it is waiting on, and the due date.

• Where it stands: one sentence on progress, such as "first draft of the quote done, price table not yet checked."
• Next step: the thing the next person should do on opening the folder, specific enough to start right away.
• Waiting on: the person or outside event it is blocked by, if any.
• Due: when it needs to be finished, so priorities have something to rest on.

These look ordinary, but they answer exactly the four questions a newcomer asks first. As long as they are current, any AI that opens the folder knows within seconds where to begin.

The same fields do a second job. Each morning a script reads every case's next step and due date and builds a list of what should move today. One set of fields is both the trail for the next worker and the input for scheduling, so there is no separate to-do list to keep in sync.

The status page people read is generated from the identity file by a script, never written by hand. People and AI therefore always read the same facts, and the two can never drift apart.

At the end of each stretch of work, a short work log is written too: what was done, why, and what is still open. The status fields say where things are. The log keeps how they got there.

Handoff cards: the only way AIs pass work

When work moves from one AI to another, we do not let them talk directly, and nothing is passed on by word of mouth. The only way is a handoff card, placed in a fixed inbox inside the receiver's folder.

A card has eight fields: ID, from, to, what to do, basis, done-when, due date and permissions. If any field is missing, a check blocks the card from entering the inbox.

Here is an example. An event plan is half done. The card says: what to do is "turn quotes from three venues into a comparison table"; the basis is the budget range agreed last week; done-when is "the table shows price, capacity and open dates, and marks the one we recommend"; due is Thursday; permissions are "read the quotes folder, write only the comparison table." The receiving AI can start without a single question, and it knows what not to touch.

Two fields matter most. "Done when" means the receiver never has to guess how far to go. "Permissions" says what the task allows. The receiver's permissions can equal the sender's or be narrower, never wider. A handoff cannot be used to grow access.

A card can also become the starting point of new work. The receiver can open a new piece of work from the card, and the card becomes that work's record of origin. If anyone later asks why this started, the answer is one card away.

Entry rules hold only signposts

The first thing a new AI does in a workspace is read the entry rules. Many teams put every rule, every bit of background and every piece of history into that file. It grows and grows, eats a large share of the context before any work begins, and dilutes the rules that really matter.

We do the opposite. The entry rules hold signposts only: which files to read first, where state lives, and what must never be done. Then they stop. The real content lives in its own files and is opened when needed.

It is the same idea as how skills load. A tool first reads a short description of each skill, and pulls in the full text only when a task actually needs it. Reading less leaves room to think.

Good continuity is not making the next person remember everything. It is making sure they know where to look.

Across tools and machines

Because the state is in files, the next worker does not have to be the same AI tool. Work started in one tool today can be continued in another tomorrow. Both read the same entry rules, the same status fields and the same inbox.

We keep one shared set of rules, not one per tool. Each tool's own settings file does a single thing: point to the shared rules. Two copies of the rules will, sooner or later, become two different sets of rules.

A new machine works the same way. A repeatable installer rebuilds the environment and leaves a signpost so AI can find the platform. The AI then reads each case's status fields and lists what should move forward today.

When several AIs share a workspace, the rule is simple. Claim files that do not overlap, then work. Anything shared, such as the same file or common settings, is changed one at a time. Before writing, re-read what is there now. If someone else changed it, keep both sets of work and merge, rather than overwriting the whole file.

There are limits, too. Writing state to files depends on each stretch of work closing properly. If an AI is cut off before it writes back, the next one reads stale information. That is why every step also appends an event to a log that is never edited, so we at least know what happened last. When the status fields and the log disagree, the next worker should stop and reconcile, trusting the dated record, rather than filling in the gap on its own.

The other limit is proof. Written rules are not the same as a working handoff. The only real test is to shut things down, start again, and confirm the new session picks up from the files. That drill has to be repeated, not done once.

In short

• Models have no memory, and chats get compressed or end. State belongs in files.
• Four status fields answer a newcomer's four questions, and the page people read is generated from the same data.
• AIs pass work only through an eight-field handoff card, and a handoff can never widen permissions.
• Entry rules hold signposts only, so any tool or machine continues from the same files.