Pizza Bot vs Kiro Crew: Agent Persistence Stacks, Tested

Two open-source agent harnesses shipped into the same week and both made the Hacker News front page: Pizza Bot, an inbox for long-running agents developed at Amazon, and Kiro Crew, a persistent self-improving workspace from Kiro. Both are selling the same thing — agents that survive disconnects, resumes, and reboots — but they solved persistence in completely different ways. I cloned both, ran the test suites, benchmarked the storage layer, and booted the API server. Here's what's actually under the hood.

Two Persistence Architectures, Diverged

Both stacks picked SQLite as the substrate. The divergence is in what they persist:

graph TD
  A[Agent run state] --> B[Pizza Bot]
  A --> C[Kiro Crew]
  B --> B1[LangGraph SqliteSaver
checkpoints]
  B --> B2[SqliteStore: ns/key/value
cross-thread store]
  C --> C1[memory.db: semantic KV +
episodic FAISS/FTS5]
  C --> C2[ONLINE BACKUP API
rotating hot backups]

Pizza Bot wraps the LangGraph checkpoint contract: packages/storage/src/persistence.ts wires a SqliteSaver (thread checkpoints) and a hand-rolled SqliteStore (namespaced cross-thread key/value), both with a journal_mode = WAL pragma. Kiro Crew went vertical: vector_memory.py (6,636 lines) is a semantic memory engine with allow-listed keys, confidence gating, conflict resolution, injection detection, and episodic retrieval via FAISS that falls back to FTS5 when embeddings aren't available. Pizza Bot persists runs. Kiro Crew persists knowledge.

Pizza Bot: 147 Test Files, All Green

Install and test run, straight from source on Node 26.5.1:

npm install --no-audit --no-fund   # 956 packages in 30s
npx turbo run test --concurrency=2

Result: 21 packages, 21 successful, zero failures, 2m34s total. The repo carries 147 *.test.ts files, and the tests check things that matter — secret-store.test.ts verifies an undecryptable row is skipped rather than crashing the boot. I then booted the API server from source (npx tsx apps/api-server/src/index.ts, port 8080): /ping returned {"status":"Healthy"} and /memories returned an empty memory store on first run. One rough edge: the bundled Playwright MCP server fails twice at boot with browser_not_found in a headless container before degrading gracefully — it wants npm run browser:install or PIZZA_PLAYWRIGHT_BROWSER_PATH.

The 0.144ms Store

I benchmarked Pizza Bot's SqliteStore directly — 10,000 sequential operations against a fresh database:

{"N":10000,
 "put_ms_per_op":0.144,
 "get_ms_per_op":0.089,
 "search_ms_for_all":46.8,
 "search_hits":10000}

0.144 ms per put, 0.089 ms per get, and a full-namespace scan of all 10k rows in 46.8 ms. For an agent writing state on every step, that's effectively free. The search path is the weak spot: it's a prefix match over a primary-key (ns, key), not an index-tuned query — fine at 10k rows, worth watching when a long-lived agent accumulates years of state. Notably, Kiro Crew solved the same problem with FTS5 and a FAISS fallback — vector search where it counts, full-text where it doesn't.

Kiro Crew: The Backup Story Is the Real News

The sharpest thing in Kiro Crew's tree is a docstring in memory_backup.py. The authors recount a real incident: "a 36 MB store became 29 bytes with nothing to restore from." Their fix is textbook: use SQLite's Connection.backup (ONLINE BACKUP API), not a file copy, because a gateway holding the store open under WAL means shutil.copy of memory.db alone produces "a file whose committed tail lives in a -wal sibling it did not take." Backups rotate daily and finish in milliseconds. That's the kind of durability thinking you don't see in most agent frameworks — most don't back up memory at all.

The scale is real, too: sandbox.py is 11,282 lines, agent.py 7,106. This is not a weekend repo; it's a product codebase with an evals directory, a semgrep config, and AppArmor sandboxing for Ubuntu 23.10+.

Bottom Line

If your agent does multi-day unattended work, pick by failure mode. Pizza Bot gives you durable runs — checkpointed LangGraph state that survives disconnects — and its inbox model (completed work in Unread, decisions in Action) is the right UX for human-in-the-loop agents. Kiro Crew gives you durable knowledge — semantic memory with an audit trail and automated hot backups. Both prove the same point: agent persistence is a database problem, and both teams chose boring, correct infrastructure (SQLite under WAL) instead of a vector-cloud dependency. That's the right call, and both test suites passing clean from source is a level of engineering discipline worth copying.