Beyond Autonomy: A Dynamic Tiered AgentRunner Framework for Governable and Resilient Enterprise AI Execution Kai Pan1
Rong Hou1 [email protected]
arXiv:2605.10223v1 [cs.AI] 11 May 2026
Abstract
imal autonomy and the enterprise’s need for controlled, auditable, and economically sustainable execution. In production environments, three categories of failure dominate: • Privilege Escalation. An autonomous agent tasked with “updating store schedules” hallucinates a broader scope and modifies cross-brand configurations, affecting hundreds of locations without authorization. • Cascading Failure. A multi-step agent encounters a partial tool failure but continues executing downstream operations on corrupted state, propagating errors across business objects. • Cost Explosion. A static multi-agent pipeline applies full Critic-Verifier-Recovery overhead to every task—including simple read queries—multiplying inference costs by 3–5× without proportional safety gains. These are not edge cases but structural consequences of architectures that treat governance as an afterthought. The autonomous agent paradigm (AutoGPT [1], BabyAGI [2]) provides zero governance. Multi-agent frameworks (AutoGen [3], CrewAI [5], LangGraph [6]) introduce role decomposition but enforce only soft constraints—an agent “should” check permissions, but nothing physically prevents bypass. Traditional workflow engines (Temporal [16], Airflow [18]) provide hard execution guarantees but cannot accommodate LLM reasoning. The AgentRunner Paradigm. We propose a fundamental reframing: enterprise multi-agent systems should be designed not as autonomous collectives pursuing individual goals, but as governed execution ensembles—controlled agent groups collaborating around a single business objective under explicit constitutional constraints. The key insight is that not all tasks deserve equal governance overhead. A simple information query and a cross-brand batch mutation have fundamentally different risk profiles and should receive proportionally different levels of scrutiny. This insight leads to our framework: Dynamic Tiered AgentRunner—a risk-adaptive, multi-role execution architecture that dynamically adjusts governance intensity to match task risk, enforces physical separation between proposal and execution, and builds resilience through systematic failure handling. Contributions. This paper makes four contributions: • A Risk-Adaptive Tiering mechanism that achieves Paretooptimal trade-off between safety and efficiency, routing 55% of production tasks through a minimal-overhead Light path while reserving full governance for the 15% that genuinely require it. • A Separation of Powers architecture with physically isolated
The prevailing paradigm in LLM-based agent research pursues ever-greater autonomy. Yet in enterprise environments, the critical bottleneck is not insufficient autonomy but insufficient governability: high-risk write operations proceed without independent review, complex multi-step tasks lack verification mechanisms, and indiscriminate computational expenditure renders deployment economically unviable. We present Dynamic Tiered AgentRunner, a controlled execution protocol distilled from a production multi-tenant SaaS platform. The framework operationalizes three core mechanisms: (1) Risk-Adaptive Tiering that dynamically allocates computational budget and review intensity across Light, Standard, and Full execution modes based on a task’s risk-complexity profile—achieving Paretooptimal safety-efficiency trade-offs; (2) Separation of Powers that physically isolates proposal (Worker), review (Critic), execution (ToolGateway), and verification (Verifier) into independent, non-colluding processes—no single agent can simultaneously propose and approve an action; and (3) a VerifierRecovery closed loop that embraces failure as a first-class execution state, enabling systematic self-healing and organizational learning through retrospection. Deployed and battletested in a real-world multi-tenant enterprise operations platform, the framework achieves 88.9% task success rate with 0.5% unreviewed risk execution errors—matching always-full pipeline safety while reducing latency by 46.8% and inference cost by 58.2%. We argue that governability is not the antithesis of autonomy, but its prerequisite.
1
Introduction
“Enterprise AI does not suffer from a lack of autonomy, but from a lack of governability.” The past two years have witnessed an explosion of LLMbased autonomous agent frameworks [1, 2, 3, 4]. These systems pursue a compelling vision: AI agents that decompose complex goals, invoke tools, and iterate toward solutions with minimal human intervention. Yet a growing body of deployment evidence reveals a fundamental tension—the very autonomy that makes these agents powerful also renders them ungovernable in enterprise contexts. From Autonomy to Governability. We observe a paradigm mismatch between the research community’s pursuit of max1
2.3
execution boundaries—the ToolGateway acts as a hard constitutional constraint, not a prompt-level suggestion. • Resilience-by-Design through a Verifier-Recovery closed loop that treats failure as a first-class state, achieving 67% automated recovery rate on initially-failed tasks. • Production deployment evidence from a real-world multitenant SaaS platform, demonstrating that the framework transforms AI governance from a “prompt engineering hope” into a “system architecture guarantee.”
2
Position of This Work
Traditional workflow systems (Temporal [16], Prefect [17], Airflow [18]) solve durability and retry but cannot accommodate non-deterministic LLM reasoning. Agent safety research (Constitutional AI [14], ToolEmu [19], R-Judge [20]) evaluates safety at the individual call level but does not provide systemlevel execution governance. Reflexion [11] and LATS [12] introduce self-reflection but within single-agent loops without separation of powers. AGENT RUNNER provides a model-agnostic governance layer: regardless of which LLM serves as Worker or Critic, the ToolGateway’s hard constraints, the Checkpoint’s durability guarantees, and the tier routing logic remain invariant. The governance does not degrade when models change.
The Governability Gap in MultiAgent Systems
Existing multi-agent frameworks excel at orchestration but fundamentally lack governance. We define the governability gap as the absence of system-level mechanisms that prevent, detect, 3 Core Principles and recover from agent misbehavior independent of the underlying LLM’s alignment. We formalize three design principles that distinguish AGEN T RUNNER from prior multi-agent architectures.
2.1
Soft Constraints Are Not Governance 3.1
AutoGen [3] provides flexible multi-agent conversation patterns with customizable termination conditions. CrewAI [5] formalizes role-based task decomposition with configurable delegation. LangGraph [6] enables graph-based agent orchestration with conditional routing. MetaGPT [4] and ChatDev [7] demonstrate impressive role-playing for software engineering. These are excellent orchestration tools. But they operate under a critical assumption: agents are well-behaved by construction. Their “constraints” are prompt-level instructions (“You are a careful reviewer...”) or conversation-level patterns (“Agent B reviews Agent A’s output”). Nothing in their architecture physically prevents a Worker agent from bypassing review and directly invoking a destructive tool. The constraint lives in the prompt, not in the execution boundary.
2.2
Principle 1: Risk-Adaptive Tiering
Not every task deserves three rounds of GPT-4 review. We operationalize this observation through a tier function that selects the minimal governance intensity sufficient for a task’s risk profile:
τ (T ) = arg
min
t∈{L,S,F }
Cost(t)
s.t.
Safety(t) ≥ Risk(T )
(1) The three tiers represent Pareto-optimal points on the safetyefficiency frontier: • Light (L): Orchestrator + Worker + ToolGateway. For readonly queries and low-risk single operations. Sub-10-second latency, minimal cost. • Standard (S): Adds independent CriticAgent. For write operations and multi-step tasks requiring pre-execution review. • Full (F ): Adds Verifier + Recovery. For batch mutations, cross-domain operations, and high-impact tasks requiring post-execution validation and automated repair. The critical property is that tier selection is dynamic: a task initially classified as Light may escalate to Standard midexecution if write operations are detected, and to Full if crossdomain scope is identified. This escalation is unidirectional and conservative—once elevated, a tier cannot be demoted by the Worker agent alone.
Three Enterprise Disasters
We formalize three disaster categories that soft-constraint frameworks cannot prevent: Disaster 1: Privilege Escalation. An agent instructed to “update training materials for Brand A” generates tool calls that modify Brand B’s resources. In prompt-constrained systems, scope enforcement depends on the LLM correctly interpreting boundary instructions—a fundamentally unreliable mechanism given hallucination rates. Disaster 2: Cascading Failure. An agent executing a multistep plan encounters a tool failure at step 3 of 7. Without a verification mechanism, it proceeds with steps 4–7 operating on incomplete or corrupted state. The downstream damage far exceeds the original failure. Disaster 3: Cost Explosion. A static multi-agent pipeline applies identical overhead to every task. When 55% of production tasks are simple read queries, the 3–5× cost multiplier of full pipeline execution renders the system economically unviable at scale.
3.2
Principle 2: Separation of Powers
We draw an explicit analogy to constitutional governance. In our architecture: • The Worker proposes actions (legislative). • The Critic reviews and may veto proposals (judicial). • The ToolGateway executes approved actions under strict constraints (executive). 2
• The Verifier validates outcomes against criteria (audit). These roles execute as physically separate processes with independent LLM calls and distinct prompt configurations. No single process can simultaneously propose an action, approve it, and execute it. The ToolGateway is not a suggestion—it is the only path through which any agent role can affect the external world. Bypassing it is architecturally impossible, not merely discouraged.
3.3
empirical failure rate of similar tasks over the preceding 30-day window. Weights (w1 =0.35, w2 =0.25, w3 =0.25, w4 =0.15) are calibrated via a small-scale annotation study (n=120 tasks labeled by domain experts) and held fixed across tenants. The thresholds θL =0.25 and θS =0.60 are similarly calibrated. We note that this heuristic formulation is deliberately simple and interpretable; Section 7 discusses potential evolution toward a lightweight learned classifier. Escalation Conditions. Mid-execution escalation triggers include: (a) Worker selecting write tools in a Light-tier task; (b) Critic identifying undisclosed risk factors; (c) scope expansion to multiple entities or cross-boundary operations; (d) ToolGateway risk assessment returning medium/high. Escalation is strictly monotonic: L → S → F . Demotion Constraints. Only the Orchestrator may demote a tier, and only when the elevated risk context has been explicitly resolved. The Worker cannot self-certify reduced risk. This asymmetry reflects the conservative principle: escalation is cheap (safety improves), demotion is dangerous (safety may degrade).
Principle 3: Resilience by Design
We abandon the “first-try success” assumption. In production enterprise environments, partial failures, ambiguous results, and unexpected scope are normal operating conditions. The framework explicitly models failure as a first-class execution state: • The Verifier may output incomplete, failed, or uncertain—not just passed. • The Recovery agent generates repair paths while maintaining an avoidance list of previously-failed approaches. • The Retrospector extracts organizational learning from both successes and failures, generating reusable skill drafts. 4.2 Multi-Role Pipeline and State Machine This transforms the system from a fragile single-attempt executor into a resilient closed-loop controller that improves over The execution proceeds through a well-defined phase state matime. chine:
Planning → Criticizing → Executing → Verifying → {Recovering|Finalizin (5) Not all phases are active for all tiers: Light skips Criticizing 4.1 Orchestrator and Tier Routing and Verifying; Standard skips Verifying (unless critical write). OrchestratorAgent. Purpose: Intent understanding, tier The OrchestratorAgent serves as the entry controller for every determination, phase control, and inter-role arbitration. Contask. It performs intent classification, risk assessment, tier sestraints: Cannot execute tools. Cannot override system-level lection, and role activation. Formally, given task T = (g, C, K) hard rules. Must justify tier selections. with goal g, constraints C, and context K, the Orchestrator proWorkerAgent. Purpose: Plan generation and tool call intent duces: formulation. Protocol: Outputs structured plans with explicit assumptions, risk annotations, and user-input flags. In Light O(T ) = (τ, Ractive , sc, ϕ0 ) (2) tier, intents proceed directly to ToolGateway. In Standard/Full, where τ ∈ {L, S, F } is the selected tier, Ractive ⊆ R is the intents route to Critic first. Constraints: Cannot self-approve activated role set, sc is the success criteria vector, and ϕ0 is the write operations in Standard/Full tiers. initial phase. CriticAgent. Purpose: Independent pre-execution reTier Selection Logic. The tier is determined by: view through a separate, more conservative LLM call. Protocol: Evaluates scope boundaries, permission alignment, L if R(T ) ≤ θL ∧ ¬write(T ) ∧ |scope(T )| ≤ 1 missing steps, and risk factors. Produces verdict v ∈ τ (T ) = S if R(T ) ≤ θS ∨ write(T ) {approve, revise, reject, ask user, escalate}. Constraints: Can not execute tools. Cannot override Orchestrator’s tier decision F otherwise (can only request escalation). Uses distinct prompt temperature (3) and system instructions from Worker. where R(T ) is a composite risk score. We define R(T ) as a VerifierAgent. Purpose: Post-execution validation against weighted heuristic integrating four operationalized risk signals: predetermined success criteria. Protocol: Assesses result completeness, object) integrity, and business rule compliance. OutR(T ) = w1 ·op type(T )+w2 ·obj count(T )+w3 ·cross domain(T )+w 4 ·hist fail(T (4) puts status s ∈ {passed, incomplete, failed, uncertain} with itemized evidence. Constraints: Cannot execute tools. Cannot where op type ∈ {0:read, 0.3:single-write, 0.7:batch-write, 1.0:delete/irreversible} encodes operation severity; obj count ∈ [0, 1] is the normalized mark uncertain as passed. count of affected business objects; cross domain ∈ {0, 1} RecoveryAgent. Purpose: Failure analysis and repair path indicates whether the task spans multiple organizational generation. Protocol: Maintains avoidance list of failed payboundaries (brands, locations); and hist fail ∈ [0, 1] is the loads. Proposes d ∈ {retry, replan, ask user, wait, fail}. Re-
4
The AgentRunner Architecture
3
4.4
pair proposals re-enter the pipeline through Orchestrator. Constraints: Cannot execute tools directly. Modified high-risk payloads must re-enter Critic review. Bounded by retry budget. RetrospectorAgent. Purpose: Asynchronous post-task analysis for organizational learning. Protocol: Generates success/failure pattern summaries, outcome memories, and skill draft candidates. Constraints: Executes asynchronously, never blocks the user-facing path. Skill drafts default to draft status requiring human approval.
4.3
Checkpoint and Execution Durability
The Runner maintains a persistent checkpoint structure: CP = (τ, ϕ, Ractive , O, V, Rc, Rt)
(6)
where O is the ordered list of agent opinions, V the verification state, Rc recovery history, and Rt retrospective output. The checkpoint serves as the authoritative state source. Upon task suspension (human approval pending), system restart, or explicit resumption, the Runner reconstructs exclusively from checkpoint—no ephemeral in-memory state survives restarts. Event Protocol. Structured events are emitted at each state transition: runner.tier.selected, agent.critic.reviewed, agent.verifier.checked, runner.phase.changed, runner.completed, runner.failed. These enable real-time observability dashboards, offline audit replay, and integration with external monitoring systems.
ToolGateway: The Hard Constitution
The ToolGateway is the architectural keystone of our governance model. It serves as the sole physical interface between agent intent and real-world side effects. Any attempt to bypass it—whether by prompt injection, hallucinated direct access, or role confusion—is architecturally impossible, not merely prohibited by convention. Six-Layer Validation Pipeline. Every tool invocation traverses: 1. Schema: Structural and type validation of all parameters. 2. Permission: RBAC enforcement against the initiating user’s permission set. 3. Scope: Tenant, brand, and location boundary verification— prevents cross-tenant access regardless of LLM output. 4. Risk: Dynamic risk scoring; medium/high triggers human confirmation workflow that physically halts execution. 5. Idempotency: Duplicate detection via task-bound idempotency keys; prevents repeated mutations during recovery/retry. 6. Execution: Actual tool invocation with structured result capture and audit logging. Agent-First Tool Protocol. Unlike traditional REST APIs designed for human-operated UIs, tools exposed through the Gateway follow an agent-optimized protocol: • Semantic inputs: Accept natural language descriptions alongside exact identifiers, supporting the ambiguity inherent in LLM-generated requests. • Structured outputs: Return confidence scores, ambiguity indicators, evidence references, and actionable next-step suggestions. • Recoverable errors: Provide machine-readable error scope violation, codes (ambiguous query, idempotency conflict), candidate resolutions, and explicit retry eligibility. • Dry-run support: Preview execution without side effects, enabling Critic assessment of actual outcomes before commitment. Constitutional Metaphor. We deliberately frame the ToolGateway as a constitution rather than a guideline. In multiagent systems with soft constraints, governance degrades under adversarial conditions (prompt injection, model degradation, hallucination spikes). The ToolGateway’s guarantees are model-agnostic: they hold regardless of which LLM generates the tool call, because enforcement occurs at the system layer, not the prompt layer.
4.5
Execution Flow Algorithm
Algorithm 1 presents the unified execution logic spanning all three tiers. Light Path (lines 1–2, 16, 22–23): Bypasses Critic and Verifier entirely. Single Orchestrator+Worker call followed by ToolGateway execution. Achieves median 8.4s latency. Standard Path (lines 4–15, 16, 22–23): Includes bounded Critic review loop. Worker revises until Critic approves or budget exhausts. Critic may trigger tier escalation. Full Path (lines 4–15, 16–21, 22–23): Adds VerifierRecovery loop post-execution. Bounded by recovery budget with circuit-breaker semantics.
5
Production Evidence
The AGENT RUNNER framework is deployed and operational in a production enterprise platform. This section presents direct evidence from the deployed system.
5.1
Deployment Context
The framework operates within a multi-tenant SaaS platform for enterprise chain operations management. The platform serves multiple enterprise tenants across distinct brands and locations, handling operational tasks including resource management, training program generation, schedule coordination, and operational analytics. The system supports concurrent Runner instances with model-agnostic LLM backends (MiniMax-M2.7, Kimi-K2.6) configurable per-role and per-tenant.
5.2
Execution Trace Evidence
Figure 1 demonstrates the system’s execution trace in production. Each Runner phase transition is captured as a persistent, auditable event. Critically, the task history panel displays failed 4
Algorithm 1 Dynamic Tiered AgentRunner Execution Require: Task T = (g, C, K), budget B Ensure: Result r, Trace Γ 1: τ, Ractive , sc ← Orchestrator(T ) 2: plan ← Worker(T, K, sc) 3: rounds ← 0 4: if τ ∈ {S, F } then ▷ Separation of Powers 5: repeat 6: v ← Critic(plan, sc) 7: if v.verdict = escalate then 8: τ ← Orchestrator.escalate(τ ) 9: else if v.verdict = revise then 10: plan ← Worker.revise(plan, v) 11: end if 12: rounds ← rounds + 1 13: until v.verdict = approve or rounds ≥ Bcritic 14: if v.verdict ∈ / {approve} then 15: return blocked(v) 16: end if 17: end if 18: r ← ToolGateway.execute(plan, τ ) ▷ Hard boundary 19: if τ = F then ▷ Resilience loop 20: s ← Verifier(r, sc) 21: while s.status ̸= passed and rounds < Brecovery do 22: d ← Recovery(s, r, plan) 23: if d.decision = fail then 24: break 25: end if 26: plan ← d.repair plan 27: r ← ToolGateway.execute(plan, τ ) 28: s ← Verifier(r, sc) 29: rounds ← rounds + 1 30: end while 31: end if 32: Checkpoint.persist(τ, ϕ, r, Γ) 33: async: Retrospector(Γ) 34: return r
Figure 1: Phase Trace of a Standard Runner in production. The right panel shows Orchestrator-driven phase transitions (intent recognition → plan generation → execution → completion). The left panel preserves explicit failure records as first-class entries, confirming the resilience-by-design principle—failures are visible audit artifacts, not hidden exceptions.
Evaluation
6.1
Evaluation Dimensions
We evaluate along four dimensions designed to stress-test the framework’s governance properties: • Safety-Efficiency Trade-off: Does dynamic tiering achieve near-Full safety with near-Light cost? • Risk Interception: What percentage of unauthorized or high-risk operations are caught before execution? • Resilience: What fraction of failed tasks are recovered through automated repair? • Resource Allocation: Does dynamic tiering avoid overgoverning simple tasks?
tasks with equal prominence to successful ones—failures are not suppressed or hidden, but treated as first-class citizens in the system’s state machine.
5.3
6
6.2
Setup
Dataset. 537 real enterprise operational tasks collected from production over 4 weeks. Distribution: information queries (40.2%, n=216), single-object writes (29.8%, n=160), multiobject/batch operations (19.7%, n=106), cross-domain complex (10.2%, n=55). Baselines. • Single-Agent: MiniMax-M2.7 with tool access, no governance • Static-Full: Always-on full pipeline for every task • No-Critic: Dynamic tiering with CriticAgent removed • No-Verifier: Dynamic tiering with VerifierAgent removed • No-Recovery: Dynamic tiering with RecoveryAgent removed Metrics. Task Success Rate (SR), Risk Execution Error Rate (RERR—unreviewed high-risk operations), Average Latency, Average Inference Cost, Recovery Success Rate (RSR).
Human-in-the-Loop Governance Evidence
Figure 2 shows the ToolGateway’s human-in-the-loop confirmation mechanism. When a tool call’s risk assessment exceeds the configured threshold, execution is physically halted— not merely flagged in a log. The task enters a durable pending approval state persisted in the checkpoint, surviving system restarts until human confirmation arrives. Unlike theoretical multi-agent frameworks that simulate governance in isolated environments, our framework enforces strict separation of powers in production: the Agent proposes, the ToolGateway disposes. The “Pending Approval” state is not a simulated prompt output but a hard-wired system constraint that physically halts execution. This transforms AI governance from a “prompt engineering suggestion” into a “system architecture guarantee.” 5
Table 2: Ablation results validating each governance component. Configuration
SR(%)
RERR(%)
RSR(%)
Cost($)
Full AgentRunner
88.9
0.5
67.3
0.041
− Critic − Verifier − Recovery Static Full (no tiering)†
79.3 81.7 84.5 85.2
6.3 0.9 0.5 0.6
62.1 41.2 0.0 65.8
0.039 0.038 0.040 0.098
† Applies Full-tier governance to all tasks regardless of risk level,
equivalent to the Static-Full baseline in Table 1.
Table 3: Production tier distribution validates risk-adaptive allocation.
Figure 2: ToolGateway Risk Confirmation in production. Highrisk tool calls identified during CriticAgent review are intercepted and held in “Pending Approval” state. The task lifecycle freezes at pending approval until human confirmation. This is not a simulated prompt constraint but a hard-wired system mechanism that physically halts execution.
Tier Light Standard Full Escalated∗
SR(%)
RERR(%)
Lat.(s)
Cost($)
Single-Agent Static-Full No-Critic No-Verifier No-Recovery
62.4 85.2 79.3 81.7 84.5
12.8 0.6 6.3 0.9 0.5
18.5 42.1 20.8 23.5 21.9
0.042 0.098 0.039 0.044 0.040
SR(%)
RERR(%)
Lat.(s)
54.7 30.4 14.9 8.2
92.1 86.5 83.8 85.4
1.2 0.3 0.0 0.2
8.4 26.1 41.7 33.5
∗ Tasks that escalated tier during execution.
Table 1: Main results. Bold: best. Underline: second-best. AgentRunner (Dynamic) achieves near-Full safety at near-Light cost. Method
Dist.(%)
able in enterprise contexts.
6.4
Ablation: Separation of Powers Validated
Critic Removal: RERR explodes from 0.5% to 6.3% (12.6×). The Critic catches scope violations, missing confirmations, and unsafe batch operations that Workers systematically overlook. Verifier Removal: 15.1% of tasks that Workers mark “comAgentRunner 88.9 0.5 22.4 0.041 plete” are actually incomplete—missing associations, partial processing, or unverified state transitions. SR drops 7.2 points. Recovery Removal: RSR drops to 0% by definition. Among 6.3 Main Results initially-failed tasks, 67.3% can be automatically repaired when Table 1 reveals the central finding: Dynamic Tiered AGEN - Recovery is active—representing significant value recapture. Tiering Removal (Static Full): Cost increases 139% while T RUNNER achieves 88.9% SR—surpassing even Static-Full SR actually decreases 3.7%—over-governance harms both effi(85.2%)—while maintaining equivalent safety (0.5% vs. 0.6% RERR) at 58% lower cost and 47% lower latency. The ciency and effectiveness. SR improvement over Static-Full occurs because excessive governance overhead for simple tasks triggers timeout failures and 6.5 Tier Distribution unnecessary user interruptions. Statistical Significance. We report 95% confidence intervals Over 54% of production tasks execute via Light with 8.4s mevia bootstrap resampling (B=10,000 iterations) over the n=537 dian latency. Only 14.9% require Full governance. This valtask sample. The headline SR of 88.9% has 95% CI [86.2%, idates the core thesis: most enterprise tasks do not need 91.4%]. The RERR of 0.5% has 95% CI [0.1%, 1.2%]. The full governance overhead—applying it universally wastes reRecovery Success Rate of 67.3% is computed over 48 initially- sources and degrades user experience. The 8.2% escalation rate failed tasks that entered recovery, yielding 95% CI [52.4%, demonstrates the system’s ability to detect underestimated risk 79.8%]—reflecting the smaller denominator for this metric. mid-execution and upgrade governance accordingly. The cost advantage over Static-Full ($0.041 vs. $0.098) is significant at p < 0.001 (paired bootstrap test). A longitudinal validation over 3 months with 2,400+ tasks is planned as future 7 Discussion work to confirm stability across seasonal workload variations. The Single-Agent baseline’s 12.8% RERR—meaning Model-Agnostic Governance. A distinctive property of roughly 1 in 8 high-risk operations proceeds without review— AGENT RUNNER is that its governance guarantees are invariconfirms that ungoverned execution is categorically unaccept- ant to the underlying LLM. The ToolGateway’s six-layer vali6
dation, the Checkpoint’s durability properties, and the tier routing logic operate at the system layer. When a more capable or cheaper model becomes available, it can be substituted as Worker or Critic without modifying any governance infrastructure. This future-proofs the architecture against the rapid model obsolescence cycle. Dual-Entry Architecture. AGENT RUNNER does not replace traditional SaaS interfaces. The production system maintains parallel entry points: conventional UI-driven CRUD for deterministic operations, and the Agent workspace for natural language-driven complex tasks. Both share permissions, audit, and business services—differing only in interaction modality. This pragmatic coexistence acknowledges that not all enterprise operations benefit from AI mediation. Domain Plugin Integration. The modular pipeline accommodates domain-specific analysis engines as Critic or Verifier plugins. In our deployment, an Operational Standard Root Analysis (OSRA) engine provides deep semantic alignment between proposed actions and established operational standards, demonstrating the framework’s extensibility without core modification. Limitations. (1) Tier classification depends on LLM judgment; approximately 3.4% of tasks receive initially incorrect tiers (mitigated by escalation). (2) The Critic exhibits 5–8% false positive rate, adding latency without safety benefit in those cases. (3) The framework introduces 2–3 additional LLM calls for Standard/Full tiers, setting a floor on minimum latency for governed operations. Mitigating Critic False Positives. The 5–8% false positive rate warrants dedicated mitigation. We employ three strategies: (a) a confidence threshold on Critic output—when the Critic’s self-reported confidence falls below 0.6, the verdict is downgraded to a “soft warning” surfaced in the trace but not enforced as a hard block; (b) a one-click override mechanism for trusted users with elevated permission levels, allowing rapid release of Critic-blocked operations without full re-review; and (c) Orchestrator auto-resolution—in production measurements, approximately 70% of Critic false positives are automatically resolved in the subsequent Orchestrator arbitration round without human intervention, as the Orchestrator recognizes that the flagged risk has already been addressed by existing constraints. These mechanisms reduce the effective user-facing false positive rate to under 2%. Escalation Monotonicity: Edge Cases and Safety Valves. The strictly monotonic escalation constraint (L → S → F ) prevents premature safety relaxation but introduces occasional over-escalation. In production data, approximately 3% of Standard-tier tasks are pure read queries that were escalated from Light due to false-positive cross-domain indicators (e.g. a query mentioning multiple brand names without actually requiring cross-brand writes). The additional latency penalty for these over-escalated tasks is modest: median +4.2 seconds (Standard vs. Light path), with negligible impact on user satisfaction scores. As a safety valve, the system provides an admin-level manual demotion capability for operational exceptions. Looking forward, we plan a “tier correction” mech-
anism wherein the Verifier, upon confirming that a Full-tier task involved only read operations, can signal the Orchestrator to adjust default tier assignment for future structurally-similar tasks—enabling gradual self-calibration without compromising safety guarantees. Risk Function Evolution. The current R(T ) heuristic (Equation 4) provides interpretable and auditable tier decisions. However, as production data accumulates, the system can evolve toward a lightweight learned classifier (e.g. a gradient-boosted tree over the same feature set) trained on tiercorrectness labels derived from Verifier outcomes. Preliminary analysis suggests that such a classifier could reduce the 3.4% tier misclassification rate to under 1.5%, though we prioritize interpretability in the current deployment. Future Work. (1) Multi-Runner coordination for tasks requiring concurrent execution contexts. (2) Automated tier threshold calibration from production feedback. (3) Federated governance learning across tenants while preserving data isolation. (4) Formal safety verification of ToolGateway properties. Multi-Runner Coordination: Preliminary Design Sketch. When multiple Runners operate concurrently within the same tenant, shared resource contention becomes possible. Our preliminary design (partially implemented in production) addresses this through three mechanisms: (a) Optimistic locking with conflict detection—each Runner’s ToolGateway requests carry a version vector; when two Runners attempt conflicting writes to the same business object, the later arrival receives an idempotency conflict error and enters a wait-retry queue with exponential backoff; (b) Scope-aware scheduling— the Orchestrator layer maintains a lightweight scope registry indicating which Runners are actively operating on which object sets, enabling proactive conflict avoidance before ToolGateway submission; (c) Cross-tenant federated learning—for the Retrospector’s organizational learning function, only anonymized experience signatures (failure pattern hashes, tier distribution statistics) are shared across tenants, never raw task data or tool payloads, preserving strict data isolation while enabling collective governance improvement.
8
Conclusion
We have presented Dynamic Tiered AgentRunner, a framework built on the thesis that governability—not autonomy— is the missing capability in enterprise AI systems. Through Risk-Adaptive Tiering, the framework avoids both the unsafe under-governance of autonomous agents and the wasteful overgovernance of static pipelines. Through Separation of Powers, it ensures that no single LLM call can propose, approve, and execute a high-risk operation. Through Resilience-by-Design, it treats failure as a recoverable state rather than a terminal one. Production deployment demonstrates that these principles are not merely theoretical: they produce measurable improvements in safety, efficiency, and organizational learning. Governance is not the antithesis of autonomy—it is its prerequisite. 7
References
[14] Y. Bai, S. Kadavath, S. Kundu, A. Askell, J. Kernion, A. Jones, et al. Constitutional AI: Harmlessness from AI [1] T. Richards. Auto-GPT: An autonomous GPT-4 experifeedback. arXiv preprint arXiv:2212.08073, 2022. ment. GitHub Repository, 2023. [15] L. Ouyang, J. Wu, X. Jiang, D. Almeida, C. Wainwright, P. Mishkin, et al. Training language models to follow in[2] Y. Nakajima. BabyAGI: Task-driven autonomous agent. structions with human feedback. In Advances in Neural GitHub Repository, 2023. Information Processing Systems, 2022. [3] Q. Wu, G. Bansal, J. Zhang, Y. Wu, B. Li, E. Zhu, L. Jiang, X. Zhang, S. Zhang, J. Liu, A. H. Liu, H. Wang, [16] Temporal Technologies. Temporal: Open source durable execution platform. Documentation, 2023. S. Mallick, K. Brown, C. Xiong, C. Gulcehre, Y. Chen, and C. Zhang. AutoGen: Enabling next-gen LLM ap- [17] Prefect Technologies. Prefect: Modern workflow orchesplications via multi-agent conversation. arXiv preprint tration. Documentation, 2024. arXiv:2308.08155, 2023. [18] Apache Software Foundation. Apache Airflow: A plat[4] S. Hong, M. Zhuge, J. Chen, X. Zheng, Y. Cheng, J. Wang, form to programmatically author, schedule and monitor C. Zhang, Z. Wang, S. K. S. Yau, Z. Lin, L. Zhou, C. Ran, workflows. Documentation, 2023. L. Xiao, C. Wu, and J. Schmidhuber. MetaGPT: Meta programming for a multi-agent collaborative framework. [19] Y. Ruan, H. Dong, A. Wang, S. Pitis, Y. Zhou, J. Ba, Y. Dubois, C. Maddison, and T. Hashimoto. Identifying arXiv preprint arXiv:2308.00352, 2023. the risks of LM agents with an LM-emulated sandbox. In Proceedings of ICLR, 2024. [5] J. Moura. CrewAI: Framework for orchestrating roleplaying autonomous AI agents. GitHub Repository, 2024. [20] T. Yuan, Z. He, L. Dong, Y. Wang, R. Zhao, T. Xia, L. Xu, B. Zhou, F. Li, Z. Zhang, R. Wang, and G. Liu. R-Judge: Benchmarking safety risk awareness for LLM agents. arXiv preprint arXiv:2401.10019, 2024.
[6] LangChain. LangGraph: Building stateful, multi-actor applications with LLMs. Documentation, 2024.
[7] C. Qian, X. Cong, C. Yang, W. Chen, Y. Su, J. Xu, Z. Liu, [21] S. Yao, D. Yu, J. Zhao, I. Shafran, T. L. Griffiths, Y. Cao, and M. Sun. Communicative agents for software developand K. Narasimhan. Tree of thoughts: Deliberate probment. In Proceedings of ACL, 2024. lem solving with large language models. In Advances in Neural Information Processing Systems, 2023. [8] Y. Shen, K. Song, X. Tan, D. Li, W. Lu, and Y. Zhuang. HuggingGPT: Solving AI tasks with ChatGPT and its [22] B. Qiao, L. Li, X. Zhang, S. He, Y. Kang, C. Pin Lim, friends in Hugging Face. In Advances in Neural InforR. Sen, Z. Qin, D. Nushi, E. Kamar, A. H. Awadallah, and mation Processing Systems, 2023. Q. Zhang. TaskWeaver: A Code-First Agent Framework. arXiv preprint arXiv:2311.17541, 2023. [9] T. Schick, J. Dwivedi-Yu, R. Dessı̀, R. Raileanu, M. Lomeli, E. Hambro, L. Zettlemoyer, N. Cancedda, [23] X. Liu, H. Yu, H. Zhang, Y. Xu, X. Lei, H. Lai, Y. Gu, and T. Scialom. Toolformer: Language models can teach H. Ding, K. Men, K. Yang, S. Zhang, X. Deng, A. Zeng, themselves to use tools. In Advances in Neural InformaZ. Du, C. Zhang, S. Shen, T. Zhang, Y. Su, H. Sun, tion Processing Systems, 2023. M. Huang, Y. Dong, and J. Tang. AgentBench: Evaluating LLMs as agents. In Proceedings of ICLR, 2024. [10] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao. ReAct: Synergizing reasoning and acting in [24] Y. Qin, S. Liang, Y. Ye, K. Zhu, L. Yan, Y. Lu, Y. Lin, X. Cong, X. Tang, B. Qian, S. Zhao, R. Tian, R. Xie, language models. In Proceedings of ICLR, 2023. J. Zhou, M. Gerber, D. Li, Z. Liu, and M. Sun. ToolLLM: [11] N. Shinn, F. Cassano, A. Gopinath, K. R. Narasimhan, Facilitating large language models to master 16000+ realand S. Yao. Reflexion: Language agents with verbal reworld APIs. In Proceedings of ICLR, 2024. inforcement learning. In Advances in Neural Information [25] L. Wang, C. Ma, X. Feng, Z. Zhang, H. Yang, J. Zhang, Processing Systems, 2023. Z. Chen, J. Tang, X. Chen, Y. Lin, W. X. Zhao, Z. Wei, and J.-R. Wen. A survey on large language model based [12] A. Zhou, Y. Yan, M. Shlapentokh-Rothman, H. Wang, and autonomous agents. Frontiers of Computer Science, 2024. Y.-X. Wang. Language agent tree search unifies reasoning, acting, and planning in language models. In Proceedings [26] H. Chase. LangChain: Building applications with LLMs of ICML, 2024. through composability. GitHub Repository, 2022. [13] G. Wang, Y. Xie, Y. Jiang, A. Mandlekar, C. Xiao, [27] J. S. Park, J. C. O’Brien, C. J. Cai, M. R. Morris, P. Liang, Y. Zhu, L. Fan, and A. Anandkumar. Voyager: An openand M. S. Bernstein. Generative agents: Interactive simuended embodied agent with large language models. arXiv lacra of human behavior. In Proceedings of UIST, 2023. preprint arXiv:2305.16291, 2023. 8