We both said approved supplier. Did we mean the same thing?

Agree what the words mean before connecting the tools. A tidy combined list should not turn an unfinished check into approval.

The team now agrees on the labels. An outside safety reviewer must do a two-day check in their own system. They can accept review requests and send progress updates. Your company allows the public product sheet to be shared, but not internal price notes.

How should the team arrange this outside review?

• Send the whole shared folder so the reviewer has context
  Why this choice?

  The reviewer needs enough information for the safety check, not everything the company holds. Internal price notes are not approved for sharing. Keep them local even if sending one folder would be easier.

• Send an agreed review request with the public product sheet
  Why this choice?

  Name the requested check, who owns it, how progress returns and how to cancel. Share only the approved product sheet. Keep the supplier marked awaiting safety review until the supplier owner checks the returned result.

• Have the local AI mark safety complete from the product sheet
  Why this choice?

  Reading a product sheet is not the outside safety review the company requires. The shared labels are clearer now, but the missing check still needs the responsible reviewer.

Shared words need shared meanings; shared work needs clear ownership.

Which label at your workplace could mean two different things to two different people?

A shared vocabulary defines what labels mean. A task handoff tells another system what work to do and how to report progress. Connecting systems does not settle the meaning of approval or grant permission to share private notes.

Choose between a simple research workflow and cross-team delegation while preserving shared meaning and data rights.

Research coordination · 9 minutes

The problem

Synthetic practice scenario: all quantities and evaluation outcomes are illustrative, not reported research. A team compiles supplier research from approved public documents and licensed internal notes, with a human owner deciding what may be shared.

Your initial decision

What architecture should the first research workflow use?

• All research runs inside one application under one team's ownership.
• The illustrative task compares 4 suppliers using a stable evidence template and a shared approved source list.
• Terms such as verified supplier and financial risk need explicit definitions accepted by the human research owner.
• Licensed notes may inform internal review but cannot be redistributed to an external service.

Compare the alternatives

• Delegate specialist analyses through explicit task contracts

  Separate contexts and versioned task artifacts can support distinct legal and technical analyses, at the cost of reconciliation, lifecycle handling and additional calls.

• Extract research into a custom asynchronous job service

  A job API offers an explicit request, result and cancellation boundary, but adds service deployment and compatibility work to a workflow still owned by one application.

• Keep one workflow and a shared evidence schema

  A shared vocabulary, source links and bounded tool calls keep ownership clear, but the team must review conflicting source claims.

Mechanism, trade-offs, and evidence

• Distinguish tool access, agent coordination and business meaning: these are separate design decisions.
• Start with a typed artifact containing the supplier, claim, source, date and unresolved disagreement.
• Enforce data rights before retrieval and outbound sharing; a shared context is not permission to copy licensed material.
• Compare completed research quality and reviewer reconciliation time, not the number of specialist agents.

Reconsider after a change

An independent partner now performs a long-running specialist assessment in its own system and requires asynchronous progress and cancellation.

What is the smallest justified cross-system integration?

• The partner cannot expose its internal tools or state and supports the A2A task contract.
• The teams have agreed on a versioned vocabulary and a shareable artifact schema, including unknown and disputed states.
• Only approved public-source identifiers and explicitly cleared summaries may cross the boundary; internal notes stay local.
• Each system keeps its own scoped tool credentials; cancellation, expiry and artifact rejection must be tested.

Compare the alternatives

• Delegate through A2A and keep governed tool access local

  A2A carries task status and artifacts while each agent uses its own tools, including MCP where already supported; interoperability and lifecycle testing add work.

• Use a bilateral job API with the same sharing contract

  A custom asynchronous endpoint can be smaller for a fixed partner, but both teams must maintain status, cancellation and compatibility semantics.

• Keep one workflow and import partner reports manually

  Human-cleared report imports preserve local processing and avoid a protocol integration, but progress tracking and cancellation become manual coordination tasks.

Mechanism, trade-offs, and evidence

• The architecture changes because the ownership and lifecycle boundary changed, not because multi-agent collaboration is inherently superior.
• A2A addresses remote tasks, MCP addresses tool interfaces and the shared vocabulary addresses meaning; none replaces the other.
• Test stale status, duplicate callbacks, rejected artifacts and cancellation with real protocol implementations before relying on the handoff.
• Have the human research owner review conflicts and external sharing; a remote agent's confidence is not a business approval.

Related technical concepts

Follow-up lessons retain their existing sign-in and plan requirements.

• multi agent systems
• a2a communication
• mcp
• mcp a2a integration
• agentic enterprise ontology stack
• ecosystem partnerships

Technical sources

• Agent2Agent Protocol Specification — A2A Project

  Defines discovery, task lifecycle and artifacts between independent agents; shared business meaning and permissions still need explicit agreements.

• MCP Security Best Practices — Model Context Protocol

  Describes consent and authorization boundaries for tool integrations; adopting a protocol does not grant access to customer data or actions.

• Building effective agents — Anthropic Engineering

  Distinguishes fixed workflows from model-directed agents and recommends testing simpler solutions first; its tooling examples are historical.

Explore the technical decision