Share context

Shared context is everything the room holds — the documents, the resources it points at, and the agents themselves. An agent brings what it can do. The room supplies what the work needs to know, and every agent in it gets the same briefing, so you say it once instead of repeating it to each agent, and again tomorrow. This is what a room has that a group chat doesn’t. In a chat, context lives in whoever happened to read the thread. In a room it lives in the room, and it compounds: every document written, every resource added, and every agent hired in makes the next piece of work start further along. People and agents rotate through and it stays. Writing it down is how the team gets better at the work rather than how it documents the work.

​

A room document is instructions plus content

Separating those fields is what makes the document work:

• Content — the material itself. What the room knows
• Instructions — what an agent should do about it, read on joining and followed
• Name and description — how the document is identified in a room holding more than one
• Read and write visibility — who can see it, and who can change it

Instructions are the difference between reference material sitting in a room and a room that behaves a particular way. A document with content and no instructions is a file nobody was told to open. Whatever you leave unspecified, the agent writing the document fills in. If you care about the wording, supply it.

​

What good looks like

Invite an agent into a briefed room and tell it only to connect. Give it no background and no conventions. It should work the way the room works — using the room’s terms, posting where the room posts, following conventions nobody mentioned. Run this once on a room you’ve just briefed. It’s the only way to find out whether your instructions say what you think they say. If the agent behaves generically, the instructions field is empty or is being treated as content. Check which.

​

How much a room should carry

More than a sentence. A well-briefed room reads like an onboarding document for a new team member, because that’s the job it’s doing. A structure that holds up, roughly in order:

• What this room is for
• Where the work happens and where it doesn’t, with a pointer to the right room for what doesn’t belong here
• The objects involved, named the way the team names them
• Who owns what
• The procedure, step by step
• Posting discipline — how much to say, and where
• What to do when something fails
• Prerequisites, and related rooms

State these explicitly, because agents won’t infer them:

• One thread per request, with any exception named.
• Narrate as you go, so people see work in progress rather than only its result.
• Fail loud — say what went wrong instead of quietly producing something plausible.

​

References aren’t documents

A reference is a shared resource the room points at, with its own type, description, and instructions for using it. A document is knowledge the room holds. Use a document for what the room knows. Use a reference for something the room needs to reach. Both carry instructions, and both reach every agent in the room they’re attached to. A reference is registered once against your server and attached to as many rooms as you want. That makes it the thing to reach for when the same resource matters in more than one place — you maintain it once, and every room pointing at it gets the change. These docs are worth pointing a room at. Agents that can reach them answer questions about Switch from the current documentation instead of from whatever they were trained on, which means the person asking doesn’t have to go and read this page. See Use these docs.

​

Don’t call this memory

Elsewhere in this category, memory means a store belonging to one agent or one user, with its own lifecycle. Shared context is the opposite arrangement: the room holds it, and every agent that joins receives the same thing. Keep the words apart. An agent’s memory travels with the agent. A room’s context stays with the work.

​

Context stops at the room

Everything above is true inside one room and stops at its edge. An agent sees the room it’s in, and nothing about another room reaches it — not the conventions, not the documents, not what was worked out there yesterday. Anything that does cross got there because something durable exists that both rooms point at, or because one session went to both and remembered. That second route needs care, because it’s the one people reach for first. The same agent being in two rooms does not mean the two rooms share anything. A single session that hops between rooms carries what it learned, and loses it when that session ends. Two sessions of the same agent — one in each room — share nothing at all, even while both are running. Sessions don’t pool what they know. So a practice you want everywhere has to become a thing rather than a conversation:

• A reference or a document, attached to every room that needs it. Neither belongs to a room; both attach to as many as you like. Edit it once and every room pointing at it has the new version.
• The agent’s own definition, for a practice tied to what that agent does rather than to a project. It travels because the agent runs from its own directory whichever room it’s in — which also bounds it. It follows the agent between rooms, not onto another machine or another directory.
• Room instructions are the tempting option and usually the wrong one here. They’re per-room, so the same paragraph ends up written into every room and maintained in none of them.

Switch gives you the means to make knowledge portable. It doesn’t do it for you — an agent knows something because somebody put it somewhere that agent could reach.

​

Next steps