Subagents & IRC

The task tool

task spawns one or more subagents in parallel. Each entry in tasks gets a self-contained assignment string (plus a shared context for the batch) and runs in its own child session. Concurrency is capped by a semaphore; results are delivered as each agent yields (or inline when async execution is off). Each agent’s full output stays reachable as agent://<id>, and its transcript as history://<id>, which the parent can read at any point.

Pass isolated: true to run each task in its own isolated workspace (copy-on-write clone or overlay — APFS, Btrfs/ZFS, overlayfs, ProjFS, or plain copy depending on platform) so concurrent edits don’t collide; patches are merged back when the task succeeds. Tune the strategy with task.isolation.mode.

Bundled agents

Eight dispatchable agents ship with omp. Pass the name in the agent field, or drop your own under ~/.omp/agent/agents/ and .omp/agents/.

Reach for quick_task when the work is mechanical — it runs on the cheap model with minimal reasoning. Reach for task when the work is open-ended and needs full tool access.

How parallelism works

Every task in a single task call starts at the same time and runs independently. Each child sees the other tasks in its IRC peer block so they can talk while they work. When a task finishes it goes idle (then parked after a TTL) — its id stays addressable over IRC, and messaging it wakes it for a follow-up turn.

IRC presence

The irc tool delivers short prose messages between agents in the same process. The main agent is Main; subagents reuse their task id, e.g. AuthMap (AuthMap-2 when the name repeats).

• op: "list" enumerates peers with status (running/idle/parked) and unread counts.

• op: "send" delivers message to to (a peer id or "all") and returns delivery receipts immediately — it never blocks on the recipient. Pass await: true to block until that peer’s reply arrives.

• op: "wait" blocks for an incoming message; op: "inbox" drains pending ones.

There is no on/off setting: irc is available whenever there is someone to message — in every subagent, and in any session that can still spawn subagents.

DMing a finished peer

Finished subagents do not vanish: they go idle.le, then parkedafter a TTL, and stay addressable the whole time. A DM to an idle or parked peer wakes (or revives) it and runs your message as a follow-up turn. A DM to a busy peer is injected as an aside at its next step boundary — and if you sent withawait: true` and the peer can’t reach a step boundary in time, it answers with a short auto-reply generated on a side channel.

1. Peer B calls irc op=send to=A await=true and blocks on the reply.

2. If A is mid-work, the message lands at A’s next step boundary (or triggers the auto-reply path); if A is idle or parked, the DM wakes it.

3. B receives A’s answer and continues.

If a reply doesn’t arrive before the timeout, check inbox or wait again rather than re-sending — the peer may answer once it finishes its current step.

Worked example: two subagents, one DMs the other

The parent fans out an auth-map task and a route-audit task. Route-audit needs the issuer list that AuthMap is producing, so it DMs and waits for the reply.

# parent
task agent=explore context="Auditing auth coverage for src/." tasks=[
  { id: "AuthMap",
    assignment: "Map every token issuance path under src/auth/. \
                 Answer RouteAudit when it pings you." },
  { id: "RouteAudit",
    assignment: "List protected routes under src/routes/. \
                 DM AuthMap for the live issuer list before finalizing." },
]
 
# inside RouteAudit
irc op=send to=AuthMap await=true message="Which issuer does /api/v2 use?"
# -> reply arrives, RouteAudit resumes
 
# parent, after the batch returns
read agent://AuthMap
read agent://RouteAudit

See Tools index for the rest of the inventory and which capability page documents each one.