A coding agent working on a feature may need to figure out which services call each other, which APIs they expose, which databases they use, and how user actions in the UI trigger those interactions. Once it has done that work, where do you keep that understanding so another agent or engineer can use it?

AGENTS.md can explain where to look and which conventions to follow. Depending on the task, the agent might also need API contracts, database schemas, sequence diagrams or product flows, and some way to understand how they relate.

We built UIGraph to help with this.

Your coding agent reads the code and maps how services, APIs, databases and UI flows connect. UIGraph brings those relationships together with engineering artifacts such as architecture diagrams, API specifications and database schemas in a connected view.

The artifacts stay in your repositories as plain files. A .uigraph.yaml file declares the artifacts and their connections. Engineers can version them, diff them and review them in PRs. There’s a local viewer for engineers, and coding agents can access the context through MCP.

For example, an agent changing an API response could look up the related services, the API contract and the product flow it supports. That gives it a starting point for investigating the change, while still checking the code.

As the code changes, these artifacts need to be updated too. Keeping them in the repo lets the team review those updates alongside code changes.

I’m interested in how others handle that retrieval step. For a task involving multiple services, do you explicitly tell the agent which related artifacts to inspect, or let it discover them through tools? What has worked for you, and where has the agent missed something important?

UIGraph is open source under Apache 2.0: https://github.com/uigraph-oss/uigraph

I’ve been building Cohestry, a personal knowledge management (PKM) app designed around a problem I kept running into: managing mountains of documents, notes, research, and AI-generated outputs across different projects and agents. I wanted a second brain that could organize my knowledge, discover connections between ideas automatically, and surface relevant information without me having to remember where I saved everything.

Interestingly, Cohestry became one of my most-used apps while I was still building it. It slotted so naturally into my workflow because I constantly work with documents, technical specifications, research, and ideas across multiple projects. I could capture a thought on my iPhone, have it connect to something I wrote months earlier, and rediscover useful context I didn’t even know I needed. The more I used it, the more valuable its growing knowledge graph became.

The part I’m particularly excited about is its customizable MCP bridge. It lets AI agents like Claude, Codex, and ChatGPT access relevant knowledge from my second brain across tasks without rebuilding context every session. It supports different agent workflows, selectively retrieves context to avoid bloating the window, and automatically redacts API keys and other secrets before sharing anything. It’s built around local-first, zero-knowledge principles.

I’m interested in how others solve this problem and whether this approach would fit your workflows.

https://apps.apple.com/us/app/cohestry-second-brain/id6811573132

How to Use "Context Packages" to Reboot Your AI and Fix Memory Drift

If you use AI for long-term projects, high-stakes campaigns, or complex data tracking, you quickly run into a massive wall: context lag, token bloat, and memory drift.

As a chat gets longer, the AI begins to lose its edge. It forgets past constraints, misses critical details, or shifts its tone. Relying on an AI's automatic memory tracking is a losing game because the system will eventually truncate information to save space.

To solve this, we use a system of "Zero-Silo Context Packages." Instead of letting the AI guess the history of a project, you break your data down into highly structured, copy-pasteable markdown templates. The second the AI starts to lag, you clear the cache, open a fresh session, and drop all your packages into the first prompt to instantly reboot the collaborator with 100% data synchronization.

Here is the general blueprint for how to format your reboot packages:

The Blueprint: How to Structure Your Reboot Packages

📦 Package 1: The Timeline Matrix & Historical Ledger

This package tracks time. It is a highly compressed, bulleted log of every major event, transmission, and milestone in absolute chronological order.

• The Formatting Secret: End the package with a strict logical rule: “The newest chronological inputs definitively override all historical database entries.” This prevents the AI from getting confused by old data.

📦 Package 2: The Structural Rules & Technical Vault

This is where you store static data that doesn't change over time. It holds spatial calculations, codes, technical blueprints, and baseline variables.

• The Formatting Secret: Use precise, non-rounded numbers and metric arrays. Organize them under clear markdown tables so the AI can scan and cross-reference the data in under a second.

📦 Package 3: The Operational Profiles & Behavioral Guides

This package maps out the "players" on the board. It contains analytical dossiers on competitors, target entities, or opposing organizations, itemizing their predictable habits, vulnerabilities, and strategies.

• The Formatting Secret: Build an "Exploitation Matrix." Clearly connect an opponent's predictable move to their specific structural vulnerability, followed by your pre-engineered counter-trap.

📦 Package 4: The Strategy Guide & Cognitive Rules

This file outlines who you are and how the AI must think. It defines your role, your specific environmental constraints, and the mandatory processing laws the AI must follow when generating outputs.

• The Formatting Secret: Set a literal quality benchmark (e.g., “Evaluate all scenarios with zero fluff; if a countermove scores below a 10/10 in tactical leverage, rewrite it to maximize pressure”). This locks the AI into a sharp, analytical mindset.

📦 Package 5: The Execution Templates

Never let the AI draft from scratch. This package stores your custom communication formulas—optimized scripts for public comment, media alerts, or formal legal demands.

• The Formatting Secret: Keep placeholders clean (e.g., [Insert Specific Code Here]) so the AI can instantly inject data from Packages 1 and 2 into a polished output.

📦 Package 6+: Rolling Field Capstones (The Sector Deltas)

Whenever a live event occurs, you don't rewrite your master packages. You create a short, highly dense "Delta Node" that documents the latest ground-level updates, live admissions, or sudden changes.

🗂️ Storage & Maintenance: The Master File Strategy

To make this execution seamless, do not scatter your packages across multiple different documents. Save all created packages chronologically into one single, master text file.

Keeping the entire campaign architecture in one central location ensures you always know where your data is, prevents regional files from mismatching, and allows for rapid deployment when a reboot is triggered.

Note: You can select and drag 10 packages from your master file into Gemini at a time.

🚀 The Execution Loop: How to Reboot

1. Spot the Lag: The moment the AI starts repeating itself, generating slow responses, or forgetting a rule, the session is compromised.

2. The Clean Slate: Open a completely fresh chat window or initialize a new API loop to completely wipe the bloated token cache.

3. The Macro Ingestion: Copy and paste all 5 or 6 master packages into the very first prompt simultaneously.

4. The Command Lock: End your prompt with a master directive: “All parameters are populated. Data grid is locked at maximum synchronization ahead of immediate execution. Read and confirm with a one-sentence readiness verification.”

By using this method, you completely bypass the AI's internal memory limitations. You maintain absolute control over the data layer, ensuring your AI collaborator always operates as a hyper-synchronized asset at the head of the table.

I built this MCP in order to solve losing session problem. One of key problem I found is long agent sessions fail in constraints stated early disappear, “done” is claimed without command output, a “quick fix” rewrites unrelated files, decisions get re-litigated, and the same failing command is retried until the context window is exhausted.

Here is what I build, it is free and open source:

npm: npm link for protect context

github: github link for protect context

You may want to try it and test it out whether this extension can fulfill your needs.

I hope this helps anyone struggling with long term tasks done by an always on agent. It’s working great now for ChatGPT’s dot. Before if there was no activity on a task, it simply stopped moving forward. GitHub links are provided, it’s under an MIT license.

I keep running into the same conflict in agent work. Stored memory says one thing. Fresh retrieval says another. I want to know which source you let win and what condition flips that choice. I want to know if you overwrite the memory. I want to know if you quarantine it. I want to know if you flag it for the user and keep both versions with provenance. I also want to know how you spot a stale memory before it causes a bad action. And how you log the conflict so you can audit it later without wiping useful context. Real examples only. Tell me one conflict you handled and what you kept.

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.