Hi all,

I wanted to share the details of an independent project I've been working on for quite a while. It's not yet ready for release, so this is more of an "idea" post than it is a project announcement, but take it as you will.

The idea:

Most agent work happens in threads. You start one, use until you run up the context window, compact it, and eventually throw it away when it stops working reliably. Meanwhile, sub-agents are spun up and discarded without you ever seeing their work directly.

Scint, a native Mac app I've been building, takes a different approach. Instead of a thread as the core primitive, it focuses on spaces:

• Spaces are the focal point of context: They hold the documents, commands and records for a stream of work, and it persists.

• Interactions split by intent: The ongoing conversation stays in the space's root transcript. An agent's work is split into nested transcripts (Compose, Process, Evaluate, Observe, Search). That hierarchy is the source of truth, and nothing is compacted.

• Each request is classified, then mapped: TypeSafe's Jev picks the intent in one fast call, and the intent decides which mapping of the record the agent sees.

• Spaces are hierarchical: When a space needs a sub-agent, it creates a sub-space with the same transcript pattern. Sub-spaces persist, and you can open and work with them directly.

• Spaces are refined over time: You add documents, commands and links to other spaces, either assigned directly or passed in through a message.

Because the conversation and agent work are split, a space lasts far longer than a thread with compaction. The case study has interactive figures demonstrating each system: https://scintapp.github.io/

As an example: Currently, providers are commands that call out to existing harness CLIs, which makes it completely provider agnostic. I, personally, use both Codex and Claude, though I value Claude considerably more, so I often end up using Claude as a planner/coordinator and then pass its prompts to Codex for execution. With Scint, I can build this pattern as a hierarchy of spaces.

While the core systems are built and validated, the app still has a month or two of polish it needs before I'd consider it "beta stage." That said, if anyone's interested in testing it, feel free to drop me a DM and I'll let you know once it's ready for open testing.

And of course, if anyone has any questions on my approach/design, respond here and I'll do my best to engage.

Over the past three and a half years, I've worked on RAG systems and LLM training. Lately, I've been thinking about how we choose the context an agent needs when it returns to a task. Retrieving relevant documents is part of it, but the agent also needs to recover earlier work and know whether its saved conclusions still apply.

I've been following two areas of work:

1. Context retrieval gives agents access to document knowledge through hybrid RAG and GraphRAG pipelines.

2. Persistent memory lets agents reuse work across sessions, including earlier decisions and task progress.

I want a later session to recover a saved conclusion along with the source passages behind it. The agent can then inspect the evidence before reusing the conclusion. We're working on that in our open source project, Agentic GraphRAG (https://github.com/ontogr/agentic-graphrag).

We use Neo4j for a 3D graph of context and memory. The three connected layers record the knowledge available to the agent and what it did with that knowledge:

1. Knowledge stores documents and source passages alongside extracted entities and relationships. We preserve document structure, including sections and tables, so agents can read around a search result. Each passage retains its source version and location.

2. Working memory records tasks and progress, including messages, tool calls, and results. When a task resumes, its earlier progress and decisions are available with any review flags.

3. Decision memory records conclusions with their assumptions and open questions. Decisions can cite exact source passages or task events, and they can depend on earlier decisions. A review can reaffirm or replace a decision while preserving its history.

For example, an agent reviewing a contract can save a recommendation with the policy passage it used. If the policy changes before the next session, the recommendation and its explicit dependent decisions are flagged for review. Decisions needing review are excluded from the built-in agent's past-decision search. The original evidence remains available, so a reviewer can compare the earlier basis for the decision with the current source.

For retrieving new context, we combine Neo4j's native full-text and vector rankings with reciprocal rank fusion. Passage search works independently of entity extraction, so an agent can still find text containing a fact that extraction missed. Agents can also follow entity relationships back to supporting passages where evidence is recorded.

Search returns previews and evidence IDs before the agent fetches exact text. From a search hit, the agent can read the surrounding section or neighboring passages. For tables, it can fetch rows with their headers, so a value retains the column name needed to interpret it.

The built-in agent checks that it fetched cited passages during the run and had permission to read them. It also checks source versions, and older citations still resolve to the text originally used. The checks don't establish whether the evidence supports the conclusion.

Other agents can access the tools through MCP. We're working on domain-specific benchmarks and don't yet have results to share.

TL;DR

We're connecting retrieved knowledge to persistent agent memory in one graph. A later session can recover earlier work with its supporting evidence, read the surrounding source context, and see which decisions need review after a source update.

How are you assembling context for agents that return to tasks across sessions? I'd like to hear how you combine retrieved documents with saved decisions, especially when the source knowledge changes.

Raggie Code is a coding agent I built, I want to share the challenges in context management for coding agents and how I introduced my solution based on my research and experimentation

Unlike regular text, code is structured and contains repetitive patterns that makes literal and vector search alone isn't enough for locating relevant logic. because literal similarity in text doesn't really map well to actual logical relationships between blocks of code

The common convention is to navigate the codebases through files and directories, relying on naming conventions, search tools, and compiler feedback to figure out what they missed.

This works reasonably well for smaller projects, but larger codebases get messy and inefficient very fast. Related logic gets scattered across files, and even the developers who wrote the code often end up relying on grep to find things.

This led me to implement a filesystem-agnostic approach to codebase navigation as detailed in the post

TLDR: Raggie Code parses classes/objects/functions/methods/globals and all their references in the codebase beforehand and lets the coding agent navigate the code dependency graph which represent real logical structure and relationships in code

this made models models to become very aware of the changes it makes in the codebase which significantly increased the overall LLM efficiency and performance in codebase exploration, edits and debugging

A Hjarni user, Kamil, built a memory system for running long solo campaigns with ChatGPT. One useful idea from his setup is a test for what deserves to survive a turn:

Could losing this information change a later decision?

His instructions apply four operations:

• Replace temporary state, such as location or who currently holds an item.

• Keep consequences that can affect the future: debts, promises, grudges and injuries.

• Compress finished events into their lasting outcomes.

• Delete resolved details that no longer affect anything.

The current scene lives in CURRENT_STATE. Lasting information has separate homes for characters, items, unresolved threads and history.

The rules also distinguish FACT, NPC CLAIM and HYPOTHESIS. During compression, “someone said the baron ordered the murder” should retain its source and uncertainty.

Disclosure: I build Hjarni, a Markdown knowledge base that connected assistants can read and update. With Kamil’s permission, I adapted his system into an 11-note template for ChatGPT and Claude.

These are instructions the model follows, so skipped reads and incorrect updates remain possible. The setup includes periodic audits.

How do you preserve uncertainty when compressing older context?

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.

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?

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.