Public technical case study
AeroOps: a custom runtime for disruption recovery workflows.
I built AeroOps as a public custom TypeScript runtime for airline disruption recovery: model-driven tool use inside explicit routing, structured state, recoverable execution, and evaluation.
Scenario
AO117, a synthetic disruption scenario 90 minutes before departure involving an aircraft nose-gear steering fault.
Evidence snapshot
Verified commit 8b481d23ae, evidence snapshot 2026-06-05.
62
registered tools
8
tool namespaces
7
scoped operational subagents
Explicit
runtime boundary
01 / Problem and constraints
Disruption recovery needs judgment, but the execution path still has to be inspectable.
AO117 is a synthetic airline disruption scenario set 90 minutes before departure. The aircraft has a nose-gear steering fault, so the workflow must reason about an operational problem while keeping every tool call, state transition, and terminal outcome visible.
The constraint is not simply “let a model solve it.” The runtime needs to support model-driven choices without giving up typed boundaries, bounded delegation, checkpointing, retries, rate limits, and a clear path to recovery or failure.
This page describes the public runtime and its synthetic scenario. It does not claim production airline deployment or access to real airline operations data.
02 / Why a custom runtime
The runtime is the product boundary around model behavior.
AeroOps keeps the model useful for open-ended decisions while making the surrounding system explicit. Tools are registered, execution is routed through a graph, state is checkpointed, and failures are represented as typed outcomes that the caller can inspect.
That boundary also makes the system provider-flexible. Gemini, Claude, and hosted modes can sit behind adapters while the runtime keeps its own contracts for tool calls, state, traces, replay, and evaluation.
Model flexibility
Adapters keep provider choice separate from runtime control.
Runtime control
Routing and state make execution legible and recoverable.
Evidence loop
Replay and evaluation turn long-horizon behavior into something testable.
03 / Architecture and system boundaries
A visible path from decision to response or failure.
This is a custom HTML/Tailwind architecture visual based on the public runtime concepts. It is intentionally not a screenshot or an invented system diagram.
Model decision
Provider adapters support the model-decision path, where the model selects the next tool or response from the available operation surface.
Registered tool execution
Registry validation and typed inputs constrain registered tool execution; retries, rate limits, and typed runtime errors keep failures explicit.
State / artifacts
AgentContext, checkpoints, tool results, and generated artifacts are carried forward.
Explicit routing
The explicit router sends successful tool execution back to model decision, while planning tools perform delegation.
Terminal handling
Final responses and failure outcomes move to explicit, inspectable terminal handling.
AgentContext
Structured state and checkpointing carry the workflow between operations.
Registered surface
62 tools across 8 namespaces define the operations the runtime can call.
Operational boundary
7 scoped subagents delegate bounded work without hiding the main graph.
04 / Agentic versus deterministic decisions
Use the model for judgment; use the runtime for boundaries.
Agentic decisions
The model chooses tools and adapts to open-ended operational context. Scoped subagents can handle bounded responsibilities when the graph delegates work.
Deterministic boundaries
Registration, typed inputs and errors, retries, rate limits, checkpointing, routing, and terminal outcomes stay explicit and testable.
05 / Failure handling and recovery
Recovery is part of the execution model, not an afterthought.
The public runtime makes the failure surface visible around tool use and long-running workflows. A failed operation can be represented, traced, retried where appropriate, or routed to an explicit terminal outcome instead of disappearing inside a model loop.
Retries and rate limits
Execution controls protect the runtime boundary when tools or providers are unavailable.
Typed errors
Failures remain structured so callers and routes can distinguish recoverable work from terminal outcomes.
Checkpointing
AgentContext and checkpoints support resumable state across a workflow.
Streaming traces
Execution can be inspected through streaming traces and JSONL observability output.
06 / Evaluation and replay
Long-horizon behavior needs a replayable evidence loop.
AeroOps includes deterministic replay and live-model evaluation for long-horizon workflow completion. The point is to make a multi-step run inspectable after the fact, then use that record to reason about routing, tool selection, state, and terminal outcomes.
Record
Streaming traces and JSONL keep the execution history available for inspection.
Replay
Deterministic replay makes a prior workflow available without relying on a fresh model decision.
Evaluate
Long-horizon evaluation exercises whether the workflow completes across many steps.
07 / Public evidence and intentionally omitted scope
Inspect the implementation, then read the boundary around the claim.
Model-driven tool selection across a registered operation surface.
62 tools organized across 8 namespaces.
7 scoped operational subagents for bounded delegation.
Explicit graph routing instead of an opaque free-running loop.
Structured AgentContext and checkpointing for resumable execution.
Retries, rate limits, and typed errors around tool execution.
Streaming traces and JSONL output for inspectable observability.
Provider adapters for Gemini, Claude, and hosted modes.
Public boundary
No production airline deployment is claimed.
AO117 is synthetic; it is not presented as real airline data.
No private company repositories, customer information, or internal dashboards are included.
No business outcomes, operational savings, or reliability metrics are inferred from the public code.