The second region has to hold the state of every in-flight run before the first region fails. Requests then have to move to the healthy region without a person editing configuration during the incident. The writes both regions accepted while they could not reach each other need a defined outcome.
Akka replicates agent state active-active across regions. Recovery takes under a minute and no committed write is lost.
A standby region that receives state on a schedule holds whatever arrived before the failure. Every write made after the last replication cycle is gone. Runs part way through those writes resume at the point the standby knew about, minutes of work behind where they were.
Promotion adds time of its own. A person has to decide the failure is real before a standby is made primary and connections are re-pointed to it. Every one of those steps is exercised during an incident and rehearsed at no other time.
Active-active replication removes the promotion step, because both regions were already serving traffic. Agent state replicates as it changes, so the surviving region holds the runs the failed region was executing and continues them.
Akka runs active-active HA and DR across regions or across clouds, with conflict resolution that applies when regions split. Availability on the agentic workload is 99.9999%. Recovery time is under a minute and the committed state lost is zero bytes. Akka backs the availability, recovery and data-loss figures with indemnities.
The runtime supplies clustering, failover, scaling, and traffic steering, so adding a region is a change to the deployment topology. Akka deployments span 20 or more regions on that model, and the same system runs on Akka's cloud, inside a hyperscaler VPC, or on a customer's own Kubernetes infrastructure.
A database replica carries the rows an agent wrote. The runtime that executes the agent holds the position of the run and the approval it is waiting on. A replica of the database alone leaves the surviving region holding data with no run attached to it.
The surviving region already holds that run and reschedules it onto a healthy node. Execution continues from the last completed step, and side effects recorded as done are not repeated.
A network partition lets both regions keep serving, and each records what it accepted. The runtime reconciles the two histories when the regions reconnect, so the split resolves without an operator replaying writes by hand.
Agents, memory, orchestration, endpoints, guardrails, and evaluations draw on the same shared compute in each region, so a region carries one bill for all of them.
