When an agent's tools are documents, extending the agent means writing a document — something the agent can do for itself, the owner can read as text, and the system can version, address, and diff like any other content. A tool document is canonical DAG-CBOR whose CID is its version, so "what changed about this tool" is a content address, not a changelog.

The same logic runs forward: triggers are designed to become ~/triggers/ documents so that "when X happens, do Y" is a rule a person can open and edit. That work is not built; triggers are still protocol rows, and ~/plans/ was never created — the checklist lives behind the plan verb instead.

~/memory/ — the agent's persistent files, a real directory under its state dir. See Memory.

~/tools/ — one content-addressed document per tool, builtin or agent-authored. See Tools as Documents.

Reachable through the same verbs, though they live elsewhere: hm:// documents on the hypermedia network, ipfs:// content, https:// pages, the activity: feed, attachment: files, and thread:/run: history.

An agent cannot carry its whole Space in its head, and does not need to. Every run's system prompt includes a generated index — the <space> block, budgeted at 2 KiB — listing one line per tool, the memory tree's top level, and up to eight active triggers. The agent always knows what it could expand, and expands only what a task touches (touch-expand).

This is what keeps the prompt surface constant as capability grows: a new tool adds a line to the index, not a schema to the prompt. When the index would exceed its budget, per-tool lines collapse to a count rather than being silently truncated.

The index is cached per agent and callable set, and invalidated at every site that could change it — a definition edit, a memory write or delete, a download, a trigger change, an upload. That list of a dozen invalidation points is the cost of the cache, and it is the kind of thing worth knowing before adding a thirteenth mutation path.