The blog post is titled Announcing Workflows 1.0, and if you read only the title you'll file it under "minor release" and move on. Do that and you'll miss the one sentence in the announcement that actually matters — the one where LlamaIndex admits the underlying architecture hasn't changed significantly. A 1.0 that changes nothing architecturally is not a version. It's a repackaging. And this particular repackaging quietly rewrites what the phrase "using LlamaIndex" means.
The tell is in the dependency tree#
Here is the whole story, and you can verify it in ten seconds without reading a word of marketing. Install the package:
pip install llama-index-workflowsNow look at what came with it. The hard dependencies are pydantic, typing-extensions, and llama-index-instrumentation. That's the list. There is no llama-index in it. The orchestration engine that used to live inside a document-and-retrieval framework — readers, nodes, indices, query engines, the whole RAG apparatus — now ships as a package whose dependency closure contains none of it.
That is the release. Not a feature; a subtraction. LlamaIndex took the event-driven engine out of the framework and gave it its own repo (run-llama/workflows-py), its own TypeScript sibling (@llamaindex/workflow-core, from run-llama/workflows-ts), and its own release cadence. What you get is a bare orchestration primitive: @step-decorated methods, typed events flowing between them, a shared Context. You can build an agent on it. You can build something that has nothing to do with agents on it. The engine no longer has an opinion about retrieval, because retrieval is no longer in the box.
Why the "1.0" is a little bit of a lie#
If you're the kind of person who pins versions, the "1.0" will trip you. The thing you install, llama-index-workflows, is at 2.22.2 as of June 30, 2026 — not 1.0. The mismatch isn't a mistake; it's the seam showing. The engine had already been extracted and had been shipping on its own version track for a while. "Workflows 1.0" is the product milestone — the moment LlamaIndex is willing to call the standalone framework stable and tell you to build on it directly — layered on top of a package that's already several minor releases into its independent life.
"1.0" is a stability promise about a framework, not a number you type after ==.
Treat it that way. Depend on the package by name, read its own changelog, and ignore the marketing integer.
The clever part: nothing breaks#
The obvious risk in extracting a core module from a widely-imported framework is that you shatter everyone's imports. LlamaIndex dodged it with a boring, correct move: both llama_index and LlamaIndexTS now re-export the standalone Workflows library through the original import paths. Your existing from llama_index.core.workflow import ... keeps resolving — it just resolves into the new standalone package, and inherits whatever ships there next. The refactor is invisible from the application side unless you go read your lockfile and notice a new top-level dependency that used to be a transitive one.
This is the pattern to steal, by the way, if you ever have to pull a subsystem out from under a popular API: extract, then re-export the old surface as a thin alias. Nobody's build turns red, and the people who want the smaller dependency can reach past the alias and depend on the extracted package directly.
What 1.0 actually adds, honestly#
Strip the repackaging away and the genuinely new surface is small, which is fine — small and real beats large and vague:
- Typed state, on both Python and TypeScript. The old shared context was a loosely-typed grab bag; you now get a typed state object, so the thing every multi-step workflow leans on stops being a place bugs hide.
- Dynamic resource injection (Python). You can inject a database client, an HTTP session, a model handle into steps at runtime rather than smuggling them in through closures or globals — the small quality-of-life fix that decides whether your steps are testable.
- Opt-in observability, through
llama-index-instrumentation— the one dependency that did come along. Install it and your workflows emit to OpenTelemetry, Arize Phoenix, and friends. Notice the design: observability is a dependency you already have, so tracing is a config flip, not an integration project.
So what do you do with this#
If you evaluated LlamaIndex a year ago, bounced off it because you only wanted orchestration and didn't want to adopt a RAG framework to get it, that objection is now gone — and it's gone in a way you can prove from a pip show, not a promise. The interesting reframe is what it does to the comparison everyone runs. "LlamaIndex vs LangGraph" was, for orchestration purposes, partly a comparison of dependency weight. That axis just collapsed. What's left is the thing that should have been the whole conversation anyway: do you want to model your agent as an event-driven mesh of steps or a graph of nodes — and which one your team will still understand at 3 a.m. six months from now.
Workflows 1.0 didn't answer that question. It just stopped charging you a framework to ask it.
