Governing Long-Running AI Agents: How Deep Agents Stay Within Policy for Hours

A short-task agent is easy to govern. A Deep Agent running for two hours without human oversight is a different problem. Here is how you keep it within policy from action one to action one thousand.

Long-running AI agent governance breaks the assumption that a person reads the output before anything irreversible happens. A Deep Agent research run can execute hundreds of tool calls over two hours, dispatch subagents, write files and call external APIs, then finish before anyone opens the terminal. Every one of those decisions was taken while nobody was watching.

LangChain is explicit about the workload the harness targets. The deepagents README describes an opinionated agent with "defaults tuned for long-horizon, multi-step work", built on LangGraph, with subagents that carry isolated context windows and a filesystem the agent can read and write. Long horizon is the product goal. It is also the governance problem.

OpenBox, the AI agent governance platform, treats that problem as a runtime one. Its Deep Agents SDK adds a single middleware object to an existing graph and evaluates governance on every model call and every tool call, according to the SDK reference at docs.openbox.ai/developer-guide/deep-agents. What follows is how that behaves across a session measured in hours rather than seconds.

Why Long-Running Agents Require Different Governance Than Short-Task Agents

Long-running agents need enforcement at the moment of action, because the human review step that governs short tasks does not arrive. A short task ends in seconds and a person judges the result. A two-hour Deep Agent session produces hundreds of independent decisions, and each one is either judged as it happens or not judged at all.

The OpenBox Deep Agents SDK wraps an existing graph with one middleware object created by create_openbox_middleware() and passed to create_deep_agent(). The middleware implements eight DeepAgents lifecycle hooks. Governance decisions are evaluated inside wrap_tool_call, and a BLOCK decision raises GovernanceBlockedError before the tool executes.

OpenBox returns one of four governance decisions when an operation is evaluated: ALLOW, REQUIRE_APPROVAL, BLOCK and HALT. ALLOW permits the operation, REQUIRE_APPROVAL pauses it for human review, BLOCK rejects the action while the agent continues, and HALT terminates the entire agent session. Where several policies apply, precedence runs HALT > BLOCK > REQUIRE_APPROVAL > ALLOW.

That distinction carries most of the weight over a long run. BLOCK is a local correction the agent can work around. HALT is the stop button for the whole session. Short tasks rarely need the second decision. Multi-hour autonomous runs are the case it exists for.

The Three Failure Modes Unique to Persistent Agent Sessions

Three failure modes appear only once a session runs long: unsafe action sequences, trust that degrades mid-run, and subagent work that nobody supervises. All three are invisible to a check with no memory of the session, which is why OpenBox separates stateless Policies from stateful Behavioral Rules.

The first is sequence. Policies are stateless permission checks written in OPA Rego, and each evaluates a single input document per operation, so a policy cannot see what came before. Behavioral Rules are stateful and track prior actions, detecting sequence, frequency and combination patterns: PII access followed by an external API call without approval, more than 10 failed authentication attempts in one minute, or a database write combined with a file export and an external send.

The second is drift. The Alignment Score is 25 per cent of the Trust Score, starts at 100 for new agents and is updated per session from goal alignment checks, with overall alignment calculated as a weighted average over recent sessions using a decay of 0.95. An agent that wanders from its original goal registers there before it registers anywhere else.

The third is delegation. DeepAgents dispatches subagents through the task tool, and the SDK treats those dispatches as governed tool calls, records the resolved subagent name, and labels the activity with tool type a2a. A researcher subagent inherits the same four verdicts as the root agent rather than running unobserved inside the session.

The table below maps each long-run failure mode to the control that catches it and the decision it can return.

For the same controls applied to other harnesses, the OpenBox Developer Hub: Governing AI Agents with LangChain, LangGraph and Temporal is the parent guide for this article.

How Trust Scores Accumulate and Degrade Across a Long Agent Session

The Trust Score is a 0 to 100 metric calculated as (Risk Profile Score x 40%) + (Behavioral x 35%) + (Alignment x 25%). Across a long session the Risk Profile Score stays static unless the agent is re-assessed, while the Behavioral and Alignment components move with what the agent actually does, minute by minute.

Violations do not hit the Trust Score directly. They reduce the Behavioral Compliance component, which carries 35 per cent weight. A minor violation costs 5 points on that component, which is 1.75 points of Trust Score. A major violation costs 15 points, or 5.25 points of Trust Score. A critical violation costs 25 points, or 8.75 points of Trust Score.

The arithmetic decides what a bad session does to autonomy. Three critical violations in one run remove 26.25 points of Trust Score. An agent that started at 90, the bottom of Tier 1, finishes at 63.75 and sits in Tier 3. Tier changes are immediate in both directions with no stabilisation period, and an upgrade into Tier 1 additionally requires admin approval.

Recovery is deliberately slower than decline. Agents in Tiers 1 to 3 recover at 1 point per day and Tier 4 agents at 0.5 points per day, with consecutive compliance measured over seven days or more. An agent that degrades during a Friday night run is not back at its previous tier by Monday, and the Trust Score trend through a session is therefore the earliest governance signal you have.

Configuring HALT Thresholds for Autonomous Multi-Hour Agent Runs

HALT is configured as a verdict on a Behavioral Rule rather than as a numeric score field in the SDK. In the OpenBox documentation the score floor that ends autonomy outright is the Untrusted band, 0 to 24, where the agent is suspended and cannot operate. Governance Decisions also lists a critically low trust score among the conditions under which HALT is returned.

Create the rule under Agent, then Authorize, then Behavioral Rules, using the four-step wizard: basic information including a priority from 1 to 100, the trigger semantic type, the required prior states, then the enforcement verdict and a reject message. Rules are evaluated in priority order and stop at the first rule that produces a verdict, so a HALT rule belongs above the rules it would otherwise duplicate.

Two SDK settings decide what happens when governance itself is unavailable partway through an unattended run. The on_api_error parameter defaults to fail_open, which allows the operation and logs a warning. For a multi-hour run with nobody watching, fail_closed is the conservative choice. The governance_timeout parameter defaults to 30.0 seconds per evaluation.

middleware = create_openbox_middleware(

    api_url=os.getenv("OPENBOX_URL"),

    api_key=os.getenv("OPENBOX_API_KEY"),

    agent_did=os.getenv("OPENBOX_AGENT_DID"),

    agent_private_key=os.getenv("OPENBOX_AGENT_PRIVATE_KEY"),

    agent_name="ResearchBot",

    known_subagents=["researcher", "writer", "general-purpose"],

    on_api_error="fail_closed",

    governance_timeout=45.0,

    tool_type_map={"search_web": "http", "export_data": "file"},

)

Newly created OpenBox agents require DID signing by default, so pass agent_did and agent_private_key, or set OPENBOX_AGENT_DID and OPENBOX_AGENT_PRIVATE_KEY, unless Require signing is disabled for the registered agent.

At runtime a HALT verdict surfaces as GovernanceHaltError, which is also raised when an approval is rejected or expires. Treat it as terminal. GovernanceBlockedError means one tool call was refused and the session is still live, so it is recoverable.

try:

    result = await agent.ainvoke(

        {"messages": [{"role": "user", "content": "Research AI safety"}]},

        config={"configurable": {"thread_id": "session-001"}},

    )

except GovernanceHaltError as e:

    logger.error("Agent session halted: %s", e)

except GovernanceBlockedError as e:

    logger.warning("Tool blocked: %s", e)

Behavioral Rules for Drift Detection in Long-Running Workflows

Behavioral Rules are stateful authorization rules that detect multi-step patterns across an agent session. Each rule pairs a trigger semantic type with one or more required prior states, and when several prior states are selected, all of them must have occurred before the trigger for the prerequisite to be met. If it is met the action continues. If it is not, the configured verdict applies.

The OpenBox documentation gives a rule worth copying. Name: Query Data Before Generating Reports. Trigger: file_write. Prior state: database_select. Verdict: HALT. Priority: 50. It stops a reporting agent that skips the database query and writes a file straight from model output, which is how properly formatted, entirely fabricated figures end up in a report.

A softer variant in the same documentation uses REQUIRE_APPROVAL: trigger http_post with prior state file_read, so a payment submission pauses when the agent has not read the invoice first. Approval requests appear under Approvals in the main sidebar and in the Adapt tab on the agent page, which is where a reviewer picks them up after the fact.

Drift over a long session is also recorded rather than merely blocked. The Adapt phase aggregates violation patterns for the agent, keeps a trust timeline of promotions, demotions and recovery completions, and produces policy suggestions that an operator can accept, reject or modify. A rule you did not think to write before the run can be created from what the run actually did.

Session Replay: How to Audit What Your Agent Did Over Two Hours

Session Replay plays a completed session back step by step from the Event Log Timeline in the OpenBox dashboard, showing each operation alongside the governance decision recorded for it. For a run that no human watched live, this playback is the audit surface, and the Governance Decisions documentation shows decisions timestamped to the millisecond against each operation.

The record is detailed because the middleware captures more than verdicts. The Deep Agents SDK captures model calls with prompts, completions, model name, token counts and latency, tool calls with inputs, outputs, duration and governance decision, HTTP calls, database operations from supported instrumentation, and file input and output. Top-level events run from SignalReceived and WorkflowStarted through LLMStarted, LLMCompleted, ToolStarted and ToolCompleted to WorkflowCompleted.

Evidence is the other half of the audit. When a session completes, each governance event is hashed with SHA-256, the hashes are combined into a Merkle tree using sorted-pair hashing, and the session root is signed. AWS KMS with ECDSA NIST P-256 is the default signing provider, and an external attestation endpoint, for example a Trusted Execution Environment, can be used instead. Each session produces one proof certificate carrying the Merkle root, the signature and the event count.

That combination is what makes a two-hour session tamper-evident rather than merely logged. Altering a single event changes its SHA-256 hash, which changes the Merkle root, which no longer matches the signature captured when the session closed.

Long-running AI agent governance comes down to one design decision: whether enforcement sits at the moment of action or in the review afterwards. Across a two-hour Deep Agent session, only the first is available. The OpenBox Deep Agents SDK is published under the MIT licence at OpenBox-AI/openbox-deepagents-sdk-python, and the middleware, verdict handling and telemetry behaviour are documented at docs.openbox.ai/developer-guide/deep-agents.

FAQ

Can OpenBox governance be applied to a Deep Agent running on a remote server with no human monitoring?

Yes. The OpenBox middleware evaluates every model call and tool call against your policies wherever the process runs. For unattended runs, set on_api_error to fail_closed so operations stop when the governance API is unreachable, and rely on BLOCK and HALT verdicts rather than a person watching the terminal.

How does OpenBox handle governance when a long-running agent calls external APIs hundreds of times?

Every call is evaluated at its own boundary. The Deep Agents SDK emits ToolStarted and ToolCompleted events for each tool call, and OpenBox returns ALLOW, REQUIRE_APPROVAL, BLOCK or HALT for each one. Use tool_type_map to classify tools so a single policy can cover a whole category of calls.

What Trust Score threshold should trigger an automatic HALT in a long-running autonomous agent?

OpenBox documents HALT as a verdict you configure on a Behavioral Rule, not as a numeric score field in the SDK. The documented floor is the Untrusted band, 0 to 24, where the agent is suspended and cannot operate. Tier 4 covers 25 to 49 and applies strict governance with human review.

How does Session Replay work for a two-hour agent session with thousands of logged actions?

Session Replay plays the recorded session back step by step from the Event Log Timeline, showing each operation with its timestamp and governance decision. The session events are hashed with SHA-256 into a Merkle tree and signed, producing one proof certificate per session carrying the Merkle root, signature and event count.