Back

Managing AI Agent Context With Simple Skills

Why I save my coding sessions around 150–200K tokens instead of filling a massive context window.

Modern AI models keep getting bigger context windows.

100K. 200K. Some models now support 1 million tokens.

At first, this sounds great for coding agents. Just keep the same session alive, put everything into the context, and the agent will remember what happened.

But I started doing almost the opposite.

When my coding session reaches around 150–200K tokens, I usually save the important state, kill the session, and start fresh.

To make this workflow practical, I built two simple agent skills:

  • session-saver
  • session-loader

They are probably two of the simplest skills I use, but they have become very useful in my daily workflow.

AI Agent Context Window

A bigger context window doesn’t mean I should fill it

I have been reading discussions on Reddit and watching videos about long context windows.

One thing that keeps coming up is context rot.

A model may support a 1-million-token context window, but that doesn’t mean it works equally well across the whole window.

As the context grows, useful information can get buried among old conversations, tool outputs, failed attempts, logs, and other details.

The model has more information available, but finding and using the right information can become harder.

There is also the practical cost.

A long coding session can contain a lot of stuff:

  • file reads
  • tool calls
  • command outputs
  • debugging attempts
  • temporary ideas
  • errors
  • repeated explanations
  • things that are no longer relevant

Even if the model can technically accept all of it, I started asking myself:

Do I actually need all of this context?

For my workflow, the answer is usually no.

I don’t need the conversation. I need the state.

Imagine I spend a few hours working with an agent on a feature.

During that session, maybe we:

  • explore the existing code
  • discuss several possible implementations
  • choose one approach
  • modify five files
  • discover that one idea doesn’t work
  • hit one blocker
  • decide what to do next

The full conversation might be huge.

But if I stop working and continue tomorrow, I don’t really need every message from yesterday.

I mostly need to know:

  • What are we working on?
  • What did we decide?
  • What changed?
  • What did we already try?
  • What is still broken?
  • What should we do next?

That is a much smaller amount of information.

This changed how I think about context.

Instead of asking:

How much context can I keep?

I started asking:

How little context do I need to continue?

That eventually became session-saver.

session-saver: keep what matters

session-saver is a small agent skill that tells the agent to create a checkpoint of the current work.

It doesn’t try to save the whole conversation.

Instead, it extracts the useful state and saves it into a Markdown file under .sessions/.

Something like:

.sessions/
└── 2026-07-27-auth-refactor.md

The saved session contains things like:

Status
Objectives
Decisions & architecture
Changes
Tried & ruled out
Open questions / blockers
Next steps

The goal is not completeness.

The goal is fast reload.

Two sections are especially useful for me.

Decisions

A fresh agent can inspect the code and understand what exists.

But it doesn’t always know why the code looks that way.

Maybe yesterday we considered three approaches and intentionally chose the second one.

That decision can be difficult to recover just by reading the repository.

So I want to preserve it.

Tried and ruled out

This one is even more useful than I expected.

Without previous session context, a fresh agent can suggest something I already tried yesterday.

Then I have to say:

We already tried that. It didn’t work because…

That is wasted time.

Saving failed approaches gives the next session a small amount of negative knowledge:

Don’t go down this road again. We already know what happens.

My 150–200K rule

I don’t wait until the model tells me the context window is full.

In my normal workflow, I usually use session-saver when the session reaches around 150–200K tokens.

There is nothing scientific about this number.

I didn’t benchmark 150K against 300K and discover some magic cutoff.

It is simply my practical rule.

When the context gets around that size, I prefer to checkpoint the important state and start fresh rather than continue growing the same session.

So even when I’m using a model with a much larger context window, I may never get close to its maximum.

My workflow looks roughly like this:

Work normally
     │
     ▼
Context grows
     │
     ▼
~150–200K tokens
     │
     ▼
Save important state
     │
     ▼
Close session

Now I have a small Markdown file containing what I actually care about.

But saving the state only solves half of the problem.

I still need a good way to continue from it.

session-loader: start fresh without starting over

This is why I built the second skill: session-loader.

When I open a fresh coding session, I can load the previous session state.

For example, the project might contain:

.sessions/
├── 2026-07-25-auth-refactor.md
├── 2026-07-26-api-cleanup.md
└── 2026-07-27-dashboard.md

Instead of explaining everything again, I can tell the agent to continue from the previous session.

The loader finds the relevant session file and restores the useful context.

Now the agent knows the objectives, previous decisions, changes, failed attempts, blockers, and next steps.

So instead of this:

Me: Yesterday we were working on the auth system.

We changed these files...

Then we tried this approach...

It didn't work because...

So we decided to...

The next thing we wanted to do was...

I can basically do this:

Me: Continue where we left off.

That is the part I like most about this workflow.

I get a fresh context window without completely losing yesterday’s work.

But the saved session is not the source of truth

There is one important rule in session-loader:

If the saved session and the current code disagree, the code wins.

The session file is only a snapshot.

A lot can happen after I save it.

I might manually edit the code.

Another agent might change something.

A collaborator might push new commits.

Or the session summary itself might miss something.

So the loader shouldn’t blindly assume that everything in the Markdown file is still true.

It uses the saved session to understand the previous state, but it still checks that state against the current project.

I think this distinction is important.

The session file is memory.

The repository is reality.

The complete loop

Together, these two small skills create a simple loop:

Start fresh session
        │
        ▼
Load previous state
        │
        ▼
Work normally
        │
        ▼
Context grows
        │
        ▼
~150–200K
        │
        ▼
Save session
        │
        ▼
Close it
        │
        ▼
Next session
        │
        ▼
Load previous state

I don’t have to treat one AI conversation as something that needs to live forever. That idea is also central to my workflow for turning AI conversations into plans and GitHub Issues.

The session becomes disposable.

The useful project context doesn’t.

Why just Markdown?

There are much more advanced ways to build memory for AI agents.

Vector databases.

Embeddings.

External memory services.

Automatic retrieval systems.

I didn’t need any of that.

My implementation is basically:

.sessions/*.md

And I actually like that.

I can open the file myself.

I can edit it.

I can delete old sessions.

I can search them with normal tools.

Git can track them if I want it to.

And almost any coding agent can understand Markdown.

There isn’t much magic involved.

The agent saves a compressed version of its working state, and another agent reads it later.

That’s enough for my workflow.

More context isn’t always better context

This experiment changed how I think about large context windows.

I still think large context windows are useful.

There are tasks where being able to give the model a huge amount of information is extremely valuable.

But I no longer see the context-window number as something I should try to fill.

A 1-million-token context window tells me that the model can accept a huge amount of context.

It doesn’t mean my coding session becomes better if I keep feeding it everything until I reach that limit.

For long-running coding work, I care more about the quality of the context than the amount of it.

There is a big difference between:

200K tokens of conversation history

and:

a small summary of
decisions
changes
failed attempts
blockers
next steps

The first one contains more information.

The second one may contain more of the information I actually need.

Simple skills, but I use them a lot

session-saver and session-loader aren’t sophisticated agent memory systems.

They are just two small skills built around a simple idea:

Save the state, not the whole conversation.

Once my context reaches around 150–200K tokens, I can checkpoint the useful parts and start again with a clean session.

Then session-loader gives the new session enough information to continue without making me explain everything again.

I’m not trying to make my agent remember everything.

I’m trying to make sure it remembers the right things. It is the same lightweight approach I take when customizing Pi’s system prompt: keep the useful context available without loading everything by default.

Get the skills

Further reading

ai-coding-agentscontext-managementagent-skillsdeveloper-tools
Back to all posts