Elastic 9.4 makes workflows GA

Elastic is trying to turn its stack into more than a search engine and more than an observability tool. The bet is that modern software work — especially AI work — looks like a chain of retrieval, reasoning, action, and tracing. What changed this week is that Elastic 9.4.0, released on May 5, pushes that idea forward by making Elastic Workflows generally available, while tying them more tightly to Agent Builder and to the rest of the platform. (elastic.co) ### What is Elastic actually shipping? Elastic Workflows is an automation layer built inside the Elasticsearch platform. It started as a technical preview in Elastic 9.3, and now in 9.4 it has moved into general availability. The point is simple: instead of sending data out to one system for search, another for orchestration, and a third for response, Elastic wants the workflow engine to sit next to the data and permissions model you already use. (elastic.co) ### Why does “GA” matter here? General availability is the line where a feature stops being a demo for adventurous teams and starts being something vendors expect customers to build on. That matters for workflows more than for a dashboard widget, because automation touches production systems. If a workflow is going to open tickets, call APIs, gather context, or kick off investigations, buyers want supp(elastic.co)c is basically saying Workflows has crossed that line. (elastic.co) ### How does Agent Builder fit in? Agent Builder is Elastic’s framework for creating AI agents that can answer questions and take actions over Elasticsearch data. It is already marked GA for stack version 9.3 and later. The important detail in 9.4 is the two-way connection: agents can trigger workflows, and workflows can invoke agents as steps. That turns the product from “chat over your data” into som(elastic.co)an fetch context, decide what to do, and hand off deterministic steps to a workflow engine. (elastic.co) ### Why not just let the agent do everything? Because pure agentic behavior is flexible but messy. Workflows give you the boring parts on purpose — fixed sequences, business logic, approvals, API calls, and predictable failure handling. The clean way to think about it is this: the agent is the planner, the workflow is the rails. That split matters in enterprise settings where “took an action” has to be auditable, repeatable, and permissioned. (elastic.co) ### What about Prometheus and PromQL? This is the other big piece, but it is not in the same maturity bucket. Elastic announced native Prometheus support on April 23, including direct ingestion through Remote Write and PromQL support in Kibana, and both are still in technical preview. The goal is to let SRE teams keep Prometheus-native data and queries while correlating (elastic.co)ocs is still labeled preview in 9.4. (ir.elastic.co) ### So what is the bigger product move? Elastic is collapsing three layers that used to live in separate tools. First, retrieval and context live in Elasticsearch. Second, orchestration now lives in Workflows. Third, operational visibility lives in Observability, with Prometheus and PromQ(ir.elastic.co)ion, and leave a trace you can inspect later. (elastic.co) ### Why does that matter beyond Elastic? Because observability vendors are starting to treat AI activity less like a chatbot session and more like distributed systems work. An agent call fans out into retrieval, tool use, API calls, and side effects. That looks a lot like a service graph. Once you see it that way, the natural product move is full-stack corre(elastic.co)Elastic 9.4 doesn’t finish that story, but it makes the architecture obvious. (ir.elastic.co) ### Bottom line? The headline is not just “Elastic added workflows.” The real story is that Elastic is trying to become the operational substrate for AI systems — where context retrieval, orchestration, and observability all meet. Workflows going GA is the strongest signal yet that this is now a product direction, not an experiment. (elastic.co)