Temporal and AI Agent Governance

Announcement

The Layer That Sits Above Durable Execution

Published on

Jul 13, 2026

Subscribe to our newsletter

Temporal has become the durable execution layer beneath production AI agents. Governance is the layer that sits above it, the way the application layer sits above a transport protocol, and it is the layer regulators will inspect. This article explains what that layer must do for AI agent governance, EU AI Act compliance, and enterprises running long-running agents on Temporal today.

What Is Temporal and Why Does It Matter for AI Governance?

Temporal is the durable execution platform that keeps long-running AI agents alive. In February 2026 it raised a $300 million Series D at a $5 billion valuation, led by Andreessen Horowitz, and described itself as the open-source platform powering the world's most reliable agentic applications. Its own customer list for agentic workloads includes OpenAI, Replit, ADP, and Block.

In practical terms, Temporal guarantees that a workflow runs to completion. When a process crashes, it recovers its exact pre-failure state and continues. When an activity fails transiently, it retries. Teams reach for Temporal because it removes an entire class of distributed-systems problems from agent code: state, retries, timeouts, and recovery.

Samar Abbas, CEO and co-founder of Temporal, framed the shift plainly when the round closed: "Agentic AI doesn't fail because the models aren't good enough. It fails because the systems around them can't handle real-world execution. And rather than create new problems, agentic AI tends to expose old ones such as managing state and failures." Durable execution is one of those systems. Governance is the next one.

For engineering teams, Temporal solves reliability. For governance teams, it raises the next question in the stack: if Temporal is the standard execution layer for enterprise agents, what governance layer sits above it? That layer, the one that decides and proves what an agent is allowed to do, is not yet standardized. Establishing it is the natural next step, and it is what this article is about.

The Regulatory Stakes: EU AI Act, NIST AI RMF, and ISO 42001

The EU AI Act's oversight and record-keeping provisions are not aspirational. They are design requirements for high-risk AI systems, and they map directly onto what a long-running agent does at runtime.

Article 14 requires that high-risk AI systems be designed so that natural persons can effectively oversee them during use, including the ability to detect anomalies, disregard or override an output, and stop the system. Article 12 requires that these systems technically allow the automatic recording of events, or logs, across their lifetime. Article 26(6) requires deployers to keep those logs for at least six months, and financial institutions to retain them under their sector rules.

When a Temporal workflow executes an agent's decisions, its event history becomes part of the evidence surface that auditors and regulators may examine. The question is whether that history is a compliant record or merely a starting point. It is the latter.

⏱ Timeline note. Under the Digital Omnibus provisional agreement of 7 May 2026, high-risk obligations for stand-alone Annex III systems are deferred to 2 December 2027, and for product-embedded Annex I systems to 2 August 2028. The co-legislators have been advancing the package through formal adoption, and it binds once published in the Official Journal. The 2 August 2026 transparency and enforcement dates remain live. These dates are moving through process, not settled law. Verify against current EU institution publications before relying on them.

Two non-EU frameworks point the same way. The NIST AI Risk Management Framework structures governance across four functions, Govern, Map, Measure, and Manage, each of which places explicit demands on operational oversight and monitoring. ISO/IEC 42001, the international AI management-system standard, is increasingly referenced alongside it in enterprise programs. For a CISO or AI risk officer, the operational question is now concrete: which layer of the agent stack carries these obligations, and what evidence does it produce?

What Temporal Does: Durable Execution for Long-Running Agents

Temporal splits an agent into workflows and activities. Workflows hold the orchestration logic. Activities are the individual units of work: calling a model, querying a database, or hitting an external API. Temporal records every step in an event history, which is what lets a workflow recover its exact state after a crash and replay to where it left off.

That event history is the governance-relevant surface. It captures when a workflow started, which activities ran, what they received and returned, and when they failed. For an agent, the activities are usually the tool calls: the moments where the agent actually touches a business system.

This is a genuine contribution. A durable, replayable record of what an agent did, surviving crashes and restarts, is more than most bespoke agent stacks produce. But recording what happened is not the same as deciding what is permitted to happen, signing the record so it cannot be altered, or linking it to the policy in force at the time. Temporal does the first. It does not do the others, by design.

Durable Execution vs Runtime Governance: What Is the Difference?

Reliability and governance are different jobs. Temporal answers whether an agent's work completes correctly. Governance answers whether that work was permitted, recorded in a way that survives scrutiny, and attributable to a policy and a person. The distinction matters for teams deciding where to instrument compliance controls.

Dimension	Temporal (durable execution)	Runtime governance layer
Primary purpose	Keep long-running workflows alive and recoverable	Decide, record, and prove what an agent is allowed to do
What it does	Orchestrates workflows and activities, retries, recovers state	Evaluates each operation, enforces a verdict, attests the record
Point of control	After a step is defined, ensures it runs to completion	Before a step runs, decides whether it may proceed
Audit surface	Event history: durable, replayable, not signed	Tamper-evident, cryptographically signed, policy-linked trail
Authorization	Not built in; application responsibility	Policy enforcement is the core function
EU AI Act relevance	Supports Article 12 logging as a starting point	Addresses Article 14 oversight and Article 26(6) evidence

The practical implication: Temporal governs whether the work survives. A governance layer governs whether the work should have run. Both are required for a production agent under regulatory scrutiny. Temporal provides one natively, and it was built to hand the other off cleanly.

Where Temporal Was Already Built for Oversight

Some of Temporal's architecture aligns with what oversight requires, not by marketing but by construction, because it was built for production systems where humans needed to step in. That alignment is worth naming before any gaps, because it frames the boundary as a division of layers rather than a shortfall in the platform.

Temporal's signal and human-approval patterns let a workflow pause for a person and resume on their decision, and because execution is durable, that pause survives a crash. This supports the kind of intervention Article 14 describes: a designated person able to monitor an agent, hold it, and override it before it proceeds.

Its event history gives oversight teams a replayable account of what an agent did, activity by activity. That is the natural starting surface for the automatic logging Article 12 calls for, and the raw material for the anomaly detection the NIST Manage function expects.

None of this was built for compliance. It is a consequence of building for real deployments. But the event history is the starting point for an audit trail, not the trail itself: it is not signed, not linked to the policy or model in force, and not retained to a defined standard. The governance layer begins exactly where these built-in capabilities end.

A Concrete Example: Where Temporal Ends and Governance Begins

Consider a mid-sized bank that runs an AI agent on Temporal to process commercial loan applications. The agent retrieves borrower financials, calls internal scoring tools, and initiates a funds transfer once a decision is reached. Each tool call is a Temporal Activity.

What Temporal provides in this scenario

If the worker crashes mid-application, the workflow recovers its exact state and continues without losing the in-progress decision.
If the transfer API times out, Temporal retries it under the workflow's retry policy rather than failing the whole process.
The event history records each activity, its inputs and outputs, and its timing, giving the bank a durable, replayable trace of what the agent did.

Where the governance layer takes over

Policy enforcement before the action. Temporal will faithfully execute a transfer that falls outside authorized credit parameters, and retry it reliably; the governance layer is what checks and stops it before it runs.
A tamper-evident record. The event history is durable but not signed or linked to the policy and model in force; the governance layer produces the signed, version-linked account a regulator expects.
Attribution. The history does not show which officer approved which decision under which policy; the governance layer records that, which is precisely what Article 14 oversight and an audit require.

This is not a flaw in Temporal. It was built to execute workflows reliably, not to be a compliance system. But for a bank under financial-services regulation, where audit trails are mandatory and decision accountability is non-negotiable, that boundary is exactly where a governance layer has to take over.

Is This a Governance Gap, or Just Architectural Separation?

A reasonable objection runs as follows: every layer separates concerns. TCP moves packets; it does not enforce access policy. An orchestration engine runs workflows; it does not govern them. Why should Temporal be expected to carry governance controls that belong in an adjacent system?

The objection is architecturally correct, and this article does not dispute it. Keeping durable execution focused on execution is the right design. The problem is not that Temporal lacks governance controls. The problem is that no standardized governance layer has been built above it. For networking, those layers were standardized decades ago. For agent execution, they have not been.

The gap is also operationally consequential in a way that abstract separation is not. When a regulator asks for a tamper-evident, policy-linked record of an agent's decision, the answer cannot be that governance belongs in an adjacent system without naming which system, in what format, and how it attaches to the workflow. Today each team answers that independently and inconsistently. That is an ecosystem gap, not a Temporal deficiency.

Where Temporal Hands Off to the Governance Layer

Temporal orchestrates execution. By design, it does not authorize actions, does not enforce policy, does not produce tamper-evident audit trails, and does not score how trustworthy an agent has been over time.

It does not evaluate whether a given tool call is within authorized scope before the activity runs. Its event history is a natural log surface, but it is not cryptographically signed and not linked to the policy or model that governed the decision. It carries no verified agent identity that a third-party auditor can check across delegation boundaries.

None of this is a criticism. An execution engine that embedded a fixed governance model would lock its users to one regulatory regime. The separation is correct. But it creates a specific hand-off point that governance teams need to plan for explicitly, rather than assume the workflow engine covers it.

The AI Agent Governance Layer That Needs to Exist

The outline of a compliant governance overlay above durable execution is visible. It requires:

Policy enforcement that evaluates each agent action before execution and blocks non-compliant behavior.
Tamper-evident audit records, cryptographically signed and linked to model and policy snapshots.
Identity propagation that carries verified agent and user identity across delegation boundaries.
Behavioral monitoring that detects multi-step violations across a session, not just single-event anomalies.
Post-hoc verification that lets governance teams replay and audit a session after the fact.
Trust scoring that quantifies an agent's trustworthiness from configuration, runtime compliance, and goal alignment over time.

These pieces are not novel in isolation. What does not yet exist by default is a standardized assembly of them built for the agent execution layer. OpenBox is an AI agent governance platform built to be that assembly. It wraps existing agent frameworks, including LangGraph, LangChain, CrewAI, Mastra, and Temporal, with a Trust Lifecycle: Assess, Authorize, Monitor, Verify, Adapt.

On Temporal specifically, OpenBox attaches as a worker-level plugin. It captures workflow and activity events, evaluates each operation, and enforces one of five governance decisions: ALLOW runs the action, CONSTRAIN runs it inside a sandbox, REQUIRE_APPROVAL pauses it for a human, BLOCK stops the action, and HALT stops the whole workflow. The agent's workflow definition does not change.

Underneath, Trust Scores quantify an agent's posture from three weighted components: Risk Profile (40%), Behavioral compliance from the Authorize and Monitor phases (35%), and goal Alignment from the Verify phase (25%). Guardrails enforce hard constraints at execution time. Policies, written in OPA/Rego, perform stateless per-operation checks, while Behavioral Rules detect stateful multi-step patterns that per-operation checks cannot catch. Cryptographic attestation produces tamper-evident audit trails with verifiable proof of agent behavior over time. This is the kind of control plane that belongs above durable execution, and building it is the open problem.

What Enterprises Running Agents on Temporal Should Do Now

For teams already running agents on Temporal, six steps establish a governance foundation that the execution layer does not provide.

#	Action	What it achieves
1	Map your governance boundary	Identify every workflow and activity where an agent touches a business system. That surface is your instrumentation baseline; every gap is a gap in audit readiness.
2	Establish agent identity	Temporal carries execution, not verified identity. A decentralized identifier or equivalent for each agent is prerequisite work for any meaningful audit trail.
3	Enforce policy above the workflow	Evaluate agent actions before execution. The event history shows what happened; policy enforcement decides what is permitted and stops it before the action runs.
4	Establish tamper-evident logging	Event history is a starting point, not an audit log. Cryptographic signing, linking to model and policy snapshots, and retention aligned to Article 26(6)'s six-month minimum should sit as a distinct layer above it.
5	Instrument trust monitoring	Trust scoring and behavioral rules surface deteriorating compliance before it becomes an audit failure. Static approval steps are not a substitute for continuous monitoring.
6	Build post-hoc verification	When someone asks what the agent did and why, session replay and Verify-phase tooling should be available. Its absence is what turns a compliance question into an audit crisis.

None of these steps requires waiting for a standardized governance protocol to emerge above Temporal. They require selecting and deploying the governance layer now, while the architecture is still being set.

The Market Has Already Moved: Why This Quarter Matters

Temporal's $300 million Series D at a $5 billion valuation is a signal that execution has become a competitive layer in the AI stack, not a niche tool. When the durable execution layer consolidates, the governance question sharpens: it shifts from "how do we keep our bespoke agent alive?" to "what governance layer belongs on top of Temporal?" That is a more tractable question, and a more urgent one.

The regulatory clock is running alongside the market. The EU AI Act's high-risk obligations now anchor to December 2027 for stand-alone systems, with transparency and enforcement dates live from August 2026. Enterprises moving agents into production this year are building the audit posture they will be asked to evidence later. The ones who instrument governance now will not be explaining its absence to a regulator afterward.

Risk and compliance teams have not yet engaged deeply with the agent execution layer. Article 14 and Article 26(6) framing has barely appeared in technical writing about Temporal integration. That engagement is beginning now, in 2026. Teams have a window to shape the control architecture before it is set by default.

The Workflow Survives. The Accountability Question Does Not Go Away.

Temporal standardizes durable execution. It keeps long-running agents alive, recovers them after failure, and records what they did in a replayable history. That is a genuine and significant contribution to the agentic AI stack.

It is not a governance system.

The governance layer, covering policy enforcement, tamper-evident logging, identity propagation, behavioral monitoring, trust scoring, and post-hoc verification, belongs above the execution layer, not within it. That is not a criticism of Temporal; it is the correct division of responsibility. The question is not whether that layer needs to exist. It does. The question is who builds it, what it looks like, and whether the enterprises now running agents at scale build it before the regulator asks for it.

Durable execution keeps the workflow alive. It does not answer for what the workflow did. That answer is the governance layer's job, and it is needed now.