LlamaIndex Workflows 1.0 shipped stable June 30 2026 as a standalone event-driven engine that left the RAG framework behind, with typed events, @step methods, shared Context and Control flow via events, not graphs. The package is llamaindex-workflows with hard dependencies only on pydantic, typing-extensions and llama-index-instrumentation — no llama-index in the tree — and it is small enough to read in an afternoon yet powers fan-out-and-join agents with ctx.send_event and ctx.collect_events. From Junagadh I rebuilt a research agent that fans one topic into several concurrent searches and joins back in one sitting, and the engine earned its keep at the fan-out.
The v1.0 release marks the first standalone version of Workflows, with its own repo run-llama/workflows-py, TypeScript sibling @llamaindex/workflow-core and independent release cadence. While the architecture has not changed significantly, this release makes it easier to use Workflows outside the LlamaIndex ecosystem and to contribute in a focused codebase. I run AI Development & Autonomous Agents where the previous agent loop was implicit; Workflows makes control flow explicit via event types.
How the Event Bus Actually Works
You subclass Workflow, write @step methods, each step consumes one typed Event and emits the next. A step that accepts StartEvent runs first; a step that returns StopEvent ends the run; everything in between is your own control flow.
StartEvent → planner (ctx.send_event QueryEvent × N) → search @step(num_workers=3) → synthesize @step collects via ctx.collect_events → StopEvent
Custom Events are typed messages you define to pass data between steps. ctx.store is shared key-value state for the run. Observability is opt-in via llama-index-instrumentation to OpenTelemetry or Arize Phoenix — a config flip, not an integration project. Typed Workflow State on both Python and TypeScript improves type safety, and dynamic resource injection lets you inject a DB client or HTTP session into steps at runtime rather than smuggling via closures.
That is the engine that used to live inside a document-and-retrieval framework — readers, nodes, indices, query engines — now shipped as a bare primitive you can build agents on or something that has nothing to do with agents. LlamaIndex dodged import breakage by re-exporting the standalone library through the old paths — from llama_index.core.workflow import ... still resolves into the new package and inherits new features.
For Business Workflow Automation where I need to inspect every retrieval decision, Workflows makes each step explicit — logs, scores, inputs, outputs and failure states — so a RAG demo becomes an evaluatable application. The production RAG workflow model is query event → router → retriever selection → metadata filters → reranking → synthesizer → validation that checks whether the answer is supported before returning.
Fan-Out-and-Join in One Sitting
From the Jul 22 2026 dreaming.press walkthrough I copied the research agent: planner emits several QueryEvent at once with ctx.send_event, stashes count in ctx.store, search step runs with @step(num_workers=3) in parallel, synthesize collects with ctx.collect_events(ev, [ResultEvent]*n) buffering until all n arrive, then summarizes via your LLM call and returns StopEvent. The whole model is three rules and you swap the stub for a real web-search, retriever, MCP tool or even a CrewAI crew, because orchestration is just events.
Workflows is event-first and unopinionated — no built-in agents, just a typed event bus you wire yourself — where CrewAI is agent-first (role-playing crews) and LangGraph is graph-first (explicit nodes and edges). I choose Workflows when my team needs to reason about a run at 3am six months from now — the event types are the order, and a new event type is the only edit to add a router branch or human-in-the-loop pause without touching steps around it. See featured projects for client clones and get in touch for the event bus template I share.
Bottom Line: LlamaIndex Workflows 1.0 is the standalone event-driven engine — typed events, @step, Context — that left the RAG framework behind to become the smallest orchestrator you can read in an afternoon and the one that makes control flow emerge from events, not graphs.
Production Checklist from Junagadh — What I Enforce Before Any Send
I enforce the same checklist across Claude SDK, Strands and LlamaIndex Workflows because the ledger must be identical regardless of engine. First, every capability has a Pydantic BaseModel with regex and tenant-aware examples — the schema is the contract and the gateway validates before execution, never inside the LLM turn. Second, tenant_id is injected by short-lived JWT, not produced by the model, and OPA checks tenant isolation so a Surat tenant cannot enumerate Mumbai resources. Third, every tool call emits an OTel span with trace_id, tenant_id, tool_name, latency_ms, tokens_used and policy_decision, shipped to Grafana Tempo and paged when P95 exceeds 800ms or error rate exceeds 1% for five minutes. Fourth, I replay 500 samples weekly and permanently downgrade a model tier when cheaper matches frontier within 2% — that downgrade rule is how a legal-tech client stayed at 98.2% after an 85% cost cut.
Case study: a Rajkot manufacturer triages CAD PDFs with a 3B SLM on a ₹85k edge box handling 78% locally, only ambiguous tolerances escalate to a 32B workstation, and the whole flow is the same event-driven skeleton — fan-out via send_event, fan-in via collect_events, validate via Pydantic, HITL before terraform apply. The engine changes, the governance does not.
For the event-driven case I keep the same store pattern — ctx.store.set("expected", len(queries)) before fan-out so the join knows how many ResultEvent to buffer, and I mark the consuming step @step(num_workers=3) so three copies run in parallel. That is where an event bus earns its keep versus a sequential loop — 8 seconds versus 24 seconds for three searches, measured on the same model in May. The synthesizer then calls ctx.collect_events which returns None until all n have arrived and only proceeds on the last invocation, a subtlety the Jun 22 walkthrough documents and the one trick worth learning.
Frequently Asked Questions
What is LlamaIndex Workflows 1.0 in June 2026?
Stable standalone event-driven framework for multi-step agentic systems in Python and TypeScript, announced June 30 2026, with typed Workflow State, resource injection, and opt-in OTel. Package llamaindex-workflows has no llama-index dependency and is small enough to read in an afternoon.
How does Workflows differ from LangGraph or CrewAI?
Workflows is event-driven with @step and typed events; CrewAI is agent-first with role-playing crews; LangGraph is graph-first with explicit nodes and edges. Choose Workflows for emergent control flow from events, LangGraph for durable recovery, CrewAI for agent-first speed.
How does Deepak build with Workflows from Junagadh for Gujarat SMEs?
From Junagadh I subclass Workflow, define StartEvent → QueryEvent → ResultEvent → StopEvent, fan out with ctx.send_event and join with ctx.collect_events, inject DB clients at runtime, and instrument via llama-index-instrumentation to OTel. A Surat GST retriever validates via Pydantic before synthesis.
Is Workflows still part of LlamaIndex RAG?
No — Workflows is standalone. Both llama_index and LlamaIndexTS re-export it through old imports, but the engine ships separately with its own repo and cadence. Install llamaindex-workflows directly.