The missing pieces that make agents useful

In the previous post, we built the foundation of an AI agent: tool calling, the messaging layer, and the agent loop. Those three pieces give you a system that can receive a message, reason about it, take action, and respond.

But that system has two gaps.

First, it has no memory. Every time you start a new session, the agent has no idea who you are, what you have discussed before, or what you care about. It is like talking to someone with amnesia.

Second, it has no skills beyond its built-in tools. Want your agent to post to TikTok? Manage your calendar? Control your smart home? You would need to rebuild the core codebase every time.

Add memory and skills, and you get something you would actually use daily. These two systems are what separate a tech demo from a daily-driver agent.

Memory: markdown files that give agents a past

Memory is how agents persist knowledge across conversations. In most of the claw repos, memory is surprisingly simple: markdown files.

The typical memory system uses a handful of files, each with a distinct purpose.

SOUL.md defines the agent's identity, personality, and hard boundaries. This is where you say things like "you are a helpful assistant named Larry" and "never execute financial transactions without explicit confirmation." It sets the rails the agent runs on.

MEMORY.md stores long-term facts the agent has learned over time. "User prefers dark mode." "The API key for Postiz is in the .env file." "User's dog is named Max." These facts accumulate as the agent interacts with you, building a persistent profile that makes each conversation feel continuous.

HISTORY.md holds conversation logs and interaction history. Not every message (that would be too large) but key events, decisions, and outcomes that the agent can reference later.

USER.md captures user preferences and explicit instructions. Things you have told the agent to always do or never do.

At the start of every session, a Context Builder assembles the complete prompt from these memory files, conversation history, and active skills. The LLM sees this assembled context and picks up where it left off.

The nice thing about markdown memory is that it is human-readable and human-editable. You can open SOUL.md in a text editor, tweak your agent's personality, and see the change immediately. No database migrations. No admin panels. Just a file.

OpenClaw takes memory further with a hybrid search system combining BM25 full-text search and vector embeddings, all stored locally in markdown. ZeroClaw implements hybrid vector + keyword search entirely within SQLite, with embeddings stored as BLOBs with cosine similarity, FTS5 virtual tables with BM25 scoring, and a configurable weighted merge. No external vector database needed.

IronClaw uses PostgreSQL with pgvector and implements Reciprocal Rank Fusion (RRF) to combine full-text and vector similarity into a single ranked result set.

Different implementations, same idea: the agent should remember what matters and retrieve it efficiently.

Skills: the extension mechanism that keeps agents lean

Skills are what keep these repos from becoming bloated monoliths. Instead of building every possible feature into the core codebase, you define new capabilities as SKILL.md files, markdown documents with instructions that teach the agent how to use specific tools or perform specific workflows.

Want your agent to post to TikTok? You do not write a TikTok module. You write a skill file, a plain text document that says: "Here are the tools you need (Postiz). Here is the workflow: generate 6 slideshow images in portrait, add text overlay on slide 1 with the hook, upload to TikTok as a draft, send the caption for review." That is it. The agent reads the instructions, understands the workflow, and executes it.

This is not theoretical. Skills are how @oliverhenry's OpenClaw agent "Larry" automated viral TikTok creation and generated 500K+ views in a week. Skills are how people connect their agents to Gmail, GitHub, smart homes, and wallets.

The Claude Agent SDK discovers skills automatically from .claude/skills/ directories and loads them into context when relevant. The model itself decides when to invoke a skill based on the user's request.

Always-on vs. on-demand skills

Not all skills are created equal. Nanobot makes a useful distinction between two types.

Always-loaded skills have their full content injected into every prompt. These are capabilities the agent should always know about: core workflows, safety instructions, identity definitions. The tradeoff is token cost. Every always-loaded skill consumes context window space on every single request.

On-demand skills include only a brief summary in the default prompt. When the agent determines a skill is relevant to the current request, it loads the full content. This keeps the base context small while making hundreds of capabilities available.

This two-tier system is how you scale from 5 skills to 5,000 without blowing up your context window or your API bill.

Karpathy's insight: skills as configuration

Andrej Karpathy said something about NanoClaw's approach to skills that "slightly blew his mind." NanoClaw does not use config files at all. It uses skills.

Want to add Telegram support to NanoClaw (which ships with WhatsApp only)? You do not modify the core code. You do not edit a config file. You add a skill file at .claude/skills/add-telegram/SKILL.md that teaches Claude Code how to transform the installation.

The /add-telegram skill instructs the AI agent how to modify the actual code to integrate Telegram. The agent reads the instructions and reshapes the codebase itself.

Karpathy's takeaway: the new meta is to write the most maximally forkable repo, then have skills that fork it into any desired configuration. No config mess. No if-then-else monsters. Just plain-language instructions that the agent executes to reshape the codebase.

This is a different mental model. Configuration is not a file format. Configuration is a conversation with an agent that knows how to restructure code.

The architecture that emerges

Agent loop + memory + skills. This is the shared DNA across all six repos in the claw ecosystem.

The agent loop gives you autonomy, the ability to chain actions together toward a goal. Memory gives you continuity, the agent knows who you are and what you care about across sessions. Skills give you extensibility, the agent can learn new capabilities without core code changes.

Together, they produce an agent that runs 24/7 on your machine, remembers your preferences, learns new tricks through plain-text instructions, and gets better over time as its memory grows.

In the next post, we walk through all six repos in the ecosystem and see how each one implements these same patterns with wildly different tradeoffs.

What this means for education

The memory and skill patterns described here map directly to how institutional AI should work. At ibl.ai, our mentorAI platform uses the same conceptual architecture: persistent memory of student interactions, academic history, and learning preferences, combined with modular skills that cover degree auditing, resource recommendation, and adaptive tutoring.

The markdown-as-memory approach is particularly relevant for education. When an AI mentor's knowledge base is human-readable and human-editable, faculty and advisors can inspect exactly what the system knows, correct inaccuracies, and set boundaries. Transparency is not optional in education. It is a requirement.

Skills-as-extensions also matter. Every institution has unique workflows. Transfer credit evaluation at one university looks nothing like another. A skill-based architecture lets you customize the agent's capabilities to match institutional processes without rebuilding the core system.