Delegate from your editor

You’re deep in a big task in Claude Code. Halfway through, the work surfaces things that are real but separable: a refactor you noticed, a bug in an adjacent module, docs that drifted, a migration that should happen but not now. The usual outcome is a TODO comment that dies, or a context switch that costs you the thread you were holding.

yothere’s MCP surface gives you a third option: your coding agent hands the chunk to your fleet and keeps going. The chunk runs on this same machine, in its own git worktree, on the coding-agent subscription you already have. It blocks before anything outward happens, and the ask lands in your inbox, which you can clear from the cockpit, your phone, or a voice call on a walk. Your main session never loses its place.

The division of labor is deliberate. Your editor session is where decomposition happens: it has the full context of the big task, so it knows what’s separable. yothere never guesses at splitting your work. It takes one well-formed chunk at a time and owns the isolation, the attention routing, and the approval rail.

Setup, once

1. Register the repos your fleet may touch. Registration is explicit human consent; a thread can never bind to a repo you didn’t register.

   yothere workspace add myapp ~/code/myapp

2. Install the MCP extra and register the server with Claude Code (or Claude Desktop):

   pipx install 'yothere[mcp]'
   python -m yothere.mcp_register register --target code

3. Teach your agent the pattern. Paste this into the CLAUDE.md (or AGENTS.md) of the project you work in:

   ## Delegating to the yothere fleet
   
   When the current task surfaces a piece of work that is real but SEPARABLE
   (a refactor, an adjacent bug, docs drift, a cleanup), do not do it inline and
   do not drop it. Hand it to the fleet:
   
   1. Call the yothere `list_workspaces` tool and match the current working
      directory against the registered paths.
   2. Call `spawn_thread` with a one-line, self-contained task description,
      `repo` set to the matched workspace name, and `mode: "planning"` for
      anything sizable (it drafts a plan and blocks for review) or `"auto"`
      for small, obvious chunks.
   3. Tell me in one line what you delegated, then continue the main task.
   
   If `spawn_thread` returns a clarify question or `repo_error`, relay it to me
   instead of retrying. It fails closed on purpose.
   
   At the start of a session, call `board()` and tell me if any delegated
   thread is blocked on me or came back done.

That’s the whole setup. The snippet is a starting point. Tune the delegation threshold to taste.

What happens to a delegated chunk

• A planning chunk drafts a plan and blocks. The plan card shows up in your inbox; approve, edit, or reject it in prose, from the cockpit or by voice.
• A chunk bound to a repo runs in its own git worktree under ~/.yothere, never inside your checkout, so your git status and your editor stay clean. When it’s done you get a diff card whose numbers (files, +/-) are stamped by the host’s git, not the model’s arithmetic.
• Nothing outward happens without you. The worker cannot push, merge, or send; you ship it from the cockpit with one tap.
• Every thread runs under the fleet’s cost caps, and up to five turns advance in parallel while you work.

The four tools

The MCP surface is read/spawn/reply only. There is deliberately no ship or merge tool here. Publishing lives behind one seam, in the cockpit and on the phone, where a human clicks.

Why this beats doing it inline

A separable chunk done inline costs you twice: the context you evict to do it, and the review you still owe it afterward. Delegated, the chunk progresses while you work, and the review happens when you choose: between sessions, from your phone, or on a walk with voice. The unit of value is a thread you steered to done without it ever having owned your attention.