Scaling AI agents without breaking reliability

An agent can produce an impressive interaction and still fail to earn anyone’s trust if it cannot work reliably. Temporal’s mascot makes that concern explicit: a tardigrade, or water bear, which Preeti Somal describes as the most resilient animal known to humankind. The engineering problem behind the mascot is concrete. Agents depend on LLMs, coordinate distributed components, and must continue working as demand grows. Reliability and durability are part of the application’s behavior, not infrastructure details that users can ignore.

The coordination quickly becomes a workflow. Multiple processes need to share state that may remain relevant for a long time. A human may need to approve an action; independent work may run in parallel; tools must be called and their results incorporated. Each interaction also needs enough visibility to explain what happened when the result is wrong or the process stops. A switch statement can choose the next action, but it does not by itself solve these operational responsibilities.

Somal asks whether anyone’s LLM calls succeed every time; nobody raises a hand. Failures in the surrounding toolchain compound that uncertainty. Tracing, debugging and testing the resulting system are difficult, particularly before production. Her reference to Agent Ops places observability alongside orchestration: keeping the process running and understanding its execution are related requirements.

These difficulties have a history in distributed systems. Temporal’s proposal is to take responsibility for reliability and scalability so developers can concentrate on application logic. Its language-idiomatic SDKs make that division available through ordinary code. Somal reports that Python overtook the other SDK languages in January, without specifying the adoption metric or the year. The observation illustrates the prominence of Python in this agent-building audience, rather than establishing a measured market share.

The SDK model separates the application’s intended sequence of operations from the plumbing needed to execute it reliably. Temporal supplies execution infrastructure and guardrails, backed by use in mission-critical workloads. Somal describes the product as having more than a decade in production; the historical distinction is that Temporal’s first production release announcement dates to October 2020 and describes the founders’ earlier Cadence work. That lineage should not be read as ten years of Temporal production use by this 2025 talk.

The customer examples move the discussion from infrastructure promises to deployed applications. Somal names Dust as a company building agents on Temporal, alongside another company whose published technology stack includes it. She then describes Gorgias as running production AI customer-service agents on Temporal and identifies Reebok, Timbuk2 and Glossier as brands it serves. That establishes the customer-service setting; it does not identify which brands use the particular agent implementation.

The claimed benefit is agility: teams can spend more effort on business behavior instead of repeatedly building reliability mechanisms. A payments example raises the stakes further, showing that the platform is used for workloads where execution failures have direct consequences. Additional developer testimonials reinforce that operating agents is already a production concern, not just a question of making a compelling prototype.

In the before-Temporal architecture, developers implement both the interactions between services and the error handling around those interactions. Temporal reorganizes that coordination around a Workflow written with its SDKs. This is a developer tool: the workflow is code, rather than a diagram a business user configures.

For an agent, the workflow coordinates user interaction, the LLM, a chat-history database and tools. Those components still exist; the workflow gives their interaction a durable execution structure. The architectural change is therefore not the removal of the agent’s dependencies, but a different place to express and manage their coordination.

Somal says applications can reach production in weeks and reports customer case studies with more than 6× feature-delivery velocity after adopting Temporal. She does not name the case studies or give their baseline, observation period or measurement method. The intended engineering benefit is less time spent implementing infrastructure behavior before shipping a feature.

An unnamed consumer application supplies the scaling example: demand grows with events, and Somal says the team does not implement its own scale logic. Temporal Cloud is presented as taking on that coordination burden. The operational outcome she connects to it is straightforward—fewer reliability worries for engineers and fewer broken experiences for customers.

The ticket-booking example connects these abstractions to a conversational application. Somal walks through its architecture rather than running it live onstage; a working demonstration is offered at the booth. The participants are the user, a system combining Temporal and AI, language models, goals and tools. Temporal concepts wrap the coordination between these pieces.

The workflow defines the application’s flow, including its interactive loops. A Signal supplies input to a running workflow, while a Query provides a way to inspect its state. This lets a conversation continue through multiple interactions instead of requiring the entire booking process to finish in one request.

The distinction matters when implementing the loop: application code describes what should happen next, while Temporal handles retry machinery. That does not mean every failure is automatically recoverable. Under the documented retry-policy defaults, Activities retry by default, whereas Workflow Executions do not have a default retry policy. Retry policies control backoff, limits and non-retryable errors. Developers still decide which failures should be retried and which require a different business outcome.

Temporal stores workflow history so an engineer can inspect how the agent moved through its interactions. Tools are wrapped in Activities, which are also application code. The model provider remains a choice for the application. Somal describes this arrangement as supporting input validation and progress toward the goal, with infrastructure failures handled through Temporal’s execution machinery. Validation rules and the meaning of a successful booking still belong in the application.

A compact Python workflow can express the same division. In this example, each incoming booking message triggers an agent_turn Activity, which returns a reply and whether the conversation has finished. A Query exposes the latest reply. The Activity owns the model and tool interaction; the workflow owns the conversational loop.

from datetime import timedelta
from temporalio import workflow


@workflow.defn
class TicketBooking:
    def __init__(self) -> None:
        self.pending: list[str] = []
        self.reply = "What trip would you like to book?"
        self.done = False

    @workflow.signal
    def message(self, text: str) -> None:
        if not self.done:
            self.pending.append(text)

    @workflow.query
    def latest_reply(self) -> str:
        return self.reply

    @workflow.run
    async def run(self) -> str:
        while not self.done:
            await workflow.wait_condition(lambda: bool(self.pending))
            text = self.pending.pop(0)
            result = await workflow.execute_activity(
                "agent_turn",
                text,
                start_to_close_timeout=timedelta(minutes=2),
            )
            self.reply = result["reply"]
            self.done = result["done"]
        return self.reply

The timeout bounds an individual Activity attempt; it is not a deadline for the whole conversation. There is no handwritten retry loop around the Activity call.

Somal groups Signals and Queries together when discussing recorded interactions, but their persistence semantics differ. The message-passing documentation makes the boundary explicit:

For the example above, sending message contributes to the execution record; calling latest_reply does not. Workflow history is not a log of every read of the workflow.

Somal also describes exporting the entire workflow history for customers who need to investigate execution in test or development environments, or retain evidence for compliance-related work. That export makes the execution record usable outside the immediate running system; it does not turn unrecorded Queries into recorded events or establish a compliance certification.

Loops and other agent interaction patterns fit inside the workflow programming model. Temporal Cloud supplies the durable coordination infrastructure, but the agent and workflow code run in the customer’s environment. Somal describes Cloud as retaining execution state and managing failures and retries, using the call stack as an analogy for the execution context it preserves.

The concrete execution boundary is the Worker. As the Worker documentation explains, Workers poll the Temporal Service for tasks and execute Workflow and Activity code. Cloud coordinates execution; it does not become the host process for the application’s Python code.

Because the worker is application code in the developer’s environment, it can fit existing CI/CD practices. The intended change is where reliability responsibilities live, while developers retain control of their business logic and deployment process.

The walkthrough ends with a screenshot of the example’s worker code and a route to implementations through Temporal Code Exchange. Temporal is also open source, so the next step is to inspect an application’s code and see how its workflow, Activities and worker fit together.

Somal closes with a practical starting path: choose an example, run it in a local development environment, and connect it to Temporal Cloud. She mentions Cloud signup and promotional credits available at the time of the talk, without specifying an amount. The useful progression is from readable application code to a running workflow, with the same separation between customer-hosted execution and durable service coordination.