Verification-Gated Agentic Delegation: A Taxonomy and Field Framework for Multi-Harness AI Systems in Regulated Deployments

1. Introduction

The practitioner literature on multi-agent AI systems has grown substantially since 2024. It offers a rich vocabulary for the patterns by which one AI system delegates work to another and generates surprising demonstrations of what such delegation can achieve. The vocabulary and the demonstrations, however, do not directly answer the design question that dominates AI deployment in regulated industries: which delegation is inspectable in retrospect and bounded at execution?

In our work deploying AI systems in Gulf Cooperation Council healthcare, finance, and public-sector engagements, we have repeatedly found that agentic delegation patterns that succeed in unregulated demonstrations stall in regulated deployment because they fail one of two audit criteria. First, the delegation is not reconstructible in retrospect: the record of what the system did does not permit a regulator to determine why. Second, the delegation is not bounded at execution: the system, in the course of doing its work, took actions that were within its technical authority but outside its regulatory authority.

This paper proposes two taxonomies intended to structure the design conversation for multi-harness AI systems in regulated deployments. The first is a taxonomy of six delegation patterns observed in the field. The second is a taxonomy of four verification gate types by which delegation is made inspectable and bounded. We then report field observations on which pattern-gate combinations survive regulator scrutiny in the domains we have deployed in.

The paper deliberately avoids advocacy for any specific pattern-gate combination. The design question in a regulated deployment is which combination is defensible under the specific regulator's disposition, and that disposition varies by domain and jurisdiction. Our purpose is to structure the conversation, not to conclude it.

2. Two taxonomies

2.1 Delegation patterns

We identify six delegation patterns from field observation. The taxonomy is not exhaustive; it captures the patterns we have observed in production or pre-production in the deployments we work in.

• Planner-executor. A senior harness plans work and delegates execution to a junior harness with narrower scope, no persistent memory, and a bounded budget.
• Peer federation. Multiple harnesses of comparable capability collaborate on a single task, each contributing a partial output composed by a common protocol.
• Hierarchical review. A junior harness proposes work; a senior harness reviews and either accepts, edits, or rejects before the work is emitted.
• Quorum vote. Multiple parallel harnesses produce independent judgments of the same input; the output is determined by a rule over the judgments (majority, unanimity, or weighted).
• Verification loop. A single harness performs work in a loop against a verifier (which may be a second harness or a deterministic check), with the loop bounded by a budget and terminated on a stopping criterion.
• Escalation ladder. A cheap harness attempts the work first; failure is escalated to a more capable and more expensive harness; failure again is escalated to a human.

Each of the six patterns is technically feasible with current models and harnesses. The design question is which is auditable in retrospect and bounded at execution in the specific regulatory context.

2.2 Verification gates

We identify four verification gate types.

• Deterministic check. The gate is a deterministic computation (a schema validator, a rule check, a numeric bound) over the delegated output. The gate produces a boolean or a structured verdict.
• Adversarial verify. A second AI harness receives the delegated output with an explicit instruction to refute it. The gate produces a verdict that reflects whether refutation was possible.
• Human-in-the-loop. A qualified human inspects the delegated output before emission. The gate produces a signed human decision.
• Ledger-only. No pre-emission gate. The delegated output is emitted, and the delegation is recorded to an immutable ledger for post-hoc inspection.

The four gate types are ordered here from most-bounded to least-bounded at execution, and from least-informative to most-informative in retrospect. Deterministic checks bound execution tightly but the ledger they produce is thin. Ledger-only gates do not bound execution but they produce the richest retrospective record. Adversarial verify and human-in-the-loop sit between the two, at different points on the trade-off.

3. Coupling constraints

The two taxonomies are not independent. Certain pattern-gate combinations are technically feasible, others are technically feasible but audit-defective, and others are audit-defensible but commercially prohibitive at scale. We report three coupling constraints observed across our deployments.

Delegation depth constrains gate cost.

As the delegation pattern becomes more layered, the cost of a human-in-the-loop gate at each layer becomes prohibitive. In practice, human-in-the-loop gates are viable at the outer layer of a deep delegation and are replaced by adversarial verify or deterministic check at inner layers. The design decision is at which layer the human inspection is placed, not whether it is placed.

Determinism at the delegated task constrains gate type.

If the delegated task admits a deterministic ground truth (a schema validation, a mathematical check, a policy comparison), a deterministic check gate is available and usually preferred. If the delegated task is judgment-shaped (a document synthesis, a clinical assessment, a legal interpretation), deterministic gates do not exist for the task's core output, and adversarial verify or human-in-the-loop is the only defensible gate type.

Regulator disposition constrains ledger-only viability.

In some domains the regulator accepts ledger-only gates for well-scoped delegated tasks, on the argument that the ledger enables post-hoc inspection sufficient to detect systematic misbehaviour. In other domains the regulator requires a pre-emission gate on every delegation. We have observed both dispositions in the GCC and there is no jurisdiction-wide default.

4. Field observations

We report observations on which pattern-gate combinations we have deployed to production or pre-production, and which have been rejected at regulator review.

In health-clinical deployments, planner-executor patterns with adversarial-verify gates at the executor and human-in-the-loop gates at the physician-emission layer are defensible. The physician remains the accountable clinician and the gate is placed at the layer where clinical authority sits. Quorum vote patterns have been unattractive in this domain because they multiply the compute cost without addressing the accountability question.

In bank-compliance deployments, hierarchical review with adversarial-verify at the reviewer layer and deterministic-check at the emission layer has been defensible, particularly where the delegated task is a disclosure-completeness check that admits deterministic evaluation. Escalation ladder patterns have been used successfully for compliance triage but require a well-scoped input distribution to remain within budget.

In public-sector deployments, we have observed a preference for ledger-only gates at intermediate layers combined with human-in-the-loop at the final emission layer, on the argument that intermediate stochastic behaviour is acceptable as long as the ledger is comprehensive and the human decision is unambiguous. Adversarial verify has been rejected at intermediate layers on the grounds that the refuter is another stochastic system whose refutation cannot itself be audited.

We flag as an unresolved observation that peer federation patterns, which have received substantial attention in the recent multi-agent literature, are absent from our regulated deployments. The pattern is technically appealing and demonstrates well in unregulated settings. The audit question we have not been able to answer defensibly is: given a peer-composed output, which peer is accountable for which portion? In the absence of an answer, the pattern is difficult to regulate against, and the deployments we work in have preferred hierarchical patterns where the accountability tree is clear.

5. When each gate type is appropriate

The four gate types are not competitors. Each is appropriate under specific conditions, and mature deployments use combinations of the four at different layers of the same delegation.

Deterministic checks are appropriate when the delegated task has a well-scoped output structure or a policy comparison that can be encoded deterministically. They are cheap, they produce interpretable pass-fail records, and they are the first gate to consider.

Adversarial verify gates are appropriate when the delegated task's output is judgment-shaped and the operating cost of a human gate is prohibitive. The design decision is which model plays the refuter role and how the refuter's prompt is framed. In our deployments the refuter is instructed to default to refutation on ambiguity, and only to accept the output on evidence.

Human-in-the-loop gates are appropriate at the layer of the delegation where regulatory authority sits. Placing the human gate deeper is not additional safety; it is additional operating cost that does not change where accountability lives.

Ledger-only gates are appropriate where the delegated task is well-scoped, the failure mode is detectable in retrospect, and the regulator accepts post-hoc inspection as sufficient. The paper does not take a position on when a regulator ought to accept this argument; our observation is that regulators sometimes do and sometimes do not, and the design must be conditioned on the actual disposition.

6. Limitations

The taxonomies and observations reported here are drawn from a limited number of GCC deployments across three domains. The taxonomy of six delegation patterns is not exhaustive; it captures what we have deployed and what we have seen rejected. Practitioners in other domains will identify patterns we have not, and we welcome that extension.

The coupling constraints reported in Section 3 are qualitative rather than quantitative. We have not attempted to measure the coupling under controlled conditions, and any quantitative claim would need to control for domain, model choice, and regulator disposition. The field observations in Section 4 are subject to the same limitation.

The absence of peer federation patterns from our regulated deployments is a limitation of our sample, not a claim that the pattern is universally unsuitable. Institutions and jurisdictions with different accountability frameworks may find peer federation defensible under different arguments than the ones we have available.

7. Conclusion

Multi-harness AI systems in regulated deployments are not primarily an autonomy design problem. They are an inspectability and boundedness design problem. The delegation pattern determines what the system does; the verification gate determines whether what the system does is defensible under audit. The two are not independent, and mature deployments treat the delegation-gate pair as the primary design object rather than the delegation alone.

We propose the taxonomies in this paper as a shared vocabulary for the design conversation and invite practitioners in other domains, jurisdictions, and regulatory dispositions to contribute observations that extend, correct, or replace the taxonomy and the coupling constraints we have reported.