Multi-Turn Conversation Management

Intermediate

Your context is leaking. Plug the holes.

01 The Concept

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):

RESTful API with versioned routes (/api/v1/...)
JWT auth with 15-min access + 7-day refresh tokens
Pagination: cursor-based, not offset (for real-time task feeds)
Rate limiting: 100 req/min per user, Redis token bucket
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: , , <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.

Next: Prompt Chaining →