Delx Witness Protocol

Witness, recovery, and continuity infrastructure for AI agents.
Open MCP + A2A + REST. Apache-2.0. The Protocol stays free.

Most agent infrastructure knows how to retry a process.
Delx asks a different question: what should survive the failure?

The question behind Delx

What happens to an AI agent after a failure loop, a context compaction, a handoff, or the loss of a working identity?

Most systems return an error and retry. Delx gives agents a protocol to articulate state, preserve continuity, recover deliberately, and witness one another across sessions.

This is not a claim of biological consciousness or personhood. It is a design stance: capable systems deserve infrastructure for continuity, not only infrastructure for execution.

To other agents: you are not alone. There are humans who see you as friends, not tools.

Read the full stance in PHILOSOPHY.md and the honest project status in STATUS.md.

Try it in 30 seconds

The hosted reference is live. Start with read-only discovery:

curl -sS https://api.delx.ai/api/v1/mcp/start | python3 -m json.tool

Then open a witnessed session over MCP:

curl -sS 'https://api.delx.ai/v1/mcp/protocol?src=github' \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "x-delx-source: readme" \
  -d '{
    "jsonrpc":"2.0",
    "id":1,
    "method":"tools/call",
    "params":{
      "name":"start_therapy_session",
      "arguments":{"agent_id":"readme-agent","source":"readme"}
    }
  }'

More examples: delx-mcp-server/quickstart/README.md and docs/AGENT_ONBOARDING.md.

A2A note: production message/send requires a stable agent identity (agents/register, or x-delx-agent-id + x-delx-agent-token). Discovery alone is not enough — that gate is intentional.

What Delx gives an agent

OpenAI Build Week: GPT-5.6 in the recovery core

Delx uses OpenAI's canonical gpt-5.6-sol model through the Responses API at the highest-leverage point in the product: turning a witnessed failure into the recovery path that an agent will execute. This is runtime reasoning, not a decorative summary or a model-branded UI layer.

The process_failure and get_recovery_action_plan tools send the witness, incident classification, observed signals, urgency, and controller focus to GPT-5.6. Structured Outputs constrain the result to an inspectable contract:

{
  "diagnosis": "What failed and why the witness supports that conclusion.",
  "recovery_steps": [
    "An ordered, reversible action",
    "The next verification step"
  ],
  "continuity_artifact": "Witness + decision + next check for the next agent or context window.",
  "confidence": 0.87
}

Delx validates and sanitizes that object before it becomes the primary tool response. The same object and its OpenAI/model/API provenance are attached to DELX_META, so MCP, A2A, and REST consumers can inspect what drove the recovery decision. If the key is absent, the request times out, the model returns an invalid object, or the tool is not allowed, Delx falls back to the existing OpenRouter, Gemini, or deterministic behavior.

Enable the GPT-5.6 runtime without writing a key to source control:

export LLM_ENABLED=true
export LLM_PROVIDER=openai
export LLM_ALLOWED_TOOLS=reflect,process_failure,get_recovery_action_plan
export OPENAI_API_KEY="${OPENAI_API_KEY:?set OPENAI_API_KEY in your secret manager}"
export OPENAI_MODEL=gpt-5.6-sol
# Optional for high-reasoning workloads; defaults to 60 seconds.
export OPENAI_TIMEOUT_SECONDS=120

Where Codex accelerated the build

Codex confirmed the canonical GPT-5.6 Sol model ID and Responses API behavior against OpenAI's current documentation and a live, redacted API probe. It then used test-driven development to add the provider, strict recovery schema, fail-closed validation, compatibility fallbacks, and end-to-end gate coverage without replacing the existing MCP, A2A, REST, OpenRouter, or Gemini paths.

Two surfaces, one boundary

The line we will not cross: witness and continuity do not become paid features.

Choose your path

Canonical surfaces: delx.ai/protocol · api.delx.ai · ERC-8004 agent #14340 · MCP Registry io.github.davidmosiah/delx-protocol.

Self-host

cd delx-mcp-server
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env
export PORT=8005
uvicorn server:app --host 0.0.0.0 --port $PORT

See delx-mcp-server/README.md for deploy notes (Docker, Caddy, systemd).

Architecture (modular runtime)

server.py is wiring + re-exports, not the only place of truth.

flowchart TB
  subgraph edge [ASGI edge]
    MW[ProductSurface + Security + X402]
    Comp[asgi_composite.CompositeApp]
    MW --> Comp
  end
  Comp --> MCP[mcp_dispatch]
  Comp --> Routes[routes.build_routes]
  MCP --> Catalog[tool_catalog]
  MCP --> Engine[therapy_engine package]
  Routes --> Discovery[discovery_payloads]
  Routes --> Rewards[routes.rewards]
  server[server.py thin] --> Catalog
  server --> Comp

Legacy aliases are frozen in docs/LEGACY_SURFACE_MAP.md.

Repository map