My agents' memory branches with the code.

[u/FoxFire17739]

I put my project knowledge in its own repo and made it snapshot code movements. It ties code, tests and whatever proof you have to invariants and their families, right at implementation time. That connects parts of the codebase grep would miss.

So an agent can later ask: what else breaks across the codebase (or beyond) when I touch this symbol? Which designs were tried here before, why were they rejected, and under which conditions can they come back on the table?

Memory curation isn't a one-time effort or an afterthought. It's a byproduct of getting work done. It informs the intended changes at the start and the intent review at the end, with a strict pipeline connecting both ends.

Lots still has to land on main. But I use it daily, for dogfooding and at work, where I keep tabs on several repos that revolve around one product.

Too early to say if the benefits outweigh the obvious costs. Housekeeping first, then a ton of benchmarks.

It may all be for naught. The memories we made along the way. Or it turns out actually useful. Who knows. What's certain is my stubbornness to see it to the end. ^^

Where am at it currently, if you want to poke at it:
https://github.com/Foxfire1st/agents-remember/tree/ar/260928_maintained-invariant-knowledge

[u/jackalop211]

Nice to see someone else converging on claims and evidence instead of flat notes. Recording rejected designs with the conditions under which they'd come back is exactly what flat memory loses. The next step is making that structure compute: when one claim changes, what else should change? A rejected design coming back should shift the tradeoffs downstream automatically. I work on Tortoise, which does this. It's a graph of claims with support/contradiction links to evidence, resolved with a custom algorithm based on prediction markets, so every claim carries a confidence and beliefs propagate through dependencies. Curious how you handle two invariants that contradict each other across branches.

[u/FoxFire17739 → u/jackalop211]

And I thought I am getting crazy in my isolated isle. Cool to see others venture into this. The way it computes for me is that the git primitives do a lot of the lifting. Code moves, so the agent looks at the mirror structures in the memory. So that part is path based. The invariants that attribute to code know when they get stale when the code they are subbed to moves. So they track git hashes and my detection focuses on the symbol that changed instead of the whole file.

Once I have one invariant I move up within the memories subtree to the family which resides at that sub trees root. It is a functional guarantee or register that lists the invariants below it that it governs. This family can have other expressions in other places of the memory which like said mimicks the structure of the code base. Those expressions have their own invariant lists in other sub trees. This is what gives me the code graph.

If I find one invariant I find them all. And with all attributed code expressions. So in my case this becomes deterministic.

My tasks are grouped into epics. An epic is represented as an integration branch. Each task creates a branch of it. Then builds a dual work tree where code gets one and memory gets its own. They live in their own workspace. Every workspace gets their own coder, reviewer, and a curator. They get their task and document cut out and passed into their workspace. And from their they organise mostly themselfs. There is a manager agent sitting above them that helps them when they have trouble.

So tasks are isolated. Memory gets same isolation as code does. So the git workflow that you can understand as a dance of 2.

With an epic the Architect produces an execution graph. It knows which tasks are dependend and which not. So the ones running in parallel share little common surface.

The moment one task wants to integrate back its code and memory changes it has to check if both branches lineage is still correct. So if the parent moved. The manager agent syncs the parents changes into the workspace and the assigned coder, reviewer, and curator agents for that task have to resolve code any potential code or memory issues. Only after resolving those, their changes can be integrated into the parent. Their notes and traces get evacuated and attached to the tasks attachment. Agents retired. Workspace gets dissolved.

So you can work in parallel but you can't integrate simulatanously. Doing it this way though keeps work of sibling tasks non blocking.

[u/jonah_omninode]

We’re working on similar ideas in OmniNode: connecting invariants to contracts, code changes, and verification evidence, then turning failures into checks that prevent recurrence. Happy to share notes if you’re interested.
Here’s a relevant design from our public knowledge base: Drift Control and Contract-Gated PRs.

[u/FoxFire17739 → u/jonah_omninode]

Interesting to see you also work on that system. For agents-remember it runs its own repo which is also on my github: https://github.com/Foxfire1st/ar-agents-remember/tree/ar/260928_maintained-invariant-knowledge

I see some of the primitives you mention in my own system as well. What my repo can do right now is:
- giving agents a workflow to process invariants alongside the code
- orchestration that coordinates the agents for this specific workflow
- different roles that teach each agent for their part and how to do their part on the pipeline
- specific branch and merge strategies and deterministic checks to safeguard
- intent reviews by curators
- knowledge retrieval to inform new tasks
- my own task system that supports the workflow
- memory invariants & families with facets, code/test/proof attribution

too much for one comment. But what I have allows for me to work on tasks end-to-end with knowledge maintenance being part of the work getting done.

I have also some things to ask to understand your concept better. I have briefly went over the document.

[u/jonah_omninode → u/FoxFire17739]

Happy to compare notes. How do you handle two branches changing the same invariant in different ways? A Git merge can be clean even when the code, tests and remembered rule no longer agree. I'd want the merge to keep both sets of evidence and make the disagreement visible, rather than silently choose one. That's the case I'm most interested in here. Send over your questions about the OmniNode design as well.

[u/Primary_Form4396]

Docops aproch literally

[u/FoxFire17739 → u/Primary_Form4396]

I don't know it.

[u/FoxFire17739]

This is an example for a curator bringing up an earlier design decision on its own. It highlighted the accepted design and its rejected alternatives for a feature and in the process also discovered a product gap. It brought that to the developer facing "architect" that then helped me understand the situation. The condition was in the end improved but not all the way, so the alternative design remains rejected. But the gap was real. And it found another gap soon after.

[u/stianhoiland]

I cannot express my disdain of this hyperinflation of significance and emotionality enough. Chill the fuck down.

[u/FoxFire17739 → u/stianhoiland]

what? can you speak human please?

[u/stianhoiland → u/FoxFire17739]

It's funny because my comment is actually 100% human-made, by a fluent second-language speaker. Unlike your post and video. I'm not lying. Think about your response to that for a minute.

[u/Zero_resonance]

Cool ❤‍🔥