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, and 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 that share a group value run in order, and 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 and applies them to a (scope, key). It returns both the old value and the new one. That pair is handle_call/3: a state transition and a reply, written as data rather than as 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 one command is a durable, per-actor-serialized, retry-backed, idempotency-keyed message send into a persistent state machine. Still, no source file appears anywhere in it. The supervisor is a worker-compose.yaml dependency graph, monitors are trigger bindings, and restart intensity is max_retries plus a dead-letter queue.

Note the row that says free. OTP is famous for making hot code upgrade possible and notorious for making it 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 three classes: a Mailbox (strict FIFO), a GenServer (state plus a serialized loop), and a Supervisor. That supervisor carries one_for_one, rest_for_one, and a real restart-intensity window. Restart intensity is about fifteen lines, and it is the thing everyone forgets. Without that window, a crash loop looks the same as a busy system.

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. So nothing needs rebuilding.

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

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, and the cascade was correct. Still, the run produced nothing, because the restart cleared the mailbox for score. That mailbox held the message that caused the crash, so the message went with it. 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, and 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 for one more reason: pids are ephemeral and unroutable.

flowchart LR
  ram["state in volatile RAM"] --> die["process can die with state"]
  ram --> pid["pid is ephemeral"]
  die --> sup["supervision to restart it"]
  sup --> intensity["restart intensity to bound the loop"]
  die --> links["links so peers don't read stale state"]
  pid --> registry["registry for stable names"]
  durable["state in a durable store"] --> subject["nothing above has a subject"]
  class sup,intensity,links,registry pass
  class durable,subject dim

• 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 retries already handle message failure.
• Restart intensity. Three retries with exponential backoff, then dead-letter. The dead-letter queue does the same job better: it keeps the poison message and lets you inspect it. Redrive it with iii::queue::redrive once you fix the cause. OTP escalates instead and loses the message.
• 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. But no stale memory exists here to protect against. What survives is cascade for genuine data dependencies, which the compose daemon already does.

Ordering under retry. A BEAM mailbox keeps order: two messages sent from A to B arrive in send order, always. The queue worker documents its own divergence: a failed FIFO message goes back on the queue via nack. That nack keeps the poller running, so a message enqueued after the failure can arrive before the retried one.

sequenceDiagram
  participant P as producer
  participant Q as queue
  participant W as worker
  P->>Q: enqueue A
  Q->>W: deliver A
  W--xW: A fails
  W->>Q: nack, backoff 1000ms
  P->>Q: enqueue B
  Q->>W: deliver B
  Note over W: B lands first
  Q-->>Q: retry A
  Q->>W: deliver A
  Note over P,W: BEAM: A then B, always.
  Note over P,W: queue: A then B, unless A stumbles.

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

Delayed delivery. iii has no Process.send_after. The queue accepts delaySeconds and visibilityTimeout "for parity" and ignores both. But send_after does four jobs, and three of them already have cover. Call timeouts go to timeout_ms, periodic work goes to cron, and the queue handles retry backoff natively. That leaves business-time scheduling: 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. It also runs over an event log, where history is the system and replay is the debugging surface. Both answer pressures that agent systems really do have. Read them next.