What PAL Runtime is

PAL Runtime is the production runtime for AI agents that PAL itself runs on. You describe an agent (a prompt, a model capability, optional connectors or a workflow graph) and the runtime executes it, streams the result, and keeps a journal of every step. It is for developers who run their own agents and for the platform teams who operate them. Crash recovery, spend limits and sandboxing are the runtime’s job, not code you write per agent.

PAL Runtime: system contextWho calls PAL, the control plane that decides, and the data plane in your VPC that runs the work. Step through a call, or hover any box.

Swipe sideways to pan.

1 / 7

1. A call arrives at the gateway

From the CLI, an SDK, the console or another agent. TLS and authentication happen here, once.

PAL Runtime services
Trusted host code
Untrusted code
Data stores
Outside PAL

Every run executes in one of two isolation tiers, set by manifest.isolation on the agent version. Code you wrote goes in the shared tier. Untrusted code (user uploads, arbitrary shell commands, packages from the internet) goes in the microVM tier. The caller supplies only the input and cannot change the tier. How the pieces fit together is on How PAL Runtime works.

Two tiers, one journal

Every step is written to the journal_events table before it executes, in both tiers. Crash recovery, the dashboard waterfall and Ed25519 receipts all read that one table. There is no second event store.

	Shared tier	MicroVM tier
Declared as	`"shared"` (default, or absent)	`"microvm"`
Executor	Goroutine inside the control plane	Scheduler, then runtime-manager, then Firecracker, Kata or a K8s Job
Isolation	Same OS process. First-party code only	Its own microVM (see Isolation)
Egress	Not sandboxed	Per-VM allowlist, deny by default (see Egress)
Crash resume	Recovery sweep plus completed-step replay	Recovery sweep re-schedules the VM; gives up after 3 attempts
Use for	Loop agents, bridge replies, dashboard runs, trusted workflows	User-supplied code, exec tools, untrusted packages

POST /v1/runs reads manifest.isolation from the resolved agent version and dispatches accordingly. An unknown value is rejected at publish with HTTP 400, so a typo fails at deploy.

Declaring the microVM tier

manifest:
  isolation: microvm          # routes this agent version to the microVM stack
  image_digest: …@sha256:…
  limits: { vcpu: "250m", memory: "128Mi", timeout: "60s" }
  egress_rules: [{ pattern: "api.openai.com" }]

isolation: microvm schedules the workload with isolation class standard. For a stronger class (untrusted, hostile, wasm), schedule a headless agent with pal run agent.yaml; see Isolation. Inside the VM, the harness serves a typed tool registry (shell_exec, http_fetch, read_file, write_file, list_dir); file tools are confined to /workspace.

What you get in production

Capability	Mechanism	Where to read more
Checkpointing	Every step journaled before it runs, in both tiers	Durable execution
Auto-restart	Recovery sweep (`PAL_RECOVERY_INTERVAL`, default 30 s) steals expired run leases and re-drives from the last completed step	Durable execution
Throttling	Budget gate returns 402; per-tenant concurrent-VM cap; spawn-storm guard returns 429 (`PAL_SPAWN_RATE_PER_MIN`, default 120)	Budgets
Monitoring	VM list, detail, audit trail, live logs, cluster and quota views: `pal vm list\|get\|logs\|stop\|exec`, dashboard `/runtime`	Operations
Backend	One per runtime-manager process: `RUNTIME_BACKEND` = `k8s` (default), `firecracker`, `kata`, `docker`, `wasm`	Runtime internals
Traceability	W3C trace context from control plane to in-VM harness; Ed25519 receipts	Observability, Receipts

A background sweep TCP-probes peer services every 60 s (PAL_HEALTH_SWEEP_INTERVAL). After 3 consecutive failures it marks the peer down and notifies the operator once per transition. GET /v1/system/health (JWT) returns the current snapshot.

Interactive multi-turn agents use sessions, which run on the shared tier. Next: create an agent.