The recipe travels

A builder shows an apprentice how to make a mixture that works. Which materials go in. What order. What it should feel like when it's right.

That lesson is a gift. The apprentice can do good work without repeating every failed experiment that came before.

But the recipe is smaller than the experience behind it. Some of the reasons stay with the person who learned them the hard way.

The recipe travels. How much of the reasoning travels with it?

What the material still shows

People were making lime plaster about 12,000 years ago. At one site in the Upper Jordan Valley, they covered graves with plaster made by heating rock into quicklime and mixing it so it would harden again.1 The plaster shows they could do it. It doesn't tell us how they figured it out or how they taught it.

Roman concrete has a newer twist. In 2025, researchers studied a building site at Pompeii that was frozen mid-job in 79 CE. They found piles of dry quicklime already mixed with volcanic ash, waiting for water.2 That points to "hot mixing," a method that leaves small lime chunks that can later help seal cracks. The Roman writer Vitruvius described a different order: mix the lime with water first. The leftover pile kept a method the textbook didn't fully capture.

That's not a story about ancient builders being wiser than us. It's a reminder that recipes have been outrunning their reasons for a long time. A skill and a full explanation of that skill can have different histories.

Curiosity lets us go back to the evidence. New tools help. One new AI system proposes missing words in damaged Ancient Greek texts for experts to judge.3 Another project, still being built, aims to match broken artifact pieces and suggest how they fit.4 Matching pieces that survived is recovery. Filling a gap is a guess until evidence backs it up.

Enough of the Antikythera mechanism survives to explain how a dial tracked eclipses. The missing front leaves room for more than one reconstruction. Dates mark individual milestones. Original timeline by Renaissance Solutions with Codex (CC0). Museum chronology · Imaging study · Proposed front display.

Now speed up the clock

Builders lost reasons over generations. A chat can do something similar in an afternoon. Of course, culture and chatbots work very differently. But both have to choose what to carry forward.

In one sitting, you explore an idea, reject a few, fix a wrong assumption, and settle on a plan. Later answers may be built from a smaller version of all that.

It helps to keep three things apart:

  • The archive: what the app stores and shows you when you scroll up.
  • The working context: what actually gets handed to the AI for its next answer.
  • Saved memory: selected facts some products carry from one chat to another.

A conversation can sit in the archive, word for word, while only part of it reaches the working context. Products handle this differently. One company's developer tools, for example, can shrink long histories into a compact form that isn't even meant for people to read.5 That's one product's method, not how every chatbot works.

Here's the kind of thing that can slip:

  • What we decided: Use a simpler sign-in for a demo with fake data. Revisit it before real customers arrive.

  • What carried forward: Use the simpler sign-in.

The instruction survived. The "revisit when real customers" didn't.

Both versions tell the next person what to do. Only the first tells them why that choice fit the demo and when to reconsider it. This is an illustrative handoff. Original diagram by Renaissance Solutions with Codex (CC0).

One chat, two agendas

This is an illustration, not a real case.

Dana opens a chat on Monday to plan a client workshop. Over an hour, she sets the details. Eight attendees from the client's finance team. A budget cap. A formal tone. A Thursday date. No vendor demos, because the client asked for none. She corrects the AI twice: the CFO joins only for the last hour, and lunch is on the client.

On Wednesday, she scrolls back to that same chat and types, "Make an agenda for my book club's planning night."

Nothing in her new request says which of Monday's details still apply. Depending on the product, some of Monday's details may still be in play: word for word, summarized, or held in memory. The AI may fill the gaps with what it has. The book club agenda comes back neat and well organized. It also has a formal tone, a hard stop at a budget nobody set, and a note about lunch being covered.

Or the slip goes the other way. Next week, Dana reuses that chat for a second client. The new agenda quietly brings over "no vendor demos," a rule that client never asked for. Or it forgets her correction about the CFO.

The output looks finished. That's the problem. A polished agenda can hide the fact that it was built for a different room.

None of this needed the chat to be old or full. Mixing topics can cause trouble from the first switch. And opening a new chat doesn't always mean a clean slate. Some products bring saved memory or shared project files into new chats.

Four ways it goes wrong

When an answer drifts, it helps to know which problem you have. They aren't all "the chat forgot."

  1. Carryover. Details from one topic shape another. That's Dana's agenda.
  2. Lost qualifications. A shorter version of the history drops an exception, a correction, or an open question. That's the sign-in.
  3. Stale facts. The world changed outside the chat. The budget moved, the date slipped, the file was updated. There's no set number of days when this kicks in.
  4. Plain mistakes. Sometimes the AI is just wrong.

A chat doesn't get forgetful because it had a birthday. An idle chat doesn't fill up just because a month went by. One busy hour of pasted documents can put more strain on it than weeks of light use. And from the outside, we usually can't tell which of these four caused a particular wrong answer.

Handoffs that keep the reasons

Since we have learned that explicit handoffs have been a big win, we now build formal handoffs between key steps in our process, for example:

  • Ideation → Design: We often go down at least a few and sometimes many rabbit holes during ideation. Handoffs let us remove any ideas that did not make the cut. Before handoffs, we would occasionally find something that we decided against in the design/plan, or worse, spend many tokens testing a feature that we then had to spend more tokens to remove.
  • Proof of concept (POC) → Implementation: We learn a great deal from a POC, including what we do not want to do. Since context compression sometimes gets confused when it is full of successes, failures, and contradicting decisions and assumptions, we write a fresh handoff. Before handoffs, we found ourselves relearning some of the failures from the POC.

A handoff is a short note that starts the next chat or the next person on the right foot. It isn't a transcript. It's a map, with links back to the evidence.

A good handoff covers:

  • The goal: the project or client, who it's for, and what's in scope.
  • Decisions and their reasons. The reasons are the part that usually falls off.
  • Constraints and exceptions, including temporary ones, and when to revisit them.
  • Done versus proposed: what's finished, and what's only an idea or hasn't been checked.
  • Where things live: current files, tickets, and source links.
  • What's open: questions, blockers, and the next step someone has approved.
  • What not to carry forward: old instructions that no longer apply.

Then a person reads it before the new chat starts. If the AI wrote the summary, check it. Don't let one unchecked summary feed the next.

Here's the difference, using an illustration much like Dana's workshop:

Weak: "Draft Friday's agenda using what we already decided."

Strong: "Draft Friday's agenda for the Northwind project. Attendees: Priya (engineering) and Sam (finance). Budget cap is $12,000. Tone is plain and careful, no jokes. We dropped the vendor demo because their security review is still open. Don't add it back unless Sam says the review cleared. Next step: send the draft to Priya only. Don't use anything from other projects in this chat."

The strong version names the project, the people, the limit, the reason, when the rule expires, and what must stay behind. It takes a minute to write. It can save the quiet mix-up that would have taken longer to find.

Everyday habits

You don't need a complicated system. A few habits go a long way:

  • One chat per purpose. Keep work and personal apart, and keep different clients apart.
  • Say what you're working on. Name the project, who it's for, and the dates that matter.
  • When the topic changes, start fresh. Open a new chat and paste in only a short brief you've reviewed.
  • Check what comes along. See which memory or project files apply, and recheck the details that matter most: who, when, how much, and what must not happen.
  • When answers drift, reset. Restate the goal and the limits.

A long exploration of one idea can still live in one chat, especially while the connections are the point.

When the work outlives one chat

With AI agents that edit files or take actions, a lost reason can turn into a changed file, a rewritten test, or a step taken in another system. The ability to act can survive while the reason does not.

Anthropic describes this problem in its own experiments with long-running coding agents: each new session "begins with no memory of what came before." One failure they saw: a later session would look around, see that some progress had been made, and declare the job done too early. Their fix was records outside the chat, including a feature list, progress notes, and saved versions of the code.6 That's one company's experience, not proof that every agent fails this way. But it shows why the records matter, and it has happened to me, which is why this article exists.

A few plain practices help:

  • A project folder with version history. A repository keeps past versions of files, so you can see what changed. It doesn't automatically keep the reasons, unsaved work, or the live state of a database.
  • Tickets that say why. "Make login better" tells the next session almost nothing. "Let invited members sign in, keep the existing membership checks, and test it with two accounts that have different access" carries the reason and the boundary.
  • A short decision note when a choice would be costly to rediscover: what you chose, why, what you rejected, and when to reopen it.7
  • Let the agent load what it needs. Point it to the right files when it needs them instead of piling everything into one chat. Check that the right document actually arrived, because search can miss.89

Then try the restart check. Can a fresh session find the goal, the real current state, the limits, and the next step using only your saved records? If not, the old conversation was carrying work that needed a home outside the chat.

A ticket, a short decision note, and a reliable handoff often beat an elaborate memory system that nobody keeps up.

The recipe, the reasons, and a way back

We can't carry every detail into every decision. We can keep the ones that matter and leave a path back to the evidence.

Before a handoff, ask these questions:

  • What did we decide?
  • Why?
  • When should we reconsider?
  • Where can the next person, or the next agent, check?

A builder's recipe, a chatbot's summary, and a project ticket are different things. Each can carry useful skill while shedding context.

Curiosity gives us a reason to reopen them. Good records give us somewhere to look.

Footnotes

  1. Friesem, Abadi, Shaham and Grosman, "Lime plaster cover of the dead 12,000 years ago," Evolutionary Human Sciences, 2019. https://www.cambridge.org/core/journals/evolutionary-human-sciences/article/lime-plaster-cover-of-the-dead-12000-years-ago-new-evidence-for-the-origins-of-lime-plaster-technology/FE59B9E8B995488761D6EE9589D22CCC ↩

  2. Vaserman, Weaver, Hayhow et al., "An unfinished Pompeian construction site reveals ancient Roman building technology," Nature Communications, December 9, 2025. https://www.nature.com/articles/s41467-025-66634-7 ↩

  3. Austrian Academy of Sciences, Apollo announcement, September 23, 2026. https://www.oeaw.ac.at/en/news/ai-speaks-ancient-greek-apollo-restores-2000-year-old-texts ↩

  4. NYU Tandon, Fragmented Legacy, October 13, 2026. https://engineering.nyu.edu/news/nyu-researchers-are-building-ai-piece-together-broken-archaeological-finds ↩

  5. OpenAI, "Compaction" (API documentation). https://developers.openai.com/api/docs/guides/compaction ↩

  6. Anthropic, "Effective harnesses for long-running agents," November 26, 2025. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents ↩

  7. Michael Nygard, "Documenting Architecture Decisions," November 15, 2011. https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions ↩

  8. Anthropic, "Effective context engineering for AI agents," September 29, 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents ↩

  9. OpenAI, "Retrieval" (API documentation). https://developers.openai.com/api/docs/guides/retrieval ↩