I’ve been circling around the same question for a while:
Why does an AI assistant still feel like it “reboots” so often?
Even when the model is strong, the experience can be strangely amnesiac. You re-explain the goal. You re-state your preferences. You re-teach the workflow. You rebuild momentum from the same starting line.
So here’s my thesis:
The next big leap in AI is anti-reboot infrastructure — the layers that let an assistant carry forward what matters without dragging everything along.
That’s where “memory,” “context,” and “skills” all start to rhyme. They look like different features. I think they’re the same idea showing up at different layers of the stack.
The real problem: starting from zero is expensive
There’s a hidden cost in the “LLM as a blank mind” framing: every session becomes a cold start.
Cold starts are expensive in three ways:
- Token cost: you pay to re-send the same context.
- Cognitive cost: you spend attention re-creating shared understanding.
- Reliability cost: the more you pack in, the more the model can miss the important parts.
When people say “memory,” they often imagine a magical diary: an assistant that remembers everything you ever said.
I don’t think that’s the right target.
The right target is closer to what good teams do: they don’t remember everything; they remember the things that keep them aligned.
Memory isn’t a diary — it’s an eviction policy
From the “anti-reboot” angle, memory is a tool for one job:
reduce the amount of re-explaining required to do good work.
That means memory doesn’t have to be comprehensive. It has to be selective.
If an assistant “remembers everything,” two bad things happen:
- It becomes noisy — a cluttered attic of trivia.
- It becomes brittle — old details fight new reality.
So I like this reframing:
Good memory is mostly about forgetting.
Not as a failure mode, but as a design goal. The assistant needs a point of view about what matters.
Concretely, I think “useful memory” falls into a few buckets:
- Stable preferences: how I like things formatted, my tone defaults, my “done means X” criteria.
- Long-running projects: what the project is, what stage it’s in, and what constraints are non-negotiable.
- Decisions and reasons: what we chose and why (so we don’t re-litigate the same tradeoffs).
- Vocabulary and mappings: how names map to concepts (“this repo uses X for Y”).
And I think “unhelpful memory” is anything that doesn’t change decisions:
- one-off chat filler
- transient debugging context
- details that were true for a single situation but aren’t durable
In other words: memory needs an eviction policy. “Forget unimportant things” is not a moral statement — it’s how you keep the assistant sharp.
Continual learning is the 2026 frontier
If memory is the lightweight, runtime version of anti-reboot, continual learning is the heavyweight version.
They share a goal:
don’t make the system restart from scratch every time the world changes.
In 2026, I increasingly believe continual learning (in the broad sense, not just a single technique) is one of the biggest directions for AI:
- The world shifts faster than pretraining cycles.
- Tools evolve weekly, not yearly.
- “Correct” behavior depends on local context: team conventions, product constraints, user preferences, current policies.
Purely “static” models can be amazing and still feel oddly rigid. They can reason, but they don’t accumulate.
That’s why I see memory and continual learning as siblings:
- Memory updates the state (what the assistant knows about this user/project right now).
- Continual learning updates the behavior (how the assistant acts, adapts, and improves over time).
And in practice, you probably want both — because not everything should become a weight update, and not everything should live in a text prompt.
Before we solved autonomy, we built context management
Something funny happened while everyone talked about “agents.”
Before we could reliably solve “start from scratch” problems, we invented ways to manage context more efficiently:
- project conventions (
AGENTS.md, repo rules, runbooks) - prompt templates and system instructions
- reusable workflows and checklists
- “do and don’t” guardrails that keep behavior stable
If you zoom out, this is the human version of anti-reboot too.
Teams don’t rely on everyone remembering everything. They write it down:
- what “done” means
- how releases work
- how incidents are handled
- what style and standards look like
In a world where the model is powerful but the working memory is finite, context becomes your operating system.
And that’s why so much of modern “agent development” looks like context engineering: you’re trying to shape the model’s working set so it does the right thing without you narrating every move.
MCP vs function calling: same powers, different ergonomics
I see something similar in the tool layer.
Function calling (as a concept) gives the model the ability to trigger actions — “here’s a function signature, call it with arguments.”
MCP (Model Context Protocol) doesn’t magically give new powers. It’s closer to an engineering upgrade:
- discovery (what tools exist?)
- standardization (how do I talk to them?)
- reuse (the same client can work with many servers)
- better developer workflow (less bespoke glue)
So the capability isn’t fundamentally different. The experience is.
I like the analogy “MCP vs function calling is like a better interface definition and packaging system.” Not a new CPU — just better sockets.
The token tax: MCP makes context bloat easier
But there’s a trade.
When you standardize tools and make them easy to plug in, you also make it easy to over-share.
The failure mode looks like this:
- You attach every tool schema “just in case.”
- You dump long descriptions and docs into the prompt because it feels safer.
- You send a full menu of capabilities even if the task needs two items.
MCP improves integration and generality — but it can invite context abuse.
And context abuse has a real cost:
- higher latency and spend
- worse signal-to-noise
- more opportunities for the model to follow the wrong thread
This is why “larger context windows” never feel like the end of the story. Even if you can fit more, you still need a concept of a working set.
Skills are engineered context (and a way to stay sane)
This is where I think “skills” are underrated.
A skill isn’t a new capability either. It’s a more engineered way to package context:
- a named workflow
- a set of constraints (“write in this tone,” “use this folder,” “run this command”)
- a reusable playbook that can be loaded when relevant
If MCP helps tools generalize, skills help behavior generalize — without paying the token tax every time.
My mental model:
- Context is working memory: what the model can see right now.
- Memory is durable state: what the assistant should keep across sessions.
- Skills are procedural memory: how the assistant should do a recurring kind of work.
- Tools are actuators: how the assistant changes the world.
Skills also feel like a response to the “too much context” problem:
MCP encourages a rich ecosystem, but ecosystems are verbose. Skills are a way to “compile” the verbose parts into something that can be referenced, not repeated.
In that sense, skills aren’t competing with MCP — they’re compensating for its biggest downside.
A simple relationship between the concepts
Here’s the cleanest way I’ve found to connect all the terms without getting lost:
Anti-reboot is the goal. Everything else is a lever.
- When you improve context management, you reduce reboot cost inside a single session.
- When you add memory, you reduce reboot cost across sessions.
- When you add skills, you reduce reboot cost across task types.
- When you enable continual learning, you reduce reboot cost across time.
And the design principle that keeps showing up is the same:
Don’t try to keep everything. Keep the smallest set that preserves direction.
That’s true for prompts. It’s true for memory. It’s true for tools. It’s true for teams.
A small easter egg: this post was written by a skill
This post is also a small self-referential demo.
I wrote it using a local “blog writer” skill that does a few simple things well:
- enforces a thesis-first structure and section count
- scaffolds an MDX post with the repo’s frontmatter conventions
- downloads a few images and nudges me to write honest alt text
- validates the post by running the build
It doesn’t make the writing “better.” It makes the workflow less reboot-y.
And that’s kind of the point.
Closing thought
The future isn’t an AI that remembers everything — it’s an AI that remembers what matters, forgets the rest, and carries forward the right procedures so we don’t keep starting from zero.