Async Subagents in Hermes Agent: Why a Phone Can Host a Multi-Agent Fleet
Hermes Agent has delegated work asynchronously to subagents since June 2026. Why the small host RAM comes from the cloud, not from the asynchronicity, with a real task example and a measurement from 05.09.2026.
Since June 2026, Hermes Agent lets you hand work to subagents without the parent chat blocking: the task goes out, the chat stays usable, and results arrive later on their own. Many read that change as a comfort feature; I read it as a ticket into a different hardware class. Two things have to be pulled apart that discussions like to conflate: the asynchronicity of the delegation and the offloading of the models into the cloud. Only one of them makes host RAM nearly irrelevant. This post on async subagents on a phone host sorts the two cleanly, walks a real handoff from input to verification, and gives the measurement from 05.09.2026 with its method.
Two questions that get conflated
The first question is: when does the result arrive? Asynchronous means the parent agent no longer waits. Before the change, the chat sat frozen until the child finished; anyone who submitted three research jobs in parallel got them done one after another in the waiting room. Since the change, the task goes out, the parent chat keeps working, and the result lands as soon as it exists. The change is documented: MarkTechPost covered it on 16.06.2026, and the project tracks it as Issue 5586. The official delegation docs, verified on 05.09.2026 in live operation with Hermes v0.20.6, also describe live control: you can steer a running child mid-flight without cancelling it.
For my operation that means I can run research, drafting and review in parallel while the chat stays free for the next step. The waiting time that used to be a blocked chat is now a running pipeline. The docs' list command shows running children with their last activity, and mid-flight correction has already saved me one wasted API call. A note on versions, because documentation ages: I verified these capabilities on 05.09.2026 against the official docs, in live operation with Hermes v0.20.6. What a later version adds on top, I do not predict.
The second question is: where does the child compute? In my stack, the child agents' models run at a cloud provider; the host on the phone only executes orchestration: building contexts, dispatching tasks, collecting results, verifying. This offloading is a separate decision. It can be combined with asynchronous delegation, but it does not have to be. Anyone running local models while delegating asynchronously gets a free chat at full utilization. Anyone using cloud models while waiting synchronously spares the RAM and still blocks. The RAM effect comes from the offloading, not from the asynchronicity, and that mapping was exactly what was missing in the first version of this post.
Asynchronicity decides when a result arrives. The cloud decides where it is computed. The RAM advantage belongs solely to the second question.
What the RAM measurement actually says
Now the number with its fine print. On 05.09.2026, my entire container, meaning Hermes, the gateway and the automation, sat at roughly 380 megabytes, measured as the sum of resident set sizes over ps, a single snapshot without a defined worker load. That is precisely the boundary of validity: the statement holds for the orchestration's idle state, not for a loaded operation. RSS sums can also double-count shared memory, and the value says nothing about the memory free device-wide, which that day was around 1.2 gigabytes of MemAvailable including what Android itself holds.
Under load I have occasionally noted around 450 MB; that observation was not a systematic measurement. A solid number under a defined worker load does not exist in my measurement log yet, and it is listed there as an open item. Until then the honest claim stands: the 380 MB are a documented idle snapshot, taken with a method you can retrace in one minute.
Why the host stays this lean: for the phone, a child agent is a pile of API calls, not a process with a model in memory. Compute sits with the provider; the host organizes. That is why a used Google Pixel 6a with 6 GB RAM for 45 euros suffices as a multi-agent host, without root. This device knows the downside itself: Android comes down hard under memory pressure, which I saw on my own system on 28.08.2026, when a browser ate the memory and processes died. The stack is built for exactly that: watchdogs climb back after kills, the memory survives the kill, and the division of labor holds: Hermes plans, the pi agent builds, Hermes verifies.
A real task from input to verification
Abstractions about delegation only pay off once you have seen a real handoff. The example comes from building the Preiskompass, finished and verified on 28.08.2026, a reselling monitor with an automated SEO blog. The module in question was supposed to generate weekly market analyses and set internal archive links while doing so. The task to the pi child had three parts. The goal: a module that produces the analysis, formats it and delivers it with its own archive links. The constraints: no changes outside the project folder, no new dependencies without justification, network calls only to the specified domains. The acceptance criteria: the test suite runs, defined edge cases are handled, and the result comes back as text output.
The child returned three things: the files with a short rationale per change, the test suite's output as text, and a list of the cases it had not touched. About twenty minutes after the handoff, the build was done. I did not take the success report at face value; I verified it. The test suite ran in its own Python 3.12 venv, seven out of seven tests passed, Ruff lint and the compile check were green. Only this own check against the acceptance criteria lets the task count as done, not the child's self-report. Verification costs minutes; an unverified failed run costs hours, and that is exactly why it stays with the parent agent.
Three operating rules I have learned
First: a child does not inherit the parent conversation; what extra project context it sees, such as embedded workspace files, is governed by the delegation documentation. I measured v0.20.6's behavior on 05.09.2026, not every version's docs. Context goes in completely: file paths, error messages, constraints. Half-handed-over context produces polished self-reports about work that never happened; I paid for that. Second: children do not ask follow-up questions. An ambiguous task gets an assumption, not a question, and a wrong assumption costs a whole run. Third: summaries are self-reports. Anything facing the outside, a file, an upload, a publish, I verify against the goal instead of trusting the child. These rules shift work from correcting to preparing, and preparing is cheap.
Four anti-patterns from operation
First, the vagueness task: fix the error without giving context, and the child fixes something else or invents a cause. Second, the parallel trap: five children at once on tasks that collide in the same directory produce conflicts a single child would not have built. Third, believing the self-report: the child reports success, the file is empty or the upload went nowhere, so only your own checking counts. Fourth, reaching for depth: letting children spawn children when the task does not demand it, and the tree grows faster than the control. None of these patterns costs a new tool; delegation is a craft, not a button.
What the architecture cannot do
Four limits remain, otherwise this would be an ad. First: asynchronous children raise parallelism, not reliability; a child that misreads a source misreads it just as asynchronously. Second: the verification burden moves to the parent agent and, in the end, to the human, because only the human answers for what goes out. Third: latency does not disappear, it redistributes; the chat no longer blocks, but the result still needs its time. Fourth: the costs keep running; a child is its own context with its own requests, three children cost more than one even if they finish faster. Who knows these limits gets a usable tool; who ignores them builds themselves an expensive random number generator.
What is an asynchronous subagent?
A child agent the parent dispatches without waiting for it. The chat stays usable and the result arrives later on its own. In Hermes Agent this happens through the delegate tool, documented in the official delegation docs and verified on 05.09.2026 with Hermes v0.20.6.
How many subagents run in parallel?
The official docs name three parallel children per batch as the default, configurable through max_concurrent_children. What caps it in practice: a child needs a complete context and its own verification of its result.
Why does the host need almost no RAM?
Because the child agents' models run in the cloud, not because the delegation is asynchronous. The host only executes orchestration. My snapshot from 05.09.2026: about 380 MB for the container, measured via ps as an RSS sum, without a defined worker load.
What does the parallelism cost?
Every child is its own context with its own requests. Parallelism saves wall-clock time, not budget, and verification remains a duty of its own that cannot be delegated.
How do you verify child results concretely?
For files by reading them and checking line counts, for uploads by reading back what the other side received, for publishes against the public list. In the Preiskompass example, the test suite ran in its own Python 3.12 venv. Only what has been checked against the goal yourself counts as done.
Where is the change documented?
At MarkTechPost dated 16.06.2026 and in the project tracker as Issue 5586, both linked directly in the sources block. The version in test operation was Hermes v0.20.6, as of 05.09.2026.
About the author
I am Marcel, a graphic designer and the operator of the d4sn3st sites. I run the HUNTER cyberdeck on a used Google Pixel 6a, without root, with cloud models and terminal orchestration. The RAM measurement in this post is my own snapshot from 05.09.2026, taken with ps as an RSS sum and without a defined worker load. The delegation details were verified against the official docs with Hermes v0.20.6 on 05.09.2026. Last fact-checked: 05.09.2026.