Load, capacity, and the Work CPU

This piece introduces my theory of Load and its connection to my Work CPU model. I argue that workers operate like processors with finite capacity, constrained not by time alone but by context switching, fragmentation, and coordination overhead. Kai, built into Kaamfu, measures this load in real time using live behavioral data. By defining Load precisely, we can finally understand true human operating capacity and design organizations that scale without silently exhausting the people inside them.


Today was a good day. Not because something shipped or revenue spiked, but because a mental model finally closed. One of the last missing pieces in my theory of Load snapped into place, and once it did, much of my recent lived experience suddenly made sense.

For years, I have been building the Framework for Autonomization. Central to that effort is the belief that true autonomization depends on understanding how work actually happens for humans. In my Work CPU paper, I argue that workers operate much more like processors than time buckets. A CPU is constrained not by runtime alone, but by thread count, context switching, instruction fragmentation, and coordination overhead. Humans work the same way. Each person has a finite capacity to absorb signals, switch contexts, and execute decisions. If autonomization is the goal, we therefore need a way to reliably measure that load live and in real time.

Kai, built into Kaamfu, is the practical implementation of this idea. It ingests live behavioral data across an integrated toolset and continuously assesses each worker’s Load in real time, not as a judgment, but as a measure of responsibility being carried. Once Load is defined, Capacity becomes a meaningful concept, making it possible to see who is operating within, at, or beyond their true limits.

The breakthrough for me today was adding what I now call Domain Switching. It is related to context switching, but it operates at a higher level. Kaamfu has long tracked task switching, interruptions, time fragmentation, and signal density, yet something was still missing. I could feel it in my own days. Two people could work the same number of hours, with similar intensity, yet one would sustain output calmly while the other would feel crushed under an invisible weight.

The difference is how they move between domains throughout the workday. Take a department head as an example. They may work long hours, but they live almost entirely inside a single domain. Within that domain, they move between subdomains relevant to their function, but the underlying mental model remains largely intact as they shift between tasks. The same rules, vocabulary, and goals apply. Because of that coherence, high-performing leaders can sustain extraordinarily high output even under heavy, domain-specific load.

Now contrast that with the workday of a typical founder, like myself. I move between legal, finance, fundraising, customer support, product design, sales, marketing, and accounting for two companies, in two countries, under two legal systems, with entirely different rules, vocabularies, risks, and time horizons. Each domain carries its own mental gearbox. Switching between them is not a small cognitive step, but a full reorientation.

Whereas context and task switching is changing lanes, domain switching is changing vehicles. As the overloaded founder, my workday feels like being responsible for driving ten different machines, each with its own transmission, controls, and failure modes, and being expected to jump between them flawlessly all day, without any infrastructure to reduce that burden.

Once I added Domain Switching into the Load model, my own exhaustion finally made sense. My total Load was not high because I was inefficient, but because the structure of my responsibilities was intrinsically expensive. This matters deeply for autonomization because if we do not measure Domain Switching, we systematically misjudge people. We might praise endurance without understanding its cost and attribute burnout to weakness instead of structural overload.

In an upcoming release, Kai will be able to see this distinction by differentiating between deep, sustained execution inside a coherent domain versus a fractured load that quietly erodes decision quality over time. That distinction is foundational if we want to build organizations that scale without breaking the humans inside them.

Every organization is in the race to autonomy

Autonomization is not a distant future. The race is on, and the organizations preparing today will be the ones that win tomorrow.

Join my newsletter

Industry news is everywhere. Join my newsletter for practical insights on what to prioritize inside your organization to be ready for what’s happening.