Cross-Organizational AI Coordination — A Trust Protocol Connecting Delegation, Federated Identity, and Decision Trace

🎥 The YouTube version is also available:

Autonomy Control for AI Coordination — Governing Multi-Agent Systems at Runtime

Books: Al Coordination Engineering A Practical Guide: Designing Coordination, Autonomy, and Trust in the Multi-Agent Era

Introduction

AI Agent coordination often begins within a single company or system.

A sales support agent references customer information. A procurement agent checks inventory and contract terms. A maintenance agent analyzes equipment conditions and makes recommendations to field personnel.

In reality, however, business operations do not end within one organization. Value is created through collaboration among multiple organizations: manufacturers and suppliers, logistics companies and retailers, hospitals and testing laboratories, local governments and private operators.

When AI Agents begin coordinating across organizational boundaries, the key issue is no longer simply API connectivity.

Who is acting on whose behalf? What has been delegated? Which information may be disclosed? How should differing policies be handled? And how can decisions and responsibilities be traced?

This chapter examines cross-organizational AI Coordination through the lenses of inter-company Agents, differing Policies and Trust, Cross-Organization Delegation, Federated Identity, information-disclosure boundaries, cross-organizational Decision Trace, and Trust Protocols.

Inter-Company Agents — AI Becomes an Organizational Representative

An AI Agent operating within an organization acts under that organization’s Knowledge, Roles, Policies, and authorities. When it crosses organizational boundaries, it becomes more than a technical client: it becomes a representative carrying the organization’s intentions and constraints.

Consider a purchasing Agent from a buyer organization making an inquiry to an order-management Agent at a supplier.

• The buyer’s Agent has requirements for quantity, delivery date, budget, and quality.
• The supplier’s Agent has information on inventory, supply capacity, pricing, and contract terms.
• The logistics provider’s Agent has information on transportation feasibility, delivery capacity, and temperature-control requirements.

Even when these three parties coordinate, not everyone should be allowed to see the same information. Cost structures, inventory allocated to other customers, negotiation strategies, personal data, and security-related information all have disclosure boundaries.

Therefore, inter-company Agents should not be designed merely as “Agents that exchange information.” They should be designed as Agents that coordinate within a delegated purpose, using only limited information and authority.

Differing Policies and Trust

When organizations differ, their Policies differ as well.

One company may prioritize delivery speed. Another may prioritize quality assurance. One organization may permit AI-based automatic purchasing, while another may require human approval.

The important point is not to impose one party’s Policy unilaterally on the other.

In cross-organizational coordination, at least the following three layers should be handled separately.

Trust cannot be reduced to a fixed score.

Even if a partner organization is generally considered trustworthy, separate questions remain: whether a particular Agent has authority to perform a specific Task, whether it complies with current Policy, and whether it can explain the evidence behind its actions.

Trust should be evaluated dynamically based on at least the following relationships:

• Can its Identity be verified?
• Does its Capability match the delegated responsibility?
• Is its Authority valid?
• Can Policy Compliance be confirmed?
• Can it provide Evidence and a Decision Trace?
• In the current Context, is it likely to act as expected?

In other words, inter-company Trust is not about evaluating a counterpart unconditionally.

It is about deciding how far an Agent can be entrusted at a specific moment, for a specific purpose, under specific constraints and Roles.

Cross-Organization Delegation

Cross-Organization Delegation is the act of one organization’s Agent delegating a Task or part of a decision to an Agent in another organization.

This is not merely an API call. Delegation includes purpose, scope, authority, constraints, expiration, and responsibility.

For example, when arranging transport through an external logistics provider’s Agent, a Delegation Contract should include elements such as:

• Purpose: Deliver the specified product by the required deadline.
• Scope: Present delivery options and make a provisional reservation for a delivery slot.
• Authority: Final contract confirmation only after human approval.
• Constraints: Temperature range, budget ceiling, delivery-destination restrictions, and applicable regulations.
• Information Scope: Only the minimum necessary address and product information.
• Expiration: Valid only for this order and until the specified time.
• Responsibility: Who gives final approval, and who bears execution responsibility.
• Trace Requirement: Record evidence, options, execution, and outcomes.

If delegation boundaries are vague, an Agent may request excessive information or perform unexpected confirmation actions. Conversely, if those boundaries are clear, the autonomy of the counterpart Agent can be used safely within the necessary scope.

Handling Re-Delegation

In cross-organizational coordination, a delegated Agent may in turn delegate work to another organization.

In that case, it must not exceed the scope originally authorized by the delegator. Whether re-delegation is allowed, whether information may be reused, how responsibilities are divided, and how the Trace is inherited should all be explicitly stated in the Delegation Contract.

If it is impossible to trace “who made the original request” and “through which path authority was transferred,” accountability is lost when an incident or dispute occurs.

Federated Identity

Cross-organizational coordination cannot begin unless the counterpart can be identified and verified.

Federated Identity is an approach in which each organization maintains its own identity infrastructure while making the identities of people, organizations, Agents, and Services mutually verifiable.

The questions to verify are not limited to an Agent’s name.

• Which organization operates the Agent?
• What Role does the Agent have?
• What Capabilities does it possess?
• On whose behalf is it acting?
• Which Authorities does it hold, and until when are they valid?
• Which Policies does it claim to comply with?

Identity and Authority must be distinguished.

Even if an Agent is verified as “an Agent of Logistics Company X,” that does not necessarily mean it has authority to finalize delivery arrangements for a particular shipment. Identity confirms who the Agent is and which organization it belongs to; Authority grants permission to perform a particular action for a particular purpose.

Using a Semantic Digital Twin or an Agent Capability Schema, Identity, Role, Capability, Authority, and Policy can be represented as relationships. This makes it possible not only to authenticate a coordination partner, but also to determine what may be requested from that partner and what must not be requested.

Information Disclosure Scope — Minimal Coordination, Not Full Sharing

The most dangerous assumption in cross-organizational AI Coordination is that all information should be shared in the name of collaboration.

In practice, a counterpart organization needs only the minimum information necessary to fulfill the purpose.

For example, an order-management Agent may not need the full product specification or all customer information. To determine delivery feasibility, it may need only quantity, temperature range, delivery region, and deadline—not the customer’s name or internal cost structure.

Information-disclosure scope should be designed around the following principles:

• Purpose Limitation: Why is the information being disclosed?
• Data Minimization: Is the information limited to what is necessary?
• Role-Based Access: Is the disclosure appropriate for the counterpart’s Role?
• Time Limitation: How long may the information be used?
• Re-use Control: Are secondary use and re-delegation permitted?
• Evidence of Consent: Is there a basis in consent, contract, or organizational authorization?
• Traceability: Can it be recorded who accessed or disclosed what?

The key is not to copy and share all information, but to provide verifiable claims when needed.

For example, a party may provide claims such as “This product can be transported within a temperature range of 2–8°C” or “The destination is not subject to hazardous-material handling requirements,” together with evidence and an expiration date. This enables coordination without disclosing original documents or confidential information more broadly than necessary.

Cross-Organizational Decision Trace

Within an organization, a Decision Trace records the evidence, alternatives, Policies, Actions, and Results behind a decision.

Across organizations, it must additionally record which information was provided by which organization, and who made which decision under what authority.

The main elements of a cross-organizational Decision Trace include:

• Participating organizations, Agents, Identities, and Roles
• Delegation Contracts and chains of authority
• Evidence provided by each organization and its disclosure conditions
• Applicable own-organization, counterparty, and joint Policies
• Shared Context and the boundaries of information that was not shared
• Candidate options, proposals from each Agent, agreements, and disagreements
• Human Gates, approvals, rejections, and escalations
• Executed Actions, Outcomes, and scope of impact

Not every internal reasoning process needs to be disclosed to a counterpart. In some cases, it must not be disclosed.

What matters is that the counterpart can verify, within the necessary scope, which conditions were satisfied and why a particular decision or Action was permitted.

For this reason, it is preferable to separate each organization’s internal Trace from the shared Boundary Trace, rather than concentrating all information in one central ledger.

Organization A Internal Trace
        │
        ├─ Boundary Trace ─── Organization B Boundary Trace
        │
Organization A Policy            Organization B Policy

The Boundary Trace records delegations, consent, evidence, and mutually verifiable results. Competitive confidential information, personal data, and detailed internal reasoning remain within each organization’s Internal Trace.

Trust Protocol

Cross-organizational AI Coordination should not be treated as a collection of isolated contracts and API specifications.

What is needed is a Trust Protocol that connects Identity, Capability, Delegation, Policy, Evidence, Trace, and Escalation.

A Trust Protocol is not a mechanism for authenticating a counterpart once and then forgetting about it. It is an operational protocol for verifying, updating, and—when necessary—suspending trust throughout the full lifecycle of coordination.

Basic Flow of a Trust Protocol

1. Discover
   Confirm the counterpart Agent’s Identity, Role, Capability, and available Services.
2. Verify
   Verify Identity, Authority, Policy compliance, and required credentials.
3. Negotiate
   Agree on Purpose, Scope, information-disclosure boundaries, constraints, expiration, and responsibility.
4. Delegate
   Delegate the Task based on the Delegation Contract.
5. Observe
   Monitor execution status, Policy violations, exceptions, and risks.
6. Trace
   Record the Evidence, Decisions, Actions, and Outcomes that should be shared.
7. Evaluate
   Evaluate differences between expectations and outcomes, Compliance, and Recovery.
8. Renew or Revoke
   Continue, narrow, renew, update, or terminate Trust.

The purpose of a Trust Protocol is not to over-constrain AI Agents. It is to enable the safe use of necessary autonomy even across organizational boundaries.

Conclusion

Cross-organizational AI Coordination is not about allowing AI to move freely between companies’ data.

It is about creating a state in which different organizations can coordinate within the necessary scope while preserving their own purposes, Policies, confidentiality, and responsibilities.

This requires giving inter-company Agents clear Roles and Capabilities; defining the boundaries of Cross-Organization Delegation; verifying counterparts and Authorities through Federated Identity; and controlling information disclosure according to the principle of minimum necessary access.

It also requires making decisions traceable through a cross-organizational Decision Trace—so that it is possible to identify who made which decision, based on what evidence—and continuously validating coordination itself through a Trust Protocol.

What inter-company collaboration needs in the AI era is not mere connectivity.

It is Infrastructure that enables different organizations to coordinate with trust while preserving their differences.

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance