Skip to main content
2024-06-1512 min read
System Architecture

The Actor Model and What It Can Teach Us About Human Organizational Structures

Distributed Systems Lessons for Distributed Teams

💡
TL;DR - The Actor Model Applied to Human Organizations
Message-Passing Over Meetings: Asynchronous communication beats synchronous coordination—just like the best remote teams already know
Isolated State = Clear Ownership: When one person owns a domain completely, they move faster, innovate freely, and are truly accountable
Supervision ≠ Control: Good managers handle failures and route messages—they don't micromanage execution
Let It Crash: Design for fast recovery instead of preventing all failures—embrace experimentation
Respect Human Buffers: People can only process one message at a time—unbounded queues lead to burnout
Location Transparency: Physical location doesn't matter when your org structure is based on message flow
The actor model, conceived by Carl Hewitt in 1973, is one of those computer science concepts that accidentally explains far more about human nature than it ever intended to. At its core, it's a mathematical model for concurrent computation. But look closer, and you'll find a blueprint for how successful human organizations actually function—and why so many fail.

The Beautiful Simplicity of Actors

In the actor model, everything is an actor. Each actor can:
  • Receive messages
  • Process one message at a time
  • Send messages to other actors
  • Create new actors
  • Decide how to handle the next message
That's it. No shared state. No locks. No synchronization nightmares. Just independent entities passing messages and doing their thing.

Key Principles

No Shared State

Async Messages

Serial Processing

Location Independence

Actor System

Message

Message

Message

Response

Message

Create

Actor 1
💼 State
📬 Mailbox

Actor 2
💼 State
📬 Mailbox

Actor 3
💼 State
📬 Mailbox

Actor 4
💼 State
📬 Mailbox

New Actor

Sound familiar? It should. This is how healthy organizations work when we don't screw them up with bureaucracy.
Here's what this looks like in code:
javascript
1// Simple Actor Pattern
2class Actor {
3 constructor(name) {
4 this.name = name;
5 this.state = {}; // Private state
6 this.mailbox = []; // Message queue
7 this.processing = false;
8 }
9
10 // Send message to this actor
11 receive(message) {
12 this.mailbox.push(message);
13 if (!this.processing) {
14 this.processMessages();
15 }
16 }
17
18 // Process messages one at a time
19 async processMessages() {
20 this.processing = true;
21 while (this.mailbox.length > 0) {
22 const message = this.mailbox.shift();
23 await this.handleMessage(message);
24 }
25 this.processing = false;
26 }
27
28 // Override in subclasses
29 async handleMessage(message) {
30 console.log(`${this.name} handling:`, message);
31 }
32}
33
34// Supervisor Pattern
35class Supervisor extends Actor {
36 constructor(name) {
37 super(name);
38 this.children = [];
39 }
40
41 createChild(ChildClass, name) {
42 const child = new ChildClass(name);
43 this.children.push(child);
44 return child;
45 }
46
47 async handleMessage(message) {
48 if (message.type === 'child_failed') {
49 // Supervision strategy
50 console.log(`${this.name} handling failure of ${message.child}`);
51 // Could restart, escalate, or handle locally
52 }
53 }
54}
And in a more human context:
python
1# How organizations can implement actor patterns
2class TeamMember:
3 def __init__(self, name, role):
4 self.name = name
5 self.role = role
6 self.inbox = [] # Async message queue
7 self.owned_domains = [] # Clear ownership
8
9 def send_message(self, recipient, message):
10 # Async communication
11 recipient.inbox.append({
12 'from': self.name,
13 'message': message,
14 'timestamp': datetime.now()
15 })
16 # Don't wait for response - continue working
17
18 def process_inbox(self):
19 # Handle messages at your own pace
20 while self.inbox:
21 msg = self.inbox.pop(0)
22 self.handle_message(msg)
23
24 def claim_ownership(self, domain):
25 # Clear ownership of domains
26 self.owned_domains.append(domain)
27 print(f"{self.name} now owns {domain}")

Message-Passing vs. Meetings

Traditional organizations love their meetings. Status meetings. Sync meetings. Meetings about meetings. We've created a shared-state nightmare where everyone needs to coordinate with everyone else in real-time.
The actor model suggests something radical: asynchronous message-passing is superior to synchronous coordination.
In actor systems, you send a message and move on. You don't wait for a response. You don't block. You trust that the message will be handled when the recipient is ready. This isn't just more efficient—it's more humane.
Consider how the best remote teams operate. They don't do daily standups. They write. They document. They send messages (Slack, email, pull requests) and trust their colleagues to respond when they can. They've unknowingly adopted the actor model.

Actor Model: Async Messages

Message

Continue Working

Message

Continue Working

Process When Ready

Process When Ready

Person 1
📬

Person 2
📬

Deep Work

Person 3
📬

Person 4
📬

Deep Work

Response

Response

Traditional: Synchronous Meetings

🔒 Blocked

🔒 Blocked

🔒 Blocked

🔒 Blocked

Context Switch

Context Switch

Context Switch

Context Switch

Person 1

Meeting
10am-11am

Person 2

Person 3

Person 4

Back to Work

Back to Work

Back to Work

Back to Work

The Mailbox: Your Most Underrated Organizational Tool

Every actor has a mailbox—a queue of messages waiting to be processed. The actor processes them one at a time, in order, at its own pace. It can't be interrupted mid-message. It can't be forced to multitask.
Humans need mailboxes too. Not email inboxes—those are broken. Real mailboxes with these properties:
  • Messages queue up without interrupting current work
  • Processing happens serially, not in parallel
  • The actor (person) controls the pace
This is why "focus time" and "deep work" aren't just productivity hacks—they're fundamental requirements for functioning like a healthy actor. When we force people to respond immediately to every ping, we're violating the actor model. We're creating race conditions in human form.

Isolated State: The Power of Ownership

In the actor model, each actor owns its state completely. No other actor can reach in and muck with it. Want to change something? Send a message and ask nicely.
Compare this to organizations where everyone has their fingers in everything. Shared spreadsheets that anyone can edit. Decisions by committee. Responsibilities so diffuse that no one owns anything.
The actor model teaches us that clear ownership beats shared responsibility every time. When one person (actor) owns a domain:
  • They can move fast without coordination
  • They develop deep expertise
  • They can innovate without permission
  • They're accountable for outcomes
This isn't about silos—actors still communicate constantly. It's about clarity of ownership within a communicating system.

Supervision Trees: How Real Leadership Works

In actor systems, actors can create child actors and supervise them. When a child actor fails, the supervisor decides what to do: restart it, escalate the failure, or handle it locally.
This is exactly how effective organizational hierarchies work. Good managers are supervisors in the actor model sense:
  • They spawn new actors (hire and delegate)
  • They handle failures locally when possible
  • They escalate only when necessary
  • They restart failed processes (training, reassignment)
  • They protect their actors from outside interference
The key insight: supervision isn't about control—it's about failure handling and message routing.

Supervision Tree

supervises

supervises

supervises

supervises

supervises

supervises

supervises

supervises

supervises

supervises

Failure Handling

Actor Fails

Supervisor Decides:
• Restart
• Escalate
• Handle Locally

CEO
👤 Root Supervisor

CTO
👤 Supervisor

CFO
👤 Supervisor

COO
👤 Supervisor

Backend Lead
👤 Supervisor

Frontend Lead
👤 Supervisor

Data Lead
👤 Supervisor

Backend Dev 1
⚙️ Actor

Backend Dev 2
⚙️ Actor

Frontend Dev 1
⚙️ Actor

Frontend Dev 2
⚙️ Actor

Location Transparency: The Remote Work Revelation

In the actor model, it doesn't matter where an actor is running. Same machine, different machine, different continent—as long as messages can flow, the system works.
COVID forced organizations to discover what distributed systems engineers always knew: location transparency is a feature, not a bug. When your organizational structure is based on message-passing rather than physical proximity, suddenly remote work isn't a compromise—it's just another deployment strategy.
The organizations struggling with remote work are those still clinging to shared-state models that require synchronous coordination. They're trying to recreate the office virtually instead of embracing the actor model.

Resilience Through Isolation

When an actor crashes in a well-designed system, it doesn't take down other actors. The failure is isolated. The supervisor can restart it. Messages might need to be resent, but the system continues.
Human organizations need this same resilience. When one person burns out, takes vacation, or leaves, the organization shouldn't grind to a halt. But in shared-state organizations where everyone depends on everyone else synchronously, that's exactly what happens.
The actor model solution:
  • Clear interfaces (how to send messages to a role, not a person)
  • Message persistence (documentation and handoffs)
  • Supervision strategies (succession planning)
  • Isolation boundaries (limiting blast radius of failures)

Let It Crash: The Uncomfortable Truth

The actor model embraces a philosophy that makes traditional managers squirm: "let it crash." Instead of trying to prevent all failures, you design for fast recovery.
In human terms: not every project will succeed. Not every hire will work out. Not every strategy will pan out. The goal isn't to prevent all failures—it's to fail fast, learn, and restart.
Organizations that embrace this philosophy:
  • Run more experiments
  • Learn faster
  • Waste less time on doomed efforts
  • Build more resilient cultures
"Let It Crash" vs. "Failure Is Not An Option"
Traditional management philosophy says failure is not an option. The actor model says failure is inevitable—design for it.
This isn't about being careless. It's about recognizing that in complex systems, trying to prevent all failures often creates more fragility than accepting and planning for them. When you design for fast recovery instead of perfect prevention, you get:
  • Freedom to experiment without fear
  • Faster detection of what doesn't work
  • Resources focused on recovery, not prevention
  • A culture that learns from failure instead of hiding it

The Message Buffer Problem

Here's where the actor model offers a warning: unbounded message queues lead to system collapse. If messages arrive faster than they can be processed, eventually something breaks.
Sound like your inbox? Your Slack? Your calendar?
Human actors need back-pressure mechanisms:
  • The ability to reject messages ("No")
  • Bounded buffers (limited WIP)
  • Priority queues (not everything is urgent)
  • Load shedding (letting some things drop)
Organizations that don't respect human message buffer limits create burnout. It's not a people problem—it's a systems problem.
⚠️
The Human Buffer Overflow
Just like computer systems, humans have finite processing capacity. When organizations ignore this fundamental constraint, they create:
  • Chronic stress from overflowing inboxes
  • Decision fatigue from constant interruptions
  • Reduced quality as people rush through tasks
  • Eventually, complete system failure (burnout)
The solution isn't working harder—it's implementing proper back-pressure mechanisms and respecting human limits.

Composition Over Inheritance

In the actor model, complex behaviors emerge from simple actors working together. You don't need complex actors—you need well-coordinated simple ones.
The organizational parallel: you don't need superhero employees who can do everything. You need regular people with clear roles who communicate well. The magic isn't in the individuals—it's in the interactions.

Actor Model Organization

Async Message

Async Message

Async Message

Async Message

Employee 1
📦 Own State
📬 Mailbox

Employee 2
📦 Own State
📬 Mailbox

Employee 3
📦 Own State
📬 Mailbox

Employee 4
📦 Own State
📬 Mailbox

Clean Architecture
✅ Clear Ownership
✅ No Blocking
✅ Resilient

Traditional Organization

Direct Access

Direct Access

Direct Access

Direct Access

Sync Required

Sync Required

Sync Required

Sync Required

Shared State
🔒 Spreadsheets
🔒 Databases
🔒 Resources

Employee 1

Employee 2

Employee 3

Employee 4

Coordination Chaos
❌ Race Conditions
❌ Bottlenecks
❌ Conflicts

Practical Lessons for Your Organization

  1. Embrace asynchronous communication: Default to written, persistent messages over meetings
  2. Create clear ownership: Every domain needs one owner who controls its state
  3. Design for failure: Build systems that gracefully handle people leaving or failing
  4. Respect human buffers: People can only process one thing at a time effectively
  5. Supervise, don't micromanage: Handle failures and route messages, don't control execution
  6. Location doesn't matter: Focus on message flow, not physical proximity
  7. Keep actors simple: Complex behavior should emerge from interaction, not from superhero individuals

The Future Is Distributed

The actor model isn't just a computer science curiosity—it's a proven pattern for building resilient, scalable systems. As human organizations become more distributed, more asynchronous, and more complex, the lessons from actor systems become more relevant.
The best organizations are already actor systems. They just don't know it yet. They've stumbled into these patterns through trial and error, through pain and adaptation.
But what if we were intentional about it? What if we designed our organizations like actor systems from the start? Clear interfaces. Message-passing. Isolated state. Supervision trees. Resilience through isolation.
The actor model shows us that the future of human organization isn't more meetings, more coordination, more shared state. It's the opposite: autonomous actors, communicating asynchronously, failing gracefully, and creating emergent complexity from simple rules.
The computers figured this out in 1973. Maybe it's time we caught up.