Skip to lesson

Google CloudProfessional Agentic Architect2026-093.3 Orchestrating and coordinating agentic workflows

Coordinate the five handoff responsibilities

Completed by the knowledge check

Learning objective

Coordinate Agent Identity, Agent Registry, Agent Runtime, session state, and policies during a handoff. Assign each one its distinct responsibility so that the receiving agent is discoverable, authenticated, runnable, context-aware, and authorized.

Core idea

Treat a handoff as five separate responsibilities joined by one contract:

ResponsibilityComponentQuestion it answers
DiscoveryAgent RegistryWhich approved agent advertises the required capability, and how can the orchestrator reach it?
AuthenticationAgent IdentityWhich running agent made the request?
ExecutionAgent RuntimeWhere does the receiving agent execute and scale?
ContinuitySession stateWhat interaction history and workflow checkpoint must survive?
EnforcementPoliciesMay this caller use this destination and operation with this context?

No row replaces another. A registry entry is not a credential. A valid identity is not permission. A running endpoint is not conversation state. A session ID is not authorization. A policy cannot execute the agent.

How a handoff works

Suppose a coordinator delegates one unit of work to a remote specialist:

  1. Resolve the destination. Query Agent Registry for an agent whose advertised capability and protocol interface match the task. Registry metadata supplies a logical identifier and connection information. Google Cloud explicitly distinguishes the registry’s agent identifier from the secure agent principal.
  2. Build a bounded handoff. Send the task, necessary input or artifact references, correlation data, and any existing receiver-side context or task identifiers. For new remote work, store the identifiers that the receiver returns. Do not copy the entire source session by default. Minimize data according to the receiving agent’s purpose and retention rules.
  3. Authenticate the caller. The receiving boundary verifies the coordinator’s Agent Identity. Agent Identity binds a managed workload principal to the deployed resource, giving policy and audit systems a verifiable caller. It does not represent the end user and does not grant a requested action by itself. See the Agent Identity overview.
  4. Evaluate policy. Apply policy to the authenticated principal, destination, operation, and trusted request attributes. Google Cloud policies include IAM policies for agent communication and semantic governance policies for tool invocations. The receiving agent and its tools must still enforce their own data and business rules.
  5. Execute and persist. Agent Runtime hosts and scales the receiving agent; it is the compute boundary. The receiver creates or resumes its own session, records events and compact workflow state, and returns a result or a trackable task. Agent Runtime is a managed execution environment, while Agent Platform Sessions separately maintains interaction history and state.
  6. Reconcile the result. The coordinator validates the response, updates its own session checkpoint, and records the remote task, trace, registry destination, and policy outcome. Retries should reuse an idempotency or task key when the operation could cause a duplicate side effect.

For an Agent2Agent (A2A) handoff, keep protocol context separate from storage context. A2A’s contextId logically groups related tasks and messages, and a taskId identifies one stateful unit of remote work. The receiving agent may use contextId to maintain internal state, but the A2A context rules do not define it as a shared database key or copy the coordinator’s session. Map identifiers explicitly and treat a server-generated contextId as opaque.

Key distinctions and trade-offs

Shared context versus bounded context: Sharing more history can improve continuity, but it increases disclosure, token use, and coupling. Prefer a task-specific summary, stable resource references, and the exact artifact versions the specialist needs. Keep the authoritative workflow checkpoint in a durable session store so another runtime instance can resume it.

Stable discovery versus live execution: A registry can provide stable lookup and governed metadata even while infrastructure changes. It does not prove that an endpoint is healthy or that the request will succeed. Runtime health, timeouts, retries, and task status remain execution concerns.

Central policy versus local authorization: A central policy can restrict which agent-to-agent routes are permitted. The specialist still understands operation-specific facts that the central boundary might not know. Enforce coarse route permission centrally and resource or business authorization at the destination.

Architecture / decision scenario

A claims coordinator must ask a fraud specialist to score one insurance claim. Both agents run on Agent Runtime, and the specialist is published in Agent Registry with an A2A interface.

The coordinator discovers the specialist by its registered capability, then sends the claim ID, the exact evidence-artifact versions, a purpose, a remote contextId, and a unique task key. It does not send unrelated messages from the customer’s session. The specialist authenticates the coordinator’s Agent Identity. Policy permits that principal to call the scoring capability but not the specialist’s administrative operations.

The specialist runtime creates a task and stores progress in its own session. After completion, it returns a scored artifact and task ID. The coordinator records those references and the decision in its original session. If the specialist runtime restarts, persisted specialist state supports recovery. If the registry entry exists but policy denies the caller, the handoff stops; the catalog entry never overrides authorization.

This design preserves a clear failure boundary: registry failure affects discovery, identity failure affects authentication, runtime failure affects execution, session failure affects continuity, and policy denial is an intentional enforcement result.

Common exam traps

  • Treating registration or a registry binding as permission to invoke an agent.
  • Using a registry identifier as though it were the authenticated agent principal.
  • Assuming deployment on Agent Runtime automatically transfers conversation state between agents.
  • Treating an A2A contextId as a globally shared session or as authorization to read that context.
  • Forwarding an upstream authorized: true flag instead of making the receiving boundary evaluate policy.
  • Passing the entire transcript when a bounded summary and artifact references satisfy the handoff.
  • Diagnosing every failed handoff as a runtime outage instead of locating the failed responsibility.

What to remember

  • Use Agent Registry to discover; use Agent Identity to authenticate.
  • Use Agent Runtime to execute; use session state to preserve continuity.
  • Evaluate policy at every trust boundary and authorize the requested operation at its destination.
  • Pass a minimal, explicit handoff contract and map remote context IDs to local sessions deliberately.
  • Classify failures by responsibility before choosing recovery behavior.

Knowledge check

References