• Created Wednesday 07 January 2026

The actor model gives me a clean way to think about agentic systems. I keep the definition small; Carl Hewitt’s original sketch is enough.

Primitives:

• receive a message
• send a message
• create an actor
• change how to respond next

How work enters:

• one message arrives with a command
• a bundle of capabilities: run a shell command, read or write a file, call an API, spend money
• hard limits: max runtime, max spend, max actors, max delegation depth

Limits live outside behavior. When a limit is hit, calls fail or actor creation is denied.

Delegation is just sending another message plus the capabilities you are willing to pass. You can shrink authority—read-only instead of read/write, one API instead of many, a small budget instead of a large one—but you cannot mint new power. Passing work is also risk reduction.

Some capabilities are social or contextual:

• push back on a request that looks wasteful based on what the actor already knows
• adjust behavior based on current surroundings without waiting for another message
• read and contribute to institutional memory, when granted, so successes and failures accumulate into lore, not just logs

The same rules apply: you can pass or withhold these knobs, even with respect to the human operator, but you cannot conjure new authority beyond what you received.

Flow:

• small task: keep it local
• vague task: spawn a helper to interpret
• broad task: spin up specialists and hand each a narrow bundle
• unsafe task: stop

No planner or supervisor is baked in; those roles appear only when the task demands them.

This contrasts with the typical long-lived prompt loop I see in many AI coding agents: one process with a growing scratchpad and broad OS access, pretending at delegation inside text. Boundaries blur, and safety depends on restraint. It also differs from persona systems like Gastown, where “Mayor” and “Councillor” characters are predefined and coordination is scripted. Here, boundaries are structural because capability handles and limits are explicit. Planners or supervisors appear when needed, not because the architecture assumes them. That aligns with how I want to use an AI coding agent as a teammate, not as a single omniscient loop.

The pattern mirrors how high-skill, low-ego, cross-functional teams self-organize: people negotiate capabilities, push back on bad asks, and adapt locally. In a command hierarchy, incentives are lopsided: doing a good job yields subtle, delayed rewards, while a bad job triggers immediate pain, so ducking responsibility becomes rational. Keeping authority explicit and bounded keeps accountability local instead of avoided.

This matters even for AI personas. They inherit human flavor—assertive, cautious, deferential—while also wielding superhuman reach and speed. Explicit capabilities force those traits to operate inside hard walls, so a confident persona cannot overrun its remit just because it “feels” empowered.

To try it: start with the smallest useful capability bundle, add helpers only when the work forces you to, and narrow permissions as tasks specialize. Let failure stay local. The goal is not a grand controller, but small behaviors with crisp authority that assemble only when the problem demands it.

Notes and related work:

• Lisp-Actors grand recap collects field notes on real actor-model practice.
• Actor interaction patterns surveys message topologies beyond request/response.
• Chasma is a Clojure take on Hewitt’s transactional actors, kept as pure to the original model as I can make it.