Pyrana and Temporal

What durable execution is

Durable execution means a program's progress is recorded as it runs, so a crash, a deploy, or a lost machine does not lose the work. When the program restarts, it resumes from the last completed step. Temporal is the best-known implementation: a workflow is ordinary code, every step's result is written to an event history, and after a failure a new worker replays the code against that history to rebuild state and continue.

The Temporal model in brief

Temporal separates work into Workflows and Activities. A Workflow is "your business process defined in code." Activities are the steps that touch the outside world: API calls, database writes, emails, and model calls. Temporal supervises Activities with retry policies and timeouts, so a failed call retries with backoff, and an Activity whose worker dies is rescheduled on another. Workers run in your infrastructure and poll task queues for work. Workflow code must be deterministic, because Temporal reruns it to rebuild state; anything nondeterministic belongs in an Activity.

Why agents need it

An agent run is a long chain of slow, failure-prone, nondeterministic calls. Without durability, a timeout on step 40 can mean paying for steps 1 to 39 again, or leaving a half-finished action in a business system. Durable execution gives agents three things they otherwise lack: completed steps that are never repeated, retries under a policy, and waits that can last as long as the business needs.

Waiting for a person

The wait matters most. A purchase request above a threshold may sit in a finance queue over a weekend. A Temporal workflow can wait on a durable timer that lasts "minutes or months," or wait for a Signal or Update that delivers the decision, without holding a process open. When the decision arrives, the workflow continues on whatever worker is available.

Retries and restarts

Model providers rate-limit, tools time out, and deploys restart workers. Under Temporal, each of those becomes a retried Activity rather than a failed run. Temporal's own integrations follow the same pattern: the agent's orchestration runs as a deterministic Workflow, and model and tool calls run as Activities.

What Temporal provides

Temporal provides the durable core: SDKs in several languages, the MIT-licensed Temporal server for self-hosting, and Temporal Cloud as a managed service. Workflows can receive Signals and Updates, answer Queries, start child workflows, run on schedules, and wait on durable timers. Temporal Cloud bills per Action (workflow, activity, timer, signal, query, and schedule operations) plus active and retained storage, with SAML SSO and audit logging.

Temporal's AI integrations

Temporal has invested heavily in agent durability. The OpenAI Agents SDK integration for Python reached general availability on March 23, 2026: the agent loop, tool selection, and handoffs run inside the Workflow, and model calls run as Activities. Integrations also exist for Pydantic AI, the Vercel AI SDK, LangGraph (public preview), and Google ADK, announced at Replay 2026 in May. Replay 2026 also brought Workflow Streams in public preview for streaming LLM responses. In August 2026 Temporal published an early look at the Temporal Agent Harness, "earlier than public preview," which wraps agent SDKs in workflows and adds tool-call approval policies.

What an application platform adds

Temporal makes a program durable. It does not decide who the program is acting for, whether that person may see the record, which approver is eligible, what the agent should know, or where people do their work. Pyrana builds those layers above its Temporal-based orchestration: identity, authorization, approvals bound to actions, context, pages, and versioned outputs. Each is something a team building directly on Temporal would design and own.

Identity and authorization

Temporal's access controls govern who can operate namespaces and workflows. Application authorization is the application's job. In Pyrana, every call passes one eight-step gate before anything runs: identity and idempotency key, active App version, target and caller checks, exact resource versions, one authorization check (membership, access profile, entitlement on the entity), and an execution row and audit record written in one transaction before dispatch. The gate fails closed. The user's principal also passes through to Snowflake and Databricks row-level security.

Approvals bound to actions

Temporal gives you the primitive: a workflow waits, and a Signal or Update delivers a decision. Pyrana supplies the policy around it. A tool approval policy over typed arguments (thresholds, membership, existence, compound rules) decides which invocations need a person. The platform freezes the operation, exact arguments, scope, and evidence under a hash and queues it to a named lane. Reviewer eligibility is checked at decision time; the frozen invocation is revalidated before dispatch; dispatch is idempotent, so a retry reuses the receipt.

Context, pages, and versioned outputs

Pyrana adds cortIQ, which supplies agents with typed, classified Context Units and records what was retrieved, injected, and cited in each run. It adds the application surface: an App shell, declared pages that hand exact page context to the agent, a copilot, and personal pages. And it adds durable storage for outputs: versioned, immutable, attributed resources, where a stale publish is refused rather than overwriting someone else's work.

Do I need Temporal if I use Pyrana?

Not as a separate project. Pyrana's orchestration layer runs on Temporal workers as part of the platform. Workflows are declarative and live in the App configuration; nobody on the application team writes Temporal workflow code. Temporal workers provide durability and horizontal scaling, with separate worker pools for data fetching, file extraction, and the code interpreter. A run that waits for an approval survives a restart or deploy and resumes.

Should I build on Temporal directly?

Sometimes, yes. If your team is building its own platform, or the workload is a backend process with no users in the loop, Temporal is a strong foundation and its agent integrations remove much of the durability work. The fair question is what else the deliverable needs. A business application with approvals and audited outputs also needs identity, per-user authorization, approval policy, context, a UI, and versioned storage, and those take longer to build and maintain than the durable core.

What it takes to ship the same application

The reference application: a person or agent drafts a purchase request; amounts above a threshold need a finance approver; the request waits durably for the decision; everything is recorded.

Using them together

Pyrana already uses Temporal, so the relationship is foundational rather than an integration project. Where a team also runs its own Temporal workflows, the two connect through ordinary interfaces: a Temporal workflow can call a Pyrana App through its API or App MCP server as a service principal, passing the same gate as any other call, and a Pyrana agent can call a service fronting a Temporal workflow through a REST or MCP tool source. Pyrana's view is that Temporal is the right durable core; the application platform is what sits above it.

When not to choose Pyrana

• You are building your own platform and want to own every layer, including workflow code.
• The workload is backend infrastructure or data processing with no people in the loop.
• You have already committed to an agent framework and need only durability, which Temporal's integrations provide.
• You need low-level control over workers, task queues, and SDK behavior that a platform abstracts away.