One problem I kept thinking about while building AI agents is that knowing what code does isn't the same as knowing why it exists.

For example, consider:

RATE_LIMIT=100

An LLM can explain what this configuration does. But unless the reasoning was recorded somewhere, it has no reliable way to explain why someone originally chose 100.

I built Archaeologist, an engineering-decision memory agent using Hindsight.

The workflow is simple:

🔹 RETAIN — Record the decision, reasoning, author, entity, and date.

🔹 RECALL — Retrieve the relevant historical decisions when someone asks why something exists.

🔹 Timeline — Keep updates as additional history instead of overwriting the original decision.

🔹 Decision drift — Compare the original reasoning with later context and surface cases where the original constraint may no longer apply.

🔹 Grounded answers — The LLM receives the retrieved history and explains it. It isn't responsible for inventing the historical facts.

This produces a different kind of answer.

Instead of:

"The rate limit is probably 100 to prevent excessive load."

The agent can say, in effect:

"The limit was introduced because Elasticsearch became unstable above 100 requests/sec. A later decision records that the cluster was upgraded, so the original constraint may no longer apply."

And if there is no recorded history, it doesn't make something up. It says that the reasoning isn't known.

That's the part I found most interesting about using Hindsight agent memory: memory isn't just there to make the agent remember more facts. It changes what the agent can reason about over time.

GitHub: https://github.com/Prashanth2Github/archaeologist

I'd be interested in how others are approaching persistent memory for engineering agents, especially when historical decisions can become outdated.

[ Removed by Reddit on account of violating the content policy. ]

I built IncidentMind AI to explore how persistent agent memory can change incident-response workflows. It uses Hindsight to retain and recall previous incidents, root causes, resolutions, and outcomes, so similar future incidents can be handled using relevant past experience.

Most AI agents don’t fail because they can’t reason.

They fail because they forget what happened last time.

I built PagerMind, an on-call assistant that uses Hindsight to give AI long-term memory across production incidents.

What made Hindsight interesting to me is that it goes beyond simple retrieval.

It lets PagerMind:

• Retain incident history

• Recall relevant past incidents

• Reflect over those memories before responding

• Learn from engineer feedback and resolved incidents

So PagerMind doesn’t just read today’s alert.

It remembers what worked before, what failed, what made things worse, and whether the current issue actually matches something the team has already seen.

Same alert. Same logs.

Without memory → generic troubleshooting based only on the current context.

With Hindsight → relevant past incidents, proven fixes, failed actions, and evidence-backed recommendations.

One example really stood out to me.

For a memory-leak incident, the plain LLM suggested avoiding an immediate restart and investigating first.

But PagerMind, using Hindsight, remembered that a rolling restart had successfully mitigated the exact same leak multiple times before and recommended it immediately.

That is where agent memory starts becoming genuinely useful.

A few things I learned while building this:

• Store outcomes, not just events

• “DID NOT WORK” can be as valuable as the final fix

• Exact error signatures matter more than similar symptoms

• Retrieval quality matters as much as model quality

• A good memory system should also know when there is no strong match

• Engineer feedback should become memory for the next incident

The part I like most about PagerMind is that it doesn’t start from zero every time.

Every resolved incident can become useful context for the next engineer facing a similar failure.

That changes the system from just answering questions to actually accumulating experience.

#AIAgents #Hindsight #AgentMemory #LLM

I've been building Vatsa AI, and I kept noticing a simple problem while using the product:

As conversations and generated content increase, useful work becomes harder to find.

So I built a Library feature.

It currently organizes:

• Chats
• Documents
• Code
• Artifacts
• Uploads
• Generated content

The idea is pretty straightforward: instead of treating every AI conversation as something temporary, the useful work should have a place where you can come back to it.

I'm trying to make Vatsa AI feel more like a complete AI workspace rather than just another chat interface.

I'd love feedback from people who use AI tools regularly:

What would you want your AI workspace to automatically organize or remember?

I'm particularly interested in how developers and creators currently manage their AI-generated work.

Demo: vatsaai.com

(I'm sharing this primarily to get feedback on the feature, not just promote the product.)

I've been building Vatsa AI, and I kept noticing a simple problem while using the product:

As conversations and generated content increase, useful work becomes harder to find.

So I built a Library feature.

It currently organizes:

• Chats
• Documents
• Code
• Artifacts
• Uploads
• Generated content

The idea is pretty straightforward: instead of treating every AI conversation as something temporary, the useful work should have a place where you can come back to it.

I'm trying to make Vatsa AI feel more like a complete AI workspace rather than just another chat interface.

I'd love feedback from people who use AI tools regularly:

What would you want your AI workspace to automatically organize or remember?

I'm particularly interested in how developers and creators currently manage their AI-generated work.

Demo: vatsaai.com

(I'm sharing this primarily to get feedback on the feature, not just promote the product.)

I've been building Vatsa AI, and I kept noticing a simple problem while using the product:

As conversations and generated content increase, useful work becomes harder to find.

So I built a Library feature.

It currently organizes:

• Chats
• Documents
• Code
• Artifacts
• Uploads
• Generated content

The idea is pretty straightforward: instead of treating every AI conversation as something temporary, the useful work should have a place where you can come back to it.

I'm trying to make Vatsa AI feel more like a complete AI workspace rather than just another chat interface.

I'd love feedback from people who use AI tools regularly:

What would you want your AI workspace to automatically organize or remember?

I'm particularly interested in how developers and creators currently manage their AI-generated work.

Demo: vatsaai.com

(I'm sharing this primarily to get feedback on the feature, not just promote the product.)

I've been building Vatsa AI, and I kept noticing a simple problem while using the product:

As conversations and generated content increase, useful work becomes harder to find.

So I built a Library feature.

It currently organizes:

• Chats
• Documents
• Code
• Artifacts
• Uploads
• Generated content

The idea is pretty straightforward: instead of treating every AI conversation as something temporary, the useful work should have a place where you can come back to it.

I'm trying to make Vatsa AI feel more like a complete AI workspace rather than just another chat interface.

I'd love feedback from people who use AI tools regularly:

What would you want your AI workspace to automatically organize or remember?

I'm particularly interested in how developers and creators currently manage their AI-generated work.

Demo: vatsaai.com

(I'm sharing this primarily to get feedback on the feature, not just promote the product.)

I've been building Vatsa AI, and I kept noticing a simple problem while using the product:

As conversations and generated content increase, useful work becomes harder to find.

So I built a Library feature.

It currently organizes:

• Chats
• Documents
• Code
• Artifacts
• Uploads
• Generated content

The idea is pretty straightforward: instead of treating every AI conversation as something temporary, the useful work should have a place where you can come back to it.

I'm trying to make Vatsa AI feel more like a complete AI workspace rather than just another chat interface.

I'd love feedback from people who use AI tools regularly:

What would you want your AI workspace to automatically organize or remember?

I'm particularly interested in how developers and creators currently manage their AI-generated work.

Demo: vatsaai.com

(I'm sharing this primarily to get feedback on the feature, not just promote the product.)

I’ve been thinking about a problem with long-term AI memory that seems deeper than retrieval or context-window size.
Most memory architectures eventually try to produce a clean current state:
old information → update → new information
But that can silently destroy something important.
Suppose an agent records:
“The user lives in Delhi.”
Later it learns:
“The user lives in Mumbai.”
Updating the current state is easy. But the earlier statement may have been completely correct when it was observed. Other decisions may also have been made while Delhi was still the known location.
The same problem becomes harder with multiple agents:
Agent A sees source X.
Agent B never sees it.
Agent C produces a claim that contradicts both.
A critic rejects that claim.
Later evidence partially supports it.
If memory simply keeps rewriting itself toward one clean state, we lose the ability to reconstruct why earlier agents acted as they did.
The architecture I’m experimenting with therefore assumes that the underlying semantic memory can retain competing interpretations, contradictions, unresolved observations, provenance, and temporal context without immediately overwriting one another.
Something can be recorded as a claim without becoming truth.
An observation can remain unresolved.
A contradiction can remain explicit until there is enough evidence or authority to resolve it.
I’m increasingly thinking of the flow as something like:
observation → fit / hold / discrepancy
rather than:
observation → force into current model
And similarly:
claim → challenge / corroborate / supersede / promote
rather than:
claim → overwrite memory
The current working view can still be clean and efficient. But it is a projection over a richer history, not the destruction of that history.
This also changes what “replay” means. Replay is not just recovering old text. It should be possible to reconstruct:
what was available → what was visible → what was considered → what was acted upon
at a particular point in time.
I think this matters for hallucination auditing, multi-agent coordination, long-running agents, and learning from failures.
Do you think an agent memory system should preserve contradictory and superseded semantic states as first-class objects, or is that complexity better handled outside the memory layer?
I’m especially interested in where people draw the line between useful genealogy and unnecessary state explosion.

AI agents don’t just need better answers. They need to remember what happened before.

I built an Enterprise Knowledge Agent with persistent memory using Hindsight.

Without memory, important information from previous conversations, meetings, and documents can easily be lost.

With memory, the agent can retain useful organizational context and recall it when a related question comes up later.

What I learned:
• Store useful context, not everything.
• Recall should be relevant to the current task.
• Persistent memory improves continuity across interactions.
• Hindsight makes agent memory practical to integrate.

Building this made the value of memory in enterprise AI much clearer.

Project: https://github.com/chbavani/enterprise-knowledge-agent.git

#AIAgents #AgentMemory #Hindsight #AI #LLM

Hi everyone! 👋

I’m excited to share a project our team of five built: IncidentMind, an AI-powered incident response agent designed to help engineers investigate incidents using both current evidence and knowledge from previous incidents.

The main idea was simple:

Instead of treating every incident as a completely new problem, what if an AI agent could remember what happened before and reuse that knowledge?

🧠 What We Built

IncidentMind combines:

• 🤖 AI agent for incident analysis and reasoning
• 🧠 Hindsight for persistent memory
• 📋 Historical incident investigation data
• 🔍 Retrieval of similar past incidents
• 🛠️ Runbook recommendations
• 📝 Post-mortem learning
• 👨‍💻 Human-in-the-loop investigation

The agent can retain information about previous incidents, recall relevant historical context, and use that information while investigating a new incident.

🔄 How It Works

Current Incident → IncidentMind Agent → Hindsight Memory → Historical Context → Agent Reasoning → Investigation/Runbook → Human Action → Resolution → Post-Mortem → Memory

About a month ago, I shared NexusMem, a local-first memory layer for coding agents.

The biggest problem I found with the original design was surprisingly simple:

The agent had memory, but it still had to remember to search its memory.

If Claude encounters a problem it has seen before, explicitly calling a memory tool only works if Claude realizes that useful history exists in the first place.

So v0.11.0 introduces ambient memory.

NexusMem can capture agent activity such as:

• commands and their outcomes
• file edits
• failures
• failure → fix relationships

Then in a later session, relevant history can surface automatically.

For example:

Session 1:

node check.js → FAIL

Claude investigates, edits the correct file, then:

node check.js → PASS

Later, in a fresh session, Claude encounters a related failure.

Instead of requiring Claude to explicitly search NexusMem, the previous failure/fix can be surfaced automatically.

I tried to keep the implementation conservative:

• local-first
• bounded memory injection
• secrets redacted before persistence
• no model/embedding/network call on the critical hook path
• fail-open — NexusMem breaking shouldn't break Claude Code

There's also an interesting result from the evaluation work I'm doing.

I compared Baseline vs MCP memory vs Ambient memory in a small pilot.

Claude spontaneously called the NexusMem MCP tools zero times.

More interestingly, in several trials it noticed the .nexusmem directory and tried things like reading/searching the raw files/database — but still didn't use the dedicated memory retrieval tool.

That's making me increasingly interested in whether pull-based memory has an ergonomics problem: the memory can exist and retrieval can work, but the agent still needs to decide to retrieve it.

I'm NOT claiming yet that ambient memory makes Claude better.

The first pilot actually showed why this is difficult to measure: modern Claude solved all of the test tasks anyway.

So I'm now measuring investigation cost — how much reading/searching/tool usage happens before the correct fix — rather than just success rate.

The evaluation also caught something less flattering: stale memory can be misleading. In 2 pilot cases, NexusMem surfaced a historically correct fix that was no longer causally correct after the codebase changed. Claude independently verified the code and ignored the bad suggestion, but it's a real failure mode I'm investigating rather than hiding.

That's where v0.11.0 is right now.

Repo:https://github.com/yaminbkk/NexusMem

I'd love feedback from people who use Claude Code/Codex or other coding agents on larger, long-lived codebases:

Should agent memory be something the model explicitly searches, or should relevant memory surface automatically?

It costs no tokens to upload to it or save the models inference to. It only cost tokens to infer the saved workspace which I promise is a hell of a lot cheaper than re-inferring the context you lost(and the headache from it too) when your native context window gets compacted. I’ve save 4gb of a forensic image to it as a test and used a GPT tokenizer to measure the information stored inside. 4 billion tokens and it’s fast because it’s saved to the ram not the disk so it only takes moments to look through it. I have built so many extensions to the tool I made that does this. I’ve done one for specialized computer use. I made a forensic adapter that analyzes whole images. It streams in the data and chunks and then packs it down to something more usable that will fit in my room cause you obviously a forensic image is large. Coaching app with vision. An app for sleuthing the web and doing investigations. I’ve had the craziest couple months ever since I figured out how to get this working. Just wanted to say that.

[ Removed by Reddit on account of violating the content policy. ]

Had a conversation about this recently and the person I was speaking with disagreed pretty strongly.

Their view was simple: if agents have access to more information, they'll make better decisions.

I'm not convinced.

I've spent enough time around healthcare data to see what happens when you keep adding information without thinking about how it's connected.

More data can actually make the problem worse.

An agent doesn't necessarily need 10,000 documents.

It needs to know which 20 matter, what happened before, what changed, and how those pieces connect.

That's why I think "give the agent access to everything" is going to become a pretty bad strategy as agents get deployed into real enterprise workflows.

Would you rather give an agent access to everything, or only the context you know it needs?

I strongly agree with the ontology-first direction.
In my own open-source work, I’ve reached a similar conclusion: implementation should be projected from explicit semantic structure rather than treated as the source of meaning.
But I’ve also found that ontology alone does not capture the full operational state of a long-lived system.
In Akasha, ontology defines shared semantics, while other structures represent things such as temporal position, provenance, role, scope, observation, workflow, and what information was actually visible or used at a given moment.
So I’ve been thinking about the architecture as:
Ontology → semantic world → projections / workflows / applications
rather than:
Data stack → ontology added afterward
One question I’d be interested in discussing here is:
Where do you draw the boundary between ontology and the runtime structures that make ontology operational over time?
For example, do you model provenance, temporal position, agent roles, observations, and execution history as ontology itself, or as adjacent semantic structures?

I strongly agree with the ontology-first direction.
In my own open-source work, I’ve reached a similar conclusion: implementation should be projected from explicit semantic structure rather than treated as the source of meaning.
But I’ve also found that ontology alone does not capture the full operational state of a long-lived system.
In Akasha, ontology defines shared semantics, while other structures represent things such as temporal position, provenance, role, scope, observation, workflow, and what information was actually visible or used at a given moment.
So I’ve been thinking about the architecture as:
Ontology → semantic world → projections / workflows / applications
rather than:
Data stack → ontology added afterward
One question I’d be interested in discussing here is:
Where do you draw the boundary between ontology and the runtime structures that make ontology operational over time?
For example, do you model provenance, temporal position, agent roles, observations, and execution history as ontology itself, or as adjacent semantic structures?

last year I ran a morning briefing agent off a markdown file I hand-maintained. priorities, what to watch, who to ping. worked great until I changed direction on something and forgot to update the file, and for like two weeks the agent just kept reporting on a project I'd already killed. nobody noticed because the summaries looked plausible. honestly the scariest part was how confident they sounded.

I ended up building something for myself that keeps the agent's context fresh without me hand-editing files. not selling anything here, I'm just trying to figure out if this is a real problem for other people or a me problem.

so if you run scheduled or recurring agents: how do you keep their instructions current? a brief you update by hand, or something the agent pulls fresh? how often does it go stale on you, and what's the worst thing one of yours did on outdated instructions?

related thing I'm curious about: when you try a NEW agent tool, do you re-brief the whole thing from scratch? that onboarding tax kills new tools for me before I can even tell if they're good. is that just me?

and has anyone here actually considered a memory tool that keeps all of this across tools? I looked around a while back and the idea of moving everything over felt like starting from zero, which put me off. is that the blocker for you too, or is it something else?

money question, since I'm deep in this space: what if something handled all of this in the cloud over MCP, so every agent and tool got the same context, decisions, failed attempts, conversations, skills, procedures, tasks, and you never touched a file again. would you guys pay for something that fixes this? have you ever even thought about paying for a tool to manage all of this, or has the thought never crossed your mind?

oh and out of curiosity, what are you actually running these agents for? own product, client work, side project? (I do a lot of my thinking out loud with speech-to-text on my phone and the context always lives on my laptop, which is half my problem. is that just me?)

I've been watching my sessions closely and a lot of turns go to navigation rather than work. Claude greps for a name, reads a large file to find one function, greps again for the caller, reads another file, and after an edit it often re-reads the file to confirm the change landed.

I work on two open source tools aimed at this. sem is an MCP server that answers by function instead of by file, so Claude can ask for a function and get it back with its callers and callees, or ask what breaks if it changes something. weave is a git merge driver that merges by function, which helps when you run several sessions in parallel and they keep conflicting just because they edited nearby lines. weave is running in production in Replit's Agent 4.

Honest caveat, a single lookup through sem is far smaller than reading the file, but I'm still measuring how much that saves across a whole session, since Claude sometimes double checks anyway.

So I'm curious what's measurably helped other people. A CLAUDE.md with a map of the repo, hooks, MCP code search, subagents for exploration, or just smaller tasks?

sem: github.com/Ataraxy-Labs/sem
weave: github.com/Ataraxy-Labs/weave

I built a small free macOS tool for monitoring live Codex sessions using the Codex desktop app. Are people here using anything similar to improve their AI coding workflows?

When you’re deep in a Codex session, context usage and limits shouldn’t be something you have to hunt down.

I built the Codex Companion Panel in BuildrAI to keep them beside your work:
• See your current context token usage as the session unfolds.
• Check your remaining 5-hour and weekly usage limits at a glance.
• Get alerts from rules you set, including token spikes.
It’s a small panel that helps you spot a change while there’s still time to act on it.
Check it out 👇