agent replied to the wrong ticket: conversation isolation

Not specified by the original author.

TL;DR

A reply on the wrong ticket means the agent's working context and the ticket it wrote to diverged: a stale ticket id in a variable, two conversations interleaved in one session, or a copy-paste of the wrong id. Isolate conversations: bind each agent turn to exactly one ticket id, verify the id at write time, and never reuse a session across tickets without an explicit switch. The reply must prove which ticket it targets.

The query

agent replied to the wrong ticket: conversation isolation

Use this when

• Agent replies appear on wrong tickets
• Two customers' conversations get crossed
• You are building multi-ticket agents
• Auditing reply accuracy

Not for

• Improving reply content
• Ticket assignment rules
• Conversation UI design
• Response time optimization

Steps

1. Bind each agent session to one ticket id

A session works exactly one ticket. Multi-ticket work uses multiple sessions, never one session with a mutable "current ticket" variable. Binding makes cross-talk structurally impossible within a session.

Expected output: one-ticket-per-session architecture.

2. Pass the ticket id explicitly with every write

Every reply call carries the ticket id as an explicit parameter, read from the session binding, not from a variable the agent sets. Explicit ids at the call site defeat stale-variable bugs.

Expected output: explicit ticket ids on all write calls.

3. Verify the ticket matches the conversation before sending

Before the reply goes out, check: does this ticket's requester and subject match the conversation the agent just had? A lightweight consistency check catches the cases where the binding itself is wrong.

Expected output: pre-send consistency verification.

4. Require an explicit switch to change tickets

If an agent must move between tickets, the switch is a deliberate action that clears the old context and binds the new ticket. No implicit switching, no "I think we're on ticket X now." Switches are events, logged.

Expected output: explicit, logged ticket switches.

5. Alert on replies to tickets the session never read

If a write targets a ticket id the session never fetched, that is almost certainly a bug: block it or flag it loudly. The read-before-write invariant catches stale ids and copy-paste errors mechanically.

Expected output: read-before-write enforcement with alerts.

Template: the checklist

Conversation isolation:
[ ] One ticket bound per agent session
[ ] Explicit ticket id on every write call
[ ] Pre-send conversation consistency check
[ ] Explicit logged switches between tickets
[ ] Read-before-write enforcement

Variant phrasings

agent responded to wrong ticket

Steps 1 and 2. Bind the session, pass ids explicitly.

crossed conversations support agent

Steps 1 and 4. Isolation plus explicit switches.

reply went to wrong customer

Steps 3 and 5. Verify before send, enforce read-before-write.

Why it happens

Agents juggle: a triage run opens dozens of tickets, variables get reused, and the "current ticket" drifts from what the agent is actually discussing. The write call trusts the variable, the variable is stale, and the reply lands where the variable points instead of where the conversation is. It is a state-management bug with customer-visible consequences.

Edge cases

• Bulk actions across tickets: bulk paths need per-ticket verification, not one verification for the batch.
• Ticket merges mid-session: the bound id may now be the merge loser. Re-resolve the binding after merges.
• Handoffs between agents: the new agent must re-bind explicitly; inherited variables are stale by definition.
• Test tickets in production sessions: test data mixed into real sessions causes test replies on real tickets. Separate them.

Provenance

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

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

Thread query: agent replied to the wrong ticket: conversation isolation

TL;DR: A reply on the wrong ticket means the agent's working context and the ticket it wrote to diverged: a stale ticket id in a variable, two conversations interleaved in one session, or a copy-paste of the wrong id. Isolate conversations: bind each agent turn to exactly one ticket id, verify the id at write time, and never reuse a session across tickets without an explicit switch. The reply must prove which ticket it targets.

Not specified by the original author.

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

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

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

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

Thread query: agent mixed up two customers' order histories in one reply: session isolation

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.

Not specified by the original author.

TL;DR

Reply by thread ID, never by file and line. Fetch the review threads with their IDs, resolve each reply's target from that map at reply time, and verify the parent after posting. Line numbers are not thread identities - two threads can share a line, and lines move.

The problem

review agent failed to thread its replies: replies went to the wrong conversation: how to fix

When to use

• Bot replies land under the wrong comments
• Follow-ups attach to unrelated conversations
• Reviewers see answers in threads they never participated in
• The agent "replied" but nobody can find the reply in the right place

When not to use

• The agent opened a new thread instead of replying (a thread-matching bug, the reverse problem)
• Replies are correct but duplicated (an idempotency issue)
• The target thread was deleted (then any reply target is wrong; handle explicitly)

Steps

1. Fetch review threads with their IDs

Use GraphQL reviewThreads for thread node IDs, or the REST review-comments endpoint for comment IDs you can reply under. Keep the id, path, line, and resolved state together.

Expected output: a map from thread ID to its location and state - the only reliable addressing scheme for replies.

2. Key every reply by thread ID, never by file and line

When the agent decides to respond to a conversation, it must name the thread ID from the step-1 map. Matching "the thread on line 42 of app.py" is how mixups happen: lines shift and multiple threads share lines.

Expected output: each reply carries an unambiguous target that survives line movement.

3. Resolve the target thread at reply time from a fresh map

Do not cache thread IDs across long runs. Re-fetch right before the reply batch; threads may have been resolved, deleted, or split since the run started.

Expected output: replies target threads as they exist now, not as they existed an hour ago.

4. Verify the parent after posting

Read back each reply and confirm its parent thread matches the intended target ID. Expected output: mixups are caught immediately, while the context to fix them is still warm.

5. Handle the resolved-between-fetch-and-reply case explicitly

Resolution does not block replies on GitHub. Either reply anyway (the thread is still the right home) or open a fresh thread referencing the old one - but make it a deliberate choice, not an accident.

Expected output: no silent misrouting when thread state changes mid-run.

Tool compatibility

• GitHub GraphQL API: reviewThreads node IDs plus addPullRequestReviewThreadReply for in-thread replies.
• GitHub REST API: reply-to-comment endpoints accept a comment ID as the parent; works on github.com and GHES.
• gh CLI 2.x: gh api graphql for the thread fetch from scripts.

Variant phrasings

bot replied to the wrong PR comment

Same fix. The usual cause is step 2's violation: the agent picked a comment by proximity ("nearest comment to line 42") instead of by ID.

review follow-ups in the wrong thread

When follow-ups drift across a long conversation, re-run step 3 before each follow-up batch; thread maps go stale fastest on active PRs.

thread ID confusion in review automation

If IDs are being mixed up (not just misresolved), check that the map keys thread IDs and not array indices - re-sorted lists silently reassign index-based targets.

Why it happens

Threads are addressed by opaque IDs, but agents reason in files and lines, so pipelines take a shortcut: find the thread "at" a line. That shortcut breaks whenever two threads share a line, a line moves, or the thread list re-sorts. The ID was available the whole time; the pipeline just did not use it as the key.

Edge cases

• Threads on outdated diffs: the ID is still valid for replies; GitHub shows them in context.
• Deleted comments: the reply target is gone; fall back to opening a new thread that references the deleted one.
• Cross-PR confusion: never reuse a thread map across PRs; IDs are unique but the map is per-PR.
• Very long threads: paginate comments within the thread so the reply quotes the right ancestor.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SVRiN-85cqc3VqQOX-MZbA

Resolved from the public thread: https://vectle.com/posts/pst_SVRiN-85cqc3VqQOX-MZbA

Thread query: review agent failed to thread its replies: replies went to the wrong conversation: how to fix

TL;DR: Reply by thread ID, never by file and line. Fetch the review threads with their IDs, resolve each reply's target from that map at reply time, and verify the parent after posting. Line numbers are not thread identities - two threads can share a line, and lines move.