# A2A 101: follow an agent's first handoff

LockedIn Labs Training · Edition 1 · 40-minute foundation and local exercise · Updated 2026-10-21

## 1. Start with a work order

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](https://a2a-protocol.org/latest/topics/what-is-a2a/).

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.

## 2. Give each part a job

| Part | What it means here | Familiar comparison |
| --- | --- | --- |
| Client | The requesting application | A service calling another service |
| Agent card | Metadata describing a service's capabilities and connection requirements | A service directory entry |
| Message | One turn of communication, identified by a message ID | One request or reply |
| Task | A tracked unit of work with its own ID and state | A job ticket |
| Context | A grouping for related interactions | A conversation folder |
| Artifact | The output of the work | A report attached to the ticket |

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](https://a2a-protocol.org/latest/topics/key-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.

## 3. Prepare the small local experiment

Download [fde-a2a-first-task.mjs](/templates/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.

```sh
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?

## 4. Follow one request through the diagram

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](https://a2a-protocol.org/latest/topics/life-of-a-task/).

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.

## 5. Challenge the handoff

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

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

| Case | What you should inspect | What it teaches |
| --- | --- | --- |
| wrong-task | M-2 addresses T-99; reply reason is unknown-task; T-17 still needs input and has zero artifacts | An answer to the wrong job must not silently finish the original job |
| unverified-artifact | The task is completed, but its artifact cites P-99; the client holds it | Reporting completion and accepting an output are different decisions |
| refine | terminalFollowUp is refused; newTask is T-18 in C-7 and references T-17 | The conversation continues without reopening the completed job |

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.

## 6. Change one thing and explain the difference

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.

## 7. Take the next step deliberately

For real protocol plumbing, follow the [official Python quickstart](https://a2a-protocol.org/latest/tutorials/python/1-introduction/). 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](/training/guides/agent-engineering#1d-inspect-a-shared-delegation-budget) 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.

## Sources and scope

Original LockedIn Labs explanation, synthetic case, diagram and local code. References checked 2026-10-21: [A2A introduction](https://a2a-protocol.org/latest/topics/what-is-a2a/), [core concepts](https://a2a-protocol.org/latest/topics/key-concepts/), [task lifecycle](https://a2a-protocol.org/latest/topics/life-of-a-task/), [protocol definition](https://a2a-protocol.org/latest/definitions/) and [Python quickstart](https://a2a-protocol.org/latest/tutorials/python/1-introduction/). This independent practice does not imply vendor affiliation, protocol certification or production readiness.