HomeBlog › Collaboration without surrender: shared panes, owned data
Blog

Collaboration without surrender: shared panes, owned data

Jul 19, 20265 min readBy the Rysh team

Most collab tools make you move your work into their cloud first. Rysh shares live streams out of a workspace you still own.

There's a trade every collaboration tool asks you to make, so quietly you barely notice signing it:

To share your work, first move your work to us.

Collaborative docs? Your documents live in their cloud. Collaborative design? Your files live in their cloud. Collaborative coding? Your repo, their servers. The sharing features are real — but they're downstream of a relocation. Collaboration becomes the reason your work now lives on someone else's computer, governed by someone else's retention policy, exportable through someone else's API, priced by someone else's next pricing page.

For documents, maybe fine. For live terminals with AI agents wired to your shell, your repos, and your internal APIs — the trade is unacceptable. So rysh's collaboration is built on the opposite premise.

The work stays home

Here's the model, concretely.

Your rysh session runs on your machine (or your server — one self-contained binary). The panes are yours. The shell is your shell. The agents run against your Anthropic key — rysh runs on Claude, bring your own key — and the agent logic itself is markdown skill files sitting in your git repo. Session state persists in an embedded store on your disk. On an average Tuesday, nothing about your workspace touches anyone's cloud.

Then a teammate needs to see something.

##share pane view

What happens is transmission, not relocation. Your session opens a connection to an upstream server and forwards that one pane's output stream — a workspace-scoped NATS subject (ws.{workspace}.share.{shareID}.output), your teammate subscribing from their own terminal with ##upstream subscribe. The stream flows while you share.

##unshare pane

…and the stream stops. Your workspace didn't move. It never moved. Sharing was a faucet, not a moving truck.

What the upstream is — and pointedly isn't

The upstream rysh-server does real work: it authenticates workspaces, isolates them at the messaging layer with NATS subject ACLs, enforces share modes server-side (a view-only share rejects inbound commands at the proxy, not in the client), validates subscribers per message, and filters control-mode commands against a blocklist.

Notice what's on that list: routing and governance. Notice what isn't: your repos, your keys, your agent definitions, your session history. The server is a checkpoint your streams pass through, not a home your work lives in.

And because the boundary is explicit — streams you deliberately share transit the upstream; treat a shared pane like a screen share and don't print secrets into one — you can reason about exposure per share, not per vendor relationship.

The self-host move

For some teams, even "transient streams through a hosted checkpoint" is off the table. Regulated industry, paranoid security posture, or plain taste. Good news: the checkpoint is not sacred infrastructure.

The rysh stack is self-hostable. Run the upstream server on your own infrastructure and the entire loop — sessions, agents, shares, subscriptions — completes without a byte leaving your network (agent inference goes to Anthropic with your key; that's the one external call, and it's yours). Same binary, same commands, same isolation architecture. Your team gets ##share pane and ##upstream subscribe; your security team gets to run the boundary.

Self-hostable, note — we don't claim open source, and won't imply it. What we claim is operational ownership: the software runs where you say, holding what you hold.

Why ownership compounds in the agent era

This isn't just data-sovereignty hygiene. With agents, ownership has a second-order effect that surprised even us.

Your agents' definitions are skill files — markdown, in git. Which means your team's accumulated agent knowledge (the prompts that work, the guardrails you've added, the workflows you've encoded) is an asset you accrue, reviewable in PRs, portable across machines, versioned like the code it works on. Compare the alternative: months of prompt-tuning trapped inside a SaaS vendor's config UI, one pricing change away from hostage negotiations.

The collaboration layer respects the same line. Teammates subscribe to your streams; they don't need accounts in a system that owns your stuff. When a share ends, what they have is what they saw. When a design partner leaves us (we're early; it could happen), what they keep is… everything: their binary, their skill files, their data, their keys, and — if they self-host — the server too.

That's the test worth applying to any tool in this wave, ours included: describe what leaving costs you. If the answer is "our workflows live in their cloud," you didn't adopt a tool, you signed a treaty.

The honest ledger

To keep ourselves honest, the full trade in one place:

Collaboration tools keep asking teams to choose between working together and keeping their work. With agents about to touch everything your company runs, refuse the choice.


If "agents across the team, work stays ours" is the requirement your last three vendor evaluations failed — talk to us. We're onboarding design partners with direct founder access: rysh.ai/design-partner

Related: Multi-tenant NATS isolation: how workspaces stay out of each other's business · ##upstream subscribe: watch a teammate's agent work from your own terminal

Try Rysh

Every pane is a shell and an AI agent — install takes one command.

Get started free →