Durable execution with Temporal

Why this conversation

Any system that runs work over minutes, days or longer has to answer one question: what happens when it stops halfway? Restart from the beginning and you may repeat steps that should only happen once. At AGNTCon + MCPCon Europe in Amsterdam the host sat down with Simon Emms, Staff Solutions Architect, EMEA at Temporal, to hear how durable execution answers it. The host had a personal interest: he already runs Temporal under Postiz, the open source social media platform he uses to publish his posts, so every post he publishes goes through it.

The story of the week it was filmed is in AGNTCon + MCPCon Europe 2026: who we met.

Restart where it stopped

Simon describes Temporal as a durability framework and explains it with a deliberately simple bank transfer. Step one validates the data: someone sends bank details, and they must be real numbers. That needs no distributed system. Step two moves the money out of the account into a holding account; those are the bank’s own accounts, so there is reasonable confidence about what is going on. Step three sends the money to the receiving bank, a third party over which there is no control.

If that third step fails because the other side is down, you do not want to restart from the beginning, because you would keep taking money from the account, upset the customer, and have a large problem to solve. Temporal provides the durability: when the work restarts, it knows exactly where it was and carries on from that point, so it completes as intended. The host compared it to transactions in a database, and to an agent that gets interrupted and should not have to start again from the beginning.

Open source and Temporal Cloud

Temporal is completely open source. You can use it without talking to the company, run your own servers and build your own workflows from the documentation. That works well when developers are starting out, or for a couple of teams.

At large scale it is different. Temporal’s biggest customer sends 150,000 actions every second, every day. Even a few hundred actions per second calls for resilience, and building that into a self-run deployment takes a lot of time. That is what Temporal Cloud is for: Temporal manages the service and all the updates, and the customer only has to build the workflows.

Why not just a queue

Simon is a fan of queues and was careful not to criticise them, but he sees two kinds of limitation: technical and cultural. On the technical side, queues are first in, first out, which is fine if that is what you need. It becomes difficult when you want to send something and then do nothing for 20 minutes, or for three years, which some customers do. A queue takes the data and sends it out; Temporal takes the data and knows when to send it. A workflow can pause for a year, and the workers use no resources while it waits.

The cultural point comes from his time as a platform engineer, and he admits he was as guilty of it as anybody. With a queue, a developer asks the platform team to set something up. Then a mistake turns up, the platform team has moved on to other work and cannot get to it for three days, and the developer is stuck. Temporal is code first, so the developers who write the workflows also configure what they need, with no other team involved.

Getting started

Start at temporal.io, where the instructions are, along with a large set of use cases. The simplest step is to open your code editor: there is a CLI that runs a dev server locally, so you can start building straight away.