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:
- what the feature actually is
- what is already done
- what is not done
- what is intentionally parked
- what rules matter in this repo
- what not to touch casually
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.
What I changed
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:
- wandering into adjacent cleanup
- ignoring existing repo patterns
- jumping into code too early
- needing the same correction more than once
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.”
That is the real idea
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:
- tracker memory for feature state
- behavioral memory for recurring rules
- retrieval memory for recoverable context
- repo-grounded verification so memory never outranks code
Each part already exists in some form.
But the combination mattered more than I expected.
Why I think this is worth looking at
A lot of discussion around coding agents still feels too chat-centric.
People ask:
- which model is better
- how much context can fit
- which agent is best at coding
- whether one prompt style beats another
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.
What I am claiming, and what I am not
I am not claiming:
- a new model architecture
- a new retrieval algorithm
- a universal proof that this beats every workflow
- some dramatic AI breakthrough
I am claiming:
- this solved a real problem for me
- it emerged while doing substantial actual software work
- it made agent switching less destructive
- it reduced how often I had to reconstruct the same context from scratch
- it is worth testing as a method, not just as a personal habit
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.
Why I gave it a name
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:
- repo only
- repo plus spec
- repo plus tracker
- repo plus tracker plus rules
- full tracker plus rules plus retrieval workflow
That is where I think the discussion should be.
Where it is weak
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.
If you want to try it
Try it on one feature.
Not your entire company.
Not a six-month transformation plan.
One feature.
Set up:
- a tracker
- a behavior-rules file
- a runtime memory layer
- one explicit rule that the repository outranks memory when they conflict
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.
