Let the workflow keep running after the request is gone

Long-running work becomes reliable when execution is treated as a lifecycle rather than one HTTP response that must remain open until every model, tool, and external service has finished. Edgaze gives each run a durable identity, canonical status, ordered events, explicit terminal outcomes, and a result that remains available after the initiating request or browser session ends. That lets a product acknowledge work immediately, show meaningful progress, recover from a lost connection, and complete the same run instead of accidentally starting another one.

The caller submits schema-valid input, receives an accepted run identifier, and stores it beside its own user or job record. Edgaze can continue through model calls, external APIs, loops, delays, and supported retries while status and step events accumulate on that run. A foreground interface can poll while the user waits; a backend can use signed webhooks to react after the original request is gone; and support tooling can query the same canonical record later. The integration only declares success when the run reaches completed, and it treats failure, cancellation, and a compute-limit stop as distinct outcomes with their own billing and recovery behavior.

Research, scraping, media generation, external API work, repeated transformations, and deliberate delays can exceed normal request windows even when nothing is wrong. Trying to hide that reality behind a long-held synchronous request creates brittle behavior: proxies time out, mobile connections disappear, users refresh the page, and the caller cannot tell whether the work stopped or merely became unreachable. A durable run makes acceptance and completion separate, observable events.

The public API reflects that model directly. POST /runs validates the request and returns 202 with a run id and status URLs. The product stores that id and can query GET /runs/{id} until the workflow reaches a terminal state. Marketplace buyers and MCP-connected agents use different interfaces, but they rely on the same underlying lifecycle. Closing a browser or ending a chat turn does not erase the execution record or make a fresh run necessary.

This separation matters most when the workflow has financial value or external side effects. An email campaign, research report, generated video, or batch of tickets should not be repeated simply because the initiating connection timed out. An idempotency key prevents an ambiguous retry of the same request from creating a second billable execution. If the first run genuinely fails and the user wants another attempt, the application creates a new key so the intent to execute again is explicit.

A spinner only says that the interface is waiting. Ordered durable event records can say when the run started, which supported step progressed, and which terminal event ended the execution. Each event carries a monotonic sequence number and timestamp, so a client can request the next page after the last sequence it processed. That makes it possible to build a progress view, a support timeline, or a debugging surface without treating transient client state as the system of record.

Choose the delivery mechanism according to the user experience. Polling every one to three seconds is straightforward while a person is actively watching. Events add step-level context. Optional streaming can improve immediacy while the connection is healthy. Signed webhooks are appropriate when a backend must react after the foreground request has ended. None of these should create a second notion of status: the canonical run response remains the authoritative place to read terminal state and output.

Good interface copy should tell the user that they may safely leave and return, then make the run easy to find in history. It should also distinguish quiet from stuck. A workflow can spend time inside a provider or a long node without emitting a constant stream of updates. The application can show the last known event and elapsed time honestly rather than manufacturing progress percentages that the runtime never supplied.

Completion, failure, and cancellation are explicit terminal outcomes, and billing follows the outcome rather than the click that started the job. A successful wallet-funded run settles the displayed price, while a successful bundle-funded run consumes one matching prepaid run. Ordinary failures and cancellations do not keep the creator margin or consume a bundle run. Demos and builder tests remain free regardless of outcome.

A run stopped at its compute limit is deliberately shown separately from an ordinary failure because work already consumed may remain charged. Applications should preserve that reason rather than reducing every non-success state to failed. The same is true for an invalid input or spend cap rejected before execution: those are request-time problems and should lead the user back to a field or funding decision, not to a generic retry loop.

Cancellation is also a real state transition, not proof that every provider operation vanished instantly. A product can request cancellation for an eligible in-flight run, then observe the recorded terminal state and present its documented billing outcome. For results that finish after a person leaves, surface the Edgaze run URL alongside your own notification so there is a durable place to inspect the output and its history later.

The embedded Blog to Thread workflow makes the lifecycle concrete: one submitted source can move through several transformations before a final result exists. Use a graph like this to test what your product shows at acceptance, during quiet periods, and at every terminal outcome—not only the happy path.

Open the embedded Blog to Thread template below and inspect how one input becomes a multi-stage result. Reuse it when useful, but first identify which events and final output your own interface needs so the graph and product language agree. Use the template. Resolve the current input schema, submit valid fields with an idempotency key, and keep the returned run identifier instead of waiting for the whole workflow in one request. A 202 response means accepted, so do not show the job as finished at that point. Read the creation contract.

Fetch the run itself whenever the product needs authoritative status, timestamps, output, charge information, or terminal failure detail. Use the ordered event feed for step-level progress, but let the run record remain the source of truth for final state. See the run response. Verify webhook signatures against the exact raw body before parsing, reject stale timestamps, and deduplicate on the delivery id. Delivery is at least once and ordering is not guaranteed, so make downstream handlers idempotent and reconcile terminal runs if a missed event would create a correctness gap. Implement webhooks.