How do I give AI context so it stops repeating mistakes?
Keep a handoff-ready account of the current state; provide relevant evidence rather than an entire chat history.
On this page
Direct answer
Context engineering asks what AI needs to know for this task, which information remains valid and where it can be checked. More text does not necessarily produce a better judgment. Missing facts, obsolete decisions and irrelevant material can all cause confusion. Maintain a concise current state, trace important claims to evidence, and begin a new round by inspecting the implementation that actually exists.
When to use
- A long conversation keeps returning to an approach that was already rejected.
- You need to continue the same project after changing tools, models or conversations.
Step by step
Locate the real scope of the task
Describe the user problem and entry point, then inspect relevant code, configuration, errors and callers. Avoid pasting an entire repository merely because it is large; an isolated error without its triggering action is also insufficient.
Separate facts, decisions and ideas
Facts describe observed behavior; decisions are accepted constraints; ideas remain unverified options. Attach a file, screenshot or check result to important facts so a later session does not mistake a discussion for an implemented feature.
Save the smallest usable handoff
Record the goal, completed scope, unresolved issues, key files, how to run and the next action. Before starting with a summary, check that it retained restrictions and did not turn failures into successes.
Recheck information that changes quickly
Library APIs, platform policies and tool options need the installed version and official documentation. If external documentation conflicts with project code, state the conflict before choosing a migration.
Verify before resuming work
A new conversation should read the handoff and key implementation, then confirm uncommitted changes and verification status. Update the account after changes and remove superseded conclusions; do not keep several contradictory documents that all claim to be current.
Diagnose the symptom and add the smallest evidence packet
First record a concrete failure: entry point, version, action, observed result and expected result. For missing context, add the relevant function and callers. For excess material, provide an index and search cues before opening excerpts. For obsolete assumptions, state the new situation and retired decisions. If evidence is already sufficient but execution is wrong, inspect the implementation or model judgment instead of blaming the prompt alone. Produce an evidence card that locates the problem.
Locate excerpts first, then apply a three-color check
Useful approaches include a specific code excerpt, locating an entry point before reading, handing off to a fresh conversation, and consulting external evidence. Before submission, mark green for current facts locatable in a file or log, yellow for unresolved hypotheses, and red for obsolete or irrelevant material. Without code access, supply a minimal reproducer, relevant configuration and full error context. With access, find the actual entry point before widening the search, so an unrelated authentication module is not mistaken for the active call chain.
Ask the question that changes implementation, then fix the decision
Look for hidden assumptions, unclear boundaries and whether a desired feature serves a real user need. Ask one important question at a time when its answer changes goals, data or permissions. Check existing answers first and use defaults for low-risk details. Record each answer as decision, reason and acceptance: whether a shared link requires sign-in, whether a failure can be retried, or whether a record can be undone. Begin when goals, non-goals and critical boundaries have checkable answers; a fixed number of interview rounds is not a completion criterion.
Index long-lived knowledge with validity conditions
Rules, references, memory, skills and tool settings serve different roles. Add evidence, review time, applicable version and supersession links to reusable knowledge. When facts change, retain a necessary change record and invalidate the old conclusion. Keep sensitive evidence only in authorized locations; hand off a sanitized conclusion and controlled reference. Feeding every email or customer record into a model is unnecessary, and discoverability does not grant permission to read or act.
Worked example
Hypothetical exercise: handing off a payment issue
Payment is complete is ambiguous. A better handoff says: a test payment was created, its callback has not arrived, the local endpoint is in the identified file, signature configuration has been ruled out, and the next step is to inspect the public callback address. The next collaborator can investigate without rebuilding the payment flow.
Action checklist
Reusable templates
Project continuation handoff
Goal:
Accepted constraints and decisions:
Implemented and verified:
Implemented but unverified:
Current failure and reproduction steps:
Key files and evidence:
Unsuccessful approaches and reasons:
Smallest next action:
Resumption rule: check code and state first. Flag an outdated summary; do not treat a suggestion as completed work.
Minimal context evidence card
Task and user outcome:
Current entry point, page or caller:
Code version, uncommitted changes and environment:
Triggering actions and input:
Observed result → expected result:
Relevant files, log times or screenshots:
Green: verified current facts, with evidence for each:
Yellow: hypotheses or unknowns and how to test them:
Red: obsolete decisions or unrelated information to ignore this round:
Constraints that must hold:
Critical questions for the user, or none:
Smallest deliverable, acceptance and stopping condition:
Conversation handoff and knowledge-expiry table
Goals and non-goals:
Decision → reason → evidence for the decision:
Implemented work → file or version → tested scope:
Failed, unexecuted or missing configuration:
Next entry point and first check:
Knowledge item | Evidence | Applicable version | Last review | Expiry trigger | Replacement
Recipient checks: do the files exist, has the version changed, does the failure remain, and did the summary confuse discussion with completion?
Exclude plaintext keys, full customer records and unauthorized material.
Pitfalls
- A large context window is not a reason to include unlimited material; noise still affects judgment.
- A summary is an index and work state, not a substitute for evidence.
- Do not include passwords, keys or complete personal records in a general handoff.