Most people treat AI conversations like texting — fire and forget. But in a multi-turn session, context decays, decisions drift, and the model quietly forgets what you agreed on three messages ago.
The fix isn't shorter sessions. It's treating conversation state as an artifact you own — not chat residue. The best practitioners maintain a running context block that they re-paste at key moments, use explicit "pin" commands to lock decisions, and design their conversations with checkpoints.
This is the difference between a chaotic brainstorm that goes nowhere and a structured working session that produces real output.
02 Weak vs. Strong
EX 01Architecture discussion that doesn't contradict itself
I'm designing a backend for a task management SaaS. Let's maintain a DECISIONS register throughout this conversation.
Format for the register:
- DECIDED: [thing] — [reason] — [turn #]
- OPEN: [thing being discussed]
- REJECTED: [thing] — [why]
First decision:
DECIDED: PostgreSQL as primary datastore — strong relational model for task hierarchies, JSONB for flexible metadata — Turn 1
Now, given PostgreSQL as our primary store, what caching layer makes sense for read-heavy dashboard queries? Consider our constraints: 2-person eng team, hosted on Railway, budget under $50/mo for infrastructure.
[Every 4–5 turns]: "Before we continue — here's our current register:
DECIDED: PostgreSQL (Turn 1), Redis for caching (Turn 3), REST not GraphQL (Turn 5)
OPEN: Authentication approach
REJECTED: MongoDB — no relational integrity for task dependencies (Turn 2)
Continue with authentication options."
→ Why it works
The DECISIONS register acts as version-controlled state. Re-pasting it every few turns prevents drift. The model can't contradict a decision that's explicitly in its current context window.
EX 02Multi-session project with context handoff
Context handoff from yesterday's session. Paste this at the start of every new session:
---
PROJECT: TaskFlow API (task management SaaS)
STACK: Go + PostgreSQL + Redis on Railway
ROLE: You are a senior backend architect helping me design the API layer.
DECISIONS (locked):
1. RESTful API with versioned routes (/api/v1/...)
2. JWT auth with 15-min access + 7-day refresh tokens
3. Pagination: cursor-based, not offset (for real-time task feeds)
4. Rate limiting: 100 req/min per user, Redis token bucket
5. Error format: {"error": {"code": "TASK_NOT_FOUND", "message": "...", "details": {}}}
GOTCHAS (things we learned the hard way):
- Task dependencies create cycles — we need DAG validation on write
- Soft delete only — legal requires 90-day retention
TODAY'S GOAL: Design the WebSocket layer for real-time task updates.
Constraint: must coexist with the REST API, same auth tokens.
---
Start by proposing the event types we need for real-time task updates.
→ Why it works
The handoff block is a portable, session-independent artifact. It captures decisions, gotchas, and today's goal. The model starts exactly where you left off — no re-explanation needed.
03 Key Points
01Re-state key decisions every 4–5 turns — models lose salience over distance
02Use a DECISIONS register: DECIDED (locked), OPEN (discussing), REJECTED (with reason)
03Pin context with explicit blocks: 'For the rest of this conversation, assume…'
04Summarize before pivoting: 'Before we move on — confirm these 3 things are locked'
05Start new sessions with a context handoff, not from scratch
04 Model-Specific Notes
Claude has strong long-context retention but still drifts on decisions made 20+ turns ago. Explicit re-pinning every 5 turns is the reliable pattern. Use XML tags: <decisions>, <context>, <today_goal>.
05 For Your Role
Think of it like meeting notes. You wouldn't walk into a meeting and say 'let's continue from where we left off' without an agenda. Give the AI the same courtesy — paste your notes.