Skills vs memory

My agent knows that I prefer project updates in a shared topic rather than a private message.

That is memory. It is a fact about how I work. If I change my mind, I should be able to correct it in one sentence.

The same agent can also restart our production services. On our team, that happens through the deployment dashboard, never by opening a terminal on the server and running the command by hand. That may look like another preference. It is not. It is a procedure with a reason, a safe path, and consequences when ignored.

That belongs in a skill.

The distinction sounds tidy when written down. In practice, both can make an agent look experienced. A remembered note can steer behavior. A skill can carry context. Soon the memory contains little operating rules, the skill contains personal facts, and nobody knows which one to edit when the agent does the wrong thing.

There are two reasonable instincts behind the mess.

One says the agent should learn the person. Stop making me repeat how I work, what I care about, and which defaults I have already rejected.

The other says important behavior should never depend on what the agent happened to remember. Put the procedure in a file, version it, test it, and load it when the work calls for it.

I want both. I just do not want them doing each other's job.

A persistent assistant without memory is a new contractor arriving every morning with no notes.

It can still be capable. It may know the domain, use the tools, and produce good work. But it makes the relationship expensive. I have to restate that updates belong in the project thread, that some work needs a concise report, and that a familiar name refers to the same ongoing project we discussed yesterday.

Memory removes that tax.

Its best material is compact and declarative: who a person is, what a name refers to, which preference is stable, what decision was made, and which constraint remains true across sessions. These facts make an agent personal without prescribing every move it should make next.

Memory also handles change better than a hard-coded workflow when the fact itself is fluid. If I decide that a project has moved to a different channel, I should correct the destination. I should not have to release a new version of a publishing procedure just to update one preference.

But memory has a seductive failure mode. A sentence can influence behavior, so every correction starts to look like something worth remembering.

"Do not do that again" becomes a durable note. Then another. Six weeks later, the agent is carrying a pile of prose that mixes preferences, warnings, exceptions, and half-obsolete policies. The behavior works until retrieval misses the relevant line, two notes disagree, or the old exception outranks the new rule.

The agent did not forget in the human sense. We stored a procedure in a place with no procedural guarantees.

Keeping procedure out of memory does not make memory harmless.

A recent paper, Memory as Infrastructure, reports on one months-long development project whose memory subsystem was instrumented continuously. Its central argument is useful: persistent memory needs the same reliability engineering as any other production system. That means a health check at session start that distinguishes between failure modes, and telemetry designed so that no known failure can pass unrecorded.

The record backs the argument in an instructive way. The author logged 85 memory failures, none of them silent, and 84 of them happened in the first three weeks. Failures were not rare. They were visible, so they could be fixed.

The paper also states its limits: one self-reported project, no control arm. I would not treat its numbers as a general benchmark. I would keep the operational lesson.

A memory system without that kind of instrumentation can fail silently. The agent may retrieve stale information, miss a relevant fact, or present an old decision as current. That means memory needs provenance and correction, not just more storage.

For facts that can expire, record when they were learned and where they came from. For decisions, retain the replacement rather than leaving two conflicting notes. For preferences, make correction cheap. If memory is unavailable, say so instead of pretending the agent has continuity.

The goal is not maximum recall. It is memory I can inspect, correct, and distrust for good reasons.

A skill makes behavior inspectable.

Anthropic describes Agent Skills as folders of instructions, scripts, and resources that an agent discovers and loads for a task. The design uses progressive disclosure: lightweight metadata helps select the skill, then the agent reads the fuller instructions only when needed. That keeps a procedure available without forcing every detail into every conversation. Since late 2025 the format is also an open standard, so a skill is not locked to one vendor's agent.

This is a better home for repeatable work. A deployment skill can name the approved control plane, the checks to run, the actions that need approval, and the evidence required before claiming success. A review skill can include a script instead of asking the model to remember a regex. A failure can become a changed instruction or a deterministic check.

OpenAI's guidance on skill evaluation makes that last point concrete. Capture the run, inspect its trace and artifacts, and score behavior with targeted checks. Every manual fix is a candidate for an eval. The goal is not a perfect document. It is a procedure whose behavior can improve without quietly regressing somewhere else.

Skills have their own pathology.

A procedure can become a fossil. Teams keep adding branches until a short operating guide turns into a history of every incident. The agent follows a five-month-old workaround because the skill says so, even though the tool changed last Tuesday. Or the author tries to encode judgment that cannot survive outside its original situation.

Skills are not automatically current because they are files. They need owners, version control, tests, and deletion.

There is another cost. A skill can be too rigid for personal work. If every preference becomes a workflow step, changing your mind requires editing operational logic. The agent stops adapting to you and starts complying with a bureaucracy built from your old choices.

Memory should absorb correction easily. Skills should resist accidental change. That difference is useful.

The simplest boundary I know is to ask what kind of edit should fix the mistake.

If the agent sends me an update privately and I say, "Use the shared project topic from now on," a memory update is enough. The error concerns me and my current preference.

If the agent restarts a production service from a terminal on the server instead of through the deployment dashboard, a remembered warning is not enough. The procedure should specify the source of truth, allowed actions, verification, and escalation. The fix belongs in the skill, with a test if the behavior can be checked.

The same rule works beyond those examples.

"The customer now calls this project Northstar" is memory.

"Before migrating Northstar, verify the blackout window and require owner approval" is a skill or workflow contract.

"I prefer short progress reports" is memory.

"A security review must include dependency scanning and authorization tests" is a skill.

A useful shorthand is this: memory describes the world and the person. Skills govern repeatable action.

There is a second axis hiding in those examples: who the rule belongs to. Memory is usually about one person. Skills are usually shared by a team. "I prefer short reports" is mine, and I can change it whenever I like. "Deployments need owner approval" belongs to the team, and no single conversation should be able to rewrite it. When the fact-or-procedure question is ambiguous, the ownership question often settles it.

There will be overlap. A skill needs enough context to do its job, and a memory can affect which skill is chosen. The boundary is not about keeping the files pure. It is about knowing where authority lives.

When memory and a skill disagree, the skill should win for the procedure it owns. Otherwise an old personal note can silently override a reviewed operating rule. Memory may select parameters or raise a conflict. It should not rewrite the procedure in flight.

Before adding another remembered instruction or another skill file, I would ask:

Here is a case where they earn their keep: "Never deploy on Fridays."

It sounds like a preference. Run it through the questions and the answer depends on whose rule it is.

If it is my personal habit, because I want my weekends free, one correction should change it, a miss is merely annoying, and I own it. That is memory. The agent can remind me before I schedule something, and I can override it.

If the team adopted it after a bad weekend incident, a miss is unsafe, the behavior is testable by checking the date before the deploy step, and the team owns it. That is a gate in the deployment skill.

Same sentence, two homes. The wording did not decide. Ownership and consequences did.

In short: identity, preferences, names, and decisions go in memory, kept small and easy to correct. Steps, tool rules, approval gates, and stop conditions go in skills, versioned and tested.

The boundary is not fixed for a given rule. Things migrate.

The clearest signal is repetition. If I have corrected the agent the same way three times, the correction has stopped being a preference. It is a procedure asking for a file. At that point the honest move is to promote it: write it as a step in a skill, add a check if one is possible, and delete the memory notes that were standing in for it.

Promotion also cleans up memory. Each note that becomes a skill step is one fewer piece of prose that retrieval can miss or contradict.

Anthropic points in the same direction when it describes a future where agents create, edit, and evaluate skills on their own, turning their own patterns of behavior into reusable capabilities. I would want a person to review that promotion before it ships. But the direction is right: memory is where a pattern gets noticed, and a skill is where it gets made reliable.

I like the small magic of an agent remembering where I want an update sent. It feels attentive. More than I want to admit, that feeling makes me trust remembered behavior before it has earned the trust.

That is exactly why the boundary matters.

Personalization should feel light. Procedure should feel deliberate. When I confuse them, I get the worst combination: behavior that looks personal, carries operational consequences, and has no clear place to review or fix it.

Memory should make an agent more personal, not more mysterious.

The next article takes on Parallelism vs Coherence: when do more agents reduce elapsed time, and when do they merely multiply the cost of making the answers agree?