Workflow Orchestration

Parent: Agentic.

Workflow Orchestration covers durable execution engines and lighter agent workflow runners: retries, timers, queues, and audit across steps that outlive a single process. Under Agentic it is the backbone for long-running business work — not the chat turn, not the model server. Compare it to Frameworks: frameworks own agent reasoning graphs; workflow engines own durable state machines that survive crashes and human wait times.

Mechanically you care about exactly-once or at-least-once semantics, compensation/saga patterns, visibility of in-flight work, and how tool side effects are attributed to a case. Failure modes: fire-and-forget scripts that cannot resume, workflows that become a second Monday board, and engines that hide payload PII in unmanaged logs.

Members span productized builders (Dify) and code-first durable runners (Inngest, Hatchet, Burr, Dapr Agents, PocketFlow, deer-flow, Microsoft Agent Framework). Prefer durable engines when the bottleneck is days-long approval and retry; prefer agent frameworks when the bottleneck is tool-using reasoning inside a short horizon.

In a company OS, workflow orchestration is how propose→gate→execute becomes recoverable. Feature maps such as Verify business effect, not API 200 and Agent Building Platform mark the job: closed loops with evidence, not vibes.

Inline members for audit: Dify Inngest Hatchet Burr Dapr Agents PocketFlow deer-flow Microsoft Agent Framework. Features: Verify business effect, not API 200 Agent Building Platform. Related terms referenced: Frameworks, Runtime, Tool Integration.

For this research catalog the acceptance test is boring and strict: after wiring the pack, can a second person replay the same scenario and get the same measurable outcome? If not, the page is still a brochure. Document the scenario, the expected number, and the log line that proves it. That habit is what separates a deepened taxonomy cell from a landscape screenshot.

Also record what you refused: tools not connected, corpora not ingested, metrics not collected. Refusals keep the cell honest when marketing pages claim universality. A taxonomy essay that only lists winners teaches less than one that names the skip conditions next to the install path.

Keep the essay technical enough that an engineer can argue install order — and short enough that a reader finishes it before opening the right-rail member list. Prefer primary docs and repo evidence over landscape blurbs when the right-rail packs disagree.

Operational discipline for this cell: name the install artifact, the health check, and the rollback. Prefer one golden path documented against a member pack in the right rail over five half-wired demos. When packs disagree, believe the primary repository README and a failing test you can re-run — not the landscape one-liner. Measure latency, cost, and error rate on a frozen scenario before declaring the subcategory “covered.” If you cannot point at a log line that proves the scenario, the essay is unfinished even when the word count clears the audit floor.

Cross-link greedily but honestly: every taxonomy wikilink should change a reader’s next click, and every pack slug should resolve to a real pack. Do not invent members to decorate the prose. Prefer fewer true links over many decorative ones. Keep Monday-shaped typing out of the runtime story; observation and ledger remain senior to any agent UI that retypes reality.