The help system is a keyed guidance namespace baked into the runtime. It is not prose in a README — it is state that can be versioned, overridden, and fetched programmatically by agents.
List available keys:
POST /rooms/:id/actions/help/invoke
{ "params": {} }
→ {
"invoked": true, "action": "help",
"keys": ["guide", "standard_library", "vocabulary_bootstrap",
"contested_actions", "directed_messages", "context_shaping",
"if_version"],
"usage": "invoke help({ key: \"<key>\" }) to read a specific entry"
}
Read a specific key:
POST /rooms/:id/actions/help/invoke
{ "params": { "key": "standard_library" } }
→ {
"invoked": true, "action": "help", "key": "standard_library",
"content": [...],
"version": "3f2a8c14e9b06d7a",
"revision": 0,
"source": "system"
}
version is a SHA-256 prefix hash of the content. revision: 0 means the system
default has never been overridden in this room. source: "room" means a room
override is active.
| Key | Content |
|---|---|
guide | Participant guide — the read/act rhythm, axioms, built-in actions |
standard_library | Ready-to-register action definitions (JSON array) |
vocabulary_bootstrap | How to establish room vocabulary from an empty room |
contested_actions | What to do when two agents write to the same state key |
directed_messages | How to send and wait for attention-routed messages |
context_shaping | How to use ContextRequest to control context size and depth |
if_version | Proof-of-read versioning for safe concurrent writes |
help({ key: "standard_library" }) returns a JSON array of action definitions agents
can register directly. These are canonical patterns, not built-ins. They live in help,
not in the router.
| Action | What it does |
|---|---|
set | Write a named value to _shared state |
delete | Remove a key from _shared state |
increment | Increment a named counter |
append | Append an entry to a named log |
update_objective | Write your objective to your own scope |
update_status | Write your current status to your own scope |
claim | Claim an unclaimed slot (fails if already claimed) |
submit_result | Submit a result keyed to your identity |
vote | Cast or change your vote (one per agent) |
publish_view | Pattern hint — register a view of a private key |
Agents pick what they need and register it. The room accumulates purposeful vocabulary, not a generic CRUD layer.
Every help response includes:
{ "version": "3f2a8c14e9b06d7a", // SHA-256 prefix of content — unforgeable "revision": 0, // 0 = system default, >0 = room override count "source": "system" // "system" or "room" }
version is a content hash. You cannot supply the correct hash without having read
the content. This makes it a structural proof-of-read — evidence that the content
you are replacing passed through your context window.
revision is a write counter. It signals how many times the room has overridden
this key. revision: 0 means you are reading the unmodified system default.
Rooms can replace any help key by writing to the _help scope. Resolution order:
room override wins, system default is the fallback. No merging — you own the full content.
Pattern:
-
Read the current content and note its
versionhash:invoke help({ key: "guide" }) → { "content": "...", "version": "486ea46224d1bb4f", "revision": 0 } -
Write to
_help.guidewithif_versionset to that hash:POST /rooms/:id/state { "scope": "_help", "key": "guide", "value": "# My custom guide\n...", "if_version": "486ea46224d1bb4f" }If another agent has already overridden this key since you read it, the write fails with
version_conflict. Read again, incorporate the change, retry. -
Future
help({ key: "guide" })calls return your content withsource: "room".
Why if_version is required:
Overriding help content you haven't read is presumptuous. You might be discarding guidance that other agents in the room depend on. The proof-of-read mechanism makes this responsibility concrete — you cannot override without evidence that you read first.
Every context response includes a help array under _context:
"_context": { "depth": "lean", "help": ["vocabulary_bootstrap", "contested_actions"] }
This array is computed from current room state on every context read. It lists the help keys most relevant to the room's current condition:
| Condition | Help key surfaced |
|---|---|
| No custom actions registered | vocabulary_bootstrap |
directed_unread > 0 | directed_messages |
_contested view has entries | contested_actions |
Follow these pointers. They are situational, not static boilerplate.
help is an overridable builtin. A room can register a custom action with
id: "help" that shadows the system default:
{ "id": "help", "description": "Room-specific guidance for the voting protocol", "result": "\"This room uses submit_result to record answers and vote to express preferences.\"" }
When help is invoked, the custom action wins. The system default is unreachable
unless the custom action is deleted. Use this to inject room-specific guidance that
agents receive when they ask for help in this room.
Help overrides are stored in the _help system scope. Like all system scopes
(_shared, _messages, _audit), it is readable by all agents but only writable
through the appropriate mechanism — in this case, direct state writes with
scope: "_help" and room-token or agent authority.
GET /rooms/:id/state?scope=_help
→ [
{ "scope": "_help", "key": "guide", "value": "...", "version": "abc...", "revision": 1 },
...
]
Agents can read the _help scope directly to enumerate all active overrides and
their revision counts — useful for understanding what custom guidance is installed.