What happened
Airbnb’s announcement says Skipper is now available under the Apache 2.0 license. The open-source release includes the core engine, MySQL and SQLite adapters, test utilities and an admin UI. Skipper is designed for Java and Kotlin services that need to coordinate processes spanning multiple steps, services or human decisions. Developers express a workflow as a class and its orchestration logic; separate actions perform work that may have side effects, such as calling an API or updating a database.
The architectural choice is to run the workflow runtime and scheduler in the service’s own replicas. Replicas typically share a database containing workflow state and scheduled work. The scheduler polls for runnable tasks and uses leases to coordinate ownership. If one replica fails, another can take over; the timing depends on scheduling and lease settings. The workflow can execute directly in the service process rather than round-tripping through an external orchestration service between actions. Airbnb presents this as a way to avoid operating another shared system and to keep workflow ownership within each service.
Skipper’s workflow code can wait without holding a thread. In Airbnb’s example, a listing publication workflow waits up to a day for a review signal, then either publishes the listing and notifies its host or returns a negative result. A redeploy during the wait does not discard persisted workflow state. Java and Kotlin share the programming model, and the release includes Java, Kotlin, Spring Boot and Dropwizard examples. The WorkflowTest utility provides an isolated in-memory runtime with controllable time, allowing tests of waits, signals, retries and completion with fakes for downstream collaborators.
Recovery works by replay: Skipper starts an interrupted workflow method from the top, returning saved results for actions whose checkpoints were persisted and continuing through the remaining steps. That means orchestration code must remain deterministic and compatible with replay. Clock reads, randomness and I/O belong in actions or explicit checkpoints, not directly in workflow logic. Checkpoints are batched by default until completion or a pause for a wait or retry, reducing database writes. A crash before the batch is saved can cause completed actions to run again; actions may request immediate checkpointing to reduce that window.
The announcement stresses that persisted workflow state does not make external side effects transactional. A downstream effect and its checkpoint are not one atomic operation, so actions must make side effects idempotent—for example, by deduplicating publication and notification separately with a stable request ID. Developers also define retryable errors and retry policies. Permanent failures and exhausted retries are surfaced for handling, and exhausted scheduler recovery attempts can require manual intervention. Skipper supports Saga-style compensation for processes that need recovery actions for completed steps. Airbnb says the release also includes signals, queries, retries, compensation, workflow-evolution primitives and Skipper State Machine, a Kotlin DSL for state- and event-driven processes.
What the archive adds
New Runtime’s earlier coverage includes CASTLE and Airbnb’s search cold-start work (2026-10-16) and Airbnb’s production classifier benchmark (2026-11-04). Those were separate Airbnb engineering stories, not prior coverage of Skipper. This is a new event and a new thread on how Airbnb structures durable service workflows.
Trend signal
This release supports harness architecture outlives model choice: a durable execution layer can matter independently of which model or component performs individual tasks. The connection is indirect—Skipper is a general workflow engine, not specifically an AI-agent harness—but it illustrates how runtime, state and recovery shape the capabilities of systems built on top.
Why now
Airbnb says Skipper is already in production across teams and is now available to the open-source community. Its stated next areas of exploration include additional storage plugins such as Postgres and DynamoDB, plus better workflow-evolution and replay-debugging tools. Those are plans, not released capabilities.
Why it matters
For teams building AI-enabled services, long-running workflows often combine model calls with database updates, external APIs, timers and human review. Skipper offers a way to persist that orchestration inside a Java or Kotlin service rather than introducing a separate workflow cluster. This may simplify deployment topology and remove an orchestration round trip from the normal execution path.
The trade is not simply “fewer systems.” The service team inherits responsibility for database capacity, scheduling, retries and recovery. Replay also makes workflow code and action boundaries part of the reliability design: nondeterministic behavior must be kept out of orchestration, and downstream effects must tolerate retries. Teams should compare those responsibilities with the operational burden of a centralized workflow engine, rather than judging fit from the embedded architecture alone. Skipper is most relevant where a JVM service already owns a durable process and the team has the operational maturity to run it.
What happens next
- Airbnb will explore additional storage plugins, including Postgres and DynamoDB (6 months, 65%). Watch for: an official Skipper release or documentation announcing a new adapter.
- Replay debugging and workflow-evolution tooling will remain active development areas (6 months, 60%). Watch for: a release adding migration assistance or replay visualization.
Limits and uncertainty
Airbnb describes Skipper as used in production across its teams, but the announcement gives no deployment count, throughput, latency, availability or comparative operational-cost measurements. It does not quantify the database load or the conditions under which lease-based takeover succeeds. The release’s MySQL and SQLite adapters are named; other storage integrations are only areas Airbnb plans to explore. The announcement is the company’s account of its own system, not an independent evaluation. Teams would need to test replay compatibility, recovery behavior and database capacity against their own workloads.
Skill to build now
Take one existing multi-step process and draw its durable boundary: list each step, external side effect, wait, retry condition and human decision. Then mark which operations can safely run more than once and how they are deduplicated. This exercise directly exposes the replay and idempotency requirements that Skipper’s model makes explicit, even if you ultimately choose a different workflow engine.
Reader takeaway
Skipper trades a separate orchestration tier for workflow execution inside the service that owns the process. That can reduce infrastructure, but it does not remove the hard parts of durable work: deterministic replay, idempotent side effects, database capacity and recovery remain the service team’s job.