Context architecture for continuous AI workbench

What we were testing ?

The initial problem was continuity: how can a professional workbench stay involved in the same engagement for weeks, months or even years?

During that time, conversations accumulate, decisions change, documents are added and working assumptions evolve continuously. We found out that simply sending more history to the model was not the answer.

The experiment then shifted to a question of context architecture:

What information should remain active and become persistent? What should be retrieved only when relevant, and what should eventually disappear?

What we observed ?

Different information was being treated as if it belonged to the same memory layer, even though it didn't. We progressively separated it into several areas that required different retrieval and persistence rules:

• reference knowledge - documents and reusable content retrieved when relevant;
• working state - what is currently true and needed to continue the task;
• engagement memory - decisions, constraints and material changes tied to a specific engagement;
• core behavioural memory - stable ways of reasoning, structuring and challenging work;
• provisional memory - recent corrections and emerging patterns that may or may not remain useful;
• feedback calibration - examples of outputs that were accepted, rejected or corrected.

What we changed

The target context assembly became closer to the following framework:

Base behaviour
+
Relevant reference knowledge
+
Core behavioural memory
+
Relevant engagement memory
+
Relevant provisional observations
+
Relevant feedback examples
+
Current working state

This translated into several concrete mechanisms in the workbench:

1. Stable knowledge and instructions could be pinned and kept available, while larger knowledge sources were retrieved dynamically through RAG.
2. Engagement-specific information was stored separately so that it would only influence work related to that engagement.
3. Learned preferences could be injected into the prompt without being confused with client facts or reference knowledge.

However, the engagement-memory implementation also exposed a failure in our first approach. Initially, every distillation rewrote the engagement memory using a snapshot of the latest conversation window, which meant that as the engagement evolved, older context and decisions could progressively disappear.

What we did was rebuild the mechanism so that engagement memory became mostly append-oriented:

• new context is appended when a new phase emerges;
• key decisions are dated and retained;
• reversals are added explicitly rather than replacing the original decision;
• structural choices are preserved;
• resolved open questions can disappear;
• older information is compressed when the memory reaches approximately 8,000 characters;
• the current phase remains available in greater detail.

To ensure continuity, we found out that the way persistent information evolves over time matters as much as what is actually stored.

What we retained ?

A continuous AI workbench does not need one large memory. It needs several forms of context with explicit boundaries.

This raises practical design questions:

• Is this information knowledge, memory or current state?
• Should it apply everywhere or only to one engagement?
• Should it always be present permanently or retrieved when relevant?
• Can it become stale?
• If it changes, should the previous state disappear or remain traceable?
• What mechanism weakens or compresses information once it becomes less useful?

The architecture we retained was therefore focused on controlling scope, persistence, retrieval and evolution separately.

Takeaway

When designing a sustained AI workbench, the challenge is deciding which information matters, where it belongs, how it is retrieved and how it changes without destroying useful history.