AI Memory Management: Progressive Disclosure, Skills, and Sub-Agents

Every agent user hits the same wall eventually: “I keep telling it the same thing. Here’s the answer, write it to memory.” The model doesn’t remember you. It never did. Part 6 of Ariel’s “AI Concepts from Zero to Pro” series is about how to fake memory properly, so the agent knows what it needs without starting every session half full.

Memory lives in the environment, not the model

The model is always stateless. What makes an agent feel stateful across sessions is a memory system in its environment: usually files, sometimes a database.

The classic example is the main agent file, AGENTS.md or CLAUDE.md, which the agent loads at the start of every session. Tired of reminding it that you’re on Postgres and not MySQL? Don’t repeat it. Write it to memory, put it on disk, and let it load at session start.

That leads straight to the next complaint: “Why does every session start with 4,000 tokens used before I’ve even said hello?” Answer: someone stuffed the agent file.

Ariel is honest about his own setup. For the agent he develops on, his agent files run to 40–50 thousand tokens, because he wants it to know everything the moment it loads and doesn’t want to remind it one thing at a time. It burns budget, and he knows it. On the metrology client project, where the work is narrow, specific tickets, he loads only what’s needed. Same person, two strategies, chosen by the type of work.

Progressive disclosure

This is the concept skills were built on. Disclosure means revealing; progressive means gradually. You reveal to the agent the information it needs, when it needs it, not all at once.

His working example: he needs a new service that connects five existing components. Instead of dumping the whole project on the agent, he goes component by component. “Did you understand what you need from here? Good. Write a hand-off file that explains only this part.” Five components, five tight files. Then a fresh session: “Now I want a service that serves these five. Read these five files.” That’s progressive disclosure done by hand.

Context pointers

Should you paste the full UI style guide into your agent file? No way. You don’t need color and spacing rules every time you talk to the agent. You need them when you’re building a component.

So the agent file holds a context pointer instead: “There’s a RAG folder with docs on X. The models live in this folder. When you build UI, read the style guide here.” Same idea with a database agent that’s told it must always read the schema, but can read the stored procedures and SQL functions whenever it decides they’re relevant.

Rule of thumb from the video: if your agent file is getting huge, most of it should be pointers, not content.

Skills: the packaged version

A skill is the formal, reusable version of everything above:

• It always lives in a skills/ folder, in a subfolder named after the skill, with a SKILL.md as the source.
• It can carry extra files next to it: scripts, templates, anything the agent can run.
• Only the name and description sit in context. Everything else loads through progressive disclosure, when the agent decides it needs it.

His example: a skill for making schnitzel and a skill for making cheesecake. You’ll never need both at once, so they’re separate, and each loads only when it’s relevant.

Where should the deploy runbook go? A skill. When it’s time to deploy, the agent reads it. Until then, it costs zero tokens.

Sub-agents: delegate the noise

A sub-agent is an agent the main agent launches through a tool call. Its big advantage is that it gets its own session and its own context window. It does the job and reports back with a summary in the tool result. Unlike a hand-off, it doesn’t write a document for the parent unless you tell it to.

Two clarifications from Ariel:

• The source he’s reading says sub-agents can’t spawn more sub-agents. He disagrees: it’s a configuration and recommendation question, the limits keep changing, and Claude currently allows several levels.
• There’s no real chain of command. Calling a sub-agent is basically calling a tool: give it a task, it does it, it returns an answer.

The point is to push context-heavy work that you don’t care about somewhere else. His example: “Read all my email and tell me the five most urgent tasks.” You don’t want every email sitting in your main session. A sub-agent reads everything and hands back five items, and you start working immediately. Same fix for “search keeps blowing up my context”: every search goes to a sub-agent that returns only the answer.

The other advantage is specialization. A database sub-agent that only knows databases. Ariel points to a Microsoft security harness that he says used more than 100 agents, each focused on one type of attack, plus ranking agents to combine the findings, and beat a single frontier model at finding vulnerabilities. Many narrow specialists versus one generalist that sees the whole system.

🔥 Roast Corner

Let’s address the 50,000-token elephant in the room. The man teaching “don’t stuff your agent file” admits, on camera, that his own agent files are 40–50 thousand tokens. That’s a novella his agent re-reads every morning before it’s allowed to say hello. Respect for the honesty, and to be fair, he has a reason. Most people who do the same thing don’t.

The rest of us have a different disease: the agent file as a junk drawer. The style guide, the deploy steps, the “remember we use Postgres”, three paragraphs about a bug from March, and a list of rules contradicting each other. Then people wonder why the agent “got dumber.” It didn’t. You buried its working memory under your diary.

And if your agent reads 400 emails in the main session to find five urgent ones, you didn’t build an assistant. You built a very expensive way to forget what you asked it to do in the first place.

🤖 AI for Humans

Open your agent file today and give it this five-minute diet:

1. Measure it. If it’s thousands of tokens and you’re doing narrow tasks, it’s too big.
2. Keep only what applies to every session: stack, key rules, where things live.
3. Turn everything else into pointers. “Style guide: docs/style.md. Read it before UI work.”
4. Turn repeatable procedures into skills. Deploy, release, onboarding. Name plus one-line description in context, details on demand.
5. Send noisy jobs to sub-agents. Searches, inbox sweeps, log digging. Ask for the five things you need, not the 500 it read.
6. For big tasks, disclose progressively. One component at a time, one hand-off file per piece, then a fresh session that reads only those files.

Your agent will never remember you. But with a lean memory system, it can act like it does without paying for it on every message.