Quarkus Flow 1.0 embeds durable agent workflows inside Java applications

Quarkus Flow has reached 1.0, giving Quarkus applications an embedded workflow engine for deterministic service orchestration and agentic AI pipelines. The release announcement describes this as the project’s first stable version and says it implements the CNCF sandbox Open Workflow Specification.

What changed

Unlike workflow platforms that require a separate control service or worker fleet, Quarkus Flow runs inside the Quarkus application. Teams can define workflows declaratively in Open Workflow Specification YAML or use the project’s fluent Java FlowDSL. The Java task catalog covers HTTP requests, function calls, emitted and consumed events, branches and agent tasks.

The agent integration is built around LangChain4j. A workflow can inject a registered AI service and place that agent call alongside conventional steps such as fetching data, branching, retrying or waiting for a human decision. Quarkus says the engine handles sequencing, state passing and threading around those steps.

Version 1.0 also connects to SmallRye Reactive Messaging so workflows can emit and consume CloudEvents over supported connectors such as Kafka and AMQP. For longer-lived execution, state can be checkpointed through JPA, embedded MVStore or Redis. A Kubernetes extension uses Leases to coordinate workflows that must survive pod restarts.

Who should care

The release is aimed at Java teams that want agent calls to live inside a more controlled application workflow rather than an unstructured chain of prompts. That matters when an AI step must be surrounded by ordinary integration logic, approval events, retries and recoverable state.

The operational pieces are unusually broad for a first stable release. OpenTelemetry traces cover workflow instances and task executions, Micrometer can expose execution metrics, and an OIDC extension negotiates OAuth2 tokens for downstream calls. The extension stack, including messaging, persistence and gRPC tasks, can also compile to a GraalVM native image.

What to do

Developers can trial a prebuilt runner or add io.quarkiverse.flow:quarkus-flow through the Quarkus CLI. Before adopting it for production orchestration, teams should match the persistence option to their recovery requirements and test how Kubernetes Lease coordination behaves under their deployment topology.

The published roadmap also marks several boundaries of 1.0. Native MCP and A2A client tasks, a REST endpoint for managing running instances, a dedicated testing extension and a clustered Quartz scheduler are future work rather than current capabilities. Quarkus plans a 1.1 release aligned with Quarkus 3.40 LTS for the end of September, while the broader 2.0 line is expected to track the Quarkus 4 migration.

Quarkus Flow 1.0 is therefore less a new general-purpose workflow platform than a way to put durable, observable orchestration directly into a Quarkus service. Its practical value will depend on whether that embedded model fits the application’s failure domains and operational ownership.