Every enterprise deploying multi-agent AI has the same architectural blind spot: oversight tiers assigned to an orchestrating agent do not propagate to the sub-agents it instructs. The result is an accountability void that grows with every delegation hop.
Most enterprises today govern AI agents by assigning an oversight tier to the agent as a unit. A customer support agent is classified as Tier 2 Notify. A procurement automation agent is classified as Tier 3 Confirm. The Autonomy Calibration Index maps each agent class to a tier based on the Action Consequence Class of the actions it performs.
This model works for single-agent deployments. It breaks immediately when agents instruct other agents.
In a multi-agent system, Agent A (the orchestrator) delegates specific actions to Agent B (the sub-agent). Agent B may delegate further to Agent C. Each delegation hop introduces a question that current governance frameworks cannot answer: what oversight tier applies to Agent B when it executes an action on behalf of Agent A? If Agent A is operating at Tier 3 Confirm, does Agent B inherit that constraint? If not, who is responsible when Agent B executes a Tier 4-class action at Tier 1 speed?
The answer enterprises currently give, implicitly, is that Agent B's tier is whatever it was assigned at deployment. This is wrong. And it creates a gap that scales with deployment complexity.
Oversight tier assignments are made per agent at deployment time. Delegation is a runtime event. No current governance framework, including NIST AI RMF and ISO/IEC 42001, specifies how oversight requirements transfer across agent boundaries at runtime. This is the gap.
For a set of agent actions A delegated by orchestrating agent O to sub-agent S, the Trust Inheritance Gap is the subset TIG ⊆ A where S's deployed oversight tier T_deployed(a) is less restrictive than the effective tier T_eff(a) required by the Trust Propagation Rule. Formally:
TIG = {a ∈ A : T_deployed(a) < T_eff(a)}
where T_eff(a) = max(T_O, T_ACC(a)) and max() takes the more restrictive tier (Tier 4 > Tier 3 > Tier 2 > Tier 1). TIG = {} means the chain is fully governed. TIG ≠ {} means there is an accountability void for those actions at that delegation hop. The term originates with this work.
For an organization with incident response window W_IR (the time within which a human principal must identify a fault and invoke override before downstream effects become uncompensable), the Delegation Depth Ceiling is the maximum delegation depth D at which a responsible human principal can trace the full agent chain A_1 → A_2 → ... → A_D and invoke override within W_IR.
DDC is the largest D such that for all agent chains of depth D, the responsible human principal can identify the chain origin, the delegating agent, and the executing sub-agent within W_IR. For depth D > DDC, accountability is structurally broken regardless of audit log completeness: logs may record the chain, but no human can act on them within the window that matters. The term originates with this work.
The Trust Inheritance Gap exists because enterprises have no rule for how oversight tiers should propagate. This post proposes one.
Non-Upgrade Principle: no delegation may reduce the oversight requirement for an action. If Agent A operates at Tier 3 Confirm and delegates action a to Agent B, Agent B's effective tier for action a is the more restrictive of: (1) Agent A's assigned tier, and (2) the ACC-derived default tier for action a.
Formally, the Trust Propagation Rule (TPR) states: T_eff(a) = max(T_O, T_ACC(a)), where T_O is the orchestrator's assigned tier, T_ACC(a) is the Action Consequence Class default tier for action a, and max() selects the more restrictive.
This rule has two important properties. First, it is monotonic: adding delegation hops can only increase or maintain the effective oversight tier, never decrease it. Second, it is locally computable: each sub-agent can determine its effective tier from its own ACC classification and the tier of the agent that instructed it, without needing to know the full chain above.
The DDC is not a fixed number. It depends on three organizational variables: the incident response window W_IR (how quickly a human team can identify a fault and invoke override), the chain observability (whether the audit log makes the delegation chain queryable in real time), and the agent population size (how many concurrent chains are active).
For most enterprise deployments, W_IR is measured in minutes for customer-facing applications and hours for back-office automation. Chain observability is low in most current deployments: orchestration frameworks log actions, but few provide real-time chain tracing queryable by an on-call human. With these parameters, the DDC for most organizations is structurally D=1 for customer-facing and D=2 for back-office, meaning any chain longer than this operates outside tractable human oversight.
This has a direct consequence for EU AI Act Article 14 compliance. Article 14 requires that human oversight be effective, meaning a human can understand, monitor, and intervene in the system's operation. A delegation chain whose depth exceeds the DDC is not Article 14 compliant, regardless of whether each individual agent was assigned a compliant tier at deployment.
| Variable | What to assess | Governance implication |
|---|---|---|
| Action Consequence Class | Map each action the sub-agent can execute to its ACC cell (reversibility × blast radius) | T_ACC(a) sets the floor; the orchestrator's tier sets the ceiling; max() applies |
| Delegation Depth | Count hops from human principal to executing agent for each action class | Compare to your DDC. D > DDC requires either chain compression or human insertion at depth DDC |
| Override Window Compatibility | Time from sub-agent action to downstream effect propagation | If this window is shorter than W_IR at depth D, the action must be reclassified to Tier 3 or 4 regardless of ACI score |
| Chain Auditability | Can the full delegation chain be traced end-to-end within W_IR? | No auditability at depth D means DDC is effectively D-1 for that chain |
| Regulatory Classification | Does any action in the chain touch an EU AI Act Annex III high-risk category? | Article 14 compliance applies at every node, not just the orchestrator. Each sub-agent executing high-risk actions requires independent oversight assignment. |
Different multi-agent architectures concentrate the TIG risk in different places. The architecture pattern determines where in the chain the gap is most likely to appear and how large it tends to be.
A logistics operator deployed an orchestrating agent for route optimization and procurement. The orchestrator was assigned Tier 3 Confirm for all procurement actions. It delegated vendor communication and small purchase order creation to a sub-agent, which had been independently assigned Tier 1 Autonomous at deployment (appropriate for its original use case: status notifications).
The sub-agent executed a $1.4M purchase order on behalf of the orchestrator without any confirmation step. The action was Permanent × Enterprise-wide in ACC terms, requiring Tier 4. The sub-agent's deployed tier was Tier 1. TIG = {purchase order above $500K}. The orchestrator's Tier 3 assignment was irrelevant because the TPR had not been implemented.
Resolution: Tier propagation enforced at delegation time. Any sub-agent invoked by the Tier 3 orchestrator inherits a minimum effective tier of Tier 3 for all actions. For Permanent × Enterprise-wide ACC actions, the effective tier is Tier 4 regardless. Incident could not have occurred had TPR been in place.
A financial services CISO authorized a threat detection orchestrator at Tier 2 Notify. The orchestrator delegated threat classification to a second agent, which in turn delegated remediation action selection to a third. The third agent, operating at D=2, executed a firewall rule change blocking external access to an API serving 280,000 customer-facing transactions.
The action was Permanent × Enterprise-wide: Tier 4 by ACC default. The third agent's deployed tier was Tier 1. The CISO's incident response team could not identify the chain origin within the W_IR window. DDC was exceeded at D=2 for this deployment.
Resolution: DDC computed as D=1 given the W_IR of 8 minutes for customer-facing API infrastructure. Chains longer than D=1 for Permanent × Enterprise-wide actions are prohibited; human insertion required at D=1. Orchestrator restructured to a hub-and-spoke pattern with the CISO's team as the hub for any remediation action class.
A healthcare network deployed a scheduling orchestrator to manage appointment availability across 14 facilities. The orchestrator operated at Tier 3 Confirm for patient-facing actions. It delegated appointment modification to a sub-agent that had been assigned Tier 2 Notify for internal calendar adjustments (a different use case from its original deployment).
The sub-agent sent appointment cancellation notices to 3,200 patients without the confirmation step required by the orchestrator's tier. Under EU AI Act Annex III, patient scheduling falls within the high-risk AI category for essential services. Article 14 requires effective human oversight at every node. TIG = {appointment cancellation affecting patient access}.
Resolution: ACC analysis performed for all patient-facing sub-agent actions. Appointment cancellation reclassified as Compensable × Enterprise-wide: Tier 4 by default. TPR applied: sub-agent inherits min(T_O, T_ACC) = Tier 4. Article 14 compliance verified at sub-agent level independently of orchestrator. Cancellation workflow redesigned to require explicit human confirmation before execution.
| Component | Build / Buy / Configure | Rationale |
|---|---|---|
| ACC classification at sub-agent level | Build | Existing orchestration frameworks (LangGraph, CrewAI, AutoGen) do not classify individual action types by ACC cell. This mapping must be authored and maintained by the implementing team. |
| TPR enforcement layer | Build (configure from orchestration framework hooks) | The TPR can be implemented as a pre-execution hook that receives the delegating agent's tier and the action's ACC classification and returns the effective tier. Most frameworks support hook injection; the logic itself must be built. |
| Delegation chain audit log | Configure (extend existing observability stack) | If LLM observability tooling is already in place (LangSmith, Arize, Helicone), chain depth and delegation origin can be logged with minimal custom work. Without existing tooling, a structured logging layer must be built. |
| DDC calculator | Build | DDC requires organization-specific inputs: W_IR by action class, chain observability score, and agent population size. No vendor tool computes this. A lightweight internal tool suffices; a spreadsheet is sufficient for an initial DDC baseline. |
| Human insertion at DDC boundary | Configure (from existing approval workflow) | For actions at depth D=DDC, the approval step can typically be routed through an existing ticketing or approval system (ServiceNow, Jira, Slack approval workflows) rather than requiring a new tool. |
Inventory all deployed multi-agent systems. For each system, document: (1) the orchestrator's assigned tier, (2) all sub-agent action classes, (3) the ACC cell for each sub-agent action, (4) the current deployed tier for each sub-agent, and (5) the delegation depth for each action.
Compute TIG for each system. A non-empty TIG is a governance gap requiring remediation before Phase 2.
Gate: TIG documented and prioritized by severity (Permanent/Enterprise-wide gaps are P1).
Implement the TPR as a pre-execution hook across all orchestration frameworks in use. Enforce effective tier at each delegation boundary. For systems where TIG cannot be closed by TPR alone (the sub-agent's architecture prevents tier enforcement), insert a human approval step at the action level.
Compute DDC for each system using W_IR inputs from incident response playbooks. Flag systems where active chains exceed DDC.
Gate: TIG = {} for all P1 gaps. DDC computed and documented for all production chains.
Enable real-time chain depth monitoring as part of the observability stack. Alert when a chain exceeds DDC at runtime. Establish a quarterly review cadence to re-verify TIG = {} as new sub-agents are added or action classes change.
Document EU AI Act Article 14 compliance at the sub-agent level for all Annex III use cases. Include sub-agent tier assignment in AI system documentation under Article 11.
Gate: Zero active chains exceeding DDC. Article 14 compliance documented at sub-agent granularity.
Multi-agent incidents are structurally harder to contain than single-agent incidents. When a sub-agent at D=2 executes a Permanent action, the orchestrator's audit trail records a delegation event, not the consequential action. Remediation requires tracing across multiple systems. Incident cost scales with D.
EU AI Act Article 14 applies at every node executing high-risk actions, not only at the orchestrator level. A sub-agent executing Annex III-class actions without an Article 14-compliant oversight tier is a provider or deployer violation. Penalties reach 3% of global annual turnover under Article 99.
When a delegated action causes harm, the absence of TPR creates genuine legal ambiguity: is the responsible party the team that deployed the orchestrator, or the team that deployed the sub-agent? This ambiguity does not reduce liability: it distributes it, making resolution slower and more expensive.
Each new sub-agent added to an ungoverned chain multiplies the action surface without multiplying the oversight coverage. TIG grows combinatorially with agent population size. Remediation cost grows faster than deployment cost for each deferred governance cycle.
Related: Agent Autonomy Calibration (ACC + ACI) · AI Agent Incident Response · Multi-Agent Governance Topology