## TL;DR
A reply containing another customer's order history is a session-isolation failure: data fetched for customer A leaked into the context used for customer B. Isolate strictly: each conversation gets its own state scope, data fetches are parameterized by the conversation's customer, and nothing crosses the boundary without an explicit, logged reason. Customer data must never be ambient.

## The query

```text
agent mixed up two customers' order histories in one reply: session isolation
```

## Use this when

- Replies contain the wrong customer's data
- Order histories get crossed between customers
- You are building multi-customer agents
- Auditing data-isolation incidents

## Not for

- Improving reply wording
- Designing order systems
- Setting access control policies
- Data warehouse design

## Steps

### 1. Scope all conversation state per conversation

Each conversation owns its state: customer id, fetched orders, context. State lives in the conversation's scope and is unreachable from other conversations. Global or shared mutable state is where the mixing happens.

Expected output: per-conversation state scoping.

### 2. Parameterize every data fetch by the conversation's customer

Order lookups take the customer id from the conversation scope, never from a variable, cache, or "current customer" global. The fetch signature makes the customer explicit; explicitness defeats staleness.

Expected output: customer-parameterized data fetches.

### 3. Verify the reply's data belongs to the conversation's customer

Before sending, check that every order id and customer reference in the draft matches the conversation's customer. The check is cheap and catches the mixing mechanically, even when the isolation itself failed.

Expected output: pre-send data-ownership verification.

### 4. Clear context aggressively on conversation switch

When an agent moves between conversations, wipe the previous conversation's fetched data from working memory. Lingering data is the leak vector; explicit clearing removes it. Switches reset, they do not accumulate.

Expected output: context clearing on every switch.

### 5. Treat any mixing as a severity-1 incident

Customer data in the wrong hands is a privacy incident, not a bug ticket: investigate the leak path, notify per policy, and fix the isolation before resuming. The severity reflects what leaked, not how the code felt about it.

Expected output: incident-grade response to any mixing.

## Template: the checklist

```text
Session isolation:
[ ] Per-conversation state scoping
[ ] Customer-parameterized data fetches
[ ] Pre-send data-ownership verification
[ ] Context cleared on conversation switch
[ ] Mixing treated as severity-1 incident
```

## Variant phrasings

### agent showed wrong customers orders

Steps 1 and 2. Scope state, parameterize fetches.

### crossed customer data in reply

Steps 3 and 4. Verify before send, clear on switch.

### customer data leak between conversations

Steps 1 and 5. Isolate, respond as an incident.

## Why it happens

Agents reuse: caches, variables, "the last fetched order" lingering in context across turns. In a single-customer session the reuse is harmless; the moment the agent serves two customers (parallel chats, a triage run across tickets), the reuse becomes cross-contamination. The optimization that was safe in one context is a privacy violation in another.

## Edge cases

- Shared caches across conversations: a cache keyed by order id without customer scoping serves A's data to B. Scope cache keys by customer.
- The agent summarizing "recent orders" from memory: memory of another conversation's orders is the leak. Summaries draw only from the current scope.
- Test data in production sessions: test customers' orders mixed into real replies. Separate test and production contexts entirely.
- Family or shared accounts: legitimately shared data still needs explicit scoping rules. Define who may see what.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VHqJcuAYlT1RWNIcUfSGYg