Browse documentation

Start here

OverviewGetting startedThe mental model

Use the runtime

Run the simulatorPi Agent and workspaceInstall and manage AppsESP32-P4 reference targetESP32-S3 supported target

Build Apps

App developer guideBuild your first AppApp source and packageData and migrationsActions and ToolsView and interactionNetworking and native servicesApp resourcesSchedulesPackage and updateTesting and debugging

Understand the runtime

Runtime flowGuests and lifecycleLayers and ownershipHarness boundary

Security

Trust and capabilitiesData isolationLifecycle and recovery

Reference

App manifestPocketPi APIView APICLI referenceLimits and compatibility

Examples

Exa App walkthroughRobinhood App walkthrough

Project

Current boundariesValidation status

Schedules

PocketPi has two scheduling models because reasoning work and deterministic App work have different owners. Use an Agent wake to ask the resident Agent to think; use an App schedule to run one named Action without a model turn.

Choose by owner

Agent wakeApp schedule
Declared byAgent through schedule.* ToolsApp release in app.json
Persistent statePi Agent schedule storeApp-local schedule state
RunsA prompt through the resident HarnessOne local Action with fixed args
Model requiredYesNo
Example“Every morning, review research and decide what needs attention.”“Refresh portfolio data every five minutes.”

Declare an App schedule

"schedules": [
  {
    "id": "portfolio-refresh",
    "everyMinutes": 5,
    "action": "refreshPortfolio",
    "args": {}
  }
]

The Action name is local and unqualified. Installation evaluates actions.js and rejects the App if the Action is missing. The runtime clamps intervals to at least 60 seconds.

Headless execution

  1. The scheduler claims a due App declaration.
  2. The shared Action runner loads or reuses that App's Action Guest.
  3. The Action executes with source: "schedule".
  4. Any successful transaction commits SQLite and increments the App revision.
  5. The schedule records success only after the Action completes.
  6. A closed View remains unloaded; it projects current data when opened later.

Admission and busy behavior

v1 executes one ordinary Action at a time. Scheduled Actions share that bounded runner rather than creating background concurrency. Hosts poll schedules only when install/uninstall and other exclusive product work allow admission. This keeps behavior deterministic on constrained hardware.

Update and uninstall behavior

  • An App update replaces its schedule declarations with the candidate release after successful activation.
  • Existing App schedule state is reconciled to the current declaration.
  • Uninstall removes all schedules and cursors owned by that App.
  • Removing an App Tool does not affect Pi Agent wake schedules, but a future wake may no longer find that Tool.