Agents that forget everything are just expensive cron jobs

Run a workflow agent today. Run it again tomorrow. Without persistent memory, it starts from zero both times. It re-discovers the same context, re-makes the same decisions, and potentially makes the same mistakes.

For one-off tasks, that's fine. For agents doing ongoing work, it's a design flaw that compounds over time.

Why agent frameworks default to stateless

Statelessness is the safe choice. It's easy to reason about, easy to test, and easy to scale horizontally. Most frameworks (LangChain, CrewAI, AutoGen, custom LLM pipelines) give you tools and prompts, not a memory store. State management is treated as your problem.

That's a reasonable default for task automation. It becomes a real limitation when your agent is doing work that builds on itself: data pipelines with evolving schemas, monitoring agents that track drift over time, orchestration agents that learn which downstream systems are flaky, multi-step research jobs that accumulate findings across runs.

What stateful agents actually need to store

Not everything that happens in a run deserves persistence. The signal-to-noise ratio in a typical agent trace is terrible. What you want to preserve:

Decisions made and why. If your agent picked approach A over approach B, that reasoning is worth keeping. Next run, it won't have to re-evaluate the same tradeoffs.

Environment state at key points. Schema snapshots, API response shapes, rate limit observations. Things that change slowly but matter a lot when they do.

Failure history. Which steps failed, under what conditions, with what errors. An agent that knows "this endpoint times out above 50 req/min" behaves very differently than one that learns it fresh every run.

Task progress and checkpoints. Long-running jobs need to be resumable. Storing checkpoint state lets you restart mid-run instead of from scratch.

Entity relationships. The agent's working model of the system it operates in. Which services depend on which, who owns what, what's considered stable vs volatile.

// Example: what a monitoring agent might store after each run
await memory.remember({
  store: "semantic",
  category: "fact",
  title: "payments-service latency baseline",
  content: "p99 at ~240ms under normal load. Spikes above 800ms correlate with scheduled DB maintenance window (Sun 02:00 UTC).",
  tags: ["payments-service", "latency", "monitoring"]
});

What not to store

Every raw LLM turn. Intermediate scratchpad work. Observation logs that can be re-derived from source data. The temptation is to store everything "just in case," but that tanks retrieval precision faster than anything else.

Write governance matters more than write volume. Set importance thresholds. Require a minimum salience score before anything hits long-term storage.

Retrieval at agent startup

The pattern that works: wake briefing at the start of each run, targeted recall during execution.

Wake briefing pulls a scoped snapshot: recent decisions relevant to this task, known environment state, any failure history for the systems this run will touch. Keep it tight. 5-10 memories is better than 30.

async function agentWakeup(taskType: string, systems: string[]) {
  const context = await memory.recall({
    query: `${taskType} context and history`,
    tags: systems,
    limit: 8,
    stores: ["semantic", "episodic"]
  });

  return buildSystemPrompt(context);
}

During execution, targeted recall fires when the agent hits a decision point or encounters an entity it has prior history with. This is where entity extraction pays off -- if the agent recognizes "payments-service" in its current context, it should pull memories tagged to that entity before acting.

The failure modes

Stale memory poisoning. Stored facts become wrong over time. An agent that confidently acts on outdated knowledge is worse than one that asks. Add TTLs to volatile facts. Add supersession logic so new observations can explicitly invalidate old ones.

Retrieval without ranking. Vector similarity returns "related" memories. It doesn't return "relevant right now" memories. Add recency weighting, task-type filters, and salience scoring. Otherwise your agent gets distracted by plausible-but-useless context.

No write discipline. Without filters, you get a noisy mess. Implement importance scoring at capture time. Archive low-signal memories. Run periodic pruning jobs.

Missing checkpoint boundaries. Long-running agents need explicit checkpoints. If you don't checkpoint at meaningful milestones, a failure three hours in means starting over. Checkpoint after each significant phase completes.

Memory Crystal as the implementation layer

Memory Crystal handles the storage and retrieval infrastructure so you're not building it yourself. It separates episodic memory (what happened) from semantic memory (stable facts), with a scoring pipeline on retrieval that combines vector similarity, recency, salience, and entity graph proximity.

The API is designed around agent workflows:

import MemoryCrystal from "@memory-crystal/sdk";

const mc = new MemoryCrystal({ apiKey: process.env.MC_API_KEY });

// Save a decision at end of run
await mc.remember({
  store: "episodic",
  category: "decision",
  title: "Switched to batch API for upstream sync",
  content: "Individual calls were hitting rate limits above 200 records/min. Batch API handles 5000/batch with no observed throttling.",
  tags: ["data-sync", "upstream-api", "rate-limits"]
});

// Recall relevant context at next run start
const priorContext = await mc.recall({
  query: "upstream sync rate limits and batch strategy",
  limit: 5
});

You get checkpoint primitives, TTL policies, and retrieval quality tooling without standing up your own vector infra.

Checklist for stateful agent design

Define what gets stored: decisions, environment state, failures, entity relationships
Set write governance: importance scoring, TTL by memory type, pruning schedule
Build wake briefing retrieval at run start (8-10 memories max)
Add targeted recall at decision points and entity encounters
Implement checkpoint boundaries for long-running jobs
Add supersession logic for volatile facts
Run recall probes weekly to verify precision holds

Stateless agents are fine until they aren't. Once your agent is doing work that accumulates over time, the memory layer is load-bearing.