A research agent submits an analysis job, then its host fails before it records the result. Restoring the input files does not tell the agent whether the job completed. Useful recovery needs a saved checkpoint, a record of unfinished operations, and a way to check what happened outside the failed runtime.
Define what the backup protects
This article describes recovery design requirements for Agent Backup System. Reference implementation work exists, but the managed service remains pre-operational. B12Y can scope backup integration and recovery testing; a generally available managed service and unattended public restoration are not currently offered.
The first design decision is the state needed to continue a particular task. A research workflow might need the documents already reviewed, intermediate findings, pending analysis jobs, and references to datasets. Another agent may need a different protection boundary.
| State | What to record | What restoration must check |
|---|---|---|
| Working context | Supported conversation, explicit plan, and intermediate results | Whether the runtime can reconstruct usable context |
| Durable memory | Memory records or consistent references to them | Availability and consistency with the checkpoint |
| Task progress | Completed and pending steps, journal position, and open request identifiers | Which operations completed after the checkpoint |
| Environment | Runtime version, configuration, artefact digests, and resource references | Compatibility, accessible dependencies, and fresh permissions |
Private model reasoning is not a required component. Credentials should be resolved through the target environment rather than deliberately embedded in portable state. Captured transcripts and tool results also need screening because they may already contain sensitive values. References alone do not establish that a snapshot is free of secrets.
Capture a consistent checkpoint
A snapshot should represent a point the runtime can explain. In the research example, a checkpoint before job submission records the intended request and its stable identifier. A later checkpoint records the provider's response.
The runtime needs a way to stop dispatching new actions while it records progress, flushes the journal, and captures the agreed state. Operations that cannot pause must be listed with their known status and reconciliation method.
A backup request can use an authenticated API or an MCP tool. MCP defines tool invocation; the backup implementation must define the snapshot contract, access controls, and storage behaviour separately.
The request needs a stable identity so retries can find the original result. Retain the local journal until the remote receipt has been checked. If capture or upload fails, an explicit workload policy determines whether work continues or pauses.
Specify protection and verification
Agree encryption mode, key custody, retention, hosting location, access policy, and metadata exposure for the actual deployment. These are implementation and operating requirements, not guarantees established by this reference design.
A manifest can identify the components and their digests. Signature and digest verification can detect unauthorised changes within the scheme's assumptions, but cannot establish that omitted state was unnecessary or that captured data was correct.
Recovery also depends on retained keys, available artefacts, and compatible software. Include those dependencies in the recovery test. If incremental snapshots are used, test restoration of the complete required chain and the effect of retention on its parents.
Reconstruct state before allowing actions
Restore first into a clean, compatible environment with external writes disabled. Verify the snapshot, apply only tested migrations, and reconstruct the supported context and task progress.
The recovery controller or a separately authorised read-only process should check the open analysis job. If it completed, record the result. If it never started, a retry may be appropriate. If its state cannot be established, hold the operation for investigation. A timeout alone is insufficient reason to submit it again.
Check for stale assumptions too. The source dataset, project instructions, or permissions may have changed since capture. Record unresolved differences before choosing a resume point.
A host becoming unreachable does not prove it has stopped. Before activating a replacement, establish how the original loses write authority. Generation-based fencing works only where the relevant write paths enforce it. Integrations without that support need another tested isolation or reconciliation procedure.
Make the recovery drill the acceptance test
Run a drill on a clean target and record what state returns, which dependencies resolve, what remains missing, and which actions stay blocked. Exercise interrupted uploads, damaged snapshots, unavailable keys, incompatible versions, ambiguous external jobs, and an original runtime that is still alive.
Measure achieved data loss and recovery time from the drill. Checkpoint frequency alone does not establish either result: failed uploads, provisioning, verification, and reconciliation all affect recovery.
The acceptance record should identify the supported runtime, captured state, known gaps, reconciliation results, and authority required for activation. A verified snapshot receipt is useful evidence of capture. A completed drill provides the evidence needed to assess recovery.