AI Project Context & Handoffs 8 min read Updated Jul 7, 2026

How to Keep AI From Forgetting Project Decisions

Over a long project, AI keeps reopening decisions you already settled — re-suggesting the option you rejected, softening a constraint, renaming things. Here's how to turn those decisions into a block the model reads before it works.

Try the Project Context Builder

When the AI keeps reopening settled decisions

Early in a project you make the calls: this is the stack, this is the audience, the tone is direct not hyped, we're not building X, the term is "seat" not "license." It holds for a while. Then the conversation gets long, or you open a fresh chat to keep going, and the AI starts drifting — it re-suggests the option you rejected, softens a constraint you set, reopens a question you closed, and quietly renames the thing you named. You correct it, again, and a few turns later it does the same thing.

The model isn't being difficult; it just doesn't have your decisions. They were made in the conversation, not written down as rules, so a long chat buries them and a new chat never had them. This guide is a process for turning the decisions scattered through a project into a decision block the AI reads before it works — so "settled" stays settled. It reduces the drift; it doesn't give the model permanent memory, so you still keep the block current and check that the output obeyed it.

Why AI forgets project decisions

A few things make decisions the first thing to slip:

  • There's no memory across chats. A new conversation starts blank — everything you settled last week is gone unless you bring it with you, and even a long single chat pushes early decisions out of the window it can attend to.
  • The decision was never a rule. "Let's not do X" said once in message 12 reads like a passing remark, not a standing constraint; the model has no reason to treat it as permanent.
  • The model pulls toward the default. When your choice differs from the common one — a stricter tone, a narrower scope, an unusual term — the model drifts back to the average unless the decision is in front of it.
  • Rejected options don't announce themselves. The thing you decided against leaves no trace in the chat, so nothing stops the model from proposing it again as if it were new.

Step 1: Separate settled decisions from still-open questions

Not everything in a project is decided, and mixing the two is what invites the AI to reopen things. Make two lists: settled — the calls that shouldn't change without a deliberate choice — and open — the questions still genuinely in play. The stack you committed to is settled; the pricing copy you haven't written is open. The line between them tells the model where it's allowed to help decide and where it should just comply.

State the settled ones as decisions, not discussion: "Tone is direct, not hyped" rather than "we talked about tone." And when a decision is still tentative, say so, so the model doesn't treat a maybe as a yes.

Step 2: Write down the rejected options and the do-not rules

The decisions the AI reopens most are the ones you made against something — the option you considered and dropped, the feature you scoped out, the claim you won't make. Those leave no trace in the conversation, so unless you record them, the model re-proposes them as fresh ideas. Write them as explicit do-not rules: don't claim the product does X, don't use the term Y, don't add the feature we cut.

This is the half most decision notes skip, and it's the highest-value one. "We decided to keep it read-only" is good; "do not add write access — we rejected it for the audit risk" is better, because it carries the reason and pre-empts the next well-meaning suggestion to add it back.

Step 3: Build a standing decision block the AI reads first

Collect the settled decisions, the do-not rules, the terminology, and the constraints into one block — a short, standing record of what's true about the project. This is the thing you paste into the place your AI tool keeps persistent instructions, so it loads at the start of every new chat instead of being re-explained each time.

The Project Context Builder is built for this: from your inputs it assembles a project profile with an "Always Remember" section for the settled decisions, a "Never Assume" section for the do-not rules and rejected options, and a glossary for your terminology. It runs in your browser and produces text you paste into your own tool's project or custom instructions — it doesn't store anything, connect to your account, or sync between chats. When the profile loads every session, that's your tool re-reading what you pasted, not NewPrompt holding a memory. The Persistent Project Context resource is a worked example of the same block you can adapt by hand, and it's the one you edit when a decision actually changes.

Step 4: Carry the decisions into a fresh chat when you switch

Persistent instructions cover the always-true decisions, but sometimes you start a new chat mid-task and need to bring the current state too — what's decided, what's constrained, what's still open right now. That's a handoff, not a standing profile: a snapshot you paste as the first message of the new chat so it continues instead of restarting.

The Context Handoff Builder assembles that snapshot from a session — decisions, constraints, open questions, and next steps — with instructions that tell the new chat to treat the decisions as settled and raise a question before overriding one. The Preserve Project Decisions resource is a worked example focused on exactly the decision part: it carries every decision verbatim and adds the rule that a settled call can be challenged only by asking, never silently reversed. You paste it into the new chat yourself; it keeps what's settled settled for that session.

Step 5: Make the AI restate the decisions before it starts

A block only helps if the model actually read it, so open each significant task by having it prove that it did. Ask it to restate the decisions and constraints in its own words and flag anything the new task would conflict with before it produces anything. A model that has to repeat "tone is direct, the product doesn't claim to build finished apps, pricing is still open" is far less likely to then write hype copy that promises a finished app.

It also surfaces the gaps. The Handoff Completeness Review resource is a review prompt that checks a decision block or handoff for what's missing — decisions the work depends on that were never written down — and gives a ready-or-not read before you build on it. Catching a missing decision here costs a sentence; catching it after the AI built on the wrong assumption costs the work.

Step 6: Update the block when a decision changes

A decision record is only as good as its last edit. When you genuinely change a call — you did decide to add write access after all — change it in the block; don't just say it once in the chat. Nothing updates the block for you: if the new decision only lives in a message, the next new chat still loads the old one and the drift starts over.

Keep it small and current rather than complete and stale. A short block of the decisions that actually get reopened, kept accurate, beats an exhaustive document nobody maintains — because the model reads what you paste, and what you paste is only right if you keep it right.

Common mistakes

A few habits let the AI keep drifting:

  • Deciding out loud but never writing it down. A call made only in the chat is gone the moment the window rolls or you open a new one.
  • Recording what you chose but not what you rejected. The rejected option is what the model re-proposes; leave it out and you'll keep saying no to the same idea.
  • Mixing settled and open in one list. If the model can't tell which is which, it treats settled decisions as still up for debate.
  • Assuming the tool remembers. Nothing syncs or persists on its own — the block works because you pasted it, and it's current only if you keep it current.
  • Never checking the AI read it. A pasted block the model skimmed past changes nothing; make it restate the decisions before it works.

A worked example: a landing page that keeps overpromising

Say you're writing landing-page copy for a tool with clear decisions: the tone is direct, not hype; the product helps people work but doesn't build finished apps for them; the SEO copy must not overpromise. You rejected "the product builds your app for you" early. Three chats later, the AI writes a hero line: "Build and ship your app automatically" — exactly the claim you cut. Here's the messy decision history turned into a block that heads it off:

Scattered decisions, turned into a block that stops the overclaim
Scattered through the chats:
  "keep the tone direct, no hype"     -> Always Remember: tone is direct, not hype
  "we help people work, we don't
   build apps for them"               -> Never Assume: do not claim the product
                                         builds or ships finished apps
  "'builds your app for you' — no,
   we cut that"                       -> Rejected: "builds/ships your app for you"
                                         (an overclaim we decided against)
  "SEO copy can't overpromise"        -> Constraint: no guaranteed-outcome claims
  "pricing wording — still deciding"  -> Open: pricing copy (not settled)

Use it like this (paste before the task):
  "Here are the project decisions. Restate them, then write the hero copy.
   Do not claim the product builds or ships apps; keep the tone direct,
   not hype; flag anything that would conflict before writing."

  Now, instead of "Build and ship your app automatically," the model writes
  to the decisions — and asks, rather than guessing, on the open pricing copy.

Where this fits in NewPrompt

Keeping one project's decisions straight is a working habit. When carrying a project across chats, models, or teammates becomes routine, the AI Project Handoff Workflow connects these moves into a repeatable pass — capture the current state, distill what's worth keeping, re-establish it as standing project context, and review the handoff for the decisions it's missing. Throughout, NewPrompt structures the decision block and the handoff; you enter and edit the decisions, paste the block into your own AI tool, keep it current, and confirm the output actually followed it.

Tools for this guide

Each generates the prompt described above — you run it in your own AI assistant.

Ready-made resources

Reusable prompts and templates for the exact steps in this guide.

Take it further

When this task is one step inside a larger workflow or build.

FAQ

Does NewPrompt remember my project decisions or sync them between chats?

No. NewPrompt doesn't store your decisions, sync between chats, or connect to your AI account. The tools build a decision block or handoff in your browser; you copy it and paste it into your own AI tool — its project or custom instructions for the standing block, or the first message of a new chat for a handoff. When the block loads in every chat, that's your tool re-reading what you pasted, not a memory NewPrompt keeps.

Will a decision block guarantee the AI never reverses a decision?

No — it reduces drift, it doesn't give the model perfect memory. A block the model reads at the start of a task makes it far more likely to honor your decisions, but models still slip, so open important tasks by having the AI restate the decisions, and check the output against them before you rely on it. Consistency comes from the block plus the check, not the block alone.

What's the difference between a standing decision block and a handoff?

Time scope. A standing block — pasted into your tool's persistent instructions — holds the decisions that are always true (the stack, the terminology, the do-not rules), so every new chat starts with them. A handoff is a snapshot of now — decisions plus current state and open tasks — that you paste as the first message when you continue the same work in a fresh chat. The [Context Handoff Builder](/tools/context-tools/context-handoff-builder) makes the second; the [Project Context Builder](/tools/context-tools/project-context-builder) makes the first.

Do I really need to write down the options I rejected?

Yes — they're the decisions the AI reopens most. A rejected option leaves no trace in the conversation, so the model re-proposes it as a fresh idea unless you record it as an explicit do-not rule, ideally with the reason. "Don't add write access — we rejected it for the audit risk" stops the suggestion from coming back every few chats.