A pattern from the last quarter of ASO calls, near-verbatim from three different in-house Managers:
If I turn on the automation, does that mean it picks the experiment too?
It is a fair question because the marketing language for product automation has trained everybody to treat "automated" as one binary lever. ASOLOOP splits the lever in two, deliberately, and the split is what lets ICP 1 use one and not the other on the same app at the same time.
This piece is the long version of that split, framed as a decision that an ASO Manager running a real portfolio actually has to make. Walked end-to-end so the next time you sit in front of the Settings → Automation toggles, the choice is decomposed.
What you are actually choosing between
There are two automation opt-ins. They are independent unless one implies the other (which only happens in one direction).
Auto-apply-winner is available in every mode — Learning, Classic, Agent. When on, ASOLOOP applies the winning variant to your live listing after the experiment finalizes, with no manual click in App Store Connect or Play Console. The operator still picks the hypothesis, reviews content, and approves submission. Auto-apply-winner only handles the final click — the one between "experiment finalized" and "winning variant live."
Autopilot is available only in Agent mode. When on, ASOLOOP runs the experiment loop end-to-end with no operator approval at any step: picks the single candidate, generates content, runs claim-safety validation, submits via the store-console agent, scrapes metrics, finalizes, applies winner. Autopilot forces auto-apply-winner on — you cannot have ASOLOOP submit autonomously and then wait for you to apply the winner. The operator can suspend, suppress, revoke, or turn autopilot off at any time, but those interventions are optional, not gating.
The mistake ICP 1 keeps making is reading these as a continuum — off → auto-apply-winner → autopilot — and picking a single setting that covers the whole portfolio. That framing is wrong twice over. First, auto-apply-winner is not a partial version of autopilot; it is a different lever pointing at a different click. Second, the right answer is rarely portfolio-wide.
The decomposition of what gets clicked
Walk through the click sequence of a routine experiment. Each click is a separate operator decision, with its own quality-gate value.
- Pick the hypothesis from the candidate menu (3-4 in Learning/Classic; 1 in Agent).
- Review the AI-generated content for the variant (with the claim-safety validator's pre-display pass already done).
- Approve submission to App Store Connect / Play Console.
- Wait for the platform to run the experiment to its conclusion.
- Read the finalized result and the ASOLOOP posterior.
- Apply the winning variant to the live listing.
Auto-apply-winner removes step 6 only. The operator's quality gate still fires at steps 1-3 — picking the hypothesis, reading the content, approving the submission. That is where the meaningful judgment happens. Step 6 is mechanical once the result is in.
Autopilot removes all of steps 1-3 and 5-6. The operator is not in the routine click path. Step 4, the platform wait, is not an operator click in either configuration — it is a system state.
ICP 1's typical posture is: stay in the routine path for the apps where their judgment is loadbearing, get out of the routine path for the apps where it is not.
When auto-apply-winner is the right answer
Auto-apply-winner is the answer when steps 1-3 still want your eyes and step 6 is wasting them.
Concrete trigger conditions, paraphrased from ICP 1 calls:
- "I review every variant before it ships, but I have stopped reading the finalization emails before applying the winner — the result is already in, my read is rubber-stamping." That click is the textbook auto-apply-winner candidate.
- "I want to keep picking the hypothesis because the candidate menu still informs my own model of what is working on this app — the menu is half the value." This is the Classic-mode stable-app pattern: 3-4 candidates → pick → review → approve → auto-apply.
- "This app is on a quarterly subtitle refresh; I do not want to be involved in routine final-click work for a Cycle Workflow that runs the same shape every 13 weeks." Same answer — Classic mode + auto-apply-winner.
Notice what is not the trigger condition: low stakes. Auto-apply-winner does not mean "the app is low-stakes enough to remove judgment from." It means "the judgment has already fired by step 3; step 6 is administrative." High-stakes apps with stable hypothesis programs are often the best candidates for auto-apply-winner — the operator's quality gate is in the right place, and the final click is wasted attention.
What auto-apply-winner does not remove: any of the operator's intervention points. You can still suspend the experiment before finalization, suppress the winner signal in the 7-day revocation window, revoke a contribution that drove the hypothesis, push the previous metadata back. None of that changes between auto-apply-winner-off and auto-apply-winner-on. The lever is narrow on purpose.
When autopilot is the right answer
Autopilot is the answer when the operator has accepted the Agent-mode posture — one candidate, no menu — and decided that for this specific app, ASOLOOP's signal-reading is reliable enough that the candidate menu is no longer informative.
The trigger conditions ICP 1 describes are almost always portfolio-segmented:
- "I have 6 apps. Two of them are high-stakes — they will stay in Classic forever. Three of them are stable mid-tail apps with thick signal bases. One is a long-tail app I have not actively touched in eight months." The long-tail app is the autopilot candidate. Possibly one of the mid-tail apps, after a few cycles in Agent mode without override.
- "This app has a thick signal base, the Agent-mode candidate has matched my own pick on the last six cycles, and the routine flow on this app is consuming attention I would rather spend on the high-stakes apps." Same answer. Agent → autopilot is the next step.
- "I am operating a portfolio of 40+ apps; I cannot review every variant on every app, but I trust the validator on the routine ones." Multi-app autopilot at scale — common pattern for indie portfolios and ICP 2 default mode.
What autopilot does not remove: the claim-safety validator. Every model output still passes the validator before display or submission, and on rejection the system either falls back to deterministic templated copy or skips the cycle and notifies the operator. The validator is non-overrideable; autopilot does not turn it off.
What autopilot also does not remove: the four refusal classes. Even with autopilot on, ASOLOOP forces operator preview for pricing-related copy on Subscription/Paid apps, regulated-category claims (medical / financial / legal / children's), icon experiments, and the first experiment after onboarding. These cannot be disabled by toggle. Autopilot is end-to-end on the routine flow; on these four classes, the routine flow includes an operator-review step by structural rule.
The decision table, per app
The honest answer to "auto-apply-winner or autopilot?" is neither one across the portfolio. Walk app by app:
| App profile | Mode | Auto-apply-winner | Autopilot | Why |
|---|---|---|---|---|
| High-stakes, thick signals, you have a strong personal model | Classic | off | unavailable | Your judgment is the value. Stay in the full click path. |
| High-stakes, thick signals, you have stopped reviewing finalization emails | Classic | on | unavailable | Steps 1-3 fire your judgment; step 6 is administrative. |
| Stable mid-tail, regular cadence, Cycle Workflow | Classic | on | unavailable | Routine final clicks across iterations — same answer as above. |
| Mid-tail, Agent-mode candidate has matched your pick consistently | Agent | on (independent) | off | You have accepted the one-candidate posture but still want to review content. |
| Long-tail, you have not touched it in months, the validator + refusal classes are your safety net | Agent | on (forced) | on | You are explicitly delegating end-to-end on this one app. |
| First experiment after onboarding, any app | any | any | refusal class forces preview | Cannot autopilot the first experiment. Structural. |
| Subscription/Paid app, any pricing-copy experiment | any | any | refusal class forces preview | Cannot autopilot pricing-related copy. Structural. |
| Regulated-category app (medical/financial/legal/children's) | any | any | refusal class forces preview | Cannot autopilot regulated-category claims. Structural. |
The point of the table is not the per-row recommendation, which will vary by operator. The point is: the answer is per-app and per-mode, not per-portfolio. You will run different configurations on different apps simultaneously, and that is the design.
Why the layering is structural
A reasonable question at this point: why not just have one "automation level" slider that goes off → light → full? Because the lever pointed at "remove the operator from the final click" and the lever pointed at "run the loop end-to-end" are not on the same axis. Bundling them as a single slider would force a meaningless compromise — light setting is too much for the high-stakes apps and too little for the long-tail ones.
The other reason: each opt-in carries its own risk-acceptance modal, scoped to what it actually does. Auto-apply-winner's modal says "the applied variant becomes your live listing — verify in your store console." Autopilot's modal says "AI-submitted experiments and AI-applied winners are your responsibility." These are different commitments. A bundled slider would force a single modal at the wrong specificity for at least one of them.
Layered opt-ins, scoped consent, per-app configuration. The shape of the toggle exposes the shape of the decision. The decision is yours; ASOLOOP surfaces it correctly.
What stays available regardless
Both opt-ins live under the broader product commitment that nothing in ASOLOOP is locked in. Auto-apply-winner does not block signal revocation. Autopilot does not block experiment suspension. Both can be toggled off at any time; in-flight experiments complete and stop, the audit log records the change, and the per-app intervention points stay open. The full long-form on that commitment lives in why every signal can be revoked.
The same reasoning shows up in a different shape across how the loop works — Cycle Workflows that run under autopilot on long-tail apps still write signal contributions back into the per-app evidence library on every iteration, so the operator's eventual return to the app inherits the accumulated evidence, not a black-box catch-up.
That is the layered automation contract: click-reduction without trust loss. The trust survives because the levers are scoped, the consent is explicit, the refusals are structural, and the audit trail is permanent.