The 30-Minute Runtime Trap: Agent Compute Has Three Planes

Two Vercel releases today make very different compute products look deceptively similar.

The Bun runtime on Vercel Functions now supports packages up to 5GB uncompressed and per-function durations up to 30 minutes. Both features are beta, require Fluid compute, and bring Bun to limits that were already available for supported Node.js and Python runtimes.

Vercel Sandbox also became globally available across four initial regions, with project defaults, per-sandbox placement, and configured failover regions on Pro and Enterprise plans. A developer can now put an isolated workspace closer to its database or object store instead of accepting Washington, D.C. as the only placement.

Both can run substantial code for a meaningful amount of time. Both can sit behind a web application. Both can host part of an AI agent. That does not make them interchangeable.

The repeated angle to avoid

The ten most recent posts here covered security treatment states, soft-navigation measurement, agent authorization loops, credential isolation, payment routing, MCP detection, encrypted handshakes, deployment authentication, checkout experiments, and plugin trust. Older overlapping posts covered long-running agent checkpoints, worktree isolation, harness sessions, upload quarantine, prototype exits, and runtime credentials.

The weak version of this article is the old X needs Y formula: agent code needs sandboxes. That repeats the generic isolation advice and ignores why today's function announcement makes the placement decision harder.

The sharper thesis is that capacity overlap creates architecture ambiguity. A 5GB, 30-minute function can now fit dependencies and work that previously forced a team toward a container or sandbox. The correct boundary is not package size or elapsed time. It is which plane the code belongs to: trusted coordination, hostile execution, or durable evidence. When those planes are compressed into one long request, timeout, retry, credential, and recovery behaviour become accidental.

Fresh evidence and background context

The source map separates this week's platform changes from the durable mechanics they expose:

Source	Freshness	What it contributes
Bun large functions and extended duration	24 August 2026	A 5GB uncompressed package ceiling and 30-minute per-function limit, plus Fluid compute and beta constraints
Vercel Sandbox global availability	24 August 2026	Four starting regions, project and per-sandbox placement, failover settings, and snapshot locality
How Ora benchmarks major AI agents	21 August 2026	Separate runtimes per harness, step-level tracing, comparable journey conditions, and a sandbox override for instrumentation
Vercel Sandbox hacker challenge	18 August 2026	The stated security boundary: Firecracker microVM isolation plus host-enforced network controls and credential brokering
Function duration documentation	Current primary documentation	Termination semantics, configuration scope, supported runtimes, HTTP idle-connection behaviour, and the 800-to-1800-second beta boundary
Sandbox firewall documentation	Current primary documentation	Default outbound access, deny and allowlist modes, DNS and SNI limitations, runtime policy changes, and brokered credentials
Persistent Sandbox documentation	Current primary documentation	Automatic filesystem snapshots, session versus sandbox lifetime, resume behaviour, retention, and separate storage cost
Vercel Workflows documentation	Background primary documentation	Durable pause, resume, deterministic replay, step state, event logs, and region pinning

The new information surplus is the placement model between the sources. The releases describe more function capacity and wider sandbox placement. The security post describes containment. The workflow docs describe durability. Ora describes comparability and traces. Joined together, they show that a production agent runner is not one bigger process. It is a control system around a replaceable execution environment, with evidence that survives both.

Thirty minutes is a timeout, not durability

A longer function is useful. It can finish an import, render a substantial document, stream a long model response, run a bounded transformation, or call several slow services without being terminated at the old ceiling.

The important wording in the duration documentation is that Vercel gives an invocation more time before terminating it. If the invocation exceeds its configured limit, it is terminated. Increasing maxDuration changes the deadline; it does not make the work resumable.

That distinction produces four separate clocks:

Clock	Question	A 30-minute function answers it?
Request clock	How long can this invocation keep serving or streaming?	Yes, up to its configured maximum and client-path limits
Work clock	Can the business task pause for an hour, a day, or human approval?	No
Recovery clock	Can execution resume from the last completed step after termination or deployment?	Not by duration alone
Retention clock	How long do inputs, intermediate state, logs, and outputs remain available?	Not by duration alone

The docs also warn that an idle HTTP/2 connection can receive protocol-level pings while HTTP/1.1 clients and intermediaries may still close an idle path. A server being allowed to run for 30 minutes does not guarantee that a browser, reverse proxy, mobile network, or webhook caller will wait for it.

Use a long function where the task is bounded, trusted, and restartable from authoritative input. Return a job identifier early when the customer does not need the result in the original response. Do not use duration as a substitute for a state machine.

A function is the control plane when it owns trusted decisions

The control plane accepts the request, authenticates the caller, validates input, assigns an idempotency key, selects policy, starts work, records transitions, and decides what can happen next.

A function is a good fit for that role because it is already part of the application deployment. It can enforce tenant and resource authorization, read trusted configuration, and publish a small command to a workflow or execution service.

customer or operator request
  -> trusted function
  -> authenticate principal
  -> validate task and business scope
  -> create job + idempotency key
  -> choose execution policy
  -> start workflow or sandbox
  -> return job ID

Fluid compute makes the boundary more important, not less. Vercel documents that multiple invocations can share one function instance concurrently. This improves utilisation for I/O-heavy application work, but it means process-global state can be shared across requests. A cache, mutable singleton, temporary credential, current-tenant variable, or agent workspace must not assume one fresh process per customer or task.

Keep these in the control plane:

• caller authentication and tenant authorization;
• task classification and input schema validation;
• policy selection by data class and action consequence;
• idempotency and duplicate suppression;
• durable job status and retry counters;
• approval state and cancellation intent;
• references to secrets, never secret values copied into untrusted work;
• the rule that promotes an output into a business system.

Do not let model-generated or customer-supplied code run in the same process merely because the function package can now hold its dependencies.

A sandbox is the execution plane when code is not trusted

Vercel describes Sandbox as a compute primitive for untrusted or user-generated code. Its security architecture puts operator code in a Linux container inside a Firecracker microVM on a bare-metal host. The post is explicit that the microVM, not the inner container namespace, is the security boundary.

That matters for coding agents, spreadsheet evaluators, customer scripts, package inspection, generated applications, browser automation helpers, and third-party repository builds. The code may run as root inside its container and have broad access inside the guest. It should still be unable to reach the host or another tenant.

Compute isolation is only half the boundary. The fresh security post says outbound TCP and DNS are intercepted by controls outside the microVM. The firewall documentation exposes the operational consequence: the default network policy is allow-all.

A microVM with unrestricted egress can still send customer data, source code, environment details, or generated credentials to the public Internet without escaping the VM. For private inputs, start from deny-all or a narrow user-defined policy rather than treating network policy as optional hardening.

The minimum execution envelope should define:

• an image or image digest;
• CPU, memory, and session timeout;
• ephemeral versus persistent filesystem behaviour;
• allowed input objects and read/write paths;
• outbound domains and exact CIDR requirements;
• whether DNS must be available;
• credentials brokered at the host boundary;
• commands and child processes allowed by the task;
• maximum output and log volume;
• a cancellation and teardown path.

Credential brokering is particularly useful. The sandbox can make a matching outbound request while the host-side boundary injects the credential, so the secret never enters the guest. That reduces direct theft, but it does not make the resulting authority harmless. A brokered GitHub token that can push to every repository is still too broad. Constrain destination, method, path, principal, and business capability together.

A network allowlist has failure modes of its own

“Allowed domain” sounds more precise than it always is. The Sandbox firewall documentation says domain matching normally uses TLS Server Name Indication and does not terminate TLS. It therefore constrains the hostname negotiated for the connection, not necessarily the HTTP Host that a shared CDN or service ultimately routes.

The docs call out domain fronting explicitly. A client can negotiate an allowlisted SNI and send a different Host header; whether that reaches another virtual host depends on the destination infrastructure. Broad CIDR allowances create another gap: code can use literal addresses or another resolver, bypassing domain filtering and brokered transformations. Allowing IP ranges without domain rules can also leave DNS resolution unrestricted, creating a possible exfiltration channel.

The implementation rules are practical:

1. Prefer narrow, single-purpose hostnames over a shared provider apex.
2. Avoid 0.0.0.0/0, ::/0, and broad private ranges unless unrestricted address access is genuinely intended.
3. Use a transformation or controlled forward proxy when the HTTP host, method, path, headers, and audit record matter.
4. Set deny-all before hostile processing begins if dependency installation required broader access earlier.
5. Test blocked destinations, alternate DNS, literal IPs, redirects, and shared-host routing—not only the approved happy path.

The security boundary is an exercised policy, not the presence of a microVM product name.

A workflow is the durable part of the control plane

Some agent jobs outlive a request even when each individual computation is short:

accept task
  -> prepare workspace
  -> run agent
  -> wait for approval
  -> rerun one failed check
  -> publish evidence
  -> promote result

A 30-minute function cannot safely sleep for a reviewer overnight. It also should not repeat every completed side effect after a timeout. Vercel Workflows provides the missing semantics: pause and resume, managed state, deterministic replay, external hooks, step logs, and runs that can span minutes to months.

The useful split is:

• Function: validates and starts the job.
• Workflow: owns transitions, retries, waiting, and compensation.
• Sandbox: performs untrusted or high-variance execution.
• Business system: remains authoritative for orders, bookings, leads, deployments, or customer records.

A workflow does not make unsafe code safe; execute hostile code in the sandbox. A sandbox does not make business work durable; keep task state in the workflow or database. A function does not become either one because its timeout increased.

The evidence plane must outlive the workspace

Ora's fresh account of benchmarking major agent harnesses provides a useful implementation clue. Each harness expects its own environment and exposes steps differently, so Ora uses a separate runtime for each and traces every step. It also uses a sandbox override to place one framework inside the same instrumented environment as the others.

The transferable lesson is not which harness scored best. It is that comparable evidence has to be designed outside the harness.

A sandbox filesystem is working state. A persistent sandbox automatically snapshots that filesystem on stop, but a snapshot is not automatically a release artifact, audit receipt, or customer record. Persistence is on by default, snapshots incur separate storage, and session duration caps each VM session rather than the long-lived sandbox identity. Snapshot retention defaults and inactivity rules can eventually make old work unavailable.

Publish evidence before declaring the job complete:

• input object IDs, versions, and hashes;
• policy and image version;
• model and harness identifiers where relevant;
• commands or tool events, redacted for secrets and customer data;
• file diff or generated artifact hash;
• tests and checks with exit status;
• network-policy violations and denied requests;
• cost, elapsed time, CPU time, and retry count;
• approval or automatic decision that allowed promotion;
• final business-system write and reconciliation result.

Store evidence in a system with explicit retention and access rules. Do not require a stopped sandbox to be resumed just to explain why an order feed, code patch, quote, product import, or published page changed.

Region choice is a data decision, not just a latency toggle

Global Sandbox placement improves latency when an execution environment repeatedly reads a database, repository mirror, or object store. The new release starts with iad1, sfo1, cle1, and cdg1, with iad1 still the default.

The placement decision also affects state:

• snapshots remain associated with the region where they were created;
• normal creation or resume from an unavailable region produces a snapshot-region mismatch;
• ordinary snapshot migration is not supported—recreate and snapshot the environment in the target region;
• drives are single-region, must be mounted by a sandbox in that region, and cannot use failover regions;
• the GA announcement says configured failover can load snapshot state across regions automatically during a platform failover, which should not be mistaken for a general application-controlled migration feature.

Choose the region from the strongest dependency, not from the web visitor alone. An agent triggered in Brisbane but operating on a Paris-hosted database may be better placed near Paris. A coding agent working from an object-store mirror should run beside that mirror. A sandbox handling regulated or customer-sensitive material also needs a documented data-location decision for snapshots, drives, logs, and exported evidence.

Keep evidence portable even when workspaces are regional. A region failure should not erase the only record of what completed.

A placement matrix for common web work

Workload	Primary plane	Why	Escalate when
Trusted product-image resize from an object ID	Function	Bounded application code, deterministic input, easy retry	Customer-supplied codecs or binaries execute dynamically
AI response streamed to a signed-in user	Function	Trusted loop, I/O-heavy, result belongs to one request	Human approval, long pause, or multi-step recovery is required
Product-feed import with validation and approval	Workflow + functions	Durable steps and retryable trusted transforms	Feed formulas, scripts, or third-party packages must execute
Customer spreadsheet formula evaluator	Workflow + sandbox	Hostile input needs isolation; workflow owns status and promotion	Output can alter inventory, price, or payments without review
Coding agent fixing a repository issue	Workflow + sandbox + evidence store	Workspace is untrusted/high variance; job needs checkpoints and a durable diff/test receipt	Token scope, network destinations, or merge authority expand
One-off dependency inspection	Non-persistent sandbox	Throwaway filesystem and narrow outbound package access	Findings must be retained or rerun reproducibly
Long-lived developer workspace	Persistent sandbox	Filesystem continuity across sessions	Snapshot cost, staleness, secret residue, or region migration matters
Customer booking or refund mutation	Function or workflow calling the authoritative API	Business authorization and idempotency belong outside generated code	The agent proposes rather than executes a sensitive change

The decision rule is straightforward:

Put trusted, bounded request logic in a function; put pause, retry, and approval state in a workflow; put untrusted or generated execution in a sandbox; put proof in durable storage outside all three.

An agent compute contract

This compact contract makes the three planes reviewable before a task reaches production:

agent_compute_contract:
  job_type: repository_fix
  business_surface: ecommerce_storefront
  owner: web_operations
  input:
    repository: owner/storefront
    base_commit: required
    issue_id: required
    data_class: source_code
  control_plane:
    entry: authenticated_function
    durable_state: workflow
    idempotency_key: repository_plus_commit_plus_issue
    pause_before:
      - scope_expansion
      - pull_request_creation
      - production_action
    max_attempts: 3
  execution_plane:
    runtime: sandbox
    image_digest: pinned
    region: near_repository_mirror
    persistent: false
    session_timeout_seconds: 1800
    filesystem:
      read:
        - /workspace
      write:
        - /workspace
        - /tmp
    network:
      initial: deny_all
      allow:
        - repository-read-proxy.example.com
        - package-mirror.example.com
      broad_cidr_access: false
      credential_mode: host_brokered
    authority:
      repository: read
      pull_request: none
      deployment: none
  evidence_plane:
    destination: immutable_job_artifacts
    retain_days: 90
    required:
      - input_manifest_hash
      - image_and_policy_version
      - redacted_tool_trace
      - git_diff
      - tests_with_exit_status
      - denied_network_attempts
      - unresolved_risks
    promote_if:
      - diff_within_scope
      - required_tests_pass
      - reviewer_approves
  cleanup:
    stop_sandbox: always
    delete_ephemeral_workspace: true
    revoke_job_grants: always

The contract does not put a production token in the sandbox. It gives the execution plane read access through a narrow broker, exports a diff and test receipt, and leaves pull-request creation to the trusted control plane after review.

For a product-feed import, change the input, checks, and promotion rule. For a local-service quote helper, keep CRM writes in the trusted API and let the sandbox produce only a structured recommendation. The plane boundaries stay the same.

Failure modes worth exercising

The long function times out after doing the side effect

A 30-minute import creates records, the connection closes, and the caller retries. Without an idempotency key and durable step record, the second invocation repeats completed work. Record the operation before execution and reconcile the authoritative system before retrying.

A microVM gets unrestricted egress

The team enables Sandbox and assumes containment is complete. Generated code sends repository content to an arbitrary host without crossing the compute boundary. Replace the default allow-all policy for sensitive jobs and test denials.

The function becomes the sandbox

A large Bun package bundles compilers, model files, and customer-selected plugins, then executes them inside the application function because they now fit. Package capacity does not change trust. Move dynamic execution to the sandbox and keep the function as coordinator.

Persistent state becomes invisible retention

Every stopped workspace is automatically snapshotted. Old source, generated credentials, customer files, and package caches remain billable and recoverable longer than the business expects. Set snapshot expiry, retention count, cleanup ownership, and a non-persistent default for one-off jobs.

A sandbox snapshot is treated as a portable artifact

The team changes the project region or mounts a single-region drive, then discovers the workspace cannot be resumed where expected. Export required artifacts separately and rebuild disposable environments from pinned images and input manifests.

A brokered credential is still too powerful

The secret never enters the guest, but any matching request can trigger a broad API capability. Restrict destination, method, path, repository, resource, action, rate, and job lifetime. Brokered is a delivery property, not an authorization policy.

A trace is complete but not comparable

Two harnesses emit different event shapes, use different starting state, or receive different network access, yet one is declared better from success rate alone. Normalise task fixture, model, image, network policy, starting commit, timeout, and evidence schema before comparing outcomes.

Cancellation stops the UI, not the work

The user presses Cancel, the browser disconnects, but the function, workflow step, or sandbox process continues. Cancellation must be a durable control-plane state checked before every new side effect, followed by explicit process termination, grant revocation, and a final evidence receipt.

A migration checklist for long agent routes

Before increasing an existing route from 800 to 1800 seconds, review the architecture rather than changing one number:

1. Name the trust class. Is every executed byte deployed application code, or can a user, model, package, repository, or file influence it dynamically?
2. Name the recovery point. If compute stops at minute 29, which completed step can resume without repeating a side effect?
3. Separate request from job. Can the caller receive a job ID and reconnect instead of holding one fragile connection open?
4. Add idempotency before retries. Define the key and authoritative reconciliation query.
5. Inventory credentials. Decide which stay in trusted control code and which, if any, are brokered narrowly to the execution plane.
6. Set network policy explicitly. Never inherit allow-all by accident for private inputs.
7. Choose persistence deliberately. Use non-persistent workspaces for throwaway tasks; set expiry and retention for state that must resume.
8. Pin image and region. Record the image digest, data dependency, snapshot expectations, and failover limitations.
9. Export evidence before promotion. A result is not complete until its diff, checks, policy version, and business outcome are stored outside the runtime.
10. Exercise timeout, cancellation, and regional failure. Happy-path duration proves little about recovery.

The practical conclusion

Today's Bun update removes two real constraints. A substantial trusted workload no longer has to leave Vercel Functions solely because its package exceeds 250MB or its normal execution exceeds 800 seconds. Today's Sandbox update removes another constraint by making isolated execution region-selectable and failover-aware instead of tied to one location.

Those improvements create overlap in capacity, not equivalence in semantics.

A function is still a bounded application invocation that can be terminated at its deadline. A workflow is still the durable owner of pauses, retries, approvals, and replay. A sandbox is still the place to contain code whose behaviour is not part of the trusted deployment—and its default egress still requires an explicit decision. A snapshot is still workspace state, not a permanent evidence record.

Use the larger limits where they simplify trusted work. Do not let them collapse the architecture. Keep control, execution, and evidence as separate planes, then make duration, region, persistence, network, credentials, and retention explicit inside each one. That is how a 30-minute agent job becomes recoverable rather than merely long-running.