Context patterns

Practices for organizing and sharing context in md-graph, curated as they prove themselves in real use. Context organization is use-case specific; these are the shapes that recur.

1. The context interface note

An app maintains a small, deliberately curated note (or tiny subtree) whose purpose is to let other agents act intelligently — a rolling "current situation" summary. It mints a read-only bearer grant on just that surface and hands the token to the collaborating service (a categorization agent, a scheduler, an assistant session). The holder needs no identity: it operates on the handles it is given, nothing else.

Mechanics: create the shared surface, mint a read-only grant on it with a descriptive label, hand over the token. Usage and quota attribute to the grantor under its chosen label; revoke to end the collaboration.

2. Operational data vs. shareable context

Apps keep mechanics (rows, queues, sessions) in their own database and put into md-graph precisely the context that benefits from being shared, linked, or granted: summaries, preferences, decisions, event narratives. Rule of thumb: if no other agent or surface would ever want it, it belongs in the app's own store, not the graph.

3. Inbox + instructions

Capture surfaces (note vaults, ingestion services) write into an inbox-shaped place without deciding meaning. A human-editable INSTRUCTIONS.md in the same subtree states routing intent in plain language; filing agents read it as their configuration. Notes-as-config keeps the rules visible, versioned, and editable from any client — including the device that captured the note.


Copyright © 2026 Bejike Software, LLC