2 posts tagged with "Temporal"

If you've built anything agentic in the last year, you know the shape of it: an agent that plans steps, calls tools, reflects on the result, and loops until it hits a goal. Defined in code - a graph of nodes, a crew of roles, or a hand-rolled loop around an LLM call and a tool list. It works in the demo. Then you try to ship it.

The wall everyone hits is the same one: the agent's autonomy is exactly what makes it ungovernable. What tools is it allowed to call? When does a human get to approve before it does something irreversible? What does the trace look like six weeks later when compliance asks what happened on instance #48213? And what happens to the half-finished run when the worker crashes while the agent is waiting three days for a human to click "approve"?

This post is about answering those questions with a BPMN engine - not by replacing the agent, but by giving it a process to live inside. Where it's useful, we'll be concrete about what QuantumBPM gives you for each piece, because "a BPMN engine could do this" and "here is the endpoint you call" are very different levels of promise.

When we started designing QuantumBPM's process engine, we ran into the same wall every workflow tool runs into: how do you make execution durable? Survive worker crashes, network partitions, weeks-long timers, replay after restart, exactly-once activity semantics? The honest answer turned out to be: don't build that yourself.

This post is about the bet we made — running BPMN on top of Temporal — what it cost us, what it bought us, and why we think Temporal developers are the audience that benefits the most from a BPMN layer sitting above their existing investment.