Resource Leases for AI Agents: Prevent Orphaned Tools and Duplicate Work

An agent that starts a tool does not necessarily remain alive long enough to finish or clean it up. Workers crash, requests time out, models are retried, and orchestration services lose network connectivity. Without explicit ownership, two agents may operate the same browser session or the same abandoned job may run forever.

A resource lease is time-limited ownership. A worker may use a resource while its lease is valid, renew the lease while making progress, and lose authority when the lease expires. This small distributed-systems primitive is especially useful for agents because model calls are slow, variable, and frequently retried.

Identify Resources That Need Exclusive Ownership

Not every tool needs a lease. Read-only searches can often run concurrently. A lease becomes valuable when duplicate use is expensive, confusing, or unsafe:

• an authenticated browser profile;
• a file transformation job with shared output;
• a deployment environment;
• a hardware device or remote desktop;
• a payment or messaging workflow;
• a queue item that must have one active handler.

Define the resource key narrowly. browser/account-42 is safer than locking every browser, while deploy/production may intentionally serialize all production releases.

Store a Fenced Lease, Not Just a Boolean Lock

A useful lease record includes an owner, expiration, and monotonically increasing fencing token:

{
  "resource": "browser/account-42",
  "owner": "run-8f21",
  "expiresAt": "2026-08-29T05:07:00Z",
  "fence": 184
}

The owner proves which run acquired the lease. The expiration allows recovery after a crash. The fence prevents a paused former owner from resuming after another worker has acquired the resource.

Every mutating tool request should carry the fencing token when the tool supports it. The tool rejects tokens older than the latest accepted value. Without fencing, an expired worker can wake up and continue acting even though the database says ownership moved on.

Acquire and Renew With Compare-and-Swap

Lease acquisition must be atomic. Create the record if absent, or replace it only when expired. A transaction, conditional write, or compare-and-swap operation can enforce that rule.

Choose a duration longer than normal scheduling jitter but shorter than the time you can tolerate an abandoned resource. Renew well before expiration and add jitter so thousands of workers do not renew simultaneously.

Do not let the model decide whether it still owns a lease. The orchestrator should check time and token mechanically before every side effect. If renewal fails, stop tool execution and move the run to a recoverable state.

Separate Lease Expiry From Job Completion

An expired lease does not prove the previous operation failed. A browser may have submitted a form immediately before its worker crashed. The next owner must reconcile external state before retrying.

Use idempotency keys for APIs, operation receipts for tools, and a state-inspection step for systems that lack idempotency. “Lease acquired” grants permission to investigate and continue; it is not permission to blindly replay.

For long tasks, record checkpoints outside the leased resource. A replacement worker can determine which steps completed and which require confirmation.

Make Cleanup Best-Effort and Recovery Deterministic

Release a lease explicitly after successful cleanup, but never depend on release alone. Process termination can interrupt any finally block. Expiration is the real recovery path.

Provide a sweeper that finds expired leases, closes disposable resources, and alerts on resources that cannot be safely reclaimed. Track acquisition conflicts, renewal failures, expired-owner actions, reconciliation outcomes, and time held.

Resource leases do not make an agent exactly-once. They bound ambiguity. Combined with fencing, idempotency, and reconciliation, they turn “which agent owns this?” from a conversational guess into an enforceable runtime fact.