2.3 Beyond a single prompt
2.3.1 Skills are procedural memory
A skill is a reusable procedure. The open Agent Skills specification defines one as a directory containing a SKILL.md file with metadata and instructions, optionally accompanied by scripts, references, and assets, and it recommends progressive disclosure — expose the name and description first, load the instructions when the skill activates, and load supporting material only when needed.23 Claude Code describes skills as reusable workflows that load on demand, OpenClaw as Markdown instruction files that teach an agent how and when to use tools, and Codex as reusable workflows with supporting resources and invocation policies.24
Set against the neighboring concepts, the distinctions are clean:
| Thing | What it does |
|---|---|
| Prompt | States the current request |
| Skill | Encodes a repeatable procedure |
| Reference | Supplies supporting knowledge or evidence |
| Template | Constrains the shape of the output |
| Script | Performs deterministic work |
| Tool | Exposes an action or data source |
| Policy | Defines what is allowed or forbidden |
| Hook | Intercepts a lifecycle event |
Maya’s “read customer feedback” skill might say:
- Load the original support conversations, not only the weekly summary.
- Group cases by the customer’s underlying problem, not by the tag assigned by support.
- Preserve representative quotes and links to the source records.
- Separate observed evidence from proposed explanation.
- Identify contradictions and return them rather than smoothing them away.
- Produce a structured report with affected service, confidence, unresolved questions, and recommended next investigation.
Like a versioned prompt, it can be evaluated and revised. Packaging it as a skill makes reuse explicit: several systems may invoke it when the person who wrote it is not in the room. A skill is procedural memory, and procedural memory needs an owner, a review cycle, and eventually a retirement date.
The reason for progressive disclosure is economic. Loading the full instructions of every available skill into every request burns tokens — a system with thirty skills would pay for thirty skill files on every call, whether it used them or not. The consequence is that the description carries real weight. It is the part of the skill an inference engine sees before loading the procedure, so it has to be descriptive enough to give the model the context for that decision — without being so broad that the skill triggers when it should not. There is a craft to a well-made skill, and most of the craft lives in the parts the model reads before it commits.
2.3.2 Plugins package capability with instructions
A plugin is not simply a bigger skill. A plugin can package skills together with tools, channels, model providers, hooks, MCP servers, credentials, user-interface components, or arbitrary runtime code, and OpenClaw’s documentation draws the distinction directly: tools are callable actions, skills teach agents how to work, and plugins add runtime capabilities.2526
The difference shows up concretely in Maya’s system. A skill might teach the agent how to inspect a pull request, while a plugin adds the pull-request tool, authenticates it against GitHub, registers a post-tool hook, and exposes a skill explaining the review workflow. The skill is a procedure; the plugin is an installable capability package.
Installing one therefore changes considerably more than the agent’s vocabulary. It may change what the agent can see, what it can call, which events can trigger code, and which credentials are in reach. OpenClaw recommends inspecting the live runtime after installation rather than trusting that a package manifest describes what is actually active, and OpenAI likewise describes plugins as bundles that may contain skills, connectors, MCP servers, hooks, and presentation assets.27
Before installing one, ask: What does this package add? What code runs? Which credentials does it request? Which tools become visible? Which hooks can block or modify behavior? Who approved the source? How do we remove it? Installing a plugin without understanding what it does is a common and consequential mistake, and the format is part of the problem: a bundle that rolls tools, skills, hooks, credentials, and code into one unit is hard to review as a unit. Installing one is closer to adding a dependency that runs with production credentials than to adding a browser extension, and it deserves that level of scrutiny.
2.3.3 Hooks are not suggestions
A hook runs because an event happened, not because the model remembered to ask for one, and that single property is what separates it from every instruction discussed so far. Claude Code documents hooks at session start, prompt submission, before and after tool calls, permission requests, subagent start and stop, task completion, compaction, and other lifecycle events, and a hook can inspect the event, add context, return a decision, or block an action outright.28
Compare the two mechanisms on the same requirement. A skill can say run the security scan before opening the pull request; a pre-tool command hook can block the PR-creation call, and a required CI check can block merge when the scan has not passed. A local pre-commit hook alone cannot enforce either boundary against an agent that can bypass it. That is the difference between guidance and enforcement, and Maya can put it to work with a hook that checks every generated pull request for a change to authentication or authorization, a new external dependency, access to customer data, a database migration, a disabled test, or a change to the deployment configuration. A deterministic command hook does not need the model to understand why those changes matter. It can route them for review. Some products also offer model-based prompt or agent hooks; those are another evaluator, not deterministic enforcement.
None of this makes hooks automatically safe. A hook can block legitimate work, leak sensitive event data, or quietly become an unreviewed execution path of its own. Hooks operate at a different layer from instructions, and they should be reviewed as both code and policy.
It is easy to assume that instructions have to live where the work happens. They do not. A hook does not need to be distributed to every repository, every machine, and every workstation — for some checks, distributing it makes no sense at all. A security check or a compliance verification that every change must pass is often better built into a continuous integration and continuous deployment server, where it runs once, centrally, against every change, and where a single owner can update it without touching a hundred repositories. More generally, the instructions a system works under can be assembled from several different sources. Do not assume they need to be bundled with the source code, or with the system being deployed.
2.3.4 Memory is part of delegated intelligence
Memory, as Chapter 3 established, is a defining property of delegated intelligence rather than a convenience feature, and the toolkit survey covers the products that supply it. When an orchestrator delegates intelligence, they are not asking a model for one more output; they are teaching a bounded system how to work on a class of problems, and memory is part of the teaching.
The research literature defines memory more precisely than “storing notes”: memory in an LLM-based agent is the set of mechanisms that acquires, stores, retains, and retrieves knowledge and experience to support the agent’s actions — four operations, and storage is only one of them.29
Two clarifications keep this from going wrong. First, memory is not the same as context: context is what the runtime sends to the model for this run, while memory is information retained somewhere so it can be selected for a later run — and the retrieval step is where things break, because a system may hold thousands of remembered facts and include only a small and possibly badly chosen subset in any given context. Second, memory is not automatically authoritative. Maya’s system may remember that a particular support tag was unreliable last quarter, which is useful context and not permission to ignore new evidence. A temporary exception recorded during an incident should not quietly harden into a permanent rule, and a statement copied out of an untrusted customer message should not become organizational memory merely because an agent summarized it neatly.
What a system stores is also not what it keeps. Memory can be distilled. Raw episodes get summarized into shorter records, recurring patterns consolidate into durable facts, and stale entries age out — the memory research calls this consolidation, moving detail from episodic form into semantic form. Some systems run that maintenance on a schedule, a step Chapter 4 called dreaming, because a system that keeps everything eventually drowns in its own history. The distillation step is where both the value and the danger live: what survives the long run is a design decision.
So memory needs provenance, ownership, freshness, and a route to correction or removal. The orchestrator is not only teaching a system what to remember. They are deciding what qualifies as knowledge and what has to stay a hypothesis, a warning, or a discarded observation.