AnthropicClaude Certified Architect – Professional2026-103.7 Evaluate connection protocols and select the appropriate integration mechanism (MCP, API/CLI, agent-to-agent)
Own acceptance across independent agent systems
Completed by the knowledge check
Learning objective
Choose agent-to-agent delegation for work across independently operated agents or systems, defining identity, trust, task contracts, result formats, and observability.
Core idea
For an architect integrating another team’s or supplier’s agent, delegation means assigning an outcome while the receiver owns how it performs the work. Within one harness, you can configure specialist definitions and result routing. Across independent systems, the additional problem is accepting work where you cannot configure the other agent’s internal tools or release process.
Choose this relationship when the receiver needs its own planning, context, or task lifecycle. If it only returns a record for fixed parameters, a tool is usually sufficient. Independent operation, not a different machine or model, creates the need to define mutual trust, service responsibility, and acceptance explicitly.
Agent2Agent (A2A) is one concrete protocol for external delegation. The exam objective names agent-to-agent integration without mandating A2A. The identifiers here come from the A2A version 1.0.0 canonical model; select a supported interface and protocol version rather than assuming every agent service implements the same binding.
How it works
Establish who can request which work
An A2A AgentCard describes the agent, including supportedInterfaces, skills, securitySchemes, and securityRequirements. An advertised skill helps a client discover a candidate. It does not establish that your organization trusts the operator or that every caller is authorized to use the skill.
A2A treats identity at the protocol layer. Production HTTP bindings require HTTPS, and clients should validate the server’s TLS certificate. The client obtains credentials out of band and includes them in the binding’s headers or metadata for every request. The server authenticates requests and applies its own authorization policy, which can consider skills, actions, data access, and OAuth scopes.
Define the acting principal deliberately. A supplier accepting your application’s service identity has not necessarily authenticated the employee who initiated the request. If the workflow requires user attribution, agree how the supplier verifies and records it. Never turn an unverified user identifier in a task message into an authenticated delegation grant.
The trust review should name the selected operator, allowed data, accepted task types, and the owner who can revoke access. The card is discovery metadata for that review. Even a validly authenticated agent can return unsuitable or misleading content, so transport trust and result acceptance remain separate.
Delegate a bounded task, not unrestricted authority
A2A SendMessage can yield a message or a task. A Task has a server-generated id, a status, optional contextId, and optional artifacts and history. Use the task identity to track the accepted assignment rather than assuming the HTTP call itself contains the whole work lifecycle.
The task’s business contract is your responsibility. Define what outcome is requested, which inputs are authoritative, what the receiver may do, when it should request clarification, and what constitutes an acceptable artifact. Keep this contract narrower than “do whatever is necessary.” A supplier authorized to recommend an allocation is not thereby authorized to publish it or commit funds.
For a Messages API application, a custom tool can request external delegation. Your handler implements the A2A client and persists the returned task identity. Naming the tool delegate_review does not make the Messages API execute A2A or transfer credentials automatically. The application must implement that behavior, just as it implements other client tools.
Preserve lifecycle distinctions
A2A distinguishes TASK_STATE_WORKING, TASK_STATE_INPUT_REQUIRED, and TASK_STATE_AUTH_REQUIRED. The last two are interrupted states: the task needs input or authentication rather than an unchanged retry. Route clarification to the person or application component authorized to supply it; do not let the delegating model invent a missing business approval.
Terminal states include TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED, and TASK_STATE_REJECTED. Preserve those distinctions in the local outcome. Completion describes the remote task’s status; your application must still evaluate the delivered artifact against its own business criteria.
Use GetTask to inspect a known task. If a response is lost after acceptance, reconcile the known task before creating another business assignment. If resending the message is necessary after a lost response, reuse its messageId and agree whether the operator deduplicates on that field: A2A makes Send Message idempotency optional. A task identifier alone does not establish that two submissions represent the same business assignment.
Your application tracks the task by its identity and still evaluates the delivered artifact itself.
Define results you can accept and observe
An A2A Artifact identifies output through fields including artifactId and parts. The protocol supports delivery structure; the business result still needs agreed content. For an illustrative supplier analysis, require a proposal identifier, source references, applicable input version, unresolved constraints, and a machine-readable decision payload. These are application-defined fields, not mandatory A2A properties.
Make the result sufficient for the next decision without requiring the supplier’s private reasoning or internal tools. Reject an artifact that omits a required constraint, even if the remote task is marked complete. Conversely, retain supported partial work as partial rather than silently promoting it to a final recommendation.
For observability, join the initiating business request to Task.id, each observed status.state, clarification events, and accepted artifactId values. Record the selected agent and interface version so a changed supplier release can be investigated. Avoid treating a descriptive agent name as an immutable identity.
Your operational view ends where the supplier’s instrumentation ends. Agree what the operator can provide during an incident: task lookup, failure explanations, artifact provenance, and escalation ownership. If the workflow cannot be defended without telemetry the supplier will not provide, that is a selection constraint rather than a logging problem your local agent can solve.
Key distinctions and trade-offs
These boundaries distinguish external delegation from related mechanisms:
| Alternative | Control retained locally | What changes with external delegation |
|---|---|---|
| Direct tool | Implementation dispatches a defined operation | Receiver chooses internal execution toward an outcome |
| MCP capability | Host invokes an exposed tool or obtains context | Task acceptance and lifecycle cross an independently operated system |
| SDK subagent | Host configures specialist definitions and capabilities | Other operator owns its runtime and releases |
The Claude Agent SDK invokes defined subagents through Agent and returns their final message to the parent. That is a harness mechanism, not an interoperable external delegation protocol. An external agent might use SDK subagents internally, but those details are not your integration contract.
External delegation buys access to independently operated expertise and planning. It costs visibility and direct control over execution. Do not choose it solely because a task is long: a long deterministic service operation can still be exposed as a tool.
Architecture / decision scenario
A government procurement team needs independent supplier-risk assessments for 300 bids. The service target is two hours, while a supplier’s agent normally needs twenty minutes and sometimes requests a missing ownership declaration. The procurement application must retain final eligibility decisions.
One proposal wraps the supplier as a synchronous lookup and treats any returned text as its answer. Another asks the supplier to expose its internal tools so the local agent can reproduce the assessment. The architect chooses external delegation because the supplier owns the investigation and clarification process, and neither alternative preserves that responsibility effectively.
The integration owner verifies the Agent Card against the approved supplier endpoint and authentication agreement. Each assignment names the bid revision, allowed source material, required findings, and the prohibition on awarding a contract. The application stores Task.id, handles TASK_STATE_INPUT_REQUIRED through a procurement officer, and tracks the task with GetTask within the two-hour delivery target.
A completed artifact lacks the required source references. The acceptance service rejects it as incomplete and opens supplier follow-up; it does not mark the bid eligible. Task status, artifact acceptance, and the procurement decision remain separately observable. The procurement owner retains the business decision, while the supplier owns investigation delivery and the integration team owns tracking and escalation.
Common exam traps
- Selecting delegation for a fixed lookup because the provider calls it an agent.
- Treating an Agent Card as a trust or authorization decision.
- Confusing interrupted states with terminal failure.
- Assuming a lost response means the supplier never accepted the task.
- Equating remote completion with local artifact acceptance.
- Treating the SDK’s
Agenttool as an external wire protocol.
Where the exam guide differs
The exam guide says “agent-to-agent” without prescribing a protocol. This Bite uses A2A 1.0.0 as one concrete external protocol; an Anthropic SDK subagent invoked through Agent is delegation inside a harness. In an exam item, identify the cross-operator relationship first: an option substituting local subagents for independent-agent delivery, or requiring a particular protocol that the stem does not require, is a distractor.
What to remember
Delegate across independent systems when the receiver owns meaningful execution decisions. Authenticate the relationship, bound the task, agree an acceptable artifact, and observe its lifecycle through stable identifiers. Your application retains acceptance and the business actions that follow.
Knowledge check
A procurement application delegates a supplier-risk assessment over A2A. The task moves to TASK_STATE_INPUT_REQUIRED because the supplier’s agent needs a bidder’s ownership declaration, which only a procurement officer may supply. What should the application do?
TASK_STATE_INPUT_REQUIRED is an interrupted state, not a terminal failure: the task needs input rather than a retry or a fresh assignment. The input must come from the person authorized to supply it, so the application routes it to the officer; a model-drafted declaration would invent a business fact the workflow requires a human to provide.An application sends an A2A SendMessage to a supplier’s agent, but the connection drops before any response arrives, so no task identifier was received. The supplier may already have accepted the work, and a duplicate assignment would be billed twice. What should the integration design specify for this case?
messageIdmessageId , relying on A2A to deduplicate every Send MessagemessageId , once the supplier agrees to deduplicate on itGetTask with the original messageId to retrieve the accepted taskmessageId to detect duplicates, so reusing it prevents a second assignment only where the operator has agreed to deduplicate on that field. GetTask looks up a known task by its identifier, which the client never received.A supplier’s agent marks an assessment task TASK_STATE_COMPLETED, but the delivered artifact lacks the source references that the procurement contract requires. The procurement application owns the eligibility decision. What should the application record?
An insurer’s claims application delegates fraud reviews to a partner’s agent, authenticating with the application’s service identity. Regulation requires the partner to attribute each review to the employee who requested it. A developer proposes adding the employee’s ID to the task message text. What should the architect do?
References
- Agent2Agent, Protocol specification, version 1.0.0
- Anthropic, Subagents in the SDK
- Anthropic, Tool use with Claude
- Anthropic, Claude Certified Architect – Professional Exam Guide