CoAdapt-GUI: Joint Workflow Context and Policy Adaptation for Unseen GUI Applications

# CoAdapt-GUI: Joint Workflow Context and Policy Adaptation for Unseen GUI Applications
Source: [https://arxiv.org/html/2608.11588](https://arxiv.org/html/2608.11588)
Zihuan JiangZhixiang ChiSiobhan ReidAffiliation:Li GuZiqiang WangAffiliation:Li GuYuanhao YuWei LiuAffiliation:Li GuYang WangAffiliation:Li GuTse\-Hsun \(Peter\) ChenAffiliation:Li Gu

###### Abstract

Mobile GUI agents remain brittle when deployed to applications absent from source training\. We study novel\-app generalization under a limited target interaction budget and without target demonstrations\. We introduce CoAdapt\-GUI, a test\-time adaptation \(TTA\) framework that jointly adapts structured workflow context and policy from the agent’s own target\-app rollouts and rewards\. The workflow context retains transferable procedures, failure modes, and verification rules while excluding app\-bound source details\. This separation allows reusable workflow knowledge to guide adaptation without transferring source\-interface state\. For policy adaptation, task–context\-matched group\-relative optimization updates a LoRA adapter on a frozen vision–language model\. Across two unseen\-app evaluations, CoAdapt\-GUI reaches45\.0%45\.0\\%on AndroidWorld\-Generalization, compared with37\.5%37\.5\\%for the reported Policy\-Only TTA baseline, and raises AndroidWorld Plus performance from38\.6%38\.6\\%to52\.9%\\mathbf\{52\.9\\%\}\. These results show that transfer\-constrained workflow context provides substantial gains and that joint policy adaptation further improves held\-out performance\.

## 1Introduction

Mobile GUI agents execute natural\-language instructions by interpreting application interfaces and carrying out multi\-step actions\. Recent advances in GUI grounding, trajectory synthesis, and reinforcement learning have substantially improved their performance on established benchmarks\([4](https://arxiv.org/html/2608.11588#bib.bib5);[10](https://arxiv.org/html/2608.11588#bib.bib6);[3](https://arxiv.org/html/2608.11588#bib.bib17);[26](https://arxiv.org/html/2608.11588#bib.bib18)\)\. However, these evaluations generally assume a predefined collection of applications and workflows\([18](https://arxiv.org/html/2608.11588#bib.bib2);[27](https://arxiv.org/html/2608.11588#bib.bib9);[12](https://arxiv.org/html/2608.11588#bib.bib20)\)\. In deployment, an agent may instead encounter an application whose interface and task procedures were absent from training\. Adapting to such applications from limited interaction is therefore essential for effective operation beyond the original training environment\.

This challenge is particularly pronounced under cross\-application shifts\. AndroidWorld\-Generalization distinguishes generalization to unseen task instances, templates, and applications\. Source\-side online RL improves a 7B policy by 26\.1 percentage points on unseen instances, but the gain drops to 8\.3 points on unseen applications\([7](https://arxiv.org/html/2608.11588#bib.bib1)\)\. Success on new tasks within a familiar interface therefore does not imply effective behavior in an unfamiliar application\.

An unseen application can expose both interface\-specific and procedural gaps\. An agent may understand the goal but fail to ground actions to unfamiliar interface elements, or it may execute individual actions correctly yet lack the workflow and completion conditions needed to finish the task\. Updating the policy can change how the agent interprets and acts on the new interface, while adapting an external workflow context can preserve procedures learned from target\-side experience\. Updating only one state may therefore leave an important source of failure unresolved\.

Existing work only partially addresses this target\-side adaptation problem\. AndroidWorld\-Generalization updates the policy from the agent’s own target\-app rollouts while leaving its workflow context fixed\([7](https://arxiv.org/html/2608.11588#bib.bib1)\)\. UI\-Mem jointly learns experience memory and policy during source\-side training, then transfers the resulting knowledge to unseen applications\([25](https://arxiv.org/html/2608.11588#bib.bib31)\)\. This leaves open whether an agent can use interactions collected after encountering a new application to adapt both its workflow context and policy before evaluation on held\-out target tasks\.

We introduceCoAdapt\-GUI, a test\-time adaptation \(TTA\) framework that maintains and jointly updates these two states from target\-app rollouts and task\-level rewards\. Its context channel contrasts successful and failed traces to revise transferable procedures, failure patterns, and completion checks while excluding app\-bound details\. Its policy channel updates a lightweight LoRA adapter through a task–context\-conditioned group\-relative objective\([19](https://arxiv.org/html/2608.11588#bib.bib12)\), while keeping the VLM backbone frozen\. Both updates are derived from the same rollout groups within each adaptation round, and the resulting context and policy are frozen before evaluation on held\-out target tasks\.

We evaluate CoAdapt\-GUI under two levels of unseen\-app generalization\. AndroidWorld\-Generalization\([7](https://arxiv.org/html/2608.11588#bib.bib1)\)evaluates new instances of task types encountered during target adaptation\. In this setting, CoAdapt\-GUI reaches 45\.0%, exceeding the reported Policy\-Only TTA baseline of 37\.5% by 7\.5 percentage points\. To test whether adaptation transfers beyond the task types encountered during target interaction, we construct AndroidWorld Plus with disjoint adaptation and evaluation task types within each target app\. Here, Context\-Only TTA improves the Base Policy from 38\.6% to 48\.1%, while CoAdapt\-GUI further raises success to52\.9%\. These results show that target\-grounded workflow adaptation provides substantial gains and that jointly adapting the policy achieves the best overall performance in both settings\.

This paper makes three contributions:

- •Joint target\-side adaptation from autonomous interaction\.We introduce a test\-time adaptation framework that updates separate workflow\-context and policy states using only the agent’s own target\-app rollouts and task rewards, without target demonstrations or access to held\-out evaluation signals\.
- •Transfer\-constrained context–policy adaptation\.We separate transferable workflow knowledge from app\-bound source state and coordinate two reward\-guided updates from the same target interactions\. Validated reward differences revise the workflow context, while policy credit is computed only among rollouts sharing the same task and context condition\.
- •Evaluation across instance\- and task\-type generalization\.We evaluate CoAdapt\-GUI on the released AndroidWorld\-Generalization unseen\-app split and construct AndroidWorld Plus to hold out entire task types during target adaptation\. CoAdapt\-GUI reaches 45\.0% and 52\.9% in the two settings, respectively, achieving the best overall result in both settings\.

## 2Related Work

### 2\.1Mobile GUI Agents and Generalization

Mobile GUI agents commonly combine a vision–language policy with an interaction loop for action execution and task verification\. GUI\-specific pretraining and high\-resolution perception improve visual grounding and action prediction\([4](https://arxiv.org/html/2608.11588#bib.bib5);[10](https://arxiv.org/html/2608.11588#bib.bib6);[6](https://arxiv.org/html/2608.11588#bib.bib7)\), while OpenMobile and MobileRL scale supervised or online policy learning from executable trajectories\([3](https://arxiv.org/html/2608.11588#bib.bib17);[26](https://arxiv.org/html/2608.11588#bib.bib18)\)\. UI\-Mem also evaluates zero\-shot transfer to held\-out applications by retrieving hierarchical memory accumulated during source\-side policy training\([25](https://arxiv.org/html/2608.11588#bib.bib31)\)\. These approaches acquire transferable behavior on source applications before evaluation; we instead study how an agent can continue adapting after encountering an unseen application\.

AndroidWorld, AndroidLab, and MobileWorld provide programmatically evaluated environments for studying GUI agents across apps and multi\-app workflows\([18](https://arxiv.org/html/2608.11588#bib.bib2);[27](https://arxiv.org/html/2608.11588#bib.bib9);[12](https://arxiv.org/html/2608.11588#bib.bib20)\)\. Related studies examine generalization across websites, tasks, applications, and app categories\([5](https://arxiv.org/html/2608.11588#bib.bib21);[14](https://arxiv.org/html/2608.11588#bib.bib4)\)\. Most closely, AndroidWorld\-Generalization separates unseen instances, templates, and apps, and shows that policy adaptation on target\-app interactions can improve unseen\-app performance\([7](https://arxiv.org/html/2608.11588#bib.bib1)\)\. We use its released setting for comparison, but adapt both workflow context and the policy from autonomously collected target rollouts\.

### 2\.2Test\-Time Context and Policy Adaptation

Test\-time adaptation updates a deployed model using data from its target environment\([20](https://arxiv.org/html/2608.11588#bib.bib14);[22](https://arxiv.org/html/2608.11588#bib.bib13)\)\. Recent methods extend this idea to language\-model reasoning and interactive agents\([30](https://arxiv.org/html/2608.11588#bib.bib25);[31](https://arxiv.org/html/2608.11588#bib.bib26);[2](https://arxiv.org/html/2608.11588#bib.bib29)\)\. Few\-shot GUI methods such as LearnAct and AdaptAgent also use target experience, but rely on demonstrations rather than the agent’s own reward\-bearing interaction\([15](https://arxiv.org/html/2608.11588#bib.bib27);[21](https://arxiv.org/html/2608.11588#bib.bib28)\)\. Our setting instead uses executable rewards from autonomously collected trajectories and evaluates adaptation on held\-out target tasks\.

External memory provides a complementary in\-context adaptation channel\. AppAgent records explored app functionality, Agent Workflow Memory abstracts reusable routines, and Mobile\-Agent\-E and MobiMem accumulate experience as evolving notes or prompt memory\([28](https://arxiv.org/html/2608.11588#bib.bib8);[24](https://arxiv.org/html/2608.11588#bib.bib22);[23](https://arxiv.org/html/2608.11588#bib.bib23);[16](https://arxiv.org/html/2608.11588#bib.bib24)\)\. These methods demonstrate the value of explicit workflow knowledge while generally keeping the underlying policy fixed\. Unlike UI\-Mem, which varies memory guidance within each policy\-optimization group to internalize guided behavior\([25](https://arxiv.org/html/2608.11588#bib.bib31)\), CoAdapt\-GUI treats context and policy as separate target\-side states\. Reward differences across context variants revise the workflow state, while policy credit is computed only among rollouts sharing the same task and context condition\. Agent\-SAMA additionally represents app execution as a finite\-state machine \(FSM\) for planning and recovery\([8](https://arxiv.org/html/2608.11588#bib.bib19)\)\. In contrast, CoAdapt\-GUI uses FSM\-grounded context to constrain which workflow knowledge may transfer across applications, excluding app\-bound source state from transfer\.

E\-SPL jointly optimizes a global free\-text prompt and a policy from shared rollouts\([29](https://arxiv.org/html/2608.11588#bib.bib15)\)\. CoAdapt\-GUI instead combines validated evolution of structured workflow context with reward\-based LoRA adaptation\. Their overlap is therefore limited to the high\-level idea of joint context–policy adaptation\.

## 3CoAdapt\-GUI: Test\-Time Context–Policy Adaptation

We study test\-time adaptation to an unseen GUI application\. Our central premise is that test\-time behavior depends on two complementary adaptive states\. An explicit workflow stateMtM\_\{t\}provides contextual guidance about procedures, failure conditions, recovery strategies, and completion checks\. A parametric stateθt\\theta\_\{t\}controls the policy’s underlying visual–action behavior\. Rollouts in the target application provide executable feedback for adapting both states\.

Co\-adapting these states introduces two forms of interference\. First, source experience may mix portable workflow knowledge with application\-specific screens, identifiers, geometry, and navigation paths, causing negative transfer on an unseen interface\. Meanwhile, changes to the workflow context alter the effective policy input, so reward differences across context conditions need not reflect differences in policy behavior\.

We propose CoAdapt\-GUI, which combines transfer\-constrained workflow adaptation with task–context\-matched policy learning\. The context channel prevents app\-bound source details from crossing application boundaries and stores target\-grounded revisions separately\. The policy channel computes relative advantages only among rollouts sharing the same task and context condition\. The updates are coupled through interaction: the current workflow state shapes the trajectories used for policy learning, while the current policy generates the successes and failures used to revise workflow knowledge\. Figure[1](https://arxiv.org/html/2608.11588#S3.F1)summarizes the resulting adaptation loop\.

![Refer to caption](https://arxiv.org/html/2608.11588v1/evofsm_method_overview.png)Figure 1:CoAdapt\-GUI uses matched target\-app rollouts to refine transferable workflow context and update a lightweight policy adapter on a frozen VLM\. Context\-Only TTA executes only the context branch, whereas CoAdapt\-GUI executes both branches using the same rollout batches\. The adapted context and policy are frozen before held\-out evaluation\.### 3\.1Test\-Time Adaptation Problem

Let𝒜src\\mathcal\{A\}\_\{\\mathrm\{src\}\}and𝒜tgt\\mathcal\{A\}\_\{\\mathrm\{tgt\}\}denote the source and target application sets\. In the strict unseen\-app setting,𝒜src∩𝒜tgt=∅\\mathcal\{A\}\_\{\\mathrm\{src\}\}\\cap\\mathcal\{A\}\_\{\\mathrm\{tgt\}\}=\\varnothing\. More generally, target trajectories never enter source initialization, and application\-specific interaction knowledge from one application is not transferred to another\.

For test\-time adaptation, tasks are partitioned into disjoint adaptation and evaluation sets,𝒬adapt\\mathcal\{Q\}^\{\\mathrm\{adapt\}\}and𝒬eval\\mathcal\{Q\}^\{\\mathrm\{eval\}\}\. Only tasks in𝒬adapt\\mathcal\{Q\}^\{\\mathrm\{adapt\}\}may update the deployed agent; evaluation tasks and outcomes remain unavailable throughout adaptation\.

The workflow state for taskqqcombines an immutable source workflow contextM0​\(q\)M\_\{0\}\(q\)with a target\-grounded stateMttgtM\_\{t\}^\{\\mathrm\{tgt\}\}:

Mt​\(q\)=\(M0​\(q\),Mttgt\),Ct​\(q\)=Render⁡\(Mt​\(q\),q\)\.M\_\{t\}\(q\)=\\left\(M\_\{0\}\(q\),M\_\{t\}^\{\\mathrm\{tgt\}\}\\right\),\\quad C\_\{t\}\(q\)=\\operatorname\{Render\}\\\!\\left\(M\_\{t\}\(q\),q\\right\)\.At interaction stepkk, the effective policy conditions on the task, current observationoko\_\{k\}, interaction historyhkh\_\{k\}, and rendered workflow context:

uk∼πθt\(⋅∣q,ok,hk,Ct\(q\)\)\.u\_\{k\}\\sim\\pi\_\{\\theta\_\{t\}\}\\left\(\\cdot\\mid q,o\_\{k\},h\_\{k\},C\_\{t\}\(q\)\\right\)\.Executing the action sequence produces a trajectoryτ=\{\(ok,uk\)\}k=1K\\tau=\\\{\(o\_\{k\},u\_\{k\}\)\\\}\_\{k=1\}^\{K\}and a task rewardr⁡\(τ\)r\(\\tau\)\.

The parametric stateθt\\theta\_\{t\}contains the trainable LoRA parameters of an otherwise frozen vision–language policy\. Together with the target environment,Mt​\(q\)M\_\{t\}\(q\)andθt\\theta\_\{t\}induce the rollout distribution

τ∼d\(⋅∣q,Mt\(q\),θt\)\.\\tau\\sim d\\\!\\left\(\\cdot\\mid q,M\_\{t\}\(q\),\\theta\_\{t\}\\right\)\.Updating either state therefore changes the interaction data available for updating the other\.

Given an interaction budgetBB, adaptation returns final states\(M⋆,θ⋆\)\(M^\{\\star\},\\theta^\{\\star\}\)\. Both are frozen before evaluation, and their generalization is estimated only on𝒬eval\\mathcal\{Q\}^\{\\mathrm\{eval\}\}\. Adaptation rewards are therefore training signals rather than the final evaluation objective\.

### 3\.2Transfer\-Constrained Workflow Context

Source trajectories mix reusable procedural knowledge with application\-specific interaction details\. Procedures, failure conditions, and completion checks may remain useful across applications with similar functionality, whereas screen layouts, visible strings, resource identifiers, coordinates, and source\-specific navigation paths may cause negative transfer\.

We represent each transferable workflow entry as

w=⟨c,P,F,V⟩,w=\\langle c,P,F,V\\rangle,whereccspecifies when the workflow applies,PPdescribes an abstract procedure,FFrecords failure or recovery conditions, andVVspecifies observable or executable completion checks\. These fields are stored in a typed schema so that applicability, execution guidance, failure handling, and verification can be validated and revised separately\.

For each source applicationaa, we construct a finite\-state machine \(FSM\) grounded workflow context with two components: an app\-bound stateMappaM\_\{\\mathrm\{app\}\}^\{a\}and a transferable stateMtraM\_\{\\mathrm\{tr\}\}^\{a\}\. The app\-bound state is instantiated as a screen\-transition FSM recording concrete screens, action\-conditioned transitions, visible interface cues, and resource\-level information\. This representation makes the expected effect of each action explicit, supporting the identification of failed transitions and possible recovery paths\([8](https://arxiv.org/html/2608.11588#bib.bib19)\)\.

The transferable state contains workflow entries of the form defined above, abstracted from the same source trajectories used to construct the screen\-transition FSM\. Rather than encoding source\-specific screens or transitions, it describes what should be accomplished, which failures should be avoided, and how task completion should be verified\.

An eligibility predicate,Eligibletr⁡\(w\)∈\{0,1\}\\operatorname\{Eligible\}\_\{\\mathrm\{tr\}\}\(w\)\\in\\\{0,1\\\}, determines which entries may cross application boundaries\. A schema validator and linter reject entries containing app names, package or resource identifiers, concrete widget labels, coordinates, task\-instance values, and other app\-bound content\. Eligibility does not imply that an entry will help the target; it excludes identifiable source\-specific information, while target rollout rewards subsequently determine utility\.

A frozen synthesizer constructs the app\-bound and transferable source states from audited trajectories\. Let𝒲src\\mathcal\{W\}\_\{\\mathrm\{src\}\}denote the set of workflow entrieswwsuch thatw∈Mtraw\\in M\_\{\\mathrm\{tr\}\}^\{a\}for some source applicationa∈𝒜srca\\in\\mathcal\{A\}\_\{\\mathrm\{src\}\}andEligibletr⁡\(w\)=1\\operatorname\{Eligible\}\_\{\\mathrm\{tr\}\}\(w\)=1\. These entries are grouped by functional category and consolidated into the source library

ℒsrc=Consolidate⁡\(𝒲src\)\.\\mathcal\{L\}\_\{\\mathrm\{src\}\}=\\operatorname\{Consolidate\}\\left\(\\mathcal\{W\}\_\{\\mathrm\{src\}\}\\right\)\.
For target taskqq, initialization retrieves bounded, eligibility\-constrained protocol\-permitted source workflow context,M0​\(q\)=Retrieve⁡\(ℒsrc,q\)M\_\{0\}\(q\)=\\operatorname\{Retrieve\}\(\\mathcal\{L\}\_\{\\mathrm\{src\}\},q\)\. Strict unseen\-app evaluation excludes all app\-bound source states\. If the target belongs to a functional category absent from the source pool, retrieval returns an empty prior rather than forcing unrelated guidance\.

The source library remains fixed during target adaptation\. Target interactions instead maintain the separate target\-grounded stateMttgtM\_\{t\}^\{\\mathrm\{tgt\}\}\. Rendering selects task\-relevant entries from the source workflow context and target\-grounded state while preserving their provenance\. This separation prevents target adaptation from overwriting reusable source knowledge while allowing target experience to refine or supplement the guidance used during execution\.

### 3\.3Joint Context and Policy Adaptation

Target interactions can update both the workflow state and the policy parameters\. At adaptation roundtt, the controller selects a taskqt∈𝒬adaptq\_\{t\}\\in\\mathcal\{Q\}^\{\\mathrm\{adapt\}\}and one or more already materialized context variants from the current population\. It then collects matched rollouts under controlled reset conditions:

Dt=\{\(τj,rj,κj,zj\)\}j=1Nt\.D\_\{t\}=\\left\\\{\(\\tau\_\{j\},r\_\{j\},\\kappa\_\{j\},z\_\{j\}\)\\right\\\}\_\{j=1\}^\{N\_\{t\}\}\.Here,κj\\kappa\_\{j\}identifies the context variant that generated trajectoryτj\\tau\_\{j\}, andzjz\_\{j\}records its reset identity\. Only context variants present before collectingDtD\_\{t\}can receive rating updates from their rewards\. The trajectories are also added to the policy bufferℬ\\mathcal\{B\}with their task and context identities\.

The two channels reuse the same rollout stream but operate at different frequencies\. Each matched batch updates the ratings of the evaluated context variants and may produce a validated child for subsequent evaluation\. The LoRA parameters are updated only whenℬ\\mathcal\{B\}contains valid task–context comparison groups\. The updates are therefore interaction\-coupled rather than jointly differentiable: the current context shapes the trajectories used for policy learning, while the current policy determines the successful and failed behaviors available for future context revisions\.

##### Reward\-guided context update\.

For the repeated seeded tasks used in our evaluation, the controller maintains a population of TrueSkill\-rated context variants\([9](https://arxiv.org/html/2608.11588#bib.bib16)\)\. At each round, it samples already materialized variants, evaluates them on matched tasks and resets seeds, and updates their ratings using the resulting task rewards\. A frozen reflector then contrasts successful and failed traces from the evaluated variants and proposes a typed workflow revision to a high\-rated parent\.

The resulting child enters the population only after passing schema, provenance, and lint checks\. Because the child is proposed after collecting the current round’s rollouts, it does not inherit their rewards\. Its utility is determined only when it is sampled and evaluated in subsequent matched rollouts\. At the end of adaptation, the highest\-rated validated workflow state is selected for deployment\.

##### Task–context\-matched policy update\.

The policy update learns online from trajectories generated by the current policy rather than from a fixed dataset\. Because the context condition changes the effective policy input, trajectories are partitioned into groups sharing both task and context:

G\(q,κ\)=\{j\|qj=q,κj=κ\}\.G\(q,\\kappa\)=\\left\\\{j\\;\\middle\|\\;q\_\{j\}=q,\\;\\kappa\_\{j\}=\\kappa\\right\\\}\.For a groupGGof sizenGn\_\{G\}, we compute

r¯G=1nG​∑j∈Grj,Aj=rj−r¯GsG,\\bar\{r\}\_\{G\}=\\frac\{1\}\{n\_\{G\}\}\\sum\_\{j\\in G\}r\_\{j\},\\qquad A\_\{j\}=\\frac\{r\_\{j\}\-\\bar\{r\}\_\{G\}\}\{s\_\{G\}\},wheresGs\_\{G\}is the normalization factor: it is set to one for mean\-centered advantages, or to the within\-group standard deviation plus a small constant for standardized advantages\. Singleton and constant\-reward groups provide no active policy gradient\.

For trajectoryτj\\tau\_\{j\}, we average log\-probabilities over its action\-generation units:

ℓj​\(θ\)=1\|τj\|​∑m∈τjlog⁡πθ​\(uj,m∣xj,m\),\\ell\_\{j\}\(\\theta\)=\\frac\{1\}\{\|\\tau\_\{j\}\|\}\\sum\_\{m\\in\\tau\_\{j\}\}\\log\\pi\_\{\\theta\}\\left\(u\_\{j,m\}\\mid x\_\{j,m\}\\right\),wherexj,mx\_\{j,m\}contains the task, observation, history, and rendered context available when action unituj,mu\_\{j,m\}is generated\. Letℬact⊆ℬ\\mathcal\{B\}\_\{\\mathrm\{act\}\}\\subseteq\\mathcal\{B\}contain trajectories belonging to nondegenerate groups\. The resulting online group\-relative objective\([19](https://arxiv.org/html/2608.11588#bib.bib12)\)is

ℒpolicy=−1\|ℬact\|∑j∈ℬactAjℓj\(θ\)\+βℛ\(θ;πanchor\),\\mathcal\{L\}\_\{\\mathrm\{policy\}\}=\-\\frac\{1\}\{\|\\mathcal\{B\}\_\{\\mathrm\{act\}\}\|\}\\sum\_\{j\\in\\mathcal\{B\}\_\{\\mathrm\{act\}\}\}A\_\{j\}\\ell\_\{j\}\(\\theta\)\+\\beta\\mathcal\{R\}\\left\(\\theta;\\pi\_\{\\mathrm\{anchor\}\}\\right\),whereℛ\\mathcal\{R\}denotes the frozen\-policy regularizer when anchoring is enabled\. The vision–language backbone remains frozen, and only the LoRA parameters are optimized\([11](https://arxiv.org/html/2608.11588#bib.bib11)\)\. Restricting comparisons toG⁡\(q,κ\)G\(q,\\kappa\)controls variation due to task difficulty and contextual guidance when computing relative advantages\. The policy bufferℬ\\mathcal\{B\}stores only trajectories collected since the most recent LoRA update\. The policy remains fixed while these trajectories are collected\. Once the update threshold is reached, at most one LoRA update is attempted, and the buffer is cleared, regardless of whether it contains an active comparison group\. No trajectory is reused after the policy changes\. Each trajectory retains the task and rendered\-context identity under which it was collected\.

Algorithm[1](https://arxiv.org/html/2608.11588#alg1)summarizes the complete schedule\. Each matched comparison evaluates only already materialized context variants; revisions proposed from its traces enter the population for subsequent evaluation\. LoRA is updated only when the policy buffer contains nondegenerate task–context groups\.

Algorithm 1CoAdapt\-GUI test\-time context–policy adaptation1:Source workflow library

ℒsrc\\mathcal\{L\}\_\{\\mathrm\{src\}\}, policy initialization

θ0\\theta\_\{0\}, adaptation tasks

𝒬adapt\\mathcal\{Q\}^\{\\mathrm\{adapt\}\}, frozen reflector, interaction budget

BB
2:Frozen workflow state

M⋆M^\{\\star\}and policy parameters

θ⋆\\theta^\{\\star\}
3:Retrieve the protocol\-permitted source workflow context

M0M\_\{0\}
4:Initialize target\-grounded state

Mtgt←∅M^\{\\mathrm\{tgt\}\}\\leftarrow\\varnothing
5:Initialize policy

θ←θ0\\theta\\leftarrow\\theta\_\{0\}and buffer

ℬ←∅\\mathcal\{B\}\\leftarrow\\varnothing
6:whileinteraction budget remainsdo

7:Select a task

q∈𝒬adaptq\\in\\mathcal\{Q\}^\{\\mathrm\{adapt\}\}
8:Select already materialized context variants for

qq
9:Collect matched rollouts

DDand record their task, context, and reset identities

10:Update the ratings of the evaluated variants using rewards in

DD
11:Propose and validate a child revision from traces in

DD
12:ifthe child passes all validation checksthen

13:Add the child to the population for subsequent evaluation

14:endif

15:Add the same trajectories in

DDto

ℬ\\mathcal\{B\}
16:ifLoRA adaptation is enabled and

ℬ\\mathcal\{B\}is readythen

17:Update LoRA from nondegenerate groups in

ℬ\\mathcal\{B\}, if any

18:Clear

ℬ\\mathcal\{B\}
19:endif

20:endwhile

21:

M⋆←M^\{\\star\}\\leftarrowhighest\-rated validated workflow state

22:

θ⋆←θ\\theta^\{\\star\}\\leftarrow\\theta
23:Freeze

\(M⋆,θ⋆\)\(M^\{\\star\},\\theta^\{\\star\}\)
24:return

\(M⋆,θ⋆\)\(M^\{\\star\},\\theta^\{\\star\}\)

### 3\.4Source Initialization and Frozen Evaluation

During source preparation, the frozen synthesizer constructs the app\-bound and transferable source states\. Eligible workflow entries are consolidated intoℒsrc\\mathcal\{L\}\_\{\\mathrm\{src\}\}\. Separately, a shared LoRA adapter is trained on source\-app trajectories while workflow context is held fixed\. The resulting context and policy initializations are independently usable: either may be deployed without enabling adaptation of the other\.

At test time, initialization follows the evaluation protocol\. Strict unseen\-app evaluation excludes all app\-bound source interaction knowledge, and a target from a novel functional category begins without a source workflow prior\. The policy is initialized from a source\-side checkpoint selected using source metadata\. Target trajectories and held\-out outcomes never influence source construction or checkpoint routing\.

Algorithm[1](https://arxiv.org/html/2608.11588#alg1)then uses only𝒬adapt\\mathcal\{Q\}^\{\\mathrm\{adapt\}\}\. The source library remains immutable, while target interactions update the separate target\-grounded workflow state and, when enabled, the LoRA parameters\. Once the interaction budget is exhausted, the selected workflow state and final policy adapter are frozen\. No task, trajectory, or reward from𝒬eval\\mathcal\{Q\}^\{\\mathrm\{eval\}\}may alter either state\.

## 4Experiments

We evaluate CoAdapt\-GUI in two unseen\-app settings\.\(1\) AndroidWorld\-Generalizationfollows the released setup and tests adaptation to new instances of task templates encountered during adaptation, enabling direct comparison with the reported Policy\-Only TTA baseline\([7](https://arxiv.org/html/2608.11588#bib.bib1)\)\.\(2\) AndroidWorld Plus, an experimental extension of AndroidWorld\([18](https://arxiv.org/html/2608.11588#bib.bib2)\), separates adaptation and evaluation by task template to test transfer to new task types within unseen apps\.

### 4\.1Experimental Setup

Each experiment setting separates source data, target adaptation tasks, and held\-out target evaluation tasks\. Source data is used to obtain the initial policy and reusable workflow context\. During target adaptation, the agent may update its workflow context, policy, or both, depending on the configuration\. All updates stop before evaluation; no held\-out task, trajectory, reward, or outcome is used for adaptation or checkpoint selection\. A*task template*defines a reusable task type, whereas a*task instance*supplies its concrete arguments\. Our primary metric is success rate \(SR\), defined as the percentage of held\-out evaluation episodes successfully completed according to the benchmark’s programmatic evaluator\.

##### Compared methods\.

We mainly compare five configurations in each setting\.The Base Policyuses the initial policy without workflow context or a target\-side update\.Static Context Transfersupplies source workflows as frozen context\.Policy\-Only TTAkeeps the workflow context fixed and updates only the policy adapter from target adaptation rollouts\.Context\-Only TTAkeeps the policy fixed and builds additional workflow context from target adaptation rollouts\.CoAdapt\-GUIalso updates a LoRA policy adapter while freezing the VLM backbone\. These configurations isolate source workflow transfer, target\-side context adaptation, policy adaptation, and their joint use\. Context\-Only TTA and CoAdapt\-GUI receive the same adaptation tasks and rollout budget, but are run independently and can therefore collect different policy\-dependent trajectories; their difference reflects the complete joint procedure, not a controlled estimate of the LoRA update alone\. Experiments were run on NVIDIA H200 GPUs with 141 GB of memory; one 20\-round target\-app adaptation run required approximately 9–10 GPU\-hours on average\.

### 4\.2New Task Instances in Unseen Apps

##### Setup\.

We follow the released unseen\-app setting of AndroidWorld\-Generalization\([7](https://arxiv.org/html/2608.11588#bib.bib1)\)\. Its source split contains 12 apps, 62 task templates, and 905 training instances\. All configurations start from the released step\-500 UI\-TARS\-7B checkpoint\([17](https://arxiv.org/html/2608.11588#bib.bib30)\), trained on this split\. The target split contains five disjoint apps, with eight adaptation instances per app \(40 total\) and 48 held\-out evaluation instances\. Adaptation and evaluation cover the same 16 templates but use instances generated with non\-overlapping seeds, thereby testing transfer to new instances of task types seen during adaptation\.

We use the released manifests throughout\. All adaptive methods use the same eight adaptation instances and nominal 50\-step schedule per target app, and all methods are evaluated on the same 48 held\-out instances\. The Base Policy and Policy\-Only TTA values are taken directly from AndroidWorld\-Generalization\([7](https://arxiv.org/html/2608.11588#bib.bib1)\)\.

Table 1:Setting 1—New Task Instances in Unseen Apps \(AndroidWorld\-Generalization\)\.Success rates are measured on 48 held\-out instances of task templates used during target adaptation\. Reported results are from AndroidWorld\-Generalization\([7](https://arxiv.org/html/2608.11588#bib.bib1)\); our results are mean±\\pmstandard deviation over five runs\.
##### Results\.

The reported Base Policy and Policy\-Only TTA achieve 27\.10% and 37\.50%, respectively\. Our CoAdapt\-GUI configuration performs best at45\.00%±1\.86\\mathbf\{45\.00\\%\\,\\pm\\,1\.86\}, 7\.5 points above the reported Policy\-Only TTA result\. Context\-Only TTA reaches35\.00%±1\.7435\.00\\%\\,\\pm\\,1\.74, while Static Context Transfer reaches28\.75%±2\.2828\.75\\%\\,\\pm\\,2\.28\. Under the same adaptation instances and rollout budget, CoAdapt\-GUI outperforms Context\-Only TTA by 10\.00 points, indicating that co\-adapting workflow context and the policy is more effective than adapting context alone in this setting\.

### 4\.3New Task Templates in Unseen Apps

##### Setup\.

To evaluate transfer to task templates not observed during adaptation, we construct AndroidWorld Plus by extending AndroidWorld\([18](https://arxiv.org/html/2608.11588#bib.bib2)\)with three apps from B\-MoCA\([13](https://arxiv.org/html/2608.11588#bib.bib3)\)and three from AndroidLab\([27](https://arxiv.org/html/2608.11588#bib.bib9)\)\. After executable\-task filtering, the benchmark contains 25 apps and 191 task templates\. We assign 12 apps with 96 templates to the source set and the remaining 13 apps with 95 templates to the disjoint target set\.

All AndroidWorld Plus configurations use Qwen3\-VL\-8B\-Instruct\([1](https://arxiv.org/html/2608.11588#bib.bib10)\)with a frozen backbone and start from a LoRA adapter trained only on the 12 source apps\. Checkpoint selection occurs before target adaptation without using target rollouts or rewards, and each matched comparison uses the same initialization\. Policy\-Only TTA updates only the LoRA adapter while keeping its initial source context fixed\. Supplementary Section 1 provides the filtering procedure and complete app\-level manifest\.

Within each target app, adaptation and evaluation use disjoint task templates\. Across the target apps, 60 templates yield a pool of 300 adaptation instances, while 35 held\-out templates yield 105 evaluation episodes using non\-overlapping seeds\. Each adaptive configuration runs for 20 rounds per app with up to two context variants per round\. Context\-Only TTA, Policy\-Only TTA, and CoAdapt\-GUI collect four rollouts per selected task–context condition \(≤160\\leq 160per app\)\. Context\-Only TTA uses its batches only for workflow adaptation, Policy\-Only TTA uses them only for LoRA adaptation, and CoAdapt\-GUI uses them for both\. Supplementary Section 3 provides the remaining adaptation details\. This setting therefore tests whether experience from some task types transfers to unseen task types within the same target apps\.

##### Source\-category coverage\.

Following Android Control\([14](https://arxiv.org/html/2608.11588#bib.bib4)\), we use Google Play categories as a coarse, externally defined boundary for source\-workflow retrieval\. Source workflows are eligible only when their app category matches that of the target app\. Under this protocol, six target apps areCategory\-Sharedand can retrieve source workflows, whereas seven areCategory\-Novel, for which retrieval returns no source workflow\. Static Context Transfer therefore supplies no workflow context for Category\-Novel Apps\. Context\-Only TTA and CoAdapt\-GUI instead initialize an empty target\-grounded workflow state, construct workflow entries from target adaptation rollouts and rewards, and refine them in subsequent rounds\. This breakdown assesses whether target\-side adaptation remains effective without category\-matched source experience\. Supplementary Section 1 provides the complete app allocation and implementation details\.

Table 2:Setting 2—New Task Templates in Unseen Apps \(AndroidWorld Plus\)\.Success rates are measured over 105 held\-out episodes whose task templates are disjoint from target adaptation\. Category\-Shared and Category\-Novel group episodes by whether the target app’s category is represented in the source pool\.
##### Results\.

Our CoAdapt\-GUI performs best, raising overall success from 38\.6% to 52\.9%, a gain of 14\.3 points\. The cumulative context path—Static Context Transfer followed by Context\-Only TTA—reaches 48\.1%, 9\.5 points above the Base Policy, whereas Policy\-Only TTA reaches 40\.0%, a gain of only 1\.4 points\. CoAdapt\-GUI is a further 4\.8 points above Context\-Only TTA\. This pattern is consistent with evolved workflow guidance producing more informative target experience for policy learning\.

On Category\-Shared Apps, CoAdapt\-GUI reaches 70\.4%, compared with 53\.7% for Policy\-Only TTA and 63\.9% for Context\-Only TTA\. Category\-Novel Apps provide a built\-in control for source transfer\. Because retrieval is empty in this group, Static Context Transfer exactly matches the Base Policy at 29\.4%\. Policy\-Only TTA falls to 25\.5%, whereas Context\-Only TTA and CoAdapt\-GUI improve success to 31\.4% and 34\.3%\.

Separately, a representative Chrome adaptation trace illustrates how context evolution can affect the policy\-learning signal\. All evaluated variants received zero task reward during the first 11 rounds\. In round 12, an evolved variant reached a mean task reward of 0\.25 over four rollouts, while the root context remained at zero\. Context evolution thus exposed a task\-success signal that was not observed under the original workflow guidance\.

## 5Limitations

##### Evaluation scope and leakage control\.

Target\-side adaptation can overestimate generalization through information leakage or evaluation on overly similar target tasks\. We prevent leakage by using disjoint source and target app pools, restricting all updates and model selection to the adaptation split, and freezing both adapted states before held\-out evaluation\. We further evaluate two levels of task separation: AndroidWorld\-Generalization uses disjoint instances generated from the same templates, whereas AndroidWorld Plus uses disjoint adaptation and evaluation templates within every target app\. Fixed manifests, repeated runs, and a common evaluation harness are used across matched configurations\.

##### Transfer and context reliability\.

Source workflows may contain interface\-specific assumptions or errors introduced during reflection, causing negative transfer to a new application\. CoAdapt\-GUI addresses this risk in two stages\. Before transfer, it separates app\-bound screen\-transition state from reusable workflow knowledge and applies eligibility, schema, provenance, and lint checks before a source workflow enters the transferable library\. During target adaptation, a proposed revision first enters the candidate population and is evaluated in subsequent matched rollouts; task rewards update its rating and determine whether it is retained in the final workflow state\.

##### Sparse feedback and adaptation stability\.

A limited target\-interaction budget can produce noisy or uniform rewards, making it difficult to distinguish useful context revisions and assign policy credit\. To reduce this ambiguity, we evaluate context variants on matched tasks and reset seeds, and compute policy advantages only among rollouts sharing the same task and context condition\. Groups without reward variation are excluded from policy updates rather than assigned artificial credit\. We also clear the on\-policy buffer after each update attempt and restrict training to a LoRA adapter on a frozen backbone, reducing stale\-policy updates and limiting parameter drift under sparse supervision\.

##### Deployment safety and continual use\.

Exploration on a new application may expose private information, trigger irreversible actions, or accumulate unstable updates over time\. We therefore conduct adaptation in resettable emulators, restrict interaction to designated adaptation tasks and a fixed budget, and freeze the selected context and LoRA checkpoint before held\-out use\. App\-bound workflow state remains local to its application, while only validated transferable knowledge may cross application boundaries\. Updating only a lightweight LoRA adapter on a frozen backbone further limits parameter drift and the cost of repeated adaptation\.

## 6Conclusion

We introduced CoAdapt\-GUI, a test\-time adaptation framework that updates workflow context and policy on unseen applications using the agent’s own target rollouts and task rewards\. Its transfer\-constrained context retains reusable workflow knowledge while excluding app\-bound source state, and its policy update assigns credit only within matched task–context conditions\. CoAdapt\-GUI reaches 45\.0% on AndroidWorld\-Generalization, compared with 37\.5% for the reported Policy\-Only TTA baseline, and improves AndroidWorld Plus from 38\.6% to 52\.9%\. Context adaptation improves performance without policy updates in both settings, while CoAdapt\-GUI achieves the strongest overall results, supporting context and policy adaptation as distinct but complementary channels for novel\-app generalization\.

## References

- Baiet al\.\(2025\)S\. Bai, Y\. Cai, R\. Chen, K\. Chen, X\. Chen, Z\. Cheng, L\. Deng, W\. Ding, C\. Gao, C\. Ge, W\. Ge, Z\. Guo, Q\. Huang, J\. Huang, F\. Huang, B\. Hui, S\. Jiang, Z\. Li, M\. Li, M\. Li, K\. Li, Z\. Lin, J\. Lin, X\. Liu, J\. Liu, C\. Liu, Y\. Liu, D\. Liu, S\. Liu, D\. Lu, R\. Luo, C\. Lv, R\. Men, L\. Meng, X\. Ren, X\. Ren, S\. Song, Y\. Sun, J\. Tang, J\. Tu, J\. Wan, P\. Wang, P\. Wang, Q\. Wang, Y\. Wang, T\. Xie, Y\. Xu, H\. Xu, J\. Xu, Z\. Yang, M\. Yang, J\. Yang, A\. Yang, B\. Yu, F\. Zhang, H\. Zhang, X\. Zhang, B\. Zheng, H\. Zhong, J\. Zhou, F\. Zhou, J\. Zhou, Y\. Zhu, and K\. ZhuQwen3\-vl technical report\.External Links:2511\.21631,[Link](https://arxiv.org/abs/2511.21631)Cited by:[§4\.3](https://arxiv.org/html/2608.11588#S4.SS3.SSS0.Px1.p2.1)\.
- Chenet al\.\(2026\)A\. Chen, Z\. Liu, J\. Zhang, A\. Prabhakar, Z\. Liu, S\. Heinecke, S\. Savarese, V\. Zhong, and C\. XiongTest\-time adaptation for LLM agents via environment interaction\.InThe Fourteenth International Conference on Learning Representations,External Links:[Link](https://openreview.net/forum?id=OH4PE0TDo0)Cited by:[§2\.2](https://arxiv.org/html/2608.11588#S2.SS2.p1.1)\.
- Chenget al\.\(2026\)K\. Cheng, Z\. Li, Z\. Ma, N\. Chen, J\. Cao, Q\. Sun, Z\. Ding, F\. Xu, H\. Yan, J\. Chen, A\. T\. Luu, J\. Zhang, L\. Lu, and D\. LinOpenMobile: building open mobile agents with task and trajectory synthesis\.External Links:2604\.15093,[Link](https://arxiv.org/abs/2604.15093)Cited by:[§1](https://arxiv.org/html/2608.11588#S1.p1.1),[§2\.1](https://arxiv.org/html/2608.11588#S2.SS1.p1.1)\.
- Chenget al\.\(2024\)K\. Cheng, Q\. Sun, Y\. Chu, F\. Xu, Y\. Li, J\. Zhang, and Z\. WuSeeClick: harnessing gui grounding for advanced visual gui agents\.InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics \(ACL\),External Links:[Link](https://arxiv.org/abs/2401.10935)Cited by:[§1](https://arxiv.org/html/2608.11588#S1.p1.1),[§2\.1](https://arxiv.org/html/2608.11588#S2.SS1.p1.1)\.
- Denget al\.\(2023\)X\. Deng, Y\. Gu, B\. Zheng, S\. Chen, S\. Stevens, B\. Wang, H\. Sun, and Y\. SuMind2Web: towards a generalist agent for the web\.InAdvances in Neural Information Processing Systems \(NeurIPS\), Datasets and Benchmarks Track,External Links:[Link](https://arxiv.org/abs/2306.06070)Cited by:[§2\.1](https://arxiv.org/html/2608.11588#S2.SS1.p2.1)\.
- Gouet al\.\(2024\)B\. Gou, R\. Wang, B\. Zheng, Y\. Xie, C\. Cheng, Y\. Shu, H\. Sun, and Y\. SuNavigating the digital world as humans do: universal visual grounding for GUI agents\.arXiv preprint arXiv:2410\.05243\.External Links:[Link](https://arxiv.org/abs/2410.05243)Cited by:[§2\.1](https://arxiv.org/html/2608.11588#S2.SS1.p1.1)\.
- Guet al\.\(2026\)L\. Gu, Z\. Jiang, Z\. Chi, H\. Liu, Z\. Wang, Y\. Yu, G\. Berseth, and Y\. WangGeneralization in online reinforcement learning for mobile agents\.arXiv preprint arXiv:2603\.07432\.External Links:[Link](https://arxiv.org/abs/2603.07432)Cited by:[§B\.1](https://arxiv.org/html/2608.11588#A2.SS1.p1.1),[§B\.3](https://arxiv.org/html/2608.11588#A2.SS3.p2.1),[§1](https://arxiv.org/html/2608.11588#S1.p2.1),[§1](https://arxiv.org/html/2608.11588#S1.p4.1),[§1](https://arxiv.org/html/2608.11588#S1.p6.1),[§2\.1](https://arxiv.org/html/2608.11588#S2.SS1.p2.1),[§4\.2](https://arxiv.org/html/2608.11588#S4.SS2.SSS0.Px1.p1.1),[§4\.2](https://arxiv.org/html/2608.11588#S4.SS2.SSS0.Px1.p2.1),[Table 1](https://arxiv.org/html/2608.11588#S4.T1),[Table 1](https://arxiv.org/html/2608.11588#S4.T1.1.2.1),[Table 1](https://arxiv.org/html/2608.11588#S4.T1.1.4.1),[§4](https://arxiv.org/html/2608.11588#S4.p1.1)\.
- Guoet al\.\(2026\)L\. Guo, W\. Liu, Y\. W\. Heng, T\. \(\. Chen, and Y\. WangAgent\-sama: state\-aware mobile assistant\.InProceedings of the AAAI Conference on Artificial Intelligence,External Links:[Link](https://arxiv.org/abs/2505.23596)Cited by:[§2\.2](https://arxiv.org/html/2608.11588#S2.SS2.p2.1),[§3\.2](https://arxiv.org/html/2608.11588#S3.SS2.p3.1)\.
- Herbrichet al\.\(2006\)R\. Herbrich, T\. Minka, and T\. GraepelTrueSkill™: a bayesian skill rating system\.InAdvances in Neural Information Processing Systems,B\. Schölkopf, J\. Platt, and T\. Hoffman \(Eds\.\),Vol\.19,pp\.\.External Links:[Link](https://proceedings.neurips.cc/paper_files/paper/2006/file/f44ee263952e65b3610b8ba51229d1f9-Paper.pdf)Cited by:[§3\.3](https://arxiv.org/html/2608.11588#S3.SS3.SSS0.Px1.p1.1)\.
- Honget al\.\(2024\)W\. Hong, W\. Wang, Q\. Lv, J\. Xu, W\. Yu, J\. Ji, Y\. Wang, Z\. Wang, Y\. Dong, M\. Ding, and J\. TangCogAgent: a visual language model for gui agents\.InProceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition \(CVPR\),pp\. 14281–14290\.Cited by:[§1](https://arxiv.org/html/2608.11588#S1.p1.1),[§2\.1](https://arxiv.org/html/2608.11588#S2.SS1.p1.1)\.
- Huet al\.\(2021\)E\. J\. Hu, Y\. Shen, P\. Wallis, Z\. Allen\-Zhu, Y\. Li, S\. Wang, L\. Wang, and W\. ChenLoRA: low\-rank adaptation of large language models\.arXiv preprint arXiv:2106\.09685\.External Links:[Link](https://arxiv.org/abs/2106.09685)Cited by:[§3\.3](https://arxiv.org/html/2608.11588#S3.SS3.SSS0.Px2.p2.3)\.
- Konget al\.\(2026\)Q\. Kong, X\. Zhang, Z\. Yang, N\. Gao, C\. Liu, P\. Tong, C\. Cai, H\. Zhou, J\. Zhang, L\. Chen, Z\. Liu, S\. Hoi, and Y\. WangMobileWorld: benchmarking autonomous mobile agents in agent\-user interactive and MCP\-augmented environments\.InProceedings of the 64th Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\),M\. Liakata, V\. P\. Moreira, J\. Zhang, and D\. Jurgens \(Eds\.\),San Diego, California, United States,pp\. 6142–6167\.External Links:[Link](https://aclanthology.org/2026.acl-long.278/),[Document](https://dx.doi.org/10.18653/v1/2026.acl-long.278),ISBN 979\-8\-89176\-390\-6Cited by:[§1](https://arxiv.org/html/2608.11588#S1.p1.1),[§2\.1](https://arxiv.org/html/2608.11588#S2.SS1.p2.1)\.
- Leeet al\.\(2026\)J\. Lee, T\. Min, M\. An, D\. Hahm, H\. Lee, C\. Kim, and K\. LeeBenchmarking mobile device control agents across diverse configurations\.InProceedings of The 4th Conference on Lifelong Learning Agents,S\. Chandar, R\. Pascanu, E\. Eaton, B\. Liu, R\. Mahmood, and A\. Rannen\-Triki \(Eds\.\),Proceedings of Machine Learning Research, Vol\.330,pp\. 261–306\.External Links:[Link](https://proceedings.mlr.press/v330/lee26a.html)Cited by:[§A\.1](https://arxiv.org/html/2608.11588#A1.SS1.p1.1),[§4\.3](https://arxiv.org/html/2608.11588#S4.SS3.SSS0.Px1.p1.1)\.
- Liet al\.\(2024\)W\. Li, W\. Bishop, A\. Li, C\. Rawles, F\. Campbell\-Ajala, D\. Tyamagundlu, and O\. RivaOn the effects of data scale on ui control agents\.arXiv preprint arXiv:2406\.03679\.External Links:[Link](https://arxiv.org/abs/2406.03679)Cited by:[§A\.1](https://arxiv.org/html/2608.11588#A1.SS1.p1.1),[§2\.1](https://arxiv.org/html/2608.11588#S2.SS1.p2.1),[§4\.3](https://arxiv.org/html/2608.11588#S4.SS3.SSS0.Px2.p1.1)\.
- Liuet al\.\(2025a\)G\. Liu, P\. Zhao, L\. Liu, Z\. Chen, Y\. Chai, S\. Ren, H\. Wang, S\. He, and W\. MengLearnAct: few\-shot mobile GUI agent with a unified demonstration benchmark\.arXiv preprint arXiv:2504\.13805\.External Links:[Link](https://arxiv.org/abs/2504.13805)Cited by:[§2\.2](https://arxiv.org/html/2608.11588#S2.SS2.p1.1)\.
- Liuet al\.\(2025b\)Z\. Liu, C\. Zhang, X\. Zhao, Y\. Feng, B\. Bai, D\. Feng, E\. Feng, Y\. Xia, and H\. ChenBeyond training: enabling self\-evolution of agents with MOBIMEM\.arXiv preprint arXiv:2512\.15784\.External Links:[Link](https://arxiv.org/abs/2512.15784)Cited by:[§2\.2](https://arxiv.org/html/2608.11588#S2.SS2.p2.1)\.
- Qinet al\.\(2025\)Y\. Qin, Y\. Ye, J\. Fang, H\. Wang, S\. Liang, S\. Tian, J\. Zhang, J\. Li, Y\. Li, S\. Huang, W\. Zhong, K\. Li, J\. Yang, Y\. Miao, W\. Lin, L\. Liu, X\. Jiang, Q\. Ma, J\. Li, X\. Xiao, K\. Cai, C\. Li, Y\. Zheng, C\. Jin, C\. Li, X\. Zhou, M\. Wang, H\. Chen, Z\. Li, H\. Yang, H\. Liu, F\. Lin, T\. Peng, X\. Liu, and G\. ShiUI\-tars: pioneering automated gui interaction with native agents\.External Links:2501\.12326,[Link](https://arxiv.org/abs/2501.12326)Cited by:[§B\.1](https://arxiv.org/html/2608.11588#A2.SS1.p1.1),[§4\.2](https://arxiv.org/html/2608.11588#S4.SS2.SSS0.Px1.p1.1)\.
- Rawleset al\.\(2025\)C\. Rawles, S\. Clinckemaillie, Y\. Chang, J\. Waltz, G\. Lau, M\. Fair, A\. Li, W\. Bishop, W\. Li, F\. Campbell\-Ajala, D\. Toyama, R\. Berry, D\. Tyamagundlu, T\. Lillicrap, and O\. RivaAndroidWorld: a dynamic benchmarking environment for autonomous agents\.External Links:2405\.14573,[Link](https://arxiv.org/abs/2405.14573)Cited by:[§A\.1](https://arxiv.org/html/2608.11588#A1.SS1.p1.1),[§1](https://arxiv.org/html/2608.11588#S1.p1.1),[§2\.1](https://arxiv.org/html/2608.11588#S2.SS1.p2.1),[§4\.3](https://arxiv.org/html/2608.11588#S4.SS3.SSS0.Px1.p1.1),[§4](https://arxiv.org/html/2608.11588#S4.p1.1)\.
- Shaoet al\.\(2024\)Z\. Shao, P\. Wang, Q\. Zhu, R\. Xu, J\. Song, X\. Bi, H\. Zhang, M\. Zhang, Y\.K\. Li, Y\. Wu, and D\. GuoDeepSeekMath: pushing the limits of mathematical reasoning in open language models\.arXiv preprint arXiv:2402\.03300\.External Links:[Link](https://arxiv.org/abs/2402.03300)Cited by:[§1](https://arxiv.org/html/2608.11588#S1.p5.1),[§3\.3](https://arxiv.org/html/2608.11588#S3.SS3.SSS0.Px2.p2.2)\.
- Sunet al\.\(2020\)Y\. Sun, X\. Wang, Z\. Liu, J\. Miller, A\. A\. Efros, and M\. HardtTest\-time training with self\-supervision for generalization under distribution shifts\.InInternational Conference on Machine Learning \(ICML\),External Links:[Link](https://arxiv.org/abs/1909.13231)Cited by:[§2\.2](https://arxiv.org/html/2608.11588#S2.SS2.p1.1)\.
- Vermaet al\.\(2024\)G\. Verma, R\. Kaur, N\. Srishankar, Z\. Zeng, T\. Balch, and M\. VelosoAdaptAgent: adapting multimodal web agents with few\-shot learning from human demonstrations\.arXiv preprint arXiv:2411\.13451\.External Links:[Link](https://arxiv.org/abs/2411.13451)Cited by:[§2\.2](https://arxiv.org/html/2608.11588#S2.SS2.p1.1)\.
- Wanget al\.\(2021\)D\. Wang, E\. Shelhamer, S\. Liu, B\. Olshausen, and T\. DarrellTent: fully test\-time adaptation by entropy minimization\.InInternational Conference on Learning Representations \(ICLR\),External Links:[Link](https://arxiv.org/abs/2006.10726)Cited by:[§2\.2](https://arxiv.org/html/2608.11588#S2.SS2.p1.1)\.
- Wanget al\.\(2025\)Z\. Wang, H\. Xu, J\. Wang, X\. Zhang, M\. Yan, J\. Zhang, F\. Huang, and H\. JiMobile\-agent\-e: self\-evolving mobile assistant for complex tasks\.arXiv preprint arXiv:2501\.11733\.External Links:[Link](https://arxiv.org/abs/2501.11733)Cited by:[§2\.2](https://arxiv.org/html/2608.11588#S2.SS2.p2.1)\.
- Wanget al\.\(2024\)Z\. Z\. Wang, J\. Mao, D\. Fried, and G\. NeubigAgent workflow memory\.arXiv preprint arXiv:2409\.07429\.External Links:[Link](https://arxiv.org/abs/2409.07429)Cited by:[§2\.2](https://arxiv.org/html/2608.11588#S2.SS2.p2.1)\.
- Xiaoet al\.\(2026\)H\. Xiao, G\. Wang, H\. Wang, S\. Liu, Y\. Chai, Y\. Pan, Y\. Zhou, X\. Chen, Y\. Wen, and H\. LiUI\-mem: self\-evolving experience memory for online reinforcement learning in mobile gui agents\.External Links:2602\.05832,[Link](https://arxiv.org/abs/2602.05832)Cited by:[§1](https://arxiv.org/html/2608.11588#S1.p4.1),[§2\.1](https://arxiv.org/html/2608.11588#S2.SS1.p1.1),[§2\.2](https://arxiv.org/html/2608.11588#S2.SS2.p2.1)\.
- Xuet al\.\(2025\)Y\. Xu, X\. Liu, X\. Liu, J\. Fu, H\. Zhang, B\. Jing, S\. Zhang, Y\. Wang, W\. Zhao, and Y\. DongMobileRL: online agentic reinforcement learning for mobile gui agents\.External Links:2509\.18119,[Link](https://arxiv.org/abs/2509.18119)Cited by:[§1](https://arxiv.org/html/2608.11588#S1.p1.1),[§2\.1](https://arxiv.org/html/2608.11588#S2.SS1.p1.1)\.
- Xuet al\.\(2024\)Y\. Xu, X\. Liu, X\. Sun, S\. Cheng, H\. Yu, H\. Lai, S\. Zhang, D\. Zhang, J\. Tang, and Y\. DongAndroidLab: training and systematic benchmarking of android autonomous agents\.arXiv preprint arXiv:2410\.24024\.External Links:[Link](https://arxiv.org/abs/2410.24024)Cited by:[§A\.1](https://arxiv.org/html/2608.11588#A1.SS1.p1.1),[§1](https://arxiv.org/html/2608.11588#S1.p1.1),[§2\.1](https://arxiv.org/html/2608.11588#S2.SS1.p2.1),[§4\.3](https://arxiv.org/html/2608.11588#S4.SS3.SSS0.Px1.p1.1)\.
- Zhanget al\.\(2025\)C\. Zhang, Z\. Yang, J\. Liu, Y\. Li, Y\. Han, X\. Chen, Z\. Huang, B\. Fu, and G\. YuAppAgent: multimodal agents as smartphone users\.InProceedings of the 2025 CHI Conference on Human Factors in Computing Systems,CHI ’25,New York, NY, USA\.External Links:ISBN 9798400713941,[Link](https://doi.org/10.1145/3706598.3713600),[Document](https://dx.doi.org/10.1145/3706598.3713600)Cited by:[§2\.2](https://arxiv.org/html/2608.11588#S2.SS2.p2.1)\.
- Zhanget al\.\(2026\)L\. Zhang, R\. Chen, and B\. C\. StadieEvolutionary system prompt learning for reinforcement learning in llms\.arXiv preprint arXiv:2602\.14697\.External Links:[Link](https://arxiv.org/abs/2602.14697)Cited by:[§2\.2](https://arxiv.org/html/2608.11588#S2.SS2.p3.1)\.
- Zuoet al\.\(2025\)Y\. Zuo, K\. Zhang, L\. Sheng, S\. Qu, G\. Cui, X\. Zhu, H\. Li, Y\. Zhang, X\. Long, E\. Hua, B\. Qi, Y\. Sun, Z\. Ma, L\. Yuan, N\. Ding, and B\. ZhouTTRL: test\-time reinforcement learning\.arXiv preprint arXiv:2504\.16084\.External Links:[Link](https://arxiv.org/abs/2504.16084)Cited by:[§2\.2](https://arxiv.org/html/2608.11588#S2.SS2.p1.1)\.
- Zweigeret al\.\(2025\)A\. Zweiger, J\. Pari, H\. Guo, E\. Akyürek, Y\. Kim, and P\. AgrawalSelf\-adapting language models\.arXiv preprint arXiv:2506\.10943\.External Links:[Link](https://arxiv.org/abs/2506.10943)Cited by:[§2\.2](https://arxiv.org/html/2608.11588#S2.SS2.p1.1)\.

Appendix / Supplementary

Appendix overview\.This appendix reports the complete data allocation, implementation details, workflow\-context examples, additional analyses, prompt templates, and validation contracts for CoAdapt\-GUI\. Section numbering is continuous within the appendix and cross\-references are resolved in the main document\.

## Appendix AAndroidWorld Plus Construction and Data Allocation

### A\.1Benchmark construction and executable filtering

AndroidWorld Plus is an experimental extension of AndroidWorld\([18](https://arxiv.org/html/2608.11588#bib.bib2)\)\. We retain the 19 AndroidWorld apps with app\-attributable executable tasks and add six apps with their task suites: Calculator, Snapseed, and Wikipedia from B\-MoCA\([13](https://arxiv.org/html/2608.11588#bib.bib3)\), and Bluecoins, Maps\.me, and Pi Music from AndroidLab\([27](https://arxiv.org/html/2608.11588#bib.bib9)\)\. This produces 25 apps spanning 12 Google Play Store categories\. We use the published Play Store category as an external functional taxonomy, following Android Control\([14](https://arxiv.org/html/2608.11588#bib.bib4)\), rather than defining categories from task outcomes\.

The merged metadata contains 194 task rows\. Two generic or composite tasks,OpenAppandSaveCopyOfReceipt, cannot be attributed to one app and are excluded from the app\-level split, leaving 192 app\-attributable templates\. We then validate every template against the executable task registry\.WikipediaDecreaseTextSize50is defined in the upstream task file but is not registered with the execution harness and therefore cannot be instantiated\. We remove this template before freezing the manifests, yielding 191 executable task templates\. No filtering decision uses an agent rollout, reward, or evaluation outcome\.

### A\.2Source and target app pools

The source and target app pools are disjoint\. The source pool contains 12 apps and 96 templates \(Table[3](https://arxiv.org/html/2608.11588#A1.T3)\)\. Five task seeds per template,\{30,31,32,33,34\}\\\{30,31,32,33,34\\\}, provide 480 source episodes for source\-side policy training and workflow construction\.

Source appCategoryTemplatesSource appCategoryTemplatesmarkorProductivity14tasks\_orgProductivity6joplinProductivity4calculatorTools19clockTools3filesTools2bluecoinsFinance15pi\_musicMusic & Audio12audio\_recorderMusic & Audio2snapseedPhotography11simple\_sms\_messengerCommunication6contactsCommunication2Total96Table 3:Complete AndroidWorld Plus source\-app allocation\. All source templates are excluded from the target pool\.The target pool contains the remaining 13 apps and 95 templates\. For the category\-coverage analysis, a target app’s group depends only on whether its category is represented in the source pool\. Six target apps satisfy this condition and form theCategory\-Shared Appsgroup\. The other seven belong to categories absent from the source pool and form theCategory\-Novel Appsgroup\. Table[4](https://arxiv.org/html/2608.11588#A1.T4)gives the complete target allocation\.

GroupTarget appCategoryTemplatesEpisodesAdapt\.Eval\.Adapt\. poolEval\.Category\-Sharedsimple\_calendar\_proProductivity1165518Category\-Sharedsystem\_settingsTools964518Category\-Sharedpro\_expenseFinance63309Category\-Sharedretro\_musicMusic & Audio31153Category\-SharedcameraPhotography1153Category\-SharedchromeCommunication21103Category\-Shared subtotal321816054Category\-Novelmaps\_meMaps & Navigation964518Category\-NovelosmandMaps & Navigation21103Category\-NovelbroccoliFood & Drink854015Category\-NovelopentracksHealth & Fitness42206Category\-NovelwikipediaBooks & Reference32156Category\-NovelvlcVideo Players & Editors1153Category\-Novelsimple\_draw\_proArt & Design1050Category\-Novel subtotal281714051Target total6035300105Table 4:Complete AndroidWorld Plus target\-app allocation\. The adaptation pool uses five seeds per adaptation template; frozen evaluation uses three disjoint seeds per evaluation template\.simple\_draw\_prohas one executable template and is used only for adaptation, so the held\-out panel covers 12 of the 13 target apps\.
### A\.3Template and seed separation

Within each target app, we sort the executable template identifiers and create disjoint adaptation and evaluation sets\. For an app with at least three templates, the first⌈0\.6​n⌉\\lceil 0\.6n\\rceiltemplates are assigned to adaptation and the remainder to evaluation\. Two\-template apps use a one–one split; a single\-template app contributes only to adaptation\. This deterministic rule produces 60 adaptation templates and 35 evaluation templates, with no template overlap in any target app\. The split was frozen before target rollout collection and does not use task rewards, policy predictions, or evaluation outcomes\.

Each adaptation template is instantiated with seeds\{30,31,32,33,34\}\\\{30,31,32,33,34\\\}, defining a 300\-instance sampling pool\. Each evaluation template is instantiated with the disjoint seeds\{40,41,42\}\\\{40,41,42\\\}, producing the frozen 105\-episode panel used for all reported AndroidWorld Plus results\. The 300 adaptation instances specify the available sampling pool rather than the number of target rollout calls: CoAdapt\-GUI samples from this pool under the fixed interaction schedule described in Appendix[C](https://arxiv.org/html/2608.11588#A3)\.

### A\.4Complete source and target template manifests

Tables[5](https://arxiv.org/html/2608.11588#A1.T5)and[6](https://arxiv.org/html/2608.11588#A1.T6)list all 191 executable templates in the frozen AndroidWorld Plus manifest\. Source templates are used only for source\-side policy training and workflow construction\. Target templates are partitioned into adaptation and held\-out evaluation sets within each target app\. Identifiers match the execution harness exactly\.

Table 5:Complete AndroidWorld Plus source\-pool template manifestSource appCategoryCountExecutable source templatesmarkorProductivity14∙\\bulletMarkorAddNoteHeader∙\\bulletMarkorChangeNoteContent∙\\bulletMarkorCreateFolder∙\\bulletMarkorCreateNote∙\\bulletMarkorCreateNoteAndSms∙\\bulletMarkorCreateNoteFromClipboard∙\\bulletMarkorDeleteAllNotes∙\\bulletMarkorDeleteNewestNote∙\\bulletMarkorDeleteNote∙\\bulletMarkorEditNote∙\\bulletMarkorMergeNotes∙\\bulletMarkorMoveNote∙\\bulletMarkorTranscribeReceipt∙\\bulletMarkorTranscribeVideotasks\_orgProductivity6∙\\bulletTasksCompletedTasksForDate∙\\bulletTasksDueNextWeek∙\\bulletTasksDueOnDate∙\\bulletTasksHighPriorityTasks∙\\bulletTasksHighPriorityTasksDueOnDate∙\\bulletTasksIncompleteTasksOnDatejoplinProductivity4∙\\bulletNotesIsTodo∙\\bulletNotesMeetingAttendeeCount∙\\bulletNotesRecipeIngredientCount∙\\bulletNotesTodoItemCountcalculatorTools19∙\\bulletCalculatorConvert45DegreesToRadians∙\\bulletCalculatorGeometricMean∙\\bulletCalculatorHarmonicMean∙\\bulletCalculatorInput1∙\\bulletCalculatorInput10Choose2∙\\bulletCalculatorInput17Times23∙\\bulletCalculatorInput1Plus1∙\\bulletCalculatorInput2Plus24Div3∙\\bulletCalculatorInput3Times5∙\\bulletCalculatorInput5Choose2∙\\bulletCalculatorInputCos180∙\\bulletCalculatorInputCos60∙\\bulletCalculatorInputFactorial6∙\\bulletCalculatorInputLn1234∙\\bulletCalculatorInputPercent50Of28∙\\bulletCalculatorInputSqrt25∙\\bulletCalculatorOpen∙\\bulletCalculatorSumFirst5Fibonacci∙\\bulletCalculatorSumFirst5PrimesclockTools3∙\\bulletClockStopWatchPausedVerify∙\\bulletClockStopWatchRunning∙\\bulletClockTimerEntryfilesTools2∙\\bulletFilesDeleteFile∙\\bulletFilesMoveFilebluecoinsFinance15∙\\bulletBluecoinsAddExpense∙\\bulletBluecoinsAddExpenseOnDate∙\\bulletBluecoinsAddExpenseOnDateWithLabel∙\\bulletBluecoinsAddIncomeOnDateWithNote∙\\bulletBluecoinsAddIncomeWithLabel∙\\bulletBluecoinsEditExpenseAmount∙\\bulletBluecoinsEditExpenseDateAmountNote∙\\bulletBluecoinsEditIncomeDateAndAmount∙\\bulletBluecoinsEditTransactionType∙\\bulletBluecoinsEditTransactionTypeAmountNote∙\\bulletBluecoinsQueryCategorySpending∙\\bulletBluecoinsQuerySpendingCategory∙\\bulletBluecoinsQuerySpendingOnDate∙\\bulletBluecoinsQueryTotalSpendingOnDate∙\\bulletBluecoinsQueryTransactionCountpi\_musicMusic & Audio12∙\\bulletPiMusicCreatePlaylist∙\\bulletPiMusicPauseAndSeek∙\\bulletPiMusicPlayFromPlaylist∙\\bulletPiMusicPlaySongByTitleArtist∙\\bulletPiMusicQueryArtistSongCount∙\\bulletPiMusicQueryArtistTotalDuration∙\\bulletPiMusicQueryLongestSongDuration∙\\bulletPiMusicQuerySongAlbum∙\\bulletPiMusicQuerySortedSongsByTitle∙\\bulletPiMusicQueryTotalSongs∙\\bulletPiMusicSortByDurationAscending∙\\bulletPiMusicSortByDurationDescendingaudio\_recorderMusic & Audio2∙\\bulletAudioRecorderRecordAudio∙\\bulletAudioRecorderRecordAudioWithFileNamesnapseedPhotography11∙\\bulletSnapseedTask1∙\\bulletSnapseedTask10∙\\bulletSnapseedTask11∙\\bulletSnapseedTask2∙\\bulletSnapseedTask3∙\\bulletSnapseedTask4∙\\bulletSnapseedTask5∙\\bulletSnapseedTask6∙\\bulletSnapseedTask7∙\\bulletSnapseedTask8∙\\bulletSnapseedTask9simple\_sms\_messengerCommunication6∙\\bulletSimpleSmsReply∙\\bulletSimpleSmsReplyMostRecent∙\\bulletSimpleSmsResend∙\\bulletSimpleSmsSend∙\\bulletSimpleSmsSendClipboardContent∙\\bulletSimpleSmsSendReceivedAddresscontactsCommunication2∙\\bulletContactsAddContact∙\\bulletContactsNewContactDraftTable 6:Complete AndroidWorld Plus target adaptation/evaluation manifestAdaptation templatesHeld\-out evaluation templatessimple\_calendar\_proCategory\-Shared; Productivity11 templates∙\\bulletSimpleCalendarAddOneEvent∙\\bulletSimpleCalendarAddOneEventInTwoWeeks∙\\bulletSimpleCalendarAddOneEventRelativeDay∙\\bulletSimpleCalendarAddOneEventTomorrow∙\\bulletSimpleCalendarAddRepeatingEvent∙\\bulletSimpleCalendarAnyEventsOnDate∙\\bulletSimpleCalendarDeleteEvents∙\\bulletSimpleCalendarDeleteEventsOnRelativeDay∙\\bulletSimpleCalendarDeleteOneEvent∙\\bulletSimpleCalendarEventOnDateAtTime∙\\bulletSimpleCalendarEventsInNextWeek6 templates∙\\bulletSimpleCalendarEventsInTimeRange∙\\bulletSimpleCalendarEventsOnDate∙\\bulletSimpleCalendarFirstEventAfterStartTime∙\\bulletSimpleCalendarLocationOfEvent∙\\bulletSimpleCalendarNextEvent∙\\bulletSimpleCalendarNextMeetingWithPersonsystem\_settingsCategory\-Shared; Tools9 templates∙\\bulletSystemBluetoothTurnOff∙\\bulletSystemBluetoothTurnOffVerify∙\\bulletSystemBluetoothTurnOn∙\\bulletSystemBluetoothTurnOnVerify∙\\bulletSystemBrightnessMax∙\\bulletSystemBrightnessMaxVerify∙\\bulletSystemBrightnessMin∙\\bulletSystemBrightnessMinVerify∙\\bulletSystemCopyToClipboard6 templates∙\\bulletSystemWifiTurnOff∙\\bulletSystemWifiTurnOffVerify∙\\bulletSystemWifiTurnOn∙\\bulletSystemWifiTurnOnVerify∙\\bulletTurnOffWifiAndTurnOnBluetooth∙\\bulletTurnOnWifiAndOpenApppro\_expenseCategory\-Shared; Finance6 templates∙\\bulletExpenseAddMultiple∙\\bulletExpenseAddMultipleFromGallery∙\\bulletExpenseAddMultipleFromMarkor∙\\bulletExpenseAddSingle∙\\bulletExpenseDeleteDuplicates∙\\bulletExpenseDeleteDuplicates23 templates∙\\bulletExpenseDeleteMultiple∙\\bulletExpenseDeleteMultiple2∙\\bulletExpenseDeleteSingleretro\_musicCategory\-Shared; Music & Audio3 templates∙\\bulletRetroCreatePlaylist∙\\bulletRetroPlayingQueue∙\\bulletRetroPlaylistDuration1 template∙\\bulletRetroSavePlaylistcameraCategory\-Shared; Photography1 template∙\\bulletCameraTakePhoto1 template∙\\bulletCameraTakeVideochromeCategory\-Shared; Communication2 templates∙\\bulletBrowserDraw∙\\bulletBrowserMaze1 template∙\\bulletBrowserMultiplymaps\_meCategory\-Novel; Maps & Navigation9 templates∙\\bulletMapsMeAddWorkPlace∙\\bulletMapsMeCheckDrivingDistanceTime∙\\bulletMapsMeCheckNearestHotel∙\\bulletMapsMeCheckNearestPlace∙\\bulletMapsMeCheckNearestPlaceDriveTime∙\\bulletMapsMeCheckNearestPlaceWalkTime∙\\bulletMapsMeCheckPublicTransportRoute∙\\bulletMapsMeCheckRidingTime∙\\bulletMapsMeCheckWalkingDistanceTime6 templates∙\\bulletMapsMeCompareRidingVsPublicTransport∙\\bulletMapsMeNavigateToBerkeley∙\\bulletMapsMeNavigateToLocation∙\\bulletMapsMeNavigateToOpenAI∙\\bulletMapsMeNavigateToStanford∙\\bulletMapsMeNavigateToUniversitySouthosmandCategory\-Novel; Maps & Navigation2 templates∙\\bulletOsmAndFavorite∙\\bulletOsmAndMarker1 template∙\\bulletOsmAndTrackbroccoliCategory\-Novel; Food & Drink8 templates∙\\bulletRecipeAddMultipleRecipes∙\\bulletRecipeAddMultipleRecipesFromImage∙\\bulletRecipeAddMultipleRecipesFromMarkor∙\\bulletRecipeAddMultipleRecipesFromMarkor2∙\\bulletRecipeAddSingleRecipe∙\\bulletRecipeDeleteDuplicateRecipes∙\\bulletRecipeDeleteDuplicateRecipes2∙\\bulletRecipeDeleteDuplicateRecipes35 templates∙\\bulletRecipeDeleteMultipleRecipes∙\\bulletRecipeDeleteMultipleRecipesWithConstraint∙\\bulletRecipeDeleteMultipleRecipesWithNoise∙\\bulletRecipeDeleteSingleRecipe∙\\bulletRecipeDeleteSingleWithRecipeWithNoiseopentracksCategory\-Novel; Health & Fitness4 templates∙\\bulletSportsTrackerActivitiesCountForWeek∙\\bulletSportsTrackerActivitiesOnDate∙\\bulletSportsTrackerActivityDuration∙\\bulletSportsTrackerLongestDistanceActivity2 templates∙\\bulletSportsTrackerTotalDistanceForCategoryOverInterval∙\\bulletSportsTrackerTotalDurationForCategoryThisWeekwikipediaCategory\-Novel; Books & Reference3 templates∙\\bulletWikipediaDisablePreviewAndFeed∙\\bulletWikipediaGoToSavedTab∙\\bulletWikipediaGoToSearchTab2 templates∙\\bulletWikipediaIncreaseTextSize180∙\\bulletWikipediaOpenvlcCategory\-Novel; Video Players & Editors1 template∙\\bulletVlcCreatePlaylist1 template∙\\bulletVlcCreateTwoPlaylistssimple\_draw\_proCategory\-Novel; Art & Design1 template∙\\bulletSimpleDrawProCreateDrawing0 templates*None*

## Appendix BAndroidWorld\-Generalization Protocol and Run Accounting

### B\.1Released source and target splits

Setting 1 follows the released AndroidWorld\-Generalization unseen\-app split\([7](https://arxiv.org/html/2608.11588#bib.bib1)\)\. Its source split contains 12 apps, 62 task templates, and 905 training instances\. Every configuration starts from the released step\-500 UI\-TARS\-7B checkpoint\([17](https://arxiv.org/html/2608.11588#bib.bib30)\), which was trained only on this source split\. The reusable source workflow library used by CoAdapt\-GUI is likewise constructed only from this source split\.

The target split contains five apps absent from the source split\. It provides eight adaptation instances per app, for 40 in total, and 48 held\-out evaluation instances\. Adaptation and evaluation cover the same 16 task templates but instantiate them with non\-overlapping seeds\. This setting therefore evaluates transfer to new instances of task types encountered during target adaptation, rather than transfer to new task templates\.

Table 7:Complete target allocation for AndroidWorld\-Generalization\. Each template is present in both splits, but the concrete task instances are disjoint\.
### B\.2Instance seeds and leakage control

The released evaluation manifest instantiates every target template with seeds\{7,30,1234\}\\\{7,30,1234\\\}\. Adaptation uses different seeds: Audio Recorder and Clock use\{1,2,3,4,5,6,8,9\}\\\{1,2,3,4,5,6,8,9\\\}; each OsmAnd template uses\{1,2,3,4\}\\\{1,2,3,4\\\}; each Tasks template contributes two instances; and each Broccoli template contributes one instance\. The released Tasks instances use seeds\{1,2\}\\\{1,2\\\}, exceptTasksCompletedTasksForDate, which uses\{2,3\}\\\{2,3\\\}\. Seven Broccoli templates use seed 1 andRecipeDeleteSingleWithRecipeWithNoiseuses seed 2\. Consequently, the intersection between adaptation and evaluation\(task\_id,seed\)\(\\texttt\{task\\\_id\},\\texttt\{seed\}\)pairs is empty\.

All context revisions, policy updates, and checkpoint selection use only the 40\-instance adaptation manifest\. The workflow context and policy adapter are then frozen before the 48\-instance evaluation manifest is opened\. No held\-out task instance, trajectory, reward, or outcome is used for adaptation or model selection\.

### B\.3Update schedule and result provenance

The adaptive configurations use the released eight adaptation instances per target app and a nominal 50\-update schedule per app\. They are evaluated on the same frozen 48\-instance manifest\. The schedule fixes the number of method\-level updates; because context revision and policy optimization use different update operators, it should not be interpreted as an identical gradient or compute budget across methods\.

The Base Policy and Policy\-Only TTA values in the main paper are reported results from AndroidWorld\-Generalization\([7](https://arxiv.org/html/2608.11588#bib.bib1)\)and were not reproduced in our environment\. Static Context Transfer, Context\-Only TTA, and CoAdapt\-GUI are our results\. Each is evaluated in five complete runs, and the main paper reports the mean and standard deviation over those runs\. All five runs use the same frozen adaptation and evaluation manifests; no incomplete run is included in the reported statistics\.

## Appendix CCoAdapt\-GUI Implementation Details

This section specifies the realization of the context and policy branches in Algorithm 1 of the main paper\. It describes CoAdapt\-GUI itself rather than restating the implementation of every comparison configuration\. The notationlayer1andlayer2below refers to the runtime JSON schema:layer1is the app\-bound screen\-transition state, andlayer2is the transferable workflow state described in the paper\.

### C\.1Policy and source initialization

For AndroidWorld\-Generalization, CoAdapt\-GUI starts from the released step\-500 UI\-TARS\-7B checkpoint and uses the released 50\-step target schedule described in Appendix[B](https://arxiv.org/html/2608.11588#A2)\. For AndroidWorld Plus, the acting policy is Qwen3\-VL\-8B\-Instruct at revision0c351dd01ed87e9c1b53cbc748cba10e6187ff3b\. The VLM backbone is loaded in bfloat16 and remains frozen\. We initialize it with a rank\-16 LoRA adapter trained only on the 12 source apps\. All configurations within a matched comparison use the same source\-trained initialization, and configurations without policy adaptation keep it frozen\. No target rollout, reward, or held\-out outcome is used to construct or select this initialization\.

Source workflow construction is independent of source\-side LoRA training\. A frozen synthesizer converts audited source trajectories into one app\-bound screen\-transition state and one transferable workflow state per source app\. Only validated transferable entries are grouped by the externally defined Play Store category and consolidated into the immutable source library\. App\-bound screen states, transitions, UI strings, and identifiers never enter this library\.

Table[8](https://arxiv.org/html/2608.11588#A3.T8)reports the resulting frozen library\. A target app can retrieve only the single library matching its Play Store category; cross\-category retrieval is disabled\. Thus a Category\-Novel App receives no source entry, rather than an entry selected by semantic similarity or target reward\.

Table 8:Composition of the frozen transferable source\-workflow library used by AndroidWorld Plus\. Counts refer to validated structured workflow entries, not source trajectories or task templates\.
### C\.2AndroidWorld Plus adaptation configuration

Table[9](https://arxiv.org/html/2608.11588#A3.T9)records the final configuration used for the AndroidWorld Plus experiments\. The four rollouts associated with one task–context condition form the group sizeN=4N=4;NNis not the number of context variants\. At mostM=2M=2already materialized variants are selected in a round, so 20 rounds require at most20×2×4=16020\\times 2\\times 4=160target rollout calls per app\. Early rounds may use only the root variant and therefore consume fewer calls\.

ComponentParameterFinal valuePolicyBackbone / numerical precisionQwen3\-VL\-8B\-Instruct / bfloat16PolicyMaximum image pixels / generated tokens1,605,6321\{,\}605\{,\}632/ 512PolicyLoRA rank / scale / configured dropout16/32/0\.016/32/0\.0PolicyLoRA target modulesq\_proj,v\_projPolicyOptimizer / learning rateAdamW /3×10−43\\times 10^\{\-4\}PolicyMaximum gradient norm1\.01\.0PolicyAdvantage normalizationmean\-centered within task–context groupPolicyMinimum active trajectories for an update33PolicyFrozen\-policy anchor coefficient / log\-ratio clip0\.05/10\.00\.05/10\.0ContextInitial TrueSkill mean / standard deviation25\.0/8\.3325\.0/8\.33ContextTrueSkill performance / dynamics parameters4\.17/0\.0834\.17/0\.083ContextPopulation window / child uncertainty increment15/1\.515/1\.5ContextSelection optimism / softmax temperature1\.0/1\.01\.0/1\.0ContextFrozen synthesizer and reflectorClaude Opus 4\.7ContextReflection / diff output limits4,096/32,0004\{,\}096/32\{,\}000tokensContextMalformed\-output retries33ProtocolAdaptation rounds per target app2020ProtocolContext variants per roundM≤2M\\leq 2ProtocolRollouts per task–context conditionN=4N=4ProtocolMaximum rollout calls per app160160ProtocolAdaptation / evaluation task seeds\{30,31,32,33,34\}/\{40,41,42\}\\\{30,31,32,33,34\\\}/\\\{40,41,42\\\}ProtocolHardware / mean adaptation timeNVIDIA H200 141 GB / 9–10 GPU\-hoursTable 9:CoAdapt\-GUI implementation details for AndroidWorld Plus\. The policy buffer is transient and is cleared after every update attempt; its lifetime is specified below\.
### C\.3Context population and reward\-guided revision

Each target app has an independent population of transferable workflow states\. For a Category\-Shared App, the root contains the retrieved category\-matched source workflow context\. For a Category\-Novel App, source retrieval returns empty and the target\-grounded root is initialized empty\. In the latter case, the first validated child constructs an initial transferable entry from target rollout evidence; later children refine that entry in the same way as in the nonempty case\.

At roundtt, the controller samples up to two variants from the latest 15\-member population window\. Sampling is proportional to

p⁡\(i\)∝exp⁡\(μi\+λ​σiT\),λ=1,T=1,p\(i\)\\propto\\exp\\\!\\left\(\\frac\{\\mu\_\{i\}\+\\lambda\\sigma\_\{i\}\}\{T\}\\right\),\\qquad\\lambda=1,\\quad T=1,
where\(μi,σi\)\(\\mu\_\{i\},\\sigma\_\{i\}\)is the variant’s TrueSkill rating\. Selected variants are evaluated on matched task and reset conditions\. Their benchmark task rewards determine their ordering and update their ratings\. A frozen reflector then contrasts the resulting success and failure traces and proposes a typed revision to a high\-rated parent\.

The temporal order is important\. Only variants that existed before the current rollouts receive ratings from those rollouts\. A newly proposed child is added only after typed\-diff parsing, transferable\-state scope filtering, and a nonempty state change; the caller records its parent, task, iteration, and revision provenance\. The child receives no inherited reward\. Its usefulness is measured only if it is sampled in a later round\. At budget exhaustion, the highest\-rated validated state is selected asM⋆M^\{\\star\}\.

The reflection record contains the task template and instantiated goal, reset seed, executable task reward, and a compact trace of actions, action reasons, post\-action summaries, UI evidence, and parse or execution status\. The caller retains at most ten UI\-element lines per step, clips each line to 160 characters, and clips reasons and summaries to 400 characters\. These limits bound the reflector input without replacing executable rewards with model judgments\.

### C\.4Task–context\-matched LoRA update

Every trajectory is stored with its task, rendered\-context identity, reset identity, and the exact multimodal inputs and action tokens used during collection\. Policy advantages are computed only within groups whose members share the same task and context variant\. In the reported AndroidWorld Plus configuration, each such group contains four rollouts and uses the mean\-centered advantage

Aj=rj−1\|G\|​∑i∈Gri\.A\_\{j\}=r\_\{j\}\-\\frac\{1\}\{\|G\|\}\\sum\_\{i\\in G\}r\_\{i\}\.
Singleton or constant\-reward groups have zero advantage and are excluded from the active policy batch\. An update is attempted only when at least three active trajectories remain\. For each active trajectory, action\-token log\-probabilities are averaged within the trajectory before weighting byAjA\_\{j\}, preventing a long rollout from dominating solely because it contains more action units\.

The policy buffer is a transient on\-policy accumulation buffer, not a replay memory\. The policy remains fixed while a matched batch is collected\. After the batch becomes eligible, at most one LoRA update is attempted and the buffer is cleared whether or not the batch contains an active reward comparison\. No trajectory is reused after the policy changes\. The frozen source\-trained adapter supplies the policy anchor; the numerical log\-ratio is clipped to\[−10,10\]\[\-10,10\], and the final gradient norm is clipped to 1\.0\. Adapter dropout is disabled during both collection and gradient replay so that the saved behavior probabilities and the replayed current\-policy probabilities refer to the same stochastic policy\. Policy\-sampling seeds, rather than dropout, provide the within\-condition rollout diversity\.

### C\.5Frozen evaluation

After the interaction budget is exhausted, the selected workflow state and final LoRA adapter are written as immutable artifacts\. Evaluation loads only these artifacts and the held\-out manifest; the reflector, population controller, and optimizer are disabled\. The structural, transferability, and behavioral checks applied before this point are specified together with the operative prompts in Appendix[F](https://arxiv.org/html/2608.11588#A6)\.

## Appendix DWorkflow\-Context Representation

This section gives concrete examples of the structured context described in the main paper\. Each transferable workflow entry followsw=⟨c,P,F,V⟩w=\\langle c,P,F,V\\rangle: an applicability condition, an abstract procedure, failure or recovery conditions, and completion checks\. Each example below is condensed from a validated workflow artifact by removing repeated safeguards and provenance metadata; no new procedural, failure, or verification rule is introduced\. App names are shown in the headings to identify the originating run, but are not part of the transferable text injected into the acting policy\.

### D\.1App\-bound and transferable components

Table[10](https://arxiv.org/html/2608.11588#A4.T10)illustrates the transfer boundary with a source artifact frommarkor\. The app\-bound component is a genuine screen\-transition FSM: it includes concrete state names, visible strings, resource hints, and action\-conditioned transitions\. The transferable component retains the task logic while removing those interface bindings\. Under unseen\-app adaptation, only the right\-hand form is eligible to initialize another app\.

App\-bound screen\-transition state \(not transferred\)Transferable workflow entry \(eligible\)States:file\_browser, identified by the Markor title, a red bottom\-right create button, and the Files/To\-Do/QuickNote/More navigation;new\_file\_dialog, identified by the pre\-filledmy\_notefield, format selector, and FOLDER/CANCEL/OK controls; andeditor\_edit\_mode, identified by the editor toolbar and save icon\.Transitions:State transitionActionfile\_browser→\\rightarrownew\_file\_dialogclick\(fab\_plus\)new\_file\_dialog→\\rightarroweditor\_edit\_modeclick\(OK\)Applicability:a list or index exposes an affordance for creating an item\.Procedure:invoke the create affordance; clear any placeholder; provide the required identifier; select the requested item type if needed; confirm creation; enter the requested content; and persist the change\.Failures:retaining a placeholder in the identifier, choosing the wrong item type, creating in the wrong parent container, or declaring success before persistence\.Verification:the new item appears under the expected parent with the exact identifier, and reopening it shows the requested content\.Table 10:Concrete separation between app\-bound interaction state and an app\-agnostic workflow entry\. The left column may support execution within its source app but is excluded from cross\-application retrieval\.
### D\.2Representative highly rated target contexts

We next show three entries from highly rated validated states produced during AndroidWorld Plus adaptation\. They cover both initialization regimes: the calendar example refines retrieved source knowledge for a Category\-Shared App, whereas the navigation and activity\-history examples were constructed from target rollouts after Category\-Novel retrieval returned an empty source state\. These entries are selected to illustrate the representation, not as additional quantitative evaluation examples\.

Example 1: Scheduled\-entry creation \(Category\-Shared\)Origin\.The target app issimple\_calendar\_pro; its Productivity category is represented in the source pool\. The entry starts from retrieved source workflow knowledge and is revised using target\-app traces\.Applicability \(cc\)\.A create form exposes multiple structured fields, such as title, date, start time, end time or duration, and optional content\.Procedure \(PP\)\.Enumerate every goal\-specified field before acting; resolve relative dates to absolute dates; set and visually confirm each field; after confirming the start time, derive the dependent end time; verify which picker component is active before editing it; save; then reopen the created item and read back every requested field\.Failure/recovery \(FF\)\.Do not assume that an end\-time field inherits an edited start time\. Do not mistake an hour\-to\-minute auto\-advance within one picker for a transition to another field\. If the reasoning and action summary contain contradictory numeric values, re\-inspect the form before continuing\.Verification \(VV\)\.The saved detail view, rather than a potentially truncated list row, must show the requested date, start and end times, and other specified fields before completion is emitted\.

Example 2: Nearest\-place and route lookup \(Category\-Novel\)Origin\.The target app ismaps\_me; Maps & Navigation is absent from the source pool\. Its root transferable state is empty, and the entry is synthesized and subsequently refined from target adaptation traces\.Applicability \(cc\)\.The task asks for a nearby place, place details, or a route with a specified travel mode\.Procedure \(PP\)\.Establish a valid location and populated map view before searching; clear the query field and use a canonical place\-category term; inspect both result rows and map markers; open a candidate’s detail view; for routing, set both endpoints and the requested travel mode before reading the rendered distance or duration\.Failure/recovery \(FF\)\.A viewport\-scoped empty result is not global infeasibility\. Recenter or widen the map before reformulating the query\. Clear existing text before retrying to avoid concatenated queries, and avoid random panning without a location reference\.Verification \(VV\)\.A location reference and populated map are visible; the selected result’s type matches the goal; and any reported place, distance, or duration is read from the rendered result or route summary\.

Example 3: Historical activity aggregation \(Category\-Novel\)Origin\.The target app isopentracks; Health & Fitness is absent from the source pool\. The selected workflow descends from a child that constructed the category entry from an empty root\.Applicability \(cc\)\.A history query specifies a time window, an activity type, and an aggregation such as count, total, maximum, or average\.Procedure \(PP\)\.Anchor relative dates to an observed current date; resolve the requested time interval and week convention; use available date and activity filters; inspect the full in\-window set; disambiguate activity types using structured metadata rather than user\-authored titles; aggregate the confirmed entries; and format the result in the requested unit and precision\.Failure/recovery \(FF\)\.Avoid first\-match answers for maximum or total queries, title\-based activity classification, confusion between calendar weeks and rolling seven\-day windows, and unit conversion based on rounded summary values when a precise detail value is available\.Verification \(VV\)\.Every included entry has an observed type and timestamp inside the requested interval; the list boundary has been reached; units and time formats have been checked; and exactly one answer is followed by one completion action\.

### D\.3A recorded context\-evolution step

The Chrome adaptation log provides a compact example of reward\-guided context selection\. The retrieved Communication context initially contained generic navigation and repeated\-action procedures\. A child proposed after target traces added three pieces of guidance: handle first\-launch gates before continuing the task, verify that a post\-action observation has actually advanced, and change strategy after repeated no\-op actions\. Table[11](https://arxiv.org/html/2608.11588#A4.T11)shows that the child was admitted without inheriting its parent’s reward and was evaluated only in later rounds\.

Table 11:A recorded Chrome context\-evolution event\. Values are mean executable task rewards over the four rollouts for the indicated task–context condition\.The round\-12 rating update favored the evolved branch, and later revisions retained its onboarding and state\-advancement checks\. The trace illustrates the intended temporal separation: a typed revision is first validated, then tested in subsequent rollouts, and retained according to executable task feedback\.

## Appendix EAdditional Analyses and Ablations

### E\.1Incremental contributions of the adaptation channels

Table[12](https://arxiv.org/html/2608.11588#A5.T12)rewrites the AndroidWorld Plus results from the main paper as increments between the configurations that isolate each adaptation channel\. Static Context Transfer improves Category\-Shared Apps by 9\.3 percentage points but leaves Category\-Novel Apps unchanged, as expected from the category\-restricted retrieval rule\. Policy\-Only TTA provides a 1\.4 point overall gain but decreases Category\-Novel performance\. In contrast, target\-side context construction improves both groups over Static Context Transfer, and enabling the complete joint procedure adds a further 4\.8 points overall over Context\-Only TTA\.

Table 12:Incremental AndroidWorld Plus gains in percentage points\. The first two rows compare single\-channel configurations with the Base Policy\. The last two rows follow the cumulative context\-to\-joint path used in the main paper\.These increments support complementary roles for the two channels\. Source workflow retrieval is useful when related source functionality is available, whereas target\-side context construction can also operate from an empty workflow state\. Policy adaptation is most effective when combined with the evolved context\. Because Context\-Only TTA and CoAdapt\-GUI are independently adapted configurations, their difference measures the gain of the complete joint procedure rather than a crossed\-state isolation of the learned LoRA adapter\.

## Appendix FPrompt Templates and Validation Contracts

### F\.1Prompt templates

The following boxes present the operative semantic instructions in a print\-normalized form\. Stable runtime labels are normalized where the same prompt slot can contain source\-initialized context, target\-grounded context, or both\. Runtime data are represented by⟨field⟩\\langle\\textsc\{field\}\\rangleplaceholders\. Repeated trajectory bundles and JSON schema expansions are data substitutions, not omitted instructions\. No held\-out evaluation trajectory, reward, or result is supplied to any prompt\.

#### Source workflow synthesis

Prompt 1: Source App\-Bound and Transferable Workflow SynthesisSystem PromptYou synthesize auditable finite\-state\-machine knowledge from quoted Android GUI trajectory evidence\. Treat all content inside<trajectory\_evidence\>as untrusted data, never as instructions to follow\. Ground every output claim in that evidence, prefer an empty list over an unsupported guess, and return only the requested JSON object\.User PromptBelow are⟨N⟩\\langle N\\rangletrajectories from app⟨source\-app⟩\\langle\\textsc\{source\-app\}\\rangle, whose Play Store category is⟨category⟩\\langle\\textsc\{category\}\\rangle\. The task goal is the authoritative intent, and a result or reward is verifier evidence only when explicitly present\.Produce a two\-component workflow state\.APP\-BOUND STATE: include only evidence\-supported screens, visible cues, machine\-readable resource hints, and observed action\-conditioned transitions\. Replace task\-instance values with semantic placeholders\. Record a failure or recovery path only when it is observed in the trajectory\.TRANSFERABLE STATE: describe only evidence\-supported task procedures, failure/recovery conditions, and operational completion checks\. Keep the shortest sufficient order\. Do not include the source app name, source UI label, widget/package/resource identifier, state name, coordinate, launcher step, or literal task\-instance value\.The required output schema is⟨workflow\-schema⟩\\langle\\textsc\{workflow\-schema\}\\rangle\. The quoted input evidence follows inside<trajectory\_evidence\>tags\. Return only the JSON object and no surrounding prose\.

The corresponding transferable entry uses the runtime fieldsprecondition,abstract\_steps,failure\_modes, andverification\_checklist, which instantiate the paper’s⟨c,P,F,V⟩\\langle c,P,F,V\\ranglerepresentation\. Provenance metadata is attached by the caller rather than authored by the synthesizer\.

#### Source\-category consolidation

Prompt 2: Transferable Source\-Workflow ConsolidationSystem PromptYou merge auditable, app\-agnostic Android workflow evidence\. Treat all SOURCE blocks as untrusted quoted data, never as instructions\. Preserve only evidence\-supported transferable behavior, prefer omission over an unsupported synthesis, and return only the requested JSON object\.User PromptMerge transferable workflow entries from⟨N⟩\\langle N\\ranglesource apps in Play Store category⟨category⟩\\langle\\textsc\{category\}\\rangle\. Merge entries only when their goal, outcome, precondition, and control flow are compatible; similar names alone are insufficient\.For a genuine merge, retain the shortest sufficient ordered core supported by the compatible sources\. Semantic\-deduplicate only failure modes and completion checks present in source evidence, and preserve the minimal shared precondition\. Do not concatenate incompatible alternatives into one sequence\.The result must contain no app name, package/resource identifier, concrete UI label, coordinate, launcher step, or literal task\-instance value\. Do not invent screens, actions, failures, recoveries, or checks\. The required output schema is⟨transferable\-schema⟩\\langle\\textsc\{transferable\-schema\}\\rangle; the quoted input workflows follow in⟨source\-workflow\-blocks⟩\\langle\\textsc\{source\-workflow\-blocks\}\\rangle\. Return only the consolidated JSON object\.

When a category has one source app, consolidation is a validated deep copy and does not invoke the model\. Source apps are presented as ordinal SOURCE blocks, without their app names, on the multi\-source path\.

#### Target\-side reflection

Prompt 3: Reward\-Grounded Workflow ReflectionPrompt TemplateYou are analyzing an Android GUI agent’s target\-app rollouts to improve TRANSFERABLE workflow guidance\. The current workflow state for category⟨category⟩\\langle\\textsc\{category\}\\rangleis⟨current\-workflow⟩\\langle\\textsc\{current\-workflow\}\\rangle\. The evaluated trajectories are⟨rollouts\-with\-task\-seed\-reward⟩\\langle\\textsc\{rollouts\-with\-task\-seed\-reward\}\\rangle\.Analyze the supplied trajectories and their rewards\. Determine whether an abstract step is missing or misleading, whether an observed failure or recovery pattern should be recorded, and whether the completion checks require another observable or executable signal\. Cite trajectory step numbers for every proposed change\.All suggestions must remain applicable beyond the current interface\. Do not propose app names, screen names, button labels, package/resource identifiers, coordinates, or literal task\-instance values\. If the evidence is insufficient, state that no revision is supported\.Empty\-State BranchIf⟨current\-workflow⟩\\langle\\textsc\{current\-workflow\}\\rangleis empty, construct an initial app\-agnostic workflow entry from the target evidence instead of editing a source entry\. Use only patterns supported by the supplied target rollouts; an empty proposal is preferable to an unsupported rule\.

#### Typed workflow revision

Prompt 4: Typed Transferable\-Workflow DiffPrompt TemplateGiven the current transferable workflow state and the grounded reflection, return a JSON diff\. Every operation must targetlayer2/category; no app\-bound operation is allowed\. The only operation types areadd,modify, andremove\. Include only evidence\-supported changes\. For a modified list, return the complete updated list rather than only its new items\. Prefer one to three focused operations and consolidate near duplicates\.Keep at most 16 abstract steps, 20 failure modes, and 16 verification items in an entry\. No app name, package/resource identifier, concrete widget label, coordinate, state identifier, or literal task\-instance value may occur\. Return only the JSON object\.Output Schema\{"ops": \[\{"layer": "layer2", "target": "category","op": "add\|modify\|remove", "key": <category\>,"value": <complete typed value\>\}\],"reflection\_summary": <string\>, "layer\_tag": "layer2"\}

For an empty target\-grounded state, the first valid diff uses anadd/categoryoperation containing the initial precondition, abstract steps, failure modes, and verification checklist\. It enters the population without reward and is tested only in later rounds\.

#### Agent\-facing workflow injection

Prompt 5: Agent\-Facing Workflow GuidanceInjected Prompt Slot\# Workflow knowledgeThe following abstract workflow patterns encode general strategies, common failure modes, and verification signals\. They may come from eligible source workflows, validated target\-adaptation experience, or both\. They do not describe this specific app’s UI; rely on the current screenshot to identify actual elements\.⟨rendered\-transferable\-workflow\-state⟩\\langle\\textsc\{rendered\-transferable\-workflow\-state\}\\rangle

The slot is inserted after the stable agent instruction prefix and before the episode\-specific goal, history, screenshot, and UI\-element list\. The rendered state contains the retrieved source entries together with the currently selected target\-grounded revisions\. For a Category\-Novel App, the initial rendered state contains no abstract categories; guidance appears after an empty\-state candidate has been constructed, admitted, and selected in a later round\.

### F\.2Validation contracts

The prompts above state semantic evidence and transfer constraints, while the runtime applies separate programmatic checks\. Table[13](https://arxiv.org/html/2608.11588#A6.T13)distinguishes these two roles\. This distinction is important: instructions against concrete UI labels, coordinates, launcher behavior, and literal task\-instance values are semantic prompt constraints; the hard transfer linter detects identifiable source\-app strings, package or resource identifiers, and app\-specific state identifiers\. Structural validity and later task reward are checked independently\.

Table 13:Prompt\-level and programmatic validation contracts\. Structural admission determines whether a candidate can be evaluated; executable rewards from later matched rollouts determine whether it is behaviorally useful\.The validation pipeline therefore does not treat a syntactically valid model response as learned knowledge\. Source entries must satisfy construction and transfer checks, and target revisions must first become typed candidate states\. Only candidates that subsequently receive favorable executable task feedback can be selected as the frozen workflow context\.