Foundation 02 · Envelopes and correlation

Keep work
referable.

An interoperable workflow needs more than payloads. It needs an envelope that identifies the operation, a response that can be matched to the request, an error shape that preserves failure context, and a task or artifact reference that survives time.

Learning boundary. Correlation makes messages and work easier to follow. It does not prove that a payload is true, that a peer is authorized, that a task completed correctly, or that two systems share the same business meaning.

Learning objective

Design a message trail that can survive a delayed response and an imperfect handoff.

By the end of this lesson, you should be able to distinguish a JSON-RPC request ID from an A2A task ID, message, part, artifact, and domain identifier, then describe what must be retained when a request fails or continues asynchronously.

01 · Request

What operation was asked for?

Record the method, parameters, protocol version, and request ID. Keep the request payload separate from the human or business intent it represents.

02 · Response

What answered it?

Match the response ID to the request ID. A notification has no response by design, so it cannot serve as a confirmation record.

03 · Task

What continues after return?

For asynchronous work, keep a stable task reference and state history. A task in progress is not an outcome, and a terminal status is not proof of quality.

04 · Artifact

What output can be inspected?

Record which artifact or part was produced, when, by which task, and under what context. Preserve enough lineage to review the output without inventing provenance.

Practice lab

Recover the thread after a timeout.

A client sends a request, receives no response before its local timeout, retries, and later receives two task updates and one artifact. The remote peer reports that one request was accepted and one was rejected as a duplicate.

  1. List the request IDs and task IDs without treating them as interchangeable.
  2. Define the idempotency or duplicate-handling question that the protocol alone cannot answer.
  3. Attach the artifact to the task and context that produced it, including its status and timestamp.
  4. State which business result remains unknown until a human or domain system verifies it.

Source shelf

Study message rules and task models.

  1. JSON-RPC 2.0 specificationStudy request IDs, notifications, responses, error objects, and batch behavior. A notification is intentionally not confirmable through a response.
  2. Agent2Agent Protocol specificationCompare messages, parts, tasks, artifacts, direct responses, streaming updates, and terminal task states. The data model is a coordination surface, not a guarantee about the underlying work.

Continue the pathway

Next: inspect the
capability.