meerkat-mob.
Core Model
MobActor serializes mob commands, persists mob state, and projects public
status from MobMachine authority. Member sessions are still ordinary Meerkat
sessions, so they inherit provider, tool, auth, memory, and live-channel
behavior from the session runtime.
Identity
Mob member identity has two layers:
Use
AgentIdentity for facts that survive respawn. Use AgentRuntimeId only
for per-binding runtime facts.
Runtime Bindings
Members can run as local session-backed agents or as external peers.
External members require an explicit runtime binding. A bare
External backend
tag is not enough because the runtime needs a concrete process identity before
it can route work or trust peer messages. For a remote rkat member, generate
the current binding with rkat run --comms-listen-tcp ... --comms-binding-out <path>.
Public Surfaces
Flows
Flows are declarative work graphs. They support one-to-one, fan-out, fan-in, branching, and frame/loop nodes. Flow status is persisted, so a host can check live state first and fall back to the terminal snapshot.WorkGraph Bridge
WorkGraph commitments and Flow runs remain separate authorities. A durableWorkExecutionBinding records the exact effective Flow run configuration and
deterministic run identity before execution. The generated execution lifecycle requests the
launch, observes Mob-owned terminal state, requests evidence projection, and
feeds the WorkGraph closure result back into the binding lifecycle.
The external-delivery ledger is not a second run machine. Its realizing
phase is a custody fence, crossed by the Mob actor only after the deterministic
pending MobRun is durable. Mob remains the sole owner of run lifecycle. The
ledger prevents blind target reinvocation across an unobserved reply boundary.
Flow success is evidence, not completion authority. WorkGraph’s completion
policy remains the only path that can terminalize the commitment. Failed and
canceled runs remain terminal execution attempts and may be superseded by a
new binding while the WorkGraph item stays open.
For multi-host mobs, the binding and WorkGraph store remain on the controlling
host. Remotely placed members execute Flow steps through normal Mob routing;
they do not independently claim or mutate the controlling WorkGraph. Terminal
run observation and evidence projection return to the controlling host, so
distributed execution does not create replicated WorkGraph authority.
Persistence
Persistent mob state is SQLite/WAL-backed throughSqliteMobStores.
In-memory storage is used for tests and WASM. The previous exclusive-handle mob
store is gone.
Mobpacks are portable mob artifacts. They package definitions and trust policy
material for deployment through:
mob web build copies the required prebuilt wasm-pack output into the browser
bundle; it does not compile wasm32.
Live Channels
Live channels are per session. For a mob member, openlive/open against that
member’s session using a realtime-capable model such as gpt-realtime-2.
The old realtime attachment/status plane has been removed. Live channel
lifecycle is caller-initiated through the live/* method family.