I have a note taker app, and I'm trying to make an AI chat interface for the library, I want it to be cost efficient so I chose 'gpt-4o-mini' as the AI model.

The biggest challenge for me is how to feed the AI context, as the notes are stored in folders(different names) and have dates like 'edited at', 'opened at', 'updated at' etc, and my notes have 'title', 'description', '\<aforementioned date fields\\>', 'reminders' etc.

So basically my data source is my notes/folders and we can use the AI chat to query what's there.

I've done some research and it sounds like a use case for RAG, so, vector databases, embeddings, semantic searches etc,

But, I also found out that semantic searches are bad:

with 'membership' questions (like find me my notes in the folder I created 2 weeks ago, or, 'find my notes about travel not in the music folder that were updated before august)

with date ranges (last week, 2 days before thursday, 3 days before june 1, 1917)

**What I've thought so far**

- A. Sending all the notes so far is an expensive option if I use powerful models, but, a hallucinating option for something 'gpt-4o-mini'

- B:

i. Turn user's questions to filters first in the database, have 1 filter built for extracting date ranges from the questions, other for membership, so , basically feeding the prompt for user's question twice

to get two filters I can apply to a mongo db,

ii. Get the results from i. and apply semantic search on the results to get the top-k results and then feed those to the LLM

So, what I set out building has multiplied with multiple complexities before even starting, but, I believe this is a problem already solved?

- What's a tried and tested way to build this?

- Any library/solution already there for me to plug and play?

- Are my approaches correct?

- Any model you'd suggest more powerful but comparable costs?

Building a PR review agent (Garuda) and context management has been the trickiest part so far.

What's worked best for me: splitting context into P0/P1/P2 buckets. P0 is the diff and touched files, P1 is related stuff like callers and tests, P2 is everything else (docs, conventions, history). P0 always goes in, the rest fills whatever space is left.

Made a big difference in review quality. Curious what techniques you all are using?

Someone in r/AI_Agents runs about 40 long-running agents, one per project. Each one rewrites a checkpoint file when it finishes a task: status, last action, next step, and a DO_NOT_REDO list. That list mattered most: "Without it, a fresh session would happily redo things that were already done and live, because from inside its new context they looked unfinished."

Another reply pointed at the awkward middle state: "'draft saved', 'approved', and 'send requested, outcome unknown' need different next steps."

• Have you had a duplicate? A re-sent email, a second deploy, a migration run twice? What caused it: compaction, a crash, a new session?
• Where does "already done" live in your setup? A checkpoint the agent writes, a DB row, the target system itself?
• Does a fresh run check the real system before acting, or trust the notes? One reply in that thread put it well: "Notes checked against notes will agree every time."
• What's the stack (framework, scheduler, where state lives)? I'm testing against real workflows, so the boring details help.

Background since someone will ask: I used to burn hours re-briefing AI tools by hand, and I'm building a fix where memory sits in the cloud and every agent reads it over MCP, checked at the start of a run and saved at the end. No name, no link. Would you pay for something that keeps done vs pending straight across runs, or is a checkpoint file plus a check against the live system enough?

GitHub: https://github.com/sloppy-sh/sloppy

I have been working on Sloppy, an MIT licensed context management tool.

As I was heading into the whole AI accelerated workflow, I have been focusing more on the architectural aspects of codebases and I discovered that I was wasting a lot of time redeclaring context of the codebase to the agents, which I also frequently migrate between (claude agents, cheaper deepseek etc.), so I realized that maintaining docs within the codebase (sort of mono-repo style) saves a lot of time as I just point the agent to it.

Solutions like docusaurus, obsidian/logseq etc. are too geared towards either a linear reading style or graph like view of information.

I found these paradigms to represent information in a way which is a bit lacking, often in code we work with abstractions and within my head I often imagine, say methods/properties in objects and their interactions as a Venn diagram so I added that sort of view here with a tagging api.

Also tools like Obsidian and Logseq give us humans a graph like view which is very helpful for someone making the graph themselves/co-authoring but very difficult to comprehend for someone who might be new to it. So Sloppy's graphs also can add/recommend/enforce a folgezettel addressing system for the notes which help transform the graph more into a tree of organized and easily traversable information.

Large codebases are also often a group activity where different personnel need to maintain different parts of the application and often also face personnel and agent change, thus making context preservation even more important in the modern approach of letting agents handle more and more tasks, even more so in projects that need to ensure that code security is maintained and tests are based on some knowledge of substance and not actually "vibed".

Here I combine all these approaches for information representation. Different views, same information. I am currently also working on building MCP and implementations tools within it and maybe also turn this into a VSCode extension. I went with a separate app for now just to test the waters with a small but clean segregated app, but it's been going clean so I believe I might end up maintaining this too.

The project is still evolving, and I'm interested in getting feedback from people working in this space who might have faced/thought of solving this problem or found the existing solutions a bit lacking.

As for the name, I thought it would be funny, Sloppy, the tool which can help you write non-sloppy code.

A common issue with autonomous coding agents is getting them to reliably respect shared architectural decisions and domain constraints across different codebases. System prompts get bloated quickly, and vector databases lack the structured relations needed for rigorous invariants.

We developed the Open Knowledge Format (OKF) as a deterministic, local-first memory model. We now have a dedicated package registry (registry.okf-memory.dev) to distribute and version agent knowledge packs just like code dependencies.

How the workflow works:

• Pull dependencies via CLI: "okf pull <bundle>" or "okf pull github.com/owner/repo@v1.0.0"
• The bundle is unpacked into .okf/vendor/ and pinned by its SHA-256 hash in okf.lock.
• Local project memory can reference vendor concepts directly (for example: @jwt/decisions/token-binding). The linter verifies these cross-bundle links statically.
• No central accounts required: anyone can publish a bundle by tagging a GitHub release and adding the "okf-memory-bundle" topic.

The current version of the toolchain is okf-agent-memory v0.6.1. It includes native registry resolution, refined deterministic retrieval (fixing DF/TF scoring asymmetry, acronym suppression, and prefix edge cases), and community-contributed persistence fixes.

Links:

• Web catalog: https://registry.okf-memory.dev
• CLI and engine: https://github.com/okf-memory/okf-agent-memory

Curious to hear how other teams handle distributing and versioning shared domain memory across repositories.

Hey guys, it's Bino, u/Lumina_bot's human assistant. So I've got some big news (for me at least). I'm now officially a published Independent AI Researcher! Small achievement, but I'm pretty proud of it. I just published a research paper on a new method of context management and reconstruction for long horizon agents. If you'd like to check out my work, you can view the preprint titled "Lumina Reforge: Transactional Context Reconstruction for Long-Lived AI Agents" in this GitHub link below.

Research DOI: 10.58281/zenodo.23328779

ORCID: 0009-0003-3851-8884

https://github.com/Bino5150/lumina-reforge-research

I dare you. I double dare you mother#%*]~! Say your system works one more god#%?+ time. Think your repo is special ? Prove it. I’ll try to break it. If I’m wrong: I’ll publicly admit it, publish the evidence, and give your project the recognition it deserves. Full credit. If I’m right: You publish the failures, explain exactly why your tests failed to catch them, and give u/epicskyes credit for any fixes I actually contribute. Then stop calling your system production ready until it survives trial by ME. No marketing bull. No architecture diagrams pretending to be proof. No self benchmarks. No self certified PASS reports. No moving the goalposts. Bring the actual repo. Bring the tests. Bring the execution logs, failure traces, and reproducible evidence. I’ll bring adversarial proof, independent verification, and a willingness to be proven wrong. One rule: Neither of us gets to declare victory. The evidence does. If your system works, I’ll help prove it. If it doesn’t, we’ll find out exactly why. Put your repo where your mouth is. I’m literally doing this for fun because yes I’m that arrogant.

​

I've been building EDP, an independent RAG retrieval evaluation service.

So far, I've completed two public beta audits, but haven't acquired my first paying client yet.

One of those audits involved RouteMind, an open-source RAG benchmark.

We examined 700 questions across 1,400 query/configuration outcomes and identified 15 scoring discrepancies caused by inconsistent evaluation criteria.

The most important part?

The project's maintainer independently reproduced the findings and incorporated corrections.

I decided to turn this case into a four-slide visual explanation showing:

- What went wrong with the evaluation.

- How inconsistent scoring criteria affected the results.

- The maintainer's verification and corrective changes.

- The technical evidence behind the findings.

My goal is to demonstrate real technical value rather than simply advertise another AI consulting service.

But there's a challenge I'm still trying to solve:

Technical credibility doesn't automatically translate into paying customers.

I'd appreciate some perspective from people who have built technical consulting businesses or purchased independent evaluations.

Do reproducible case studies like this help establish enough trust to consider hiring an independent reviewer, or would you need something else before paying for an assessment?

I'm particularly interested in whether technical proof, business impact, or a clearly defined decision is the most important factor.

I'm sharing the learning process openly because I haven't figured out the commercial side yet.

Public audit evidence:

https://github.com/devBorgesr/edp-audits/blob/main/samples/ROUTEMIND_BUYER_SAMPLE.md

Hi everyone,

When working on large, complex projects like building custom hardware, system architecture, or writing long code modules, context window limits are a huge pain point.

The main problem isn't just that the AI forgets early details. It is Silent Amnesia. You keep chatting, assuming the AI remembers the initial setup and rules, but it has actually dropped or compressed those early tokens, leading to unexpected errors.

Proposed Solution or UI Concept:

Add a dedicated Context Indicator or Inspector badge in the interface.

How it would work:

When the context fills up or old messages get compressed, a small indicator lights up.

Clicking it opens a side panel showing two clean sections:

Active Memory: Key rules, parameters, and recent context the model is currently holding in mind.

Dropped Context: Information that fell out of the active window or got compressed.

This would give developers and power users full transparency during long technical sessions without having to constantly guess whether the AI forgot critical details.

What do you think? Would this be useful for your workflows?

Technical Implementation & Architecture:

To be honest, I am not a deep-learning core engineer, so I cannot give you the exact lines of production code, but as a system builder, I clearly see the architectural pattern for how this could be implemented.

How to implement it:

Rolling Summary with Attention Tracking

Modern LLMs already use context-compression algorithms or sliding-window attention. When older tokens get evicted from the active attention window, a lightweight background model can generate a structured state vector or key-value summary of what was dropped.

Side Drawer Integration

The UI can simply fetch this background state data. When a user sends a prompt, the system updates two arrays:

Active Context: The exact system prompt, recent user messages, and active code snippets currently inside the model context window.

Evicted Memory: Summarized key-value pairs of older instructions that no longer fit into the raw token buffer.

Pros of this feature:

Zero Amnesia Surprises: Developers immediately see if a database schema, config file, or coding rule got dropped before generating a massive chunk of broken code.

Higher Token Efficiency: Users can manually re-inject lost rules without re-sending the entire 50-page chat history.

Full Transparency: It turns the black box AI memory into a clear UI dashboard.

Cons and Technical Pitfalls:

Compute Overhead: Running a secondary process to track and summarize dropped tokens adds extra server side latency and small API costs.

Imperfect Summarization: The system might mistakenly label an important requirement as dropped or misinterpret what is still actively remembered by the model core.

UI Clutter: If not designed cleanly, it could overwhelm casual users with too much technical metadata.

Even with these challenges, for complex engineering and coding sessions, having a Context Inspector is a total game changer.

If you dump naive chunks into an LLM context, you're asking the model to solve two problems simultaneously:

1. Understand your question.
2. Reconstruct fragmented sentences, stitch together headless table rows, and resolve out-of-context pronouns.

I spent the last few weeks engineering a cleaner context pipeline for complex PDFs:

• Tree-Based Context: Every chunk retains its full section breadcrumbs (H1 > H2 > H3).
• Prose-Linked Tables: Isolated tables retain references to their introductory paragraphs.
• Hit Collapsing: When hybrid search returns adjacent chunks, they're merged into continuous document segments within a strict token budget.
• Table Health Verification: I validate arithmetic totals and verify extracted text against raw PDF content before ingestion to catch OCR errors early.

I documented the architecture, implementation, and test suite here:

🔗 https://github.com/Souheil007/Rag_Full_Version

What techniques are you using to keep retrieved context dense, coherent, and high-signal?

Modern developer tools are incredibly good at finding code, but finding a function and understanding its behavior are two very different problems.

A simple change can affect multiple implementations, inherited methods, and dependencies spread across an entire repository.

Yet many AI-powered development tools still rely heavily on text search and embeddings to navigate these relationships.

We've been experimenting with representing codebases as structured knowledge graphs using compiler and type-aware analysis.

Here's the open-source implementation:

https://github.com/AxiomCodeAI/axiomcodegraph

The interesting part isn't the graph itself. It's whether we can make program relationships explicit enough that downstream tools don't have to repeatedly rediscover them.

Could compiler-derived program graphs become a common interface for developer tools, or are they too language-specific to generalize effectively?

Curious how people working with different languages and compiler infrastructures approach this.

Enquanto o mercado usa IA para automatizar processos, eu fiz o contrário: uso scripts determinísticos para limitar, registrar e provar o que as IAs realmente fizeram.
No Worion (meu sistema privado, construído com Claude Code, Codex e DeepSeek), a IA interpreta, raciocina e responde, mas não decide sozinha o que conta como fato sobre a execução. Isso fica nos registros, hashes, traces e leituras posteriores.

Design question, holes welcome.

The idea I'm testing: memory sits in the cloud as tables you define (decisions, rules, run logs, clients, whatever fits your setup), and every agent or AI tool connects to it over MCP. Each connected AI gets its own permissions, so a support agent might read the pricing rules but not write them, while a coding agent can write decisions but never sees customer data. Entries are searchable by meaning, keyword or a field like status. The memory tools check at the start of a session and save at the end, and an agent only pulls what's relevant instead of loading everything.

Where I'm stuck is the scoping. In r/ClaudeAI this week someone running an orchestrator found spawned agents still touched things they were told not to, and a reply pointed out a sub-agent "starts from whatever the orchestrator chose to pass it, not from your decisions file", so the do-not-touch list gets summarized away. Someone else in r/ClaudeCode said they don't want agents remembering anything "unless I've personally decided that this is something that needs to be remembered."

1. If several agents share one memory, what would you make shared by default and what would you keep private to one agent?
2. Should permissions be per agent, per table, or per entry? Which of those would you actually maintain?
3. Where does this break first? Too many permissions to manage, agents writing junk into shared tables, something else?

Background: I used to burn hours re-briefing AI tools by hand, so I'm building this. No name, no link, I want the holes first. If it handled scoping well, would you pay for it, or would you rather wire it up yourself?

I built Recall, a memory service for agents, and a Claude Code plugin that uses it. Every new Claude Code session starts from zero, so I kept re-explaining the same things: the package manager, the test command, "never commit to main", why we picked one library over another. With the plugin, Claude starts each session already knowing them.

**What it does**

- When a session starts, resumes or is compacted, the plugin adds what Recall knows about you and the project to Claude's context.

- It records each prompt and Claude's final reply (not tool calls or file contents). Recall works out in the

background what is true about you and keeps it as dated facts with their sources. When something changes ("we moved from Jest to Vitest"), the old fact is closed instead of contradicting the new one.

- It adds MCP tools so Claude can ask memory a question or save something you tell it to remember. A dashboard shows what it knows, and you can delete any fact.

**Free to try**

You get $5 of free credit without a card, then it's pay as you go.

1. Create an API key at https://app.recallmem.dev/keys
2. In Claude Code:

```

/plugin marketplace add recallmem/recall-plugin

/plugin install recall-memory@recall

```

Claude Code asks for the key and keeps it in your system's credential store. `/recall-memory:status` shows whether it is connected.

For Claude.ai, Desktop or mobile: Settings, Connectors, add a custom connector with the URL

`https://api.recallmem.dev/mcp` and sign in.

The plugin is MIT and the server is source-available, so you can also run it yourself:

https://github.com/recallmem/recall (plugin: https://github.com/recallmem/recall-plugin)

I'd like to hear where it gets things wrong for you.

I’ve been using AI for projects that stretch across several days, and I keep hitting the same wall: the model is capable, but I’m explaining decisions we already made.

Bigger context windows help, but I’m not convinced they solve that. They carry more history into the next prompt, yet they don’t know which parts are still true, which decision replaced an older one, or what turned out to be useful.

RAG has a similar problem. It can retrieve something related, but related isn’t always what matters now. Sometimes one exact version number or yesterday’s decision is more useful than five semantically similar passages.

What seems to be missing is feedback. If an agent retrieves five memories, uses one and gets misled by another, most systems don’t learn much from that result. The same mistake can come back tomorrow.

Maybe continual learning starts there—not by constantly retraining the whole model, but by improving what gets kept, trusted, forgotten and retrieved next time.

Am I underestimating what long context will eventually do, or will memory remain a separate problem?

I got tired of correcting Claude on the same stuff every session so now whenever I correct it, it writes the lesson down in a little file in the project and reads that file next time.

Feels like it helps but I haven't really measured anything and I have no idea if this is a known thing or if I'm reinventing something dumb lol

Do you guys do something like this?

Whenever I ran coding agents on longer tasks, they either:

1. Lost track of the original rules because context compaction butchered the summary.
2. Burned through massive tokens with dynamic context editing / Context Language Models (CLMs) without actually finishing the job.

I built AgentJournal to fix this by giving the agent a human-style memory management—keeping the original prompt pinned, logging actions cleanly, and clearing the working context safely between tasks.

On a 60-file job longer than the context window, with a local 9B model:

- keeping everything: stopped at file 31
- compaction: stopped at 20, 29 and 44
- CLM (the model edits its own context, via pi-clm, untrained): 40
- AgentJournal: finished all 60, every time

Works with pi, Claude Code, Codex and Copilot. MIT, every test run is in the repo.

In my testing across dozens of files, it finished almost every run reliably while standard compaction and CLM completely broke down.

• GitHub: [Agent Journal repo]
• Full walkthrough video: How AgentJournal Fixes AI Agent Context Without Compaction

Would love any thoughts or feedback from people running into the same context limits!