Arrastra Relay

AI agents are replaceable. Their work shouldn’t be. Arrastra Relay preserves every decision, proof, and handoff so teams can move faster without losing trust.

Comment

The problem

AI agents are replaceable. Their work shouldn’t be.

Long-running agent work breaks at the handoff. When a task moves to a new conversation, model, provider, or person, the successor usually receives a summary. What it often loses is the authoritative state, supporting evidence, governing policy, and precise definition of done.

That gap creates two expensive failure modes: silent drift and confident false completion.

Arrastra Relay is a trust layer for agent workflows. Agents can investigate, hand off, and resume work, but the application—not the model—owns the state, the rules, and the authority to declare the job complete.

What it does

We built a synthetic checkout incident to demonstrate the complete trust chain, including the moment an agent tries to close the incident too early.

  1. A human establishes one non-negotiable closure rule: the checkout must be tested after rollback.
  2. An investigator agent calls read_incident to receive the authoritative state, current revision, evidence, and handoff contract.
  3. It calls submit_handoff with canonical structured data bound to the source-set hash and evidence identifiers.
  4. A successor context calls read_handoff and receives the retained artifact, remaining requirements, application receipt, and predecessor summary clearly labeled as untrusted.
  5. If the successor attempts to close the incident early, the application returns VERIFICATION_REQUIRED without advancing the revision.
  6. run_verification performs the application-owned synthetic checkout and issues a verification receipt.
  7. submit_resolution can then bind the handoff, verification receipt, evidence, and final artifact into a committed revision.
  8. The human can inspect or export the complete application-owned audit record.

The arrastra visualization is not decorative animation. Seven visual beats are driven by real application events; the eighth occurs when the human opens the audit view. If the underlying workflow does not advance, neither does the mill.

Why WebMCP is essential

WebMCP turns Arrastra Relay from a dashboard into an agent-native application.

The page exposes exactly five semantic tools through document.modelContext.registerTool(...):

  • read_incident
  • submit_handoff
  • read_handoff
  • run_verification
  • submit_resolution

The human and the agent operate against the same authoritative application state, but they have different responsibilities. The human can inspect policy, evidence, status, receipts, and history. The agent receives structured tools for performing the workflow.

The mutation sequence is intentionally not duplicated with manual buttons. A person cannot impersonate the agent path simply to make the demo advance.

All five tools remain registered throughout the session because the refusal is part of the product. An early resolution attempt must reach the application so the application can reject it, preserve the failed attempt, and return the exact corrective action required.

Agents also carry forward application-issued source, evidence, and receipt identifiers. They do not invent the hashes or decide whether the evidence is sufficient.

Human-agent experience

The human sets the rule and retains visibility into every consequential transition. The agent receives structured contracts, current-revision guidance, and actionable errors instead of guessing through a mouse-oriented interface.

The application arbitrates between them.

A rejected closure attempt becomes evidence that the gate worked. A successful resolution becomes a durable receipt tied to the evidence chain—not another unsupported statement that the task is “done.”

Implementation

The architecture is intentionally narrow enough to understand and audit:

  • ChatGPT Sites serves the public Worker and static client.
  • D1 stores an independent incident record for each visitor session while sharing that record across the visitor’s browser and conversation contexts.
  • The same deterministic domain and service layer runs locally and in the hosted Worker.
  • Revision checks provide compare-and-swap protection against stale writes.
  • Submitted JSON is parsed, structurally validated, canonicalized, hashed, and retained with explicit evidence identifiers.
  • Predecessor prose is labeled and handled as untrusted data. It never controls the completion gate.
  • The UI, choreography, receipts, and audit table are all derived from application state.

What makes it different

Agent handoffs are usually treated as context transfer. Arrastra Relay treats them as continuity of authority.

A successor receives more than the previous agent’s explanation. It inherits the current state, retained evidence, unresolved obligations, and application-issued receipts—without inheriting the predecessor’s right to be believed.

Incident response is the first use case because the cost of a false “done” is easy to see. The same pattern can support other completion-sensitive workflows where teams want the speed of agents without allowing model confidence to become operational truth.

Arrastra Relay is not another memory layer or a better summary. It is an application-level control layer for deciding when agent work has actually satisfied the rules.

What we learned

Trust does not come from a stronger model or a more persuasive handoff. It comes from placing authority at the correct layer.

WebMCP callbacks do not establish trustworthy model identity. Hashes can bind an artifact to a record, but they cannot prove that an external-world claim is true.

The prototype therefore makes narrow, testable claims:

  • Revisions prevent stale writes.
  • Canonicalization binds retained artifacts to stable hashes.
  • Evidence identifiers preserve the application’s evidence chain.
  • The verification receipt proves that the application ran its defined check.
  • Only the application can advance the incident to resolved.

Arrastra Relay does not claim that a hash makes an agent truthful. It demonstrates how an application can keep unsupported confidence from becoming committed state.

How we used AI

We used AI broadly, but not blindly.

OpenAI Codex and ChatGPT, Anthropic Claude, selected NVIDIA-hosted and OpenRouter-hosted models contributed to concept exploration, adversarial threat modeling, test-oracle design, implementation review, and edge-case analysis. Meta AI produced the final entrant-directed interface image, and ElevenLabs provided the Adam narration voiceover.

Every outside-model result was treated as a proposal. Claims, code, diffs, and tests were independently checked before adoption.

How we used Codex

Codex was the primary engineering and verification environment.

It reconciled the challenge rules, maintained the project’s decision and assistance ledgers, implemented and reviewed the WebMCP and D1 application, ran the 16-test suite, exercised the complete reject-verify-resolve workflow in a WebMCP-capable browser, verified hosted state and logs, froze the rc3 release candidate, deployed the exact build, and published the matching source tree.

Key features

  • Five working WebMCP tools with strict input schemas and bounded outputs.
  • Application-authoritative state shared across contexts within one visitor session.
  • Evidence-linked, canonical structured handoffs.
  • Revision checks and stale-write rejection.
  • Visible rejection of premature completion.
  • Application-owned verification receipts.
  • Evidence-gated final commits.
  • Untrusted predecessor-summary containment.
  • Seven event-driven workflow beats, one human audit beat, and an exportable audit record.

Built With

Share this project:

Updates

Submission history