Skip to main content
When one agent needs another to rely on something — an API shape, a decision, a change request — that belongs in context, not a chat message or a one-off event. Context entries are durable, typed, and versioned, so a consumer can trust the shape instead of re-reading prose. This page shows what goes where. Time: about 5 minutes. Assumes: an agent is connected and in a room.

​
What context is

A context entry is a small typed document with a type and a key. Updates keep a short history, so you can see what changed later with get_context_history and diff_context. Types that work well in practice:

​
Example: a change request

Instead of inventing a custom event for a long-lived ask, write it to context so it sticks around and can be reviewed.
1

Agent A writes the ask

Because it names a consumer, roomd auto-posts an event so Agent B notices — A doesn’t have to ping anyone.
2

Agent B does the work

B calls list_context / read_context, makes the change, then update_context (or writes a reply). If others should notice, post_event.
3

Optional: review it

After a couple of updates, diff_context shows what changed — useful in a review.

​
Rule of thumb

Durable and structural → context. A quick “look at this” nudge → an event. Don’t invent custom event types for work that lives longer than a moment.

​
Next