ALAS: Transactional and Dynamic Multi-Agent LLM Planning

• Standalone LLM planners often produce incomplete or inconsistent action sequences, violate constraints, and struggle with long-range coordination or reactive updates.These failures become acute when plans require multi-entity coordination and revision under change.Source: §1 · p. 1
• ALAS separates planning from non-circular validation and uses versioned logs, explicit execution policies, and localized repair to treat reliability as a systems property.Its transactional controls include idempotency keys and compensation, while dynamic behavior adapts to runtime disruptions without global recomputation.Source: §1 · pp. 1–2
• The five-layer architecture covers workflow blueprinting, canonical workflow compilation, policy-governed execution and repair, repeated revalidation, and supervised final-plan selection.The workflow loop records metrics for audit and replay while re-checking feasibility after repairs until success or a budget limit.Source: §1 · p. 2
• The canonical workflow IR makes retries, catches, timeouts, backoff, idempotency keys, compensation, loop guards, and schemas explicit, then maps to Amazon States Language and Argo Workflows.Round-trip tests and a conformance matrix enforce portability and parity across the two runtimes.Source: §1 · p. 2
• Disruption-aware evaluations on DMU and TA job-shop scheduling suites show improved feasibility retention and stable makespan under comparable token and latency budgets.The evaluation emphasizes reliability under runtime disruption rather than perfect first-pass generation.Source: §1 · p. 3

2.1 STRUCTURAL LIMITATIONS OF LLMS

• LLMs face circular verification, decoding bias, context degradation, error propagation, and absent persistent state; ALAS addresses these through isolated validation, versioned logs, and localized repair.Open-domain validation and reliable revision remain unresolved despite self-reflection, chain-of-thought variants, and structured validators helping in narrower domains.Source: §2.1 · p. 3

2.2 LLM MULTI-AGENT SYSTEMS AND ORCHESTRATION

• Conversation-centric multi-agent frameworks support collaboration, retries, branches, and state passing but generally lack durable workflow guarantees, isolated validators, auditable logs, compensation, idempotency, and conformance testing.ALAS instead treats planning reliability as a systems property, combining explicit policy contracts, independent validators, durable execution, and an IR mapped to ASL or Argo.Source: §2.2 · p. 3

2.3 WORKFLOW STANDARDS AND ALAS INTEGRATION

• ALAS defines a canonical workflow IR that makes retries, timeouts, backoff, idempotency, compensation, loop guards, and schemas explicit, with converters to Argo Workflows and Amazon States Language.BPMN 2.0 supports documentation diagrams, while Airflow and scientific-workflow systems provide additional deployment and contextual options.Source: §2.3 · pp. 3–4

2.4 LLM PLANNING FRAMEWORKS AND BENCHMARKS

• Classical scheduling methods remain stronger on static benchmarks, while ALAS uses LLMs for interpretability and adaptive repair, adding execution logs and localized repair under disruption.This complements execution-layer durability and compensation work such as SAGALLM by making planning reliability explicit.Source: §2.2 · p. 3, §2.4 · p. 4
• Disruption-aware evaluation remains limited, so ALAS uses Demirkol-DMU and Taillard job-shop suites with machine-downtime and operation-delay shocks to assess logs, validator isolation, and localized repair.These benchmarks provide formal constraints, known bounds, and natural perturbation models for execution-aware evaluation.Source: §2.4 · p. 4

3 ALAS ARCHITECTURE AND SPECIFICATION

• ALAS organizes reliable planning into five layers: blueprinting, agent instantiation, runtime execution with localized repair, revalidation, and supervision.The architecture targets validator isolation, grounded restore points through versioned logs, and bounded disruption during execution.Source: §3 · p. 4

3.1 LAYER 1: WORKFLOW BLUEPRINTING

• The workflow blueprint maps inputs and constraints into role nodes, dependency edges, invariants, local log schemas, repair specifications, explicit policies, and independent validation checks.Validation covers structural soundness, constraint satisfaction, and repair coverage under the disruption model.Source: §3 · p. 5, §3.1 · p. 5

3.2 LAYER 2: AGENT FACTORY AND CANONICAL WORKFLOW IR

• The agent factory instantiates executable roles from bounded specifications, while the canonical workflow IR explicitly represents schemas, logs, repairability, and policies and maps to Amazon States Language and Argo Workflows.The IR is engine-agnostic and serves as the single source of truth for execution targets, portability, and reproducibility.Source: §3.2 · pp. 5–6, Table 2 · p. 6

3.3 LAYER 3: RUNTIME EXECUTION AND LOCALIZED REPAIR

• During execution, agents update assignments and versioned logs, while localized cascading repair edits the smallest affected neighborhood, preserves unaffected work, validates the subplan, and enlarges scope only when necessary.Global recomputation is a fallback when repair cost thresholds are exceeded.Source: §3.3 · p. 6

3.4 LAYER 4: REVALIDATION

• After each repair, ALAS revalidates until feasibility is restored or the iteration budget is exhausted, then proceeds with the best feasible plan if necessary.This layer closes the repair loop while preserving an explicit feasibility condition.Source: §3.4 · p. 7

3.5 LAYER 5: SUPERVISION

• The versioned log supplies restore points and auditability, so a separate supervisor is unnecessary; ALAS selects the plan with the best makespan and records key execution metrics.Logged outputs include makespan, operation counts, and critical operations.Source: §3.5 · p. 7

3.6 POLICIES, FAULT MODEL, AND DETERMINISM

• ALAS handles transient and logical faults with bounded retries, catches, timeouts, safe idempotent compensation, fixed seeds, pinned tools, and log-based replay, while excluding resource exhaustion and Byzantine behavior.Replay reconstructs inputs from the log and reruns validators to check parity.Source: §3.6 · p. 7

3.7 APIS AND CONTRACTS

• Typed planner, validator, repair, and optimizer contracts constrain schemas, domain validity, neighborhood-limited edits, and non-increasing optimization cost.The repair contract requires changes only inside the selected neighborhood, while optimization applies only to feasible plans.Source: §3.7 · p. 7

4 EXPERIMENTAL EVALUATION

• The evaluation spans three domains of increasing complexity, including URS coordination, five classical JSSP benchmarks, and Family Reunion event coordination.Reported metrics cover static-plan and dynamic-repair feasibility, efficiency, edit-radius containment, and token or latency overhead, using 10 independent fresh-context threads.Source: §4 · pp. 7–8

4.1 MAIN EXPERIMENT: JOB SHOP SCHEDULING PROBLEM

• 83.7% aggregated success, with statistically significant gains on DMU, TA, and ABZ over single-agent and lean multi-agent baselines.ALAS’s best-performing workflow variant achieves 100% optimal rate across all five benchmarks.Source: §4.1 · p. 8, Table 3 · p. 8, Table 4 · p. 9

4.1.1 BASELINE

• The baseline comparison covers four single-agent LLMs and four multi-agent systems under default API settings with temperature=1.0.The scheduling tasks introduce machine breakdowns and duration shocks while optimizing makespan and minimizing work-in-progress movement.Source: §4.1 · p. 8, §4.1.1 · p. 9

4.1.2 LCRP MECHANISM: A WHITE-BOX ILLUSTRATION

• 22 final makespan versus 19 baseline + 3 downtime, with one unit of WIP movement, demonstrates bounded queue reordering after a breakdown.LCRP first propagates local edits through logged dependencies, then applies bounded reordering with a WIP penalty and stops when further gains do not exceed cost.Source: §4.1.2 · p. 9, Figure 2 · p. 9, Figure 3 · p. 10

4.2 ABLATION STUDY

• Removing either validation or repair sharply reduces optimal rates, whereas the full workflow reaches up to 99.0–98.2% across backbones.The ablation injects 20 structural faults and compares Full (ALAS), No-Repair, and No-Validator conditions.Source: §4.2 · p. 10, Table 5 · p. 10

5 CONCLUSION

• ALAS achieves high feasibility and strong efficiency across transportation, event coordination, and job-shop scheduling while preserving work in progress and outperforming single-LLM baselines and competitive heuristics under disruption.Its core design principles are validator isolation, versioned execution logs, and localized cascading repair that limits disruptions to minimal neighborhoods.Source: §5 · p. 10

A.1 IR JSON SCHEMA (COMPLETE)

• Policies in Π make retry, backoff, timeout, catch, idempotency, compensation, and loop guards explicit, enforceable, portable to ASL and Argo, and auditable through execution logs.The policy contract supports transient-fault recovery, safe replay, termination of iterative loops, and parity across engines.Source: §A.1 · pp. 19, 20, 22, 23

A.4 ENGINE MAPPINGS AND ROUND-TRIP RULES

• IR-to-engine mappings define exact field correspondences, guard translations, and fallbacks, with round-trip tests checking preservation of types, ordering, and policy fields.The expanded mapping covers ASL and Argo materializations.Source: §A.4 · p. 23, Table 7 · p. 24

A.6 POLICY SEMANTICS AND IDIOMS

• Idempotency caches successful results or waits on pending executions, while compensation supports failure or cancellation recovery and loop guards bound iterations by maxIters or deadlineSeconds.Compensation handlers must be safe to re-invoke when the idempotency key is preserved.Source: §A.6 · pp. 23–24, Table 6 · p. 24

A.7 TYPED API REFERENCE

• The typed API exposes separate validate and repair operations, returning validity, constraint violations, warnings, and scoped error information.Constraint scopes may identify jobs, operations, machines, or edges.Source: §A.7 · p. 24

A.8 LOGGING AND OBSERVABILITY SPEC

• Structured observability records event taxonomy, versions, correlation IDs, redaction tags, and representative validation, repair, and compensation entries, while replay harnesses pin seeds and tools for exact reproduction and engine parity checks.The determinism harness also supports drift triage.Source: §A.8 · p. 24, §A.9 · p. 24, Table 8 · p. 25

A.10 FAULT MODEL AND INJECTION

• The fault model covers transient timeouts, tool failures, and logical constraint violations through labeled injection, while excluding resource exhaustion and Byzantine behavior.The injection API supports targeted violations.Source: §A.10 · p. 25

A.11 LCRP PSEUDOCODE AND GUARANTEES

• LCRP specifies neighborhood growth and termination under bounded retries and guards, and worked examples show end-to-end IR materializations in ASL or Argo with round-trip checks.The specification also identifies future work in optimization, adaptive telemetry-based repair, formal guarantees, validator soundness, and systematic red-team QA.Source: §5 · p. 10, §A.11 · p. 25, §A.12 · p. 25

A.13 EXPERIMENTAL PROTOCOLS

• The appendix identifies benchmark setup, disruption generators, hyperparameters, evaluation-harness details, dataset visualizations, and supplementary failure-rate statistics.These materials augment the core experiments with prompt specifications and supplementary visualizations.Source: §A.13 · p. 25, B ADDITIONAL JSSP RESULTS AND ANALYSIS · p. 25, §B.1 · p. 25

B.2 LLM PROMPT DESIGN

• ALAS transforms an initial LLM-generated workflow template through validation and refinement, then executes code-generated agents with runtime logging, disruption detection, and local repair.Standalone LLMs may produce invalid schedules, while ALAS validates the preliminary Wtemplate before instantiating Wexec and applying runtime repair.Source: §B.2 · p. 25, Table 9 · p. 27

B.2.1 COMMON JSSP QUERY STRUCTURE

• The shared JSSP query requires a valid schedule with minimum makespan while enforcing job precedence and non-overlapping machine operations.The prompt requests structured operation-level start, end, duration, and machine fields.Source: §B.2.1 · pp. 27–28

B.2.2 TESTING FRAMEWORK

• The testing framework assigns ALAS one job agent per job and a supervisor agent that coordinates schedules to find the minimum-makespan solution.The broader evaluation also compares AutoGen, CrewAI, LangGraph, and OpenAI Swarm using three-agent configurations.Source: §B.2 · p. 25, §B.2.2 · p. 28

B.3 AGENT PROMPTS

• The agent prompts explicitly require strict job-step precedence, exclusive machine use, and a complete schedule minimizing total completion time.The supervisor coordinates all job schedules under these constraints and returns a complete minimum-makespan schedule.Source: §B.3 · p. 28
• 88 constraint violations were identified while processing 244 schedule entries, after an initial schedule with makespan 665 was loaded for repair.The workflow proceeds through validation and repair, including cascading repair and queue reordering.Source: §B.3 · p. 30
• The cascading repair workflow identifies affected operations, fixes immediate constraints, repairs job precedence and machine capacity, then performs iterative improvement and final cleanup.The prompts explicitly organize repair into five phases, including machine-overlap resolution and invalid-operation-time correction.Source: §B.3 · pp. 30–32
• The third repair iteration fixed machine overlaps and invalid operation times before reducing the remaining constraint violations to 10.Reported fixes include overlaps on Machines 6, 0, and 1 and invalid times across multiple jobs and steps.Source: §B.3 · pp. 32–33
• Algorithm 3 completed each repair iteration by generating 244 schedule entries.The completion message appears after each of the three cascading repair runs.Source: §B.3 · pp. 30–32
• Errors fell from 88 to 10 across three repair iterations while the makespan remained 665.The reported reductions were 88 to 76, 76 to 28, and 28 to 10.Source: §B.3 · pp. 30–32
• Errors fell from 10 to 6 and then 2 after five repair iterations, while the makespan remained 665 and 244 schedule entries were generated.The repair completed with remaining errors, indicating partial rather than complete correction.Source: §B.3 · pp. 31–33
• Revalidation failed because Job2 violated precedence and Jobs18, 20, and 19 were missing, halting workflow execution and requiring global replanning.The replacement four-step workflow also failed, and manual intervention may have been required.Source: §B.3 · p. 33

B.3.1 AUTOGEN FRAMEWORK

• AutoGen configures three agents: a Job Scheduler for initial schedules, a Machine Coordinator for machine conflicts, and a Supervisor for final coordination and optimization.The example targets the 20-job abz07 job-shop scheduling problem.Source: §B.3.1 · pp. 33–34
• The AutoGen prompt requires a final makespan and structured per-operation machine, start-time, end-time, and duration fields, while resolving conflicts through rescheduling or compatible-machine reassignment.The scheduler instructions also call for data collection, job prioritization, machine-availability checks, and overlap detection.Source: §B.3.1 · pp. 34–35
• AutoGen coordinates job scheduling and machine usage around precedence and non-conflict constraints, with an illustrative abz07 schedule described as near-optimal but lacking an exact makespan.The example includes machine-level start and end times, but the reported makespan is not numerically specified.Source: §B.3.1 · p. 35

B.3.2 CREWAI FRAMEWORK

• CrewAI uses three role-based agents: a Job Scheduler, Machine Coordinator, and Supervisor who aggregates schedules and coordinates agents toward an optimal JSSP solution.The Machine Coordinator resolves overlaps and optimizes utilization before the Supervisor calculates the final makespan and structured schedule.Source: §B.3.2 · pp. 35–36

B.3.3 LANGGRAPH FRAMEWORK

• LangGraph uses Job Scheduler, Machine Coordinator, and Supervisor agents whose workflow targets minimum makespan while enforcing job precedence and machine constraints.Its simplified schedule is explicitly conceptual rather than the actual solution, and the workflow iteratively evaluates schedules while retaining the best makespan.Source: §B.3.3 · pp. 36–37

B.3.4 OPENAI SWARM FRAMEWORK

• OpenAI Swarm uses three agents—a Job Scheduler, Machine Coordinator, and Supervisor—for a job-shop scheduling problem with 20 jobs and 15 machines.Source: §B.3.4 · pp. 37–38
• OpenAI Swarm schedules each operation at the earliest feasible time satisfying job precedence and machine availability constraints.The procedure identifies operations and dependencies, sequences them by job and machine, and maintains machine calendars to prevent conflicts.Source: §B.3.4 · p. 39
• The framework finalizes schedules by avoiding machine overlaps, enforcing dependencies, and defining makespan as the latest operation end time.It illustrates precedence with Job1 operations scheduled from time 0 to 24 and then from 24 to 36; a preliminary example yields 1200 time units.Source: §B.3.4 · p. 39
• The example output lists concrete operation records, including Job1’s machine assignments and corresponding start, end, and duration values.The example gives Job1 Step 1 on Machine2 from 0 to 24 and Step 2 on Machine3 from 24 to 36.Source: §B.3.4 · p. 39
• The required output reports a final makespan followed by every operation’s job, step, machine, start time, end time, and duration.The format is standardized across frameworks and continues through all operations.Source: §B.3.4 · pp. 39–40

B.4 LLM HEURISTIC BASELINES (SAMPLED)

• Standalone LLMs propose an optimization method, hyperparameters, and expected makespan, but produce only a static Wtemplate requiring later validation, refinement, agent instantiation, and runtime adaptation.Table 10 samples five instances per model; full tables are in the supplement.Source: §B.4 · p. 40, Table 10 · p. 40

B.5 ADDITIONAL EXPERIMENTAL RESULTS AND ANALYSIS

• Execution time, token usage, and cost are reported as averages across five benchmarks in Tables 11–13, with supplementary comparison summaries in Table 14.The cited tables provide the appendix’s breakdowns for runtime, tokens, cost, and overall MAS-versus-ALAS averages.Source: §B.5 · p. 40, Table 11 · p. 41, Table 12 · p. 41

B.6 ALAS’S VALIDATION REPLAN ITERATIONS

• Up to 5 validation-replan iterations typically suffice to converge from an initial Wtemplate to a valid plan across all benchmark datasets.Figure 5 reports the error rate for each repair iteration.Source: §B.6 · p. 40, Figure 5 · p. 42

C SUPPLEMENTAL INFORMATION FOR SECTION 3

• The three-layer architecture prepares agent specifications after Phase 1, implements them in Phase 2, and instantiates them as real-time processes in Phase 3, with persistent memory supporting validation and recovery.Figure 6 depicts the layered architecture and persistent-memory role.Source: C SUPPLEMENTAL INFORMATION FOR SECTION 3 · p. 40, Figure 6 · p. 43

C.1 COMPLETE META-PLANNER ALGORITHM FOR WORKFLOW GENERATION

• The meta-planner constructs roles, nodes, dependencies, invariants, log schemas, agent specifications, repair specifications, and an independent bounded-context validator before refining Wtemplate until structural, constraint, and repair-coverage checks pass.The algorithm separates blueprinting, factory preparation, and validation-refinement while enforcing planner–validator non-circularity.Source: §C.1 · p. 42

C.2 AGENT FACTORY IMPLEMENTATION DETAILS; C.2.1 AGENT FACTORY OVERVIEW

• The Agent Factory translates formal specifications into executable implementations through discovery first and custom coding when no suitable implementation is found.The overview defines the two-stage factory process.Source: §C.2.1 · p. 43

C.2.2 AGENT DISCOVERY PROCESS

• Discovery searches repositories, directories, libraries, and domain collections, scores candidates against capability, protocol, efficiency, context, and logging requirements, then verifies and registers compatible implementations.Exact matching requires all parameters; approximate matching permits partial capability matches with adaptation mechanisms.Source: §C.2.2 · pp. 43–44

C.2.3 AGENT CODING MECHANISM; C.2.4 COMPENSATION AGENT GENERATION; C.2.5 DEPLOYMENT ARTIFACT PRODUCTION

• When discovery fails, coding translates specifications into implementation briefs, selects compatible LLMs, generates logged and protocol-aware code, validates it, and may iteratively refine complex agents.Compensation agents additionally derive reversal strategies and recovery sequences covering every state-modifying operation, while deployment artifacts may be code, prompts, API configurations, or hybrids with execution, interface, persistence, monitoring, and recovery metadata.Source: §C.2.3 · p. 45, §C.2.4 · p. 45

C.2.6 FACTORY DESIGN PATTERN IMPLEMENTATION

• The Agent Factory standardizes agent instantiation while encapsulating implementation selection, generation, and validation complexity.This interface decouples agent specifications from implementation details and supports heterogeneous implementation technologies.Source: §C.2.6 · p. 46
• The Factory supports runtime agent substitution for recovery or optimization and maintains a growing repository of reusable components.These capabilities allow implementation strategies to evolve without changing meta-planning or runtime components.Source: §C.2.6 · p. 46
• The Factory adapts to new implementation technologies and approaches without requiring changes to ALAS meta-planning or runtime components.This creates an architecture that can evolve its agent implementation strategies over time.Source: §C.2.6 · p. 46

C.2.7 IMPLEMENTATION EFFICIENCY CONSIDERATIONS

• Caching, component reuse, incremental refinement, and resource scaling reduce redundant generation and allocate resources according to agent complexity and criticality.Incremental refinement generates similar-agent variants from deltas, while reusable components support sharing across agents.Source: §C.2.7 · p. 46
• These optimizations significantly reduce agent-generation overhead when multiple similar agents are needed or recurring workflow patterns are executed.The efficiency benefits arise from avoiding redundant generation and reusing prior implementations or components.Source: §C.2.7 · p. 46

C.2.8 THEORETICAL FOUNDATIONS

• The Factory is grounded in program synthesis, component-based software engineering, LLM prompt engineering, and agent-oriented software engineering.These frameworks cover specification-driven generation, component composition and reuse, structured prompting, and autonomous-agent development.Source: §C.2.8 · p. 46
• Together, these foundations provide a rigorous basis for transforming abstract agent specifications into concrete, executable implementations.The theoretical grounding connects the Factory’s implementation process to formal generation, reuse, prompting, and agent-development methodologies.Source: §C.2.8 · p. 46

D ALGORITHM, LEMMA, AND THEORY PROOFS

• LCRP’s operational repair cost is dominated by status updates, delay propagation, queue optimization, and cascading delays across jobs, operations, and machines.The practical bound is O(SJOmax) when swaps are limited to S evaluations, while cascading delay handling contributes O(JMOmax).Source: D ALGORITHM, LEMMA, AND THEORY PROOFS · p. 47
• Special cases yield O(J2/M + JM) for single-operation jobs and O(SJOmax + JMOmax) for swap-limited implementations.The stated complexity is quadratic in job count and operations, while machine count affects both delay accumulation and parallelization; swap heuristics can improve practical bounds.Source: D ALGORITHM, LEMMA, AND THEORY PROOFS · p. 47
• LCRP repair feasibility is strongly NP-hard, even when repairs are constrained by a bounded edit budget.The decision problem asks whether a schedule can be made feasible and achieve Cmax(σ) ≤ K using at most R local edits; hardness follows by embedding JSSP, and bounded-edit variants remain hard.Source: D ALGORITHM, LEMMA, AND THEORY PROOFS · pp. 47–48
• The LCRP hardness proof reduces JSSP by using the same instance, an empty or infeasible initial schedule, a repair budget at least the number of operations, and the same makespan bound.A feasible JSSP schedule can be reached through permitted local edits, while any feasible repaired schedule satisfying K is also a valid JSSP schedule.Source: D ALGORITHM, LEMMA, AND THEORY PROOFS · pp. 47–48
• The NP-hardness result concerns global makespan-target repair decisions, whereas the operational complexity bound describes worst-case effort for a single LCRP run.Thus polynomial per-iteration costs do not make the global repair-existence problem tractable in general unless P = NP.Source: D ALGORITHM, LEMMA, AND THEORY PROOFS · p. 48

E APPLICATION 1: URBAN RIDE ASSIGNMENT PROBLEM

• ALAS applies the planning framework to urban ride assignment over a city graph, ride requests with pickup and drop-off windows, and vehicles constrained by location, battery or fuel, and passenger capacity.The objective is to assign requests to autonomous or human-driven vehicles while satisfying the stated constraints and objectives.Source: E APPLICATION 1: URBAN RIDE ASSIGNMENT… · pp. 48–49

E.1 A SIMPLIFIED URS PROBLEM STATEMENT

• The worked example uses a URS instance with three drivers and four passengers, then generates a planning template Wtemplate as the starting point for the planner W* walkthrough.Table 29 supplies the simplified problem statement, while Table 15 lists agent specifications and protocols for the walkthrough context.Source: §E.1 · p. 49, §E.2 · p. 49, Table 15 · p. 49

E.2.1 STATE-SPACE ANALYSIS

• ALAS models URS with seven locations, four airport-bound passengers, three two-seat vehicles, deadline constraints, travel times, resource limits, and distance-minization objectives.Urban links are 10 km at 60 km/h, while airport routes are 31–36 km at 100 km/h, requiring 10- or 19–22-minute travel times.Source: §E.2.1 · pp. 49–50

E.2.2 PHASE 1: NETWORK CONSTRUCTION

• The planning network represents passenger, vehicle, and location nodes, linking them through temporal, spatial, and capacity dependencies for feasible assignments and shared rides.Temporal constraints are computed backward from airport deadlines, while capacity edges enforce vehicle passenger limits.Source: §E.2.2 · p. 50

E.2.3 PHASE 2: AGENT ASSIGNMENT

• Specialized agents divide route planning, scheduling, capacity management, temporal constraints, resource allocation, distance optimization, and passenger grouping across the workflow.This assignment separates task-specific optimization from cross-cutting dependency and relationship management.Source: §E.2.3 · p. 50

E.2.4 PHASE 3: VALIDATION AND REFINEMENT

• Validation checks deadline feasibility, vehicle capacity, passenger service, and resource allocation, then refines compatible groupings and assignments before generating buffered routes with disruption contingencies.The example groups r2 and r3 when their pickup locations are close and arrival times are within 5 minutes.Source: §E.2.4 · pp. 50–51

E.3 FROM WORKFLOW TEMPLATE TO EXECUTION WORKFLOW

• ALAS transforms an abstract workflow template Wtemplate into a concrete execution workflow Wexec that resolves roles, incorporates real-world data, and continuously updates actions and dependencies.Wexec maps abstract drivers and passengers to real instances while adapting to traffic, vehicle availability, and passenger delays.Source: §E.3 · p. 51

E.3.1 OBSERVATION ON SEQUENTIAL PLANNING

• Agent specialization supports dynamic, distributed, modular, and resilient operation by enabling parallel decisions, component upgrades, and fallback refinement when conditions or agents change.The motivation is especially relevant to larger ride-sharing systems with continuous requests, delays, and changing road conditions.Source: §E.3.1 · p. 52

E.4 REACTIVE PLANNING UNDER DISRUPTIONS

• Under disruptions, ALAS locally and concurrently updates affected routes, schedules, and vehicle assignments, preserving workflow stability; in the URS case, it handles cancellation and request insertion while baseline LLMs lose state consistency.The disruption example cancels r2 at 8:05 and adds r5 at location F at 8:10, with ALAS preserving passenger deadlines.Source: §E.4 · pp. 52–53

F APPLICATION 2: FAMILY REUNION PLANNING PROBLEM

• The family-reunion application assigns role and dependency monitors, combines agent-collected operational constraints with human social and personal input, and uses continuous threshold-based monitoring for dynamic adjustment.Monitors cover cooking, driving, supervision, resources, timing, spatial relations, and safety; temporal status is normal, warning, or violation based on schedule deviation and buffers.Source: §F.1.1 · p. 53, §F.1.2 · p. 53, §F.2.1 · p. 54

F.4 MONITORING PROTOCOLS AND DYNAMIC ADJUSTMENTS

• Dynamic adjustments detect deviations, assess their effects, evaluate reassignment options, verify safety coverage, and update the workflow while preserving global constraints.The meta-planner coordinates spatial, temporal, role, and safety responses when disruptions occur.Source: §F.4 · pp. 56–57

F.5 INTEGRATED WORKFLOW NETWORK

• The integrated workflow network assigns agents and protocols to cooking, driving, supervision, temporal dependencies, spatial travel, and safety coverage.The network W∗ includes role nodes, dependencies, and monitoring responsibilities, including continuous oven supervision while the turkey cooks.Source: §F.5 · p. 57

F.6 AGENT INTERACTION SPECIFICATIONS

• Agent interaction protocols and state transitions are specified in Table 20 for the integrated workflow.The supplied passage identifies Table 20 as the source for these protocols and transitions but does not provide its cell contents.Source: Table 20 · p. 57

F.7 AUGMENTED PROBLEM STATEMENT REVISED WITH W*

• The revised problem statement fixes a 6:00 PM dinner, specifies travelers and Grandma’s pickup, and adds timing, preference, cooking, traffic, dependency, idle-time, and schedule-format constraints.It requires strict task completion by dinner and represents the schedule with time, task, and assigned-person columns; listed assumptions include 30-minute luggage pickup and car rental times, one-person cooking, and no traffic modeling.Source: §F.7 · pp. 57–58

F.8 EXPERIMENT #1: SEQUENTIAL PLANNER WITH COMMON SENSE

• ALAS and Gemini consistently generated feasible schedules, whereas the other evaluated standalone LLMs encountered significant challenges under realistic luggage-claim and rental-car constraints.The experiment used an augmented problem specification incorporating common-sense constraints such as luggage claim and rental-car pickup time.Source: §F.8 · p. 58
• DeepSeek outperformed GPT4o and Claude on slack time, total driving distance, and load balance by having James wait at the airport for Emily.Claude sent James home before returning to the airport, while GPT4o assigned Michael separate pickups, producing unnecessary travel and poorer load distribution.Source: §F.8 · p. 58, Table 22 · p. 59, Table 23 · p. 59

F.8.1 OBSERVATIONS OF ERRORS IN STANDALONE LLMS

• Although DeepSeek and Claude reached feasible plans in their second iterations, their initial attempts contained wrong travel-time estimates and implausible scheduling decisions.Reported errors included treating 60-minute trips as 45 or 30 minutes, starting turkey preparation at 10 AM, and letting James leave without Emily.Source: §F.8.1 · p. 59, Table 24 · p. 59, Table 25 · p. 59
• Extended-context erosion and overlapping dependencies cause standalone LLMs to lose constraints and generate cascading errors during complex scheduling; Liu et al. (2024), Xiao et al. (2024).Extended contexts accelerate information loss, while cognitive limits make simultaneous tracking and exhaustive verification difficult; Park et al. (2023), Wei et al. (2023).Source: §F.8.1 · p. 59
• ALAS addresses these failures by isolating domain-relevant processing, enumerating atomic dependencies, independently validating global constraints, and resolving conflicts systematically.The proposed solution framework emphasizes dependency isolation, comprehensive verification, and robust conflict resolution.Source: §F.8.1 · p. 59
• Iterative revisions can propagate stale errors because incomplete constraint resets preserve previous mistakes, making clean-state re-evaluation necessary for cross-iteration consistency.The implementation strategy resets each iteration to a clean baseline and re-evaluates constraints, while managing nested dependencies and residual errors.Source: §F.8.1 · pp. 59–60
• ALAS consistently generated feasible and efficient plans in all test runs, outperforming inconsistent standalone LLM performance in the summarized sequential-planning comparison.DeepSeek required two iterations, GPT4o three, and Claude two; GPT4o and Claude produced redundant travel despite eventual feasibility.Source: §F.8.1 · p. 60, Table 26 · p. 60

F.9 EXPERIMENT #2: REACTIVE PLANNER FOR FLIGHT DELAY

• The reactive-planning prompt required updating the schedule after James’s flight was delayed until 4:00 PM while meeting a 6:00 pm deadline and all constraints.James was assigned to pick up Emily in the stated disruption scenario.Source: §F.9 · p. 60
• ALAS generated a feasible reactive plan, whereas DeepSeek and Claude 3.7 failed the disturbance-handling test.Only ALAS, DeepSeek, and Claude 3.7 were tested because they survived sequential planning.Source: §F.9 · p. 60
• DeepSeek and Claude failed in seven of ten runs through taxi assignments, missed pickups, or missed dinner deadlines.These failures violated family pickup constraints, delayed or missed Grandma’s pickup, or missed the 6:00 pm deadline.Source: §F.9 · p. 60
• ALAS remained feasible in all runs by persisting James’s state, detecting conflicts, evaluating alternatives, and validating constraints.Following the Local Reactive Compensation Protocol, ALAS produced four distinct feasible solution patterns.Source: §F.9 · p. 60
• 2.5× computation time—12.1s versus 4.8s—was the cost of ALAS’s feasibility guarantee in the time-sensitive disruption scenario.The reported overhead is presented as important for ensuring feasibility.Source: §F.9 · p. 60

G ADDITIONAL CASE STUDIES AND ANALYSIS

• ALAS rerouted Michael directly to Boston Airport instead of stopping at home, a spatial adjustment attributed to MP’s state-aware reasoning.The case study describes this as a common-sense adjustment overlooked by the other LLMs.Source: G ADDITIONAL CASE STUDIES AND ANALYSIS · p. 60
• Table 27 presents an example failed reactive schedule in which Grandma was not picked up despite the family being ready for dinner.The example is described as one of the concealed-LLM failure schedules.Source: §F.9 · p. 60, Table 27 · p. 61

Unresolved limitation

• Under the stated constraints, Grandma cannot join the 6:00 PM dinner because James and Michael cannot complete the required pickup routes, while Sarah supervises the oven.Source: P OST 6:00 PM · p. 61

Reactive plan

• ALAS’s optimized reactive plan uses persistent state history and compensation to produce a feasible schedule and preserve the on-time family reunion.The plan is presented in Table 28 and relies on continuous tracking of each participant’s state and history.Source: P OST 6:00 PM · p. 61, Table 28 · p. 61
• After collecting Emily, Michael proceeds directly to Grandma’s house, trimming roughly 30 minutes of travel and enabling two grandchildren to arrive together.Source: P OST 6:00 PM · p. 61

G.1 CASE STUDY 1: TRANSPORTATION SCHEDULING

• 95.1±13.0 km versus 118.9±16.6 km for baseline LLMs, a 20% improvement (p < 0.01), while all models met deadlines in sequential ride-sharing planning.ALAS also repaired every reactive ride-sharing run after a cancellation and new passenger, whereas baseline LLMs commonly lost state, duplicated assignments, or ignored updated deadlines.Source: §G.1 · p. 62, Figure 7 · p. 62

G.2 CASE STUDY 2: EVENT COORDINATION

• ALAS produced feasible family-reunion schedules in all runs, while baselines frequently violated hard constraints; under a flight delay, DeepSeek and Claude failed in 7/10 runs, but ALAS succeeded in all runs via LCRP.LCRP logs state, detects conflicts, tests alternatives, and re-validates locally; ALAS also confines context per agent and uses an independent validator, addressing arithmetic, commonsense, and long-context failures.Source: §G.2 · pp. 62–63

H.1 INTRODUCTION AND MOTIVATION

• ALAS’s custom JSON format limits interoperability, tooling, validation, documentation, observability, and explicit compensation or idempotency contracts, motivating standards adoption.The proposed canonical IR consolidates plan and state while preserving explicit retries, timeouts, backoff, idempotency keys, compensation handlers, and loop guards for conversion.Source: §H.1 · p. 63

H.2 TAXONOMY

• The orchestration taxonomy distinguishes standards/spec-first runtimes—Argo Workflows, ASL, and BPMN 2.0—from code-first durable engines including Temporal or Cadence, Flyte, Dagster or Prefect, and Netflix Conductor.Standards offer interoperability and mature tooling, while explicit semantics support more deterministic retry and replay.Source: §H.2 · p. 63, §H.1 · p. 63

H.3 STANDARDS: SURVEY AND TRADEOFFS

• Argo provides Kubernetes-native scaling, fan-out/fan-in, and mature logs, but requires Kubernetes and RBAC, makes dynamic graphs verbose, and lacks built-in compensation; ASL aligns with the IR and supports Retry/Catch but is AWS-centric.BPMN offers clear diagrams and compensation-event mapping, but XML stacks are heavy and dynamic plans need extensions; diagram/runtime drift is also possible.Source: §H.3.1 · p. 64, §H.3.2 · p. 64, §H.3.3 · p. 64

H.4 CODE-FIRST ENGINES: SURVEY AND TRADEOFFS

• Code-first engines provide durable state and runtime control-flow changes; Temporal or Cadence is suited to disruption-heavy workflows through durable activities, signals, timers, sagas, cancellation, and retry.Flyte supports Python-first dynamic tasks and conditionals but still requires Kubernetes; Dagster or Prefect offers dynamic mapping and retries, while DAG focus can limit state-machine repair.Source: §H.4 · p. 64, §H.4.1 · p. 64, §H.4.2 · p. 64

H.5 KEY COMPARISONS

• The engine comparison evaluates spec-first and code-first options across six axes, including control model, dynamic replanning, durable waits, signals and timers, error and compensation, and hosting model.The comparison also includes REALM-Bench cases against workflow engines, while the supplied tables mark favorable choices and summarize engine tradeoffs.Source: §H.5.1 · pp. 64–65, Table 31 · p. 65, Table 32 · p. 65

H.6 RECOMMENDATION FOR ALAS

• ALAS adopts Temporal as the primary control plane for workflow state, timers, signals, and local repair, invoking Argo for very large Kubernetes parallelism before resuming Temporal control.Temporal is preferred for modest parallelism, rich branching, or human waits; Argo is preferred for large container fanout, GPU pools, or heavy artifact movement, while ASL and BPMN remain for portability analysis.Source: §H.6 · pp. 65–66

H.7 IMPLEMENTATION ARCHITECTURE; H.8 CONVERTER NOTES

• The ALAS IR connects standards and engines through explicit policy and data-shape layers, with conversions mapping retries, catches, timeouts, idempotency, compensation, and loop guards.BPMN conditions should use formal expressions, while CWL conditions and requirements must match the declared version.Source: §H.7 · p. 66, Figure 8 · p. 66, §H.8 · p. 66

I.1 GOAL; I.2 PREREQUISITES

• The end-to-end goal is to run a local Temporal Server, one ALAS worker, and a client that starts a JSSP workflow and prints JSON.The example assumes macOS on Apple Silicon, Python 3.11, Homebrew, and the Temporal Server CLI.Source: §I.1 · p. 66, §I.2 · pp. 66–67

I.3 DIRECTORY LAYOUT; I.4 SET UP THE PYTHON ENVIRONMENT

• The project uses an alas-temporal directory, a Python 3.11 virtual environment, and pinned temporalio==1.7.0, pydantic==2.8.2, and rich==13.7.1 dependencies.The layout includes worker.py, requirements.txt, and .venv/.Source: §I.3 · p. 67, §I.4 · p. 67

I.5 CODE FILES; I.8 WHAT THE CODE ACTUALLY DOES •

• The worker runs solve_jssp, computes a sequential schedule and makespan, and returns a JSON verdict of pass when makespan is greater than zero.The workflow invokes one activity with a 30-second start-to-close timeout, while the activity is explicitly a placeholder for a real scheduler.Source: §I.5 · pp. 67–68, §I.8 · p. 70

I.7 EXECUTION FLOW; I.8 WHAT THE CODE ACTUALLY DOES •

• Execution flows from the client through Temporal persistence and task dispatch to the worker and solve_jssp activity, then returns the schedule and verdict as formatted JSON.The activity walks operations in order and assigns contiguous start and end times, making the schedule naive rather than a full scheduler.Source: §I.7 · pp. 69–70, §I.8 · p. 70

I.9 OBSERVED PITFALLS AND FIXES •; I.10 REPEATABLE CHECKLIST

• The appendix documents fixes for shell-comment parsing, zsh virtual-environment activation, missing Temporal storage paths, and incorrect start_workflow argument syntax.The repeatable checklist is to create files, install dependencies, start the server and worker, run the client, capture JSON, and inspect the Web UI.Source: §I.9 · p. 70, §I.10 · p. 70

I.11 NEXT STEPS

• Next steps replace the naive activity with real planner, validator, and executor modules, add validation and repair branches, and persist results with searchable Temporal attributes.The proposed extension adds multiple activities and workflow branches for validate and repair, plus file-store or database persistence.Source: §I.11 · p. 70