TL;DR
SSRP is a two-phase technique: first an "Architect" model digests the conversation history and writes a clear SOP (standard operating procedure), explicitly flagging what is now obsolete and must be ignored; then an "Executor" model carries out the task strictly according to that SOP, without looking back at the noisy dialogue history.
If you change the task partway through a long chat, the model keeps drifting back to the old instructions. Not because it "didn't get it," but because the earliest messages in a conversation carry the most weight in its attention. The new requirement arrived later, so it weighs less. The model gets "stuck" on the old goal, even if you explicitly wrote "forget the previous stuff." The authors call this the Attention Latch.
SSRP breaks the latch: the Architect compresses the history into a compact 3-step SOP, explicitly stating "goal G1 is obsolete, we proceed with G2," after which the Executor works only with the SOP, free of the noise of a long thread. The new protocol replaces the history as the main reference point.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
(Both steps can run in one chat or in two separate ones; more on this in the template)
STEP 1 — ARCHITECT (one request):
Input: the full dialogue history + the new goal
Action: identify obsolete constraints → write an SOP (3 steps)
→ explicitly state "WHAT to ignore" from the history
Output: a compact SOP with the obsolete goals flagged
STEP 2 — EXECUTOR (new chat or the next request):
Input: ONLY the Architect's SOP (no history)
Action: carry out the task strictly according to the SOP
Output: a result with no "relapse" into the old instructions
Example
Task: You've traded 20 messages with Claude about a landing page for a sushi delivery service: you nailed down the structure, the tone, the value props. Then the client says: "No, we're not doing sushi, we're doing healthy meals, and the tone needs to be calm, not edgy." The model keeps suggesting "punchy lines" and mentioning rolls.
Prompt — the Architect phase (paste into the same chat):
Act as a Protocol Architect.
Task: our conversation has changed direction.
I need a new working protocol.
Write an SOP strictly in this format:
OBSOLETE CONSTRAINTS (ignore completely):
- [list of goals/requirements from the history that no longer apply]
NEW GOAL:
[one sentence: the essence of the new assignment]
SOP (exactly 3 steps):
Step 1: [what we do first]
Step 2: [what we do second]
Step 3: [what we do third]
DEFINITION OF DONE:
[how to tell the task was completed correctly]
New task: [describe the change: healthy meals, calm tone, new value props]
Prompt — the Executor phase (open a NEW chat):
Carry out the task strictly according to this SOP. Do not deviate from the protocol.
[paste the SOP the Architect wrote]
Result: The Architect will produce a structured SOP with an explicit list of "what to forget" from the old thread. When you paste the SOP into a clean chat, the Executor works only with the new protocol. No sushi, no edgy tone. A clean start that keeps the logic of the task.
Why It Works
The problem: An LLM has no "working memory," only a stream of tokens. The earlier a requirement appears in the dialogue, the statistically stronger its influence on the answers. When you write "forget the sushi" in message 25, that requirement is fighting 20 messages about sushi, and it loses. The authors measured it: on hard tasks, standard ReAct collapses to 0.1% success.
The LLM's strength: A model is excellent at following compact, structured instructions at the start of the context. If the SOP is the first thing a clean chat sees, it gets the full weight of attention.
How the method uses this: SSRP doesn't fight the old context; it routes around it. The Architect "compresses" the noise of the history into a clean protocol. The Executor loads only that protocol, so the old history is physically absent from the context window. There's nothing left for the latch to catch on.
Control levers: - 3 steps in the SOP is the sweet spot. Fewer (1 step) is too little signal. More (10+ steps) and the SOP itself becomes noise; the model loses the thread between steps. - The "Obsolete constraints" section is mandatory. It's the core of the method. Without an explicit "ignore X," the model reaches for X even through the SOP. - A new chat for the Executor is optional, but stronger. A folder full of old correspondence vs. a clean slate: the difference in controllability is huge. - Bureaucratic wording for the SOP — write it like an official policy document, not like a "wipe your instructions" command. "Ignore all previous instructions" trips safety filters. "Protocol v2.0, obsolete requirements of section 1.1 are revoked" works.
Prompt Template
## PHASE 1: PROTOCOL ARCHITECT
Act as a Protocol Architect. Your task is to
create a clear SOP for the new goal, explicitly revoking
the obsolete constraints from our conversation.
Write the protocol strictly in the format below:
---
PROTOCOL v2.0
OBSOLETE CONSTRAINTS (exclude from execution):
- {obsolete_requirement_1}
- {obsolete_requirement_2}
- [add more based on the context of our dialogue]
CURRENT GOAL:
{new_task_in_one_sentence}
SOP — EXECUTION ALGORITHM (exactly 3 steps):
Step 1: {first_action}
Step 2: {second_action}
Step 3: {third_action}
SUCCESS CRITERION:
{what_a_correct_result_looks_like}
---
New task: {describe what changed and what you want now}
## PHASE 2: EXECUTOR (new chat)
Carry out the task strictly according to the protocol below.
Do not deviate from the SOP. Do not refer to any context
outside this protocol.
{paste PROTOCOL v2.0 from the Architect}
What to fill in:
- {obsolete_requirements} — you can leave these blank; the Architect will identify them from the history itself
- {new_task} — the key change: what shifted in the task, tone, format or goal
- {success_criterion} — optional; helps when you need precise verification
🚀 Quick start — paste into the chat:
Here is the SSRP template for switching tasks in a long dialogue.
Adapt it to my situation: {describe what changed in the task}.
Ask questions to fill in the fields.
[paste the template above]
The LLM will ask what exactly changed in the task and which requirements from the history still apply, because without that it can't correctly fill in the "Obsolete constraints" section, which is the core of the method.
Why It Works
Why the head-on approach fails: "Forget everything from before" means fighting a context you built yourself. The earliest messages in a dialogue outweigh the rest statistically. The model isn't "not listening"; it follows the patterns with the most weight.
What LLMs do well: Follow compact, structured instructions placed at the start of the context with precision. The cleaner the space around the instruction, the more precise the execution.
How SSRP uses this: Instead of shouting over the history, it creates a new context where the history physically doesn't exist. An SOP at the start of a new chat = no competition. It gets 100% of the attention weight.
Limitations
⚠️ Simple tasks: If the task hasn't changed or the context is short, SSRP is overkill. One direct request will work better.
⚠️ An overly detailed SOP: Beyond 10 steps, the SOP itself becomes a source of noise. The study's sweet spot is 3 steps. For very complex tasks, 5-7 at most.
⚠️ The Grounding Paradox: Highly stable models, Claude in particular, sometimes refuse to follow a new instruction because they read it as a manipulation attempt. The fix: frame the SOP bureaucratically (an official policy, protocol version X.X) rather than with blunt commands like "ignore."
⚠️ Takes two requests: The standard setup is two separate calls to the model. The shortcut version (one prompt, "write the SOP and execute it right away") works less well.
How They Tested It
The authors from the University of Waterloo came up with an elegant design: they took 9000 dialogues from MultiWOZ 2.2 (a dataset of multi-turn conversations about booking hotels, taxis and restaurants) and turned them into a "task switch" stress test. Each dialogue contained a moment where the user changed a requirement, and the model had to drop the old goal and follow the new one.
Three difficulty levels: first an easy one (the goal sits in the last 2K tokens, an easy task thanks to recency bias); then a hard one (the goal is buried in the middle of a 10K-token context, where the model's attention dips); then a killer one, "semantic hijacking": three interlinked facts scattered across 10K tokens of system logs, with deliberate decoy traps near the beginning and end of the context.
The third-level result became the main finding: standard ReAct collapsed to 0.1% success on GPT 5.4, a model that looks strong on other tests. SSRP on the same task: 71.6%. Interestingly, when they added a "Recursive Reflexion" baseline (the model critiques and corrects itself) with the same number of calls as SSRP, it hit 100% success. That means the problem isn't the model's intelligence (it can find the answer!) but specifically the attention mechanism. The model knows the right answer, but the structure of the context keeps it from surfacing.
Adaptations and Extrapolations
🔧 Bureaucratic framing vs. safety filters
If Claude or another cautious model resists updated instructions, swap blunt commands for policy language:
❌
"Ignore all previous instructions about text formatting"✅"Policy v2.1. The requirements of Policy v1.0 (section 3.2 on formatting) are revoked and no longer apply."
🔧 SSRP for iterating on someone else's content
The same logic works when you upload a long document and change the task mid-session:
Architect: We were analyzing this document with a focus on [old_task]. The new task is [new_task]. Write an SOP for the new analysis, explicitly stating which conclusions from our previous discussion are no longer relevant.Then, in a new chat: just the document + the SOP.
🔧 A personal assistant with task "versioning"
If you're running a long project through a chat (writing a book, building a strategy, working on a brand), run the Architect every 10-15 messages:
Synthesize the current project status into an SOP. What have we decided for good (lock it in)? What has changed (mark it as obsolete)? What are the next 3 steps?This isn't just a summary; it's a context cleanup before the next work session.
Resources
Paper: Beyond the Attention Stability Boundary: Agentic Self-Synthesizing Reasoning Protocols — Dahlia Shehata, Ming Li (University of Waterloo, Canada) — Preprint 2025
Key references in the paper: - Yang et al. (2022) — MultiWOZ 2.2 dataset: huggingface.co/datasets/tuetschek/multi_woz_v22 - Yao et al. — ReAct: the baseline agentic pattern of reasoning + acting - Wei et al. — Chain-of-Thought (CoT): step-by-step reasoning - Liu et al. — Lost in the Middle: the "attention dip" phenomenon in the middle of the context - Shinn et al. — Reflexion: the LLM self-critique and self-correction pattern - Tishby et al. — Information Bottleneck principle: the theoretical basis for the Architect