AFTERLIFE

Kill the agent. Not its memory.

AI agents are increasingly trusted with long-running work. But their compute is ephemeral: a process crashes, a container restarts, a serverless invocation disappears — and suddenly the agent may lose not only context, but the work it had already done and the commitments it made.

AFTERLIFE explores a simple idea: an agent's runtime should be disposable. Its continuity should not be.

Inspiration

We usually treat agent memory as conversation history or retrieval.

But production agents need something stronger.

If an agent promises to complete a task, performs two of three steps, and then its runtime dies, what should happen?

A replacement agent should not start from zero. It should recover:

  • who it is
  • what it was doing
  • what has already been completed
  • what it remembers
  • and, crucially, what it still owes

That is the problem AFTERLIFE demonstrates.

What it does

The demo begins with Agent A-7 — Generation 1.

It receives a three-step task and a commitment:

"Deliver synthesis to Agent B."

A-7 completes two steps.

Then we deliberately kill its runtime.

The compute disappears.

The durable state does not.

When REBIRTH is triggered, a new runtime appears as Agent A-8 — Generation 2.

Using CockroachDB, it recovers the unfinished task state and retrieves relevant persistent memories.

It knows that 2/3 steps were already completed, so it does not replay completed work.

Generation 2 performs only the remaining step.

The original commitment becomes:

FULFILLED.

This turns persistent memory from a passive archive into an active mechanism for agent continuity.

Why CockroachDB matters

CockroachDB is not an incidental datastore in AFTERLIFE.

It is the system of record for the agent's continuity.

It persists structured state for:

  • agent identity and generations
  • tasks and progress
  • commitments
  • episodic and identity memories
  • runtime events

AFTERLIFE also uses CockroachDB Distributed Vector Indexing for semantic memory retrieval.

During rebirth, the new runtime retrieves memories relevant to restoring continuity rather than simply loading an undifferentiated transcript.

Operational state and semantic memory therefore live together in one durable system.

CockroachDB tools used

1. Distributed Vector Indexing

Memories are stored with vector embeddings and retrieved semantically during continuity restoration.

This demonstrates long-term agent memory without requiring a separate vector database.

2. CockroachDB Agent Skills

The repository includes a machine-readable skill at:

skills/survive-runtime-failure/SKILL.md

It describes the recovery behavior an agent should follow after runtime failure: restore durable state, retrieve relevant memory, resume unfinished work, and preserve commitments.

AWS integration

The agent API runs on AWS Lambda.

That choice is deliberate.

Lambda makes the distinction at the heart of AFTERLIFE extremely visible:

Compute is ephemeral. Continuity is durable.

The public frontend communicates with the Lambda Function URL, while CockroachDB remains the persistent system of record across runtime generations.

Architecture

Public Web Demo → AWS Lambda → CockroachDB

AWS Lambda provides the ephemeral agent runtime.

CockroachDB provides the durable continuity layer containing identity, generations, task progress, commitments, memories, runtime events, vector memory, and semantic retrieval.

When the runtime fails, a new generation restores its state and relevant memories from CockroachDB and resumes unfinished work.

The key demo

The complete failure/recovery sequence is intentionally simple:

RESET → WORK → WORK → KILL → REBIRTH → WORK

The state transition is:

Generation 1: 0/3 → 1/3 → 2/3 → RUNTIME KILLED

Then:

Generation 2: CONTINUITY RESTORED → 2/3 → 3/3 → COMMITMENT FULFILLED

The important detail is the 2/3 → 2/3 transition across runtime death.

The new runtime remembers what was already done.

Challenges

The hardest part was making failure real enough to demonstrate continuity without faking the effect in the frontend.

Runtime events, task progress, commitments, and memories therefore live in CockroachDB rather than browser state.

I also had to make the public AWS Lambda/frontend integration reliable, including Function URL deployment and CORS configuration, while keeping the deployment intentionally small and reproducible.

What I learned

The project changed how I think about agent memory.

Memory is not merely:

"What did the user say before?"

For autonomous systems, memory also includes:

What did I do?

What remains unfinished?

What did I promise?

That last question is particularly important.

An agent that remembers facts but forgets its obligations is not truly persistent.

What's next

AFTERLIFE is a compact demonstration of a larger architectural pattern.

The same continuity layer could support coding agents, research agents, operational agents and multi-agent workflows that survive deployments, crashes, region changes, model changes, or replacement of the runtime itself.

Future work would extend AFTERLIFE toward concurrent agents, richer commitment graphs, stronger recovery policies, authentication, observability, and multi-region failure scenarios.


Built by Mathieu D. WEILL

Compute is ephemeral. Continuity is not.

Built With

Share this project:

Updates