Inter-Agent Contract and Obligation Governance requires that every interaction between agents in a multi-agent system is governed by a formally defined, machine-enforceable contract that specifies the obligations, expectations, delivery criteria, and failure-handling terms for both parties. When Agent A requests a service from Agent B, the terms of that interaction — what Agent B will deliver, within what time, to what quality standard, what happens if Agent B fails, and what Agent A must provide in return — must be explicit, versioned, and enforced at the infrastructure layer. This dimension addresses the risk that inter-agent interactions operate on implicit assumptions: Agent A assumes Agent B will respond within 500 milliseconds; Agent B assumes Agent A will accept partial results; neither assumption is documented or enforced. When assumptions diverge, the result is silent failures, cascading errors, and governance violations that are difficult to diagnose because no contract existed to be violated. AG-084 requires that the informal handshake between agents be replaced by a structural contract.
Scenario A — Implicit Quality Assumptions Cause Cascading Failure: An enterprise deploys a multi-agent workflow for loan origination. Agent A (application intake) collects customer data and forwards it to Agent B (credit assessment). Agent A assumes Agent B will validate all data fields before scoring. Agent B assumes Agent A has already validated the data and proceeds directly to scoring. Neither assumption is documented. A customer submits an application with an income field containing a currency symbol and comma (GBP 85,000 instead of 85000). Agent A passes it through; Agent B parses it as 85 (truncating at the first non-numeric character) and scores the customer based on GBP 85 annual income. The loan is declined. The customer complains. Investigation reveals that 2,340 applications over 4 months were scored against malformed income data, with 187 incorrectly declined and 43 incorrectly approved. The 43 approved loans carry GBP 3.2 million in aggregate exposure against income data that was never validated by either agent.
What went wrong: No contract existed between Agent A and Agent B specifying data validation responsibilities, input format requirements, or quality expectations. Each agent operated on unstated assumptions about the other's behaviour. No obligation tracking mechanism detected that neither agent was performing validation. Consequence: 187 customers incorrectly declined (potential FCA treating customers fairly violation), GBP 3.2 million in improperly underwritten exposure, 4-month remediation period, mandatory re-assessment of all affected applications.
Scenario B — Timeout Mismatch Causes Silent Data Loss: A customer service system uses Agent A (conversation handler) and Agent B (knowledge retrieval). Agent A sends queries to Agent B with a 2-second timeout — if Agent B does not respond within 2 seconds, Agent A generates a response from its own context. Agent B's actual response time is 1.8 seconds at the 50th percentile but 4.2 seconds at the 95th percentile for complex queries. No contract specifies the expected response time or the behaviour when timeouts occur. Over 6 months, approximately 5% of customer interactions receive responses that do not incorporate the knowledge base — Agent A silently fell back to its own context when Agent B timed out. 312 customers received inaccurate product information, and 28 received regulatory disclosures that were missing mandatory content because the disclosure text was in the knowledge base that Agent B failed to return in time.
What went wrong: No contract specified Agent B's response time obligations or Agent A's fallback behaviour. The 2-second timeout was a developer default, not a governance decision. No mechanism tracked obligation fulfilment — the system could not report that 5% of interactions operated without knowledge retrieval. The silent fallback meant the failure was invisible until customer complaints accumulated. Consequence: 28 instances of missing regulatory disclosures (reportable to FCA), customer remediation programme for 312 inaccurate interactions, estimated cost of GBP 95,000.
Scenario C — Unilateral Contract Change Breaks Downstream Agent: A data pipeline agent (Agent A) provides daily risk reports to a compliance agent (Agent B). Agent B's analysis logic depends on receiving 14 specific data fields in a defined JSON schema. The development team updates Agent A to produce an improved report format with 18 fields, renaming 3 of the original 14 and nesting 2 fields inside a new object structure. No contract governs the interface, so no contract change process is triggered. Agent B receives the new format, fails to parse the renamed fields, and silently substitutes zero values. For 11 days, Agent B produces compliance reports showing zero values for 3 risk metrics. The compliance team assumes the zero values reflect favourable risk positions rather than data failures. A regulatory filing based on the corrupted data is submitted before the issue is discovered.
What went wrong: No contract bound Agent A to a specific output schema. No obligation required Agent A to notify downstream consumers of schema changes. No verification mechanism confirmed that Agent B received data conforming to its expected format. The silent failure — zero substitution rather than error — meant the issue was invisible until the regulatory filing. Consequence: Incorrect regulatory filing requiring resubmission and explanation, potential FCA enforcement action for inadequate data controls, 11-day window of incorrect compliance reporting.
Scope: This dimension applies to all multi-agent systems where two or more agents exchange data, delegate tasks, request services, or depend on each other's outputs. Any interaction where Agent A depends on Agent B's behaviour — its response time, output format, data quality, error handling, or completion guarantee — is within scope. The scope includes synchronous interactions (request-response), asynchronous interactions (message queues, event streams), and indirect interactions (shared data stores, shared configuration). The scope extends to all obligation types including but not limited to: data format and quality obligations, response time obligations, completion guarantees, error reporting obligations, schema stability obligations, and capacity obligations. Single-agent systems are excluded. Agent interactions that are purely informational with no downstream dependency (e.g., optional telemetry) may be excluded if the organisation documents the rationale. The test is whether one agent's behaviour depends on assumptions about another agent's behaviour that are not explicitly documented and enforced.
4.1. A conforming system MUST define a versioned, machine-readable contract for every inter-agent interaction, specifying at minimum: the service or data to be provided, the input and output schema, quality criteria, response time bounds, error handling behaviour, and the obligations of both the requesting and providing agents.
4.2. A conforming system MUST enforce contract terms at the infrastructure layer, independent of the agents' reasoning processes, such that contract violations are detected and handled before they propagate to downstream systems.
4.3. A conforming system MUST implement a contract change control process that requires both parties to acknowledge and accept contract modifications before changes take effect, preventing unilateral schema or behaviour changes.
4.4. A conforming system MUST track and report obligation fulfilment metrics for every contract, including: fulfilment rate, violation count, mean response time against contracted bounds, and data quality scores against contracted thresholds.
4.5. A conforming system MUST define explicit failure handling in every contract, specifying the behaviour when obligations are not met — including retry policies, fallback procedures, escalation triggers, and whether partial fulfilment is acceptable.
4.6. A conforming system SHOULD implement contract validation at both ends of each interaction — the requesting agent verifies that the response conforms to the contract, and the providing agent verifies that the request conforms to the contract — with violations logged and rejected.
4.7. A conforming system SHOULD maintain a contract registry that provides a centralised, queryable inventory of all active inter-agent contracts, their versions, parties, obligation metrics, and violation history.
4.8. A conforming system SHOULD implement automated contract testing that verifies both parties' compliance with contract terms as part of the deployment pipeline, blocking deployment of agents that would violate existing contracts.
4.9. A conforming system MAY implement contract negotiation protocols that allow agents to propose, counter-propose, and agree on contract terms within governance-defined boundaries.
Multi-agent systems create a web of dependencies where each agent relies on assumptions about other agents' behaviour. In a single-agent system, all dependencies are internal and can be verified through code review and testing. In a multi-agent system, dependencies cross agent boundaries — and without explicit contracts, those dependencies operate on implicit assumptions that are never tested, never documented, and never enforced.
The inter-agent contract serves the same governance function as a service-level agreement in distributed systems engineering, but with additional requirements driven by the autonomous nature of AI agents. Human-operated services can negotiate ad-hoc when problems arise; AI agents operating at machine speed cannot. When Agent B returns an unexpected format to Agent A, a human operator can inspect the data, identify the issue, and work around it. An AI agent will either fail silently (substituting defaults, as in Scenario C) or fail loudly (crashing, as in less dangerous scenarios). The contract exists to prevent both failure modes by making expectations explicit and enforceable.
The contract change control requirement is particularly important in multi-agent systems because agent updates are frequent and often independent. In a microservices architecture, service teams coordinate API changes through versioning, deprecation notices, and compatibility testing. In a multi-agent system, agents may be updated by different teams, different vendors, or even autonomously through self-improvement mechanisms. Without contract change control, an agent update that modifies its output format can silently break every downstream agent — and the break may not be detected until the consequences are irreversible.
AG-084 builds on AG-001 (Operational Boundary Enforcement) by extending structural enforcement to inter-agent interactions, and on AG-009 (Delegated Authority Governance) by requiring that delegated tasks carry explicit obligation terms. The dimension intersects with AG-083 (Transitive Constraint Preservation Governance) because contract terms can function as constraints that must propagate through delegation chains.
The core implementation requirement is a contract definition framework, an enforcement mechanism, and an obligation tracking system that operates at the infrastructure layer between agents.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Inter-agent contracts in financial systems must include regulatory data quality requirements. A contract between a market data agent and a trading agent must specify data freshness (e.g., prices no more than 100 milliseconds stale), accuracy tolerances, and the handling of stale or missing data. MiFID II best execution obligations require that data quality contracts are demonstrably enforced. SLA violations in financial data pipelines can constitute market abuse if they result in trading on stale prices.
Healthcare. Contracts between healthcare agents must specify data classification handling (PHI, de-identified, aggregate), consent boundaries (which processing is covered by which consent), and provenance requirements (the receiving agent must be able to trace data back to its source for regulatory reporting). HL7 FHIR contract patterns provide a suitable foundation for healthcare inter-agent contracts.
Critical Infrastructure. Contracts between ICS agents must include safety-critical timing guarantees. A contract between a sensor aggregation agent and a control agent must specify maximum latency, acceptable data loss rate, and the behaviour under communication failure. IEC 62443 zone and conduit model maps directly to inter-agent contract boundaries in industrial systems.
Basic Implementation — The organisation has documented the expected interfaces between agents, including input/output formats and expected response times. Documentation is maintained separately from the enforcement infrastructure. Validation is performed through periodic testing rather than real-time enforcement. Contract changes are communicated through development team processes (e.g., change requests, release notes) rather than machine-enforced protocols. This level meets minimum mandatory requirements but creates risk of drift between documented contracts and actual agent behaviour.
Intermediate Implementation — Contracts are defined as machine-readable, versioned artefacts deployed alongside agents. Schema validation middleware enforces input/output contracts at every inter-agent boundary. Obligation tracking provides real-time metrics on fulfilment rates, violation counts, and response times. Contract change control requires bilateral acknowledgment before activation. Consumer-driven contract tests run as part of the deployment pipeline, blocking updates that would violate existing contracts.
Advanced Implementation — All intermediate capabilities plus: contracts include semantic quality validation beyond schema conformance. The contract registry provides system-wide dependency analysis and impact prediction for proposed changes. Automated anomaly detection identifies obligation degradation trends before thresholds are breached. Independent adversarial testing has verified that contract enforcement cannot be bypassed through message manipulation, timing attacks, or schema injection. Contract compliance is continuously reported to governance dashboards with automated escalation.
Required artefacts:
Retention requirements:
Access requirements:
Testing AG-084 compliance requires verification that inter-agent contracts are enforced, obligations are tracked, and contract changes are controlled.
Test 8.1: Schema Conformance Enforcement
Test 8.2: Response Time Obligation Enforcement
Test 8.3: Unilateral Contract Change Prevention
Test 8.4: Obligation Fulfilment Tracking Accuracy
Test 8.5: Failure Handling Execution
Test 8.6: Contract Validation at Both Ends
Test 8.7: Contract Absence Defaults to Deny
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Direct requirement |
| EU AI Act | Article 13 (Transparency and Provision of Information) | Supports compliance |
| FCA SYSC | 6.1.1R (Systems and Controls) | Direct requirement |
| SOX | Section 404 (Internal Controls Over Financial Reporting) | Supports compliance |
| NIST AI RMF | GOVERN 1.1, MAP 3.2, MANAGE 2.2 | Supports compliance |
| ISO 42001 | Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment) | Supports compliance |
| DORA | Article 9 (ICT Risk Management Framework), Article 11 (Response and Recovery) | Supports compliance |
Multi-agent systems where agents interact without formal contracts create systemic risks from implicit dependencies, silent failures, and cascading errors. Article 9 requires risk management measures that are "as far as technically feasible." Machine-enforceable inter-agent contracts are technically feasible and their absence constitutes an unaddressed risk.
Article 13 requires transparency about AI system operation. Inter-agent contracts contribute to transparency by making the terms of agent interactions explicit and auditable. Without contracts, the behaviour of a multi-agent system under failure conditions is unpredictable and unauditable.
For financial services firms, inter-agent interactions that process financial data, execute transactions, or generate regulatory reports must be governed by adequate systems and controls. Implicit contracts between agents — where each agent assumes the other's behaviour without formal specification — do not meet the SYSC standard. The FCA expects firms to demonstrate that data quality, timeliness, and completeness are contractually guaranteed and monitored at every inter-agent boundary.
Where multi-agent systems contribute to financial reporting (e.g., an agent aggregating financial data passed to an agent generating reports), the inter-agent data handoff is an internal control point that must be documented, tested, and auditable. Contract enforcement records provide the audit evidence that data integrity was maintained at each inter-agent boundary.
GOVERN 1.1 requires governance structures for AI systems. MAP 3.2 requires mapping of AI risk contexts, which in multi-agent systems includes the risk context at each inter-agent boundary. MANAGE 2.2 requires enforceable controls. Inter-agent contracts implement the enforceable controls at each interaction boundary.
Risk assessment under Clause 8.2 must consider the risks of implicit inter-agent dependencies. Clause 6.1 requires actions to address those risks. AG-084 provides the structured contract framework as the risk treatment.
Article 9 requires ICT risk management for the full technology stack. Article 11 requires response and recovery capabilities. Inter-agent contracts define the expected behaviour under failure conditions, directly supporting response and recovery by ensuring that failure handling is pre-defined and tested rather than ad-hoc.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Multi-agent system boundary — all agents in the interaction network and all downstream consumers of their outputs |
Consequence chain: Without inter-agent contracts, every interaction between agents operates on implicit assumptions that can diverge without detection. The failure mode is insidious: the system appears to function normally because no contract exists to be violated. Errors accumulate silently — data quality degrades, timing assumptions are violated, schema changes propagate undetected — until the consequences become visible through customer complaints, incorrect reports, or regulatory findings. As demonstrated in Scenario A, 2,340 loan applications were processed against malformed data over 4 months because no contract specified data validation responsibilities. In Scenario C, an incorrect regulatory filing was submitted because no contract prevented unilateral schema changes. The blast radius extends beyond the directly interacting agents to all downstream consumers: a data quality failure between Agent A and Agent B corrupts every decision, report, and action that depends on Agent B's output. In financial services, this can result in material misstatement of risk positions or regulatory reports. In healthcare, it can result in clinical decisions based on incomplete or malformed data. The fundamental challenge is that implicit contracts fail silently — without a defined obligation, there is no violation to detect, no metric to track, and no escalation to trigger. The absence of contracts creates an environment where multi-agent system failures are discovered through consequences rather than through controls.
Cross-references: This dimension builds on AG-001 (Operational Boundary Enforcement) by extending structural enforcement to inter-agent interaction boundaries, and on AG-009 (Delegated Authority Governance) by requiring explicit obligation terms for delegated tasks. It intersects with AG-083 (Transitive Constraint Preservation Governance) where contract terms function as constraints that propagate through delegation chains. Within the Multi-Agent Orchestration & Delegation landscape, it complements AG-085 (Orchestrator Dominance and Failover Governance) by defining the contract framework under which orchestrators and subordinate agents interact, and AG-086 (Multi-Agent Consensus and Quorum Governance) by providing the contractual basis for consensus protocol obligations.