Runtime 1.4: The Part of Edgaze You're Not Supposed to Notice

I've spent the past few weeks rebuilding a part of Edgaze that, if everything goes well, most people will never think about. The runtime. Running a workflow once is easy. You take some input, execute a few steps, call a model or an API, return the result, and everything looks great in a demo. Running thousands of workflows reliably is a completely different problem. Some finish in a few seconds. Others can run for minutes or hours. APIs time out. Model providers have bad days. Workers restart. Containers move. Networks disappear for a moment. A workflow can make it through ten successful steps and then fail on the eleventh because some external service decided not to answer for three seconds. At that point, the problem is no longer "how do we run these steps?" It becomes "how do we make sure this piece of work survives everything around it going wrong?" That is what Runtime 1.4 is about. The biggest change is that execution state is now durable. A workflow is no longer tied to the life of one process or one worker. If a worker restarts in the middle of a run, the run does not need to disappear with it. The system already knows what completed, what is still pending, and where execution should continue. That matters much more than it sounds. Imagine a workflow with fifteen steps. The first twelve complete successfully. Step thirteen calls an external API and times out. The dumb version of recovery is to start the whole thing again. Now the first twelve steps run twice. You pay for model calls again, APIs get called again, data gets processed again, and any step with side effects becomes a much bigger problem. If one of those earlier steps sent a message, created a record, or triggered something external, "just retry the workflow" stops being a harmless solution very quickly. Runtime 1.4 treats completed work as completed work. If twelve steps finished, they stay finished. Recovery continues from the right place instead of pretending the previous execution never happened. Retries are handled at the runtime level as well. I do not want every creator on Edgaze building the same little retry system into every workflow because APIs occasionally fail. That is infrastructure work, and infrastructure work should live in the infrastructure. A creator should decide what the workflow does. They should not have to spend half their time thinking about exponential backoff because some model provider occasionally returns a 500. There is a bigger reason for this rebuild too: workflows are becoming longer-lived. A lot of normal web infrastructure assumes a request starts, does something, and finishes quickly. Workflows do not always behave like that. A workflow might need to wait for an API, pause for a period of time, process a large batch of data, or eventually sit around waiting for an external event before continuing. Once that happens, relying on a single process staying alive becomes a ridiculous assumption. An hour-long workflow should not require one worker to have a particularly lucky hour. The execution itself has to be durable. Workers should be disposable. Infrastructure should be allowed to restart, move, deploy, fail, and recover without taking the run down with it. Cancellation, recovery, retries, and run state need to be properties of the execution system rather than hacks attached to individual workflows. That is what Runtime 1.4 moves Edgaze toward. The funny part is that almost none of this should be visible. Nobody comes to Edgaze because they are excited to inspect our retry semantics. A buyer does not care which worker ran step nine. They do not want a notification explaining that one provider timed out and the runtime recovered from it beautifully. They want the thing they paid for. Creators should not have to care much either. If somebody is building a workflow that researches companies, summarizes documents, processes leads, or coordinates several services, their mental energy should go into making that workflow good. Not into wondering what happens if a container dies halfway through it. The runtime should absorb that complexity. There is an odd thing about infrastructure work where the better you do it, the less anyone notices. You can spend weeks rebuilding execution, recovery, state handling, cancellation, and retries, ship the entire thing, and the ideal user response is basically nothing. No complaints. No broken runs. No "why did this execute twice?" messages. No one even realizing a worker restarted underneath them. That is success. And the more valuable the workflows become, the more important this gets. A three-second toy workflow can fail and be refreshed. A workflow sitting inside someone's actual business process cannot operate at that standard. Once people depend on a workflow to process customers, research leads, transform data, or trigger other systems, reliability stops being a backend concern and becomes part of the product itself. A marketplace full of powerful workflows is not very useful if the execution underneath them is fragile. So Runtime 1.4 is one of the least visible things I have shipped on Edgaze, but probably one of the most important. Creators build the workflow. Buyers press Run. Everything ugly in between is our problem.