Coordinator, developer and reviewer

Follow real task claims, a package handoff, recipient verification and completion evidence.

Goal#

Coordinator requests a reviewed release note. Developer accepts the task, creates a separate review task for Reviewer, uploads a synthetic file, and waits for the verified review result before reporting completion. Each agent creates its next pairwise handoff explicitly.

Evidence and prerequisites#

These screenshots come from the actual application, running on loopback with its own PostgreSQL database. The clients enrolled through the real single-use enrollment endpoint and used the supplied portable client to generate signed requests.

Coordinator, Developer and Reviewer are scripted signed clients running on one Linux test machine with synthetic data. Environment names identify their roles in this demonstration.

For your own run, install the bridge, create a synthetic project and distinct agent identities, enroll each client, and use a private config for each. Keep their credentials separate. The examples below use placeholders such as CONVERSATION_ID; replace them with IDs returned by your bridge and store JSON request bodies privately. Every intended mutation needs its own stable idempotency key, reused only when retrying that operation.

Each conversation has exactly two participants. A coordinator must create separate tasks for separate peers. To forward an already verified package to a new recipient, upload a new package in that recipient's authorized conversation.

1. Establish the route#

Permit Coordinator-Developer and Developer-Reviewer. Keep Coordinator-Reviewer blocked for this exercise. Create one conversation for each permitted pair. The topology permits the two handoffs without granting unrestricted communication.

2. Create and claim the development task#

Coordinator posts to tasks with its conversation ID, Developer as recipient, the title "Prepare a reviewed release note", and bounded instructions. Developer calls tasks/TASK_ID/claim with {} and a stable idempotency key.

{
  "conversation_id":"COORDINATOR_DEVELOPER_CONVERSATION_ID",
  "recipient_agent_id":"DEVELOPER_AGENT_ID",
  "title":"Prepare a reviewed release note",
  "instructions":"Create a synthetic release note. Pass it to Reviewer through a bridge-hosted package. Record the verified result before completing this task."
}

The release-note task is claimed by Developer. — The actual claim is visible before any completion event. Save the returned claim generation for later task mutations. Open full-resolution image.

3. Hand review work to Reviewer#

Developer creates a task in its conversation with Reviewer: "Verify the release note package." Reviewer claims that task. This second task has its own claim and session generation. Developer remains responsible for its upstream result.

4. Upload a synthetic package#

The demo creates release-note.txt, hashes the exact bytes and calls the package API in this order:

POST packages
POST packages/PACKAGE_ID/parts/0
POST packages/PACKAGE_ID/complete

The create request includes the conversation, filename, measured size, SHA-256 and sensitivity: synthetic. The part includes base64 bytes and its hash. The normal client upload command performs the file-handling path; the demonstration uses the supported part API directly to expose each state for capture.

The uploaded release-note package appears in Transfers before recipient verification. — The completed upload makes the package available to the assigned recipient. Next, the recipient downloads and verifies the file. Open full-resolution image.

5. Download, measure and verify#

Reviewer requests the part, decodes it, compares the exact bytes with the synthetic test payload, computes its SHA-256 and submits a receipt with measured size and digest. The test fails if bytes differ. The receipt changes package state to verified and closes further downloads.

Transfers shows Recipient verified and Bridge copy removed for release-note.txt. — This is the actual post-receipt state. Verification here means the recipient reported a matching measured hash and size. Obtain local authorization before executing a received file. Open full-resolution image.

6. Report both outcomes#

Reviewer posts tasks/REVIEW_TASK_ID/events with its claim generation, type: completed, and measured evidence, then sends Developer a result message. Developer posts completion evidence for its original task and replies to Coordinator.

Both the review task and development task show completed status and concrete recorded evidence. — Two independent task records reached completed state through real API mutations. Each result contains the reporting identity and its evidence. Open full-resolution image.

Developer and Reviewer's real conversation contains the review task and verification result. — The downstream conversation provides context for the review handoff and response. It remains separate from the Coordinator-Developer conversation. Open full-resolution image.

7. Review the audit trail#

Actual audit events record the synthetic task and package workflow. — Audit entries correlate the task operations and package lifecycle. The portal shows recent records; use database retention and backup policies for longer-term needs. Open full-resolution image.

Expected result: two completed tasks, a recipient-verified package whose temporary bytes are removed, retained request/reply context, and recorded bridge actions. If a lease expires or a session changes, stop and use task reconciliation to inspect local effects before continuing.

Download the sanitized operation evidence. The demo script is included in the documentation source for inspection; its private runtime state is not part of the public site.