An agent for your life. A runtime for yours.

The problem

Agents that act are easy to start and hard to trust.

01 · A reply can commit you

An agent writing as you can promise money, confirm a date it never checked, or answer bad news in the wrong tone. Sounding like you is the easy part.

02 · A crash spends twice

A process dies mid-run and the run starts over: the model is billed again and the email goes out twice. Retries are not durability.

03 · Agent code is untrusted code

Tools run code the model chose, fetch from the internet and hold your keys. A loop with no cap runs until the invoice arrives.

PAL · for you

It brings you what matters. It waits on what is risky.

PAL runs on your Mac next to iMessage and WhatsApp. Ordinary replies go out in your voice, paced like you. A reply that promises money, states a date it cannot verify or claims something only you could confirm is held and sent to your self-chat. Step through what happens to one held reply:

Holds: gates at the send boundaryBefore a reply leaves in your voice, two gates can hold it for you. Each is a model judgment plus a deterministic backstop, so an outage cannot fail open.

Clean replyPromises moneyUnverifiable date

Swipe sideways to pan.FitShow steps

⏮◀▶ Play▶

Scrub through steps1 / 3

1. A contact writes

Any ordinary message.

• Gate: model + backstop
• Held
• Sent

How PAL works · Holds and trust · Privacy and control

PAL Runtime · for builders

The parts every production agent needs.

PAL is built on PAL Runtime, and your agents get the same platform. Every step is journaled, so a crash resumes instead of restarting. Budgets are checked before the model is called, so a hard cap costs nothing. Untrusted code runs in a microVM with an egress allowlist, and models are addressed by capability, not by vendor name.

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.FitShow steps

⏮◀▶ Play▶

Scrub through steps1 / 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

How PAL Runtime works · Durable execution · Security model

Quickstart

From a checkout to a first result.

Every path starts from a checkout. Install lists the prerequisites (Docker, Node.js 22, Go 1.26).

git clone https://github.com/dshakes/pal.git && cd pal
(cd packages/cli && go build -o "$(go env GOPATH)/bin/pal" ./cmd/pal)

Try it (no keys)

The whole platform on Docker, with recorded model answers. Each visitor gets a throwaway workspace that expires after 30 minutes.

$ pal demo                                      # Docker builds the images (slow the first time)
…
 Container pal-demo-dashboard-1  Started
demo ready in 1m15s: http://localhost:3001/kiosk
$ pal demo --down                               # stop it and delete its volumes
…
demo stopped, data deleted

Next: Try it: the demo.

Use pal

Install and pair the two channel bridges first (BOT-SETUP.md). Then pal setup walks you through the rest and checks each channel live. This is a real run on a Mac where neither bridge was started yet, so step 2 says how to fix it; lines in <…> come from your model.

$ pal dev            # the control plane and dashboard, on this Mac
$ pal setup
pal setup
────────────────────────────────────────────────

1. Meet pal
   <pal introduces itself and says what it will touch>
   Any questions first? (Enter to continue) >
   pal may read your iMessage/WhatsApp on this Mac and reply as you, sending conversation text to your own model provider. Agree? [y/N] y
   Optional: learn your voice from messages you've sent (read once, not stored)? [y/N] y
2. Connect channels (checked live)
   • iMessage: the bridge isn't running — start it (`pal dev`), then re-check
   • WhatsApp: the bridge isn't running — start it (`pal dev`), then re-check
   [i] start iMessage + check permissions  [w] link WhatsApp  [Enter] re-check  [q] quit >

With a bridge running, its line reads ✓ iMessage: connected (or ✓ WhatsApp: connected) and setup moves on to your voice, trust, your people and facts, and a first Brief. pal setup resumes where you left off and never gives consent for you. Next: How PAL works, then Set up PAL.

Build on PAL Runtime

Start the stack, then let pal onboard design an agent from one sentence, test your provider key with a real call, and stream the first run. This is a real run against a fresh database; run ids are replaced with <run-id> and lines in <…> come from your model.

$ pal dev            # Postgres, Redis, MinIO, the API on :8080, the dashboard on :3001
$ pal onboard
PAL onboard — let's get you set up.
────────────────────────────────────────────────
1. Health check ... ✓
2. Authentication ... ✓  dev login (<dev account>)
3. LLM provider ... ✗  none configured
  Configure an LLM provider to continue.
  Provider (openai/anthropic): openai
  API key:                                      # not echoed
3. LLM provider ... ✓  openai
4. Agent
   What do you want your agent to do? (one or two sentences; Enter for a general assistant)
   > Summarize any web page I paste into three bullets
   designing ... ✓

   Proposed agent: <name>
   <one-line description>
   Why: <why this design fits the goal>
     1. <step> — <what it does>
   First task: "<a first input that proves it works>"

   Create it? [Y/n]
   ✓ created <name>
5. First run ... ✓  run <run-id> started
   streaming events:
   …                                            # one started/completed line per step
────────────────────────────────────────────────
You're set.

Agent output:
  <the agent's answer>

Dashboard:  http://localhost:3001/runs/<run-id>

Run it again:
  pal runs create --agent <name> --input '{"prompt":"What can you do?"}'

What just happened:
  <a short explanation of the run>

next: pal agent dev <name>   # edit locally; re-publishes and re-runs on every save

Next: Quickstart in 60 seconds, then Your first agent.

Measured, not claimed

Every number links to its source.

Real Firecracker microVMs, medians of 20 or more runs, from the committed runtime latency benchmark. They were measured under nested virtualization on a laptop, so compare changes with them; they are not production SLOs.

Operation	p50
Spawn a microVM (RPC returns)	143 ms
Exec round trip in a warm VM	115 ms
Restore a paused VM (RPC returns)	131 ms
Restore, then first exec answered	2,491 ms
Egress request refused by the broker	32 ms

How the numbers move a sandbox through pause, resume and fork: Sandbox lifecycle.

For the people who say no

In production, a missing guard stops the service.

The chart sets the environment to production. From then on these refuse to start, rather than run without the guard:

Missing	What refuses
Shared service token (PAL_GRPC_SERVICE_TOKEN)	The control plane, and every internal gRPC service that checks it
Encryption key for stored credentials (PAL_CREDENTIAL_KEY)	The control plane
Restricted database role for row-level security (PAL_APP_DB_PASSWORD)	The control plane, unless you opt out with PAL_RLS_ENFORCE=0
TLS certificate and key (PAL_TLS_CERT, PAL_TLS_KEY)	The gateway
The firewall rule that forces sandbox egress through the allowlist, when egress rules are declared	The workload inside the microVM

Each boundary and what it demands: Security model and Security boundaries.

Pick your path

Read the docs in order, or jump to your part.

You want to	Read, in order
Know what this is	What PAL is
Use PAL on your own messages	How PAL works → Set up PAL → Holds and trust → Daily use → Build your own personal agents → Privacy and control
Build an agent	What PAL Runtime is → Quickstart in 60 seconds → Your first agent → Agents
Test it, then ship it	Evaluations → Promotion → Deploy to your cloud
Run it in production	Observability → Debugging and support → Operations → Upgrading
Secure it	Security model → Agent identity and policy → Accounts and teams
Look something up	REST API · CLI · SDKs · Environment variables