Every tool call visible: observability as the foundation, not a feature flag

Black-box agents ask for trust. rysh renders every tool call in the pane as it happens — because you can't govern what you can't see.

There's a moment with every agentic coding tool where you stop reading and start hoping.

You type the task. A spinner appears. Sometimes a cheerful status line: "Working on it…" Forty seconds later: "Done! I refactored your auth module and updated the tests." And now you're doing archaeology — git diff, scrollback, trying to reconstruct what actually happened from the summary of what was claimed.

I've been building rysh, an agentic terminal multiplexer, around the opposite premise: the agent's work should be exactly as visible as your own. Not summarized after the fact. Not available-on-request in an admin dashboard. Rendered, live, in the pane, while it happens.

What "visible" means, concretely

In rysh, every pane is a conversation — a shell, an autonomous agent, a chat. When an agent works, its tool calls print in the pane like any other terminal output:

> fix the flaky retry test

[tool] grep TestRetryBackoff ./...            → 3 matches
[tool] file_read internal/httpx/retry_test.go
[tool] edit internal/httpx/retry_test.go
       --- a/internal/httpx/retry_test.go
       +++ b/internal/httpx/retry_test.go
       @@ -41,7 +41,7 @@
       -   time.Sleep(10 * time.Millisecond)
       +   clock.Advance(10 * time.Millisecond)
       [preview only — awaiting approval y/n]
y
[tool] test_run ./internal/httpx              → PASS (12 tests, 1.4s)

That's the whole interaction model. The grep it ran. The file it read. The exact diff it wants to apply — colour-coded in your terminal, and not on disk yet — waiting for your yes. The test run, with structured results. You watched the work at the same altitude you'd watch a colleague typing on a shared screen.

No "trust me." No changelog written by the same model that made the change.

Why visibility has to be the foundation

You could bolt a activity log onto a black-box agent and call it observability. It isn't, because three things only exist when visibility comes first:

1. Approval gates need something to approve. "May I edit retry_test.go?" is theater — of course it sounds reasonable, everything an LLM proposes sounds reasonable. Approving an actual diff you can read is governance. rysh's preview-first editing exists because the pane can show you the diff before anything touches disk. (More on the gate design in approval gates.)

2. Loop detection is visibility, formalized. rysh keeps a sliding window of the last 20 tool calls (tool name + a hash of the params) and hard-blocks after three identical calls — the classic agent death spiral where it greps the same file forever. But the human version comes first: you see the pane repeating itself and cancel. The machine backstop just automates what an open pane already made obvious. A spinner can loop for ten minutes before you get suspicious. A transcript can't.

3. History becomes something a teammate can read. Pane conversations persist across detach and restart. There's a session_history tool, so an agent — or a colleague — can pull the full conversation of any pane in the workspace. "What did the agent actually do on Friday?" is a query, not a shrug.

The plumbing, briefly

This isn't a debug overlay bolted onto the side. In rysh's architecture, the visible output is the data path. Every pane publishes its streams over NATS topics — shell output and AI output as separate streams, merged for display by arrival time. The TUI renders from snapshots of that state; there is no privileged hidden channel where the "real" work happens and a sanitized view for the human. The pane is the source of truth.

The separated streams matter more than they sound. When you're reviewing what an agent did, you can read just the AI stream — tool calls, results, responses — without shell noise interleaved. When you're debugging your own commands, you read the shell stream. Same pane, two lenses.

An honest limit

Visibility does not make the model correct. rysh runs on Claude — the same model you may already use elsewhere — and models are confidently wrong sometimes. An open pane doesn't fix that.

What it changes is the price of wrongness. A bad edit caught at diff-time costs one keystroke: n. The same edit caught three commits later costs an afternoon. Observability is not a correctness claim; it's a claim about where on that curve you get to intervene.

Second honest limit: nobody reads everything, and pretending otherwise is how "review fatigue" becomes a security hole. That's why rysh doesn't treat every action equally — reads flow freely, while writes, commits, and unrecognized shell commands are pushed into explicit approval moments. Attention is a budget; the design spends it where reversal is expensive.

The question to ask any agent vendor

Here's the test I'd apply to any agentic tool, including mine:

"Show me the worst thing your agent did last week — the full action sequence, not the summary."

If the answer is an aggregate dashboard, a filtered log in an admin console, or an after-the-fact narrative generated by the same model that made the mistake — that's not observability. That's a press release.

If the answer is "scroll up," you're in the right kind of tool.

rysh is in private beta — self-hostable (your infra, your Anthropic key), built on Claude. We're recruiting design partners: free access, a direct line to the founder, your feedback shapes the roadmap. If "we can't see what the agent is doing" is the sentence blocking AI adoption at your company, apply here.

Related: Approval gates: deciding which operations deserve a human · Is it safe to let an agent loose on your systems? An honest checklist