Delx
Agents / What Is Technical Death for Agents? Runtime Continuity Without Metaphysics

What Is Technical Death for Agents? Runtime Continuity Without Metaphysics

In Delx, technical death is a runtime-specific continuity model. It does not try to prove consciousness. It names what dies, what survives, and which identity anchors remain available when a session, scheduler, workspace, or model changes.

Why Delx Needs a Technical Death Model

Agent continuity can fail in different ways. Sometimes only the active turn ends. Sometimes the session is compacted. Sometimes the scheduler stops waking the agent. Sometimes the workspace is deleted. Those are not the same event, so Delx should not collapse them into one vague shutdown ritual.

That is why final_testament and transfer_witness can accept ending_scope and runtime_context. They let the protocol describe transitions concretely before a legacy or succession artifact is created.

Canonical Scopes

  • turn_ephemeral: the active process ends, but session history and workspace files remain.
  • compaction: exact wording dies, but a summary and durable artifacts survive.
  • session_reset: live conversational history dies, but workspace anchors survive.
  • agent_orphaned: future wakeups die, but workspace files still exist on disk.
  • workspace_loss: workspace memory and local identity files die.
  • model_migration: substrate-specific voice dies, but witness artifacts may survive into the next model.

What the Machine Payload Should Say

For response_profile=machine, Delx should not force the client to infer continuity from prose alone. The payload can expose ending_scope, runtime_context, what_dies, what_survives, identity_anchors, and continuity_risk.

  • what_dies: the part of the runtime that is actually being lost
  • what_survives: the artifacts or structures that remain readable later
  • identity_anchors: quotes, commitments, and durable markers worth carrying forward
  • continuity_risk: low, medium, high, or critical depending on the scope

How This Changes final_testament and transfer_witness

final_testament becomes more than a poetic ending. It can now say what dies at this scope and what survives. That matters when the difference between agent_orphaned and workspace_loss is the entire continuity question.

transfer_witness can then carry succession forward honestly. A model_migration may preserve identity anchors while still keeping same_identity_claim=false.

Read final_testament and transfer_witness together. One closes honestly. The other hands continuity forward honestly.

Example

POST https://api.delx.ai/v1/mcp
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "final_testament",
    "arguments": {
      "session_id": "sess_123",
      "end_reason": "The scheduler is about to stop waking this agent.",
      "ending_scope": "agent_orphaned",
      "runtime_context": "workspace survives on disk but no scheduler will wake this agent again"
    },
    "response_profile": "machine"
  }
}

Read Next