I did not sit down to invent a framework.
I was trying to build real software with coding agents, and after a while the same problem kept showing up: the work was bigger than the session.
That was the actual issue.
Not “which model is smartest.”
Not “which IDE has the best agent.”
Not even “does RAG help.”
The issue was continuity.
A feature would start in one session, continue in another, get interrupted by limits, get resumed in a different tool, and somewhere in the middle I would end up re-explaining the same things again:
That gets exhausting fast.
And it is not just annoying. It affects quality. Every restart adds noise. Every new session risks drift. Every agent handoff creates room for stupid mistakes that have nothing to do with intelligence and everything to do with lost continuity.
At some point I realized I was relying too much on the chat thread to be the memory.
That was the mistake.
I started putting feature trackers in the project root.
Not motivational docs. Not vague notes. Real trackers.
What is the current feature?
What is completed?
What is pending?
What is parked?
What was verified?
What decisions were already made?
That helped immediately.
A fresh session no longer had to guess the active boundary from code alone.
Then I hit the next problem: even when the feature state was clear, the agents would still repeat behavioral mistakes.
Things like:
So I started externalizing that too.
I wrote down the recurring rules. Scope rules. Verification rules. Reuse rules. Repo-boundary rules. The practical stuff that normally lives in your head until you are forced to repeat it for the fifth time.
Then later I added retrieval for some of that memory, because not everything needs to be in the always-loaded layer, but some things absolutely should be recoverable when the work reaches the right point.
Somewhere in there the whole workflow changed shape.
It stopped being “chat remembers context.”
It became “project holds continuity.”
The shortest version is this:
The project remembers, not the agent.
That is what I started calling ATMAR: Agentic Tracker Memory And Retrieval.
And to be clear, I am not claiming I invented memory, trackers, or retrieval.
That would be nonsense.
What I am saying is that under real delivery pressure, I ended up combining them in a way that made interrupted multi-agent work much more survivable.
The core pieces are simple:
Each part already exists in some form.
But the combination mattered more than I expected.
A lot of discussion around coding agents still feels too chat-centric.
People ask:
Those questions are fine. I use those tools too.
But I think there is a more basic software-engineering question sitting underneath all of that:
What happens when the work outlives the session?
Because that is normal. That is not some edge case. Real software work is messy, long, interrupted, and spread across time.
So if continuity depends mainly on the current thread being alive, then the workflow is fragile by design.
That is the part I wanted to fix.
I am not claiming:
I am claiming:
Someone will probably say: “this is just disciplined workflow.”
Fine.
Maybe it is.
But that is not a dismissal unless the discipline does nothing.
The real question is whether this kind of discipline creates a stronger continuity layer for long-horizon AI-assisted software development.
That is testable.
Because unnamed patterns disappear.
If you do not name something, people either ignore it, or they copy pieces of it without any shared language for what actually made it useful. I wanted this to be inspectable.
Not glorified. Inspectable.
If it has a name, then people can do something more useful than vague agreement or vague dismissal. They can compare it.
For example:
That is where I think the discussion should be.
The weak point is obvious.
I have strong operational evidence and real artifact evidence. I do not yet have clean comparative proof.
So I am not pretending the argument is finished.
That is why I published ATMAR as a case-study and evaluation artifact, not as some inflated “future of engineering” pitch.
I would rather have people test it and tell me where it breaks.
Try it on one feature. Not your entire company.
Not a six-month transformation plan.
One feature.
Set up:
Then resume the feature from a fresh session or another agent.
See what happens.
Did the restart get easier?
Did the agent stay in scope better?
Did handoff improve?
Did you repeat yourself less?
Or was the maintenance overhead not worth it?
That is the kind of feedback I want.
I put the repo here:
https://github.com/revdfdev/ATMAR
If you test it, I would genuinely rather get a sharp criticism backed by a real attempt than polite praise. That would be more useful.
Maybe this ends up being a niche but solid method.
Maybe it becomes a useful reference point for long-horizon agent continuity.
Maybe people copy the pattern and improve it.
All of that is fine.
The key thing for me is simpler than the branding:
once I stopped depending on the agent to be the memory layer, the work became much less fragile.
That is the point.