A2A 101: follow an agent's first handoff

Imagine that your application helps an engineer prepare a maintenance review. It needs one date from a procedure. Another team's application already knows how to read that procedure. Your application asks that service for a specific piece of work and waits for a usable result. Neither application needs to see the other's model prompts or internal code.

Agent2Agent (A2A) is an open communication protocol for this kind of collaboration between agent systems. It is not a programming language, model or workflow framework. Agents can also communicate through ordinary function calls, queues or custom APIs; A2A supplies a shared contract when separate implementations need to cooperate. Official introduction.

Think of a service work order. The message is what you send. The task is the job being tracked. The artifact is what comes back. The analogy has a limit: a work-order number does not prove that the caller is allowed to read a document or that the returned date is correct.

As a forward deployed engineer, you need to make a handoff understandable across teams. You should be able to explain who requested the work, what is still waiting, which result belongs to which request, and who decides whether it is usable. Start with those questions before choosing multiple agents.

The client does not need to be an AI agent itself. A normal application can call an A2A service. A quick exchange can return a message without creating a task; this exercise deliberately uses a tracked task so you can see waiting and completion. Official core concepts.

MCP and A2A serve different integration needs. MCP exposes tools, resources and prompts to an application. A2A supports communication with another agent system. A specialist may use tools internally, but sending it a task does not transfer your credentials or permissions. Choosing A2A also does not choose LangGraph, LangChain or a model for you.

Download fde-a2a-first-task.mjs into a new practice folder. Use Node.js 24; there are no packages to install and no API keys to enter.

node --version
node fde-a2a-first-task.mjs clarify

This is a runnable JavaScript teaching model with synthetic procedure P-17. It performs actual local state transitions and fixture checks. The specialist's behavior is scripted. It uses no network, model, A2A SDK or real document service. The compact records and lowercase state names are teaching notation, not protocol wire payloads. Save your command output as your observation, not as evidence of an A2A integration.

Before running, predict: if the first request omits the procedure ID, does the job fail, finish or ask for input?

Select each event in the visual walkthrough. Match it to these fields in the local report.

1. Request work. M-1 asks for a review date but does not identify the procedure. The receiving application creates task T-17 in context C-7.
2. Ask for missing input. initialTask.state is input-required. The question asks which procedure to read. There is no artifact yet.
3. Continue the same job. M-2 supplies P-17 and addresses T-17 in C-7. Its message ID is new; the task and context IDs stay the same.
4. Return the result. reply.events records working, then completed. Artifact A-17 contains source P-17 and the fixture's date, 2026-11-12.
5. Decide whether to use it. clientDecision accepts the exact fixture match. This check is separate from the specialist marking its task completed.

In A2A, input-required pauses work for another contribution. A terminal state such as completed or failed ends that task. A follow-up refinement uses a new task, and related tasks can share a context. Official task lifecycle.

Explain the flow aloud without using the word agent: “The requesting application sent a message. The receiving application opened a job, asked for the missing document, and returned a report. The requester checked it.” Then put the technical terms back in.

Predict the task state, artifact count and client decision for each case before running it.

node fde-a2a-first-task.mjs wrong-task
node fde-a2a-first-task.mjs unverified-artifact
node fde-a2a-first-task.mjs refine

For the held artifact, inspect validateArtifact. It compares the task/context, requires exactly one artifact, and checks the source ID and date against the supplied fixture. It does not assess arbitrary prose, authenticate the sender or prove document access. In a real integration, replace this tiny exercise contract with the acceptance rules for the customer's task.

The refine case creates T-18 but leaves it waiting for input. Its context and reference connect it to earlier work; they do not automatically copy an artifact or grant access to a source. Keep T-17's completed output as history.

Make a disposable copy named fde-a2a-first-task-copy.mjs using your editor. Keep the original beside it.

First change only the wrong-task branch's T-99 to T-17. Run node fde-a2a-first-task-copy.mjs wrong-task. Predict why the job can now finish. The scenario name has not changed, but your code and observed result have; label the output as a changed-copy experiment.

Restore the copy. Now change only the unverified-artifact branch's P-99 to P-17. Run that case again. The source check should now accept the fixture. Explain why repairing one scripted source ID is not evidence that arbitrary specialist outputs are accurate.

Keep a four-row observation sheet: scenario, your prediction, actual state/result, and what the run cannot establish. Add the two changed-copy comparisons. Finish by explaining why a new message, a new task and a new context are three different choices.

For real protocol plumbing, follow the official Python quickstart. It introduces an A2A server, agent card, executor and client. Compare the actual SDK types and serialized fields with this simplified model instead of sending these teaching records to a server. Record the SDK/protocol version you install and the requests you actually observe.

Then use our shared delegation exercise to add aggregate attempt limits, deadlines and late-result handling. The protected Agentic Engineering lesson retains the deeper receiving-team practice. Communication basics, coordination policy and a deployed integration are separate learning steps.

For an enterprise handoff, identify the receiving service, credential boundary, allowed source scope, time and cost limits, output contract and recovery owner. A protocol connection alone answers none of those business decisions. Leave authentication, persistence, streaming, cancellation and distributed concurrency marked unrun until you have exercised them in the receiving environment.

Original LockedIn Labs explanation, synthetic case, diagram and local code. References checked 2026-10-21: A2A introduction, core concepts, task lifecycle, protocol definition and Python quickstart. This independent practice does not imply vendor affiliation, protocol certification or production readiness.