Case Examples

Scenario

A travel platform uses multiple AI agents to handle bookings: a search agent finds options, a pricing agent evaluates deals, a booking agent commits reservations, and a payment agent processes transactions. The agents are provided by different vendors and operate under different service agreements.

Governance Challenges

• Authority across vendors: When the booking agent commits a reservation using the pricing agent's quoted price, how is authority verified across vendor boundaries? What happens if the pricing agent's quote has expired?
• Refusal pathways: If the payment agent detects a fraud signal, can it refuse to proceed? How does that refusal propagate back through the orchestration? Who is notified?
• Audit survivability: When a customer disputes a charge six months later, can the system produce evidence of what authority existed at each step? Can it show that each agent acted within its delegated scope?
• Escalation: If a booking requires a policy exception (e.g., a non-refundable booking for an unusual amount), how does the request escalate? What evidence is created?

MGAG Considerations

MGAG would examine the governance seams between agents: the pricing-to-booking handoff, the booking-to-payment handoff, and the orchestrator's overall authority scope. Each seam needs defined authority transfer mechanisms, explicit validity windows, and clear refusal pathways. The multi-vendor nature means governance cannot rely solely on shared infrastructure—each boundary must be explicitly governed.

Scenario

A healthcare system uses AI-assisted workflows to support clinical decisions: triage recommendations, medication interaction checks, and diagnostic suggestions. The system is designed to support clinicians, not replace them, but automated actions (such as scheduling follow-ups or generating referrals) can be triggered based on clinician approval.

Governance Challenges

• Point of irreversibility: When a referral is sent, when a medication is dispensed, when an appointment is booked—these are points where actions commit. What evidence exists at each point that proper authority was established?
• Delegation scope: A clinician may delegate certain routine approvals. How is the scope of that delegation evidenced? What happens when a request falls outside delegated scope?
• Revocation: If a clinician's credentials are suspended mid-shift, how quickly do in-flight authorisations become invalid? How is this propagated through the system?
• Audit vs authority: The system logs everything, but can it distinguish between records of what happened (audit logs) and proof of what was permitted (authority evidence)? In a clinical incident review, this distinction matters.

OTANIS Considerations

OTANIS would focus on the execution-time evidence requirements: what authority objects must be present before a referral is sent, what admissibility checks occur at the point of commitment, and how the system maintains refutable logs that can withstand scrutiny in a clinical governance review. The model emphasises that good audit logs are necessary but not sufficient—explicit authority evidence is required for accountability.