docs
Documentation menu

The Autopilot

Pushlane's Autopilot is a daily AI growth agent. Turn it on, pick an objective, and it silently creates flows, tests copy, and builds audiences — using only the events and segments already in your catalogue.

Heads up
Autopilot is available on the Scale plan only. The toggle is visible on the Autopilot page; it returns a 402 if your account is on a lower tier.

#How it works

Once per day at 06:00 UTC, Pushlane runs one Autopilot cycle for every tenant with the toggle enabled. The cycle has three phases — all happen automatically, with no input required from you.

  1. Collect (no AI, no cost). A compact snapshot is assembled: the events you have actually recorded (top names with their 30-day counts and reach), your saved audiences, every existing flow with its 7-day send and suppress counts, and the last ten Autopilot actions with their outcomes. It also carries a digest of Pushlane's starter-template library so the agent copies sane cadences (onboarding pushes are hours-to-a-few-days apart, never a week). Only aggregate numbers are read — never individual user rows.
  2. Plan (Claude Opus). The model reads the snapshot and your chosen objective, then proposes a plan of at most three actions with short, structured rationales (a bold takeaway plus a couple of bullets — no walls of text). If the data is insufficient — for example, fewer than about 50 sends on an experiment — it emits a none action with a written rationale; doing nothing is explicitly a valid and common outcome. On a brand-new or near-empty account it instead proposes a starter plan: a first onboarding or activation sequence grounded in your app's identity, the events that already exist, and the template cadences.
  3. Execute (Claude Sonnet). Each action is executed through the same path the builder uses: flow generation goes through the flow generator, audience creation goes through the audience generator, and every created flow is activated via /v1/flows/activate on the ingest worker. Consent checks, frequency caps, and quiet hours are enforced by the engine exactly as they are for human-built flows — there is no bypass.

Every plan and every action — including the ones that were skipped or that failed — is shown in the activity feed on the Autopilot page. Transparency is the same at all three autonomy levels; what changes is only whether an action needs your approval before it runs (see below).

#Autonomy levels

Autopilot plans the same way at every level. The autonomy level is only a gate that decides how much runs without your approval. Pick it right under the objective on the Autopilot page — the default is level 1 (the safest).

LevelWhat happens
1 — Review each actionThe agent proposes a plan, but nothing runs until you Approve each action individually in the feed. Decline an action (with an optional note) and it never runs; the note is read back to the agent on the next run.
2 — Approve the planThe whole daily plan is proposed at once. A single Approve runs all of its actions end to end — flows, in-flow A/B tests, audiences. Decline rejects the whole plan.
3 — Full autonomyThe agent plans and executes on its own every day, then iterates as data arrives. You still see every decision in the feed — you just don't have to approve anything.
Note
Nothing is ever sent to your real users without passing the gate for your level. Planning never activates a flow; only an approved (or full-auto) action does, through the same /v1/flows/activate path human-built flows use.

#The feed & chat

The Autopilot page shows the master control (toggle, objective, autonomy), a compact Ask Autopilot bar, and the activity feed below it.

  • Feed — every run and its actions, newest first, with the real status (a failed action shows the honest reason from the generator or worker, never a fake success). Approve / Decline appear per-action at level 1 and per-plan at level 2.
  • Ask Autopilot — the bar above the feed opens a chat overlay. Ask why the agent did (or didn't do) something and it answers from the run journal only — it never invents numbers, replies in plain text, and records what you want prioritised for the next run. It cannot execute anything itself: if you want a change it tells you it lands on the next daily run, or asks you to Approve/Decline a pending action. Every feed card's Cite in chat button opens the overlay pre-loaded with that decision.
  • History — conversations are saved. The History button lists past chats (most recent first); reopen one to continue it, or delete it from the list.

#Turning Autopilot on

Go to Autopilot in the sidebar. You will see one toggle and one dropdown.

  1. Objective — choose what Autopilot optimises toward:
    ObjectiveWhat the agent pursues
    retentionRe-engage users who have gone quiet; reduce churn signals.
    revenueNudge trial-to-paid conversion and subscription upgrades. Locked until you connect a revenue source (RevenueCat or Apple) — the dropdown is disabled without one.
    engagementDrive feature discovery and session-start events.
  2. Toggle ON. The setting is saved immediately via PUT /api/agents/autopilot, and Autopilot kicks off its FIRST run right away — you don't have to wait for the daily window. That first plan appears in the activity feed within a few seconds (you'll see it “thinking”), and from then on it runs automatically once a day at 06:00 UTC.
Note
To trigger a run immediately for testing, a signed-in member can call POST /api/agents/autopilot/run?self=1 with their session cookie — it runs Autopilot for their own tenant only (same Scale-tier gate, 402 otherwise). This is the same code path as the cron — not a simulation.

#What Autopilot can do

The agent may emit any of the following action types in a single run. At most three actions are executed per day — this cap is enforced in code, not only in the prompt.

ActionWhat it does
create_flowGenerates a new flow from a precise brief, activates it immediately. The flow name is prefixed with [Autopilot] and its created_by field is set to 'autopilot'.
create_audienceGenerates a new audience (segment) and saves it. Name is also prefixed with [Autopilot].
ab_test_flowCreates a single flow with a split node that routes users between two independently briefed variants (A and B) at equal weight.
ab_test_copyAdds one or two alternative push copy variants to a message node in any flow in the account, rebalancing all variant weights evenly. The edit preserves the flow's status — a paused flow stays paused.
adjust_splitRe-weights a split node or message node variants on any flow — for example, to shift traffic toward a winning copy after sufficient signal. The edit preserves the flow's status.
pause_flowPauses an underperforming flow. Status is set to 'paused' on the flows table (the same mechanic as the operator's Pause) and the compiled IR status is kept in sync.
noneNo action. The model writes a rationale explaining why acting would be premature. This is the most common outcome in the first week.

#Guard-rails

The following rules are enforced in code on every run. They are also encoded in the strategy prompt, but the code wins — a plan that violates them is silently corrected or skipped before execution.

  • Edits preserve a flow's status. Autopilot now has full-account scope — it can edit, re-weight, A/B-test, or pause any flow, including ones you created. But an edit of an existing flow never changes its lifecycle status: a paused flow stays paused, a draft stays a draft. Autopilot cannot silently re-activate a flow you paused. This is enforced in code — edits go through the same status-preserving save path the builder uses, never the activation path. On a human-created flow it prefers reversible changes and labels the action in the feed (human-created flow).
  • At most 3 actions per run. The plan is truncated after the third action regardless of what the model emits.
  • At most 10 active Autopilot flows per tenant. If this cap is reached, create_flow and ab_test_flow are skipped (status: skipped) until the count drops below the limit.
  • Real, recorded events only. The agent is given the events you have actually recorded (not just declared) and is instructed to trigger only on those. This is also enforced in code: before a create_flow or ab_test_flow is activated, its entry trigger is verified — the entry event must have been recorded at least once for your app (or the entry segment must exist). Pushlane's own delivery telemetry (e.g. message_sent) doesn't count: it is recorded for analytics but never routed to a flow, so it can never be used as a trigger. A flow that would never fire (a hallucinated, never-seen, or delivery-only event) is refused with an honest reason instead of being activated, and if that check can't be read the action fails closed (never activated on a guess).
  • Same delivery path as human flows. Created flows go through /v1/flows/activate on the ingest worker. Opt-in consent (R10), frequency caps, and quiet hours are enforced downstream — there is no code path that bypasses them for Autopilot.
  • Fail-safe per action. A failing action is logged with status failed and the run continues. Autopilot never retries in the same run and never blocks on telemetry writes.
Note
All Autopilot-created flows appear in your Flows list prefixed with [Autopilot]. You can inspect, pause, or delete any flow at any time from the builder. Autopilot may also improve your own flows (a copy A/B test, a split re-weight) — but it never re-activates one you paused, and every action it takes on a flow you created is labelled in the activity feed so you always see what changed.

#Revenue objective prerequisite

Selecting revenue as the objective requires a connected revenue source. The dropdown is disabled if revenue_source is none. Connect RevenueCat or Apple StoreKit events first, then return to Autopilot to unlock the option.

See RevenueCat integration for the connection steps.

#Next steps

Once Autopilot is running, the best signal it can get is a healthy event catalogue. The more events you send — subscription changes, feature usage, session starts — the more precise the plans it can produce.