“He will win who knows when to fight and when not to fight. He will win who knows how to handle both superior and inferior forces.” — Sun Tzu, The Art of War

Sun Tzu wrote those words around 500 BCE, codifying principles that Chinese armies had refined over centuries. But buried in his treatise on generalship is something more fundamental than tactics: an information architecture for coordinating thousands of soldiers across contested terrain with nothing but signal flags, drums, and runners.

He didn’t have radios. He didn’t have GPS. He certainly didn’t have mesh networks. And yet his armies coordinated at scales that modern autonomous systems programs struggle to match.

What did he understand that we’ve forgotten?

Bamboo slips containing Sun Tzu's Art of War, discovered in the Yinqueshan Han Tombs in 1972. Bamboo slips containing Sun Tzu’s Art of War, discovered in 1972. The oldest surviving copy of the text, sealed in a tomb around 134 BCE. Photo: Gary Todd / Wikimedia Commons / Public Domain

The Modern Prejudice Against Hierarchy

In contemporary discussions of autonomous systems, hierarchy is treated as an obstacle—bureaucratic overhead inherited from rigid institutional thinking. The prevailing assumption is that flat, decentralized architectures are inherently more agile, more resilient, more modern.

This assumption is wrong.

Hierarchy isn’t about authority. It’s about information flow. And it turns out that human organizations discovered the optimal information architecture for large-scale coordination roughly five thousand years ago.

The Cognitive Constraint

In 1956, psychologist George Miller published one of the most cited papers in cognitive science: “The Magical Number Seven, Plus or Minus Two.” His finding was simple but profound: human working memory can only hold about seven items at once.

This isn’t a software limitation we can patch. It’s a hardware constraint baked into the architecture of the human brain. And it explains why every military organization in history—from Roman legions to modern infantry battalions—has converged on the same basic structure: small teams of 4-8 people, led by individuals who report to leaders coordinating 3-5 teams.

A Roman centurion didn’t track 80 individual soldiers. He tracked 10 squad leaders. A modern Army company commander doesn’t manage 120 soldiers directly—she coordinates with 3-4 platoon leaders who each manage 3-4 squad leaders.

This pattern isn’t bureaucratic tradition. It’s cognitive load management.

Hierarchy as Compression

Here’s the insight that matters for autonomous systems: hierarchy is a compression algorithm.

When a platoon leader reports to the company commander, they don’t transmit the position, status, ammunition count, and physiological state of every soldier under their command. They transmit a summary: “Second platoon is combat-effective, in position at grid reference XY, ready to execute.”

That summary compresses perhaps 40 individual data points into one capability statement. The company commander can then hold 3-4 such summaries in working memory—exactly what cognitive science predicts—and make decisions at their echelon.

This compression happens at every level of the hierarchy. Squad leaders summarize fire teams. Platoon leaders summarize squads. Company commanders summarize platoons. The information that flows upward is aggregated, with detail appropriate to the decision-making authority at each level.

Sun Tzu understood this intuitively:

“If words of command are not clear and distinct, if orders are not thoroughly understood, the general is to blame. But if his orders are clear, and the soldiers nevertheless disobey, then it is the fault of their officers.”

Clear orders flowing down. Summarized status flowing up. Coordination happening laterally between peers. Three information flows, each optimized for its purpose.

The Mathematics of Flat vs. Hierarchical

Let’s make this concrete with some numbers.

In a flat mesh network where every node must coordinate with every other node, the number of communication links grows as n(n-1)/2. For practical purposes, this is O(n²)—quadratic scaling.

Nodes Links (Flat Mesh)
10 45
20 190
100 4,950
1,000 499,500

Now consider a hierarchical structure where each node only communicates with its immediate superior and 4-6 peers. The communication complexity drops to O(n log n).

Nodes Links (Hierarchy)
10 ~23
20 ~53
100 ~332
1,000 ~4,983

At 1,000 nodes, the hierarchical approach requires roughly 1% of the communication bandwidth. This isn’t a marginal optimization—it’s the difference between systems that work and systems that collapse under their own coordination overhead.

Relief from Trajan's Column showing Trajan reviewing his troops, circa 113 CE. Trajan reviews his troops from a tribunal, flanked by officers—hierarchy in action. The column depicts 2,662 figures across 155 scenes, organized by cohort and century. Photo: R.B. Ulrich / trajans-column.org

Three Flows, Not One

The hierarchy insight isn’t just about reducing bandwidth. It’s about recognizing that coordination requires three distinct information flows, each with different characteristics:

Upward: Aggregation. Raw state becomes summarized capability. “I have 12 UAVs with 47% average battery” becomes “ISR coverage available for 3 hours.” The next echelon doesn’t need to know which specific platforms are assigned—they need to know what the team can do.

Downward: Dissemination. Commander’s intent becomes specific tasking. “Maintain situational awareness on Route Tampa” gets translated at each level into increasingly specific guidance, until individual platforms receive actionable instructions appropriate to their capabilities.

Lateral: Coordination. Peers synchronize directly without routing through higher echelons. Adjacent squads coordinate their boundaries. Neighboring platoons deconflict their movements. This happens at machine speed, without burdening the hierarchy with routine coordination traffic.

        ┌─────────────────┐
        │   Commander     │
        │   (Intent)      │
        └────────┬────────┘
                 │
    ┌────────────┼────────────┐
    │            │            │
    ▼            ▼            ▼
┌───────┐   ┌───────┐   ┌───────┐
│ Plt 1 │◄─►│ Plt 2 │◄─►│ Plt 3 │  ← Lateral coordination
└───┬───┘   └───┬───┘   └───┬───┘
    │           │           │
    ▼           ▼           ▼
 [Squads]    [Squads]    [Squads]

    ▲           ▲           ▲
    │           │           │
    └───────────┴───────────┘
         Aggregated status
            flows UP

These flows map directly to military doctrine because doctrine encodes the patterns that work.

Sun Tzu again:

“The control of a large force is the same principle as the control of a few men: it is merely a question of dividing up their numbers.”

Divide, aggregate, coordinate. The pattern scales because it was designed to scale.

What This Means for Autonomous Systems

If hierarchy is evolved communication optimization, then treating it as bureaucratic overhead is an architectural mistake. The challenge isn’t to eliminate hierarchy—it’s to implement it properly.

This means:

Design for aggregation. Platforms should advertise capabilities, not just positions. “I can provide persistent surveillance for 4 hours at 10km range” is more useful to a coordination layer than raw telemetry.

Respect cognitive limits. Human operators in the loop should see summarized team capabilities, not individual platform states. If your interface requires an operator to track 20+ entities simultaneously, you’ve exceeded human cognitive capacity.

Enable lateral coordination. Peers should be able to synchronize directly without routing through a central coordinator. Boundary management between adjacent teams is a local problem that should be solved locally.

Preserve authority at appropriate echelons. Not every decision should flow to the top. Define what can execute autonomously, what requires approval, and what demands human judgment—then encode those policies into the coordination architecture.

The Oldest New Idea

We tend to assume that modern problems require modern solutions. But the coordination of large numbers of heterogeneous agents across contested environments with unreliable communications isn’t a new problem. It’s arguably the oldest problem in organized human activity.

Military hierarchies evolved over millennia precisely because they solve this problem. The Roman legion could coordinate 5,000 soldiers across miles of battlefield with nothing but flags and horns. The Mongol army could execute complex maneuvers across hundreds of miles with relay riders.

These weren’t primitive solutions waiting for technology to replace them. They were sophisticated information architectures optimized by centuries of selection pressure. The organizations that got coordination wrong didn’t survive to pass on their patterns.

Sun Tzu’s armies didn’t need mesh networks. They understood something more fundamental: that hierarchy isn’t the enemy of agility—it’s the precondition for it.

“In war, the way is to avoid what is strong, and strike at what is weak.”

Flat coordination architectures are strong in small teams. They are weak at scale. Hierarchy is the way to avoid that weakness.

The ancients figured this out with bronze swords and signal fires. Perhaps it’s time we remembered what they knew.


(r)evolve is building HIVE Protocol, open coordination infrastructure for human-machine-AI teams. We’re encoding five millennia of organizational wisdom into protocol.


Image Credits

  • Hero image: Yinqueshan bamboo slips of Sun Zi’s Art of War, Western Han Dynasty, Shandong Museum permanent collection. China Daily.
  • Trajan’s Column relief: Scene VII, Trajan reviews his troops from a tribunal. Photo by R.B. Ulrich. trajans-column.org.