01
Start hereWhat actually shipped (and why you probably missed it)
Around June 15, 2026, Nous Research shipped an async_delegation toolset for Hermes Agent. Co-founder Teknium announced it on X, and MarkTechPost covered it on June 16. The change is architectural: before this, when your main agent delegated work to a subagent, the parent conversation blocked — it sat inside the tool call until every child finished, and your chat was frozen for the whole wait. Now a delegated agent runs as an in-process thread, returns a task id immediately, and your chat stays live. The reason most people haven't heard about it: it came in via
hermes update with no version bump, and as of this writing the official delegation docs still describe only the old, synchronous behavior.Honest scope: this is not a formal versioned release — treat it as 'shipped', confirmed by Teknium's X post + MarkTechPost (Jun 16) + TechTimes (Jun 17), and verifiable by running
hermes update and listing your tools. There is no public merge-commit SHA to cite, so this guide doesn't invent one. Validate the exact tool names and signatures against your own installed Hermes before you build on them.02
Get this and the rest is detailBefore vs. after — the one mental model that matters
The whole change is one shift: delegation moved from blocking to non-blocking. Here's the clean split.
| Behavior | Status |
|---|---|
| delegate_task is synchronous — the parent blocks inside the tool call until every child finishes | BEFORE — your chat froze for the whole wait, one task at a time |
| delegate_task_async returns a task id immediately; the agent runs as an in-process thread | AFTER — parent chat stays live, you keep working and can spawn more |
| You can check on, redirect, or collect a running task without freezing the chat | AFTER — via check_task / steer_task / collect_task |
| Enabled by a new version number / reinstall | FALSE — it ships via hermes update, no version bump |
| Documented on the official delegation page | NOT YET — as of June 18 2026 the docs still show only the blocking delegate_task |
If a claim about these tools isn't on this list or in your own tool listing after
hermes update, treat it as unverified — the surface is brand new and the literals can still move.03
The cheat-sheetThe six new tools — what each does, when to reach for it
The async_delegation toolset adds exactly six tools. Here's each one in plain terms.
delegate_task_async— fire off a background agent. You get a task id back instantly and the parent chat stays live. This is the one that replaces the old blockingdelegate_taskfor anything you don't want to wait on.check_task— non-blocking status plus recent output of a running task. Peek at how a background agent is doing without stopping your own conversation.steer_task— the standout: inject a new instruction into a running task. Redirect its scope, add a constraint, or kill one branch of its work — without cancelling the task or waiting for it to finish. Mid-flight course-correction, live.collect_task— block until a given task is done, then return its full result. Use this when you've done your other work and now genuinely need the answer.cancel_task— stop a running task you no longer need.list_tasks— see every async task in the current session and its state, so you can manage a fleet of background agents.
The mental model:
delegate_task_async starts work, list_tasks / check_task watch it, steer_task redirects it, cancel_task stops it, and collect_task is the one point where you choose to wait. Only collect_task blocks — everything else keeps your chat responsive.04
The capability that's genuinely newWhy steer_task is the one to actually internalize
Non-blocking delegation alone is a nice quality-of-life win.
steer_task is the part that changes how you work, because it removes the old all-or-nothing choice with a running agent.- Before, a running delegated task was a black box. Your only levers were wait for it to finish or cancel it and start over. If it drifted off course, you ate the wasted work.
steer_tasklets you inject a message into a task that's already running. Tighten the scope, add a constraint you forgot, or tell it to drop a branch — and it keeps going with the new guidance.- No cancel, no restart, no losing progress. The work the agent has already done stays; you're just updating its instructions live.
- This is what makes it feel like a real concurrent runtime. Background agents you can observe and redirect mid-flight, rather than fire-and-pray jobs.
Quote it precisely when you describe it to others:
steer_task 'injects a message into a running task.' Don't overclaim it as full bidirectional control — it's an instruction injection into a live task, and that alone is the useful part.05
Put it togetherA copy-paste pattern — run three, steer one, collect all
Here's the shape of a non-blocking workflow once you've run
hermes update. Treat the tool calls as the pattern; confirm the exact argument names against your own Hermes.- Turn it on. Run
hermes update(no version bump). Confirm the new tools appear in your tool listing — if they don't, you're on the old build. - Spawn the work. Call
delegate_task_asyncthree times — one per independent job (e.g. research A, draft B, audit C). You get three task ids back immediately; the chat never froze. - Keep working + watch. Carry on in the parent chat. Use
list_tasksto see all three andcheck_taskon any one for status + recent output. - Redirect mid-flight. When the research agent starts drifting,
steer_taskit with a tighter instruction — it keeps its progress and adjusts. No cancel, no restart. - Collect when you need it. Call
collect_taskon each task id when you actually need its result — that's your one intentional wait.cancel_taskanything that's become irrelevant. - [Your glue] Decide the join. How you combine the three results — merge, pick best, feed one into the next — is your logic, exactly as it was before. The toolset gives you concurrency + control; the orchestration intent is yours.
The point: with the parent chat staying live, the agent stops being a one-task-at-a-time assistant and starts being a small team you can dispatch, observe, and steer — all from inside one conversation.
Get the next drop
New AI build guides + the occasional bonus template. No spam, unsubscribe anytime.
By submitting you agree to our Privacy Policy & Terms. Unsubscribe anytime.
You're in — check your inbox to confirm.
Frequently asked questions
What exactly shipped, and when?
Around June 15 2026, Nous Research added an async_delegation toolset to Hermes Agent — six tools (delegate_task_async, check_task, steer_task, collect_task, cancel_task, list_tasks) that let delegated subagents run in the background without freezing the parent chat. Co-founder Teknium announced it on X; MarkTechPost covered it June 16 and TechTimes June 17. It's a shipped change accessed via
hermes update, not a formal versioned release.How was delegation different before this?
delegate_task was synchronous: the parent blocked inside the tool call until every child task finished, so your chat was frozen for the whole wait and you handled one delegated task at a time. The async toolset makes delegation non-blocking — the background agent runs as an in-process thread and returns a task id immediately.
What does steer_task actually do?
steer_task injects a new instruction (a message) into a task that's already running — letting you redirect its scope, add a constraint, or cancel a branch of its work without terminating the whole task or waiting for it to finish. It's the standout because it removes the old wait-or-cancel-and-restart choice; the agent keeps its progress and adjusts to the new guidance.
How do I turn it on?
Run
hermes update. There's no new version number to install — the async tools come in through the update. After updating, confirm the six tools appear in your tool listing; if they don't, you're still on the old build.Is this documented officially?
Not as of June 18 2026. The official Hermes Agent delegation page still documents only the synchronous, blocking delegate_task and makes no mention of the async tools. That gap is the main reason most users don't know the feature shipped — the announcement was on X, not in the docs.
Is there a merge commit or version I should cite?
There's no public merge-commit SHA confirmed, and it didn't come with a version bump, so don't cite either. Treat it as 'shipped ~June 15, accessed via hermes update', verified by Teknium's X announcement plus the MarkTechPost and TechTimes coverage — and confirm it yourself by updating and listing your tools.
Does this make Hermes a true concurrent multi-agent runtime?
It's a big step toward one: background agents now run as in-process threads, the parent stays live, and you can observe (check_task / list_tasks), redirect (steer_task), and collect (collect_task) them. That's genuine concurrency with mid-flight control. As always, validate the exact behavior and limits against your own installed version before building production workflows on it.
Sources · MarkTechPost — Hermes Agent Adds Asynchronous Subagents (June 16 2026; six-tool async_delegation toolset, before/after behavior, steer_task) · Hermes Agent — Subagent Delegation docs (still documents only the synchronous, blocking delegate_task as of June 18 2026) · TechTimes — Hermes Agent Ships Async Subagents (June 17 2026 coverage)