reopt-state-and-memory-control

---
name: reopt-state-and-memory-control
description: When session state and long-term memory need to be separated. Distinguishing what must outlive the session from temporary state that should be cleared with it. When there's risk of data leakage across sessions.
---

# State and Memory Control

OCLS phase: **LAYER** · Separate short-term state from long-term memory to prevent leakage and confusion.

## Core rules

- Draw a hard line between session-scope short-term state and system-scope long-term memory.
- Short-term state is cleared automatically at session end.
- Promotion to long-term memory is governed by explicit criteria (repeated pattern, quality contribution).
- In multi-agent settings, define read/write authority on shared memory per agent.
- For long-running agents, use compaction to handle the context-window limit — preserve architectural decisions, open bugs, implementation details; discard duplicate tool output.

## Judgment question

**What stays in the session, and what gets promoted to system memory?**

## Application check

1. Is the boundary between short-term state and long-term memory explicit in code?
2. Is short-term state cleared automatically at session end?
3. Are the promotion criteria for long-term memory declared?
4. Is read/write authority on shared memory defined per agent?

## Code example

```typescript
// Short-term state — session scope (auto-expired via Redis TTL)
interface SessionState {
  sessionId: string;
  currentStep: string;
  tempVars: Record<string, unknown>;
  // ttl: 30 * 60  (auto-deleted after 30 minutes)
}

// Long-term memory — system scope (writable only when promotion criteria are met)
interface MemoryRecord {
  customerId: string;
  pattern: string;
  evidence: { sessionIds: string[]; count: number };
  writtenBy: "qa-agent"; // authority: QA writes only
  createdAt: string;
}

async function promote(observation: Observation) {
  if (observation.occurrences < 3) return; // promotion criterion unmet
  await memoryStore.write({
    customerId: observation.customerId,
    pattern: observation.pattern,
    evidence: observation.evidence,
    writtenBy: "qa-agent",
    createdAt: new Date().toISOString(),
  });
}

// Response Agent can read only
const context = await memoryStore.read(customerId); // ✅
await memoryStore.write(...);                        // ❌ no authority
```

## Antipatterns

**Customer support**: without separation, the previous session's "shipping delay" context leaks into the new session's "payment change" response, producing an inappropriate "sorry for the shipping delay." Wiping everything at session end is the opposite failure — the same customer returning with the same problem gets the same proposal again.

**Long-running coding agents**: running hundreds of steps without compaction saturates the context window and triggers incidents like "forgot the architectural decision and retried the wrong path." Compaction that preserves architectural decisions and open bugs while discarding duplicate tool output is mandatory.

## Invocation example

```
"Response Agent is leaking state between sessions.
Apply reopt-state-and-memory-control to split short-term state (SessionState)
from long-term memory (MemoryRecord), and declare promotion criteria and
write authority."
```

## Related patterns

- Context Routing — rules for transferring context across sessions
- Evaluation and Guardrails — validation of promotion criteria