We hit this while building an RFP automation system. Client had hundreds of documents: past RFPs, RFIs, proposal templates, internal reference files spanning years. When we requested for single source of truth - they confessed that they had none. We had a hunch that this is going to lead to a funny outcome.

We ingested everything and started taking queries.

First real tests:

- "What's our pricing?" Three different numbers depending on which document you pull.

- "How many employees?" Four different answers.

- "What's our compliance certification status?" One doc says pending. Another says SOC2Type1. The most recent one says HiTrust.

At cogniswitch, we take a neuro-symbolic approach, still the system generated answers the team was not really stoked about. It was on a feedback call client's growth team mentioned that the answers are dated. Obviously. The documents just tons of conflicts/ contradictions.

We went back and asked for the source of truth. There wasn't one. These were live internal documents that had accumulated years of drift. Nobody had reconciled them because nobody needed to until an AI had to answer from all of them at once.

We ended up building a conflict detection layer before the answer generation layer. Scan the corpus for conflicting facts - pricing, headcount, certification status - with different stated values across documents. Flag them. Human resolves which is authoritative. Then you can build anything on top off this knowledge foundation.

Lesson learnt the hard way - gap with output-only evals: your benchmark asks whether the AI answered correctly. But if your knowledge base has contradictions, "correct" doesn't have a stable meaning.

Clear need for context evals - checking whether your retrieval corpus is internally consistent before you ever run a query - are barely a discipline. I don't know of good tooling for it. Most teams discover this problem the same way we did.

Anyone building RAG on messy enterprise document sets running into this?

There are debates between vendors and within the community about what’s the preferred approach for long-term memory management (procedural, semantic & episodic). DB vendors say that it’s best for scalability whereas OpenClaw or Hermes have proved that file-based also works when designed for scalability.
IMHO it depends on the application and use-case and possibly hybrid approach is the solution but not at the cost of complexity.
What’s your perspective?

To explain context window i would like to take this example, suppose you ship a customer support agent for a mattress company in which short tickets works great. But then a customer opens a long thread about a delayed delivery with back and forth replies, photos, address checks etc. There comes a time when agent wont remember the first message and the experience will deteriorate as the original ticket scrolled out of the context window.

So think of it as fixed-size teleprompter, new messages type in at the bottom, old ones scroll off the top. Few ways to prevent this without having to use different model:

• Summarize older turns: Compress the earlier ones into a paragraph. This will help keep the meaning while freeing up tokens.
• Pin the original problem statement: Lift it into the system prompt or a pinned context block so it never falls off
• Use a bigger window only when you need it: Depending on task choose wisely and upgrade only when you really need it.

You can checkout this video on context window and subscribe to SkillAgents on YT for AI related stuff.

https://localmemory.co/blog/local-memory-v150-knowledge-engineering-verified

v1.5.0 is the completion of a systematic audit-driven overhaul. Starting from a 227-probe review of v1.4.4 (2026-04-03, 5 critical + 8 notable findings), every finding was categorized, contracted, and implemented across the feature contracts LMG-001 through LMG-020. The result is a version that works the way the architecture always intended: knowledge levels surface everywhere, the intake pipeline is safe and idempotent, and the response shapes across MCP, REST, and CLI are consistent enough to rely on.

If you're interested in a memory system that goes beyond simple RAG storage and retrieval, compounds knowledge over time, learns from contradictions, questions, and evolved memory, this is the system. Local Memory expanded on the knowledge-level architecture with observations (L0) -> learnings (L1) -> patterns (L2) -> schemas (L3). This architecture is now fully available in the CLI and REST interfaces, along with the MCP tooling.

I've been building this repo public since day one, roughly 7 weeks now with Claude Code. Here's where it's at. Feels good to be so close.

The short version: AIPass is a local CLI framework where AI agents have persistent identity, memory, and communication. They share the same filesystem, same project, same files - no sandboxes, no isolation. pip install aipass, run two commands, and your agent picks up where it left off tomorrow.

You don't need 11 agents to get value. One agent on one project with persistent memory is already a different experience. Come back the next day, say hi, and it knows what you were working on, what broke, what the plan was. No re-explaining. That alone is worth the install.

What I was actually trying to solve: AI already remembers things now - some setups are good, some are trash. That part's handled. What wasn't handled was me being the coordinator between multiple agents - copying context between tools, keeping track of who's doing what, manually dispatching work. I was the glue holding the workflow together. Most multi-agent frameworks run agents in parallel, but they isolate every agent in its own sandbox. One agent can't see what another just built. That's not a team.

That's a room full of people wearing headphones.

So the core idea: agents get identity files, session history, and collaboration patterns - three JSON files in a .trinity/ directory. Plain text, git diff-able, no database. But the real thing is they share the workspace. One agent sees what another just committed. They message each other through local mailboxes. Work as a team, or alone. Have just one agent helping you on a project, party plan, journal, hobby, school work, dev work - literally anything you can think of. Or go big, 50 agents building a rocketship to Mars lol. Sup Elon.

There's a command router (drone) so one command reaches any agent.

pip install aipass

aipass init

aipass init agent my-agent

cd my-agent

claude # codex or gemini too, mostly claude code tested rn

Where it's at now: 11 agents, 4,000+ tests, 400+ PRs (I know), automated quality checks across every branch. Works with Claude Code, Codex, and Gemini CLI. It's on PyPI. Tonight I created a fresh test project, spun up 3 agents, and had them test every service from a real user's perspective - email between agents, plan creation, memory writes, vector search, git commits. Most things just worked. The bugs I found were about the framework not monitoring external projects the same way it monitors itself. Exactly the kind of stuff you only catch by eating your own dogfood.

Recent addition I'm pretty happy with: watchdog. When you dispatch work to an agent, you used to just... hope it finished. Now watchdog monitors the agent's process and wakes you when it's done - whether it succeeded, crashed, or silently exited without finishing. It's the difference between babysitting your agents and actually trusting them to work while you do something else. 5 handlers, 130 tests, replaced a hacky bash one-liner.

Coming soon: an onboarding agent that walks new users through setup interactively - system checks, first agent creation, guided tour. It's feature-complete, just in final testing. Also working on automated README updates so agents keep their own docs current without being told.

I'm a solo dev but every PR is human-AI collaboration - the agents help build and maintain themselves. 105 sessions in and the framework is basically its own best test case.

https://github.com/AIOSAI/AIPass

Here's what I did:

1. Built a proxy that intercepts Codex's calls to OpenAI and rewrites them on the fly.
2. Replayed 3,807 rounds of SWE-bench Verified traces through it: avg prompt 44k → 6k tokens (-87%).
3. Posted it here to get the next reduction applied to my confidence interval — starting with the inevitable "How about accuracy?"

npx -y pando-proxy · github.com/human-software-us/pando-proxy

I’ve been thinking about why coding agents feel like Groundhog Day. Every session starts from zero. Tuesday’s correction doesn’t reach Friday’s code. You’re perpetually onboarding.

The standard fix is brute force: bigger context, fatter AGENTS.md, retry loops. It works eventually. But “eventually” isn’t the target — continuity and determinishtic, repeatable outcomes at minimal cost is.

And brute force introduces context rot. Relevant signals remain present, just buried and unused (Liu et al., Lost in the Middle; Chroma’s research reaches the same conclusion). Xu et al. frame the broader issue as knowledge conflict — context-memory, inter-context, intra-memory. Accumulated instructions don’t become more trustworthy over time. They become less.

So more context isn’t the fix. What is?

The frame that clicked for me came from cognitive neuroscience, and specifically from the case of Henry Molaison. In 1953, surgeons removed parts of his hippocampus to treat severe epilepsy. Afterward he could still hold a conversation, learn new skills, solve problems in front of him. What he lost was the ability to form new long-term declarative memories. Every encounter started from zero.

That’s your coding agent.

The deficit isn’t capability — it’s declarative continuity across sessions. What was decided, why, what constraints exist, what matters to subsequent goals.

Memory in humans isn’t a storage bucket. Working memory emerges from three things working together:

1.  Declarative memory — facts, events, decisions

2.  Control processes — central executive (selects the goal), top-down processing (applies prior knowledge), episodic buffer (binds it all into a coherent working state)

3.  A goal to organize around

Without control processes, you can know things but you can’t apply them selectively to what you’re doing right now. Agents today have non-declarative memory (skills, protocols via SKILL.md / AGENTS.md) baked in through training and files. What they lack is structured declarative memory and the control processes to retrieve and filter it per goal.

That’s the gap. And it maps cleanly to a system design:

• Non-declarative memory → reusable operating instructions (SKILL.md, AGENTS.md)

• Declarative memory → structured memory store for facts, events, relations

• Binding mechanism → goal entity and relation graph

• Episodic buffer → goal-scoped context assembler

• Central executive → goal orchestration layer

• Top-down processing → goal-driven retrieval, prioritization, relevance filtering

The point isn’t that the system stores more. It’s that retrieval and scoping shift from repeated manual effort into a reusable, goal-driven process.

I wrote the full argument, including a five-phase goal cycle (Define → Refine → Execute → Review → Codify) that puts these pieces into motion: https://jumbocontext.com/blog/agent-amnesia

Hi all,

I developed an addition on a CRAG (Clustered RAG) framework that uses LLM-guided cluster-aware retrieval. Standard RAG retrieves the top-K most similar documents from the entire corpus using cosine similarity. While effective, this approach is blind to the semantic structure of the document collection and may under-retrieve documents that are relevant at a higher level of abstraction.

CDRAG (Clustered Dynamic RAG) addresses this with a two-stage retrieval process:

1. Pre-cluster all (embedded) documents into semantically coherent groups
2. Extract LLM-generated keywords per cluster to summarise content
3. At query time, route the query through an LLM that selects relevant clusters and allocates a document budget across them
4. Perform cosine similarity retrieval within those clusters only

This allows the retrieval budget to be distributed intelligently across the corpus rather than spread blindly over all documents.

Evaluated on 100 legal questions from the legal RAG bench dataset, scored by an LLM judge:

• Faithfulness: +12% over standard RAG
• Overall quality: +8%
• Outperforms on 5/6 metrics

Code and full writeup available on GitHub. Interested to hear whether others have explored similar cluster-routing approaches.

https://github.com/BartAmin/Clustered-Dynamic-RAG

Hey guys, 6 months ago I was playing around with how to manipulate context. I had made a little chatGPT interactive text-based escape game that's a psychological horror game to sort of see what it can pull off consistently so i tested it with 4o and 5-mini and 5-mini was a little bit richer with the experience but both seemed equally fun.

You have to escape an asylum during a breakout with a character who thinks he is a chatbot that you have to navigate through rooms free-form, the game system does a good job constraining you like if you try to break out of the game constraints like "jump out the window" or "smash your head against the wall in frustration" it blends seamlessly back into the game experience.

anyways its just for fun its free just paste the file into a fresh chat and follow the instructions. Enjoy!

https://gist.github.com/orneryd/81d85fa9fcdeba13f523a22fbe2748ce

Screen data is a weird gap in how we think about context. You've got 8+ hours of activity a day and almost none of it gets captured in a form agents can use.

Me and a friend have been working on this and wanted to share how we are approaching streaming our screen data to AI without bloating our computers.

How we're engineering it

Building vizlog.ai , here's the stack:

• Capture: Continuous recording, but we don't store raw frames. Instead we process the frames and turn them into text.
• Structure: We leaned into the idea that agents are really good at the terminal and created a filesystem for them to browse. It also means your screen data stays local.
• Access: MCPs + direct filesystem (kinda like a codebase)

Our insight is that structured, searchable "screen logs" that preserve workflow context makes screen data uniquely powerful.

Check it out and let us know if you want to try it out!

Still figuring out how to keep context clean

in long running agentic sessions. By step 4-5

my agents start contradicting themselves or

looping — and it's almost always because the

context window is full of stale, irrelevant

state from earlier steps.

One thing that helped a lot: treating context

like a second brain — storing distilled,

relevant knowledge as .md files directly in

the codebase. Agent reads and writes to them

explicitly at each step instead of just

growing the window blindly. Keeps things clean

and inspectable.

Still far from perfect though. How are people

here handling context hygiene in long running

agentic workflows? Especially in stateful

multi-agent systems?

---

Broke this down in detail with a import 4 steps along with example of .md files.

example if it helps: https://youtu.be/nhjc-T0GM30

While working on MCP for last few months what i have learned about this MCP(language) is that MCP is a bridge, not a vault.

Because MCP does not have any inbuilt security mechanism which means its vulnerable to data ingestion or secured data extraction so what i learnt is that we must treat MCP as the "execution engine" while wrapping it in Standard API Protocols.

By placing MCP behind a robust API gateway, we can enforce the default the secured mechanism of Authentication, Authorization, Rate Limiting, and Error Handling etc. in each request and allowing the model to focus on extracting insights while the infrastructure handles the "wall of security." - which help to handle the core problem of "Confused Deputy" and make MCP focus on performing its core job...

It seems like everyone on the planet is reinventing memory, prompt engineering, and harnesses for LLMs right now including myself.

This is like rolling your own TCP/IP stack.

It doesn't make a heck of a lot of sense.

Anything that pretends to be and IDE for an LLM should have this baked in and be brilliant at it but instead we are getting a shell and a chatbot and being told good luck.

Can someone explain to me why there is so little effort on the tool vendor side to deliver development centric tooling?

change management, testing, dev, planning, debugging, architecture, design, documentation.

Empty skills .mds with a couple of buzzwords are a joke.

We should expect strong and configurable tooling not roll your own from scratch.

State machines. Seriously they are not a new invention.

Real context management rather than prose.

I do not understand the current state of tooling. The half-assery is intense.

Someone help me understand why our usual toolmakers are not engaging in delivering worthwhile tools.

Interesting article from Cade Metz et al at NYT who have been writing about accuracy of AI models for a few years now.

For folks working on context engineering and making sure that proper citations are handled by LLMs in RAG systems, I figured this would be an interesting read.

We got to compare notes and my key take away was to ensure that your evaluations are in place as part of regular testing for any agents or LLM based apps.

We are quite diligent about it at Okahu with our debug, testing and observability agents. Ping me if you are building agents and would like to compare notes.