Have your agent maintain a task journal. It is like a more detailed commit history, that includes tribal knowledge gained during the task and additional context, eg.
X is incorrect but we cannot change it due to some other service depending
on it, don't use Y as it is deprecated in favor of Z.
Describe the current project or larger task in progress, then give a
breakdown of all the planned sub-tasks with status, explain any learnings,
then note what work is remaining. Write this in a file called HANDOFF.md
Ask AI to record in a projects directory memory: LOG.md, HANDOFF.md, DECISIONS.md, a plan folder. Reference code with absolute paths. Keep repeatable processes in skills. Version control it all, and use a dreaming process across multiple sessions to stop repeat mistakes.
That's what's worked for me, but there's many variations of this.
For big tasks/features, I'm always creating a new git worktree and I'm using a "status repo" skill that creates a sibling status git repository where everything is recorded.
It works quite well whenever I have to revisit something. It's quite token hungry but I have the full trace of what happened in the past.
https://gist.github.com/vkalintiris/3ad526e71a75bcba013aaadc....
Another approach I want to explore is using https://github.com/netdata/netdata (disclaimer, I work at Netdata) to send all OTel logs/traces of LLMs to it. The idea is to replace the status repo skill with something that will allow LLMs to retrieve the history of a given task/feature. It will probably require some "checkpointing" to make this more efficient.
> Try to keep context shoved in a conversation thread under a token limit to save tokens.
That is another solid tip. If using subagents, use the main thread for only the conversation + launching subagents. Tell it explicitly not to implement anything, and only support integration efforts.
Doing so keeps the worker subagent's context clean - so it can stay laser focused on the task.
The context should be self-evident from the code alone, and if it is not, it should be in your head and you should write it down again so that you do not forget it yourself.
Being forced to re-explain stuff to the LLM is good, actually, as that way, one actually thinks about the architecture, choices and limitations.
I've been iterating on this approach for about a year—it makes switching between agents and harnesses trivial.