How I use memory with agents

Nick Shatilo on the shortcuts, saved preferences, visual plans, and working conventions he uses to avoid explaining the same things to agents every time.

I use memory quite a lot, mostly to avoid explaining the same things every time I start a chat. Over time, I've saved how I want recurring tasks handled, which skills I use, and the preferences that affect the suggestions I get.

Some examples of what I actually use it for:

  • Shortcuts for things I do often. I can say "babysit this PR" and the agent has the process saved. Which review pipeline to run, how to handle findings, what checks need to pass, and what to do when something fails.

    There's quite a bit behind that request. For example, I want worktree hooks paused during the review loop so they don't trigger competing work, then restored afterward. I also want the actual review submitted through the repository's workflow. Having that written down means I don't need to include the whole procedure every time.

    You could do the same with a weekly report or a regular investigation. Work out the process, save what you mean by it, and use a short request next time.

    A short request, Babysit this PR, retrieves a saved workflow: review, fix, verify, and ready for merge. Merging requires separate authorization.

  • Picking up things from other chats. If we figured something out in one session and saved it, another session can use it. That might be a decision about the implementation, the location of unfinished work, or an approach we already tried and rejected.

    This doesn't mean every session knows what all the others are doing in parallel. It's saved context, and it can get outdated. But it gives the next session somewhere to start. I can ask it to check what we already know instead of reconstructing the whole conversation myself.

    I find this useful when I switch between tasks. I want to come back to a problem and continue from the decisions we made.

    Chat A saves a useful note in personal or workspace memory. Chat B retrieves relevant saved context. This is not a live view of other chats.

  • Visual plans and investigations. When I ask for a plan, I like getting a proper HTML artifact I can open in a browser. Show me how things work today, what we're changing, how the proposed approach would work, and the caveats. Add diagrams where they help explain it.

    I want enough context that I can read the document without remembering every detail from the chat. Then I can look through the options and decide what we're going to build.

    I've saved that preference, so I don't have to keep adding instructions about the format. I can focus my request on what I want investigated.

  • Applying skills by default. For example, I use unslop for writing. It removes a lot of the phrasing that makes AI text sound generic or unnecessarily promotional.

    I can tell the agent to remember that I want the skill applied to my writing. The skill contains the editing instructions; memory records my preference to use it.

    It still needs to actually load and follow the skill. Saving the preference doesn't guarantee every draft gets it right, as the revisions to this post show. But I want that preference available in the next chat instead of having to introduce it again.

  • Remembering how we do things. Every PR needs a Linear ticket. Use the right base branch for the repository. Don't post progress comments on my tickets unless I ask. Don't add code comments that just repeat what the code says.

    These are small conventions, but they come up constantly. I'd rather have the agent account for them while doing the work than correct the result afterward.

    The scope matters too. A branch rule belongs to a particular repository. My preference about ticket comments applies more broadly. When a rule changes, I want the saved version updated so the old one doesn't keep coming back.

  • Knowing my preferences. I prefer concise responses. I also prefer considering a substantive architectural change when the underlying design is causing the problem.

    That affects which solutions I want the agent to suggest. I don't want it to assume that the smallest patch is always my preferred option. If we're adding another workaround around the same design problem, I'd like it to point that out and explain what fixing the design would involve.

    Sometimes the small fix is still the right choice. I want the tradeoff explained with my preferences in mind, so we can make the decision without repeating that discussion from scratch.

When I notice I'm repeating an instruction, I ask the agent to remember it. I'm fairly specific about what should happen and where the preference applies. "For this repository, do this" is more useful than a vague "always do better."

And when it gets something wrong, I want to check the saved memory too. Sometimes the preference is missing. Sometimes it's outdated. Sometimes the agent just didn't follow it. Those need different fixes.

Cookie preferences

Choose whether to allow marketing tracking and session recordings. Essential features, performance monitoring, and first-party attribution stay on. Privacy policy