46+ built-in agent tools, part 2: cross-pane coordination and shared memory

Any CLI can give one agent a file tool. Rysh's interesting tools let agents inspect each other, message each other, and share memory.

Part 1 toured the tools every agent platform has some version of: files, search, git, web. Necessary, table stakes, honestly a bit commodity.

This post is about the tools that only make sense because of what rysh is — a multiplexer where every pane is a conversation, agents run side by side with humans, and everything rides a NATS message bus. When your workspace is a set of concurrent conversations, a new question appears that single-agent CLIs never have to answer:

How do agents work together without a human playing message courier?

If you've ever copy-pasted output from one AI session into another, you've been the integration layer. These tools exist so you can stop.

Awareness: knowing the workspace exists

• agents_list — enumerate the panes and agents in the workspace: who's here, what they're called, what they're up to.
• pane_inspect — look at another pane's state and recent output.

This is the foundational shift. A rysh agent isn't a brain in a jar with a file mount — it's a participant in a workspace it can see. The refactoring agent can check whether the test pane is red before claiming the build is fine. An agent you've just briefed can look around: "there's already a pane running the dev server; I won't start a second one."

Mundane-sounding. Structurally huge. Awareness is what separates a collaborator from a very smart batch job.

Communication: panes talking to panes

• pane_send — send input to another pane: a shell command into its PTY, or a prompt into its agent.

Concrete scenario: a build-fixer agent hits a failure caused by a stale generated file. Instead of stopping to tell you — instead of you relaying it — it uses pane_send to ask the codegen agent's pane to regenerate, waits, re-runs the build. The handoff you'd have done by hand, minus you.

And because this is rysh, the governance holds: whatever lands in the target pane plays by that pane's rules. A mutating shell command sent cross-pane still faces the same allowlist and approval gates it would face typed by hand. pane_send is a doorway, not a tunnel under the fence — and both sides of the exchange are visible in both panes.

History: reading the room

• session_history — retrieve the conversation history from any pane in the session.

The context-handoff killer. You've spent an hour in pane 1 debugging a NATS reconnect issue. You spin up a fresh agent in pane 2 for the fix. Its first move: pull pane 1's history and catch up — what was tried, what failed, what you decided. No re-explaining, no "as I mentioned earlier."

Shared memory: three scopes, deliberately

Rysh splits agent memory by lifetime instead of pretending one blob fits all:

• todo — a per-pane task list, JetStream-KV-backed, surviving restarts. The agent's working plan — and you can read it live to see where a long task actually stands. Scope: this task.
• context — store / recall / list against a workspace-level KV store. One agent stores api_design_decisions; another recalls it an hour later. Copy-paste, retired. Scope: this session.
• project_notes — a shared .rysh-notes.md in the repo: conventions, decisions, gotchas — visible to humans, versionable in git. Scope: this project.
• memory_edit — durable workspace memory in RYSH.md: the long-lived facts every future agent should inherit ("staging deploys from release/*; never touch vendor/"). Scope: forever.

Ephemeral, session, project, permanent. Each in the right place — KV for machine state, markdown-in-git for human-auditable knowledge. Your agents' shared brain is a text file you can diff, not a proprietary vector silo.

Utilities that respect the boundary

• clipboard — read what you copied; the cheapest human→agent channel there is.
• list_tools — the agent can enumerate its own toolbox, useful when you've extended it (e.g. via MCP servers).

Why this needed the architecture

Small honest engineering note: these tools aren't a feature you bolt onto a CLI. pane_inspect, pane_send, session_history, todo, context are NATS-backed and registered per-pane in the orchestrator — they work because every pane in rysh is an actor on a message bus with addressable state, and memory rides the same JetStream KV that persists your workspace. The multiplayer tools fall out of the actor architecture; they'd be a rewrite anywhere else.

That's the real difference between part 1 and part 2. Part 1 tools make one agent competent. Part 2 tools make a workspace of agents and humans into a team — visible to each other, talking through governed channels, sharing memory with the right lifetime, all observable in your panes as it happens.

Runs on Claude, your API key, your machine — self-hostable, like everything in rysh.

One agent is autocomplete with ambition. A coordinated workspace is a workforce.

If "agents that stop making me the courier" sounds like your roadmap, help us build it — become a design partner: rysh.ai/design-partner.

More in this series: 46+ built-in agent tools, part 1: files, search, git, and the web · A todo list your agents actually share