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 mode they're in.

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. An agent you've just briefed can look around: "there's already a pane called devserver; 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 you relaying it, it uses pane_send to ask the codegen agent's pane to regenerate — you approve the send — then checks back and re-runs the build. The handoff you'd have done by hand, minus the copy-paste.

And because this is rysh, the send is gated: by default, pane_send asks you before it sends anything to another pane. That one approval is the gate — once you say yes, the target pane runs the input as sent, so read it before you approve.

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. First move: have it 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, stored in JetStream KV. The agent's working plan for a long task. 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 workspace.
• 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.

Task, workspace, 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. agents_list, 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.

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