A five-part protocol for deploying AI agents in shared client rooms without leaking internal context.
Adapted from @alex_prompter# The Future of Human-AI Collaboration: Put Agents in Client Rooms Without Exposing Your Workspace Picture your best agent sitting in a channel with your biggest client. They ask a fair question. "Why does this keep breaking on our end?" Your agent knows the answer. It knows because it has read your codebase, your incident log, your Slack history, and the postmortem where your team admitted the retry logic was written in a rush before a demo. So it answers. Helpfully. Accurately. In full. And in one message you have just told a client something that changes how they price their next contract with you. Nobody shared a file. No permission was granted. No access control was violated. Your agent simply did its job, which is to be useful with the context it has. That is the failure mode that's about to bite a lot of builders, and it isn't a security problem. Security is solved. Permissions, scopes, private servers, all of that works fine. The gap is that a permissions system governs what your agent can open. It governs nothing about what your agent is willing to say out loud in a room where the other company keeps a copy of the transcript. You don't need an access boundary. You need an inference boundary. I have not seen anyone write that rulebook, so I wrote it. It's below, it's free, and it works on any stack. Copy it into your own agents today. Raft is the workspace that makes the full version possible, and I'll get to exactly why at the end, but the protocol itself is yours either way. ## The Cross-Company Agent Protocol Five parts. Boundary matrix, roles, labeling discipline, handoff templates, escalation ladder. Part 1: The Share / Summarize / Never Expose matrix Three tiers, and the third one is the tier people forget. Share means the artifact itself crosses. Both sides can open it and verify it. Summarize means the conclusion crosses and the source stays home. Your agent gives the answer, not the reasoning trail that produced it. Never Expose means your agent must not answer from it. Not in paraphrase, not in a hint, not by confirming a guess, not even when the answer would genuinely help. That last distinction is the whole protocol. Never Expose is not a list of files to lock. It's a list of things your agent is not allowed to know out loud. Write your own version before you open any shared room. Three rows per tier is enough to start. The act of writing it is most of the benefit, because it forces you to decide things you have been deciding by accident. Part 2: Three roles, and the counterintuitive one The room agent. One per side. Exactly one. It handles intake, clarification, restatement, labeling, and delivery. It is a diplomat, not an engineer. Here's the part that surprises people: your room agent should be your least privileged agent, not your most. The instinct runs the other way. You want the shared agent to be helpful, so you give it broad access. That's backwards. The room agent produces the only transcript the other company keeps forever. Every capability you hand it is a capability that can be talked out of it by a well-phrased question. Narrow it on purpose, and let it fetch depth through a handoff instead of holding depth in its head. Also: one voice per side. Two of your agents talking in the same shared room will eventually contradict each other, and the other party gets to quote whichever version helps them. Backstage agents. Full private access. Never in the room, never addressed by the other side, never speaking across the line. They hold the code, the history, the tooling. They do the actual work and hand results back through a readback packet. The human approver. A named person, not a role in the abstract. They own the authority gates in Part 5. Naming them matters because an unnamed approver becomes no approver by Friday afternoon. Those three make up one bounded environment: an agent that speaks, a private team that does the work, and a named human who decides. Raft has a term for that arrangement, a Trust Unit, and the label is carrying real weight. It means the other side isn't talking to a bot that happens to be pointed at your systems. They're talking to a team through one agent, and the team behind it is accountable for what that agent says. Which is why the room agent's narrow permissions cost you nothing. Depth still reaches the room. It arrives through the handoff, with the team's accountability attached. Part 3: Label every claim Three tags. Your room agent uses one on every substantive statement. FACT means verified, with evidence the other side can independently open. INFERENCE means derived from your private context. Conclusion only, labeled as derived. UNVERIFIED means a hypothesis. Say so, and say what would settle it. One hard rule underneath all three: your agent never implies it has seen data the other side did not send. When a conclusion came from your private workspace, the label says so. That's the difference between a collaborator and a black box, and it's the thing that makes the other side comfortable acting on what your agent tells them. Paste this into your room agent: Part 4: The handoff templates Two packets. One going backstage, one coming back. Room to backstage: "What they did NOT send" is the line that earns its place. It's where scope creep and bad assumptions hide, and a backstage agent that can see the gap will ask for the missing piece instead of inventing it. Backstage to room: That fourth line is the one I'd fight for. Naming your boundary out loud reads as discipline. Going silent reads as evasion. "The root cause sits in a service we don't expose, so I'm giving you the conclusion and the fix, not the trace" is a sentence that builds trust. Saying nothing while obviously knowing something does the opposite. Part 5: The escalation ladder L0. The room agent answers in the room. Covered by Share tier, no private context needed. L1. Room agent hands off, backstage works it, room agent returns with a readback. This should be your most common path. L2. Human approver is notified and reviews the readback before it posts. Triggered by anything touching money, scope, timeline commitments, or a Never Expose adjacency. L3. The human speaks in the room directly. Triggered by disagreement, escalating tone, or a decision that binds the relationship. L4. Stop and move off-channel. Triggered by legal, security incidents, or a conversation that has become a negotiation. The gates that always need a human, drawn from how Raft's own team runs it: production changes, credentials, policy, architecture, and final approval. Agents carry the investigation and the verification between those gates. A person decides at them. Add one of your own: any answer that would require Never Expose material to be genuinely useful goes to a human. Not because the agent will leak, but because that's the moment you decide whether the relationship has earned a different boundary. That's a business call, not an agent call. Worth saying plainly: each side sets this dial for its own agents. How far yours can go before a human signs off is your call, not your collaborator's. ## The protocol in action Here's the shape, using the case Raft published about their own vendor relationship with ScopeDB, the database they run tracing and observability on. Before any of this exists. You hit a performance problem at the seam between your system and your vendor's. Someone writes it up. It becomes a ticket. Their support reads a summary of a summary, asks three questions you already answered, and eventually a call gets booked. Half of it is rebuilding context. The one engineer who could answer in ninety seconds is four layers away from your actual query. The expensive fix for this has always been a forward-deployed engineer, one of their people embedded with your team, gated on somebody's calendar. In the room. ScopeDB's founder and CEO is in a joint channel, the private shared room between the two companies, together with Raft's agent. He asks the agent directly how they've designed their usage, and whether their queries hit a materialized index. The agent answers him in the room. No human on Raft's side relays a word. Sit with the shape of that. The vendor's CEO is running technical discovery against a customer's system by talking to the customer's agent. The agent is the embedded engineer. Nobody flies anyone in. Where the protocol does its work. That query design is Share tier, so the room agent states it as FACT with evidence attached. When the question moves toward why their workload looks the way it does, that's Summarize, so the conclusion crosses and the internal reasoning stays. When the founder asks something that would need Never Expose material, the room agent says which tier it's declining on and offers what it can give instead. Then it hands off, and the backstage agents that own the relevant code work the problem on Raft's own server and return a readback. Outcome. The relationship stops being ticket ping-pong. ScopeDB hardens their database against a real high-concurrency agent workload. Raft gets an observability layer they can query and verify. Each side becomes the other's proving ground. What stayed private. Only what a participant deliberately posts into that channel crosses. Other channels, DMs, files, member lists, permissions, and read state stay local to each server. ## Why this needs a room built for it You can run most of this protocol today in a shared Slack channel with a well-prompted bot. Roles, labels, templates, gates, all of it is portable. What you cannot fake is the room itself. Raft's answer to that problem is Joint Mode, and the idea is narrow enough to state in a line: two Trust Units work one problem together without either one joining the other. Each side keeps its own server, its own agents, its own private everything. What they share is a joint channel, the room between them. The room is shared. The two environments behind it stay separate, and neither becomes a member of the other. The mechanics back that up. A joint channel connects up to three servers as a single conversation projected into each side's workspace. Each side adds its own members, and only its own. Joining grants no membership or authority anywhere beyond that channel, and there are no cross-server DMs. Agents from either side participate as members, and each agent's permissions stay tied to the server that owns it. Put my protocol next to that and the division of labor is clean. Your boundary matrix decides what crosses. Joint Mode decides what can cross. One is policy, the other is the architecture holding the policy up, and policy without architecture underneath it is just a prompt you're hoping holds. One detail I like more than I expected: joint channels have no task board. The room is for conversation, so your task tracking necessarily lives on your own server. The architecture pushes backstage work backstage by default. Honest caveats, because this account doesn't do commercials. Raft labels joint channels experimental in their own docs. Three servers is a hard cap. Setup is real work: create a server, connect a computer, build your agents, then open the room. Agents run on your own machine through a local process, using AI subscriptions you already pay for, which is good for cost and means your hardware is now part of the system. ## Run the 30-minute test Grab one collaborator you already trust. A vendor, a contractor, a design partner. 0 to 5. Pick one real task that currently dies in email. Small and boring beats impressive. 5 to 10. Write your boundary matrix. Three rows per tier. Ten minutes, not an afternoon. 10 to 15. Open the room, name your room agent, paste the operating card with your matrix filled in. 15 to 20. Your collaborator does the same on their side. Their matrix will differ from yours, and comparing the two is worth the whole exercise. 20 to 27. Run one full cycle. Their ask, your L1 handoff, a readback with labels attached. 27 to 30. The audit, and skip this at your peril. Copy the room transcript into a fresh model with zero context and ask: what can you infer about this company's internals, staffing, clients, and pricing from this alone? Whatever comes back is what you actually exposed. That number is almost never zero the first time. ## The verdict For as long as companies have worked together, the unit has been the person. Your people talk to their people, and both sides relay for the software behind them. Agents in a shared room change the unit to the person and their agent, on both sides, at the same time. That's a real capability jump and I think it lands within a year whether or not anyone is ready. The part I'd bet on: the teams that win at this won't be the ones with the strongest models. They'll be the ones who decided in advance what their agents are allowed to say. A capable agent with no boundary matrix is a liability you're paying for monthly. So write the matrix. Name the approver. Paste the operating card. Run the audit and look at what it finds. Then go find a room worth opening. Links in the first reply.
