Your Personal and Edge AI Needs a Consistency Model

Tuesday, 9:02 AM — Phone: “I don't take red-eye flights anymore.”

Nothing crashed. No API timed out. Both agents executed correctly against the state they had. They just operated on different versions of you.

This is familiar territory in distributed systems: a write commits, but a replica hasn't caught up. Reading the primary is one solution. The better architecture is to declare the consistency guarantee each operation requires. Agents make the dependency harder to see — a stale preference becomes a summary, then a plan, then a purchase.

Part 1 mapped inference to the database execution engine and asked where its optimizer was. Part 2 brought transactions, recovery and concurrency control to agent runtimes. Part 3 moves to replication: which version of state can an agent trust before it acts?

Each consequential action needs an explicit contract: which state it requires, what authority permits it, and what happens when either is unavailable.

1From replicas to agents, translated for a database engineer

What personal and edge AI has already rebuilt

Some of this exists: Meta's Muse gives each user a dedicated VM as the system of record, with state in Postgres — the primary half of the pattern, a cloud authority store. The building blocks exist. What's still missing is a common agent-runtime contract tying state dependencies, consistency guarantees and authority to each consequential action.

Personal and edge: same replication problem, different authority

A personal AI agent spans a person's or household's phone, laptop, wearable and cloud. An edge AI agent runs closer to the work itself — a vehicle, a factory floor, a clinic — and often answers to several independent authorities, one per site or system. The underlying replication mechanisms are familiar. What differs is who owns the state, who can update it, and which actions require fresh authority — and in both settings, it's an agent that acts on the stale copy, not just a screen that displays it.

None of these need a crash or a hallucinated answer. Ordinary replication lag, two independent writers and an authority handoff are enough — the agent just has to act before it catches up.

A cloud commit gate can serialize purchases while you're connected. It cannot serve offline checkout, millisecond control loops or data under another institution's own access controls. In the factory, fencing has to be enforced at the actuator or a trusted local gateway, with physical safety limits sitting below the agent entirely. Authority has to live where the state and the action require it.

The question is not cloud versus edge. It is which state each replica can trust, and what it is allowed to do when it cannot reach the authority for the rest.

2Replicate the meaning; treat context as a cache

A database replica does not copy the primary's buffer pool. It replays the replication log and builds its own cache: the log travels, the working set stays local. Agents need the same split. The context window and its KV cache are the buffer pool from Part 1, assembled for a particular model and execution context. KV cache can be transferred between compatible inference workers to avoid recomputation, but that is an execution optimization, not state replication. The durable source of truth is the accepted agent state, not its execution artifacts:

Each runtime builds its own context from replicated state, under its own model, privacy boundary and budget. That is Part 1's context pushdown, applied across devices.

The phone records “aisle seats”; the laptop records “window seats on flights over five hours.” Log replay preserves both; last-writer-wins may discard one. Neither resolves the intended default and exception. A model can propose the conditional rule, but the user or authorized policy accepts it as a versioned state change that replicas share.

Each action tracks a state graph: the accepted rules it read, their versions, derived summaries and the grant authorizing the action. The consistency model validates those dependencies.

3Where is the consistency model for agents?

Distributed databases make consistency explicit: isolation levels in SQL, configurable consistency in Cassandra — ONE, QUORUM, ALL — and replica-visibility guarantees in MySQL and PostgreSQL.

What guarantee did the red-eye booking require? The laptop simply acted on v41. The consistency model was not weak. It was absent.

An offline laptop can still read local state, but an action needing authoritative validation must wait — the guarantee depends on its risk and reversibility. For this agent, I would declare:

Escrow — reserving a bounded allowance locally so each device can spend without coordinating every transaction — comes from O'Neil's escrow transactions (1986), applied to exactly this kind of distributed invariant.

Written as a declaration the runtime can enforce, the booking row might look like this:

action: book_flight
state:
  preferences: validated_at_authority
  minimum_version: session_version
  dependencies: revalidate
authority:
  grant: book_flights
  max_spend_usd: 700
  expires_at: "10:00"
on_stale: replan
on_unavailable: wait
on_uncertain_outcome: reconcile

Before an irreversible action, the runtime enforces the contract: proceed, wait, replan or reconcile.

The $700 grant would have allowed the $640 red-eye. Authorization wasn't the failure. The agent acted on stale state.

The mechanisms are familiar. A session token carries the minimum version the next read must meet. The commit gate applies optimistic concurrency control: validate the action's state graph, then atomically record intent before dispatch. A lease bounds what a disconnected participant may do, and for how long.

Recording intent doesn't make the booking API part of the transaction. If dispatch fails or its outcome is uncertain, the runtime reconciles; it never blindly retries a side effect. That's Part 2's job.

One case no mechanism fixes: if v42 existed only on a disconnected phone, no runtime could know about it. The laptop could research, but not purchase.

4Beyond replica consistency: state, dependencies and authority

The commit gate checks more than replica versions. A summary or vector index may still reflect an older preference even after source state has synchronized. Unlike a deterministic database view, a summary regenerated by a different model may produce a different result. Its source dependencies must be tracked so stale summaries, indexes and plans can be invalidated or rebuilt. Dynamo exposed a related resurrection problem with deleted shopping-cart items; Cassandra has similar tombstone risks when replicas remain stale too long. Agents add derived memory, caches and checkpoints that must also be invalidated or reconciled.

And current state is not the same as permission to act. A replica may know the itinerary without holding a valid grant to book it. Leases bound delegated authority; fencing tokens let an enforcement point reject stale holders.

The runtime must validate three things before acting: state freshness, derived dependencies and authority.

EXPLAIN, distributed: which version did the agent act on?

EXPLAIN should show more than what an agent did. It should show which state it trusted, which dependencies it validated, and what authorized the action. Here's how the red-eye booking would execute with those guarantees enforced:

EXPLAIN AGENT TASK  trip-8821

Goal           Book tomorrow's trip
Session        task created after v42 commit; requires prefs ≥ v42
Requires       booking: validated at authority on commit
Read           laptop replica prefs v41   (behind session; fetch requested)
Decision       research: PROCEED on v41, provisional
               purchase: VALIDATE at authority first
Validation     authority prefs v42; plan built on v41: REJECTED
Invalidated    trip summary derived from v41
Replan         daytime flight, built on v42
Grant          issued by authority, approved on phone —
               flights only, ≤ $700, expires 10:00
Authorize      intent recorded against prefs v42
Dispatch       booking.create → CONFIRMED, outcome recorded

That is the answer a customer needs when they ask why the agent booked that flight: the version it read, the guarantee the action required and the authority that allowed it.

The Distributed Agent Runtime: A Reference Architecture

The architecture brings inference execution, transactional recovery and distributed consistency into one runtime. The planner decides what can run and where; the state layer tracks what each action depends on; the commit gate validates consequential actions before dispatch. EXPLAIN makes the decisions observable.

Authority is scoped by state domain and operation, not by tier — device, edge and cloud may each own different state.

The bottom line

Once agent state is distributed, consistency becomes an execution contract. The runtime must know when to read locally, wait for a version, reconcile state, validate authority, ask you — or refuse to act.

Key takeaways

Architects: Every consequential action should answer: "Which version did I read, and who allowed me to act?" If your runtime can't answer that, you're exposing the system to failures with real-world consequences. Declare consistency per action and enforce it at the commit gate.

Builders and investors: Distributed systems spent decades solving replication, consistency, concurrency and recovery. Agent runtimes now face the same challenges, with semantic state and autonomous actions adding new complexity. Models will commoditize. The infrastructure that makes agent actions trustworthy won't be so easily replaced.