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.
#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.
- 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.
- 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
noneaction 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. - 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/activateon 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).
| Level | What happens |
|---|---|
| 1 — Review each action | The 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 plan | The 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 autonomy | The 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. |
/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.
- Objective — choose what Autopilot optimises toward:
Objective What 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. - 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.
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.
| Action | What it does |
|---|---|
create_flow | Generates 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_audience | Generates a new audience (segment) and saves it. Name is also prefixed with [Autopilot]. |
ab_test_flow | Creates a single flow with a split node that routes users between two independently briefed variants (A and B) at equal weight. |
ab_test_copy | Adds 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_split | Re-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_flow | Pauses 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. |
none | No 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_flowandab_test_floware 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_floworab_test_flowis 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/activateon 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
failedand the run continues. Autopilot never retries in the same run and never blocks on telemetry writes.
#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.
- Events & catalogue — ensure your key lifecycle events are tracked.
- RevenueCat — unlock the revenue objective.
- Building flows — understand the flow structure Autopilot creates and how to extend it manually.