---
title: "What Replay 2026 Actually Changes for Teams Building Agents on Temporal"
date: 2026-10-13
author: "Anton \"JD\" Titov"
featured_image: "https://spiralscout.com/wp-content/uploads/2026/10/image.png"
categories:
  - name: "AI Agents & Automation"
    url: "/blog/category/ai-expertise.md"
tags:
  - name: "AI Agent Architecture"
    url: "/blog/tag/ai-agent-architecture.md"
  - name: "Cost Governance"
    url: "/blog/tag/cost-governance.md"
  - name: "Durable Execution"
    url: "/blog/tag/durable-execution.md"
  - name: "LLM Observability"
    url: "/blog/tag/llm-observability.md"
  - name: "Multi-Tenancy"
    url: "/blog/tag/multi-tenancy.md"
  - name: "Production AI Agents"
    url: "/blog/tag/production-ai-agents.md"
  - name: "Temporal workflows"
    url: "/blog/tag/temporal-workflows.md"
  - name: "Wippy AI"
    url: "/blog/tag/wippy-ai-2.md"
---

# What Replay 2026 Actually Changes for Teams Building Agents on Temporal

[Durable execution](https://spiralscout.com/glossary/temporal-microservices-orchestration-platform) isn’t the hard problem anymore. Your [agents](https://spiralscout.com/glossary/ai-agent) survive crashes, restarts, and the 2am failures better than anything you’d build yourself. What’s still hard is everything above it: [the application layer](https://spiralscout.com/glossary/wippy) that turns a workflow that runs into a product a company can actually operate.

[Replay 2026](https://temporal.io/replay/2026#video) shipped five primitives that close real pieces of that gap: multi-tenancy, streaming, large payloads, versioning, and cost attribution. [We wrote the Temporal PHP SDK](https://spiralscout.com/case/temporal-php-sdk-for-microservice-platform), we’ve spoken at Replay, and we’ve shipped more [production applications on Temporal](https://spiralscout.com/services/ai-implementation/agentic-ai-with-temporal) than most teams will in a decade. Here’s what each of the five actually solves, and where it stops.

## Key Takeaways

- Durable execution solves the workflow primitive. It does not solve multi-tenancy, permissions, or the interface a business actually runs on.
- Five new Temporal primitives from Replay 2026 close real gaps: multi-tenancy, streaming, large payloads, versioning, and cost attribution.
- Four of the nine features discussed here are still Public Preview or pre-release, not GA. Build against that reality, not the announcement.
- The two things you cannot retrofit cleanly, multi-tenancy and permissions, need to be designed in before anything else.
- Everything Temporal doesn’t own is still yours: the review UX, the business dashboard, the failure semantics a customer actually understands.

## The Shape of the Problem

Durable execution works at the level of the workflow: run this reliably, retry on failure, resume after a crash, wait as long as you need. That’s the correct primitive, and it’s hard enough to build correctly that you shouldn’t try. Temporal exists precisely so you don’t have to.

Your users, however, don’t think in workflows. They think in tenants, approvals, dashboards, budgets, and outcomes. Between the primitive and the person sits a layer, and that layer is the application. Most teams underestimate it because the demo works, and the demo always works. It’s the three months after the demo where the application layer is what actually breaks.

 ![The application layer between the business user and durable execution on Temporal](https://spiralscout.com/wp-content/uploads/2026/10/replay-2026-application-layer-above-temporal-768x403.png "The application layer between the business user and durable execution on Temporal")

Everything in the middle box is yours to build. Here’s what Replay 2026 changed about filling it in.

## Temporal Primitives at a Glance

The five themes above map to these nine features.

**Primitive****Release Stage****What It Closes****What’s Still Yours****Task Queue Priority & Fairness**Generally AvailableCompute fairness across tenantsNamespace strategy, isolation guarantees**Principal Attribution**Pre-releaseNon-spoofable invocation recordCapability scoping, authorization logic**Workflow Streams**Public PreviewLive update primitive for a paused workflowRouting, review UX, escalation**External Storage**Public PreviewLarge payload offload from historyWhat belongs in the durable record**Worker Versioning**Generally AvailableVersion pinning for in-flight workSchema and config migration story**Worker Status UI**Public PreviewTask queue worker visibilityPart of the telemetry picture, not all of it**OpenMetrics Endpoint**Generally AvailableExecution telemetry: what ran, whenThe semantic layer: why it went wrong**Billing API**Generally AvailablePer-namespace cost dataAttributing spend to a tenant or feature**Billable Action Count**Generally AvailableGranular action-level usageSame as above## 1. Multi-Tenancy Is a Foundation, Not a Feature Flag

The moment more than one customer or team shares your system, their data, their agents, and their failures have to stay in their own lane. Durable execution runs your workflows reliably, but it doesn’t decide who’s allowed to see which run, or keep one tenant’s context out of another tenant’s agent.

That’s on you: the tenancy model, the namespace strategy, the per-tenant limits, the isolation guarantees. Retrofit this later and you end up touching every part of the system at once, which is exactly why teams that treat it as a foundation ship, and teams that treat it as a later concern end up rewriting.

Temporal’s Task Queue Priority & Fairness, now Generally Available following Replay 2026, handles half of this by distributing compute across tenants so no group starves the others under load. The rest of the boundary, deciding who can see what, is application code you still own.

## 2. Principal Attribution Closes the Audit-Trail Half of Your Permission Model

An agent that can take actions needs to be told what it’s allowed to touch, and that has to be architecture, not a policy document sitting in a wiki somewhere. Temporal’s Principal Attribution, in pre-release as of Replay 2026, gives you a non-spoofable record of who invoked an execution. That closes the audit-trail half of the problem. What it doesn’t do is decide what an agent may do before it does it. Capability scoping per agent, authorization at the point of action, that’s still the application layer, and it’s what we cover in [why agent governance is an architecture problem](https://spiralscout.com/blog/ai-agent-governance-architecture) and [how a production agent system assumes the model will try something wrong](https://spiralscout.com/blog/agentic-ai-architecture-production-patterns).

## 3. Workflow Streams Gives the Pause a Live Surface

Durable execution already made the pause itself easy. A workflow can wait indefinitely for a human to steer, correct, or approve, without holding resources or burning compute the whole time. Workflow Streams, in Public Preview following Replay 2026, adds the missing piece: a primitive for pushing live updates to whatever surface that human is actually watching while they decide. The routing, the review experience, and what happens when nobody answers in time are still yours to build, and that’s what we walk through in [what makes a review gate work, and what turns it into a bottleneck](https://spiralscout.com/blog/human-in-the-loop-ai-workflows).

## 4. A Workflow Is Not an Interface, and Your Users Are Not Engineers

The people who need to configure, run, and monitor a workflow are usually not the people who wrote it. A backend that executes flawlessly is invisible to a business user, and invisible systems don’t get adopted, no matter how well they run. Somebody has to build the forms, the dashboards, and a run history a non-engineer can actually read and act on. None of this has anything to do with execution reliability. It has everything to do with whether the system earns its place in someone’s actual job, and it’s usually the largest chunk of work in the whole project, precisely because it never shows up in the proof of concept.

## 5. What the User Watches and What You Durably Commit Are Two Different Systems

Agents produce tokens and intermediate steps that users want to watch in real time, but the live stream and the durable record don’t share the same guarantees or the same failure modes. Show the user a token you haven’t committed and a crash makes you a liar. Commit before you show it and the experience feels dead. Reconciling the two without double processing or lost updates is a design problem most teams meet late, once it’s already expensive to fix. Workflow Streams gives you durable streaming built on Temporal’s signal and update primitives, which is the right foundation to build on. How you present it, batch it, and guard it at the application level is still your call.

## 6. AI Moves Big Blobs, and Your Workflow History Is the Wrong Place for Them

Embeddings, retrieval context, documents, model outputs, these are large, and pushing them through workflow history bloats it fast. You end up building external storage, references, and cleanup just to keep the durable record lean. Temporal’s External Storage, in Public Preview as of May 2026, wires large payloads through S3 or a custom driver instead of history, which is exactly the primitive you want here. What’s still a design call you make: deciding what belongs in the durable record versus external storage, and keeping references coherent across a long-running agent.

## 7. Long-Running Work Outlives Your Deploys

A workflow you started last week has to finish correctly next week, even after you’ve shipped new code in between. Managing versions, migrations, and progressive rollout so an in-flight execution doesn’t break on deploy is ongoing operational work, and most teams discover it the hard way the first time a deploy corrupts a running job. Temporal’s Worker Versioning went generally available at Replay 2026 and pins running workflows to the version that started them, which removes a whole category of patching headaches. The application-level story, schema changes, config changes, how a half-finished business process migrates, is still yours to own.

## 8. “Runs on My Machine” Is Not a Product

Getting a working system from a repository to something a customer can install and run is its own engineering effort. Dependency resolution, configuration, install-time setup, the difference between code that works when you run it and software that works when someone else does, none of this is visible until the first time you try to hand the thing to a team that isn’t yours. Then it’s the only thing that matters for a week.

## 9. Two Primitives Cover the Execution Layer of Observability, Not the Semantic Layer

Temporal’s Worker Status UI, in Public Preview as of Replay 2026, together with the existing OpenMetrics endpoint (Generally Available), gives you solid execution telemetry: what ran, when, and how. Neither one tells you why an agent made a bad decision, which is the question you actually get asked once something goes wrong. That semantic layer, tracing across the [LLM](https://spiralscout.com/glossary/large-language-model) call, the tool call, and the human step to reconstruct what the agent was actually trying to do, is something you still have to assemble yourself. We cover what that requires in [how enterprise AI agents actually make it to production](https://spiralscout.com/blog/agentic-ai-architecture-production-patterns).

## 10. Agents Spend Money Unpredictably, and Someone Has to Answer for It

Agents make expensive, variable model and tool calls, and at the end of the month someone always asks which customer or feature burned the budget. Knowing the answer, and enforcing a limit before the bill arrives instead of after, is a system you have to build. Temporal’s Billing API and Billable Action Count metric, both now Generally Available, give you granular visibility into Temporal usage per namespace and workflow type, which covers the platform half of the problem. Attributing LLM and tool spend to a tenant, a feature, or an agent, and cutting it off at a threshold, is still your layer.

## 11. A Retried Workflow Is a Technical Success and Still a Business Failure

Durable execution retries and recovers beautifully at the technical level, and honestly, that’s most of why you chose it. But “the agent tried three times and still couldn’t complete the customer’s order” needs a business-level answer, not a stack trace. What the user sees, what gets escalated to a human, what compensating action runs, that’s application logic. Mapping the engine’s retry and failure semantics onto outcomes a business actually understands is a translation layer only you can write, because only you know what the failure means to the customer on the other end.

## 12. Every New App Should Not Start From Zero

The first application teaches you patterns you’ll want in the second one. Without a way to package those patterns as installable, versioned, dependency-aware building blocks, every new app restarts from near zero, and your velocity never compounds. This is the deepest gap on the list, because durable execution operates one level below the reusable business component, at the workflow primitive. It’s also the one that pays off most over time, since every reusable piece makes the next application cheaper to build than the last. This is the frontier, and it’s where the durable-execution ecosystem is heading next.

## How It Chains Together

None of these twelve live in isolation. A single agent request touches most of them in sequence, and the real work lives in the connective tissue between them, not in any one box.

 ![How a single agent request flows through Temporal and the application layer](https://spiralscout.com/wp-content/uploads/2026/10/replay-2026-agent-request-flow-on-temporal-768x243.png "How a single agent request flows through Temporal and the application layer")

Temporal makes the boxes reliable. The arrows between them, plus tenancy and permissions wrapped around the whole thing, are the application, and that part doesn’t ship itself.

## Where to Start

You don’t need all twelve on day one, and trying to build them all at once is usually how projects stall. Most teams need multi-tenancy and agent permissions first, since those are the two you can’t retrofit cleanly. Human review and a usable interface come next, the moment a real user gets involved. Cost governance and business-level failure semantics tend to arrive right after the first surprising bill, or the first support ticket a dashboard couldn’t answer. Composability is last, but it’s the one that changes how fast everything after it moves.

## The Application Layer Is the Only Part You Actually Own

Temporal’s primitives will keep improving, and the ones in this post will move to GA on their own timeline whether we write about them or not. What doesn’t change is who owns the layer above it. That’s the part a client keeps, extends, and runs without depending on whoever built it first. Every system we ship on [Wippy](https://wippy.ai) is architected around that: you own the code, the data model, and the agents, and there’s no dependency on us to keep any of it running.

## Stuck Between a Workflow That Runs and a Product You Can Ship?

If you’re looking at this list trying to decide which of the twelve to build first, that’s a conversation we have most weeks. Start with an [AI Readiness Audit](https://spiralscout.com/services/ai-implementation/ai-readiness-audit) if you want a second set of eyes on where your system actually stands. We wrote the Temporal PHP SDK, we speak at Replay, and we build the application layer on top of durable execution so teams can ship the product instead of the plumbing.

 [  
   
 Talk to the Team  ](https://spiralscout.com/contact)