Workflows Shouldn't Disappear When You Close the Tab

For a while, one thing about Edgaze kept bothering me more than it probably should have. A workflow could run successfully, produce a useful result, and then effectively vanish. You could see the output when the run finished, but there was no proper place where runs lived afterward. If you closed the tab, came back later, or left while something longer was still executing, the whole experience started feeling strangely temporary. The workflow itself might have done real work, but the product treated that work almost like a chat message you were expected to look at immediately and then forget about. That is fine for a quick prompt. It is a terrible model for a workflow. So I rebuilt runs around a different assumption: a workflow execution is a job. Jobs have state. They can take time. They should continue even if nobody is staring at the screen. They should have a history. You should know whether they succeeded, failed, or are still running. And when they finish, the result should still exist somewhere obvious. Edgaze now has one unified Runs view for every way a workflow can execute. Runs started from Workflow Studio, the marketplace, public demos, the API, and MCP all end up in the same place. The source can be different, but the underlying object is the same: something was asked to run, Edgaze executed it, and there is now a durable record of what happened. That sounds almost painfully obvious once it exists. Previously, different execution surfaces could feel like separate experiences. A test run in the builder felt like one thing. A marketplace run felt like another. API execution happened somewhere else entirely. But the user does not really care which frontend button or protocol initiated the work. A run is a run. Unifying them also makes longer workflows much more natural to use. You can start something and leave. The workflow keeps executing without the browser staying open, and when you return, the run is still there with its current status or final result. There is no need to keep a tab alive like you are guarding a download from 2007. Once a run finishes, the output remains attached to it alongside the information you actually need later: how long it took, what it cost, where it came from, and whether it completed successfully. Previous executions stay in the same history, which means a workflow starts becoming something you can actually operate over time rather than repeatedly firing into the void. You can share a result directly from the run, download it, or run the workflow again. That last part matters more than it sounds because repeat usage should not require rediscovering the workflow and reconstructing what you were doing from scratch. If a run produced something useful, the next action should be close to the result. The Runs panel can also work in the opposite direction. Instead of starting with a workflow and eventually arriving at a run, you can start from Runs itself, search the marketplace, see the price before execution, add the inputs, and launch the workflow directly. That turns the page from a passive history screen into something closer to an operating surface for workflows. I think this becomes more important as workflows get more serious. A five-second prompt chain can feel disposable because the cost of rerunning it is tiny and the result may only matter for a moment. But a workflow that researches dozens of companies, processes documents, calls several services, or runs for half an hour is doing actual work. Treating the result like a temporary UI state starts to feel ridiculous. There is also a reliability aspect to this. If a run is a first-class object with persistent state, the frontend no longer has to be the thing holding the experience together. The browser becomes a window into execution rather than the owner of execution. You can leave, refresh, switch devices, or come back later without changing what the runtime is doing underneath. That separation is important. The workflow should run because you asked Edgaze to run it, not because a React component is still mounted somewhere. The larger direction here is that workflows should feel less like interactive AI demos and more like pieces of work being handed to a system. Start the job. Go do something else. Come back when it is finished. Inspect the result. Share it, download it, or run it again. That is much closer to how real work behaves. A workflow should not demand your attention just because it is executing. And it definitely should not disappear because you closed the tab.