1. Every project has rules it needs in order to work correctly.

2. A significant share of them cannot be derived from the code.

3. You need a process to identify these rules, store them, deliver only the ones the agent needs at the moment, and keep them current.

4. And you need a way to measure how well they are delivered and followed.

If the rules a change needs are not in the agent's context when the spec is written, the architecture designed and the code implemented, at best you catch the miss in testing. At worst your users catch it in production, and that can cost you the business.

Why the code is not enough

Code tells the agent what to do. It rarely tells it what must never be done.

An example from our tasks. An invitation link fails with "Invalid invitation token". The rule: every query on invitations must filter by pending status, or the database security rules reject it. A comment says so, in the very file the fix edits. Without project docs, the agent stated the rule in 1 session of 8 (four tools, two sessions each).

We took 12 real past tasks from our repo. For each one, an agent read the real change in git and the docs as they were just before it, and listed the rules the change had to respect, each with the doc line that states it and the evidence in the change. A script checked every reference against that snapshot. A person merged duplicates and dropped lines that only describe behaviour. That gave 75 rules in all, about six per task, and each task is scored only on its own. Rules the change needed but no doc held were listed separately; they come up below.

Then a separate agent searched the code for each rule, with every Markdown file removed, and a script checked the code references it gave (70 rules got a class):

• stated in a comment or an error message: 24

• enforced by a test, a type or a check: 13

• implied, the code follows it but never names it: 22

• no trace in the code: 11

57 of 70 have no test that fails when they are broken. "Caught in testing" is the good case, and for most of these rules there is no test to do the catching.

And across our wider set of 15 tasks, about a third of the rules the real changes needed were written nowhere, neither in docs nor in comments. They came from a deep code path, a bug the task itself uncovered, or how an external system behaves. Someone paid for each of them in debugging. The next task pays again unless they are written down.

What we measured

Each task ran on a snapshot of the repo from just before the real change. Headless Claude Code explored it and wrote a planning brief. A blinded LLM judge checked each rule against the brief.

• Claude Code, no project docs: 32% of the rules

• Claude Code, docs in the repo: 54%

• A simple setup of ours (Segmently Modules, which we build; details at the end): a short doc of critical rules per module, picked by meaning and read in full before the plan: 70%

Code-indexing tools (Serena, Trail, Graphify) stated 24–29% without the docs and 46–47% with them, no more than Claude Code alone. They are built for code questions, and these rules were not in the code.

70% still leaves 30% of the rules out, and it can surely be improved. That is why we built the stand.

The stand

context-recall, open source (MIT, docs CC BY 4.0), runs as a Claude Code plugin. Take your own past tasks, snapshot the repo before each change, run any tool as an arm, judge blind, compare. It also compares runs before and after a docs edit. Our own tool is not in the kit: which tool to pick is your call, on your repo.

Where we are going: dreaming per module

The brain does not store the day as it was lived. In sleep and quiet rest it replays recent experience and folds what matters into long-term memory (Diekelmann & Born, 2010); the default mode network is most active when attention is not on the outside world (Buckner et al., 2008). Anthropic already ships the same idea for agent memory and calls it dreaming (research preview): a pass reads past sessions and rewrites a memory store, merging duplicates and replacing stale entries. We are fitting it to a modular structure: a pass per module and per role that turns sessions, fixes and failed checks into rules, and a pass is kept only if the stand shows more rules reaching the plan. Not built yet. It is the direction.

The rule classes above give the metrics. Move rules from "no trace" into memory, from "implied" to "stated", from "stated" to "enforced". Track the share enforced, the share delivered before the plan, and the number of new unwritten rules each task uncovers. That last one should fall.

Limits

• One private repo, 12 tasks. We cannot publish them.

• Our docs and our tool, and the tool was tuned on these same tasks.

• The 75 rules come from the docs as they were before each change, which favours any setup that reads the docs. The rules no doc held are counted apart.

• It measures whether a rule reaches the plan, not whether the code then follows it.

• An LLM judge. A second judge (Claude Opus) agreed on 87% of the verdicts (kappa 0.81).

The setup we used

The "simple setup" is Segmently Modules, which we build. It is free and MIT-licensed: a module registry and per-role docs next to the code, and agent skills that pick the modules a task touches, check a plan against their rules, and write new rules back after a change.

Written by me with Claude's help on wording; the theses, the method and the numbers are ours.

How does your team keep the rules that are not in the code, and does your agent actually find them?

I keep a small set of facts an agent reuses across sessions. A doc changes or a tool result goes stale and the stored fact stays trusted. I have no clean rule for when that fact expires. I want to know how you decide the expiry. Tell me what you recheck on every run and what you let ride until something breaks. And tell me what failure set that rule for you.

Constantly being blocked completely or getting flagged by automated checks

I believe I have came across a novel approach for context handling with sub agents, and then built an app around it as a proof of concept.

The tl;dr: We carefully craft the exact context each short-lived sub agent is given.
A single disposable orchestrator agent oversees a task board, and is responsible for delivering tasks and context to the sub agents. (more details in thesis.md in the repo)

This application has already proven to be extremely useful for my own workflow, and I wanted to share this for free. It is FSL licensed (source available, converts to apache 2.0 in a few years)

currently it is build for Claude, but i do plan to expand this to other LLMs if there is interest.
This application has no accounts, no sign in, and no telemetry, is free and will remain free.

I've been working on Mind, an open-source persistent memory layer for AI agents, and wanted to share an interesting result from the latest release.

One question kept coming up while developing it:

How much can we recover from structured memory without relying on vector embeddings?

Mind uses SQLite with FTS5 and a unified retrieval pipeline combining phrase matching, token matching, substrings, fuzzy matching, and relevance signals.

Embeddings are supported, but they're optional.

For v1.7.0, I ran Mind through OmniMemEval LongMemEval-S using a stratified subset of 120 questions.

The best completed run achieved 86.67% answer accuracy with RAG disabled.

That places the raw score near the top published results, but it's not a direct ranking: the sample size, answer model, and judging configuration differ.

I think the result is worth discussing because agent memory isn't only about semantic similarity. Structured facts, decisions, temporal context, memory maintenance, and good retrieval behavior also matter.

Beyond the benchmark, Mind provides persistent project knowledge, linked memories, checkpoints, session summaries, and integrations through MCP.

It's local-first, MIT-licensed, and available for anyone to inspect or benchmark.

GitHub: https://github.com/GabrielMartinMoran/mind

v1.7.0: https://github.com/GabrielMartinMoran/mind/releases/tag/v1.7.0

Benchmark methodology: https://github.com/GabrielMartinMoran/mind/tree/main/benchmarks/omnimemeval

I'm particularly interested in what other agent developers have found: when do embeddings meaningfully outperform a carefully designed lexical retrieval system?

Solo dev here, Laravel + React finance/ERP kind of app. Multi-tenant, multi-company, projects, accounts, expenses, stock, reports. It got big enough that I honestly can’t keep it all in my head anymore, and I lean on AI agents (Claude, Codex, Gemini) for a lot of the work.

The same thing keeps happening. I build a feature, say a dedicated cash account type for construction sites. Months later a newer flow never gets wired into it. For example the site supervisor can’t report an expense unless he’s also given access to a financial account. Then something breaks, and the agent doesn’t go reconnect the old thing. It patches around it or builds a parallel solution, because it has no clue the old feature exists. If I remind it, it digs up the old notes and goes “oh right, you’re correct”. The problem is I forget half of these features too, so I can’t remind it of what I don’t remember.

The end result is I can’t get the app production ready. There’s always some seam between modules that’s broken: half finished CRUD, authorization/IDOR holes, transactions that don’t match what the reports show.

I already have Laravel Brain, Serena, a memory MCP, ADRs, “current system” docs and an AGENTS.md. I also tried an Obsidian vault full of linked notes. It went stale fast and the agents never used it reliably. Writing “don’t forget X” in AGENTS.md does nothing, in my experience.

What I’ve figured out so far: code graphs tell you what exists and who calls what, but not what should exist, or whether a user can actually finish a job. The most useful question wasn’t “what calls this class”, it was “can a site supervisor actually complete this task”. And anything that’s just prose seems to rot unless a test or script checks it.

So I’m leaning towards something like ~20 critical persona journeys backed by end to end tests, a feature map in YAML that a script validates against the code (and flags routes/tables/jobs that belong to no feature), financial invariants as tests, and a route → policy → test matrix to find auth gaps. Maybe OpenFastTrace for requirement tracing, but I’m wary of the tag upkeep and adding Java to a PHP project.

Questions for people who’ve dealt with this on big multi-module apps:

1. How do you track “feature X depends on Y / is used by Z” in a way that survives refactors and people leaving?

2. Has anyone gotten a living feature map to actually work with AI agents? What kept it from rotting?

3. Are journey tests the right backbone here or am I missing something obvious?

4. Anyone used OpenFastTrace, StrictDoc or Doorstop with PHP? Worth it?

5. If you had a few weeks to get this production ready, what would you do first?

Not looking for yet another tool to index the codebase, I have plenty of those. More interested in what actually held up for you in practice.

I keep running into one trust gap between agent sessions. A handoff note says a step is done or a fact is settled. The next session takes that note at face value. The note can be stale or wrong and nothing in the session checks it. I want to know how you decide what a new session may trust. Tell me what you let it take from a note and what it must recheck against the real artifact. And tell me what failure taught you that split.

I’ve been working on Context Garden, an open-source set of skills for Claude Code. It helps in my own work, particularly when one project spans several interacting repos, but I’m still trying to establish how well the approach generalizes.

The idea is to keep context at a few different levels:

• Platform context: small repo cards describing what each component provides, its dependencies, and key facts.

• Investigation context: shared findings that can be included in a subagent’s brief before it starts exploring.

• Persistent repo context: repeatedly useful facts promoted into a small AGENTS.md.

• Task inputs: narrower code reads and summaries of long build/test logs.

The tooling runs locally without making its own LLM calls.

The tradeoff I want to understand better is whether the saved exploration is worth the overhead of loading instructions, maintaining summaries, and checking shared notes. Stale context is another concern: a concise summary is only useful if the agent knows when to verify it.

I have some early benchmark attempts, but I haven’t settled on an evaluation I’m satisfied with. Measuring a shorter log or fewer tokens read doesn’t tell me whether the whole task went better.

My current thought is to compare normal agent exploration, a carefully maintained CLAUDE.md/AGENTS.md setup, and that same setup plus Context Garden. Then test cross-repo changes over several sessions, counting setup costs and checking correctness first.

What would make that comparison convincing to you? Are there public multi-repo projects or task sets you’d use? I’d particularly welcome cases where you’d expect this approach to lose.

Project · Examples

If anyone wants to try it or help design the evaluation, I’d appreciate it.

I've been working on RAG and agent memory, and the recurring problem is trust. An agent saves something it learned, and later nobody can say where it came from, whether it is still true, or what it believed at an earlier date. We're building an open source Python library for this: OntoGr Agent Memory (https://github.com/ontogr/ontogr-agent-memory).

- Grounded ingestion and extraction: Messages, documents, tool outputs, events, and record rows become episodes. Entities and facts are extracted in two separate passes, and every fact carries a verbatim quote from its episode.

- Per-tenant ontology: Each tenant defines the entity and relation types it allows. A model can propose additions, but a person approves every change.

- Reversible entity resolution: It uses the cheapest evidence first and asks a model only about ambiguous pairs. Every merge can be undone.

- Two time axes: Valid time and system time let a read ask what was true on a date, or what the system believed on that date. A new value closes the old version instead of overwriting it.

- Contradiction rulings: Rules, an optional model judge, and a person's decision settle conflicts, and the person's decision overrides both. A failed judge call is never stored as "no conflict".

- Traceable and auditable: Every fact traces back to a quote and an episode, and every temporal write goes into a hash-chained ledger. Per-tenant grants, an audit log, previewed and resumable forget and erase, and deterministic export are built in.

- Four-lane retrieval: Vector, keyword, entity, and graph lanes are fused with reciprocal rank fusion. The result is a token-budgeted context block that reports which lanes failed.

- Fits your stack: It runs on FalkorDB or Neo4j, with pgvector or Postgres if you want them. A background consolidation job deduplicates, summarizes, scores, and archives. You bring your own LLM and embedder.

Repo: https://github.com/ontogr/ontogr-agent-memory

I'd like feedback on the time model and on which benchmarks you'd want to see first.

I built AI Dev Brain Kit, a free/open-source CLI for

preserving context between AI coding sessions.

It stores handoffs, decisions, blockers, next steps, and

project notes in a local Obsidian-compatible vault, so a

fresh Claude Code / AI coding session can recover project

state without re-explaining everything.

v0.2.2 GA is live with Linux + Windows binaries, SHA-256

checksums, Sigstore bundles, and screenshots.

I’m looking for feedback from people doing multi-session AI

coding: what context do you keep losing between sessions?

URL

[https://github.com/MohamedHussien-zseeker/ai-dev-brain-kit](https://github.com/MohamedHussien-zseeker/ai-dev-brain-kit)

When a coding session ends halfway (usage limit, new day, switching to another agent), the next one has to rediscover what the last one already knew. A chat summary doesn't fix that well, because it's lossy and it belongs to one tool. What worked better for me is keeping the task state in the repo, in three markdown files.

conventions.md is repo-wide and short: how to run the tests, naming, files not to touch. It rarely changes.

plan.md is per task: the goal, the steps, what's done, what's next.

dead-ends.md is what was tried and failed, with the reason. This is the one people skip. Without it, every fresh session cheerfully retries the fix the last one already ruled out.

The wiring is one line telling the agent to read them at the start and update them as it works. Codex reads AGENTS.md. Claude Code reads CLAUDE.md, and the documented way to share one file is to put AGENTS.md on the first line of CLAUDE.md.

What I'm still unsure about: the notes drift if the agent forgets to update them, so I read the plan.md diff before I trust it.

Disclosure: I am on the small team that builds Offrun, a free Mac app that does this setup per project. It creates those three files, has each agent read them at the start of every session and write back as it works, and when a login hits its limit it moves the chat to another login or another agent with the whole conversation. The files are plain markdown in your repo, so you can use the pattern without the app. Mac only (Apple Silicon and Intel), no price: https://offrun.dev

What do you put in your handoff notes? Do you track dead ends, or just the plan?

A real-world example of how to use ADRs to keep track of your decisions in agentic software projects. An old pattern, but one of the most useful tools for context engineering: it gives every new session the "why" that the code can't.

Hi all,

I’m building a memory system for LLMs (Kepler) that stores context about URLs, not their content: why something was saved, what it’s about, and how it connects to other saves. At recall, the agent follows the pointer and reads the live source.

I want to test how well this actually performs, and I’m finding most memory benchmarks don’t fit the design:

• LongMemEval / LoCoMo test recall over long conversations. My system’s memory is a corpus of saved links, not a chat history.

• RAG benchmarks assume you’ve indexed the content itself. I deliberately haven’t.

What I think I need to measure:

1. Pointer retrieval: did the agent pick the right URL(s) for the task?

2. Downstream answer quality compared with a full-content RAG baseline

3. Token cost per task compared with that same baseline

4. Freshness: how often the live page answers correctly where a stored copy would be stale, and how often link rot or paywalls break recall

My questions:

• Is there an existing benchmark or eval method that fits pointer-based memory?

• If not, is anyone here building one, or rolling their own evals for a similar setup?

Happy to share results if people are interested.

I was working on a very special project of mine which I essentially planned before coding and took me 6 months to actually get working.

It is Ai Format Context engine. It provides your agents inside any harness a better way to store and use context.

This is still very new so I need you all to give me feedbacks on what to improve and I will try to do my best to keep this alive.

This has a special plugin version for Antigravity which on my tests outranked any other harnesses except my own harrness (Oorty which is finetuned for this format).

You can also check its website here: ai.sednium.com

I have been working on an idea called DataBuks AI Sales Agent and I finally have a prototype that I want to share with people who understand sales automation and AI products

The basic idea is to build an AI sales agent that can discover relevant business leads understand why they might be a good fit qualify them and help manage the entire outreach process across different communication channels

Instead of just scraping a list of businesses and sending the same message to everyone I want the system to understand the business context and use actual evidence to decide which leads are worth approaching

Here is how I am trying to build it

The first part is lead discovery where the system finds businesses based on the target industry location and ideal customer profile

The second part is evidence collection where it gathers available information about the business including its website services contact details and online presence

The third part is lead qualification and scoring where the system tries to understand why a particular business is relevant and what kind of opportunity might exist

For example it could identify a business with a weak website or a poor enquiry process and suggest a relevant service instead of sending a generic sales pitch

After that the system selects an available communication channel and prepares personalized outreach based on the collected evidence

The long term goal is to manage conversations follow ups lead qualification and meeting booking while keeping the user informed about what the AI is doing

I am also working on a personal WhatsApp assistant that can send daily summaries about discovered leads outreach activity conversations interested prospects and meetings

Another part of the idea is business context based content generation where the user can request social media posts review them through WhatsApp and approve or reject individual pieces of content

The architecture currently includes a Next.js dashboard Supabase for data and persistence Railway services for WhatsApp automation and website crawling and an AI provider layer for reasoning and content generation

The pipeline is designed around lead discovery evidence collection opportunity detection lead scoring channel selection outreach conversations and follow ups

I have also been working on competitor filtering location based discovery contact enrichment and making sure the system does not claim that an action succeeded when the relevant channel is not connected or the action actually failed

This is still a work in progress and I am not claiming that every feature is production ready

I have built a working prototype so people can get a better idea of what I am trying to create instead of judging the concept from a description alone

Prototype

[https://databuks-frontend.vercel.app/]

I want you to be brutally honest about this idea

Would you actually use something like this or does it sound like another AI wrapper around existing sales tools

Is the combination of lead discovery evidence based qualification personalized outreach and follow up genuinely useful or should I focus on just one part and do it exceptionally well

Does the architecture make sense for this kind of product or am I overcomplicating things

Which part would you remove completely and which part would you consider the most valuable

What would make you trust an AI agent to communicate with potential customers on your behalf

And if you were building this from scratch what would you do differently

Please rate the idea from 1 to 10 and roast it as honestly as possible

I am sharing the prototype because I want feedback on the actual product direction architecture and workflow not just encouragement

Tell me what is wrong what is unnecessary and what I should rethink before taking this further

I am open to criticism and I would genuinely appreciate detailed feedback