English version of Thalamus: Esoscheletro Cognitivo Per LLM
1. The Biological Origin: Why the "LLM Cortex" is Collapse
In the human brain, the thalamus is not a simple passive cable pass-through. It is the mind's central relay station, sensory filter, and gating mechanism. It processes, prioritises, and routes incoming sensory information before it reaches the cerebral cortex. Without this active filter, the cortex would be inundated with endless ambient noise, leading to immediate cognitive collapse.
Current AI development integrations (like VS Code Copilot or OpenWebUI) suffer from exactly the same problem. Every time the IDE interacts with a model, it sends a chaotic mass of unstructured context: proprietary system prompts, giant directory trees, static skill declarations, and entire unfiltered chat histories.
We find ourselves feeding our "LLM cortex" a 150+KB "Token Soup" to answer trivial questions like "Where is this function defined?" This crude approach results in:
- Huge Computational Waste: Biblical prefill times on local inference engines (Ollama, Llama.cpp), saturating VRAM and chip bandwidth (a critical issue when working locally on unified-memory hardware).
- Context Drift & Entropy: Models lose focus ("Lost in the Middle") due to contradictory instructions accumulated in previous rounds.
- Idempotency Loss: Duplicate or failed requests resend the same mass of tokens without maintaining a clean state.
2. The Paradigm Shift: "Context Window as RAM, not Storage"
LLM application builders are making a fundamental mistake: treating the context window like a hard disk.
Recent research (formalized by projects like Mem0 in 2026) demonstrates that the context window behaves exactly like system RAM: it is volatile, extremely computationally expensive, and its performance degrades exponentially as the number of input tokens increases.
Furthermore, the most recent scientific literature ("The Price of Meaning: Why Every Semantic Memory System Forgets" has mathematically demonstrated an intrinsic limitation of systems based purely on semantic search (classical vector RAG): organizing information based solely on geometric meaning inevitably generates interference, false recalls, and amnesia under load. Vector search is not sufficient for software development, where pinpoint precision is required.
For this reason, Thalamus introduces a hybrid, deterministic memory architecture:
- The State Blackboard (Postgres JSONB): AA persistent, centralized registry that tracks active "Dependency Contracts" (real DB schemas, API contracts, current task, and existing components). The LLM does not need to infer the project's state by rereading the history; it receives it as a deterministic snapshot.
- Episodic Memory (Qdrant Vector DB): Used exclusively to retrieve relevant historical fragments via Topic Routing (e.g., isolating vectors tagged
#databasewhen working on the backend, preventing CSS noise from contaminating the SQL logic).
3. The Evolution of Middleware: The "Tabula Rasa" Pattern
In its first conceptual implementation, Thalamus operated passively via an n8n orchestrator, intercepting payloads and applying complex Regex to "scrub" the client's XML tags. This approach proved to be fragile and partial: it forced the need to constantly chase boilerplate changes from various providers.
We then refined the architecture by switching to the Tabula Rasa (Active Reconstruction) pattern.
Thalamus now acts as a standalone Cognitive Middleware written in FastAPI and placed behind a standardization gateway (LiteLLM). When the client sends a request:
- Tabula Rasa: Thalamus intercepts the call and discards the client's proprietary system prompt to avoid "token soup".
- Optional (Non-Mandatory) Degreaser: The microservice includes a flexible degreaser module to clean up client tags and extract useful information (e.g., selected code or file references). However, it is not a blocking constraint: if the degreaser fails or the client format changes, the pipeline does not stop.
-
Metadata Extraction: Isolates the
message_id(to ensure idempotence on Postgres) and thesession_id. - Active Reconstruction: Build a dense and structured prompt from scratch by combining the Blackboard snapshot, the sliding window of the Postgres chat logs, and the last raw message from the user.
Why Thalamus?
Before delving into the architecture, a brief reflection on how I came up with this idea (Italian only).
👉 The Stochastic Parrot: Beyond Metaphor, Toward an "Alien" Intelligence
4. Pipeline Operation Flow v2
The lifecycle of each interaction in Thalamus is divided into two asynchronous hooks:
Pre-Hook (Context Summary)
-
Idempotency Check: Checks whether the
message_idis already present in Postgres. If so, immediately returns the cached response. -
State & Vector Fusion: Extracts the active
state_blackboardand queries Qdrant, filtering on the currenttopic_tag. -
Prompt Assembly: Generates the final prompt by inserting structured update rules using the XML
<thalamus_update>tags.
Post-Hook (Learning and Writing State)
-
Contract Parsing: Intercepts the LLM output before it reaches the client, looking for the
<thalamus_update>block. - Blackboard Patch: Performs an atomic update (JSONB patch) on Postgres to record new architectural changes (e.g., newly created files or modified schemas).
- Episodic Logging: Saves the degreased chat turn (pure user/assistant only) in Postgres for future calls.
5. Call for Collaboration: Get on Board
Thalamus is an experimental open-source project and is currently a work in progress.
I want to be extremely clear and transparent to avoid false expectations: currently, the infrastructure stack (Postgres + Qdrant + LiteLLM + FastAPI Core) is ready and executable in Docker, but only the logic and communication flow between the components has been tested. We've validated the interception infrastructure, persistence, and payload passing, but we're not yet looking at a turnkey assistant ready for daily use in production. The agent's deep logic and the stability of state changes on Blackboard are actively being developed.
We're in the most exciting phase of the project: the one where theory collides with practice and there are many "open avenues" to explore. We're looking for developers, software architects, and local AI enthusiasts to collaborate on these open challenges:
-
Gravity RAG Algorithms: Implement the logical time decay formula of the
gravity_scorein conversational logs to mathematically decide when a message should "fade" to avoid saturating episodic memory. - Blackboard Conflict Management: Design resolution algorithms when the LLM proposes state changes that contradict active contracts or the database schema.
-
Prompt Multi-Model DB Tuning: Optimize system prompt templates (hot-stored in Postgres in
system_config) to map different behaviors to different models (e.g., DeepSeek-R1 vs. local Llama-3).
If you want to get your hands dirty with an architecture that challenges the limits of contest management.
🧠 Thalamus: LLM Context Orchestrator & Cognitive Exoskeleton
Stop sending the "token soup." Start orchestrating high-density cognitive flows based on Active Prompt Reconstruction.
⚠️ Project Status: Work In Progress (Flow-Tested Concept)
Thalamus is currently a highly experimental, open-source concept. The orchestration infrastructure (FastAPI, Postgres, Qdrant, and LiteLLM) is fully scaffolded and containerized via Docker, but currently only the logical communication flow has been validated. It is not yet a plug-and-play production assistant. We are actively developing the core agentic reasoning loops and state blackboard patch synchronization.
🚀 The Problem: Context Overflow & "Lost in the Middle"
Current LLM-IDE integrations (VS Code Copilot, Continue, OpenWebUI) suffer from a structural flaw: they treat the LLM's context window as an hard disk rather than RAM. Every single query sends up to 150KB+ of unformatted "Token Soup" (redundant system prompts, static tool definitions, full unstructured chat histories, and massive directory trees).
This approach causes:
- …
💬 Leave a comment below with your thoughts or open an issue in the repository to start discussing the design!
Top comments (0)