1 Introduction↩︎

Modern warehouse operations require continuous monitoring, multi-step diagnosis, and timely intervention across dozens of systems, ranging from robotic conveyance operators tracing threshold breaches to root causes within minutes, to inventory ticket processing that queries state, validates constraints, and submits physical item picks across many systems per ticket. Robotic conveyance diagnosis and ticket processing are two among many such workflows, each governed by Standard Operating Procedures (SOPs): directed decision pathways with prescribed steps, dependencies, quantitative thresholds, and constraints that must be followed faithfully. Today much of their execution is manual, slow, and error-prone, and delays in diagnosis directly degrade throughput, making automated SOP execution a pressing business need.

Large language models reason well [1], [2], but agentic frameworks such as ReAct [3] and Reflexion [4] rely on loosely structured prompts with no mechanism to strongly guide SOP compliance, so a capable model can still deviate from prescribed decision paths. Recent benchmarks confirm this gap on workflow-guided tasks [5], [6], industrial SOP-following [7], and operational diagnostics where even SOP-enhanced multi-agent systems plateau in performance  [8]. A core bottleneck is context overload: with the full SOP in view, performance degrades as complex workflows overwhelm the model’s ability to select relevant actions [5], [8]. This plateau holds regardless of model scale, and prompting alone is insufficient without domain-specific training [7].

We present a graph-guided agent framework that addresses these challenges through a unified execution model. SOPs are encoded as directed acyclic graphs, and progressive disclosure surfaces only the reachable subgraph and node-level specifications on demand. A main agent orchestrates traversal and delegates independent node evaluations to parallel sub-agents in isolated contexts, each with a persistent code interpreter (the CodeAct paradigm of [9]) and access to real-time data via the Model Context Protocol [10], providing context isolation and parallelism while guiding the agent toward procedural compliance. Together, progressive disclosure and sub-agent isolation address context overload. Each operational use case is packaged as a self-contained Skill² loaded on demand, so new workflows need no bespoke systems. Since prompting alone is insufficient [7], we pair the framework with a trajectory-centric training pipeline where episodic learning corrects a strong teacher’s trajectories without weight updates, and a smaller, low-latency student is fine-tuned without episodic memory (asymmetric episodic distillation), internalizing the episodic corrections in its weights rather than depending on them at inference. We make three contributions:

• A graph-guided skill-based agent framework that encodes SOPs as directed acyclic graphs with progressive disclosure, and uses hierarchical multi-agent execution with parallel sub-agent delegation for scalable, procedurally compliant reasoning across multiple operational use cases.

• A trajectory-centric training pipeline with asymmetric episodic distillation: episodic learning iteratively improves teacher trajectory quality, and the student is fine-tuned on per-turn decomposed trajectories filtered by rejection sampling, with episodic memory stripped, internalizing the episodic corrections in its weights and eliminating inference-time memory dependence.

• Real-world performance on a 13-task operational reasoning benchmark and two production warehouse applications (robotic conveyance and ticket processing), demonstrating that a fine-tuned 32B model outperforms all baselines including its teacher and larger off-the-shelf models. A fine-tuned 355B model achieves a 94% human-match on the ticket processing application.

2 Related Work↩︎

2.0.0.1 Tool-Augmented Agents and Multi-Step Reasoning.

LLM agents have been equipped with code execution [9], [11], APIs [12], [13], and standardized tool protocols [10]. Multi-step reasoning methods range from chain-of-thought [1] and tree-of-thoughts [14] to interleaved reasoning and action [3] and hierarchical decomposition [15], [16]. These approaches improve general reasoning but rely on loosely structured prompts without mechanisms to enforce deterministic procedural constraints.

2.0.0.2 Structured Reasoning and Operational AI.

Multi-agent frameworks such as AutoGen [17] and MetaGPT [18] enable task decomposition across specialized agents. SOPStruct [19] converts unstructured SOPs into DAGs, but focuses only on structuring rather than execution. Agent-S [20] navigates SOPs via prompt-driven state machines but lacks graph-guided progressive disclosure, code execution, and post-training. Our work integrates SOP graphs into both inference and training.

2.0.0.3 Trajectory-Centric Training.

Reflexion [4] and Self-Refine [21] use iterative feedback to improve trajectories at inference time. FireAct [22] and AgentTuning [23] show that fine-tuning on agent trajectories improves generalization. Our pipeline differs in two ways: episodic learning improves the teacher trajectories used for distillation rather than the deployed model, and training is aligned with graph-structured procedural logic rather than free-form tasks.

3 A Graph-Guided Operational Agent↩︎

Eluna is a hierarchical multi-agent framework that addresses the two challenges above (context overload and use-case generality) through graph-structured progressive disclosure, parallel sub-agent delegation, and skill packaging. Figure 1 provides an overview.

3.1 Graph-Structured SOP Representation↩︎

Each SOP is a directed acyclic graph \(G = (V, E)\) with five node types: observations (detectable conditions), root causes (diagnosed causes), calculations (metric analysis), constraints (preconditions), and actions (remediation). Each node has a parameterized specification defining its evaluation procedure, which produces a structured outcome: a boolean, a classification (e.g., a category that routes downstream traversal), or a computed value. Edges encode directed dependencies: a single-node edge activates the child on the boolean outcome of one parent (holding, or not holding for fallback paths), while a multi-node edge requires several parents to hold simultaneously. A node may have multiple outgoing edges.

3.1.0.1 Progressive Disclosure.

Presenting the full graph degrades traversal accuracy [24], especially with parallel paths, where the agent conflates branches, omits nodes, or explores irrelevant subtrees. We disclose the graph at two levels. First, a retrieval tool runs BFS from the triggered node and returns only the reachable subgraph (node types, edge relationships, brief descriptions). Second, each node’s full procedural specification (evaluation logic, required tool calls, thresholds) is fetched only when the agent begins evaluating it, bounding working context to one node at a time.

3.2 Hierarchical Multi-Agent Architecture↩︎

Eluna uses a two-level hierarchy: a main agent orchestrates traversal while sub-agents evaluate individual nodes in parallel. The main agent holds the retrieved subgraph, selects the next nodes to evaluate from edge dependencies, and issues delegation calls; each sub-agent receives a fresh context with only the assigned node’s procedural specification, role instructions, and tools. Action nodes remain with the main agent because they require graph-level state for sequencing and constraint checking.

Multiple delegation calls issued in one turn execute in parallel, reducing wall-clock time to roughly the slowest single evaluation. Only each sub-agent’s structured conclusion is returned, so the main agent’s context grows by one summary per node rather than the full investigation history; sub-agent sessions persist so the main agent can query one for detail without re-running it, and sub-agents cannot spawn further sub-agents. This isolates tool outputs and intermediate computation within sub-agent sessions, addressing context overload by construction while the main agent holds only graph structure and node conclusions. In a parallel effort, we reduce the per-node sub-agent overhead by compiling repeated SOP steps into reusable tools at build time [25].

3.3 Skill Packaging↩︎

Each warehouse workflow needs its own decision logic, prompts, data sources, and actions. A custom agent per use case duplicates the execution engine and training pipeline, while a single agent loaded with all use cases suffers context overload and tool-space conflicts. The workflow is a more natural packaging unit: we bundle per-workflow artifacts into a self-contained skill loaded at runtime, following the standardized skill format models are increasingly trained to use. The framework stays use-case-agnostic so the same agent and execution logic serve any loaded skill, and adding a workflow means authoring a skill, not modifying the agent.

A skill comprises five components: (1) the decision graph encoding the SOP as a DAG, (2) use-case-specific tools accessed via the Model Context Protocol [10] for querying data and executing actions, (3) node detail specifications containing per-node evaluation logic, (4) CodeAct functions [9], and (5) execution instructions directing traversal strategy (e.g., when to delegate, how to handle constraints); reference documents for knowledge retrieval [26] are bundled as readable files. When a trigger fires, a skill-loading tool registers the skill’s tools under a namespace prefix, injects its CodeAct functions into the persistent interpreter as importable modules, and appends its execution instructions, after which the agent has exactly the tools and instructions for the current use case.

3.4 Tool Ecosystem↩︎

The agent operates over five tools: a persistent code interpreter for programmatic data manipulation and metric computation; a task-tracking list that doubles as a steering mechanism to keep traversal on the intended path; MCP-based data and action access [10] to operational dashboards; agentic RAG [26] for on-demand knowledge retrieval; and an operative memory that persists across invocations, accumulating knowledge and enabling deduplication of redundant investigations. Appendix 8 details each one.

4pt

4 Training Strategy↩︎

The graph-guided framework (Section 3) is model-agnostic, but even the largest available models fail to reach reliable accuracy on graph-structured procedural reasoning [7], motivating domain-specific training. We design a trajectory-centric pipeline: a strong teacher generates trajectories within the full framework, episodic learning [4] iteratively corrects the teacher’s errors without weight updates, and rejection sampling [27] with LLM-judge evaluation [28] filters the improved trajectories for correctness before fine-tuning a smaller student that meets the production latency SLA. Crucially, the episodic memory is used only during teacher trajectory generation and stripped from student training and inference (asymmetric episodic distillation), forcing the student to internalize the episodic corrections in its weights and eliminating any runtime memory dependence. We detail each stage in Appendix 9.

5 Experiments↩︎

5.1 Experimental Setup↩︎

The agent framework is implemented using the Strands Agents SDK [29], following the design in Section 3. We fine-tune Qwen3-32B [30] and GLM-4.5-Air [31] with LoRA [32] on 8,525 training samples (expanded from trajectories via turn-level decomposition, Appendix 9). Training and inference details are in Appendix 11.

5.1.0.1 Datasets

We evaluate on three tasks: an operational reasoning benchmark of 13 task types testing capabilities required for warehouse operational reasoning (1,400 evaluation samples; Table 1), a robotic conveyance application covering end-to-end SOP execution over 1,500 real scenarios, and a ticket processing application executing a 46-node inventory consolidation SOP on 410 real tickets evaluated against expert annotations. For the first two, ground truth is generated from real operational data by sampling timestamps, checking root-node conditions, and running a deterministic SOP implementation where they hold, with temporal partitioning separating training from evaluation. Ticket processing has no deterministic ground truth, so correctness is estimated from expert review of sampled agent traces.

5.1.0.2 Evaluation

Claude Sonnet 4 is used as the automated judge of answer correctness for the first two tasks. On the benchmark, the judge scores model outputs against reference answers. On the robotic conveyance application, node classifications are extracted from agent trajectories and compared against ground-truth labels, reporting binary correctness (per-node accuracy) and exact match (all nodes of a type correct within a scenario). All results are reported as percentage improvement over the GLM-4.5-Air off-the-shelf (OTS) baseline.

5.1.0.3 Models

All models are evaluated within the same framework, with identical tools and skills and with episodic memory stripped at inference (Section 3). The baseline is OTS GLM-4.5-Air, a 106B parameter model that meets the production latency SLA, hence the reference point for what is achievable under operational constraints. GLM-4.7 (355B), the teacher that generated training trajectories, is too large to meet that SLA, so it serves as a trajectory generator and upper reference rather than a deployable baseline. We additionally compare OTS Qwen3-235B-A22B-Thinking and OTS Qwen3-32B, against our two fine-tuned models Eluna-Q (Qwen3-32B) and Eluna-G (GLM-4.5-Air). For the ticket task, which runs on a longer interval, we additionally fine-tune the teacher itself into Eluna-G-XL, whose latency meets that interval.

5.2 Results↩︎

5.2.0.1 Operational Benchmark.

Table 1 reports per-task results. Eluna-G improves 6.5% and Eluna-Q improves 6.0% over the baseline on average. Eluna-Q, trained on GLM-4.7 trajectories, matches the teacher (+6.0% vs.+6.1%) despite being a different and smaller architecture, showing that our pipeline transfers operational reasoning across model families, while OTS Qwen3-32B averages 38.0% below the baseline, showing the gap that domain-specific training closes. The largest gains concentrate on complex multi-step tasks like Causal Chain Analysis (Task 5), Query Understanding (Task 8), and Query Decomposition (Task 10). These require chaining tool calls and synthesizing across data sources, indicating that training instills operational reasoning rather than single-step retrieval.

5.2.0.2 Robotic Conveyance Application.

End-to-end SOP execution is far harder than isolated benchmark tasks: even with full framework access, the OTS baseline compounds per-node errors across the traversal and degrades sharply. We report binary correctness and exact match (Section 5.1) per node type—observations, root causes, and actions—to reflect the distinct sub-tasks of detection, diagnosis, and remediation. Fine-tuning on complete trajectories closes the gap (Table 2): all trained models improve observation binary correctness by over +49%, root-cause binary correctness by over +73%, and exact match by +84% on root causes and +165% on actions, with our 32B model matching the GLM-4.7 teacher across all metrics—evidence that trajectory distillation transfers full SOP traversal behavior, not just isolated skills.

Median end-to-end execution latency (wall-clock from query to final action) is also reduced by 54.3% (Eluna-Q) and 54.8% (Eluna-G) relative to GLM-4.7, meeting the latency constraints for real-time diagnostic support.

5.3 Ablation Studies↩︎

Table 3 isolates the contribution of episodic learning (EL) by varying where EL memory is applied. Results on Tasks 5 and 10 are reported as percentage change relative to the no-EL variant.

Applying EL only to the teacher (our approach) yields +16.2% on Task 5 and +28.6% on Task 10, matching the variant that also feeds EL to the student at inference (Task 5: +16.6%, Task 10: +25.3%) but without its runtime memory dependence. Training the student with EL yet removing it at inference degrades catastrophically (Task 5: \(-\)​52.7%, Task 10: \(-\)​40.0%), confirming that our asymmetric design must distill episodic knowledge into parameters rather than expose it as a brittle inference-time dependency. Appendix 10 details the four variants.

6 Deployment and Business Impact↩︎

Our framework is deployed in production across multiple operational applications, served on Amazon Bedrock AgentCore [33]. The two applications below apply it in contrasting regimes: robotic conveyance is latency-critical metric analysis, while ticket processing is latency-insensitive but needs complex reasoning.

6.1 Robotic Conveyance↩︎

This metric-analysis task queries live dashboards to compute metrics, and compares them against thresholds over a 63-node SOP graph whose high branching factor drives parallel sub-agent delegation. A degraded station can back up the main conveyor and erode facility-wide throughput in minutes, so diagnosis must be fast and correct.

In production deployment at a warehouse, the agent has processed roughly 8,000 triggers, producing 3,435 process alerts and 1,078 maintenance tickets. SOP adherence is near-perfect: SME review of agent trajectories finds the execution correct. The remaining errors trace to gaps in the SOP specification and upstream data quality rather than to agent reasoning. Prior to deployment, operators manually interpreted dashboards, navigated SOPs, and coordinated corrective actions. Early deployment feedback indicates a \(300\%\) speedup in resolution time while reducing cognitive load and improving SOP adherence consistency.

6.2 Ticket Processing↩︎

This is a language-reasoning task. The agent interprets free-text ticket requests (expiration, damage, recalls, audits) and performs multi-step reasoning over structured inventory records—validating constraints, resolving eligibility, and deciding consolidation—rather than merely parsing the request. Each request type routes differently, and eligibility depends jointly on item condition and storage-location type. The SOP graph contains 46 nodes and is predominantly sequential, with mutually exclusive conditional paths. The network processes tens of thousands of these tickets daily. Approximately 80% are handled through an existing scanning workflow. The remaining 20% require manual desk processing at \(\approx\)​6 minutes per ticket. We deploy Eluna-G-XL, an open-weight 355B fine-tune from the same pipeline. The agent’s median generation duration is 187s (p90: 257s, mean: 210s), below the manual rate.

The agent automates the digital triage preceding physical inspection: interpreting the request, querying inventory, validating constraints, and submitting the pick, leaving the associate only the inspection. Precision (Table 4) is the operationally critical metric, as a false consolidation submits a pick that cannot be processed, wasting labor and blocking the queue. Only a small fraction of tickets need manual handling, freeing capacity for substantially larger volumes.

7 Conclusion↩︎

Deploying Eluna in production surfaced two lessons that generalize beyond our setting. First, within the graph-guided framework, distillation beats scale for procedural compliance: a fine-tuned 32B model matches a far larger teacher and surpasses every OTS model tested, which plateau regardless of size. Second, the operational constraint of low latency under a production SLA is what forced the asymmetric distillation design, since exposing episodic memory at inference proved a brittle dependency rather than just an accuracy gain. The residual errors we observe trace to SOP-specification gaps and upstream data quality rather than agent reasoning, pointing to the SOP authoring and data-integrity pipeline as the next bottleneck for reliable operational automation.

Limitations↩︎

Our system is currently deployed on two operational domains; while the skill-based architecture is designed for generality, transfer to substantially different operational environments remains to be validated empirically. The episodic learning pipeline assumes access to a capable teacher model and sufficient compute for multiple trajectory generation rounds, which may limit adoption in resource-constrained settings. Finally, both episodic learning and fine-tuning rely on ground-truth labels, which are expensive and time-consuming to obtain at scale; reducing this dependence is important future work.

Appendix↩︎

8 Tool Ecosystem Details↩︎

8.0.0.1 Code Interpreter.

The agent performs data manipulation and metric computation through a persistent Python interpreter (CodeAct [9]) whose state—variables, imports, and intermediate results—is retained across tool invocations within an investigation. Operational data retrieved through MCP tools is analyzed programmatically—filtering, aggregating, and computing derived quantities—so that only the resulting view enters the model’s input context rather than the full table. Executing comparisons and threshold checks in code eliminates arithmetic errors that arise when models perform these operations in natural language, and loops over CodeAct functions (programmatic wrappers exposed within the interpreter) let the agent batch repeated queries without issuing a separate tool call per iteration.

8.0.0.2 Task Tracking.

A TodoList tool, exposed within the interpreter, lets the agent record and update the steps of an investigation as it traverses the decision graph. Beyond bookkeeping, this serves as a steering mechanism: maintaining an explicit plan keeps the agent on the intended path through parallel branches, surfaces which nodes remain to be evaluated, and reduces premature termination on multi-step procedures.

8.0.0.3 MCP Tools.

Data retrieval and actions are implemented through the Model Context Protocol [10], providing a standardized interface to warehouse operational dashboards. A query_metric interface abstracts tool invocation, accepting a tool name, warehouse identifier, and time range, and returning results as pandas DataFrames for the interpreter to consume. Decoupling the agent’s reasoning from data-source implementation lets dashboard backends evolve independently, and thread-safe connection management enables concurrent queries from parallel sub-agents.

8.0.0.4 Agentic RAG.

The agent augments its decision-making with domain knowledge retrieved on demand. Unlike static pipelines that prepend fixed context [34], the agentic RAG component operates via tool-calling [26]: when the agent detects a knowledge gap, it formulates a query and invokes a knowledge-base tool, receiving relevant passages as a tool response. This grounds reasoning in operational definitions, site-specific configurations, and historical incident documentation, and lets these definitions be updated without modifying the core SOP structure.

8.0.0.5 Memory.

The framework includes an operative memory that persists across agent invocations, accumulating knowledge over time rather than treating each investigation in isolation. The agent queries memory for prior findings on an entity before investigating and writes its outcome afterward, so observations build into patterns that are not visible within a single run. Deduplication follows as a direct consequence: when a prior invocation already resolved the same condition or determined that no remediation is possible, the current agent omits the redundant investigation. Memory entries expire after a configurable window so that stale findings do not suppress legitimate re-evaluation.

9 Training Pipeline Details↩︎

9.0.0.1 Episodic Learning for Teacher Improvement.

Initial teacher trajectories contain errors such as missed branches and threshold misinterpretations. Rather than manually correcting these, we iteratively improve the teacher through episodic learning [4] without weight updates. The episodic memory is used only during teacher trajectory generation and is excluded from student training and inference. After each batch of teacher runs, trajectories are evaluated against ground truth. For failures, a separate LLM analyzes the error and generates candidate memory entries that would prevent recurrence. New entries are added, and a consolidation step merges redundant entries to keep the memory compact. The teacher is re-run with updated memory injected into its prompt, iterating for \(N\) rounds until convergence. Providing the memory at inference would yield equivalent accuracy (our ablation in Section 5.3 confirms this), but adds prompt overhead and requires maintaining a growing memory store. Training on improved trajectories without the memory forces the student to internalize the episodic corrections in its weights, eliminating runtime context dependence.

9.0.0.2 Trajectory Decomposition and Fine-Tuning.

Training trajectories are generated by running the teacher on labeled scenarios within the full framework (skills, MCP tools, code execution). For each scenario, the teacher queries operational data through the same tools used at inference time, producing a multi-turn trajectory of reasoning, tool calls, and tool outputs. Scenarios are sampled with balanced representation across outcome categories, and temporal partitioning enforces train-test separation. We decompose each trajectory into \(T\) training samples (one per agent turn): the \(t\)-th sample takes as input the conversation history up to turn \(t\) (system prompt, all prior tool calls and outputs, with the model’s own reasoning from prior turns stripped) and targets the complete reasoning and action for turn \(t\). Retaining tool outputs is necessary: omitting them would desynchronize the model’s state from the actual execution trace. Stripping prior reasoning forces independent generation at each turn, focusing the loss on single-turn decision quality. Not all trajectories are correct even after episodic improvement. We apply rejection sampling [27] with LLM-judge evaluation [28]: numerical outputs are compared with 2% tolerance, and categorical outputs require exact match. Only fully correct trajectories are retained for fine-tuning.

10 Episodic Learning Ablation Details↩︎

To isolate the impact of episodic learning and understand whether asymmetric distillation is necessary, an ablation is performed on Tasks 5 and 10 from the benchmark (Table 3). Four variants are tested: (1) no EL anywhere, (2) EL in teacher only (our approach), (3) EL memory provided to the student during both training and inference, and (4) EL memory provided during student training only, removed at inference. Applying EL only to the teacher (our approach) yields +16.2% on Task 5 and +28.6% on Task 10 over the no-EL variant. When EL is given to the student at both training and evaluation, comparable accuracy is reached (+16.6%, +25.3%), but an inference-time dependence on the growing EL context is introduced, adding latency for no accuracy gain. Training with EL but evaluating without it degrades catastrophically (\(-\)​52.7%, \(-\)​40.0%), falling below even the no-EL variant. This shows that naively exposing the student to episodic context creates a brittle dependency. Our asymmetric design distills the episodic corrections into the student’s weights, removing any inference-time memory requirement.

11 Training and Inference Details↩︎

Models are fine-tuned using MS-SWIFT [35] with LoRA [32]. For Qwen3-32B, we use rank and alpha of 256, learning rate \(2{\times}10^{-4}\), and train on 64 H100 GPUs. For GLM-4.5-Air, we use rank and alpha of 32, learning rate \(1{\times}10^{-4}\), and train on 128 H100 GPUs. Both use a batch size of 64, 5% linear warmup followed by cosine annealing to zero, and train for 2 epochs. The ticket-processing model Eluna-G-XL fine-tunes GLM-4.7 (355B) with the same MS-SWIFT/LoRA pipeline (rank and alpha 64, learning rate \(5{\times}10^{-5}\), batch size 64, 1 epoch) on 128 H100 GPUs. LoRA weights are merged after training, eliminating inference overhead. At inference, Eluna-G and Eluna-Q are served via vLLM [36] on 8 H100 GPUs, and Eluna-G-XL via SGLang [37] on 8 H200 GPUs.

12 Ticket Processing Evaluation↩︎

12.0.0.1 Model.

The deployed ticket-processing agent is Eluna-G-XL, an open-weight GLM-4.7 (355B) fine-tuned with the same trajectory-centric pipeline as Eluna-G and Eluna-Q (Appendix 9, config in Appendix 11). Ticket processing runs on a longer interval than robotic conveyance, so a larger fine-tune is admissible: Eluna-G-XL’s median generation duration (Section 6.2) meets that requirement. All results in Table 4 are from this single fine-tuned model.

12.0.0.2 Evaluation setup.

The 410 tickets are an unbiased sample of open consolidation tickets at one fulfillment center on a single day, processed by the agent in the production framework with live inventory access. The task has no deterministic ground truth (the correct solution depends on live inventory state at processing time), so correctness is estimated by expert review of agent traces.

References↩︎

---

1.  Equal contribution.↩︎

2. https://agentskills.io/: a bundle comprising the decision graph, use-case-specific tools, node specifications, and execution instructions.↩︎