Half of OTP does not port. It dissolves.

The actor model puts state inside a process. The process is the unit of identity, the unit of concurrency, and the unit of failure, all at once. That bundling is what makes OTP elegant: because the three coincide, one mechanism — supervision — handles all three.

A durable-queue system unbundles them. Identity is a key. Concurrency is a queue lane. Failure is a message delivery. Because they no longer coincide, no single mechanism covers all three — but each one gets a mechanism better suited to it than a supervision tree was.

Start with the mailbox. A named FIFO queue whose message_group_field is the actor id: messages sharing a group value run in order, different groups run concurrently. That one field is the difference between a mailbox and a work pool.

iii trigger queue::define queue=otp-genserver config='{
  "type": "fifo",
  "message_group_field": "actor_id",
  "concurrency": 10,
  "max_retries": 3,
  "backoff_ms": 1000
}'

{ "changed": true, "queue": "otp-genserver" }

Now the callback. state::update takes an ordered list of atomic operations, applies them to a (scope, key), and returns both the old and new value. That is handle_call/3: a state transition and a reply, expressed as data rather than a function body.

iii trigger engine::queue::enqueue \
  queue=otp-genserver function_id=state::update \
  messageReceiptId=msg-001 \
  data='{ "actor_id": "c1",
          "scope": "otp:counter", "key": "c1",
          "ops": [{"type":"increment","path":"n","by":100}] }'

$ iii trigger state::get scope=otp:counter key=c1
{ "n": 106 }

That is a durable, per-actor-serialized, retry-backed, idempotency-keyed message send into a persistent state machine, and there is no source file anywhere in it. The supervisor is a worker-compose.yaml dependency graph. Monitors are trigger bindings. Restart intensity is max_retries and a dead-letter queue.

Note the row that says free. Hot code upgrade is the thing OTP is famous for making possible and notorious for making painful — code_change/3, appups, relups. Here the callback is a list of operations in a config entry, and config hot-reloads. You get the capability by accident, because you gave up expressing the callback as code.

The from-scratch half is a Mailbox (strict FIFO), a GenServer (state plus a serialized loop), and a Supervisor with one_for_one / rest_for_one and a real restart-intensity window. Restart intensity — the thing everyone forgets, and without which a crash loop is indistinguishable from a busy system — is about fifteen lines.

def restart(self) -> None:
    self.state = self._init()   # state is gone; this is the cost
    self.mailbox = Mailbox()    # so is anything still queued
    self.starts += 1

Once you have written that line, the mapping table stops being a claim and starts being obvious. On iii there is no such line to write, because the state was never in the process. There is nothing to rebuild.

The demo runs the shared workflow with one injected provider failure. The supervisor does its job flawlessly:

supervisor log:
  score crashed: provider error
  score restarted (start #2)
  accept restarted (start #2)          ← rest_for_one cascade

final state per child:
  extract   starts=1  {"claims": [...]}
  propose   starts=1  {"hypothesis": "..."}
  score     starts=2  {}
  accept    starts=2  {"accepted": null}          ← the work never completed

Every process is healthy. The cascade was correct. And the run produced nothing, because the restart cleared score's mailbox and the message that caused the crash is gone. Supervision restores the process, never the message.

The fact is this: state lives in volatile memory inside something that can die. Supervision exists to restart that thing. Restart intensity exists to stop supervision from looping forever. Links exist to stop collaborators from acting on state that died with its owner. The registry exists because pids are ephemeral and unroutable.

state in volatile RAM
  └─► process can die with state
        └─► supervision to restart it
              └─► restart intensity to bound the loop
        └─► links so peers don't read stale state
  └─► pid is ephemeral
        └─► registry for stable names

state in a durable store
  └─► nothing above has a subject

• Restart. No process owns the state, so there is nothing to restart — the state is already there. The unit of failure moved to the message, and message failure is already handled by retries.
• Restart intensity. Three retries with exponential backoff, then dead-letter. Same job done better: the poison message is preserved, inspectable, and replayable with iii::queue::redrive once you fix the cause. OTP escalates and the message is gone.
• Registry. A registry maps a stable name onto an unstable pid. Here the address is the name. (scope, key) never goes stale.
• Links and EXIT. Links protect collaborators from acting on state that died. There is no stale memory to protect against. What survives is cascade for genuine data dependencies, which the compose daemon already does.

Ordering under retry. A BEAM mailbox is a mailbox precisely because it is ordered: two messages sent from A to B arrive in send order, always. The queue worker documents its own divergence — a failed FIFO message is re-queued via nack rather than blocking the poller, so a message enqueued after the failure can be delivered before the retried one catches up.

enqueue A ──► deliver A ──► A fails ──► nack, backoff 1000ms
enqueue B ─────────────────► deliver B  ◄── B lands first
                             retry A ──► deliver A

BEAM: A then B, always.
queue: A then B, unless A stumbles.

No configuration closes this. Handlers have to be order-independent, or carry sequence numbers and park what arrives early. If your domain has genuine causal chains, this is the constraint that shapes your design, and it is the strongest argument for staying on BEAM.

Delayed delivery. There is no Process.send_after. The queue accepts delaySeconds and visibilityTimeout "for parity" and ignores both. But look at what send_after is actually used for: call timeouts (timeout_ms covers it), periodic work (cron), retry backoff (the queue does it natively), and business-time scheduling. Only the fourth is uncovered — a scheduling feature, not a hole in the actor model.

That last point is why this is a series rather than an essay. The same incident-analysis workflow runs over a blackboard, where control is opportunistic and partial results are a legitimate outcome, and over an event log, where history is the system and replay is the debugging surface. Both answer pressures that agent systems actually have. Read them next.