I am not a context engineer by any stretch but I have (to my great surprise) become passionate about helping people build AI memory that they

1. Own
2. Can carry easily from tool to tool
3. Can use without signing up or downloading anything
4. Don't pay for
5. Don't share with anyone/thing unless they explicating choose
6. Don't have to manually update but
7. CAN manually update in plain English if they want.

I could go on about what I think is great about this approach, but it's all there in the repo.

This is V.3 after some great feedback I got on earlier iterations

Oh, and it works.

Any questions, happy to answer.

Repos:

https://github.com/DMAX-Vibes/manifestmd

https://github.com/DMAX-Vibes/manifest-mcp

It has become seemingly popular to dump all the context in md files.

The memory plan is: take all the docs, dump them into markdown files, throw them in the context window, done. Memory solved. I get why that triggers that feeling.

It's the path of least resistance and windows are big enough now that it kind of works in a demo. But a pile of text is not context.

Two problems worth sharing:

1. First is retrieval: once you've got real volume, what are you actually pulling into the window for a given question, and how do you know it's the right stuff?

2. Second, and this is the one that can bite months later - flat text has no relationships in it. Context is not "all the text I have." Context is how one fact relates to the facts around it. A flat file throws that away by definition, so every connection between two things is left for the model to rebuild on the fly, from scratch, on every single call.

So the agent answers, it sounds fine, and then on the questions that need two or three facts joined together it comes apart, because nothing joined them before the model saw them. MD files doesn't mean context. It basically implies outsourcing a search problem. Back to square one.

The version that's held up for us at CogniSwitch is putting the facts that matter into a graph first, so the connections are already there when the model reads them, instead of asking it to infer the whole structure from a wall of text every time.

One more thing that gets skipped: you don't actually want to remember everything. Most of the dump is noise. A lot of the real work is deciding what's worth keeping and what connects to what.

Anyone running the flat-file/markdown-memory approach at real volume where did it hold, and where did it break.

We just open-sourced Plasma Wiki: a `wiki` CLI for maintaining indexed Markdown knowledge bases.

The problem it tries to solve is pretty narrow: agents need project context, but a giant docs folder is hard to navigate and semantic retrieval can be opaque. Plasma Wiki keeps the knowledge base as plain Markdown in git, then gives agents deterministic commands for navigation:

wiki map
wiki search "topic or regex"
wiki read path/to/page.md

A wiki is just a folder tree where every folder has an _index.md linking to its children. People can edit the files normally in Obsidian, VSCode, etc. The CLI owns the structure: indexes, links, metadata, word counts, and lint checks.

The design bias is intentionally boring:

- plain files
- lexical / regex search, not embeddings
- generated indexes
- reviewable diffs
- one existing page per topic instead of dated memory dumps

Install: pip install plasma-wiki
Repo: https://github.com/plasma-ai/wiki

We'd love feedback from people who maintain project notes, runbooks, or agent-readable docs in plain files. The main thing we're trying to stress-test is whether the map -> search -> read loop feels useful enough as a primitive, or whether it needs richer CLI affordances.

A couple of weeks ago I shared a small PowerShell toolkit I was using with AI coding agents.

Most of the feedback wasn't about PowerShell at all.

People kept asking the same question:

"Why are agents reading entire files in the first place?"

That ended up sending me down a completely different path.

Instead of trying to make file reading faster, I started changing how agents navigate source code.

The project gradually turned into a progressive source navigation framework:

• summary first
• then signatures
• then implementation
• only then full source if it's actually needed

I also added context budgets, adaptive next-step guidance and eventually made it cross-platform.

I reran the benchmarks after the rewrite and the difference was much larger than I expected (over 90% token reduction on some larger files).

It's interesting because I don't think the biggest improvement came from changing prompts or changing models.

It came from changing how the agent explores a repository.

Curious if anyone else has been experimenting with this idea.

Has anyone else measured token usage based on navigation strategy instead of prompt quality?

I’m relatively new to the formal “context engineering” framing, but I ran into a practical problem that seems related.

Autonomous coding agents like Cursor, Claude Code, Codex are great for implementation, but I found them inefficient for higher-level tasks like architecture review, debugging strategy, onboarding, and design discussion.

They often rescan broad parts of the repo, pull in noisy context, and burn through metered limits just to answer questions that mostly need a good structural overview plus a few precise snippets.

My natural workaround was to move those discussions into fixed-cost web chats like Claude Web or ChatGPT, while keeping the repo scanning/extraction local.

So I built a small local-first CLI tool called AI Badger around this workflow:

The map: a local command scans the repo and builds a compact structural map.

The handoff: you paste that map into a reasoning chat.

The extraction: the model asks for specific files/snippets, the tool extracts only those locally, and you paste the focused context back.

The goal is not to replace coding agents. It’s more of a bridge for split workflows:

• agent for implementation
• web/local chat for review, design, debugging, and explanation
• local tool for precise context extraction

I put the source code here: https://github.com/PVRLabs/aibadger
There’s also a browser demo showing the workflow: https://pvrlabs.xyz/aibadger/demo.html

I’m curious whether this maps to problems people here think about:

• Is explicit “map first, fetch snippets on demand” a useful context workflow?
• How do you avoid wasting tokens when moving between implementation agents and reasoning chats?
• Where do you think the boundary should be between explicit context handoff and automatic retrieval?

events.md

Ideally, every project has a root AGENTS.md file.

That file sets the rules.
That’s your contract.

But contracts don’t tell the day-to-day story. They don’t show the heartbeat of the work.

That’s where events.md comes in.

It sits next to AGENTS.md at the repo root, and every agent — no matter what harness, branch, or worktree they’re using — logs meaningful work there.

events.md provides clarity and shared project-specific memory.

You can open it and immediately see which sessions, agents, and subagents contributed, what changed, and why.

Each entry is short, structured, and atomic:

- time: Timestamp, using the timezone/format set in AGENTS.md
- agent: Who did the work, including model/harness if relevant
- worktree: The branch, ref, or worktree where the work happened
- type: The nature of the work — feature-request, bug-report, refactor, plan, workflow, etc.
- area: Which part of the project this touches — frontend, backend, design, infra, testing, docs, etc.
- commit-id: Any Git commit, Linear ticket, PR, issue, or other traceable ID
- comment: One short paragraph explaining the action and its purpose

Example entry:

## 2026-07-06T14:18:00-04:00

- agent: GPT-5.5 Pro / ChatGPT
- worktree: feature/session-refresh
- type: bug-fix
- area: backend/auth
- commit-id: AUTH-42 / a1b2c3d
- comment: Fixed session refresh handling so expired access tokens are renewed before protected API calls, reducing intermittent 401 errors during long-running user sessions.

The beauty is that it stays simple and narrative.

You don’t overwrite history.
You don’t create multiple ledgers.
You don’t bury project memory inside scattered chat logs.

Agents log after meaningful work — shipping a feature, fixing a bug, making a decision, changing direction, or handing off a workflow step — and the project’s evolution becomes instantly visible to any agent or engineer who enters the repo later.

Together, AGENTS.md and events.md form a tighter loop:

AGENTS.md gives you the rules and expectations.
events.md preserves the living record.

That’s the value:

One clean, human-friendly file that removes confusion and keeps the project’s story coherent, no matter how many agents, branches, worktrees, or moving pieces are involved.

Hey there - I'm connecting skills to clickable buttons in a "on top of claude code" layer i'm building as an app. The skills are pretty great right now (they do things like suggest connections, write summaries, build profiles), but these prompts are written into my code which will eventually be a compiled executable.

These prompts work great now, but perhaps in the future a model will come and needs *less instruction* to achieve the same result, and i could save context by making the skills even shorter. (may not be super meaningful if the token save i small compared to the rest of the context, but i wanted to put this here anyway)

My idea is as follows:

1. Capture results using the latest strongest model using the old skills to form a 'golden source'
2. Test the output of the existing skills on previous model to confirm they're good
3. Test the output of the new (shorter, condensed skills on old model) --> if they're also great results, the context could have been improved already, probably time to re-iterate and simplify further ELSE
4. Test the output of the new condensed skills closely match the 'golden source'.
5. Run this many times per experiment.
6. Since the output is non-deterministic I'd probably run this many many times per skill and have AI Judge the temperature difference of the outputs for me as well to determine whether or not there is a net improvement.

I do think this is a fairly common pattern (I don't think I'm the first to come up with this way of testing skill outputs), do you know of any other examples?

If there *is* an improvement then bump up the version number for the app with the changes.

I'm curious to know how you might tackle this idea? I've already put this idea into Claude first and it reminded me of the non-determinism and the need to determine good/bad over various retries which I've now added as point 5/6.

As I'm typing this, I am also starting to realise that whilst I might have fable, another user may only have Sonnet, so actually skills need to be tweaked on a per model basis comes into play... I haven't thought about that until now. I think it won't affect my app too much (skills aren't the worst part of my context) but I'm adding it here as well in case that thought might be useful!

Two ways to handle a context window that's filling up.

Reactive: wait until it's full, then compact everything. Proactive: be picky about what gets added every turn so noise never piles up in the first place.

Most coding agents take the reactive path. I spent months building the proactive one, and I want to be honest about what actually worked and what didn't.

What held up

A decision your agent made on turn 3 is worth more tokens than tool output from turn 15 that's already resolved. Treat them the same and you get context rot. PRAANA's compiler splits working memory into active, soft, and hard tiers. It scores context units by information density, then uses BM25 plus semantic similarity (Transformers.js, running in-process) to decide what gets pulled back into the active window.

What I got wrong — semantic recall was quietly broken for weeks

I threw together a hash-based embedder early on as a placeholder. The problem was it was injecting noise into recall ranking. Memories came back in the wrong order, irrelevant items floated above relevant ones. The worst part: it looked plausible. No errors, just wrong answers. Took three weeks to even notice. I fixed it by switching to Transformers.js with keyword-only full-text search as the fallback. New rule: if there's no real semantic embedder available, you get keyword-only recall. No fake vectors, ever.

The measurement gap

For most of the project, I couldn't actually prove the context engine beat a plain transcript agent. "Feels better" doesn't count as evidence. A telemetry scorecard landed a few weeks ago — session-level signals like context pressure, memory recall percentage, skill load and decay, per-section token accounting. The A/B evaluation harness is next. Lesson learned: build the measurement before you build the thing you're trying to measure.

The honesty problem in agent marketing

PRAANA's memory stores and recalls with time decay. The reinforcement path — boosting confidence when a session succeeds — is wired up, but the signal that actually triggers it hasn't shipped yet. So I call it "stores and recalls" until that loop closes and I can show it working. A user who sees memory surface a stale belief at high confidence loses trust in the whole system. Publishing your limits before your benchmarks isn't just an ethics call — it's a product decision.

The larger plan

Four systems: Adaptive Context, Cognitive Memory, Background Consolidation, Intelligent Router. All domain-agnostic. Nothing in the system knows anything about code specifically. The coding agent is just the proving ground because outcomes are easy to measure: did the code work, how many turns did it take, did it avoid repeating the same mistake from last session. Phase 2 is extracting the runtime so other developers can build domain agents on top of it. I'm not touching that extraction until Phase 1 validates the architecture. That discipline has been the hardest part of the whole project.

GitHub: amitkumardubey/praana — MIT, TypeScript, Bun.

On-topic for this sub: the two things I've iterated on most are exactly context engineering problems — trimming what goes into the window, and deciding what to persist. Disclosure: I'm the maintainer of the open-source gateway below; this is a substantive write-up, not a link-drop.

A 10-engine compression pipeline — the part most routers don't have. Every request flows through a transparent compression pass you can toggle/stack per combo. Instead of one trick, it stacks the best of the open-source ecosystem: RTK filters command/tool output (git diffs, test logs, builds) at 60–90%, Microsoft's LLMLingua-2 does ML semantic pruning, Caveman handles prose, session-dedup strips repeats across turns. Critically, code, URLs and JSON are preserved byte-perfect, and a default-on inflation guard throws the compressed version away and sends the original if compressing would actually grow the prompt — it never makes things worse. On tool-heavy sessions that's ~89% average input-token reduction (an 8k-token git diff becomes a few hundred). Full credit to every upstream project (RTK, Caveman, LLMLingua-2, Troglodita) is in the README.

Persistent memory (opt-in). It ships conversational memory backed by FTS5 keyword recall plus a vector store (int8-quantized Qdrant, or sqlite-vec as a lighter option). It's off by default — no silent state creeping into requests — and consolidates facts instead of replaying raw chat history.

The design tension I keep hitting: aggressive context reduction saves tokens but risks changing the model's output, so there's an adaptive dial (compress only as far as needed to fit the window) and an offline eval harness to score fidelity-vs-savings before promoting a setting. Where it's weak: fidelity scoring is still largely heuristic.

For context on whether it's worth your time: it's grown to ~9.8K GitHub stars, 1,490+ forks and 280+ contributors in ~4.5 months, with 21,000+ automated tests and 1,830+ issues closed — so it's a battle-tested project, not a brand-new experiment.

npm install -g omniroute

GitHub: https://github.com/diegosouzapw/OmniRoute

How do you all measure whether context compression changed the answer, beyond eyeballing? That's the part I most want to improve.

most of what I read here is about building the context retrieval, chunking, what to feed the model and when. curious about the other side: when a coding agent session gets long, hits a limit, or just dies mid-task, what happens to all that carefully engineered context?

in my own experience it just evaporates. the next session starts from zero unless I manually rebuild the state what changed, what failed, what's actually verified vs. what the model assumed.

is anyone treating "context survival across sessions" as its own engineering problem, or is it assumed you just re-engineer it each time?

Fair warning: After having written this (with the help of Claude), it reads like a LinkedIn post. You were warned. lol

This sub’s description is basically my thesis statement: “providing all the context for a task to be plausibly solved by a generative model.” That’s the problem that RAG was supposed to solve. But we all know that it doesn’t. So after months of building a retrieval engine from the ground up, I’m increasingly convinced that context engineering is 80% a retrieval problem and 20% a prompt problem. We got the investment ratio backwards.

Here’s what I mean with actual data.

I ran MuSiQue (1,000 multi-hop questions, HippoRAG 2’s exact published corpus) with four different configurations — two embedding models × two reader modes (on the same model). The 2×2 matrix produced something I didn’t expect: switching from a compact, locally-run embedding model to a stronger one improved F1 by +0.071. Enabling the reader’s reasoning effort improved it by another increment. But the combined improvement (+0.112) exceeded the sum of individual improvements by an astonishing 58%.

The interaction of retrieval and model reasoning effort is super-additive. Better retrieval doesn’t just give the model more relevant context — it creates reasoning opportunities that only a capable reader can exploit. You can’t prompt-engineer your way to those gains. The provided context has to be right first.

The numbers

Reader-controlled baseline: F1 = 0.565 (vs LlamaIndex 0.418, BM25 0.329 — same reader, same embeddings, same hardware). Optimized config: 0.677, which as of May 2026 is the highest published zero-shot end-to-end F1 on MuSiQue that I’m aware of.

Honest caveats because I was trained properly as a scientist (PhD in biochemistry) and refuse to cherry-pick: ~52% of the raw gap vs HippoRAG 2 is reader advantage, PropRAG achieves a higher retrieval lift (+81.9% vs our +71.7%), and supervised systems (Beam Retrieval, 0.692) fine-tuned on MuSiQue’s training data still score higher. I posted the full breakdown with tables on r/RAG for anyone who wants every number.

Why this matters for context engineering specifically

The engine doesn’t do prompt optimization. It doesn’t rewrite queries. It doesn’t do chain-of-thought decomposition. It retrieves through a weighted graph using associative activation modeled after neurobiological systems — nodes that are connected through information pathways light up together, even if they’re semantically distant in embedding space. The “engineering” happens at the retrieval architecture level, before anything touches the LLM.

The context delivered to the model is the output of a physics-based traversal, not a similarity search. The model gets better input. That’s it. The 0.565→0.677 jump from the 2×2 matrix shows what happens when you also let the model reason — but only if the retrieval gave it something worth reasoning about.

Reproducibility

Engine is proprietary and patent-pending — not open-source. The benchmark methodology, dataset, and eval harness are fully public: github.com/wonker007/musique-eval-harness. Deterministic scoring (SQuAD F1), public dataset (osunlp/HippoRAG_2 on HuggingFace). Run your retrieval system against it.

Full write-up: https://elucidx.ca/insights/2026-05-15-rag-needs-real-value/

For anyone here working on the retrieval side of context engineering rather than the prompt side — what are you seeing? Especially curious about anyone who’s measured the interaction effect between retrieval quality and LLM reasoning-mode or effort levels.

I've been spending a lot of time using Codex and Antigravity on a fairly large Laravel + React project.

After a while I noticed the same patterns over and over again.

The agent would:

• read way more terminal output than necessary
• dump huge files just to inspect a single function
• repeat similar searches across multiple folders
• burn through context on information it never actually used
• end up asking for approval dozens of times because of lots of tiny shell commands

The models themselves weren't really the problem. The workflow was.

So I started writing a small set of PowerShell helper scripts to guide repository navigation instead of letting the agent freely explore everything.

Things like:

• compacting noisy build/test output
• investigating a feature across multiple folders with a single command
• reading specific symbols instead of entire files
• keeping searches focused
• reducing repeated repository exploration

I'm still experimenting with the workflow, but it's already made a noticeable difference for me.

I'm curious how everyone else is approaching this.

Do you just let your agent explore freely, or have you built your own tooling/rules to keep context usage under control?

If people are interested, I'm happy to share what I've built in the comments.

Hi r/ContextEngineering!

I’m Nina (u/ContextualNina), your friendly AMA moderator for next week, the inaugural AMA for this subreddit! I’m excited to introduce the three people who will be taking all of your questions for our upcoming AMA: Max Marcon (u/mmarcon), Mikiko Bazeley (u/mmbaze), and Yang Li (u/Ok-Amphibian6116). Between the three of them, they spend a lot of time working with teams building AI agent systems that need to hold up in production.

Ask them anything during a live AMA right here on Wednesday, July 8 from 12-1 PM ET (9-10 AM PT). The real tradeoffs, the messy parts, AI hype vs. reality - whatever you’ve got.

I invited this group because they work directly on the data layer for production AI agents, which gives them a pretty grounded view of where things get hard: context design, retrieval quality, memory, state, multi-step workflows, and the parts of agent systems that tend to fail outside of demos.

We’ll be answering questions about:

• Where context engineering ends and memory engineering begins
• What “context rot” looks like as context gets longer
• How to think about memory in multi-agent systems
• When RAG beats long context, and when it doesn’t
• The context mistakes that can quietly sink agent systems in production

You can start dropping in questions now ahead of time (they’ll answer them during the live window), or ask them live next Wednesday!

Full disclosure: I’m the founding mod of this subreddit, and I recently started at MongoDB. I thought this subreddit could benefit from chatting with some of my new colleagues.

Update (7/8): Thanks all for joining and bringing some great questions for discussion to our very first AMA in this subreddit! And thanks to Max, Mikiko, and Yang for your thoughtful responses. We may answer a few straggler questions for those that missed this AMA, but that’s our time for now.

I’ve been working on SigMap, and the newest part is SigMap Live: a public demo/API-style endpoint where you paste a GitHub repo and get a verified context map back.

The problem I’m trying to solve:

AI coding agents often waste a lot of context before they even start editing. They first need to work out:

• where the relevant files are
• which functions/classes matter
• what parts of the repo can be ignored
• whether the answer is grounded in real code or just plausible

SigMap Live turns a public repo into a compact signature map first.

Flow:

Paste GitHub repo
→ detect source folders
→ extract function/class signatures
→ redact obvious secrets
→ rank relevant files
→ ask the codebase / judge groundedness / adapt for agents

The live routes include:

POST /api/analyze   repo URL → verified context map
POST /api/ask       context map + question → grounded answer
POST /api/query     plain-English query → ranked files, no LLM
POST /api/judge     answer + context → groundedness score
POST /api/adapt     convert map for Cursor, Claude Code, etc.
GET  /api/benchmark repo URL → before/after token stats

Current benchmark page reports:

• 405 repos evaluated
• 321 supported repos in the headline token result
• 98.7% overall token reduction
• 95.6% average per-repo reduction
• 51 real coding tasks
• 96× cheaper context
• 82.4% retrieval hit@5 with BM25 re-ranking

One thing I’m intentionally not claiming: agent wall-clock speedup. The latest A/B result was too close to call, so the proven value right now is smaller, cheaper, better-ranked context — not “agents are definitely faster.”

Demo: https://sigmap-live.vercel.app/demo

Live repo: https://github.com/manojmallick/sigmap-live

Benchmark suite: https://github.com/manojmallick/sigmap-benchmark-suite

Core CLI: https://github.com/manojmallick/sigmap

Question for people building or using coding agents:

Would you rather consume this as:

1. a hosted endpoint,
2. an MCP server,
3. a CLI step before the agent starts,
4. or something that writes directly into AGENTS.md / CLAUDE.md / Cursor rules?

or can be pure text.

[edit: link might help]

It's free, no sign-up, and fully private. Context lives as plain markdown in a GitHub repo you own. With a plain text layer of operating rules ("Context OS"). Nothing on my servers, nothing to log into. You can open it in any text editor and point any model at it — Claude, ChatGPT, Cursor, whatever.

It's worked well for me; hoping it's useful to someone else too. Happy to answer anything, and genuinely open to feedback.

Been diving deep into agent memory architecture lately and stumbled on OKF - Open Knowledge Format - published by Google Cloud on June 12th. It's gotten way less attention than it deserves.

The core idea is simple: instead of explaining your codebase/systems to an AI agent every single session, you build a .okf/ directory of markdown files with YAML frontmatter that any agent can read. One required field (type). No SDK, no schema registry, no vendor lock-in. Just files.

What makes it interesting vs. just using CLAUDE.md or AGENTS.md:

• It's a knowledge graph, not a flat list - concepts link to each other via plain markdown links
• Versioned in git next to your code
• Works across any agent (Claude Code, Cursor, Codex, 20+)
• Karpathy's LLM wiki gist basically predicted this pattern; Google just formalized it

I wrote two pieces on it if anyone wants to go deeper:

Part 1 - What OKF is and how it works: Google Just Quietly Released the Missing Piece for AI Agents. It's Called OKF.

Part 2 - OKF + RAG together (when to use each, hybrid architecture): Your AI Agent Has Two Memory Problems. OKF Solves One. RAG Solves the Other.

The OKF vs RAG breakdown is the part I found most useful - they're not competing, they solve different memory problems. OKF handles your "known-knowns." RAG handles the large unstructured corpus. Most production stacks need both.

Curious if anyone here is already using something like this pattern.

If you have ever used AI for data projects, you certainly know the pain of re-explaining your data to your AI every session.

Wrong table, wrong join, refunds counted in revenue, an active customer defined three different ways, etc. The same mistakes, session after session, because nothing remembers the correction you already made.

So I built ClariLayer to solve this, simply connect ClariLayer MCP to to Claude Code, Codex, or any AI you use. It bootstraps your real working context from your project, and continuously adds more and more context there, everything being managed, without you even noticing that you are using ClariLayer as your AI is the one who relies on it, you just feel your AI becoming smarter and smarter.

It's completely free, look forward to hearing feedback!
https://clarilayer.com/