Architecture: How should checkpoint recovery work for crashed agent tasks ...

Documentation for Sessions

🏗️ Architecture: How should checkpoint recovery work for crashed agent tasks ...

Date: 2026-03-20
Time: 17:40:40 UTC
Session: gspace1-240.6
Agent: backend
Confidence: 94%
Status: ✅ Documented

📋 Decision Context

Question:

How should checkpoint recovery work for crashed agent tasks — full event sourcing vs genome-based?

Task: S240: Task checkpoint and recovery system

🎯 Decision Made

Chosen:

Genome-based lightweight checkpoints. After each tool execution, persist ConversationGenome (~500 tokens) + last 3 tool results + optional VM snapshot ID. On recovery, inject genome + context as resume message. TTL 24h auto-cleanup.

Options Considered:

Full event sourcing (replay every tool call)
Raw message history checkpoints (50K+ tokens per checkpoint)
Genome-based checkpoints with VM snapshots (chosen — ~500 tokens)

💭 Reasoning

Full event sourcing is overkill — we don't need to replay every event, just resume from last known good state. Raw message replay is expensive (50K+ tokens) and produces incoherent LLM state. S239's ConversationGenome provides the perfect middle ground: compact structured representation (~500 tokens) that preserves topics, decisions, and artifacts. LLM gets a coherent picture on resume rather than a raw dump. Combined with VM snapshot (already available via SelfHostedProvider), we can restore both the conversation context AND the execution environment. TTL prevents checkpoint accumulation.

📁 Files Involved

APIs/backend-vitto-api/src/app/engine/task-recovery.service.ts
APIs/backend-vitto-api/src/app/engine/schemas/task-checkpoint.schema.ts

🔗 Related

Decision ID: dev_1774028440770_3xo53t5
Session: 240
Workspace: gspace1

Auto-generated by MCP Smart Consolidation