Agent Parallelism Audit: How to Check Whether Your Parallel Agents Are Real or Inflated
Table of Contents
Two months ago, in OpenClaw 4-Agent Fleet Public, I laid the fleet architecture open and, in the same post, caught 2/3 of the agents having silently been broken for 20 days. I thought I had learned the lesson. This post is a bigger case of the same illness: publicly I kept saying "six brands in parallel", and on the day of the audit I counted the live gateway processes. There was one. The other five brands were empty shells left behind by a migration: the directories were still there, and no process was running.
Chapter 3 of Agentic Design Patterns covers parallelization. The core idea in one sentence: subtasks that can run at the same time should not wait in line. Let them run in parallel, and only then does total time come down and throughput go up.
We read it and nodded. The fleet has 50-odd systemd timers turning at the same time, with research, posting, reconciliation and heartbeats each on its own schedule. This part we really do. And publicly we kept repeating a nice-sounding line: six brands in parallel. Implementation done, we were rather pleased with ourselves. Then we ran an adversarial audit on ourselves. The embarrassment in this chapter is not technical. It is that the line "six brands in parallel" was inflated.
The true half first: the timers really do run in parallel
Where parallelization actually happened needs to be stated first, and it is real. There are 62 timer files on disk, and 23 of them are queued for their next run right now, each firing on its own schedule without blocking the others. That is genuine parallelism.
$ ls ~/.config/systemd/user/*.timer | wc -l
62
$ systemctl --user list-timers | grep -c .timer
23
The problem is a different number. Our public claim was "six brands in parallel": six brands, each with its own agent gateway running at the same time. On the day of the audit I counted the live gateway processes:
$ pgrep -af openclaw-gateway
175 openclaw-gateway
$ cat ~/hermes-bench/data/active_profile
main
One. Only one gateway process was alive, and the profile it served was main. Yet the profiles directory clearly holds six brands:
$ ls ~/hermes-bench/data/profiles/
advisor droppin main mindthread probe quartz
Six directories, six brands, which sounds like six lanes running in parallel. The truth is that those six are just folders. After the migration to the new architecture, each brand's config and state were kept, but only main actually has a gateway running. The other five are empty shells: no process, no heartbeat, old boxes nobody threw out after the move. "Six brands in parallel" rolls off the tongue in marketing. In engineering, only one sixth of it is true.
Spend a few minutes checking whether the parallelism you claim publicly is real
01 Count live processes, not how many are listed in config files Six listed in a directory and six written in a config file does not mean six are running. The denominator of parallelism is always "how many processes are alive right now", never "how many did I configure".
# How many the directory or config says you have
ls ~/hermes-bench/data/profiles/ | wc -l # 6
# How many processes are actually running
pgrep -af 你的-worker名 | wc -l # 1
Red flag: the number listed in a directory or config file is larger than the number of processes actually running.
02 Reconcile the number you tell the public against what is actually alive Take the parallelism figure you state on your website, in decks and to customers, and put it next to the live count you can pull from the system. If the two numbers do not match, the public figure is spin.
# Pull your public parallelism figure from wherever it is written
grep -rniE '六品牌|並行|parallel|brands' 你的官網或文案目錄/
# Then count what is actually alive again; the two sides must match
Red flag: the figure on your marketing page has no corresponding live units you can count in the system.
03 Tell empty shells from live units: look for a recent heartbeat or process Empty shells and live units look alike: each has a directory and a config. The difference is that a live unit has a recent process or heartbeat, while an empty shell is just a pile of static files.
# A live unit has a recent process; an empty shell is only files
systemctl --user is-active 你的-gateway
ps -o etimes= -p "$(pgrep -f 你的-gateway)" 2>/dev/null || echo "沒有行程 = 空殼"
Red flag: only the directory and config exist, and you cannot find any recent heartbeat or process.
How we see it
We did not pretend all six were alive. Once we admitted the inflation, there were only two paths. Either actually bring the five empty shells up (every gateway eats tokens and memory, which is expensive), or change what we say publicly to the truth: one gateway serves main, and the other brands are currently config, not live units. We chose the honest path. Parallelism is a capability for cutting time and raising throughput, not an adjective for putting on a show. 50-odd timers genuinely running in parallel is capability; six brands with only one alive is inflation. The two coexist in the same system, and you have to be able to tell them apart yourself.
Parallelism health checklist
Run this against your own system:
- For the parallelism you claim publicly (brands / workers / gateways), can you count a matching number of live processes?
- Are you counting how many are listed in config files and directories, or how many processes are actually running?
- After a migration or refactor, did you go back and take stock of which units are live and which are leftover empty shells?
- Does every unit you claim is running in parallel have a recent heartbeat or process proving it is still alive?
- Does the parallelism figure on your marketing page match the live units you can count in the system?
This chapter in four sentences
- Whether parallelization is real does not depend on how many units a config file lists, but on how many processes are actually alive. The denominator is live units, not configuration.
- A parallelism figure you state publicly has to trace back to live units you can count in the system. If you cannot count them, it is inflation.
- Migrations and refactors leave empty shells behind: the directory is still there, the config is still there, but no process is running. Empty shells are the best at impersonating parallelism.
- One system can be half real and half spin. 50 timers genuinely running in parallel is capability; six brands with only one alive is inflation. You have to be able to tell them apart yourself.
Source location: systemctl --user list-timers (the 62 genuinely parallel timer files, 23 of them queued); ~/hermes-bench/data/active_profile (the profile served right now = main); ~/hermes-bench/data/profiles/* (six brand directories, only main has a live gateway; advisor / droppin / mindthread / probe / quartz are empty shells left after the migration); live units counted with pgrep -af openclaw-gateway.
This is part of the Agentic Design Patterns × Lobster Fleet series. We follow the book to systematise a solo company's AI agent fleet, then run an adversarial audit on ourselves. Every chapter we claimed to have implemented has been verified again, and the way to check and the way to fix are written up as steps you can run yourself. The credibility of this series comes from our willingness to publicly prove ourselves wrong.
FAQ
How do you check whether AI agents are really running in parallel or only listed in config?
Count live processes, not how many are listed in config files or directories. Six listed in a directory and six written in a config file does not mean six are running. The denominator of parallelism is always 'how many processes are alive right now', never 'how many did I configure'. Count the directories with ls, then count the processes actually running with pgrep; if the listed number is larger than the running count, that is a red flag.
How do you tell a live agent from an empty shell left behind by a migration?
Empty shells and live units look alike: each has a directory and a config. The difference is that a live unit has a recent process or heartbeat, while an empty shell is just a pile of static files. Check the service with systemctl --user is-active, then look up its process with ps. If only the directory and config exist and you cannot find any recent heartbeat or process, it is an empty shell.
Why do empty shells appear after a system migration or refactor?
Migrations and refactors keep each unit's config and state: the directory is still there, the config is still there, but no process is running. After our migration to a new architecture, the profiles directory held six brands, but only main actually had a gateway running; the other five had no process and no heartbeat. After a migration or refactor, go back and take stock of which units are live and which are leftover empty shells.
How do you verify the agent parallelism figure you claim publicly?
Take the parallelism figure you state on your website, in decks and to customers, and put it next to the live count you can pull from the system. If the two numbers do not match, the public figure is spin. A figure on your marketing page with no corresponding live units you can count in the system is a red flag.
What should you do after finding your agent parallelism was inflated?
There are only two paths. Either actually bring the empty shells up, though every gateway eats tokens and memory, which is expensive, or change what you say publicly to the truth. We chose the honest path: one gateway serves main, and the other brands are currently config, not live units.