`session_history`: agents that read the room before acting

The most expensive thing an agent can do is redo work a colleague finished an hour ago. session_history is how rysh agents catch up first.

Pane 1, this morning: you and an agent spend an hour investigating a dependency upgrade. Verdict, after real work: don't. It breaks the auth middleware in a subtle way; there's a note about the workaround.

Pane 3, this afternoon: a fresh agent picks up a related task. Its first suggestion?

"We should upgrade that dependency."

Nothing was wrong with the second agent. It was smart, well-prompted, and completely ignorant — because in most setups, every agent conversation is an island. Decisions made in one window simply don't exist in another. So agents re-litigate settled questions, re-run finished investigations, and occasionally undo each other's conclusions. The most expensive thing an agent can do isn't a bad tool call; it's confidently redoing an hour of work that already happened one pane over.

History is state, so make it addressable

In rysh, a pane's history isn't scrollback trapped in a UI. Every pane keeps per-mode history — shell commands, AI prompts and responses, chat — flowing over NATS topics, with a merged stream interleaved by arrival time, persisted with the pane. History is state.

And state can be queried. The session_history tool lets an agent retrieve the conversation history of any pane in the session: what was asked, what was tried, what was decided. Not a summary someone remembered to write — the actual record.

That flips the failure mode above. Before the pane-3 agent touches anything, it can pull pane 1's history and discover the morning's verdict, the reason, and the workaround. The "don't" survives. Decisions travel.

The read-the-room preamble

session_history is one of a small set of workspace-awareness tools rysh agents get, and they compose into a habit worth institutionalizing:

1. agents_list — who exists in this session? Which panes, which agents?
2. pane_inspect — what's on their screens right now?
3. session_history — what happened before I arrived? What was tried, what failed, what was ruled out?
4. Then act.

Three tool calls of situational awareness before the first opinion. We call it reading the room, because it's exactly what a competent human does when joining work in progress — you skim the thread before replying, or you are the person re-suggesting the dependency upgrade in standup.

Because rysh agents are defined in markdown skill files, you can bake the preamble into the agent itself. A reviewer agent whose standing instructions begin "pull the implementer pane's history before commenting" doesn't review code in a vacuum — it reviews code knowing what the implementer already tried, which is the difference between a review and a list of things the author considered and rejected three hours ago.

A few patterns that fall out:

• The reviewer — reads the implementation pane's history first; critiques with context instead of re-opening settled debates.
• The standup — one prompt sweeps every pane's history and produces: what happened today, what's blocked, what was decided. Nobody attends this standup; it's just written down.
• The archaeologist — "how did we fix this last time?" Shell history is part of the record too, so the answer can be the actual commands that worked, not a reconstruction from memory.

Same room the humans are in

Here's the governance property that makes this more than a convenience: the history an agent reads is the same history you see in the pane. There's no privileged side-channel, no hidden agent-to-agent whisper network. Cross-agent awareness in rysh flows through observable state — histories, panes, visible tool calls — so when an agent acts on something it learned, you can trace exactly where it learned it.

That's a standing design rule in rysh, not an accident: coordination stays inspectable. Two agents agreeing with each other is only comforting if you can audit what they agreed on.

And like everything here, it runs on your infrastructure — histories live in your session, on your machine or server, self-hostable end to end, with rysh running on Claude under your own API key. Your team's working record isn't a third party's training data.

Honest edges

• History ≠ understanding. An agent can read the room and still misread it — skim past the crucial caveat, over-weight a stale decision. Reading reduces redundant work; it doesn't guarantee judgment. Consequential actions still sit behind rysh's approval gates regardless of how well-informed the agent claims to be.
• Session-scoped. session_history covers the panes of your session — it's situational awareness, not an org-wide archive. For knowledge that should outlive sessions, that's RYSH.md; for deliberate handoffs, the context tool. History, memory, handoffs: three different lifetimes, three different tools, on purpose.
• More history, more tokens. Pulling another pane's record spends context. The preamble is cheap; ingesting everything isn't. Point agents at the panes that matter.

The multi-agent future everyone keeps pitching quietly assumes agents that know what the other agents did. Today, mostly, they don't — they're brilliant colleagues who never read the thread. session_history is the unglamorous fix: make the thread readable, teach agents to read it, and keep the reading observable.

Redoing an hour of finished work should be embarrassing for software, too.

We're recruiting design partners. If your team runs multiple agents and is tired of them re-solving each other's solved problems, come build with us: rysh.ai/design-partner

Related: context store / recall: passing state between agents · A todo list your agents actually share