Executive Summary

Key Figures

Source: Temporal announcement (2026-09-14)

Lightspeed led the round. Wellington Management, Growth Equity at Goldman Sachs Alternatives, and Tiger Global came in as co-leads, with T. Rowe Price and SV Angel participating. a16z, Sequoia, Index, GIC, Sapphire Ventures, and Amplify, who led or joined earlier rounds, all returned. Lightspeed, out in front this time, is not a new face either. It was already in February's Series D as a participating investor, and in seven months it moved from the back row to the head of the table. The company says the money goes to expanding global operations, investing in the core primitives beneath the platform, and the reliability and security work its enterprise customers keep asking for. Headcount doubled over the past year to 570.

The speed of the repricing is the heart of this announcement. Three reference points, side by side:

Move the ruler one notch further back and the span widens. At the Series C in March 2025 the company was worth $1.72B. Eighteen months later it is more than seven times that. Adding up the rounds that have been disclosed puts the money raised so far at around $1.2B.

Over the same stretch, revenue has been adding on more slowly. February's announcement put revenue up more than 380% year over year, and this one puts it up more than 200%. A bigger base naturally pulls the rate down, but the growth rate went the other way while the valuation went up 2.5 times, and the two are worth reading together.

Growth figures came out alongside the round. The annualized revenue run rate passed $250M, growing at that same rate of more than 200%. Open-source installs passed 43 million, up 134% since December 2025. The customer list names OpenAI, Snap, NVIDIA, Netflix, and JPMorgan Chase. Snap carries 414 million Stories a day on it, and JPMorgan Chase runs it in regulated production.

The press release carries a longer list: Anysphere, the maker of Cursor, along with Lovable, Scale AI, Salesforce, Shopify, Booking.com, Block, and DoorDash. Among the uses, next to long-running agents, payments, and customer operations, it names autonomous-vehicle simulations. Teams working on the physical world are running into the same class of problem.

The most striking figure concerns OpenAI. The company wrote that OpenAI's use of Temporal has grown 60-fold in under a year. Venkat Venkataramani, OpenAI's VP of Infrastructure, added this to the announcement.

“As infrastructure teams increasingly handle really complex, long-running workflows, they have even less control over external dependencies. Durable Execution is more than ever a core requirement for modern AI systems, and Temporal offers a compelling platform to help build it in from the start. This is one of the main reasons why we invested in building a durable orchestration framework powered by Temporal at OpenAI.”

The weight sits in the last sentence. OpenAI did not stop at picking the tool. It went on to build a durable orchestration framework of its own on top of it. Choosing a tool and putting your own layer over it carry different costs on the day you want to swap the thing underneath.

Temporal does not build models. It sells an execution engine that pushes a long job to the finish after the job gets cut off partway. The company calls that Durable Execution. Developers write ordinary code, the engine keeps a record of every step of the execution, and when a server dies or a network drops, the engine uses that record to carry on from where the work stopped. A job that waits days for a human approval survives on the same machinery, since nothing has to stay alive in memory during the wait.

This company did not appear on the back of the agent boom. The two founders, Maxim Fateev and Samar Abbas, met at Amazon while building services that coordinate long-running work. Fateev led Simple Workflow Service (SWF), and Abbas joined the team that brought SWF to the public in 2012. Abbas went on to co-create the open-source Durable Task Framework at Microsoft, and Microsoft later built Azure Durable Functions on top of it. The word durable attached to what this company sells today comes from those years.

The two met again at Uber and built the open-source workflow engine Cadence. Cadence passed 100 internal use cases in three years and went public as open source in 2017. Temporal started in 2019 as a fork of Cadence. The problem now called agent infrastructure is one these people were already working on under the same name, back when there were no agents.

Abbas, the co-founder and chief executive, summed up where the company stands in the announcement.

“Reliability has never been optional, but AI has quickly raised the cost of skipping it, and developers need a foundation for that built in from day one, not bolted on afterward.”

Anoushka Vaswani, a partner at Lightspeed, gave a more practical reason. Every team building on AI hits the same wall, Vaswani said: “the demo is easy, production is hard, because the systems around the models can't handle real-world execution.”

The investment arithmetic shows up right after that. Most of the market, in Vaswani's account, “solves that by locking teams into a proprietary stack,” while Temporal is “the open, pluggable foundation that runs their agents and the systems they already depend on.” The round's bet shows here too: not how well the platform runs models, but whether a team can slot it in beside what it already runs, without tearing any of that out. Real adoption paths are filling in as well. The OpenAI Agents SDK integration went generally available in March, and a Vercel AI SDK integration followed to put the same guarantees under TypeScript.

Say a worker dies thirty or so steps into an agent's job. The common answer is a retry, and a retry usually starts the whole thing from the top. If a payment API was already called at step 20, that call goes out a second time. Mail that already went out goes out again, and records that were already moved get moved again. On top of that, a model call does not return the same answer for the same input, so there is no guarantee the second path matches the first.

Durable Execution takes a different road. Every non-deterministic operation that reaches outside during a run has its result written to an event log. What the model answered, what a tool returned, what an external read produced, all of it in order. In exchange, the control flow that strings those calls together has to be deterministic, which is to say the same input order has to take the same branch. On recovery the engine does not execute again up to the point where the record ends. It substitutes the stored results instead, so no side effect repeats. Real execution resumes where the record stops, which is the spot where the worker died.

Two words split apart here, and keeping them apart saves money later. Replay answers “what happened that time.” Re-run answers “what happens if I run this now.” A recovery design that treats the two as one thing sends the mail twice and charges the card twice.

While an agent drafts text for you, a failure costs little. If the draft is bad, ask again. Once the agent starts charging cards, decrementing inventory, moving a schema, and closing tickets, the terms change. A failure no longer ends inside the screen and leaves a mark on the outside world instead. Past that line, the question a team has to answer changes. It moves from how smart the model is to how far this job got and what it has already touched.

That diagnosis is not this article's invention. In a letter published the same day, Abbas writes that agents have moved past answering questions. They call tools, hit payment systems, kick off other agents, and take “dozens of steps a person never checks.” The press release says the same thing another way: every additional step creates another place to fail.

The second question cannot be answered with a performance metric. Answering it takes state and history. The event log Durable Execution leaves behind is a recovery device, and before that it is a lineage of the judgments an agent made. Which tool was called when, with what input, and what came back, written down in sequence. So a workflow that can be recovered is usually a workflow that can be audited. Both properties come out of the same record.

Neighboring tools are gathering in one place, which backs that direction. LangGraph's checkpointer, AWS Step Functions, Inngest, Restate, and DBOS differ in design, and all of them deal with long-running execution and preserved state. This round is the price attached to the oldest and most heavily commercialized member of that family. Abbas, in the letter, reads competitors and hyperscalers converging on the same primitives as confirmation that the company saw this coming early. The party making that call is the party doing the selling.

Still, the claim can be pushed too far. Not every tool call needs this machinery. For a one-shot call that finishes in five seconds with no side effects, calling it again is cheaper. The price of bringing in a workflow engine pays back when work runs long, touches the outside world partway through, and has to be retraced after a failure. Put this structure on a pipeline that does not meet those conditions and there is more to manage than to gain.

From here the article leaves the announcement and rereads this news from the data side. The question Pebblous has held onto for a long time is where data came from and what it passed through to become the value it is now. An agent's execution record is that question laid out along a time axis. If lineage is the history of data, an event log is the history of behavior. Reproducibility on the data side and replayability on the execution side have the same requirement. Both ask that the inputs and the versions of that moment still be there.

So a reading of this round as good news for an infrastructure startup and no more than that gets half of it. This $12.55B points at the history of execution, not at the quality of a model. And that history does not arrive on its own with a purchased tool. It accumulates from the point where someone decided what to keep and started keeping it. A log that is not accumulating now cannot be assembled after the fact once something goes wrong.

For your own team's agent pipeline, five things are worth checking.

• Can you say right now at which step last week's failed agent job stopped? A log that keeps only outcomes cannot say.
• When you run that job again, can you skip the external calls that already went out? If you cannot, a retry is a duplicate execution.
• Is what the model answered at that moment stored together with the input? Keep only the answer and the grounds for the judgment are gone.
• Do the search results and tool outputs used for intermediate judgments carry a timestamp and a version? Without those, the conditions of that moment cannot be assembled again.
• Who set the retention period for these records? Usually that number came not from the person responsible for audits but from someone watching storage costs.

Thank you for reading this far. The figures and quotes this article cites can be read in the original by anyone, in Temporal's announcement. We would be glad to hear which records your own organization reaches for to retrace the point where an agent failed.