Temporal's Agent History Has a 40-Fold Storage Gap

Teams building long-running agents should audit their workflow-history lifecycle as Temporal announces a $550 million Series E. At its public storage rates, keeping an extra gigabyte of history active rather than retained for 30 days creates a $29.48 consumption-cost gap—a concrete architecture question hidden underneath the funding headline.

The expensive part of waiting is what you keep

Temporal’s pitch is that work should survive the processes and services carrying it. Its September 14 announcement describes customers asking for agents that run for days, weeks, or months, including workflows that wait for human approval and resume after outages. That makes state management a production concern rather than disposable glue around a demonstration. The decision is not whether the new valuation looks impressive; it is which unfinished work the organization can afford to lose or reconstruct.

The company’s Durable Execution explanation describes preserving progress so execution can recover after failure. For an operator, that capability should be evaluated against an explicit recovery requirement: what must resume, which external effects must not repeat, and what evidence proves completion. A workflow engine can preserve execution state without deciding whether the agent’s answer was good or its proposed business action was authorized.

The financing is substantial. Temporal reports a $12.55 billion valuation, compared with the $5 billion post-money valuation in its February Series D announcement. Combining the earlier financing record with today’s figure gives (12.55 − 5) ÷ 5 × 100 = 151% growth. That is a valuation comparison, not growth in customer productivity, available capacity, or product reliability. It strengthens the case for vendor attention without settling a migration decision.

The release also reports more than 4,300 paying customers and 1.9 trillion billable actions in August. These are company-reported adoption figures, not independently reproduced measurements. They establish the scale of the proposition Temporal is presenting to buyers. They do not reveal the distribution of workloads or the economics of an individual customer’s agent. A short automation and a months-long approval process can inhabit the same platform while having very different cost drivers.

That difference is visible in the Cloud pricing documentation. Temporal separates Actions, storage, and the Cloud plan. Open executions use Active Storage; closed execution histories use Retained Storage. This is workflow history, not a vector database or an unlimited transcript subscription. The state in which that history lives affects the rate even when its byte count is unchanged.

The buyer who should investigate now has long-lived, history-heavy workflows or recurring recovery work that current infrastructure handles poorly. A team whose jobs finish quickly and already recover acceptably should not migrate because a financing announcement gave an old architecture problem a fashionable name. First establish the failure cost and the lifetime of the data. Then compare what the managed service would replace with what the team would still operate.

Forty prices for the same byte-hour

The published storage tariff lists $0.042 per GB-hour for active history and $0.00105 for retained history. Dividing the first by the second gives 40×. The unit matters: this is a rate comparison between lifecycle states, not a claim that every customer can cut its total Temporal invoice fortyfold. Included allocations, the amount of history eligible to move, and other services determine the actual saving.

To put that spread on a familiar clock, use the 30-day default retention period in Temporal’s optimization guide. Combining that documented interval with the public rates gives 30 × 24 = 720 hours. One extra GB held throughout that window costs 720 × $0.042 = $30.24 active, versus 720 × $0.00105 = $0.756, or about $0.76, retained. The difference is $29.484, rounded to $29.48.

Active history costs 40 times as much to keep

One extra GB held for 30 days · consumption only, beyond included allowances

This is a constant-volume comparison beyond included storage allowances, not an observed bill or a simulation of a growing agent. It compares equal byte-hours in different lifecycle states. It excludes Actions, the plan charge, any new execution’s active history, and external storage. The new execution cannot be assumed to consume nothing. Nor does the calculation prescribe deleting history when it is still needed for recovery or compliance.

The mechanism for changing that lifecycle is explicit. Continue-As-New checkpoints relevant state into a fresh execution, retaining the Workflow ID but assigning a new Run ID and Event History. The operator must decide what state crosses the boundary. Closing an old execution is not the same as completing the business process; the process can continue while the old history becomes eligible for the retained-storage treatment.

The implementation therefore deserves more than a timer copied from a tutorial. Identify safe checkpoint points, preserve the state needed to resume, and test approvals or messages arriving around the transition. A smaller history is useful only if the new execution still knows what work remains and what has already happened. The optimization guide recommends Continue-As-New for long-running workflows, but its existence does not certify every application’s checkpoint design.

Actions supply a second meter. Temporal’s billable-operation reference counts workflow starts, activity starts or retries, and various messages and timers. Pure workflow replay does not create billed Actions because it reconstructs state on the worker rather than performing new server-side operations. That distinction prevents a common budgeting error: equating every replayed line with a new charge, or assuming every retry is free because recovery is automatic.

The starting overage rate is $50 per million Actions, with progressive volume discounts, according to the pricing documentation. A real budget must apply the included allocation and tier schedule rather than multiply all work by the first rate. The Essentials plan also charges the greater of $100 monthly or 5% of consumption. Consequently, even a correctly calculated storage reduction need not lower the total invoice by the same percentage.

This is the infrastructure version of the Fugu distinction between cheap tokens and cheap completed work. A convenient unit price is only one term in the cost function. Durable execution adds value when it reduces retained engineering and recovery effort; measuring that benefit requires accepted outcomes and operational labor, not merely a lower storage subtotal.

The cheap checkpoint can be the costly mistake

The strongest objection to focusing on storage comes from Temporal itself. Its optimization guide says storage typically represents 10% or less of the bill for most workloads, with Actions usually dominant. The fortyfold rate gap is therefore a targeted diagnostic for history-heavy agents, not a universal optimization priority. If the account’s history fits inside its included allocations, this marginal comparison may have no immediate invoice effect at all.

The next mistake would be collapsing useful work boundaries to reduce Action counts. Temporal’s Activity-granularity discussion treats the number of Activities as a design decision about failure handling and visibility. The right question is which steps need independent retries and which completed effects must not be repeated. Combining them merely to make a dashboard cheaper can move cost into investigation and repair.

Local Activities have a different durability boundary. Their results become durable when the enclosing Workflow Task records the completion marker. A worker failure before that point can cause them to run again. Temporal recommends ordinary Activities for most production business logic, while reserving Local Activities for suitable short, idempotent work. Fewer history entries and lower latency are benefits only when the failure semantics fit the operation.

Retries need the same care. Temporal’s Retry Policy reference provides configurable behavior rather than a guarantee that every external failure will become a successful result. An operator should distinguish temporary service trouble from a request that cannot succeed unchanged. Preserve recovery for transient failures while bounding expensive repeated calls. A durable loop that reliably repeats an invalid request is still an invalid workflow, now with a dependable billing trail.

Do not remove useful health signals blindly. The detailed Actions reference says an Activity heartbeat counts when it reaches the server; SDKs throttle heartbeat calls. A count of application-level heartbeat invocations is therefore not automatically a count of billable operations. Use the service’s measured usage when evaluating changes. Otherwise a supposed saving may be based on traffic the platform never charged for in the first place.

Retention creates a separate governance decision. The history-export documentation supports closed-history export to cloud object storage, but describes asynchronous delivery and a separate operating path. An archive that must support audits needs verified export completeness and retrievability before shorter service retention is acceptable. Moving bytes is not the same as preserving usable evidence; object storage, access controls, and recovery procedures remain the customer’s concern.

The success criterion also stays outside the execution engine. Yesterday’s AWS monitoring analysis distinguishes infrastructure health from task quality. Apply that boundary here: a workflow that resumed correctly can still produce a wrong answer. Preserve outcome checks and approval controls while measuring the cost of orchestration. The financing release does not provide a measured reduction in bad business decisions, so no such return is assumed in this comparison.

Put a lifecycle owner beside the agent owner

Start by measuring the workflow that already exists. Record active and retained byte-hours, billable Actions by category, successful completions, recovery interventions, and the time spent diagnosing incomplete work. Separate those observations from model inference and tool charges. The purpose is not a perfect cost-accounting platform; it is enough evidence to tell whether the problem is repeated execution, bulky history, or a missing business acceptance rule.

Next, identify one safe lifecycle boundary and compare it with the current implementation in a non-production trial. Include interruption, retry, and resume cases. Check that a fresh execution has the state it needs and that investigators can still connect it to the previous run. Do not declare success from smaller histories alone. The change earns production rollout only if it preserves correct completion and makes the measured operating cost better.

The rest of today’s edition shows why these boundaries deserve names. Sourcegraph’s new merge-based coordination pricing changes which code-change event creates a charge; it does not absorb every reviewer obligation. Atria’s text-only API contract constrains what an agent can send and how much room it must reserve for output. A long-running workflow has to survive both kinds of dependency change without confusing a successful API call with a completed job.

For procurement, compare the managed service with the actual alternative, including retained worker operations, external APIs, support requirements, and migration work. The public tariff is a useful starting point, not a quote for the whole application. Ask for a bill mapped to a representative trace before entering a spending commitment. A discount on the wrong consumption forecast can be less useful than paying the ordinary rate while learning the workload.

Evidence that would strengthen the adoption case is less reconstruction after failures, preserved outcome quality, and lower full cost per completed workflow. Evidence that would reverse it is checkpoint-related state loss, increased repair work, or history savings too small to cover the added complexity. The decision should remain reversible until the trial distinguishes those outcomes.

• Agent platform teams: evaluate durable orchestration where work must survive outages or long approval waits; do not migrate short, adequately recovered jobs solely because Temporal raised another round.
• Workflow owners: checkpoint only at validated state boundaries. Measure the old history moved, the new active history created, and the operational evidence retained.
• Engineering and finance leads: use the $29.48 gap only for equal extra GB held over 30 days beyond allowances. Include Actions, plan charges, inference, and retained operating work in the purchase decision.
• Reliability owners: expand after recovery tests preserve correct outcomes and investigation quality. Keep ordinary Activity boundaries and useful observability unless measurements justify changing them.

Temporal’s financing gives durable orchestration a larger commercial platform. Its tariff gives builders a smaller, more actionable question: which history still needs to be active? Durable execution should preserve the work, not every expensive mistake in its design.

Sources

• Temporal — September 14 Series E, valuation, and reported adoption
• Temporal — February Series D and $5 billion post-money valuation
• Temporal — public storage and Action rates
• Temporal documentation — pricing, allocations, tiers, and plan charges
• Temporal documentation — cost optimization and default retention interval
• Temporal documentation — Continue-As-New state and execution identities
• Temporal documentation — billable Actions, replay, retries, and heartbeats
• Temporal — Durable Execution and recovery model
• Temporal — Activity granularity and failure boundaries
• Temporal documentation — Local Activity durability and recommended use
• Temporal documentation — configurable retry policies
• Temporal documentation — closed-history export and delivery semantics