Skip to content

A Formal Hierarchical Architecture for Agentic Orchestration with Stack-Based Execution and Lazy Discovery

๐Ÿ•’ Published (v1): 2026-07-13 06:15 UTC ยท Source: Arxiv ยท link

Why this paper was selected

Formal hierarchical orchestration with stack-based execution; addresses flat-registry bottleneck architecturally

Ask a follow-up

Open an assistant pre-loaded with this paper's context.

๐Ÿ’ฌ Ask ChatGPTโœฆ Ask Claude

TL;DR

This paper formalizes a hierarchical, tree-structured orchestration architecture for LLM agents that replaces flat tool registries with a LIFO call-stack runtime and manifest-driven lazy capability loading. The design is motivated by production requirements in UPI Help, a digital payments support product, where flat tool exposure causes context saturation and routing degradation. Capabilities are bifurcated into decision-making orchestrator nodes and deterministic executable leaves, giving the system the power of a Pushdown Automaton.

Problem

Flat-registry agents expose all \(N\) tool schemas simultaneously, creating a context footprint \(|\Omega_t|_\text{flat} = \sum_{v \in V} |\text{schema}(v)| + |H_t|\) that grows linearly with \(N\), causing decision-space explosion and hallucinated tool invocations. Additionally, append-only dialogue history \(H = \langle m_0, m_1, \ldots, m_t \rangle\) has no hierarchical depth indicators, behaving as a Finite State Machine with no deterministic sub-task resumption after failure.

Method

The architecture organizes all capabilities as a rooted tree \(T = (V, E, r)\) where internal nodes \(v_\delta\) (decision-making skills) perform localized routing and leaf nodes \(v_\epsilon\) (executable skills) run deterministic logic. Global state is a triple \(S = \langle M, \Gamma, p_\text{call} \rangle\) where \(\Gamma\) is a LIFO Skill Path Stack of context frames \(\gamma_i = \langle id, \rho, \text{parent}, \tau, o_\text{self}, O_\text{acc} \rangle\), each holding a localized output accumulator \(O_\text{acc}\) so child results never leak into sibling branches. The single-step execution loop (Algorithm 1) reads the pending call pointer \(p_\text{call}\), invokes lazy discovery only when entering a decision-making node (Algorithm 2, parsing the local skills_info.json for immediate children only), calls the LLM with only those children's schemas in context, then either pushes a new frame or pops the stack on return. Leaf results bubble deterministically up the stack without LLM involvement. Capabilities are declared in per-node JSON manifests \(M = \{id, desc, \tau, \Sigma_{in}, \Sigma_{out}, \mu\}\); adding new skills requires only a new directory and a manifest entry โ€” the core loop is untouched.

Key Contributions

  • Formal system model: rooted capability tree that structurally decouples probabilistic orchestrators from deterministic execution leaves.
  • Stack-based execution semantics: LIFO runtime with the Stack-Pending Invariant (parent frame is always on-stack when a child is executing), elevating the agent to a context-free Pushdown Automaton with lossless resumption.
  • Manifest-driven lazy discovery: per-node skills_info.json restricts context to immediate children; prompt cost scales with explored path depth, not \(|V|\).
  • Execution isolation / prompt-injection mitigation: untrusted leaf outputs are scoped to leaf frames; only schema-validated results enter the parent's \(O_\text{acc}\), preventing cross-branch contamination.
  • Routing-agnostic extensibility: horizontal (sibling) and vertical (sub-orchestrator) scaling via declarative JSON, zero core-loop changes.
  • Production deployment case study: UPI Help payments-support domain.
  • Empirical benchmarks: flat vs. hierarchical routing on prompt scalability, visible schema-token exposure, multi-step workflow pressure, and UPI-specific flows.

Results

  • Per-step visible schema token exposure is bounded by the active node's local out-degree under the hierarchical architecture vs. growing as \(O(N)\) for flat registries (quantitative curves reported for increasing catalog size).
  • Hierarchical routing maintains accuracy under multi-step workflow pressure where flat routing degrades, though the paper notes "accuracy depends on tree design."
  • Controlled benchmarks show hierarchy bounds per-step context growth; flat registries show increasing reasoning failures as tool count grows (specific numbers appear in Section 9 of the full paper, which is truncated in the provided text).

Limitations

  • Routing accuracy is sensitive to tree design; a poorly structured hierarchy can degrade performance even with correct stack mechanics.
  • The architecture assumes a static or slowly-evolving tree; highly dynamic capability sets require manifest updates and may disrupt lazy discovery caching.
  • Decision-making nodes cannot directly invoke capabilities outside their subtree, which may require tree restructuring for cross-domain tasks.
  • Evaluation is conducted in a single production domain (UPI Help payments); generalizability to other enterprise verticals is asserted but not empirically demonstrated in the provided text.
  • The approach inherits LLM routing non-determinism at each decision node despite deterministic stack control-flow around it.

Relevance to Harnesses / Meta-Harnesses

This paper is directly relevant as a formal treatment of the execution substrate that harnesses sit atop: the LIFO stack with lazy manifest loading is itself a meta-harness pattern โ€” a runtime that governs how sub-agents/tools are discovered, invoked, and composed without embedding task logic in the orchestration loop. The strict separation of routing nodes (orchestrators) from executable leaves mirrors the harness/sub-agent split common in multi-agent pipeline harnesses. The manifest-driven extensibility mechanism (add a JSON file, gain a new capability) is the same declarative plugin model used in tool-registry harnesses like MCP, making this work a formal theoretical grounding for that class of systems. The Stack-Pending Invariant and localized \(O_\text{acc}\) accumulator directly address the context-bleed and non-deterministic recovery problems that plague real-world harness implementations.