Enterprise AI may grab the headlines, but in most large organisations the real bottleneck isn’t the model—it’s everything wrapped around it. Over the last decade, Fortune 500s have accumulated a dense layer of schedulers, RPA bots, cron jobs, internal tools, and domain‑specific workflow platforms. Each team can point to its own pockets of automation. Yet when something breaks, very few leaders can see how work actually moves end‑to‑end across data pipelines, infrastructure, business processes, and now AI agents.
That invisible complexity is what Kestra’s CEO and Co‑founder Emmanuel Darras calls an orchestration crisis. In his view, enterprises don’t suffer from a lack of automation tools; they suffer from a lack of a true control plane—one layer that can coordinate heterogeneous workloads, propagate context and policy across systems, and make every execution observable and auditable. It is the thesis behind Kestra, the open‑source, declarative orchestration platform now used by companies like Apple, Toyota, JPMorgan Chase, BHP, and Crédit Agricole to unify workflows spanning data, AI, infrastructure, and business operations.
With the launch of Kestra 1.0, the company pushed that idea further with what it calls “Declarative Agentic Orchestration”: teams tell the system what outcome they want, while AI agents help determine the next step—under the same governance, approvals, and audit trails that already apply to traditional tasks. As enterprises experiment with thousands of agents in production, Darras argues that the winning pattern will not be a separate “AI operating system,” but a single control plane where deterministic jobs, semi‑autonomous workflows, and fully agentic processes all coexist under one governed orchestration layer.
In this conversation with AI & Data Insider, Emmanuel Darras unpacks what that orchestration crisis looks like inside a Fortune 500 stack today, where the limits of point tools like data schedulers and RPA platforms are starting to show, and what has to change—architecturally and culturally—before a “one control plane” strategy becomes a realistic operating model for AI‑driven enterprises.
1) Kestra’s Series A announcement talks about an “orchestration crisis” in enterprises, with workflows stitched together by scripts and legacy schedulers. What are the typical failure modes you see when you walk into a Fortune 500 stack?
The most common failure mode is fragmentation. In large enterprises, orchestration has rarely been designed as a coherent system. It has grown organically over time: one scheduler for data, another for infrastructure, a separate RPA tool for back-office processes, custom scripts for edge cases, and manual approvals handled somewhere else entirely. On paper, every team has “automation.” In practice, no one has a reliable view of how work moves across the business.
That creates several problems at once. First, teams lose visibility. They can see individual jobs, but not the end-to-end workflow, the dependencies between systems, or the real source of a failure. Second, reliability suffers because handoffs between tools are often the weak point: a script finishes but status is not propagated, an approval is delayed, a downstream task starts without the right context, or error handling breaks across system boundaries. Third, governance becomes inconsistent. Different teams adopt different standards for access control, observability, versioning, and auditability, which becomes a serious issue in regulated environments.
The deeper issue is that many of these stacks were built for a different era. They were not designed for hybrid environments, high volumes of events, AI-driven workloads, or the need to orchestrate data, infrastructure, business processes, and agents in the same operating model. So the result is not just technical debt. It is operational fragility. What looks like an automation estate is often a collection of islands held together by tribal knowledge.
That is the orchestration crisis: enterprises do not lack tools, they lack a control plane.
2) Many organisations already use tools like Airflow, Dagster, and various RPA platforms. Where do you draw the line between “just scheduling data pipelines” and what you call a unified orchestration control plane?
The line is whether you are coordinating isolated tasks inside one domain, or governing execution across the enterprise.
Scheduling data pipelines is important, but it is still a narrower problem. You are primarily focused on sequencing transformations, moving datasets, and managing dependencies inside a data stack. That is very different from orchestrating an approval-driven infrastructure workflow, triggering actions from business events, coordinating APIs and scripts, or managing AI agents alongside more traditional workloads.
A unified orchestration control plane has to do more than start jobs on time. It has to maintain context across systems, manage inputs and outputs across workflows, enforce governance, provide observability, and handle failure consistently even when the workflow spans different teams and technologies. It also has to work in the real enterprise environment: hybrid infrastructure, self-hosted constraints, security requirements, multiple user personas, and a mix of technical and non-technical consumers.
This is where many organisations hit the limits of point solutions. Data orchestrators are often excellent within the data domain. RPA platforms are often effective for specific business automations. Legacy schedulers may still run critical workloads. But enterprises increasingly need something above those layers: a centralised orchestration layer that can coordinate them all, standardise how automation is built and operated, and give the organisation one trusted place to understand what is running, why it is running, and what happens when something fails.
That is what we mean by a control plane. It is not another silo. It is the layer that connects the silos.
The key principle is simple: autonomy without visibility is unacceptable in the enterprise.
3) Kestra 1.0 introduced “Declarative Agentic Orchestration,” where teams declare outcomes and AI agents figure out how to achieve them under governance. How do you prevent that from becoming a black box in regulated, high-stakes environments?
That concern is exactly why orchestration matters. If agentic systems become black boxes, they are not viable for high-stakes enterprise use.
Our view is that agentic orchestration should not remove control; it should raise the level of abstraction while preserving visibility and governance. Teams can declare the outcome they want, but they still need a platform that exposes the context, tracks the decisions being made, captures inputs and outputs, and makes every execution traceable. In other words, the agent can decide the next step, but the control plane must still show what happened, why it happened, and under which constraints.
That means several things in practice. First, execution must remain observable. You need to inspect the sequence of actions, the state transitions, the artefacts produced, and the boundaries the system respected. Second, governance must be explicit. Enterprises need the ability to restrict which models are used, where they are used, what data they can access, and which actions require human approval. Third, agentic behaviour has to coexist with deterministic workflows. Not every step should be left open-ended. In many regulated workflows, the right pattern is a governed combination of declarative intent, bounded agentic decision-making, and clearly defined controls.
A concrete example we see is a banking compliance workflow. Some steps are strictly defined by regulation, for example, validating customer identity, checking sanctions lists, or enforcing approval gates. These steps must remain deterministic and auditable. But other steps, such as document analysis, anomaly detection, or risk scoring, can be delegated to an AI agent. In that model, the workflow combines fixed, controlled stages with agent-driven stages, all orchestrated in a single system where every decision, input, and output is tracked.
ALSO READ: Agentic AI in Production: Why Better Prompts Won’t Bridge the Gap
The key principle is simple: autonomy without visibility is unacceptable in the enterprise. Agentic orchestration only works if it is embedded in a platform that gives operators confidence, not mystery.
4) Agentic AI is moving quickly from hype to production, but many implementations still struggle with reliability and governance. How do you see orchestrators evolving to manage thousands of agents as if they were just another class of workload?
That is exactly how orchestrators need to evolve: agents should be treated as a workload class, not as a special world outside operational discipline.
Enterprises are already used to managing heterogeneous workloads. They run data pipelines, infrastructure jobs, event-driven processes, APIs, scheduled tasks, and human approvals. Agents should enter that environment with the same expectations: clear triggers, defined permissions, observable execution, policy boundaries, retry logic, failure handling, and lifecycle management. The orchestrator’s role is to make that operationally normal.
What changes is the level of dynamism. Traditional workloads usually follow a pre-declared sequence. Agents introduce more non-deterministic behaviour. So orchestrators need stronger capabilities around state tracking, context propagation, concurrency control, approval gates, exception handling, and auditability. They also need to support much higher execution volumes without creating a new operational blind spot.
ALSO READ: Why Data Reliability Now Governs Scaling GenAI
I think the winning model will be one where enterprises do not build separate operating systems for AI and non-AI work. They will use one control plane to manage all of it. Some workloads will remain fully deterministic. Some will be semi-autonomous. Some will be agentic. But they will all be subject to the same enterprise requirements around reliability, security, compliance, and scale.
The future is not “agents everywhere and governance later.” The future is agents becoming first-class operational citizens inside a governed orchestration layer.
A realistic “one control plane” strategy does not mean forcing every team into the same workflows or erasing domain expertise.
5) In many enterprises, data engineering, MLOps, platform engineering, and business ops teams use different toolchains. What has to
change—organisationally and culturally—before a “one control plane” strategy is realistic?
The first change is that organisations have to stop treating orchestration as a local team choice and start treating it as shared infrastructure.
In many companies, each team optimises for its own immediate needs. Data engineering chooses one tool, platform engineering chooses another, business operations adopts a separate automation product, and everyone assumes the integration problem can be solved later. That works for a while, but eventually the business feels the cost: duplicated tooling, inconsistent governance, brittle handoffs, and no common operating model.
A realistic “one control plane” strategy does not mean forcing every team into the same workflows or erasing domain expertise. It means aligning on a shared orchestration layer while allowing different teams to keep the tools that make sense for execution. Culturally, that requires a shift from tool ownership to workflow ownership. Teams have to agree that the most important question is not “which team owns this step?” but “how does the end-to-end process run reliably, visibly, and under governance?”
You see this especially in regulated industries like banking, where a single workflow can span multiple domains: a request comes from a business system, triggers compliance checks, orchestrates infrastructure or data tasks, and may include both deterministic steps and AI-assisted analysis. Without a shared orchestration layer, each part is owned by a different team with different tools. With a control plane, the entire workflow becomes visible, governed, and auditable end-to-end.
That usually needs executive sponsorship because the benefits are cross-functional while the resistance is local. Teams are often comfortable with their existing tools, even when the overall system is inefficient. A successful transition usually starts when leadership recognises orchestration as a strategic control layer: something that improves speed, resilience, auditability, and standardisation across the business.
So the cultural shift is this: orchestration stops being a feature of individual tools and becomes part of the company’s operating model. Once that happens, a unified control plane is no longer a slide. It becomes a practical necessity.
ALSO READ: Inside IBM’s 11 Billion Dollar Bet: What the Confluent Deal Reveals About AI’s Investment Paradox
