| name | delegating-to-omp-rpc |
| description | Use when you want to hand a coding or research task to a second, persistent agent instead of doing it yourself — offloading long or independent work, running a cheaper/different model alongside your own, or keeping a separate context that accumulates across a series of related tasks. |
Delegating to omp-rpc
Overview
omp-rpc is a persistent second agent you can drive from the shell. You
(the driving agent) send it scoped tasks with omp-rpc send, read the streamed
result, and iterate — its session remembers earlier turns, so a delegation is
a conversation, not a series of cold prompts. Mechanics of each command live in
the using-omp-rpc skill; this skill is about when and how to delegate well.
When to use
- A sub-task is self-contained and you'd rather not spend your own context on
it (bulk edits, a focused investigation, boilerplate, a first-draft).
- You want a second opinion or a different model's take in parallel.
- You want work done under a separate accumulating context (e.g. iterating on
one file over several turns) without polluting yours.
Not for: tasks needing your live conversation context (the sub-agent can't see
it — you must put everything it needs in the task text), or trivial one-liners
you can just do.
The delegation loop
omp-rpc status
omp-rpc models --json
omp-rpc start --models "<sel>,<sel>" --model <sel> --cwd /path/to/repo
omp-rpc send "Task 1 — <clear, self-contained instruction>"
omp-rpc send "Task 2 — builds on task 1"
omp-rpc stop
Doing it well
- Point
--cwd at the repo the sub-agent should work in, so its file tools
operate on the right tree.
- Make each task self-contained. The sub-agent has no access to your
conversation — restate the goal, name the files, include constraints.
- One task at a time. The session is single-flight; wait for a
send to
return before the next. omp-rpc status shows busy.
- Steer instead of waiting when a running turn is going the wrong way:
omp-rpc steer "actually, skip the tests dir" injects mid-turn; omp-rpc abort
cancels it outright.
- Discover models, don't recall them. Selectors live in omp's catalog and
change over time — run
omp-rpc models --json and copy exact selectors; never
invent a selector from memory.
- Match the model to the task, live. Scope the session to a few models at
start (--models), then switch among them per turn — a big-context model for
a sprawling session, a coding-tuned one for a focused turn — with
omp-rpc model <sel>. No restart; the accumulated context is preserved. Switches
are limited to the session's scope.
- Capture cleanly when you'll parse the output:
omp-rpc send -q "..." sends
the answer to stdout and thoughts/tools to stderr. --json gives
{stopReason, usage}.
- Review before trusting. It runs a different (often smaller) model with
auto-approved tools; read its diffs/output rather than assuming success.
Safety when delegating
Destructive shell commands are auto-denied and stop won't discard in-flight
work — but the guard is a net, not a sandbox. For untrusted or high-risk tasks,
start the session with --cwd inside a throwaway checkout or container. Details
in the using-omp-rpc safety reference.
Common mistakes
- Assuming shared context. It sees only the task text you send. Missing
context → wrong output.
- Firing a second task while busy. Returns a busy error; serialize your sends
(or
steer into the running one).
- Leaving a session running on the wrong repo. Its
--cwd is fixed at
start; to work elsewhere, stop and start again there.
