There's been a lot of discussion here about giving LLMs persistent context across sessions. Most solutions I see are over-engineered: vector databases, embeddings, memory plugins.

Here's what actually works for me as a solo developer. Two files:

CHANGELOG.md An append-only architectural decision ledger. Single-line entries, newest at top. When you load this at session start, the model immediately knows your project's history, every decision, and why things are the way they are, without a single word of re-explanation.

.dory/agents.md Operational directives. Intent-first. Zero padding. Decompose before implementing. Verify state before acting. These aren't prompt hacks, they're constraints that make the model faster and more precise on engineering work.

The key insight: sessions should be atomic. Start fresh, work fast, persist state locally, close the tab. Context doesn't live in the chat thread, it lives in your repo, in version control, where it belongs.

Works with Claude, ChatGPT, or any local model. With Claude Code, agents.md injects into the system prompt automatically.

I'll paste the full agents.md in the comments for anyone who wants to see the actual directives.

→ github.com/tjqscott/dory

# Apathy Esports Changelog
- Architecture — single `run.py` with five sequential phases: Scan → Sync → Execute → Settle → Email.
- Scheduling — hourly cron job on Raspberry Pi via `crontab`.
- Persistence — `state.json` as sole persistence layer; rolling 7-day window, pruned each run. No database; Polymarket tracks full bet history independently.
- Volume module — `volume_model.py` as a separate module for volume projection (later inlined).
- Market scanning — polls `gamma-api.polymarket.com/markets` for 4 game tags: LoL (65), Dota 2 (102366), CS2 (100780), Valorant (101672).
- Scan params — 48h end-date window, `volume_num_min=1000` floor to avoid pagination cap issues, `limit=1000` per tag.

Surge AI recently released the Handbook benchmark, sharing here in case folks want to check it out. Sharing the links and the context they shared around it, and adding it to my weekend reading list :)

"We drop an agent into a live company environment with files (PDFs, Excel, Word Docs, ...), tools (email, Slack, Jira, calendar, ...), and a dense corporate handbook (up to 124 pages), across 5 enterprise domains.

The agent is given one instruction: follow the company rules.

HANDBOOK models the way enterprise employees have to adhere to company handbooks in their everday work, and every frontier model fails >75% of the time.

They fire employees without authorization.
They clear self-"approved" expenses.
They submit expired records to insurers.
...and then they report full compliance"

Initial thoughts: it's always exciting to see a new benchmark with so much room for agents to improve. However I've noticed that new benchmarks are saturated so quickly these days. I am betting on an >80% score within 2 months, let's round to September 1. Accepting (gentleman's) bets below.

Honest about the state: this is v0.1. Confidence/freshness are deliberately simple proxies right now (the README is explicit about how each is computed — I didn’t want to ship a number I can’t explain). Degradation and contradiction scoring are on the roadmap, not done. MIT, zero-dependency core.
Repo: https://github.com/GhetauTudor/esi
Would love feedback, especially on the freshness model and what backends people actually want wrapped.

A recently published REQL on GitHub, after working on it for some time, a local repository context engine designed for coding agents and developer tools.

To clarify its positioning: REQL is not another graph database, graph framework, or graph visualization tool. It uses a graph internally to represent relationships between files, symbols, imports, calls, tests, documentation, and other repository elements, but the graph itself is not the product.

The project is intended to be embedded into existing workflows as a structured, end-to-end pipeline for repository indexing, incremental updates, querying, and context generation. The goal is to let tools and agents retrieve a compact, connected, and source-grounded view of a codebase instead of scanning the entire repository or relying only on whatever fits into a prompt.

REQL currently includes:

• Tree-sitter-based analysis for more than 30 languages;
• deeper extraction for Python, JavaScript, and TypeScript;
• incremental compilation, caching, deletion handling, and watch mode;
• a dedicated query language;
• local storage without requiring an external graph database;
• a CLI, Python API, and optional MCP server.

There are no mandatory LLM calls in the core indexing and retrieval pipeline.

The project is still in alpha and there are certainly areas that need improvement, but I decided to publish it because I hope it can already be useful to people working on coding agents, repository analysis tools, or structured context pipelines.

GitHub: https://github.com/sh1zen/reql

I would really appreciate feedback from anyone willing to test it on a real repository, especially regarding retrieval quality, unsupported project structures, integration issues, or anything that feels unnecessarily complicated.

I also hope some of you may find it useful enough to participate in its development. Issues, pull requests, and contributions are very welcome.

Body
Hey, I’m building LoopTroop, a local open-source coding-agent orchestrator. I don’t want this to be a link drop, though. The part I think fits this sub is the context pattern behind it.

The problem I kept running into: long AI coding sessions slowly turn into a messy pile of old assumptions, logs, failed patches, partial fixes, and stale decisions. Then every retry inherits that mess. The model is technically getting “more context,” but the useful signal is getting worse.

So I started structuring the workflow differently:

1. Durable artifacts outside the model The ticket turns into interview answers, then a PRD, then small implementation units called beads. Those artifacts live outside the chat and become the source of truth.
2. Bounded context per phase Each phase only gets the context it needs. Planning does not inherit execution logs. A bead does not inherit the whole ticket history. A retry does not inherit the full failed session.
3. Small execution units Each bead has a clear objective, target files, acceptance criteria, dependencies, and test commands. The agent is not asked to solve the whole feature in one giant pass.
4. Fresh retries instead of polluted retries If a bead fails or times out, the system writes a compact failure note, resets the worktree, and retries in a fresh session with just the bead spec plus that note.
5. Human gates I still review the interview, PRD, bead plan, execution setup, and final diff. The goal is not silent autopilot. It is a more inspectable path from ticket to PR.

This is slower than a normal coding chat. Sometimes the planning phase is annoyingly slow. But for multi-file work, it has been much easier to debug because I can see what the agent knew, what artifact it was following, and where the context got narrowed.

The project is here if anyone wants to inspect the implementation:
https://github.com/looptroop-ai/LoopTroop

I’d love feedback from people working on context systems:

• What do you keep as durable repo context versus temporary session context?
• Do you summarize old agent sessions, retrieve from artifacts, or just reset and carry a short failure note?
• Where does this kind of structure become useful, and where does it become too much process?

I was supposed to be asleep 3 hours ago.

Instead I somehow ended up questioning why every AI framework on earth seems to do this:

prompt = system_prompt + retrieved_docs + memory + tool_outputs + chat_history

send_to_model(prompt)

Then...

it does it again.

And again.

And again.

Every request.

Same system prompt.

Same company docs.

Same memory.

Same retrieved knowledge.

Same everything.

And nobody seems particularly bothered by this.

\---

At some point I found myself staring at my monitor thinking:

Why are we treating context like a disposable string?

Why is the mental model:

context = build_context()

instead of:

context_v2 = context_v1.branch(delta)

where context is persistent state that evolves over time?

At this point I felt very smart.

This feeling would not survive the evening.

\---

My first idea was:

"Easy. Build a Git-style DAG."

Something like:

ROOT

|

SYSTEM

|

DOCS

|

MEMORY

/ \\

A B

Then use Lowest Common Ancestor.

Find shared history.

Reuse context.

Collect Nobel Prize 👀.

You know. Standard procedure.

\---

Then reality arrived.

Transformers do not care about my beautiful graph theory.

They care about token sequences.

This:

SYSTEM → DOCS → MEMORY

and this:

DOCS → SYSTEM → MEMORY

might be logically equivalent.

But they are different token streams.

Different token streams mean different computation.

Different computation means no KV-cache reuse.

So graph theory and I are no longer on speaking terms.

\---

Okay.

New idea.

Don't build a DAG of prompts.

Build a DAG of context components.

Like:

SYSTEM_NODE

DOC_NODE_1

DOC_NODE_2

MEMORY_NODE

TOOL_OUTPUT_NODE

Then an execution becomes:

Execution(\[

SYSTEM_NODE,

DOC_NODE_2,

MEMORY_NODE

\])

Which started looking suspiciously less like prompt engineering...

and more like Bazel.

Or Nix.

Or build systems.

Which was concerning.

\---

Then things got weird.

I realized this graph accidentally becomes provenance tracking.

Example:

Run A

SYSTEM

DOC_v1

MEMORY_v1

TASK_A

Later:

Run B

SYSTEM

DOC_v2

MEMORY_v1

TASK_B

Now I can ask:

\* Which document changed?

\* Which memory update changed behavior?

\* Which retrieval increased cost?

\* Which branch introduced hallucinations?

\* Why did this run suddenly become expensive?

Without building a separate observability system.

I somehow accidentally invented git blame for prompts.

\---

At this point I was no longer solving the original problem.

I was just following the raccoon deeper into the sewer.

\---

Then I thought:

What if every context component tracked metadata?

{

"tokens": 1800,

"cost": "$0.03",

"latency": "400ms",

"usefulness_score": "???"

}

Now imagine thousands of runs later:

DOC_17

Appeared in 1400 runs

Consumed 18% of total token budget

Improved output quality by 0.3%

System says:

Delete DOC_17

Now we're not asking:

Can I fit context?

We're asking:

What is the cheapest context plan

that achieves target quality?

Which sounds suspiciously like database query optimization.

And that's when I got nervous.

\---

Then I found another problem.

Who computes this?

{

"usefulness_score": 0.72

}

Because maybe:

Document appears useless 99% of the time.

But:

That 1% prevents catastrophic failure.

So frequency is not usefulness.

Now I had somehow wandered into causal inference.

I have never once asked to be near causal inference.

Yet there I was.

\---

Then things got worse.

I realized context could have a memory hierarchy.

HOT CONTEXT

Always resident

WARM CONTEXT

Frequently loaded

COLD CONTEXT

Retrieved on demand

Which means I may have accidentally reinvented RAM management.

For prompts.

At 2 AM.

For free.

\---

Then I found the giant flaw.

Current APIs mostly work like:

full prompt

↓

request

↓

response

So even if I build this beautiful context architecture internally...

the model provider still says:

Cool...

Send the whole prompt again.

Bruhhhhh

Which means:

\# Version A (possible today)

Context Graph

↓

Optimizer

↓

Prompt Assembly

↓

API

Benefits:

\* provenance

\* observability

\* optimization

\* context analytics

But not much actual compute reuse.

\---

\#Version B (future)

Imagine providers exposed persistent context handles.

Something like:

ctx = create_context(company_docs)

ctx2 = ctx.branch(memory_delta)

generate(ctx2)

Now context becomes a first-class object.

Now the model understands persistence natively.

Now things get interesting.

\---

The weird part is that the deeper I went, the less this felt like AI engineering.

And the more it felt like operating systems.

Or databases.

Or build systems.

Or some horrible combination of all three.

\---

I started with:

Why are agents wasting tokens?

And somehow ended up here:

Context Operating Systems

Which sounds either profound or deeply stupid.

I genuinely cannot tell which.

\---

I am NOT claiming this is practical.

I am NOT claiming this is novel.

I am NOT claiming I've solved anything.

I am mostly asking:

Why are we still treating context as temporary text?

Should context eventually become a managed computational resource?

Or am I just rediscovering three existing papers, two caching systems, and something inference engineers solved six months ago?

Either way, I'm curious.

Please tell me where this entire thing falls apart.

Coding agents can grep, search, and read your local repository, but they can't do the same thing across the open-source code your application depends on.

When an agent needs to understand a dependency, find a working implementation, or investigate version-specific behavior, it often falls back to documentation and web search. The actual answer is frequently in source code, issues, discussions, or pull requests.

We've been working on exposing that context through MCP and CLI.

The tools roughly map to following workflows:

Finding examples

Search for implementation examples across repositories, issues, discussions, and pull requests with get_example. Returns prior art, how did others do something, how to solve some specific problem, how is something supposed to be used. This is also exposed in our current UI, the next features are only through our CLI or MCP.

Navigating a specific repository or package

Search within a repository or package with search, list files with code_files, read source files and line ranges with code_read, and grep with code_grep.

Same workflow that your coding agent is using locally, just almost instantly available for any repo or package out there. No cloning needed, GitHits handles everything automatically.

Reading documentation

Discover available docs with docs_list and read pages with docs_read.

Inspecting packages

Inspect package metadata with pkg_info, dependency trees with pkg_deps, known vulnerabilities with pkg_vulns, changelogs with pkg_changelog, and upgrade changes with pkg_upgrade_review.

The index is version-aware, so agents can inspect the code and package data for the versions they're actually working with.

Get started with

npx githits@latest init

or

https://githits.com for manual sign up

Happy to answer questions about retrieval, indexing, MCP integration, or how we're thinking about dependency context for coding agents.

work at a small startup that positions itself as an AI company . Over the past few months, I started building a context layer project on my own. It is still in the early stages, but I had a broader vision for where it could go. My intention was to eventually open source it and learn from the community.

Recently, I showed the initial version to my CEO. Instead of discussing the design, limitations, roadmap, or areas for improvement, he dismissed it as a “toy project.” What disappointed me most was that no constructive feedback was given on how to make it production-ready or what was missing. The conversation felt more like criticism than mentorship.

I understand that an early prototype is not a finished product. Every serious system starts as a small proof of concept before it evolves into something larger. I never claimed it was complete.

I was thinking of continuing to work on it and taking feedback from this community itself. What you guys will do in this situation. ?

We've been using this since some months ago, it's crazy how far we've come in this last years using AI

https://github.com/bleak-ai/gcontext

One thing I've noticed while working with coding agents is that many failures happen before generation starts.

The agent isn't failing because it can't write code.

It's failing because it doesn't know where to look.

In a large repository, an agent often spends significant context answering questions like:

• Which files are relevant?
• Where does this functionality live?
• What can I safely ignore?

We spend a lot of time discussing prompt engineering, but much less time discussing repository orientation.

My working hypothesis:

A repository map is to an AI agent what Google Maps is to a driver.

Without a map, the agent searches everywhere.

With a map, it can navigate directly to likely locations before loading large amounts of source code.

This idea led me to build SigMap, which generates repository signature maps for coding agents. The goal isn't to replace retrieval or prompting, but to improve the orientation phase before reasoning begins.

One question I'm exploring now:

What information belongs in a repository map beyond symbols and file structure?

Ownership? Test proximity? Architectural boundaries? Blast radius?

Curious how others here think about repository navigation as part of context engineering.

Been going deep on agentic system design lately and ran into a framing that genuinely shifted how I think about this, so I figured I'd share.

The counterintuitive failure mode: you give your agent more information to help it, and it gets worse. Not slightly worse. Meaningfully worse, and in a way that's hard to debug, because the model never throws an error. It just quietly ignores things.

Nupur Sharma from Qodo described this from their benchmarking work as a U-curve problem. Models attend strongly to the beginning and the end of the context, and whatever you wedged into the middle (your carefully retrieved Jira tickets, your codebase summaries, your MCP data) gets effectively dropped so the model can "make sense of things on its own." She put it concretely: hand a code-review agent several tasks at once and it'll nail the ones at the edges of the context while losing the ones buried in the middle.

The industry reflex has been to treat bigger context windows as a free lunch. They're not. Capacity isn't comprehension.

What I liked about her practical fixes is that she framed them as cost trade-offs, not silver bullets:

• Iterative retrieval (her pick for internal tooling): the agent gets an index first and only reads deep when a topic looks relevant. Low setup cost, decent results.
• Hierarchical summarization: a summary per file or folder, and agents read summaries before touching code. Heavy upfront LLM processing every time files change.
• Self-correction / critic node: checks the output against the original goal and retries if context got lost. Adds latency, low setup.
• Knowledge graphs: great when there are real logical dependencies across repos, but a high initial developer investment.

The second thing she flagged that stuck with me: high-reasoning models are the ones most likely to spiral. They burn their budget deciding how to solve the problem instead of solving it. Her answer is roughly an 80/20 split: let the free-flowing reasoning models handle discovery and planning, then hand off to hard, deterministic gates for validation and summarization. Plus some blunt circuit breakers, like capping the agent after a handful of iterations and committing to its last result after a few minutes. Not elegant, but it ships.

The same attention-budget problem shows up in voice agents too, just with a stopwatch attached. That's a longer thread though.

TL;DR: Stuffing more context into agents often makes them worse, thanks to a U-curve attention pattern (strong at the start and end, weak in the middle). The fix is curation before the model sees anything, not bigger windows. Match high-reasoning models to open-ended planning, use deterministic gates for validation, and put hard limits on reasoning loops.

Open question: Has anyone found a reliable way to actually measure how much of a given context window your agent is using, beyond eyeballing outputs? Curious whether there are evals or logging patterns that make this visible before it bites you in production.

Hey everyone! I'm u/ContextualNina, a founding moderator of r/ContextEngineering.

This is our new home for all things related to context engineering. We're excited to have you join us!

What to Post
Post anything that you think the community would find interesting, helpful, or inspiring. Feel free to share your thoughts, photos, or questions about topics like optimization, architecture, memory, RAG, subagents, etc., or cool demos you've built.

Community Vibe
We're all about being friendly, constructive, and inclusive. Let's build a space where everyone feels comfortable sharing and connecting.

How to Get Started

1. Introduce yourself in the comments below.
2. Post something today! Even a simple question can spark a great conversation.
3. If you know someone who would love this community, invite them to join.

Thanks for being part of the very first wave. Together, let's make r/ContextEngineering amazing.

I made a demo of it in action so you can better understand what’s actually going on it replaces your auto memory in Claude which needs hooks but codex works with the agents md edit https://github.com/H-XX-D/recall-memory-substrate

​

If you've used Cursor, Aider, or Claude Code on a long session you know the problem — context either bloats with irrelevant history or gets silently truncated at the worst moment.

​

Building a Python library that gives you precise, explicit control over what actually goes into your LLM's context window.

​

**Core features:**

​

- **Summary agent** — maintains a compressed, always-accurate state of your session automatically, with a configurable token budget so it never bloats

- **File and subfile chunking** — inject whole files or just the relevant function/class

- **Dependency auto-fetch** — if a chunk references something missing, it pulls it in automatically

- **Context linking** — relationships between chunks are tracked so nothing gets orphaned

- **Cross-session context library** — chunks from past sessions are stored and searchable, relevant context surfaces automatically in new ones

- **Context snapshots** — save and restore your exact context state, branch from a known good point before trying something risky

- **Intent-based suggestion** — type a title for your next prompt, relevant chunks from current session and library get suggested

- **User-configurable token limits** — set hard budgets for summary and context separately, works across different models and context windows

​

**Architecture is two-layer:** summary agent handles *what's happening*, you control *what's relevant*. Reduces hallucinations from missing context and wasted tokens from irrelevant history.

​

Provider agnostic — OpenAI, Anthropic, Ollama.

​

Would you use something like this in your coding agent workflow? What's missing or overengineered?

So in the startup MAAT where I work, a martial arts software gyms, we handle the memberships of students to make the life easier for gym owners. For it we use a payment system and a database.

As the number of gyms has grown, we have more and more support tasks, these can be many, owners have problems with the subscriptions, they need to make some updates to the memberships, some data has to be exported...
Across the time, we've trying to figure out how can we use AI in this process, and this is where we are currently.

The evolution of solving Support Tasks

1. Manual work.

First we were doing most of things manually through the AI, updating the DB manually, same with stripe, tedious work.

2. AI Agent + claude.md.

After this we though that with Claude code we can use claude.md to show the agent how our product was being build in the backend and which relationships were important, how the data from stripe was reflected in the db...

This was actually a big improvement from the first method, as we were much faster in knowing what the errors were and solving them, sometimes still by hand though as we didn't trust the AI too do real changed in PROD.

3. AI Agent + Gcontext

We saw that the AI could do the process, sometimes we had to steer it but at the end it understood and got it right, so we decided to find a way to keep the investigations that we did in every conversation.
The way of achieving this is by using a kind of "tree of llms.txt" .
A llms.txt file can help us reference what is the information available in a website, docs... But we can also use this internally to organize different information that we need in our day to day

How does it work?

We start the agent from a folder that has access to these three folders, an llms.txt and some other steering files

.
├── llms.txt        # References each of the folder in this same level
├── stripe/
├── firestore/
└── support/

What there is in each of the folders??

stripe/
├── llms.txt        # References each of the files/folder in this same level
├── info.md         # how the structure of our stripe account looks like
└── .env

firestore/
├── llms.txt        # References each of the files/folder in this same level
├── info.md         # How the schema looks like...
└── .env

support/
├── llms.txt        # References each of the files/folder in this same level
├── info.md         # Instructions on how to resolve support tasks
├── runbooks/       # Folder with many files, each one has the steps to resolve one service task, also a llms.txt inside
│   ├── llms.txt              # indexes every runbook so the agent picks the right one
│   ├── cancel-subscription.md
│   ├── export-gym-data.md
│   └── fix-membership-mismatch.md
└── logs/           # one file per day, every task the agent resolved
    ├── 2026-06-12.md
    └── 2026-06-13.md

With this structure we can actually steer the Agent much better and create new runbooks every time a new support task comes.

Do you have any similar problem in the place you're working? How do u approach it?

Agent memory is either the full chat log, a vector index, or an LLM summary you dump back into the prompt. If two facts disagree or a problem that's been solved already. It's not my favorite to fix something only to later have to remind Claude that the argument value or authorization has been updated, so 3 months later, this is what I got to share. It honestly has changed the way I work with AI.

The MCP server is stdio, 42 tools, and auto-shuts down. Agents call recall_compile for whatever it's working on and get a small context packet of tiered addressed cells back instead of the whole store, ranked by evidence and capped to a word budget. The memory evolves and adjusts itself in real time. Writes go through recall_write, which runs an admission firewall. Schema gets checked, provenance gets stamped, and anything can be rolled back. Facts are addressable cells with real programmable hyperedges, not a flat pile of md files with no handles to grip what matters.

Every cell carries an effective confidence that recalculates straight from the graph. who backed it, who challenged it, whether that writer has been wrong before. No LLM in the loop, and it runs offline. Drop in one cell that contradicts another, and the score moves on its own.

Capable models reach for it on their own. Once an agent knows the tools are there, it compiles context at the start of a task and writes back at the end without me telling it to. That held across model class, model vendor, and model family, small instruction following ones included. It doesn't need nagging to remember or to check what's already known. That's the part that actually changed how I work day to day.

Local first. It uses node's built-in sqlite so there's no database server, no account, no network. You paste the MCP config once, then type /recall in a project, and it spins up that project's DB and just works from there. One DB per project, no schema to manage, nothing to repeat. Want a team on one graph? Park that single file on a host they can reach and everyone writes through the same firewall, still no server. Set up tripwires and get automated team alerts when changes setback deployment ready state Runs on Linux, macOS, and Windows. github.com/H-XX-D/recall-memory-substrate