Causal threads & parallelism

Two tasks can be topologically independent (neither blocks the other) and still serialise in practice because the same person has to do both. Topolog models that explicitly with causal threads.

What a thread is

A thread is a renewable resource owned by an agent. Every task assigned to that agent runs on one of the agent’s threads. Two tasks that share a thread serialise on it even if the dependency graph says they could run in parallel.

A single-thread agent is the default. A “chef with two sous” setup is three threads: the chef serialises on chef’s thread, but the two sous tasks can run in parallel.

The Causal Threads tab

The Causal Threads tab shows your plan as a swim-lane diagram: one row per thread, time running left to right, every task appearing on the thread that’s scheduled to execute it. It surfaces three classes of problem at a glance:

Over-provisioning: a thread with long stretches of empty time means an agent is sitting idle when they could be picking up other work. Either re-balance, or remove the thread.
Under-provisioning: a thread that’s fully booked for the entire plan duration is your bottleneck. Adding a second thread (a second person) cuts the critical path roughly in half.
Hand-off latency: gaps between adjacent tasks on the same thread tell you the cost of context- switching baked into the plan.

Pools

A pool is “any of these N people can do this”, useful for runners, junior engineers, or a stack of QA. A pool of N members exposes N threads; the scheduler picks the lowest-loaded available thread for each pool task. Pools compose with explicit threading: you can have two sous chefs as individual agents and a pool of three runners on the same plan.

The Parallelism tab

The Parallelism tab plots how many threads are busy at each moment over the plan’s lifetime. A flat line at 1 means the work is entirely serial: a single person grinding tasks in dependency order. A noisy line peaking at 4 then dropping back to 1 means you have a high-throughput middle phase bracketed by single-threaded setup and teardown.

Two derived numbers sit above the chart:

Average parallelism: total work-hours divided by wall-clock duration. A plan with average parallelism 1.0 is single-threaded by construction; anything above 1.0 means you’re actually using your threads.
Maximum parallelism: the busiest moment in the plan. If this matches the number of threads available you’ve saturated capacity at the peak.

When to fold threads

A common authoring mistake: declaring more threads than the dependency graph can use. Two parallel threads with no parallel work for them to do don’t speed the plan up; they just make the Causal Threads tab look noisier. The Parallelism tab is the diagnostic: if average parallelism is well below the thread count, fold extra threads into a pool or drop them outright.

Critical path - threading is the lever for shortening it.
The TOL language - how threads, agents, and pools are declared in the source view.