Apps & Running Sessions

Apps & Running Sessions

Move from saved strategy configuration to a launched session and inspect its outcomes.

An app holds saved source and configuration. A stage session is the in-memory runtime executing that configuration. A server, also called a sandbox, hosts the run and has its own identity and stored results.

Saving an app, publishing a Lab revision, launching a server, and changing runtime controls are separate operations.

App lifecycle

From saved app to running session and stored resultsA saved app supplies source and settings. Launch configuration selects the runtime, broker, and warmup. A running stage session processes data and requests execution. Stored server results preserve available snapshots and history for later inspection. Saving or publishing does not launch a session.Saved appLaunch configurationRunning stage sessionStored server resultsSource · instrument · models · strategy settingsRuntime · broker/account · warmup · app groupData → decisions → requests → execution outcomesAvailable snapshots · trades · logs · run identityBroker orders and positions have their own lifecycle.
Saving or publishing creates configuration. Launching starts execution. Stored results are historical evidence, not a live account view.

Launch may map the saved app to a different runtime or create a runtime copy based on the selected broker. Review the actual launch target and account, not just the original app's name.

Live views use the running session when available. Stored server results support later inspection, but are not guaranteed to be the final broker state or a complete replay of every in-memory value.

Follow the workflow

  1. Getting started: create and check a small saved app.
  2. Configuration: instrument, source, sizing, and data settings.
  3. Importing and publishing: move a saved snapshot through Agent Lab.
  4. Launching: review the target, broker, and warmup.
  5. Simulation and live execution: understand each environment.
  6. Monitoring: inspect data, decisions, orders, and results.
  7. Automation modes: control new bot requests during a run.
  8. Stopping and restarting: distinguish runtime control from account actions.
  9. Multiple apps: compatible leader/follower launches.
  10. Troubleshooting: isolate configuration, startup, and execution issues.

For specific integrations, keep PineScript and Polymarket alongside this workflow. PineScript is a source editor, not a broker type.

Troubleshooting

Resolve unsaved drafts, revision conflicts, failed runs, and interrupted assistant tasks.

Getting started

Save a small app, establish a historical baseline, and verify its first running session.

On this page

App lifecycleFollow the workflow