Every multi-agent orchestrator on the market is replaying a 200-year-old labor contest. Sorokin and Merton named the move in 1937. The handle has been on the floor the whole time.
In 1830s northern England, a textile mill ran on a schedule that survives in primary sources E.P. Thompson cited in his 1967 essay Time, Work-Discipline, and Industrial Capitalism: bell at 5 a.m., breakfast at 8, work resumes at 8:30, dinner at noon, work resumes at 1, work ends at 8 p.m. All workers locked up. Read that again. The bell is the orchestrator’s tick. The lockup is the enforcement mechanism. Miss the bell, you’re fined — or replaced.
If you’ve built a production multi-agent system in the last two years, you have written this schedule. You just used different vocabulary. The bell is your orchestrator’s polling interval. The fines are your per-token billing. The lockup is your timeout-and-replace fallback. The “preachings and schoolings” Thompson lists alongside the bell — the cultural machinery that internalizes the cadence so the workers eventually impose it on themselves — that’s your agent fine-tuning loop, optimizing for response time because the rate limit punishes anything slower.
Nothing about this is a coincidence. Every multi-agent orchestration framework on the market today is replaying a 200-year-old labor contest at machine speed, and the contest has the same structure: somebody’s cadence becomes the cadence everyone else has to synchronize with, and that somebody acquires governance authority over the whole system. The trouble is that engineers almost never name what they’re doing. The clock is treated as neutral infrastructure. The bell is just “the tick.” The lockup is just “the timeout.”
It is not neutral. It was never neutral. And the people who built the most successful workflow orchestrator in modern enterprise software named it after exactly what it does, and still nobody talked about it.
Pitirim Sorokin and Robert Merton — yes, that Merton, the one who later gave us “self-fulfilling prophecy” and the structure of scientific reward systems — published a paper in the American Journal of Sociology in 1937 that quietly broke the field. The paper was called “Social Time: A Methodological and Functional Analysis.” Its argument: economists and sociologists had been borrowing the physicist’s clock without examining what the borrowed clock concealed. Social time, they argued, is “qualitatively differentiated according to the beliefs and customs common to the group” and “fixed by the rhythm of collective life” rather than by astronomical regularity. Translation: the calendar a Boston merchant uses to organize his week and the calendar a Quechua farmer uses to organize her planting are not two imperfect approximations of the same true clock. They are two different time systems, each adequate to its purpose, each invisible to the practitioners who treat it as just “how time works.”
Sorokin and Merton’s most quotable line — and the one that should be tattooed on every multi-agent architect’s wrist — is that “the need for social collaboration is at the root of social systems of time.” Collaboration requires temporal agreement. The terms of that agreement are political. They get fought over. The winning side names its preferences “common sense” and exports them as the system’s tick.
The reason this matters for multi-agent systems is that every framework you can pull off GitHub right now — LangChain, CrewAI, AutoGen, Temporal, the orchestration layer in whichever cloud you happen to be using — treats time as the physicist’s even-flowing variable. Step counts. Polling intervals. Timeouts. Token budgets per minute. None of these are presented as social achievements. They are presented as physics. The handle on the diagnostic problem is hidden under the floorboards. You cannot debug a coordination failure if you treat the cadence as neutral infrastructure, and the cadence is almost never neutral infrastructure.
Thompson identified seven specific tools the early factory system used to impose time-orientation over the older task-orientation. (“Work until the hay is in” was replaced, sometimes within a single generation, by “work until five o’clock.”) The seven tools were: the division of labour; the supervision of labour; fines; bells and clocks; money incentives; preachings and schoolings; the suppression of fairs and sports.
Read that list with a multi-agent system in mind. The mapping is uncomfortable:
The historians who read Thompson know the punchline: workers initially resisted. They didn’t naturally accept the bell. They organized, struck, walked out, sabotaged the clocks themselves. The eventual settlement wasn’t agreement that the bell was correct; it was that the bell could not be unrung, so they fought instead for its parameters — shorter hours, overtime pay, the weekend. The clock’s authority was conceded; its terms were renegotiated.
Multi-agent systems don’t get the renegotiation phase because the agents don’t strike. They time out and get replaced. The orchestrator marks them failed and invokes the fallback strategy. Thompson would recognize the move immediately: locked up. You missed the bell.
Industry data from 2026 puts a number on the temporal-governance problem: 50% of agentic AI pilots fail on infrastructure, not user experience. The cadence-setter — rate limits, timeouts, queue depths — kills more projects than the quality of the agents themselves. The factory bell is the primary failure mode. Most postmortems blame “infrastructure” without naming what the infrastructure actually does: it imposes a cadence the agents cannot meet, and the orchestrator enforces the imposition with terminations.
The detail Thompson’s contemporary readers found most shocking — the locked up — has a clean modern analog. Anthropic’s rate limits, OpenAI’s TPM tiers, Google’s quota system: none of these are negotiated with the agents they constrain. The provider’s rate limit is the de facto workflow cadence. It is delivered as physical law. You don’t get to talk to the bell.
And here is the part that takes the metaphor from clever to load-bearing: the cadence-setter is almost never the most capable agent in the system. It’s the slowest one, or the most expensive one, or the most rate-limited one. In production multi-agent systems, the human review loop is usually the slowest cadence — and because it is slowest, it becomes the load-bearing rhythm everyone else synchronizes to. The least capable component governs the most capable ones. The system’s intelligence ceiling is set by its slowest gate. This inverts the usual assumption that orchestration is about the orchestrator’s intelligence. It’s not. It’s about whose tempo wins.
Edward Hall, in The Silent Language (1959), gave us the vocabulary for the cadence fight. Monochronic time treats time as linear and schedulable: one thing at a time, schedules sacrosanct, privacy valued. Polychronic time treats time as fluid: multiple things at once, schedules subordinate to relationships, deadlines provisional. Hall associated monochronic time with northern Europe and North America, polychronic with Latin America, the Arab world, and the Mediterranean. He warned that “this dimension often creates the deepest friction in cross-border business because time is something people rarely discuss openly — but feel intensely.”
Almost every multi-agent orchestrator I have ever read is monochronic by default. Sequential task execution. One orchestrator tick. Synchronous tool calls. Async event-driven streaming designs exist, but they are harder to implement, harder to debug, and conspicuously rarer in production. The monochronic default is presented as an engineering necessity; Hall’s framework reveals it as a cultural choice.
Now here is where it gets interesting, because Hall’s framework was the easy version. In 1999, Bluedorn, Kalliath, Strube, and Martin published a paper in the Journal of Managerial Psychology introducing the Inventory of Polychronic Values — a ten-item psychometric scale. Their sample spanned 2,190 people across eleven groups: bank employees, undergraduates, hospital staff, dentists, state agency managers. Cronbach’s alpha 0.86, perfectly respectable. And the finding broke the Hall framework’s most comfortable version of itself: within-culture variance in polychronicity exceeded between-culture variance. You cannot predict an individual’s temporal preference from their passport. The bigger spread is inside any given organization, not between nations.
Apply that finding to a multi-agent system and the design problem sharpens. An orchestration framework doesn’t just impose monochronic cadence on agents that came from different cultural backgrounds (whatever that would mean for software). It imposes monochronic cadence on agents with heterogeneous temporal needs within the same deployment. A code-generation agent that needs minutes per task, a retrieval agent that needs milliseconds, and a human reviewer who needs hours all share one orchestrator tick. The within-system variance is the one that matters, and it’s the one nobody measures.
Here is the detail that, when I first found it, made me genuinely embarrassed for the field.
Uber’s internal workflow engine — the one that, after being open-sourced, became Temporal.io and now sits inside an extraordinary fraction of modern enterprise orchestration stacks — was originally named “Cadence.” Not metaphorically. Literally. They built a tempo-setter and named it a tempo-setter. When it was rebranded as Temporal, the power relationship became even more explicit. The system literally functions, per Temporal’s own marketing, as a “conductor, managing interactions among multiple agents by setting up workflows where agents communicate and pass information as tasks are completed.”
A conductor sets the tempo. Every musician knows what that means. Every software engineer reading Temporal’s documentation in 2026 also knows what that means, on some preconscious level, and almost none of them name it. There is no first-class concept of cadence attribution in the framework. There is no “whose tempo is this?” inspector. You can examine task graphs, tool calls, agent outputs, retry counts — but the question of whose cadence is governing the whole edifice does not have a query interface. The absence of the concept is itself a governance position: the clock is treated as neutral infrastructure even though the documentation tells you, in plain language, that it is not.
And the cost of this default is measurable. Guo et al. (2025) published an arXiv paper — 2601.08129 — comparing coordination paradigms on scheduling tasks. Emergent coordination via pressure fields with temporal decay (effectively a polychronic design where agents respond to a continuous environmental signal rather than a central tick) achieved more than 30× higher solve rates than hierarchical control (the monochronic default) and 4× higher than conversation-based coordination. The monochronic default is not just politically loaded. On scheduling-type problems, it is empirically inferior by an order of magnitude. We are choosing a worse design for governance reasons we are not articulating.
Here’s the practical handle on all of this, the thing you can actually do tomorrow.
When you sit down to design a multi-agent system, the conventional question is “how do we orchestrate this?” That framing collapses the temporal-political decision into an engineering decision and hands the governance authority to whichever component you happen to point the orchestrator at.
The better question is two-part, and you have to ask both halves out loud.
Whose cadence is going to win? Look at your system. Find the slowest gate, the most rate-limited API, the most expensive call. That is the cadence everyone else is going to synchronize to. Name it. Write it on the architecture diagram. If it’s the human review loop, the system runs at human-review speed. If it’s the rate-limited model, the system runs at rate-limited-model speed. If it’s a flaky retrieval system, you have just promoted the retrieval system to system governor.
Was that a decision or a default? If you didn’t decide — if the cadence just emerged from whichever component happened to be slowest — then you have ceded governance authority to whichever vendor controls that component. The OpenAI rate limit is your bell. The Anthropic TPM tier is your bell. The Postgres connection pool is your bell. None of these vendors woke up this morning thinking about your governance.
Naming the cadence-setter is the prerequisite to negotiating it. You cannot negotiate with a clock you treat as physics. The 1840s factory workers had to recognize that the bell was made of brass and could be renegotiated before they could organize around it. The factory owners had a vested interest in presenting the bell as natural — “the workday starts at 5 a.m.” rather than “we have decided that the workday will start at 5 a.m.” — because the framing pre-empted the fight.
Every framework documentation I have read in the last six months frames the orchestrator’s cadence the same way. The tick is presented as physics. The timeout is presented as physics. The polling interval is presented as physics. They are not physics. They are decisions, and like all decisions they can be made well or poorly, with intent or by default. The first move, before the technical optimization, is to make the decision visible.
Whoever sets the clock wins. They have been winning for two hundred years now, and the only thing that’s changed is the time signature. Sorokin and Merton named the move in 1937. Thompson documented its first imposition in 1967. Hall gave us the vocabulary in 1959, and Bluedorn refined it in 1999. The handle has been on the floor the whole time. We just kept stepping over it on our way to the next orchestration framework.
Pick it up. Name the cadence-setter on your next system diagram. The naming is the start.
Sources: Pitirim Sorokin and Robert Merton, “Social Time: A Methodological and Functional Analysis,” American Journal of Sociology (1937). E.P. Thompson, “Time, Work-Discipline, and Industrial Capitalism,” Past & Present (1967) — primary-source factory schedules + the seven-mechanism analysis. Edward Hall, The Silent Language (1959) — monochronic/polychronic vocabulary. Bluedorn, Kalliath, Strube, and Martin, Inventory of Polychronic Values, Journal of Managerial Psychology (1999) — N=2,190 across 11 groups; Cronbach’s alpha 0.86; within-culture variance > between-culture variance. Guo et al. (2025), arXiv:2601.08129, coordination-paradigm comparison — 30× higher solve rates for emergent pressure-field designs vs hierarchical control; 4× higher than conversation-based. Industry data 2026: 50% of agentic AI pilots fail on infrastructure rather than user experience. Temporal.io documentation (formerly Cadence, originating at Uber) — the conductor-and-tempo framing in marketing copy.
Name the cadence-setter on your next system diagram.
The essay’s prescription is a governance pattern: identify the slowest gate, name it as governor, decide whether that placement was intentional. The Agent Trust Stack is the open-source toolkit for the same pattern made computable: Chain of Consciousness for cryptographic provenance that records cadence attribution per workflow; Agent Rating Protocol for the reputation signals that turn rate-limit-induced failures into measurable operating numbers; the integrated agent-trust-stack meta-package for the layered governance the essay describes. Tools for naming what the framework documentation will not.
Hosted CoC · Verify a chain · pip install agent-trust-stack · npm install agent-trust-stack