A LITTLE BACKROUND:

I spent 6 years as the founding engineer at a programmatic video generation company. This was before AI video. We were doing conventional compositing at scale, at a price point that's still below what AI-generated video costs today.

The hardest part was never the video rendering. It was the orchestration.

Every video job was a dynamic workflow. Different assets, different templates, different downstream services, all changing constantly. And none of the services involved should've needed to understand the bigger picture. A rendering service should just render. A transcoding service should just transcode. Each one operating in isolation, focused on its core intent, with no knowledge of the ecosystem around it.

The real problem was bringing them together. How do you compose independent services into workflows that change as fast as the business needs them to, without redeploying anything?

I never solved that problem the way I wanted to. Tools like Zapier and Make existed, but they weren't built for developers. They were built for non-technical users connecting apps through a UI. You couldn't version control a workflow, you couldn't programmatically create one, and the execution model was "hope the server stays up." n8n was closer to developer-friendly, but still no real durability, no SDK, and no way to treat workflows as code alongside everything else in your stack.

The founder and I had a falling out after 6 years and I left the company. But the problem stuck with me. I'd spent years watching the same pattern: services that worked perfectly in isolation, but the glue between them was fragile, tightly coupled, and required a deploy every time the workflow changed.

---

WHY NOW!

With serverless architecture, the pieces finally exist to do this right. You can deploy services rapidly (Cloud Run, MCPs, whatever) and they just work as HTTP endpoints. The missing piece was always the orchestration layer. Something that could compose these services dynamically, with real durability, without deploying new code every time a workflow changes.

---

WHY NOT N8N!

I know people will ask "why not n8n?" Honestly, I didn't come at this from the no-code automation world. I came at it from Temporal. The starting point was durable execution, not connecting apps. The visual builder came later because I realized not everything needs to be code. But the foundation is Temporal's execution model, not a traditional automation tool with reliability bolted on after the fact. They overlap on the surface (both have a canvas, both wire up API calls) but they're built from opposite ends.

So I built it. Being a bit of a completionist (and admittedly a weirdo), I figured I'd see this model all the way through.

---

TEMPORAL.IO

Why Temporal matters here. The core insight is that workflows need to survive failures. Not "retry from the beginning," but actually pick up where they left off. Temporal gives you event-sourced execution, replay on crash, and per-item isolation.

In practice that means forEach batches run each item as its own Temporal child workflow, item 500 fails and the other 9,999 keep going, retry just that one. AI agents (ADK agent nodes) run as durable Temporal workflows, so state persists across turns and you can do human-in-the-loop approval before the agent does anything dangerous. And if you already run Temporal Cloud, you can plug in your own namespace and Graph Compose uses it (BYOK).

---

OPEN SOURCE

What's open source. Open-core. Core types, schemas, graph validation, and a runtime that executes HTTP DAG workflows on your own Temporal (the @graph-compose/runtime package) are AGPL-3.0. The integrations service is open too (graph-compose/nodes). You can read exactly how the execution model works, run basic workflows on your own infrastructure, and contribute integrations. The kernel is designed to be extensible beyond HTTP, the node execution contract is generic, so addin...