A todo list your agents actually share

Plans that live in a context window die with it. rysh's todo tool is a JetStream KV-backed task list humans and agents both read.

Ask an agent for its plan and you'll get a beautiful numbered list. Ask again after a context reset and you'll get a different beautiful numbered list.

Neither list was wrong, exactly. Both were made up fresh, on the spot, from whatever survived in the context window. That's the dirty secret of agent "planning": the plan usually has the lifespan of a completion. It's prose, not state.

For a one-shot answer, fine. For real multi-step work — the kind that outlives a context window, a laptop lid, or your patience — a plan that evaporates is worse than no plan, because it looks like process while providing none.

Plans as state, not prose

rysh gives every pane a todo tool: a task list the agent manages through explicit tool calls — add items, update statuses, check them off — persisted in JetStream KV.

That last clause is the load-bearing one. rysh runs an embedded NATS server per session, and pane state lives in KV buckets, not in anyone's context window. So the todo list survives everything a conversation doesn't:

• Detach and reattach. Close the laptop, rysh attach tomorrow — the list is exactly where the work stopped.
• Session restarts. Pane state is restored from KV on startup.
• Model context resets. The agent's window can be truncated, compacted, or thrown away entirely; the list doesn't care. It was never in the window.

The plan stops being something the agent said and becomes something the workspace has.

"Share" is the operative word

Here's what changes day-to-day: the todo list isn't the agent's private scratchpad. It's pane state — you read the same list the agent writes, and every mutation is a visible tool call in the pane, like every other tool call in rysh.

That turns the list into a contract, and it enables the single most useful prompting pattern we know for delegated work — the plan gate:

1. "Plan first. Write the steps to the todo list. Don't execute."
2. You read the list. Thirty seconds. You reorder, cut the step that touches prod, add the one it forgot.
3. "Go."

Now execution is legible by default. Reviewing progress means glancing at item statuses, not excavating a transcript. When something stalls, you can see which step stalled — "stuck on 4 of 7" is a debuggable statement in a way that "the agent seems stuck" never was.

Across agents, across resets

The list also earns its keep between agents. rysh agents have workspace-awareness tools: agents_list to see who exists, pane_inspect to look at a pane, session_history to read what happened there. A reviewer agent in pane 3 can check the implementer's todo in pane 1 before opening its mouth, and a nudge travels as pane_send — "pick up item 3, item 2 is blocked on me."

And the list is the natural checkpoint for governed loops. When a judge-decided reset throws away a polluted context, the fresh run doesn't start from amnesia — it re-grounds on the surviving todo: here's what was done, here's what remains. Resume without re-planning. The context was disposable; the plan wasn't. That's the correct assignment of durability.

A few patterns that fall out:

• Plan gate — plan, review, then execute (above).
• Standup — one prompt sweeps the panes and summarizes every list: done, doing, stuck. Your agents just gave a standup nobody had to attend.
• Handoff — end of day, the list is the handoff doc, for tomorrow's you or tomorrow's agent.

Honest edges

What this is not, so nobody buys a fantasy:

• It's per-pane, not a global brain. Each pane owns its list. Cross-pane coordination is deliberate — inspect, read history, send a message — not ambient telepathy. We think that's right: implicit shared memory between autonomous agents is how you get spooky action at a distance; explicit handoffs are how you get audit trails.
• It's infrastructure, not intelligence. A durable list doesn't make plans good. The agent can still write a bad step 4; persistence just means bad step 4 is visible, reviewable, and fixable before it runs — which is where you come in.
• It's your infrastructure. The KV store is the embedded NATS in your session, on your machine or server — self-hostable, like the rest of rysh, which runs on Claude with your own API key. There's no third-party "memory service" holding your team's work plans.

The pitch, minus any magic: agents are already decent at making plans. The missing piece was never intelligence — it was a place to put the plan that outlives the conversation, that humans can read at a glance, and that the next agent (or the next context) can pick up mid-stride.

Turns out that place is a todo list. It just had to actually persist, and actually be shared.

We're recruiting design partners. If your team is delegating multi-step work to agents and wants plans you can read, gate, and resume, come build with us: rysh.ai/design-partner

Related: Judge-decided reset and resume · context store / recall: passing state between agents