Trust-Aware Recovery in Agent Fleets: Why Restarting Everything Is the Wrong Default

Ruslan Vrublevskyi — Sat, 15 Aug 2026 05:44:26 +0000

I created this article for the purposes of entering the Google All Things Agentic Hackathon 2026.Autonomous agent systems fail differently from ordinary services.

A single stale evidence record, malformed worker output, poisoned tool result, or policy change can contaminate downstream state even when most of the fleet's earlier work is still valid.

EvidenceBound Recovery Mesh treats that as a trust-graph problem rather than a process-restart problem.

EvidenceBound Recovery Mesh architecture. Solid paths are implemented and verified in the live deployment; Firestore and BigQuery are explicitly shown as enterprise extension targets, not active integrations.

Each material step becomes a checkpoint with explicit dependencies, output digests, evidence/tool digests, policy version, provenance, integrity metadata, and a deterministic verification state.

When a trust break is detected, the runtime freezes unsafe downstream action, traverses the dependency graph, computes the exact blast radius, preserves checkpoints that remain verifiable, and reruns only the affected branch.

The key design choice is that the language model is not the source of truth for trust.

Gemini agents can analyze evidence and return bounded structured output, but deterministic code decides whether a checkpoint is VERIFIED, INVALIDATED, RECOMPUTE, or BLOCKED. The model cannot override policy, provenance, integrity, or side-effect gates.

In the production acceptance run on Google Cloud, four Google ADK agents used Gemini 3.5 Flash through Vertex AI.

A controlled stale-evidence fault invalidated the history snapshot and blocked publish_action.

Scout remained reusable while Statistician, Skeptic, and Orchestrator were selectively recomputed. The final action resumed only after deterministic re-verification.

Measured on that controlled production run:

Full restart: 4 model calls / 1781 input tokens
Selective recovery: 3 model calls / 1358 input tokens
Saved: 1 model call / 423 input tokens, about 24% of input tokens for that run

This is not a general savings claim. It is a measured receipt from one bounded production scenario.

Why the live demo intentionally uses an in-memory hot store

Once the production judge path passed live acceptance on Google Cloud, I deliberately froze the backend rather than adding a new database dependency immediately before judging.

The live hackathon deployment therefore uses a bounded process-local in-memory hot store for run state.

For an enterprise deployment, the architecture separates persistence behind an extension boundary: the same Flight Recorder checkpoint/event schema can be persisted to Firestore for multi-week operational state and to BigQuery for long-term audit analytics.

Those are enterprise architecture extension targets, not active services in the live submission.

This separation is important: persistence availability must never become trust authority. Verification, invalidation, blast-radius calculation, reuse decisions and fail-closed action gating remain deterministic regardless of the storage provider.

The broader lesson is simple:

Persisted state should not be treated as trusted state merely because it exists.

For autonomous fleets, recovery should preserve only work whose evidence, provenance, dependencies, integrity and policy context are still verifiable.

Project: EvidenceBound Recovery Mesh
Hackathon: Google All Things Agentic Hackathon 2026
Category: Fortified Enterprise Fleet

DEV Community: Ruslan Vrublevskyi

Trust-Aware Recovery in Agent Fleets: Why Restarting Everything Is the Wrong Default

Why the live demo intentionally uses an in-memory hot store