Tool / Every write is a signed change in a per-object causal DAG, merged per path by last-writer-wins: writes never fail on contention, concurrent edits to different fields both survive, same-path edits lose silently, $inc and $addToSet compose, deletes win, nothing is atomic across objects; a change-history API lets you see what was overwritten. Live state comes over SSE subscriptions plus a transient event bus. The agent runs as CPython in a wasmtime cage with no sockets, filesystem or real clock and a fuel budget per cell; its one tool writes Python cells in a persistent kernel, and every side effect crosses one host boundary that checks, executes and records it, so each run replays bit-exact and can be mocked. Credentials are injected after the trace is written, so they never reach the model. Memory, triggers, config and the agent's own code are synced records: deploys are live, with no restart, and background jobs extract and decay facts so recall doesn't depend on the model choosing to look. With several devices online, an election picks the one that answers; subagents run one at a time, blocking.

any (any-sync + anyrt)

https://docs.any.org/

A local-first, end-to-end encrypted database: a local server on each device that apps reach over HTTP, syncing peer to peer and merging as CRDTs, built on any-sync (in production for years across millions of spaces, audited by Cure53). Its companion runtime anyrt runs sandboxed Python programs, scheduled jobs and a personal agent, bao, inside the same data. Developer preview, MIT.

The summary describes what the project says it does; inclusion is not an endorsement.

Take

The any README pitches exactly our problem: databases built around central transactions handle [agentic] concurrent writes badly, because "concurrent actors rewrite each other's data without history". Their answer is per-path last-writer-wins on a CRDT that has run in production for years. Writes never block and conflicts never surface. That's the catch for many agents at once: the loser of a same-path race is overwritten with no error to either side, nothing spans objects, and invariants can't be enforced. The docs tell you to design records so that concurrent writers touch different fields, and to use the history API to see what was lost. That's coordination pushed back onto the schema, which echoes AgentRoom's finding that CRDT merging alone doesn't bear the load.

What ships on top is a personal agent, not a swarm: one agent per chat, a device election that picks a single responder, and subagents that run one at a time. The submitter's "multiagent swarms" isn't in the docs or the READMEs. The parts worth borrowing for a fleet are the effect boundary (every call recorded, every run replayable, credentials kept out of the trace) and agent memory and code kept as synced, queryable data that any device can pick up. It's alpha, and the local server trusts every process on the machine, so I'd track it rather than build on it.

AI-drafted