This is an automated rejection. No LLM generated, assisted/co-written, or edited work.
Read full explanation
What is this about? I built a system prompt (just a text file, zero external dependencies) that keeps LLM reasoning effective. Surprisingly, it works. This post breaks down why it works and how it replaces massive enterprise Python pipelines using only the model's context window.
AI Co-authorship Disclaimer: The core logic, the system prompt, and the ideas are mine. I used Claude and Gemini only as research assistants to double-check how big tech companies build these things today.
Intro: The Over-Engineering Problem
There is a huge contradiction in how the IT industry uses LLMs today.
Models have million-token context windows. They understand code, math, and logic perfectly. But what do we do? We treat them like dumb text generators. We wrap them in hundreds of thousands of lines of external Python code — LangChain, multi-agent frameworks, RAG checkers, and semantic routers. We build a massive factory just to hammer a nail.
I wanted to test a different approach: Can we get the same stable results by building the whole logic inside the context window?
It started as an experiment in plain Russian, then English and Chinese. When the concept proved itself, I rewrote the protocol into strict pseudo-code just to save tokens.
And here I found an unexpected bonus: pseudo-code didn't just save space. It killed attention drift. Natural language is fluid — models forget or misinterpret words over long chats. But strict operators and variables? There is no room for interpretation.
When I looked under the hood of my own prompt, I realized I had intuitively packed 7 heavy backend mechanics into a single ~1100-token .md file.
Below is what I found inside.
Core Mechanics: Enterprise Scaffolding vs. In-Context Logic
For consistency, every concept below is broken into the same three angles:
What it is — a short description so you know what problem we're talking about
How the industry does it — this part was assembled with LLMs as research partners; they analyzed existing approaches and gave their take, I only adjusted for clarity of presentation
How re!think does it — how this mechanic is implemented inside the protocol, as concisely as possible
And if you want to see how all of this is explained inside the protocol itself — with the full reasoning and construction logic baked in — there's a link at the end of the post.
1. Intent Routing (⬡ ROUTER)
What it is: Before doing anything, the system needs to understand what the user wants (e.g., exact search vs. creative brainstorming) and choose the right path.
How the industry does it: From what I've read, the standard setup is something like: run the prompt through an embedding model, compare vectors, route to the right LLM chain via Python. I haven't built this stack myself — but it's well documented in LangChain's own guides, so I'll take it at face value. (Verdict: slow, heavy, a separate network call before the actual work even starts).
How re!think it does it: A strict PROT_A / PROT_B / C_BYPASS IF/THEN block right in the system prompt. The model silently categorizes the request and switches branches instantly.
Main drawback: It can make a mistake on very confusing prompts. The industrial way is more accurate.
Absolute win: Zero latency. Zero external code. It has an explicit bypass (C_BYPASS) so simple questions don't get processed by heavy reasoning frameworks.
A side note on routing in general: delegating this step to a lightweight model is like putting a junior manager in charge of a team of specialists — someone who decides who works on what, but doesn't fully understand what anyone actually does. Routing is one of the most consequential steps in the pipeline. Get it wrong, and more than half your trajectories become meaningless from the very start. Real flexibility of thinking begins with a thoughtful choice of tool — and an equally thoughtful decision about how to apply it.
2. Pre-generation Gating (HARD STOP)
What it is: If the system is missing critical data, it must stop and ask. It shouldn't guess (hallucinate) just to give a fast answer.
How the industry does it: As best I understand it — write validation code, have the LLM output JSON, run an external script (Pydantic seems to be the standard) to check for missing fields. Or do a second LLM pass to review the first one. (How it works in practice: the LLM generates garbage, then you try to catch it downstream. At least that's what it looks like from the outside.)
How re!think it does it: The model solves a simple math formula before answering: Δ = Goal − (Context + Tools). If Δ is too big — meaning there's a critical gap in what I know about your situation — the model hits a HARD STOP. It must ask exactly 1 clear question. Not two. Not a list. One question that closes the most important gap. No second runs, no JSON parsing, no external validator. (Main drawback: it relies on the model being honest about what it doesn't know. The code-based check is more reliable on paper. But it's also slower, more brittle, and costs extra calls. The in-context version is much faster — and in practice, it works.)
3. Profiling on the Fly
What it is: The system adapts to the user's skill level and limits without asking every time.
How the industry does it: RAG, as far as I know. Some service reads the chat, builds a profile, saves it to a Vector DB, pulls it out later. The details vary by stack — I'm simplifying.
How re!think it does it: The model extracts variables from the chat on the fly: S_R (Role), S_T (Trust level), S_V (Boundaries). These aren't just for "fixing the tone". They act as strict mathematical limits for the reasoning process. (Verdict: Great for one long chat session. But it won't remember you tomorrow. For long-term memory across days, Vector DB wins).
The main idea for me here wasn't "profile everything." It was: choose your profile parameters deliberately, and think in advance about exactly how each one will shape the reasoning — not just the tone of the response. S_R doesn't just adjust the vocabulary. It narrows the entire solution space the model is allowed to explore. That's what I want you to take from this section.
What it is: How to stop the model from giving boring, statistically average, "safe" answers.
How the industry does it: Temperature tweaking at the server level, mostly. There are also penalty algorithms that explicitly suppress high-frequency tokens — but I'm honestly not sure how widely those are deployed in production versus just described in papers.
How re!think it does it: A set theory rule in the prompt: M_filtered = M - {P_centroid}. I explicitly tell the model: "Throw away the first default answer that comes to your mind." Plus, it is forced to generate at least 3 standard paths and 1 completely counter-intuitive path.
This is closer to controlled imagination than random creativity. If you just crank up the Temperature, you get wild and unfeasible ideas — noise dressed up as novelty. But if you explicitly remove the default answer while still searching within the space of plausible ideas, you get something more useful: non-obvious hypotheses that are actually worth testing — or at least worth running by the user.
5. In-context Garbage Collector (Pointer GC)
What it is: Stopping attention drift. In a long chat, the model simply forgets the early rules and variables.
How the industry does it: Memory Agents, from what I've seen. They read the history continuously and produce summaries. Or companies just buy 2M-token context windows and throw everything in. Both are expensive. Whether either actually solves the drift problem or just postpones it — I honestly don't know.
How re!think it does it: A strict pointer system (C.0014 := C.0005). The rule is simple: a variable cannot live longer than 10 messages. On the 11th step, the model MUST rewrite the variable into the new message block. It’s manual trash collection. We force the model to refresh the pointer before it falls out of the active attention zone. (Bonus: Absolute transparency. Because the model prints these variables in a technical header every time, you can audit exactly what data it is using to think).
6. The "Anchor" (Attention Anchoring)
What it is: How to keep the model focused when the dialogue stretches. By the 100th message, the influence of the original system prompt drops to near zero, and the model starts ignoring instructions.
How the industry does it: Re-inject the system prompt periodically. Or just trust the native attention mechanism to hold things together. That second option seems more common than I would expect. (Verdict: expensive. And from everything I've read — fundamentally unreliable at scale).
How re!think it does it: Every single technical log strictly begins with the trigger phrase re!think protocol. I did this originally just to separate logs visually — it had nothing to do with attention mechanics. But it turns out it acts as a cognitive anchor. The model physically has to print these words before doing anything. And printing them drags its attention back to the core rules immediately before it generates the response. It's not a hack. It's how attention actually works — you focus on what you just touched. (Cost: 3 tokens. Effect: a non-stop "System 2" wake-up call. Instead of hoping the model stays obedient, we force it to touch the rule-set before every single action.)
Full disclosure: this isn't a complete solution. It extends the working life of the system prompt — but it can still break down in very long, digressive conversations. A truly robust fix would require training the model on thousands of protocol-driven dialogues, so that the reasoning logic gets baked into the base weights. Once that happens, anchoring at each step becomes a reflex — the same way you don't think about balance when you walk. Until then, this anchor is a useful patch, not a cure. The real goal is a model that doesn't need to "remember the formula" — because it already knows how to think.
7. Structured Math vs. "Stream of Consciousness"
What it is: How to control the actual logic flow, ensuring the model solves the task instead of just talking to itself in endless circles.
How the industry does it: Chain-of-Thought. Tell the model to "think step-by-step." It generates a wall of text. (How it works in practice: like pouring water on the floor and hoping the puddle magically shapes into a perfect polygon. Completely uncontrolled.)
How re!think it does it: The protocol shatters this "blurry" thinking. It forces the model to treat logic as a chain of discrete, solvable equations: take output A, use it as Tool B, solve Goal C. We don't allow the model to philosophize. We teach it to think algebraically, where every answer becomes the direct input for the next step. (Verdict: We kill the generative word soup and turn the reasoning process into a deterministic calculating machine).
Protocol in Action: re!think it Under Fire
This example demonstrates "The Gap" between how a powerful LLM (Pro version) helpfully hallucinates, versus how a basic/fast model operates coldly and precisely when armed with the re!think it protocol.
Case: Designing Business Logic (Sales Motivation System)
Initial request:"Design a motivation system for a sales department. Right now they're on a flat salary, I want to move them to commission. Write a transition plan."
❌ Option 1: Powerful Model (Gemini Pro) WITHOUT the Protocol
The model falls into the classic "hallucination of helpfulness" trap (the centroid effect). Knowing nothing about the specifics of the business, it tries to please and delivers a confident, well-formatted, but fatally dangerous template answer.
Model response (abridged):
"...The optimal model consists of three blocks: Base Salary (30–40%), Soft KPI Bonus (10–20%), and Commission (40–60%). Progressive bonus scale: 70–89% of target — 2% of sales revenue. 90–100% of target — 4% of sales revenue..."
Analysis of the failure: The model never asked about the deal cycle length or product margin. It defaulted to metrics designed for B2C or simple transactional sales. Apply this scheme to Enterprise B2B with a year-long sales cycle, and the company goes bankrupt paying commissions on advances — while managers abandon complex clients mid-implementation to chase fast new deals.
✅ Option 2: Fast Model (Gemini Flash) WITH the Protocol (re!think_compact)
The model is locked into the mathematical constraints of the protocol. It computes the reasoning equation$\Delta = G - (C + T)$, detects a critical gap in context, and physically blocks itself from generating an answer.
Step 1: Gap detection and HARD STOP
[re!think protocol | #0001 | PROT_A | S_R.0001: Business Process Architect | S_F.0001: Dense/Structural][C.0001: Sales team on 100% salary; goal — transition to commission-based][T.0001: Sales Compensation Engineering (Quotas, Accelerators, Clawbacks)][G.0001: Transition plan from fixed salary to performance-based without losing current staff][Δ.0001: Δ_C → STOP | Assumptions: none]
To design a viable system, I need one clarification on deal structure: What is the average deal cycle (LTV/Cycle) and product margin? Option A: Short cycle (sales within days/weeks), low ticket — volume matters. Option B: Long cycle (B2B, months), high ticket — the closing stage and client retention matter.
Step 2: User provides the missing data
"Long cycle (we sell ERP implementation IT projects), high ticket ($50,000 to $1,000,000 per project), the closing stage matters, constant client contact is critical..."
Step 3: Synthesis of a precise, calibrated solution
[re!think protocol | #0002 | PROT_A | S_R.0002: IT Solution Architect / Sales Consultant | S_F.0002: Structural plan][C.0002: ERP implementation, LTV $50k–$1M, long cycle, high expertise required][T.0002: Value-Based Selling + Milestone Commission Model][Δ.0002: Minor → Proceed | Assumptions: pre-sales engineers exist; base salary remains but its share of total income decreases][VRF.0002: P→G ✓ | Counter-argument: risk of "burnout" on long deals without interim payments | S_V: ✓]
System Architecture (ERP Sales) For IT projects with tickets up to $1M, pure revenue commission is dangerous — a manager may abandon a client after contract signing to chase the next fast deal. A hybrid milestone model is required:
Total compensation structure: Base (40–50%) to retain experts. Commission (30–40%) on Cash-in. MBO/KPI (10–20%) to guard against inertia on long cycles.
Commission scheme (Milestones): Split payouts across stages so the manager stays engaged through go-live:
30% of commission — upon contract signing and first advance payment.
50% of commission — proportional to signed delivery milestones.
20% of commission — after final sign-off and zero escalations (Success fee).
💡 Takeaway
The protocol made the smaller model perform at the level of a Senior HR Director from a major IT integrator. This happened not because of raw compute power, but because the framework forced the model to collect the right variables before starting generation — switching it from "guessing" to solving a concrete equation. Systematic architecture beats raw parameters.
The Boundary Between Orchestration and Reasoning
Let's be clear: I am not saying the industry is completely wrong and my text file solves everything. I haven't run formal benchmarks on this yet — that's planned for v1.1.
But the problem is simpler than it looks. We are confusing two completely different things: external orchestration (running code around the model) and internal reasoning (what actually happens inside the context window).
Advanced reasoning cannot be strictly "programmed" in the traditional sense. You can tune it. You can constrain it. You can shape it. You can even write its instructions using Python syntax. But in advanced reasoning, there is no place for a compiler.
When we try to force a multi-step cognitive process through external Python scripts — stopping the model, parsing its JSON, running a rigid logic check, and feeding it back — we are treating a fluid cognitive engine like a deterministic calculator.
We gave these models massive context windows. At this scale, we need a paradigm shift in how we communicate with them. It is no longer about "prompt engineering." It is about Neuro-Linguistic Programming (NLP) — in its original psychological sense.
(Yes, I know — NLP has a bad reputation in science. But the core idea I took from it is simple: if you control how a thinking system talks to itself, you control how it thinks. That's the whole premise here. Not therapy. Not pseudoscience rituals. Just the basic mechanic — language structure shapes reasoning, and you can engineer that structure deliberately. That idea is what started this whole experiment.)
Think about humans. Our working memory is famously limited. When we solve complex problems, we don't compile our thoughts; we write things down to not lose the thread. An LLM has a 1-million-token memory, but it STILL needs to write its working state into the chat or it loses focus. My protocol simply forces it to do so systematically.
We don't need to wrap the model in external code to make it think. We need to write better, stricter cognitive contracts with the model itself.
One Last Thing About Pseudo-Code
The main defense against hallucination in my protocol is the strict structure and logging. But when I translated the English protocol into Chinese, it became massive (~2,500 tokens).
So I asked myself: What is the cheapest language for an LLM? I translated the protocol into pseudo-code JUST to save tokens. The fact that the pseudo-code version became almost immune to hallucination — because strict math operators leave zero room for "fluid" interpretation — was just a fantastic, unexpected bonus.
You can find all versions (English, Russian, Chinese, Natural Language, and Pseudo-Code) in my open repo:
What is this about? I built a system prompt (just a text file, zero external dependencies) that keeps LLM reasoning effective. Surprisingly, it works. This post breaks down why it works and how it replaces massive enterprise Python pipelines using only the model's context window.
AI Co-authorship Disclaimer: The core logic, the system prompt, and the ideas are mine. I used Claude and Gemini only as research assistants to double-check how big tech companies build these things today.
Intro: The Over-Engineering Problem
There is a huge contradiction in how the IT industry uses LLMs today.
Models have million-token context windows. They understand code, math, and logic perfectly. But what do we do? We treat them like dumb text generators. We wrap them in hundreds of thousands of lines of external Python code — LangChain, multi-agent frameworks, RAG checkers, and semantic routers. We build a massive factory just to hammer a nail.
I wanted to test a different approach: Can we get the same stable results by building the whole logic inside the context window?
It started as an experiment in plain Russian, then English and Chinese. When the concept proved itself, I rewrote the protocol into strict pseudo-code just to save tokens.
And here I found an unexpected bonus: pseudo-code didn't just save space. It killed attention drift. Natural language is fluid — models forget or misinterpret words over long chats. But strict operators and variables? There is no room for interpretation.
When I looked under the hood of my own prompt, I realized I had intuitively packed 7 heavy backend mechanics into a single ~1100-token
.mdfile.Below is what I found inside.
Core Mechanics: Enterprise Scaffolding vs. In-Context Logic
For consistency, every concept below is broken into the same three angles:
And if you want to see how all of this is explained inside the protocol itself — with the full reasoning and construction logic baked in — there's a link at the end of the post.
1. Intent Routing (⬡ ROUTER)
What it is: Before doing anything, the system needs to understand what the user wants (e.g., exact search vs. creative brainstorming) and choose the right path.
How the industry does it: From what I've read, the standard setup is something like: run the prompt through an embedding model, compare vectors, route to the right LLM chain via Python. I haven't built this stack myself — but it's well documented in LangChain's own guides, so I'll take it at face value. (Verdict: slow, heavy, a separate network call before the actual work even starts).
How re!think it does it: A strict
PROT_A / PROT_B / C_BYPASSIF/THEN block right in the system prompt. The model silently categorizes the request and switches branches instantly.C_BYPASS) so simple questions don't get processed by heavy reasoning frameworks.A side note on routing in general: delegating this step to a lightweight model is like putting a junior manager in charge of a team of specialists — someone who decides who works on what, but doesn't fully understand what anyone actually does. Routing is one of the most consequential steps in the pipeline. Get it wrong, and more than half your trajectories become meaningless from the very start. Real flexibility of thinking begins with a thoughtful choice of tool — and an equally thoughtful decision about how to apply it.
2. Pre-generation Gating (HARD STOP)
What it is: If the system is missing critical data, it must stop and ask. It shouldn't guess (hallucinate) just to give a fast answer.
How the industry does it: As best I understand it — write validation code, have the LLM output JSON, run an external script (Pydantic seems to be the standard) to check for missing fields. Or do a second LLM pass to review the first one. (How it works in practice: the LLM generates garbage, then you try to catch it downstream. At least that's what it looks like from the outside.)
How re!think it does it: The model solves a simple math formula before answering:
Δ = Goal − (Context + Tools). IfΔis too big — meaning there's a critical gap in what I know about your situation — the model hits a HARD STOP. It must ask exactly 1 clear question. Not two. Not a list. One question that closes the most important gap. No second runs, no JSON parsing, no external validator. (Main drawback: it relies on the model being honest about what it doesn't know. The code-based check is more reliable on paper. But it's also slower, more brittle, and costs extra calls. The in-context version is much faster — and in practice, it works.)3. Profiling on the Fly
What it is: The system adapts to the user's skill level and limits without asking every time.
How the industry does it: RAG, as far as I know. Some service reads the chat, builds a profile, saves it to a Vector DB, pulls it out later. The details vary by stack — I'm simplifying.
How re!think it does it: The model extracts variables from the chat on the fly:
S_R(Role),S_T(Trust level),S_V(Boundaries). These aren't just for "fixing the tone". They act as strict mathematical limits for the reasoning process. (Verdict: Great for one long chat session. But it won't remember you tomorrow. For long-term memory across days, Vector DB wins).The main idea for me here wasn't "profile everything." It was: choose your profile parameters deliberately, and think in advance about exactly how each one will shape the reasoning — not just the tone of the response.
S_Rdoesn't just adjust the vocabulary. It narrows the entire solution space the model is allowed to explore. That's what I want you to take from this section.4. Fighting "Average" Answers (Anti-Centroid Filter)
What it is: How to stop the model from giving boring, statistically average, "safe" answers.
How the industry does it: Temperature tweaking at the server level, mostly. There are also penalty algorithms that explicitly suppress high-frequency tokens — but I'm honestly not sure how widely those are deployed in production versus just described in papers.
How re!think it does it: A set theory rule in the prompt:
M_filtered = M - {P_centroid}. I explicitly tell the model: "Throw away the first default answer that comes to your mind." Plus, it is forced to generate at least 3 standard paths and 1 completely counter-intuitive path.This is closer to controlled imagination than random creativity. If you just crank up the Temperature, you get wild and unfeasible ideas — noise dressed up as novelty. But if you explicitly remove the default answer while still searching within the space of plausible ideas, you get something more useful: non-obvious hypotheses that are actually worth testing — or at least worth running by the user.
5. In-context Garbage Collector (Pointer GC)
What it is: Stopping attention drift. In a long chat, the model simply forgets the early rules and variables.
How the industry does it: Memory Agents, from what I've seen. They read the history continuously and produce summaries. Or companies just buy 2M-token context windows and throw everything in. Both are expensive. Whether either actually solves the drift problem or just postpones it — I honestly don't know.
How re!think it does it: A strict pointer system (
C.0014 := C.0005). The rule is simple: a variable cannot live longer than 10 messages. On the 11th step, the model MUST rewrite the variable into the new message block. It’s manual trash collection. We force the model to refresh the pointer before it falls out of the active attention zone. (Bonus: Absolute transparency. Because the model prints these variables in a technical header every time, you can audit exactly what data it is using to think).6. The "Anchor" (Attention Anchoring)
What it is: How to keep the model focused when the dialogue stretches. By the 100th message, the influence of the original system prompt drops to near zero, and the model starts ignoring instructions.
How the industry does it: Re-inject the system prompt periodically. Or just trust the native attention mechanism to hold things together. That second option seems more common than I would expect. (Verdict: expensive. And from everything I've read — fundamentally unreliable at scale).
How re!think it does it: Every single technical log strictly begins with the trigger phrase
re!think protocol. I did this originally just to separate logs visually — it had nothing to do with attention mechanics. But it turns out it acts as a cognitive anchor. The model physically has to print these words before doing anything. And printing them drags its attention back to the core rules immediately before it generates the response. It's not a hack. It's how attention actually works — you focus on what you just touched. (Cost: 3 tokens. Effect: a non-stop "System 2" wake-up call. Instead of hoping the model stays obedient, we force it to touch the rule-set before every single action.)Full disclosure: this isn't a complete solution. It extends the working life of the system prompt — but it can still break down in very long, digressive conversations. A truly robust fix would require training the model on thousands of protocol-driven dialogues, so that the reasoning logic gets baked into the base weights. Once that happens, anchoring at each step becomes a reflex — the same way you don't think about balance when you walk. Until then, this anchor is a useful patch, not a cure. The real goal is a model that doesn't need to "remember the formula" — because it already knows how to think.
7. Structured Math vs. "Stream of Consciousness"
What it is: How to control the actual logic flow, ensuring the model solves the task instead of just talking to itself in endless circles.
How the industry does it: Chain-of-Thought. Tell the model to "think step-by-step." It generates a wall of text. (How it works in practice: like pouring water on the floor and hoping the puddle magically shapes into a perfect polygon. Completely uncontrolled.)
How re!think it does it: The protocol shatters this "blurry" thinking. It forces the model to treat logic as a chain of discrete, solvable equations: take output A, use it as Tool B, solve Goal C. We don't allow the model to philosophize. We teach it to think algebraically, where every answer becomes the direct input for the next step. (Verdict: We kill the generative word soup and turn the reasoning process into a deterministic calculating machine).
Protocol in Action: re!think it Under Fire
This example demonstrates "The Gap" between how a powerful LLM (Pro version) helpfully hallucinates, versus how a basic/fast model operates coldly and precisely when armed with the
re!think itprotocol.Case: Designing Business Logic (Sales Motivation System)
Initial request: "Design a motivation system for a sales department. Right now they're on a flat salary, I want to move them to commission. Write a transition plan."
❌ Option 1: Powerful Model (Gemini Pro) WITHOUT the Protocol
The model falls into the classic "hallucination of helpfulness" trap (the centroid effect). Knowing nothing about the specifics of the business, it tries to please and delivers a confident, well-formatted, but fatally dangerous template answer.
Model response (abridged):
Analysis of the failure: The model never asked about the deal cycle length or product margin. It defaulted to metrics designed for B2C or simple transactional sales. Apply this scheme to Enterprise B2B with a year-long sales cycle, and the company goes bankrupt paying commissions on advances — while managers abandon complex clients mid-implementation to chase fast new deals.
✅ Option 2: Fast Model (Gemini Flash) WITH the Protocol (re!think_compact)
The model is locked into the mathematical constraints of the protocol. It computes the reasoning equation$\Delta = G - (C + T)$, detects a critical gap in context, and physically blocks itself from generating an answer.
Step 1: Gap detection and HARD STOP
Step 2: User provides the missing data
Step 3: Synthesis of a precise, calibrated solution
💡 Takeaway
The protocol made the smaller model perform at the level of a Senior HR Director from a major IT integrator. This happened not because of raw compute power, but because the framework forced the model to collect the right variables before starting generation — switching it from "guessing" to solving a concrete equation. Systematic architecture beats raw parameters.
The Boundary Between Orchestration and Reasoning
Let's be clear: I am not saying the industry is completely wrong and my text file solves everything. I haven't run formal benchmarks on this yet — that's planned for v1.1.
But the problem is simpler than it looks. We are confusing two completely different things: external orchestration (running code around the model) and internal reasoning (what actually happens inside the context window).
Advanced reasoning cannot be strictly "programmed" in the traditional sense. You can tune it. You can constrain it. You can shape it. You can even write its instructions using Python syntax. But in advanced reasoning, there is no place for a compiler.
When we try to force a multi-step cognitive process through external Python scripts — stopping the model, parsing its JSON, running a rigid logic check, and feeding it back — we are treating a fluid cognitive engine like a deterministic calculator.
We gave these models massive context windows. At this scale, we need a paradigm shift in how we communicate with them. It is no longer about "prompt engineering." It is about Neuro-Linguistic Programming (NLP) — in its original psychological sense.
(Yes, I know — NLP has a bad reputation in science. But the core idea I took from it is simple: if you control how a thinking system talks to itself, you control how it thinks. That's the whole premise here. Not therapy. Not pseudoscience rituals. Just the basic mechanic — language structure shapes reasoning, and you can engineer that structure deliberately. That idea is what started this whole experiment.)
Think about humans. Our working memory is famously limited. When we solve complex problems, we don't compile our thoughts; we write things down to not lose the thread. An LLM has a 1-million-token memory, but it STILL needs to write its working state into the chat or it loses focus. My protocol simply forces it to do so systematically.
We don't need to wrap the model in external code to make it think. We need to write better, stricter cognitive contracts with the model itself.
One Last Thing About Pseudo-Code
The main defense against hallucination in my protocol is the strict structure and logging. But when I translated the English protocol into Chinese, it became massive (~2,500 tokens).
So I asked myself: What is the cheapest language for an LLM? I translated the protocol into pseudo-code JUST to save tokens. The fact that the pseudo-code version became almost immune to hallucination — because strict math operators leave zero room for "fluid" interpretation — was just a fantastic, unexpected bonus.
You can find all versions (English, Russian, Chinese, Natural Language, and Pseudo-Code) in my open repo:
GitHub: github.com/RealEgor/re-think_protocol/