Show HN: Graph Compose – Temporal workflows with visual builder, SDK, and AI (graphcompose.io)

13 points by jalapenobasil ↗ HN
Hey HN. Graph Compose is a hosted platform for orchestrating API workflows on Temporal. You define workflows as graphs of nodes (HTTP calls, AI agents, iterators, error boundaries) and everything runs as a durable Temporal workflow under the hood.

Three ways to build the same graph: a React Flow visual builder, a typed TypeScript SDK (@graph-compose/client), and an AI assistant that turns plain English into a graph.

Open-core: the execution foundations and integrations service are AGPL-3.0. The platform orchestrator, visual builder, and AI assistant are proprietary.

Longer backstory on why I built this in the first comment. Would love feedback, especially from anyone who's dealt with the "services work fine, the glue between them doesn't" problem.

Docs: https://graphcompose.io/docs

17 comments

[ 2.3 ms ] story [ 38.5 ms ] thread
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...

Ohhh this looks promising. Gonna play with it this weekend
Question on the batch handling, when a workflow fails in a batch, what's the debugging experience like? Is it easy to spot where it failed?
Yeah actually, when a workflow fails, you have a couple of options:

a) Continue on Error - Where a parent workflow continues despite a child failing b) You can re-run the child workflow - this allows you to essentially repair the state of the entire workflow orchestration in the case something fails.

Other than that, a batch would be essentially defined as a bunch of JSON Directed Acyclic Graphs - so you could just re-run them all or a portion as required

I also realize I may not have answered this clearly:

- Workflow Visibility: This is built on Temporal, so you receive the same dashboard that Temporal.io valued at $2.5B offers for it's customers. This means you see every node being executed in live time

For those not familiar with temporal, this means you can see each node's failure state, alongside the reason, and so you can debug accordingly.

You can query this via API as well in the case you are fully programmatic, and don't want visuals - but everyone loves visuals

Have you looked at DBOS for the durable execution layer? Much easier to integrate and not nearly as heavyweight for you/your customers.
Docs look promising :eyes:. I'll give it a shot over the weekend.
This looks great, judging from the docs it should be pretty straightforward too. I'll have to try and build an AI agent with this.
This is looking great! Would definitely give this a proper try.
This is so cool! I have an idea of where I could use this, looking forward to putting together a PoC with it.
Yeah for sure, I'm trying to figure out the angle for it right now...

I'm thinking where it really shines is with vibe coding. So maybe something along the lines of `Vibe-code your workflows. Run them like infrastructure.`

The docs show Graph Compose has DAG execution, conditions, polling, timeouts, retries, and error boundaries. That is exciting for enterprise action workflows, but we would want Konekti to remain the semantic brain: process definitions, business rules, evidence, health, and process correctness should live there. Where do you draw the product boundary? What kinds of logic should absolutely stay outside Graph Compose, especially when the upstream system is a semantic process platform like Konekti rather than just a simple API?
Graph Compose already has visual authoring, SDK/API authoring, Al-generated workflows, confirmation nodes, run dashboards, node-level execution details, and webhooks. If Konekti starts feeding Graph Compose high-value operational signals, such as "this case needs escalation" or "this supplier pattern requires review," how do you prevent enterprise automation from becoming ungoverned chaos? What governance exists around workflow ownership, versioning, approval, change control, audit history, environment promotion, rollback, and disabling risky workflows?
What makes GC different from n8n or something like ActivePieces (open source project on GitHub)? I want to understand when it would be the right solution, and when a different tool is better suited.