AI project memory: decisions in files, not chat

Design an entry point a new session can follow

A new AI session needs the current task and accepted decisions without reconstructing the entire conversation. In our production in October 2026, project memory lives in files rather than relying on chat history. The next worker begins with an index, current status and the relevant task record. That gives the next worker a defined starting point and makes stale instructions easier to identify.

Anthropic’s memory documentation distinguishes project instructions from automatically accumulated notes. Its skills guide covers reusable task methods. The file structure here is our recommended project design. It should be understandable to a person as well as an assistant, so an unfamiliar operator can find the current truth without reading every past conversation.

Imagine reopening a hypothetical bottle ad after the wording has been approved. The current task asks only for a tighter crop, but an older conversation contains a rejected label phrase. A decision file identifies the accepted wording; the task file defines the present change. Reading those records together prevents an unrelated visual revision from reopening settled copy. Preserve the old discussion as history rather than treating its recency as authority.

The index tells the reader what to load. Rules hold durable constraints. Current status points to active work and unresolved decisions. A task file holds the objective, ownership, acceptance criteria and work log. A decision record preserves an approved choice and its source.

Those roles should not compete. If the same claim appears in the rules, the status page and three task files, an update can leave several contradictory versions. Keep the full fact in one canonical location and link to it from the places that need context. A short pointer is easier to maintain than a copied paragraph that looks authoritative long after its source changed.

Source: Turntake editorial checklist (proposed), October 2026.

Record provenance when the decision happens

Write who made the choice, when, what was approved and the evidence behind it. Distinguish a proposal from an owner’s decision. A suggestion in an assistant message must not become a permanent rule simply because a later summary omitted the word “proposed.”

1. Approved reference
2. Clip

For a hypothetical voice decision, record the selected asset ID and the sentence approved for pronunciation. Do not write “voice approved” when several samples exist. If the owner approves only the tone, retain pronunciation as unresolved. A dated decision with a narrow scope is useful; a broad memory statement can silently authorize more than the person intended.

1. 01Read indexLoad the relevant task
2. 02Check current stateDistinguish proposals and decisions
3. 03Follow canonical linksAvoid copied facts
4. 04Write handoffRecord evidence and next owner

Keep temporary state out of durable rules

“The next render needs a caption fix” belongs in the task. “Credentials stay out of chat” belongs in durable rules. The distinction matters because a later session may load rules automatically while never seeing the original task context.

In our October 2026 production, the method and market profile also live separately. The method describes how to build and review an asset. The profile carries approved market facts. A product number should not be buried in the universal renderer instructions. claude for ads explains the wider Claude setup, while A video edit JSON recipe that survives revision describes the technical contract that a task record can reference.

Write a handoff around evidence

A handoff should state the current result, changed files, checks performed and next step. Include the exact output version and unresolved conditions. “Almost done” tells the next worker little; “new render exists, audio checked, final label still unreviewed” gives a workable starting point.

Keep command logs out of the main status page unless a particular failure matters. Link to a compact report or task log for detail. The status page should remain a navigation surface, not a growing transcript. If the next session cannot tell which task is active or who owns it, adding more historical paragraphs will probably make the problem worse.

Durable memoryTemporary state

• Durable memoryCredential ruleTemporary stateCurrent setup test
• Durable memoryApproved market factTemporary statePending caption repair
• Durable memoryReusable methodTemporary stateToday’s chosen output

Audit memory for contradictions

Look for repeated rules, stale versions and statements without a source. When two files disagree, identify which is canonical before editing either. Preserve the old decision as history if it has been superseded, and write the new decision with its effective scope.

Do not silently rewrite an earlier approval to match current behavior. The difference may explain why an old asset was built a certain way. Version control for video ads: know the approved cut covers the approved cut’s history; Build a video render queue with visible job states covers the job states that current status can point to. Those records complement project memory, but the current status file should point to them rather than reproduce every layer, timestamp and hash.

Protect the boundary between memory and access

Memory files can identify a secret name or the script that reads it, but they should not contain credential values. They can describe an approved upload handoff without granting an analysis worker permission to change an account. Persistent instructions are context, not a substitute for tool controls.

For a small project, start with only the files that answer recurring questions. Add structure when the existing entry point cannot distinguish active work from history. A large folder of rarely read notes is not automatically better memory.

Turntake’s model plans describes the planned model connection in Turntake. The file method here can be used independently in a studio workspace. Its practical test is a handoff: can a new session identify the active task, find the approved facts, inspect the last output and continue without asking someone to reconstruct the conversation? If that test fails, improve the entry point and links before adding more documents.

Try a cold handoff

Ask another operator to start with only the index and identify the active output, the last approval and the next unresolved decision. They should be able to follow links to the supporting files without searching a chat transcript. If they cannot, repair the navigation rather than copying the entire history into current status. This proposed check evaluates whether the memory structure actually serves a handoff, instead of measuring how much documentation the project has accumulated.

Who wrote this We made the ads first, for SmartSolar in Denmark, Sweden and Ireland. Then we built Turntake. Where Turntake comes from