Why Your AI Agents Lose Context and Crash: How Persistent File-Based Planning Saves Production

I’m Denis Shokhirev, Enterprise AI Architect based in Erlangen, Germany. At DennisCraft AI Studio, I’ve shipped 14 production AI agents for DACH B2B clients in the last 6 months, on a stack of Claude, Supabase, n8n, Doppler, and self-hosted Postgres. The single most common cause of production incidents? Agents lose context after a restart or crash, causing broken workflows and lost business logic.

Why Do AI Agents Lose Context in Production?

Most open-source agent frameworks (LangChain, Haystack, vanilla n8n) and even many custom stacks store agent state in RAM or ephemeral DB tables. When the process restarts—container kill, orchestrator update, or infra crash—any ongoing workflow loses its intermediate context. This isn’t theoretical: I’ve seen agents for logistics and compliance simply “forget” their last step after a Kubernetes node reboot. In regulated markets (fintech, industrial), these breakdowns are not tolerated by customers or auditors.

The Persistent File-Based Planning Pattern

This approach means every agent step—intermediate result, plan, prompt, artifact—is stored as a discrete file (JSON, YAML, PDF, image) or versioned object in S3-compatible storage. It’s not just logging; it’s atomic checkpointing between steps. I use Supabase Storage or local MinIO for files, and Postgres for step metadata.

Why Does This Actually Matter?

• Reproducibility: You can resume any workflow from any completed step.
• Diagnostics: Full traceability of agent decision logic.
• Auditability: In regulated sectors, you need evidence of all intermediate states, not just final outputs.

Example: Saving State to Supabase Storage

import os
from supabase_py import create_client

client = create_client(os.environ["SUPABASE_URL"], os.environ["SUPABASE_KEY"])

def save_agent_step(agent_id, step_num, data):
    filename = f"agent-{agent_id}/step-{step_num}.json"
    client.storage().from_("agent-steps").upload(filename, data)
    # Store metadata in Postgres
    client.table("agent_steps_metadata").insert({
        "agent_id": agent_id,
        "step_num": step_num,
        "filename": filename
    }).execute()

Comparing State Persistence Approaches

Production Pattern: File-Based Planning with Claude Code and n8n

My Claude Code + n8n stack uses a persistent file-based approach: each workflow step (e.g., spec generation, validation, deployment) writes a JSON artifact and any files to Supabase Storage. n8n orchestrates the workflow; each step has a custom action node that stores output and metadata in Postgres.

Example n8n Custom Node Fragment

// n8n custom node
import { IExecuteFunctions } from 'n8n-core';

export async function execute(this: IExecuteFunctions) {
  const stepData = this.getInputData();
  // ... agent step logic ...
  await supabase.storage.from('agent-steps').upload(`agent-${agentId}/step-${stepNum}.json`, JSON.stringify(stepData));
  await supabase.from('agent_steps_metadata').insert({ agent_id: agentId, step_num: stepNum, filename: `agent-${agentId}/step-${stepNum}.json` });
  return this.helpers.returnJsonArray([{ status: "ok" }]);
}

Compliance and Audit: Why File-Based Planning is Required

In regulated industries, audit does not stop at final outputs: you must evidence every decision point and intermediate artifact. Persistent file-based planning delivers a full audit trail (including all prompt versions and agent artifacts), which is essential for passing ISO 27001 and local financial audits. In my recent deployments, this pattern was the tipping point for DACH clients’ due diligence approval.

FAQ

Why not just store everything in the database?

Postgres is ideal for metadata but not for large binary or deeply nested objects (multi-page PDFs, images, notebooks). File stores scale better for these use cases.

How do you handle race conditions between agent steps?

I rely on optimistic locking in Postgres metadata and use unique filenames (SHA256 hash or UUID) to avoid file collisions.

How do you clean up old files?

Production systems use retention policies at the storage layer (Supabase Storage, MinIO) to purge by age or size thresholds.

Doesn’t this slow things down?

For most B2B use cases, 100–200ms write latency is acceptable. If you need real-time, write to memory and batch-sync to storage asynchronously.

How do you ensure consistency between storage and the database?

Each step writes to storage first, then atomically updates Postgres. If any operation fails, the step is rolled back and retried.

Which stage in your agent workflows causes the most production incidents: container restarts, race conditions, or loss of intermediate files? Genuinely curious. I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.