Workflow Orchestration

What's in this pack

This pack collects the eight production-grade workflow engines that AI teams reach for when a prompt-in-a-loop stops being enough. Each one solves the same trio of problems — schedule, retry, observe — but with different ergonomics. Pick by where your team already lives (Python, Node, no-code, JVM).

Every entry is open source and self-hostable. Hosted SaaS tiers exist for most, but this pack documents the OSS install path first.

Why orchestration matters for AI agents

Prompts are deterministic the first time you run them and a coin flip every time after. Add a real-world action — call an API, write to a database, send a Slack message — and "it failed once at 3am" becomes a weekly event. A workflow engine solves three things:

1. Idempotency. Steps can replay safely. If the LLM call succeeded but the next step crashed, you don't re-bill the API on retry.
2. Backoff and dead-letter. Failed steps retry on an exponential schedule, then land in a DLQ where a human can inspect.
3. Observability. Every step is recorded with inputs, outputs, latency, and cost. When the agent does something weird, you can replay the exact context it saw.

Without one of these, your agent is a Jupyter notebook with extra steps. With one, it's a service.

Install in one command

# Install the entire pack (manifests for all 8 engines)
tokrepo install pack/workflow-orchestration

# Or pick the one your team uses
tokrepo install n8n
tokrepo install prefect
tokrepo install inngest

The TokRepo manifest gives you Docker Compose / Helm starting points plus the agent-friendly defaults (idempotency keys, retry policies, observability hooks). Run tokrepo uninstall <slug> to remove.

Common pitfalls

• Treating retries as infinite. Default retry counts on most engines are 3–5. If your LLM provider is having a bad hour, you'll burn the budget and still fail. Cap retries at 3 for paid LLM calls and route the failure to a slower fallback model.
• Idempotency keys done wrong. A common mistake is keying on request_id that changes per retry. Key on the input hash so retries deduplicate against the same logical task.
• Missing token-cost observability. Vanilla orchestrators record latency but not LLM token spend. Wrap your model call to emit a tokens_in / tokens_out / cost_usd metric per step, otherwise you'll blow past budget and not know which workflow did it.
• Choosing the wrong scheduler granularity. Cron-based engines (n8n, Activepieces) struggle with sub-minute triggers. If you need event-driven sub-second response, use Inngest, Trigger.dev, or Temporal.
• Hosting the engine on the same node as the agent. A runaway agent will OOM the orchestrator. Run the engine on a separate node or container with hard memory limits.

When this pack alone isn't enough

Workflow orchestration is the durability layer. It does not give you the agent itself, the LLM gateway, or the eval. Pair this pack with:

• Python Agent Frameworks for the actual agent code that runs inside each step
• MCP Server Stack if you want orchestrator triggers callable by AI agents over MCP
• LLM Eval & Guardrails to bake an eval step into every workflow before production output ships

Together those four packs are the minimum stack for any AI workflow you'd let run unattended.

How to choose between the eight engines

If your team already writes Python data pipelines, Prefect is the lowest-friction onboarding because tasks look like decorated functions. If your team is TypeScript-native and event-driven, Inngest wins on developer experience. If you need non-engineers to build their own automations, n8n or Activepieces unlock that audience with a visual canvas. Temporal is the right answer when you genuinely need distributed-systems guarantees across thousands of long-running activities. Kestra suits JVM shops that want declarative YAML pipelines with strong plugin discovery. Trigger.dev is for product engineers shipping background jobs in serverless TypeScript apps. Windmill is the dark-horse pick when you want polyglot scripts plus a UI for ops. Most teams end up running two engines in parallel, not one — that's normal, and the manifest defaults in this pack make sure both inherit the same retry and observability conventions.