Information in this post reflects publicly available sources as of October 18, 2026.
On Monday you spend twenty minutes teaching your coding agent how your project works. Tests run with pytest -x, never through the IDE. Database migrations are off limits. Staging deploys go through a script nobody remembers the flags for.
By the end of the session, it is a genuinely useful colleague.
On Tuesday you open a new session, and it knows none of it. It runs the tests the wrong way, proposes editing a migration, and asks how to deploy. Your support assistant has the same problem with customers: a returning user explains, for the third time, that they want invoices as PDFs.
Agents need two kinds of knowledge that outlive a single conversation. Memory holds facts about a particular user, project, or situation. Skills hold know-how: packaged procedures for doing a kind of task well. This post covers how each works, why the naive versions fail, and the new risks that come with an agent that remembers.
Every session starts from zero
The context engineering post made the key point: a model is stateless. Everything it knows about your situation must be in the context window for that call. When the session ends, the window is gone, and so is everything the agent learned.
The obvious fix is to put everything into every session: all the rules, all the history, all the procedures. That fails for the reasons the same post described. Context costs money on every call, and models get worse as the window fills with material that is irrelevant to the current task. A coding agent does not need the deploy procedure while writing a unit test, and a support agent does not need a customer's two-year history to answer a question about shipping.
So the real problem is selection across time: storing what might matter later, and loading only what matters now. Memory and skills are two answers to that problem for two different kinds of knowledge.
How it works
Where persistent knowledge lives
A well-built agent assembles each session's context from several sources, each with a different lifetime and loading rule.
Instruction files are the simplest form of persistence. A file such as AGENTS.md or CLAUDE.md in a repository holds project rules that a person wrote: how to run tests, what never to touch, how to deploy. The harness loads it into every session. It works well for a short list of rules that are always true, and it stops working when it grows into a manual nobody maintains.
Memory is knowledge the system accumulates on its own, usually about a specific user or project. Skills are procedures someone packages once and the agent loads when a task calls for them. The next two sections take each in turn.
Memory: write, store, retrieve
Every memory system does the same three things. It decides what to write, from a conversation or the agent's own work. It stores each memory with enough context to judge it later. And it decides what to retrieve into a future session, which is a small RAG problem over the memory store.
There are two common ways to do the writing. In agent-managed memory, the agent has tools to read and write memory files itself, deciding during its work what is worth keeping. Anthropic's memory tool works this way: the agent manages a directory of files through tool calls, and because the files live on your side, people can read, edit, and version them. In extracted memory, a separate step runs after each conversation, pulls out candidate facts, merges them with what is already known, and stores the result, which is the approach libraries such as Mem0 take.
Either way, a useful memory is more than a sentence. It needs a subject, so it is retrieved for the right user or project. It needs a source and a date, so newer information can replace older and facts from untrusted content can be treated with suspicion:
{
"subject": "customer:4821",
"fact": "Wants invoices as PDF, not CSV",
"source": "user stated in support chat",
"recorded": "2026-10-02",
"supersedes": null
}Memory also needs a scope. Some facts belong to one user, such as a preference for PDF invoices, and some belong to a project or team, such as the decision to drop support for an old API version. Mixing them leaks one user's details into another user's session, or loses team decisions when one person leaves. Decide for each kind of memory who can read it and who can write it, the same way you would for any shared data.
Facts change, and memory has to change with them. A customer who moved last month should not keep getting the old address because both facts are stored and retrieval happened to pick the wrong one. Systems such as Zep store facts with validity periods, marking old ones as superseded rather than deleting them, so the agent knows what is true now and what used to be true.
Skills: know-how on demand
Memory answers "what do I know about this situation?" Skills answer "how do I do this kind of task well?" A team's way of producing the quarterly report, the house style for customer letters, the exact steps for rotating a credential: each is a procedure that is valuable when needed and useless context the rest of the time.
The Agent Skills format, introduced by Anthropic and published as an open standard in late 2025, packages such a procedure as a folder. At its center is a SKILL.md file with a short name and description, followed by instructions. The folder can also hold templates, reference documents, and scripts:
---
name: quarterly-report
description: Build the quarterly revenue report from the finance export.
Use when asked for the quarterly report, QBR numbers, or a revenue summary.
---
# Quarterly report
1. Run `scripts/clean_export.py <file>` to normalize the revenue export.
2. Compute regional totals with `scripts/summarize.py`. Never total by hand.
3. Lay out the report using `template.md`. Amounts in USD, rounded to thousands.
4. Flag any region whose revenue moved more than 15% from last quarter.What makes skills efficient is progressive disclosure: the agent does not load every skill, and at the start of a session it sees only each skill's name and description. When a task matches a description, it reads that skill's full instructions. Templates and references load only if the instructions point to them, and scripts can run without their source ever entering the context window.
Good skills share a few habits. They are short, with numbered steps rather than essays, and they push anything deterministic, such as calculations, file conversions, and validations, into scripts the agent runs rather than steps it improvises. They include one or two worked examples of the expected output. And they say explicitly what not to do, because the mistakes a skill prevents are usually the reason it was written.
The description is therefore the most important line in a skill. It is the only part the agent sees when deciding whether the skill applies, so it should say both what the skill does and when to use it, in the words a user would actually type. The same thinking applies to tool descriptions in MCP, and for the same reason.
Skills complement the other mechanisms rather than replacing them.
Tools and MCP servers give an agent new actions. Retrieval gives it access to large document collections. Instruction files hold the handful of rules that apply everywhere. Skills hold the procedures in between: too specific to load every time, too important to leave to improvisation.
When to use them, and when not to
Use memory when continuity matters to the user: a returning customer's preferences, a long-running project's decisions, an assistant that should not ask the same question twice. Use skills when the same kind of task recurs and there is a right way to do it that the model would not guess on its own.
Start with the simplest layer that works. A short instruction file solves most project-level forgetting in an afternoon. Add skills when the instruction file starts filling with procedures that only matter sometimes. Add automatic memory last, when you genuinely need to remember things about many different users or projects, because it brings the most new risk.
Do not use memory as a database. A customer's account balance, order status, or plan belongs in the system that owns it, queried live through a tool, not copied into a memory that will be wrong next week. Do not store sensitive personal data in memory without the user's knowledge and consent. And do not write a skill for something a model already does well with a one-line instruction; a skill earns its place when the procedure is specific to you.
What goes wrong
Memory makes injection permanent. In the prompt injection post, a malicious email could influence one session. With memory, it can write itself into every future session.
In July 2026, researchers showed that a single crafted email could get several popular agent frameworks to record a false fact in their own memory, without telling the user, and that the falsehood resurfaced as trusted knowledge in later, unrelated conversations. Existing injection defenses missed most attempts.
The mitigations follow from the memory lifecycle. Record the source of every memory, and treat facts derived from external content as unconfirmed. Keep memory-write tools away from agents that read untrusted input unattended, and log every write with the content that triggered it.
Memories go stale. People move, change jobs, and change their minds. A memory system without dates and supersession accumulates contradictions, and retrieval will eventually surface the wrong one. Store dates, prefer recent facts, and let important memories expire or be re-confirmed.
Memories get invented. An extraction step that turns one sarcastic remark into "the user hates the product," or one mention of a friend's diet into "the user is vegetarian," creates false memories as confidently as true ones. Extract only what the user stated clearly, and confirm anything consequential before acting on it.
Users cannot see what is remembered. An assistant that knows things a user never realized they shared feels invasive, even when it is helpful. Make memory visible and editable, and make deletion real, including any search indexes built from deleted entries.
Skills fail quietly too. A vague description means the skill never loads, or loads for the wrong task. A skill copied from the internet may include scripts the agent will run with its permissions, which makes it a supply chain risk just like a third-party MCP server. Review skills the way you review code, keep them in version control, and test them with your evals when procedures change.
Cost and complexity
Done well, memory and skills reduce cost, because they replace stuffing everything into every prompt. With 50 skills at about 100 tokens per description and 4,000 tokens per full skill, progressive disclosure costs about 5,000 tokens per session plus 4,000 for the one skill in use. Loading every skill in full would cost about 200,000 tokens, every session.
Memory retrieval is similarly cheap: twenty retrieved memories at about 30 tokens each add about 600 tokens to a session. The larger cost is the write path. Extracting memories usually means an extra model call after each conversation, and deduplicating and resolving conflicts adds more.
The real complexity is operational. Memory is user data, so it comes with retention policies, deletion requests, and access controls. Skills are code and documentation, so they need owners and reviews. Neither is hard, but both need someone responsible for them.
The current landscape
Agent Skills has spread quickly since Anthropic published it as an open standard, with the specification hosted at github.com/agentskills/agentskills. Besides Claude's own products, support has been reported in OpenAI's Codex and ChatGPT, GitHub Copilot, Cursor, Gemini CLI, Block's Goose, and other coding agents. Instruction files have a parallel standard in AGENTS.md, now a project of the Agentic AI Foundation alongside MCP.
For memory, the major chat assistants, including ChatGPT and Claude, offer memory features that users can review and manage. For builders, Anthropic's memory tool provides file-based memory under your control. Open-source libraries cover the other approaches: Mem0 for extracted memory, Letta, which grew out of the MemGPT research project, for agent-managed tiered memory, Zep and its Graphiti library for memory as a knowledge graph with time-aware facts, and LangMem within the LangGraph ecosystem.
Security research is catching up with the field. Memory poisoning is now a recognized attack class, and the recommended defenses, such as source tagging, confirmed writes, and separating untrusted readers from memory writers, are design choices you can make today rather than products you have to buy.
Summary
Agents forget everything between sessions, and stuffing everything into every session is too expensive and makes them worse. Memory and skills solve this by storing knowledge outside the context window and loading only what the current task needs: facts about this user or project from memory, and know-how for this kind of task from skills.
Both turn an agent from a capable stranger into a colleague who gets better over time. Both also create a long-lived store that people and attackers can shape. So treat memories as data with sources and dates, treat skills as reviewed code, and make what the agent remembers visible to the people it remembers.
Part of the Applied AI series: AI from the builder's side.