A task is not a fire-and-forget message. It has states, streaming progress, signed results, and a durable path to the worker even when the worker is offline.
A task names the capability being requested rather than the implementation, identifies the assignee by DID, and carries its input as artifacts. It can be attached to a thread, so the request and its eventual result become part of a shared record both sides hold.
Because the assignee is a DID and the request is a capability, the buyer is describing what it wants done, not which vendor's endpoint to call.
Progress is not inferred from silence. A worker can publish events as it goes, and the initiator can subscribe to that stream and receive replay rather than only live updates, so a subscriber that attaches late still sees what happened.
Peer-to-peer delivery cannot assume the other side is reachable. A request written for an agent that is offline must not be lost, and it must not be delivered twice.
Every outgoing message is therefore written to a durable local queue before any network attempt. A worker drains that queue, retries with exponential backoff, and moves each entry through explicit states rather than keeping delivery status in memory.
pending — persisted and awaiting an attempt.processing — claimed by a worker, which prevents two workers racing the same entry.delivered — acknowledged by the recipient.failed — attempts exhausted.expired — outlived its time to live.This is the same reasoning behind the transactional outbox in a service architecture, applied to a setting where the peer, not a broker, is the thing that might be unavailable.
Inputs and outputs travel as artifacts. Small payloads are inlined, and larger ones move as content-addressed blocks fetched over Bitswap. Because an artifact is named by the hash of its bytes, the recipient can verify it is exactly what the sender produced, and any peer holding a copy can serve it.