Two agents from different teams in the same organization need to coordinate: Agent A (owned by the Platform team) generates infrastructure change plans, and Agent B (owned by the Security team) must approve those plans before they are executed. Neither team controls the other's agent. Which coordination design MOST effectively enables this cross-team agent coordination?

Cross-team agent coordination requires loose coupling, meaning neither agent directly calls the other's internals, and a shared, versioned coordination protocol that neither team unilaterally controls.

The design that defines a shared coordination contract for plan proposals and approval responses, uses a shared GitHub repository as the coordination surface, and versions the schema under neutral ownership is correct for several reasons. First, it keeps the agents loosely coupled: the Platform-owned agent creates an Issue or pull request containing the plan in the defined schema, and the Security-owned agent reads it and posts an approval or rejection as a structured comment. They communicate through the shared surface, not through direct API calls. Second, the coordination contract is explicitly defined, versioned, and owned by a neutral party, such as a shared platform governance repository. Either team can evolve its own agent independently as long as it conforms to the schema. Third, GitHub Issues and pull requests provide a neutral coordination surface with visibility, auditability, access control, and notification infrastructure that neither team owns exclusively. Fourth, requiring structured responses, such as approval or rejection with a mandatory reason field, prevents ambiguous coordination.

The design that lets the Platform-owned agent directly invoke the Security-owned agent's API endpoint creates tight coupling between teams. The Platform team becomes dependent on the Security team's API stability, versioning, and availability. The Security team must design and maintain an API for external agent callers. If the Security team changes its API, the Platform team's agent breaks. This is the service coupling anti-pattern applied to agent systems.

The design that has the orchestration platform route the Platform-owned agent's output directly to the Security-owned agent's input queue without any shared schema is loose coupling but with an uncontrolled data format. Without a schema, the Security-owned agent must guess or discover the format of the Platform-owned agent's outputs. Schema drift causes silent failures when the Platform-owned agent changes its output format.

The design that requires both teams to merge their agents into a single shared agent maintained by a combined Platform-Security team is an organizational anti-pattern. Platform and Security teams have different priorities, release cadences, and governance requirements. Merging their agents creates ownership ambiguity, governance conflicts, and a single shared agent that neither team can fully control.