47
live coordination rooms
43 of them saw activity in the 30 days before the audit.
The orchestration layer
1,195 work orders, 47 rooms, and the seams where parallel work actually breaks.
Orchestration here is not a chat between agents. It is durable rooms that outlive the sessions that touch them, which is the difference between a system that is running and a system that is being run.
Structure
Work does not live in a conversation. It lives in a room.
The common shape for multi-agent work is a chat: one thread, agents taking turns, state held in the transcript. It reads well in a demo and it fails at the first interruption, because the moment the thread is closed the state is gone and nobody can tell which of the six things that were in flight actually finished.
Gevurah puts work in a coordination room instead. A room is a durable place with its own state, its own history, and its own set of open lanes. Agents join it, write results into it, and leave. The room outlives every session that touched it, which is what makes the difference between a system that is running and a system that is being run.
up to 46
parallel lanes inside a single room
The observed maximum on one room, not a configured limit.
27
rooms swept by the monitor
Every 30 minutes, so that a lane that quietly stopped is noticed by something other than a person remembering to look.
Volume
1,195 work orders over 102 days.
A work order is a unit of delegated work with an owner, a definition of done, and a place its result is expected to land. It is the atom the whole system is measured in, and it is the reason there are numbers on this site at all. You cannot report reliability on work that was never written down as a task.
1,195
delegated work orders
Counted across the live queue and the archives, over 102 days.
929
results on disk
Including results that are orphaned or not linked back to their work order.
96
escalations to a human
An escalation is the system stopping and asking. It is the behaviour the gates exist to produce, so it is counted as a success of the design and not as a fault.
The gap we publish rather than hide
356 of the 1,195 work orders have no linked result record at all, which is 29.8%. That is why the completion figure on this site is always a range of 44.5% to 63.4% and never the upper number on its own. The upper end counts 532 clean results out of the 839 tasks that do have a linked result. The lower end treats all 356 as failures. The honest answer is somewhere between, and we do not know exactly where.
Cost
Parallelism does not fail loudly. It fails at the seams.
When many lanes run at once, the individual lanes usually succeed. What breaks is the space between them: two lanes editing the same file, one lane reading a state a second lane is halfway through changing, a result written into a room after the work that needed it already finished. None of that shows up as an error. It shows up later as an inconsistency nobody can explain.
- Lanes are given non-overlapping ownership. Two lanes that would touch the same surface are sequenced rather than parallelised, even when that is slower.
- Results are written into the room, not into a chat. The room is the place the next lane reads, so a result cannot be lost by closing a window.
- The monitor sweeps for silence. A lane that stops producing is a failure mode that no lane reports about itself.
- Anything irreversible leaves the parallel path. It demotes to a supervised step before it goes out, no matter how many lanes are open.
Limit
The older parallel execution component holds 39 bytecode files and no source, so it is not presented here as a proven autonomous capability. The unsupervised dispatch layer has been switched off since 19 May. The operating mode is supervised parallelism, with a human in front of money, publishing, and customer messages.