Unified orchestration means one control plane for data, infrastructure, applications, and business processes, with AI agents governed across all four. Kestra is the open source platform built for unified orchestration: declarative, event-driven, language-agnostic, and licensed under Apache 2.0.
Most comparisons of workflow orchestration tools work through feature lists. That misses what decides whether a platform can serve dozens of teams whose workflows cut across domains, because unified orchestration is an architectural property rather than a set of capabilities. An engine either reaches across domains because of how it was built, or it does not reach across them at all. Features get added. Foundations do not.
I joined Kestra as Global Field CTO after two decades working on data integration, process intelligence, and AI, and the architecture is the reason. This article covers what unified orchestration means, what an engine needs internally to deliver it, and what changes when human work becomes a native part of the platform instead of a handoff to another system.
What is unified orchestration?
Unified orchestration is the coordination of data, infrastructure, application, and business workflows on a single control plane, with AI agents governed everywhere they act. Four workload domains sit side by side, and agentic AI runs across all four instead of forming a fifth.
The four domains under one control plane
Each domain is broad, and each one already contains several tool categories that grew up separately.
Data. Ingestion and replication, ELT and ETL, SQL transformations, lakehouse and data warehouse loads, data quality checks, and machine learning pipelines. The work is done by tools such as Fivetran, Airbyte, dbt, and Spark, coordinated by Airflow or a similar Python-first orchestrator that data engineers adopted and few other teams did.
Infrastructure. Three tool families that grew up separately. Enterprise workload automation and job scheduling, with a job-and-dependency model and a calendar heritage, on Control-M, AutoSys, Redwood, and cron. IT self-service provisioning and IT process automation, catalog-driven and request-and-approve, on VMware Aria Automation, HPE Morpheus, ServiceNow, and runbook tools such as Rundeck. And infrastructure as code with configuration management, where Terraform provisions and Ansible handles configuration and Day-2 operations, each reconciling desired state with no cross-system dependency graph of its own. CI/CD delivery, platform operations, and security operations playbooks sit alongside. Each is observed and governed in its own silo, and most of them execute rather than orchestrate.
Applications. Microservice coordination, API workflows, event-driven choreography, long-running transactions with compensation, and the glue code connecting SaaS systems. Most of it lives in per-team scripts, iPaaS tools and integration frameworks such as Apache Camel, or code-first durable execution engines embedded in the application itself.
Business processes. Approvals, customer and partner onboarding, order-to-cash, claims handling, incident resolution, and every step where a person decides something. Historically the property of BPM suites such as Camunda and Pega, RPA tools such as UiPath, and the automation built into ERP and CRM. This is where the other three domains come together in a business, and it belongs to a workflow platform because the steps are system-executed with governed human decisions between them. It is not a claim to be a BPM suite; modeling-first engines keep the processes where the diagram is the contract.
AI agents run across all four. An agent that retrieves data, calls a model, provisions a resource, and requests a human approval crosses every domain in a single execution. Agents need a layer that spans all four and governs them, not a fifth silo standing beside them.
Every silo inherited a constraint
Enterprises did not choose this fragmentation. Each part of the organization built orchestration for its own workload, at a different time, for good reasons, and each inherited a constraint from where it started. Data orchestrators inherited Python and the DAG. Workload automation inherited the batch calendar and the job-and-dependency model. BPM suites inherited the visual BPMN model as source of truth. Durable execution engines inherited the code-first programming model. Agent frameworks inherited the agent runtime.
Every one of them is strong in its home domain. The cost of the silo is not the tool but the boundary between the tools, where a pipeline finishes and the downstream job never starts, or a process waits on an approval sitting in someone’s inbox. Migrations widen those boundaries. Every platform move, whether a warehouse, a hypervisor, an ERP, or a mainframe, produces a layer of interim glue that connects the old system to the new one, and that glue routinely outlives the migration it was written for. The quietest version is the worst: a script fails silently, and the first person to notice is whoever reads the report it should have fed.
Agentic AI raises the stakes at every boundary. An agent acting across an ungoverned workflow does not fail loudly; it confidently does the wrong thing.
Why business outcomes require unified orchestration
The four domains share one axis: each names the object being worked on, whether datasets, infrastructure resources, services, or business transactions. The set is also deliberately asymmetric. Three are layers of the technology stack, and the fourth is the business outcome those layers exist to serve. Remove business processes from the set and unified orchestration collapses into one more tool coordinating IT work. Keep it and the claim changes: the platform coordinates the systems that run the business.
A simple test separates the fourth domain from the other three. When a workflow breaks, in what unit is the loss reported? Infrastructure failures are measured in capacity and availability. Business process failures are measured in orders not shipped, payments not captured, and regulatory exposure. A retailer’s order and payment workflow is a business process regardless of which team operates it. Who runs a workflow is an organizational choice, and a taxonomy that follows the org chart is a seating plan rather than a taxonomy.
How unified orchestration relates to data integration and process intelligence
The four domains describe what one engine coordinates. A second lens describes where that engine sits among its neighbors: three layers of the modern enterprise stack. This lens separates what a platform replaces from what it coordinates.
The bottom layer moves data, through integration and streaming across request-response, batch, and event-driven paradigms. Above it, the middle layer decides and coordinates. The top layer acts, through people, applications, and governed AI agents. Each layer depends on the one beneath it. I call this the trinity of modern data architecture: event-driven data integration, workflow orchestration with process intelligence, and trusted agentic AI. The three layers are not the four domains: the domains are the workloads one engine coordinates, and the layers are where that engine sits in the stack.
API platforms, batch ETL tools, messaging, event streaming, and stream processing all live in that bottom layer.
The middle layer needs a distinction that often gets blurred.
Process intelligence is the broad discipline. It covers how work actually runs across an enterprise: discovering the real process from event logs, measuring where it stalls, executing it reliably, and improving it over time. Process mining platforms reconstruct what happened, task mining looks at the desktop level, and conformance checking compares the real path against the intended one.
Workflow orchestration is the execution core of process intelligence. The orchestration layer runs the work and records how it actually ran. Every execution, retry, approval, and failure becomes an event with a timestamp and an owner. Process intelligence turns that record into insight, and the insight shapes the next run. One executes, the other explains, and neither is complete alone. An orchestrator producing a clean event log is doing process intelligence work whether or not anyone calls it that.
What is Kestra?
Kestra is an event-driven engine built for unified orchestration and coordinates the stack an enterprise already runs. Its core properties:
- Declarative. Workflows are defined in YAML, versioned in Git, and deployed through CI/CD like any other code, or promoted between environments from the interface with a diff against the target and the promotion written to the audit log.
- Language-agnostic. Tasks run in Python, SQL, Bash, R, Go, or anything that runs in a container. Existing scripts and applications run unchanged, and SaaS services are called like any other task.
- Event-driven. Schedules, events, webhooks, and messages all trigger flows through one engine.
- Open source. Kestra is Apache 2.0 licensed, the same permissive license as Apache Kafka, and the open source edition is a complete platform that teams run in production.
- Extensible. More than 2,000 plugins connect it to cloud services, databases, SaaS tools, and enterprise systems, and any script or API call runs natively as a task.
- Deployable anywhere. From the first container on a laptop to highly available clusters at enterprise scale, in the cloud, on-premises, at the edge, or air-gapped. Teams move from scripts to containers to Kubernetes without rewriting a flow, because the definition is independent of the runtime underneath it.
The project has 28,000+ GitHub stars and runs in production at organizations including Apple, JPMorgan Chase, Toyota, and Xiaomi, across financial services, manufacturing, automotive, telco, retail, and tech. More than 3,500 companies run their workflows on it.
Kestra Enterprise Edition and Kestra Cloud
The Enterprise Edition adds what regulated organizations need on top of the same engine: single sign-on and SCIM, action-based role-based access control, policies that inject, restrict, or block configuration across namespaces and tenants, execution quotas, secrets management, multi-tenancy, and audit logs that ship to the SIEM the auditors read, including over syslog.
Kestra Cloud delivers the platform fully managed, with consumption-based pricing and no operations burden, and its workers can run inside the customer’s own perimeter.
The architecture behind unified orchestration
Unified orchestration is an engineering problem before it is a product problem. Four architectural decisions determine whether one engine can span data, infrastructure, applications, and business processes.
Schedules and events run through one engine
A scheduler asks when. An event-driven engine asks what happened. The difference sounds semantic until you try to convert one into the other.
Retrofitting event handling onto a date-driven scheduler usually produces a second system: a polling loop, a message consumer, or a webhook receiver bolted alongside the calendar, with its own state and its own failure modes. Teams then operate two coordination models and reconcile them by hand.
In Kestra, a flow triggered by a schedule and a flow triggered by a file arriving in object storage are the same kind of object, with the same retries, the same state model, and the same audit trail. Modernizing legacy batch workloads becomes possible without freezing them in batch, because the same engine that runs tonight’s job also reacts to the event that should eventually replace it.
Why the engine core is event-driven
An orchestration engine built for enterprise scale is a distributed system. A scheduler decides what should start, an executor tracks state, and workers run the tasks, often on separate machines, in separate networks, sometimes on separate continents. Those components exchange a constant stream of small messages while any of them can restart at any moment.
There are three ways to connect them, and only one holds up at enterprise scale.
- Direct calls. Simple until one component is slow or unavailable, at which point the failure propagates instead of being absorbed.
- A shared database that everyone polls. Works at low volume and turns the database into the bottleneck as executions grow.
- Durable queues. Where decades of mission-critical systems ended up: JMS in enterprise Java, message brokers via AMQP in banking and telecommunications, Kafka at internet scale.
Durable queueing gives an orchestration engine three properties it cannot easily get elsewhere. Decoupling, so a worker restart or a scheduler failover loses no work. Durability, so in-flight coordination survives a crash instead of evaporating. Backpressure, so a slow downstream system creates a queue instead of a cascade.
The queue backend is a deployment choice
Kestra’s core is event-driven no matter what runs underneath it. Components communicate through durable queues, and the backend is a deployment choice rather than a fixed dependency. Administrators run the queue on a database for simple deployments, or on Redis, AMQP, Kafka, or Google Cloud Pub/Sub when throughput and high availability matter. Queue and repository are chosen independently, so a team can run Postgres as the repository with Redis for queuing, or Kafka for queuing with Elasticsearch as the repository. Supporting several backends does not multiply the engineering cost either: one implementation runs the scheduler, executor, and workers, and each backend is a thin adapter. Executions complete in milliseconds to low seconds at thousands of executions per minute on a plain PostgreSQL backend, so the database path covers far more than a proof of concept.
The architectural point matters more than the option list. An orchestration layer that dictates its own infrastructure asks every team to conform to it, and adoption stalls at the first team that cannot. I have watched that stall happen more than once: a platform team picks an orchestrator, the security-sensitive business unit refuses the required stack, and the consolidation project quietly becomes a fifth silo. A layer that adapts to the messaging and storage already in place can be adopted by many teams with very different constraints. For the thousands of enterprises running Kafka as their nervous system, the orchestration layer plugs into it. For everyone else, a database is enough.
Why orchestration is not data integration
Data integration moves and transforms data across three paradigms: request-response APIs, batch, and event-driven streaming. Orchestration coordinates what runs across all of them. Both ship hundreds of connectors, which is exactly why they get confused. I map the full space in the Data Integration Landscape 2026 and draw the line in detail in Data Integration vs Workflow Orchestration.
The deepest confusion sits with stream processing, because both react to events.
Stream processing computes continuously over data in motion. Apache Flink, Kafka Streams, and Spark Structured Streaming join, aggregate, and filter events, from millisecond stream processing to micro-batch analytics, holding state across billions of records. The unit of work is the event, and which engine fits depends on latency and consistency requirements.
Orchestration decides what runs next and owns the outcome. It triggers systems, sequences dependencies, handles retries, waits for approvals, and records what happened across tools that know nothing about each other. The unit of work is the task, and the timescale runs from seconds to days.
I have seen too many teams build orchestration inside a stream processing framework, and it goes wrong the same way every time. Long-running waits, human approvals, and cross-system dependencies map badly onto a dataflow topology, and operating the result requires specialists in state stores and partitioning to debug a workflow that stalled.
The same complementarity holds at platform level. Data streaming platforms run the always-on analytics, and the orchestrator manages everything around them: deploying and monitoring the jobs, running the batch and business workflows that consume their results, and reacting when a stream surfaces something a person or a system must act on. Use each tool for the job it was designed for. Kafka moves and buffers events, Flink computes over them, and the orchestrator coordinates the work around both. I cover the boundary, including the Confluent Control Center story, in depth in When NOT to Use Stream Processing.
Kestra separates the control plane from the data plane
Kestra separates the components that decide from the components that execute. Scheduler, executor, worker controller, web server, and indexer form the control plane; they coordinate work, execute no user code, and never touch the systems the workflows act on. Workers form the data plane. Since Kestra 2.0 each worker connects to the control plane over a single outbound gRPC stream, holds no database connection, and carries no state between tasks, so a worker needs nothing more than an outbound path to run anywhere.
That separation buys four things:
- Workers run in other regions, inside segregated networks, on-premises, or at the edge, with no database port exposed and nothing but an outbound connection required. Fully air-gapped environments run control plane and workers together inside the perimeter, on the same components.
- Communication supports mTLS and service mesh, with fine-grained network policy between components.
- Control and execution scale independently, so capacity follows actual workload instead of peak provisioning everywhere.
- Sensitive workloads execute inside the customer’s perimeter while the platform itself is managed elsewhere.
This is the property that decides whether one platform can serve a bank’s regulated workloads, a factory’s edge operations, and a cloud data team at the same time. Execution follows the data and the compliance boundary instead of forcing both to move.
Assets: the orchestrator knows what it acts on
A workflow engine sees tasks and executions. It does not, by default, see the things those tasks create and change: datasets, virtual machines, certificates, Kafka topics. Unified orchestration needs that second view.
Kestra models them as Assets. Every resource a flow acts on is registered in an inventory under the identifier the organization already uses, so a corporate naming standard becomes the asset ID with no translation layer. When two flows touch the same resource, one takes a time-bounded lock, from a task or from the interface, and the other waits. The lock expires on its own, so a failed flow cannot leave a resource locked.
Every execution also records which assets it consumed and which it produced. That lineage makes freshness a computed property: Kestra flags a stale input before a downstream job runs on it, and a stale asset can start its own remediation flow. Dashboards over the inventory show the current state of the resources, not a window of past executions.
Assets are the orchestrator’s working model of the resources it acts on, not a configuration management database (CMDB), and they do not compete with the system of record. A provisioning flow registers the asset, locks it while Terraform and Ansible work on it, updates it when they finish, and writes the record to the CMDB as one of its steps. The same object is what a case attaches to when a person has to decide.
How agentic AI connects to unified orchestration
Model Context Protocol (MCP) usually gets described as one thing, a standard way to connect a model to tools. That framing collapses the moment you put an orchestration platform in between, because the platform does not sit on one side of the connection. It takes part in three ways: it calls tools, it answers questions, and its workflows are tools.
These three connection patterns are not a vendor innovation. They are the standard patterns every serious orchestration platform has to support, and the market is converging on all three. The differentiation is not the protocol but what governs each connection, and how far that governance reaches.
Outbound: the platform calls tools
An agent step inside a flow gets a set of MCP tools and decides at runtime which to reach for. Those tool definitions can be packaged as reusable Agent Skills and shared across flows, so a team defines once how an agent may query the warehouse or open a ticket and every flow inherits it. The decision is nondeterministic, and everything around it is not. Tool selection is a logged step inside a versioned flow rather than a choice hidden in a prompt, and a human approval gate can sit in front of anything that commits money, changes production, or touches customer data.
Inbound query: the platform answers questions
Any MCP-aware client, whether Claude Code, ChatGPT, Cursor, or a team chat tool, connects to the Kestra MCP server and inspects flows, executions, logs, and namespaces in natural language. A support engineer asks which pipelines are stuck and what the error was, without learning the API surface first or waiting for someone to build a dashboard.
Inbound invocation: a workflow becomes a callable tool
A flow is published as a named tool with a description and typed inputs, so an agent framework that has never heard of Kestra’s API can discover it and call it. Your deployed workflows become a library of capabilities: run the know-your-customer check, provision the environment, rotate the credential, open a case for human review.
Why inbound invocation needs a control plane
Most platforms ship the outbound pattern and stop. Teams then hand-build the other two, per project, every time: a chat interface for operational questions here, a custom API layer for external agents there.
Inbound invocation is where architecture stops being optional. The moment a workflow is callable by an agent, the questions are which flows are exposed, who may call them, what happens when a call is wrong, and what the record looks like afterwards. On an agent framework, that governance covers the agent runtime and stops at its edge. On a control plane, it is the same namespace-scoped access control, the same versioned definitions, the same audit trail, and the same approval gates that already apply to every other execution.
The cross-domain point follows. The capabilities an agent reaches for are not only business processes. Backfilling a dataset is data. Rotating a credential is infrastructure. Restarting a service is applications. Opening a case for a human decision is a business process. A library of callable capabilities only holds together if one engine spans all four, which is the same argument as the rest of this article, arriving from the agent’s side of the connection.
The economics point in the same direction. McKinsey’s analysis of agentic workflows finds that human oversight, not token spend, dominates the variable cost of production agents, and that completing one real unit of work takes several agents, deterministic systems, and human review teams together. Coordinating that mix, and bringing down the cost of the human loop, is workflow design before it is model selection.
Orchestrating agents is not agentic orchestration
Two ideas share the word agentic. Letting an agent choose the next step is agentic orchestration. Running and governing agent workloads with deterministic guarantees around them is orchestrating agents. A serious platform does both.
The protocol is the easy part. The architecture decides what an agent may reach, and proves afterwards what it reached.
Case management: when the orchestrator owns the human loop
Human steps have always belonged to orchestration. For two decades they lived in a separate discipline called BPM. Unified orchestration brings them into the same engine that runs the data, infrastructure, and application workflows. The only question left is how human work is handled, and that is what case management answers. The scope here is operational: cases attached to executions, where work is detected, decided, and remediated under governance. It is not adaptive case management in the Case Management Model and Notation (CMMN) sense, where a knowledge worker composes the path as the case develops.
What is case management in workflow orchestration?
A case is a long-lived unit of work with its own state, owner, severity, deadline, and audit trail, linked to the executions and assets it concerns. It outlives any single execution. A workflow run finishes in minutes. A case stays open across shifts, changes hands, accumulates evidence, and closes only when a person decides it is resolved.
Kestra Cases gives that object a home inside the platform. A case carries a description, a severity, a status moving from open through acknowledged and investigating to resolved, assignees and watchers, and custom fields. It can carry acknowledgement and resolution targets with live countdowns, and it links the executions and assets it concerns. Resolving one requires a stated reason, and every change is written to a timeline.
Human work moved from BPM suites into the orchestration layer
For two decades, human steps lived in a separate product. BPM suites owned approvals, work queues, escalation, and audit trails, and they did it well. The consequence was a split: engineering could not easily reach the process logic, and the business could not see the technical flows underneath. A claims process modeled in BPMN triggered data pipelines it had no visibility into, and the pipelines knew nothing about the claim.
The split was an artifact of tooling, not of the work. When business processes become one of four domains inside a single engine, human work becomes a native step alongside the pipeline that feeds it and the infrastructure it runs on. No integration in between, one governance model, one audit trail. A concrete example: a VM patching workflow applies the patch in the test environment, pauses for a named approver who must record a reason, continues to production only on approval, and rolls back automatically on rejection or failure. An infrastructure workflow and a human decision in one governed flow, with the sign-off in the audit trail instead of an email thread.
Kestra runs the system-executed spine of those processes, the path where systems, data, and governed human decisions meet. Modeling-first process engines still fit where the diagram is the contract and business analysts own it. What changes is that human steps are no longer a reason to run a second orchestration engine.
Detection, decision, and action stopped being three systems
A critical workflow fails at 3 AM. The orchestrator detects it and fires a webhook. A message appears in Slack. Someone opens a ticket in a service management tool. Investigation proceeds by pasting execution links into the ticket. The fix runs from a fourth place, usually a terminal.
Four systems, and the evidence, the ownership, and the remediation each sit somewhere the others cannot see. The orchestrator knows exactly what broke and holds the permissions to fix it, and it is the one participant with no seat at the table.
Kestra Cases brings detect, decide, and act onto one plane. The incident, the evidence as linked executions and assets, the people through assignees and deadline clocks, and the remediation all live together. Case actions are the piece that matters most: a remediation is attached to the case as a one-click workflow, so running it starts a governed execution that is versioned, permissioned through role-based access control, linked back to the case, and recorded in the timeline. Fixing the problem produces the audit record automatically, because the fix is a workflow.
The boundary is worth stating plainly. This does not replace enterprise service management. A system of record with a configuration management database, ITIL process, and organization-wide request catalog serves a different scope. Platforms such as ServiceNow, BMC Helix, and Jira Service Management own that job, and Kestra integrates with them. What changes is that the human loop belonging to a workflow stays with the workflow instead of being exported into a general-purpose ticketing system that cannot see the executions.
Alert fatigue is a design problem, not an operations problem
One external API becoming unreachable can produce dozens or hundreds of failed executions within an hour. A notification per execution gets the channel muted, and muted alerting is worse than no alerting.
Kestra collapses them. The first failure opens a case, and every subsequent failure of the same flow and task attaches to it instead of opening another one. The team sees one incident with a hundred pieces of evidence rather than a hundred incidents. The behavior is available from the workflow definition and from the interface.
Business users get an interface, not a YAML file
The other half of human work is the people who start it. Kestra Apps turn a flow into a self-service interface through a visual editor: forms for inputs, layouts for what appears while a workflow runs and after it succeeds, and blocks that can be added or rearranged without touching the underlying definition. Apps carry revision history like any other resource, and a default app works with no configuration at all.
The point is not that engineers can avoid YAML. A finance analyst, a support agent, or an operations manager can run a governed workflow without one, while the workflow itself stays version-controlled, permissioned, and auditable. Self-service stops requiring a shadow automation platform.
Kestra Cases and Apps together close a loop back to process intelligence. Every status change, assignment, comment, action run, and missed deadline is recorded in the timeline as an event. Human decisions stop being invisible. The record of how work actually ran now includes the part where a person intervened, which is exactly the data process mining needs and rarely gets.
Agents add a forward version of this argument. They generate work with no predetermined path, where the actor exercising discretion is a model rather than a person. Kestra answers with the control plane instead of a notation: the agent runs inside a declared flow, and when an action would exceed its authority, a case opens and a named person takes ownership with the full execution record attached.
Why open source matters most in unified orchestration
Every layer of the enterprise software stack has an open source argument. The orchestration layer has the strongest one.
Orchestration is the only layer every team must trust at the same time. Data engineering, platform operations, application teams, and the business all place their critical work inside it. A layer coordinating across organizational boundaries has to be neutral, and a proprietary control plane cannot be the neutral point. Neutrality is a functional requirement here, not a preference.
Kestra is open source under Apache 2.0. The engine running in production is the same engine anyone can export, inspect, and run independently. Four consequences:
- No lock-in on the layer that touches everything. Orchestration accumulates business-critical logic faster than any other layer. Being able to leave is what makes it safe to commit.
- Sovereignty as a property, not a negotiation. Self-hosted, on-premises, edge, and air-gapped deployment are characteristics of the software, not concessions in a contract.
- An ecosystem the community extends. Plugins are open, and anything not yet covered runs as a script or an API call.
- Adoption from the terminal up. Engineers adopt what works, teams standardize on it, and the organizational case follows the technical one instead of preceding it.
Kestra Enterprise Edition extends the same engine with the governance, security, and operations that regulated organizations need, and Kestra Cloud delivers it fully managed. The engine underneath stays open, which is the part that matters for the architecture decision.
When Kestra is not the right choice
No platform is the right answer for everything. These are the cases where I point architects elsewhere.
- You need a system of record for enterprise service management. A configuration management database, ITIL process, and organization-wide request catalog belong in ServiceNow, BMC Helix, or Jira Service Management. Kestra handles the human loop attached to workflows and integrates with the system of record.
- The process model is the contract. When business analysts design processes visually and the BPMN diagram is the source of truth, a modeling-first engine such as Camunda, Flowable, or Bonita fits better. The two also combine well: the BPMN engine owns the human-modeled process while Kestra runs the data, infrastructure, and application workflows underneath it. The same applies to adaptive case management, where a fraud investigation or escalated claim has a goal instead of a sequence and a knowledge worker chooses the path. Kestra Cases holds the human loop around executions and does not replace that model.
- The job is integration, not orchestration. Data integration spans three paradigms. Request-response runs through APIs and integration platforms. Batch runs through ELT and ETL tools such as Fivetran and Airbyte. Event-driven data integration runs through messaging, event streaming, and change data capture, with protocols and platforms like AMQP, JMS, MQTT, and Apache Kafka. Orchestration coordinates these tools and replaces none of them. Small overlaps exist, as everywhere in software, but these are complementary layers rather than competing ones.
- You need continuous computation over data in motion. Sub-second joins and aggregations across streams are work for Apache Flink, Kafka Streams, or Spark Structured Streaming. Kestra is event-driven and reacts in real time, but it coordinates tasks rather than computing over millions of events per second.
- The workload lives inside a legacy platform. Mainframe job scheduling and the automation built into proprietary ERP platforms such as SAP and other packaged applications stay where they are. Kestra coordinates around these systems: it triggers them, reacts to their outputs, and connects them to the rest of the enterprise.
- You are building applications, not running workflows. Apps give business users an interface onto a workflow. Building a customer-facing application with its own data model and screens is the territory of low-code platforms such as Appian, Mendix, or OutSystems.
The coordination layer decides what an enterprise can do
Automation scaled. Coordination did not. Enterprises do not lack tools for running work; they lack a layer that governs work running across all of them, and every agent entering production raises the cost of that gap.
Unified orchestration is one control plane across data, infrastructure, applications, and business processes, with AI agents governed everywhere they act. Reaching it is an architectural decision rather than a purchasing one: one engine for schedules and events, an event-driven core that adapts to the infrastructure already in place, execution that runs where the data and the compliance boundary already are, a resource model shared by every domain, human work as a native step instead of a handoff, and an open core every team can trust.
The path from four silos to one platform starts with a single workflow. That platform is also where trusted agentic AI begins, because agents can only be governed by a layer that sees everything they touch.
To follow this work across data integration, workflow orchestration, process intelligence, and trusted agentic AI, subscribe to my newsletter and follow me on LinkedIn.
