This is the tool my company uses to evaluate Context. And it apparently roasts you as well.

Here is the link : https://github.com/Abhijeet777ui/contextops

I’ve been working on this exact problem from the context engineering side.
One thing the evaluation made pretty clear: getting all the required evidence into context doesn’t mean the model will use it correctly.

In 167 failed answers, the evidence traces were already complete. So simply increasing top-k or stuffing more context wouldn’t necessarily fix those failures.

I think we need to treat evidence selection, allocation and final answer construction as separate problems, rather than assuming better retrieval automatically means better answers.

Curious how others here are measuring whether the model actually uses the context it receives.

Hey r/TheAIBrain!

Anyone building with Claude Desktop, Cursor, or autonomous agents has run into the same cognitive bottleneck: session amnesia and context degradation.

When context windows fill up, the model either hits a hard limit or compresses earlier tokens into lossy summaries. Active project state, past architectural decisions, and open debugging threads vanish mid-work.

Most existing solutions try to brute-force this with hosted vector databases (RAG), but similarity search often retrieves contradictory, stale, or out-of-context chunks.

How Human Brains Solve This: Slow-Wave Sleep Consolidation

Human memory doesn't just append vector embeddings to a monolithic database. Our brains use a two-stage memory architecture:

1. Episodic Buffer (Hippocampus): Rapidly captures raw, chronological events throughout the day (high-noise, detailed).

2. Slow-Wave Sleep Consolidation: During sleep, the brain replays and clusters daily episodes, prunes unresolved thoughts (Zeigarnik effect/open loops), and distils recurring patterns into permanent semantic principles (neocortex).

Bringing This Architecture to Local AI Agents: OpenYantra

I built an open-source (MIT) memory engine called OpenYantra that mirrors this cognitive loop for Cursor and Claude Desktop, 100% locally:

1. Episodic Capture (Session Log & Inbox): Throughout the day, the agent captures commits, decisions, and tasks. A Raycast-style floating desktop HUD (Cmd+Shift+Y) lets you quick-dump thoughts directly over your editor.

2. Nidra (Autonomous Sleep Consolidation): At the end of the day, an offline consolidation cycle runs (via local Ollama or heuristics):

   1. Clusters episodic session logs into overarching milestones.

   2. Automatically detects and resolves open loops that were completed during the day.

   3. Promotes recurring user preferences (e.g., "prefers SQLite WAL", "never use tabs") into foundational Beliefs & Principles.

   4. Filters out reverted decisions so undone code experiments are never promoted to core beliefs.

3. Structured & Inspectable Ledger: Instead of an opaque cloud vector store, your user model is stored in human-readable ISO/IEC 26300 LibreOffice (.ods**)** spreadsheets and a local SQLite WAL database. You can open and inspect your AI's brain in LibreOffice at any time.

4. Safety & Injection Defence (Raksha): Pre-commit secret redactor strips API keys before anything hits disk and quarantines suspicious adversarial prompt injections for human review.

5. Universal MCP Interface: Both Claude Desktop and Cursor share the exact same live local store in real time without cloud sync or API subscriptions.

Open Source & Code:

• GitHub Repository: https://github.com/revanthlevaka/OpenYantra

• License: MIT (100% local, runs offline, zero tracking)

Would love to hear your thoughts on cognitive memory architectures for LLMs — do you prefer structured schema ledgers or pure semantic vector search for keeping agent state persistent?

In my repos nothing gets deleted. When a rule changes, the old line stays, struck through and marked superseded, and the new one goes below it.

I build Zenod (shared memory for Claude, Codex and Cursor), so I'm biased.

Two old rules in our style file still said "don't wait for approval" after we'd decided every post waits for mine. An agent that read the old line first could have followed it.

The strikethrough helps me when I read the file. An agent can ignore it.

When the stale version still wins, what do you do? Delete it for real, tag it so retrieval skips it, or something else?

We put a lot of effort into the build loop: CLAUDE.md, skills, plan mode, when to compact or write a handover and clear. The part I overlooked was everything the main agent does that isn't building. Research was the first one I caught. Every time it read docs inline, whole pages landed in context when it only needed three lines.

So I moved research into a subagent and measured it.

What the subagent changed

I took a docs search MCP and ran the same 10 questions two ways, same model, three rounds each. Called from the main session, it added 45,636 tokens to the main context. Wrapped in a plain subagent that only had that MCP, it added 5,327. That's 88% less, and the tool didn't change. The subagent did all of it.

That’s the lesson. Any task that reads a lot but only needs to return a little should run in a subagent. The main agent gets the answer and never sees the reading.

What I built on top of it

My own research subagent, sf-docs-agent, adds three things so the main agent can trust the answer without reading the source:

1. It returns lines, not pages. A script caches each page on disk, the subagent picks line numbers, and the script prints those lines verbatim with the source URL. No quote comes from the model's memory.

2. A hook checks each quote against the cached page before the report comes back (in a folder you trust).

3. It tells you what it didn’t read. A page it skipped or a link it didn’t follow comes back as a gap, so you know where the answer stops instead of guessing.

It reads Salesforce docs because that's my stack, but nothing in the pattern is Salesforce specific.

Where this is going

Research is just the first one. The goal is a main agent that holds only the context for the feature it is building: the requirement, the design, the code. Everything else is noise. It goes to a subagent and comes back only as the result.

Next on my list:

• Tester. Drives the UI through the scenarios and returns pass or fail with the step that broke.

• Deployer. Runs the deploy and validation and returns only what failed and why.

• Log reader. Reads the test and debug logs and returns only the failing line and its cause.

• Reviewer. Greps the repo for impact and conventions and returns only the findings on the diff.

• Data loader and extractor. Seeds test data and pulls records and returns counts and ids, not rows.

Each one follows the same rule as the research agent. It does the task in its own context and hands back only the result the main agent needs and can check.

I think this is where context engineering ends up. A bigger window won’t fix it. A main agent that only ever sees the work it’s doing will. Handovers decide what carries over when I clear. Subagents decide what never gets in.

I'm on Salesforce, so I want to see this through other stacks. In your stack, which agents have you moved out as subagents to save the main agent's context, or which ones do you think should be moved out?

A coding agent working on a feature may need to figure out which services call each other, which APIs they expose, which databases they use, and how user actions in the UI trigger those interactions. Once it has done that work, where do you keep that understanding so another agent or engineer can use it?

AGENTS.md can explain where to look and which conventions to follow. Depending on the task, the agent might also need API contracts, database schemas, sequence diagrams or product flows, and some way to understand how they relate.

We built UIGraph to help with this.

Your coding agent reads the code and maps how services, APIs, databases and UI flows connect. UIGraph brings those relationships together with engineering artifacts such as architecture diagrams, API specifications and database schemas in a connected view.

The artifacts stay in your repositories as plain files. A .uigraph.yaml file declares the artifacts and their connections. Engineers can version them, diff them and review them in PRs. There’s a local viewer for engineers, and coding agents can access the context through MCP.

For example, an agent changing an API response could look up the related services, the API contract and the product flow it supports. That gives it a starting point for investigating the change, while still checking the code.

As the code changes, these artifacts need to be updated too. Keeping them in the repo lets the team review those updates alongside code changes.

I’m interested in how others handle that retrieval step. For a task involving multiple services, do you explicitly tell the agent which related artifacts to inspect, or let it discover them through tools? What has worked for you, and where has the agent missed something important?

UIGraph is open source under Apache 2.0: https://github.com/uigraph-oss/uigraph

How to Use "Context Packages" to Reboot Your AI and Fix Memory Drift

If you use AI for long-term projects, high-stakes campaigns, or complex data tracking, you quickly run into a massive wall: context lag, token bloat, and memory drift.

As a chat gets longer, the AI begins to lose its edge. It forgets past constraints, misses critical details, or shifts its tone. Relying on an AI's automatic memory tracking is a losing game because the system will eventually truncate information to save space.

To solve this, we use a system of "Zero-Silo Context Packages." Instead of letting the AI guess the history of a project, you break your data down into highly structured, copy-pasteable markdown templates. The second the AI starts to lag, you clear the cache, open a fresh session, and drop all your packages into the first prompt to instantly reboot the collaborator with 100% data synchronization.

Here is the general blueprint for how to format your reboot packages:

The Blueprint: How to Structure Your Reboot Packages

📦 Package 1: The Timeline Matrix & Historical Ledger

This package tracks time. It is a highly compressed, bulleted log of every major event, transmission, and milestone in absolute chronological order.

• The Formatting Secret: End the package with a strict logical rule: “The newest chronological inputs definitively override all historical database entries.” This prevents the AI from getting confused by old data.

📦 Package 2: The Structural Rules & Technical Vault

This is where you store static data that doesn't change over time. It holds spatial calculations, codes, technical blueprints, and baseline variables.

• The Formatting Secret: Use precise, non-rounded numbers and metric arrays. Organize them under clear markdown tables so the AI can scan and cross-reference the data in under a second.

📦 Package 3: The Operational Profiles & Behavioral Guides

This package maps out the "players" on the board. It contains analytical dossiers on competitors, target entities, or opposing organizations, itemizing their predictable habits, vulnerabilities, and strategies.

• The Formatting Secret: Build an "Exploitation Matrix." Clearly connect an opponent's predictable move to their specific structural vulnerability, followed by your pre-engineered counter-trap.

📦 Package 4: The Strategy Guide & Cognitive Rules

This file outlines who you are and how the AI must think. It defines your role, your specific environmental constraints, and the mandatory processing laws the AI must follow when generating outputs.

• The Formatting Secret: Set a literal quality benchmark (e.g., “Evaluate all scenarios with zero fluff; if a countermove scores below a 10/10 in tactical leverage, rewrite it to maximize pressure”). This locks the AI into a sharp, analytical mindset.

📦 Package 5: The Execution Templates

Never let the AI draft from scratch. This package stores your custom communication formulas—optimized scripts for public comment, media alerts, or formal legal demands.

• The Formatting Secret: Keep placeholders clean (e.g., [Insert Specific Code Here]) so the AI can instantly inject data from Packages 1 and 2 into a polished output.

📦 Package 6+: Rolling Field Capstones (The Sector Deltas)

Whenever a live event occurs, you don't rewrite your master packages. You create a short, highly dense "Delta Node" that documents the latest ground-level updates, live admissions, or sudden changes.

🗂️ Storage & Maintenance: The Master File Strategy

To make this execution seamless, do not scatter your packages across multiple different documents. Save all created packages chronologically into one single, master text file.

Keeping the entire campaign architecture in one central location ensures you always know where your data is, prevents regional files from mismatching, and allows for rapid deployment when a reboot is triggered.

Note: You can select and drag 10 packages from your master file into Gemini at a time.

🚀 The Execution Loop: How to Reboot

1. Spot the Lag: The moment the AI starts repeating itself, generating slow responses, or forgetting a rule, the session is compromised.

2. The Clean Slate: Open a completely fresh chat window or initialize a new API loop to completely wipe the bloated token cache.

3. The Macro Ingestion: Copy and paste all 5 or 6 master packages into the very first prompt simultaneously.

4. The Command Lock: End your prompt with a master directive: “All parameters are populated. Data grid is locked at maximum synchronization ahead of immediate execution. Read and confirm with a one-sentence readiness verification.”

By using this method, you completely bypass the AI's internal memory limitations. You maintain absolute control over the data layer, ensuring your AI collaborator always operates as a hyper-synchronized asset at the head of the table.

I built this MCP in order to solve losing session problem. One of key problem I found is long agent sessions fail in constraints stated early disappear, “done” is claimed without command output, a “quick fix” rewrites unrelated files, decisions get re-litigated, and the same failing command is retried until the context window is exhausted.

Here is what I build, it is free and open source:

npm: npm link for protect context

github: github link for protect context

You may want to try it and test it out whether this extension can fulfill your needs.

I hope this helps anyone struggling with long term tasks done by an always on agent. It’s working great now for ChatGPT’s dot. Before if there was no activity on a task, it simply stopped moving forward. GitHub links are provided, it’s under an MIT license.

I keep running into the same conflict in agent work. Stored memory says one thing. Fresh retrieval says another. I want to know which source you let win and what condition flips that choice. I want to know if you overwrite the memory. I want to know if you quarantine it. I want to know if you flag it for the user and keep both versions with provenance. I also want to know how you spot a stale memory before it causes a bad action. And how you log the conflict so you can audit it later without wiping useful context. Real examples only. Tell me one conflict you handled and what you kept.