PaperlayerView exact revision on arXiv

Source-linked AI summary

From Interaction to Capability: Task Advancement as State and Supervision for GUI Agents

Ziyang Chen, Qian Li, Chengwei Qin

arXiv:2610.37482v1cs.AI

TL;DR

Long-horizon GUI workflows make it difficult to carry useful information across applications and distinguish productive local results from unsuccessful attempts. TAM tracks verified progress to guide remaining work and learns reusable operations from locally successful interactions. It improves task completion across MobileWorld and SPA-Bench, with reported gains over evaluated baselines.

  • Problem

    Long-horizon GUI workflows require information to carry across applications, while useful operations can be interleaved with failed attempts and final task outcomes give incomplete feedback about intermediate work.

    Source: §1 · pp. 1–2

  • Method

    TAM represents verified task advancement to reduce remaining requirements during execution and abstracts productive interactions into reusable operations with inputs, expected results, and verification conditions.

    Source: §1 · p. 2

  • Results

    34.2% MobileWorld success exceeds the strongest evaluated memory baseline’s 29.1%, and TAM reaches 57.0% in SPA-Bench English Level 3, the highest reported comparison.

    Source: §1 · p. 2

  • Takeaways & Limitations

    Across MobileWorld and SPA-Bench, TAM improves task completion; ablations establish independent value for Advancement State and further gains from persistent operators.

    Source: §5 · p. 8

    Persistent operators accumulate across the benchmark task sequences studied; longer task streams and repeated application updates raise further requirements for maintaining relevant experience.

    Source: Limitations · p. 9

Abstract

from arXiv · show

GUI memory should preserve the results of past actions and learn reusable operations. This is difficult in long-horizon workflows, where agents must use information across applications and useful operations are interleaved with failed attempts. We introduce Task Advancement Memory (TAM), which defines task advancement as verified task progress, and supports ongoing task execution and learns reusable operations. During execution, Task Advancement State represents how verified task progress changes the remaining goals, allowing the agent to build on earlier achievements across applications. After each task, advancement supervision identifies and abstracts the interactions that produced a verified local result. The learned operations preserve the relation between required inputs, expected outcomes, and verification conditions. This retains locally successful operations from both successful and failed tasks. On MobileWorld GUI-only tasks, Advancement State alone raises success from 12.0% to 28.2%. Full TAM achieves a 17.6% relative gain in task success over the strongest evaluated baseline and reduces lifecycle tokens per solved task by 38.7%. On SPA-Bench, TAM achieves state-of-the-art task success in the single-app English Level 3 setting.

1 Introduction

Long-horizon GUI workflows require memory that tracks how completed work changes remaining goals across applications and distinguishes verified progress from attempts. TAM uses that task progress to guide execution and learn reusable operations from locally productive interactions.

1 Introduction

  • Long GUI histories mix completed work, useful information, and detours, so memory must represent how verified progress changes what remains to do across applications.For example, after confirming an event, the agent should use its details to notify participants.Source: §1 · pp. 1–2
  • Task Advancement Memory (TAM) treats GUI-confirmed satisfaction of an unresolved requirement as task advancement, reducing what the agent still needs to determine or accomplish.Task Advancement State makes earlier advancements usable by later goals, while advancement supervision abstracts interactions that produced verified local results.Source: §1 · p. 2
  • TAM improves MobileWorld success from 29.1% for the strongest evaluated memory baseline to 34.2%; with GPT-4o in SPA-Bench English Level 3, it reaches 57.0%, highest in the reported comparison.Source: §1 · p. 2
  • Task Advancement State represents satisfied requirements, available inputs, and unresolved dependencies so agents can build on earlier progress when choosing next actions.It guides execution across applications.Source: §1 · p. 2
  • Advancement supervision converts partial task success into reusable operations that specify needed inputs, intended outcomes, and verification conditions.This retains useful capabilities from productive portions of both successful and failed workflows.Source: §1 · p. 2

2 Related Work

Prior GUI-memory work includes explicit task-state representations, reusable trajectories and workflows, and interface knowledge built through exploration. TAM links verified task results to the remaining requirements they support and to reusable operations.

2 Related Work

  • Task-state methods preserve explicit task information or validated state changes, while TAM links task results to the remaining requirements they support.TAM also uses these dependencies to define reusable operations’ inputs and outcomes.Source: §2 · p. 2
  • Trajectory, workflow, and skill memories reuse experience at different granularities, with differing rules for selecting segments, assigning local credit, and verifying expected results.TAM selects interactions by the requirement they satisfy and carries that requirement into an operation’s outcome and verification condition.Source: §2 · p. 2
  • Exploration-built interface memories provide broad application coverage before downstream tasks, using demonstrations, exploration videos, crawlers, or GUI graphs.Examples include AppAgent, GUI-Xplore, GUI-explorer, ActionEngine, and EAM.Source: §2 · pp. 2–3

3 Method

TAM combines online task-state updates with retrospective learning: it tracks verified requirement progress while extracting reusable operations from supported interactions.

3 Method

  • TAM uses Task Advancement State to represent remaining work and advancement supervision to learn reusable operations, while a fixed base policy selects primitive actions from the live interface.The memories change the supplied context without retraining the policy.Source: §3 · p. 3

3.1 Task Advancement as a Shared Memory Unit

  • A task compiler represents requirements and their dependencies as a graph, with evidence rules specifying how each result is recognized.The task-local state records requirement status, known values, and supporting evidence.Source: §3.1 · p. 3

3.2 Advancement as State: Online Task Reduction

  • Verified progress reduces the residual task, and a next observation distinguishes a draft or attempted action from a confirmed result accepted for dependent requirements.An evidence cache can restore prior source images or crops when text alone is insufficient.Source: §3.2 · p. 4

3.3 Advancement as Supervision: Learning Reusable Operations

  • Retrospective review retains supported local operations even when the larger task fails, separating required entry inputs from information the operation acquires.Operators preserve the relation among inputs, expected advancement, verification, object roles, applicability conditions, and reviewed GUI realizations.Source: §3.3 · p. 5

3.4 Operator Reuse: Task Meaning and GUI Realization

  • TAM matches operators by required inputs and expected results, then checks whether a stored GUI route applies; task knowledge can still guide execution when that route needs adaptation.Current observations determine whether the expected advancement is accepted.Source: §3.4 · p. 5

4 Experiments

The experiments evaluate task completion on cross-app MobileWorld and single-app SPA-Bench workflows, alongside lifecycle cost, component ablations, and audits of information use and learning material.

4.1 Experimental Setup

  • MobileWorld tests long-horizon workflows across applications, while SPA-Bench English Level 3 tests difficult multi-stage workflows within individual apps.MobileWorld methods share Qwen3-VL-32B-Instruct and a 50-controller-round limit; SPA-Bench uses a task-specific budget.Source: §4.1 · pp. 5–6, §4 · p. 5

4.2 Main Results

  • 34.2% MobileWorld success exceeds the strongest evaluated baseline by 5.1 percentage points, while SPA-Bench success reaches 57.0%, the highest reported comparison result.MobileWorld uses Qwen3-VL-32B-Instruct and a 50-round limit; SPA-Bench evaluates single-app English Level 3 tasks.Source: Table 1 · p. 6, Table 2 · p. 6, §4.2 · p. 7
  • 0.771M lifecycle tokens per solved task is 38.7% below ConAct’s 1.257M, while AWM uses 0.720M but solves 13.7% of tasks.TAM combines the strongest completion rate in this comparison with lifecycle cost close to the cheapest evaluated memory method.Source: Table 1 · p. 6, §4.2 · p. 7

4.3 Component Ablations

  • Task Advancement State raises success from 12.0% to 28.2%; adding the Operator Graph yields 32.5%, and with Evidence Cache the graph adds 5.1 points, from 29.1% to 34.2%.With the Operator Graph added to State, average steps fall from 23.4 to 20.9.Source: §4.3 · p. 7, Table 4 · p. 8

4.4 Mechanism Analysis

  • TAM has the highest task-averaged information-identification and target-use coverage, and outperforms flat state on availability and correct target use across 18 paired field instances.TAM scores 77.8% versus 55.6% for state availability, and 77.8% versus 66.7% for correct target use.Source: §4.4 · p. 7, Figure 3 · p. 8
  • Retrospective review reduces median retained operator segments from 20% to 7.7% of source-trajectory length, concentrating supervision on local operations.The figure reports candidate and retained step counts normalized by source-trajectory length.Source: §4.4 · p. 7, Figure 3 · p. 8

4.5 Further Analyses

  • 95.1% of tracked values remain in state after ten decisions, and 74.8% of audited failed executions containing verified local results contribute retained learning material.The appendix also reports 96.2% readout accuracy versus 80.8% for ordinary notes at similar input size.Source: §4.5 · pp. 7–8

5 Conclusion

Task Advancement Memory makes verified results useful during ongoing execution and turns productive interactions into reusable operations. Across the reported benchmarks, TAM improves task completion, with ablations showing value from Advancement State and additional gains from persistent operators.

5 Conclusion

  • TAM uses established results at two timescales: task reduction during execution and reusable operations learned from interactions.Learned operations retain aligned entry inputs, outcomes, and verification targets after abstraction.Source: §5 · p. 8
  • Ablations establish the independent value of Advancement State and further gains from persistent operators.The conclusion frames accumulated progress as making the current problem more concrete, while productive interaction builds capabilities for future workflows.Source: §5 · p. 8
  • Across MobileWorld and SPA-Bench, TAM improves task completion.The conclusion presents this as support for a task-centered foundation for GUI memory.Source: §5 · p. 8

Limitations

TAM’s execution and learning depend on model-based interpretation of requirements and GUI evidence, particularly when outcome cues are ambiguous. The evaluation and persistent-operator lifecycle also leave boundaries around tested settings and memory maintenance.

Limitations

  • TAM’s task-state and operator construction depends on model-based interpretation of requirements and GUI evidence, especially when outcome cues are ambiguous.The authors identify improved visual grounding and outcome verification as ways to strengthen online execution and experience learning.Source: Limitations · p. 9
  • The evaluation covers MobileWorld GUI-only tasks and SPA-Bench’s English Level 3 subset, with web and desktop workflows left for future transfer assessment.The evaluated settings cover cross-application workflows and difficult single-application tasks on mobile devices.Source: Limitations · p. 9
  • Persistent operators accumulate across the studied task sequences, while longer task streams and repeated application updates raise operator-maintenance requirements.The authors identify operator revision and retirement, and their effects on retrieval quality and memory-maintenance cost, as future work.Source: Limitations · p. 9

A.1 Requirements and memory records

  • A task requirement represents information to acquire or an outcome to achieve, with typed values, object roles, prerequisites, and a verification condition.Structured values specify required fields; optional branch conditions identify when a requirement applies.Source: §A.1 · p. 11

A.2 Compiling the task requirements

  • The compiler turns an instruction into information and outcome requirements, linking outcomes to their required inputs without needing advance access to task-specific application contents.It represents conditional requests and separates independent branches so each outcome need not wait for every intermediate result.Source: §A.2 · p. 11

A.3 Updating and reading task advancement state

This section describes how TAM updates task state from requirement-linked evidence and learns reusable GUI operations from verified local results, preserving their inputs, outcomes, and verification conditions. It also covers reliability- and feedback-gated retrieval against pending requirements and the live interface, with expected advancement entering task state only after it is newly observed.

A.3 Updating and reading task advancement state

  • TAM proposes requirement-linked updates from observed evidence and distinguishes source information, derived values, drafts, coverage, and effects.A visible draft does not establish a resulting effect; for example, a sent-message view must support the specified content and recipient. Structured requirements retain missing fields, and contradictory observations remain conflicted until resolved.Source: §A.3 · pp. 11–12

A.4 Recalling visual evidence

  • TAM recalls up to three relevant images when needed source evidence is absent from recent visual context, and cited recalled-image observations follow the ordinary state-update path.Selection matches requirement dependencies and bindings; recalled images are marked as past observations, while current actions and coordinates remain grounded in the live observation.Source: §A.4 · p. 12

A.5 Reviewing local operations and abstracting their inputs

  • Reviewers validate each local result against evidence, select the supporting interaction steps, and abstract their entry inputs, outcome, and reusable method.Inputs are taken from the state at the retained segment’s start; information acquired within that segment is an internal result, not a prerequisite. Compatible samples refine a shared operator while retaining their individual GUI realizations.Source: §A.5 · pp. 12–13

A.6 Retrieval and actor readout

  • Retrieved operations are read out with required inputs, expected advancement, and verification cues; a compatible GUI realization adds its route, while the actor can choose a route from the live screen otherwise.Expected advancement becomes established only when current observations support it; historical task values remain provenance rather than inputs to the present action.Source: §A.6 · p. 13

A.7 Model interfaces and call accounting

  • TAM’s model-cost accounting includes compilation, acting, triggered extraction, format repair, retrospective review, and input tokens from recalled images.Task compilation occurs at initialization, acting follows the environment loop, and review occurs after termination; cache use and input-readout organization add no separate model calls.Source: §A.7 · p. 13, Table 5 · p. 13

A.8 Structured interfaces and representative prompts

  • The compiler represents requirements as typed resource or observable-effect slots with prerequisite links, input roles, retrieval cues, branch conditions, and completion constraints.Updates cite evidence roles and references; the runtime accepts only listed requirements supported by a visible witness in the current post-action observation or a cited recalled image.Source: §A.8 · p. 14

A.9 Candidate boundaries and retained interactions

  • Candidate boundaries constrain review to a local suffix ending at the accepted result, with a default maximum of eight steps and retained inputs determined from the state before the selected start.The host validates selected steps and evidence, closes the route over observed input support, and removes an input requirement only when it was first acquired inside the retained interaction and absent at entry.Source: §A.9 · pp. 14–15

A.10 Operator identity, matching, and GUI readout

  • TAM matches operations by required results and input roles before testing GUI-route compatibility, and tracks semantic-operation reliability separately from route reliability.Reviewed target advancement can support an operation even when the actor adapts its actions; route success additionally requires completing the stored route. Ambiguous or unattributed outcomes are censored.Source: §A.10 · pp. 15–16
  • Semantic guidance must pass its reliability gate, and recorded-route guidance additionally requires sufficient route reliability and GUI applicability.Reference thresholds are τsem,0 = 0.55, τgui,0 = 0.45, and τa,0 = 0.38; changing reliability can enable or suppress route guidance.Source: §A.10 · p. 16
  • Reviewed local reuse outcomes calibrate admission thresholds between tasks, while type, input-role, and interface conflicts remain hard rejections.Thresholds use the midpoint of positive and negative mean preexecution scores; semantic outcomes calibrate matching and semantic gates, while attempted-route outcomes calibrate route and applicability gates.Source: §A.10 · pp. 16–17
  • If no route passes, a supported semantic operation can still supply inputs, result, and verification cue, with missing inputs explicit; scoped negative evidence rejects either mode.Source: §A.10 · p. 17
  • Persistent graph candidates undergo ϵ-Pareto selection on requirement coverage and execution support, then a bound favors new coverage and distinct route families.At most two alternatives are retained; semantic-only advice has E = 0, and candidates without typed requirement coverage are rejected.Source: §A.10 · p. 17
  • Conflicted or unresolved upstream facts are unavailable as inputs, making dependent requirements missing and pending or attempted effects unprepared or ambiguous.A separately confirmed effect retains its observation-backed status despite an upstream conflict.Source: §A.10 · p. 17

A.11 A complete illustrative operator for Figure 2

  • The schematic route-query operator takes origin and destination as inputs and binds the observed driving duration as its result, not as an entry input.Its realization includes the observed application and page, interaction steps, and cited route-result evidence; different observed routes remain separate records.Source: §A.11 · p. 17
  • On reuse, new endpoints replace the prior bindings, and a new observation must establish the duration before it enters task state.The later arrival-time calculation and notification are outside the route-query operator.Source: §A.11 · p. 17

B.1 Benchmarks and Observations

The benchmark evaluation uses MobileWorld’s GUI-only partition for cross-application workflows and SPA-Bench’s English single-app Level 3 setting for multi-stage tasks. Both are mobile-device settings.

MobileWorld

  • MobileWorld’s GUI-only partition contains 117 tasks across 15 applications, including single-, two-, and three-app workflows.The task set spans communication, scheduling, document handling, file management, and shopping; it includes 105 English and 12 Chinese instructions.Source: §B.1 · p. 17
  • The MobileWorld interface supports touch, text entry, scrolling, navigation, app launch, waiting, and termination, but excludes MCP tools and simulated-user clarification.Source: §B.1 · p. 18
  • MobileWorld supplies screenshots and the available Android UI tree, while native evaluators check outcomes using task-specific answer checks, backend state, files, or callbacks.Evaluation data are kept separate from actor observations.Source: §B.1 · p. 18

SPA-Bench

  • SPA-Bench’s English single-app Level 3 split contains 50 tasks across 36 applications, with reference human trajectories of 9–18 annotated actions.These multi-stage workflows complement MobileWorld’s cross-app demands; TAM uses GPT-4o with Set-of-Mark observations in this setting.Source: §B.1 · p. 18

B.2 MobileWorld Implementation and Evaluation

The MobileWorld implementation standardizes the model and interaction budget across methods, evaluates outcomes through native checks, and maintains reviewed operators across a fixed task sequence. Retries preserve task and memory boundaries rather than selecting better results after ordinary failures.

Interaction budget

  • MobileWorld methods use Qwen3-VL-32B-Instruct and a 50-controller-round budget, with internal memory calls counted toward tokens but not rounds.A round counts an external action decision, including waits and context-management actions; some decisions may expand into multiple primitive actions.Source: §B.2 · p. 18

Task outcomes and stopping

  • The native evaluator checks after each GUI action and execution stops on confirmed success; otherwise it ends at termination or the 50-round limit before final evaluation.For decisions containing multiple primitive actions, evaluation occurs after each primitive action.Source: §B.2 · p. 18

Model and context settings

  • Table 6 lists TAM reference-implementation defaults, while baseline controllers retain their own history management and role-specific output limits.Source: Table 6 · p. 18

Task outcomes and retries

  • Task success is determined by native evaluation, while interrupted attempts from unavailable services or invalid initialization are kept separate from completed outcomes.SPA-Bench scores the trajectory after execution; MobileWorld uses per-action and final checks.Source: §B.2 · p. 18
  • A task is retried only when its initial conditions and memory boundary can be restored without duplicating side effects or committed memory.Ordinary task failures are not rerun to select a better outcome; the ledger preserves the original attempt and retry reason.Source: §B.2 · p. 19

B.3 SPA-Bench Implementation and Evaluation

The SPA-Bench evaluation specifies a shared execution and scoring protocol for TAM and ConAct, then reports diagnostic evidence on retained information across later decisions. The appendices define component interventions, metrics, baseline adaptations, and the scope of those diagnostics.

B.3 SPA-Bench Implementation and Evaluation

  • Official success is determined after execution by OCR screening of recorded screenshots followed, when screening passes, by GPT-4o assessment of the instruction and annotated trajectory.Evaluator judgments are not fed back into online action selection, and task failures, premature termination, or exhausted budgets count as zero.Source: §B.3 · pp. 19–20
  • The evaluation uses all 50 SPA-Bench English single-app Level 3 tasks in two shared task-order sequences, with each method starting each sequence with empty persistent memory.TAM and ConAct use the same GPT-4o backbone, task instructions, observation interface, initialization, and task-specific interaction budgets; their memory representations and context management remain distinct.Source: §B.3 · pp. 19–20

B.4 Component Ablations

  • The component study varies enabled memory components while holding the base policy, decoding, interface, history window, and interaction budget fixed.The Evidence Cache ablation removes recalled source images; the Advancement Operator Graph ablation removes persistent retrieval and task-end learning while retaining online state updates.Source: §B.4 · p. 20

B.5 Metric Definitions

  • Success is the percentage of native-evaluator successes, while Steps averages controller rounds and is read alongside Success.Successful trajectories stop at evaluator-confirmed success; unsuccessful ones stop at agent termination or the round budget.Source: §B.5 · p. 20

C Baseline Adaptations

  • MobileWorld integrations preserve each baseline’s memory and update procedures while translating actions to a common mobile interface.The diagnostic analyses use separate task, field, operation, or episode populations, rather than the benchmark-level denominators.Source: C Baseline Adaptations · p. 21, §B.5 · p. 21

D.1 Benchmark Coverage of the Diagnostics

  • The benchmark includes 52 tasks requiring transfer of acquired text or numerical content to a later GUI operation, and source-to-target field scoring applies specifically to that requirement.The main-text audit covers 21 tasks and 52 shared values across five methods, a subset of the applicable tasks.Source: §D.1 · p. 22

D.2 Preserving Information beyond Its Source

  • 92.3% of acquired value–decision pairs retain the value in state overall, 93.1% across applications, and 89.6% when absent from current XML and recent text.Across 106 bindings from 24 tasks with ten subsequent decisions, 95.1% remain in state after ten steps, versus 57.6% in current XML or recent text.Source: §D.2 · p. 22

D.3 Preparing Inputs for an Operation

The paired comparison tests whether TAM’s prerequisite links and action guidance organize source-derived inputs before entry. TAM more often prepares operations and achieves correct first entries, especially when both conditions encountered the required source information.

D.3 Preparing Inputs for an Operation

  • Across the full panel, TAM prepares 40% of operations versus 20% with flat state; final accuracy after possible repairs is 40% versus 35%.The panel covers 20 operation instances; preparation requires all audited environment-derived values to appear together in state before the first entry attempt.Source: §D.3 · p. 22
  • 80% of shared-source operations are prepared by TAM versus 40% with flat state, and 80% achieve correct first entry versus 50%.The comparison covers ten operation instances from five tasks across two saved revisions, including invoice cases both agents fail.Source: §D.3 · p. 23
  • Across six multiinput instances, TAM prepares 66.7% versus 33.3% with flat state, while both achieve 66.7% final correctness.These instances are included in the shared-source comparison; the paired findings indicate more frequent preparation and correct first attempts when both agents encountered source information.Source: §D.3 · p. 23

D.4 Access to Captured Cross-Application Information

TAM state supports accurate, compact readout of captured cross-application information and retains useful local learning signals. The diagnostics also show how its value retention compares with alternatives and how retained material balances correctness and coverage.

D.4 Access to Captured Cross-Application Information

  • TAM state has the highest observed readout accuracy and reduces readout error by 80.0% versus notes, 50.0% versus full textual history, and 66.7% versus visual history.It uses 37.3% fewer input tokens than full textual history, with input size close to ordinary notes.Source: §D.4 · p. 24, Table 8 · p. 24, Figure 8 · p. 24
  • TAM, full textual history, and visual history reach 100% field accuracy on multi-field queries, versus 76.9% for notes.Additional full- and visual-history errors concern derived times; all five contexts repeat one incorrect amount already present in the interaction prefix.Source: §D.4 · p. 25, Table 9 · p. 25

D.5 Quality of Local Learning Signals

  • TAM-retained local outcomes are 100% supported and cover 83.3% of the supported pool, while success-only selection has 85.7% correctness.Success-only selection admits premature completion claims from a workflow that succeeds later; review-output processing failures account for missing supported outcomes.Source: §D.5 · p. 25
  • TAM retains 88.3% of correct acquired values versus 64.3% for success-only selection, with retained-value correctness of 93.8% versus 99.4%.TAM therefore combines broader coverage of correct material with lower correctness among retained values than success-only selection.Source: §D.5 · p. 25
  • TAM’s coverage advantage persists when source-value groups, rather than tasks, receive equal weight.The weighting groups values by task, resource role, and reference value; supported values remain in the coverage denominator even when none from a group are retained.Source: §D.5 · p. 25, Table 10 · p. 25

D.6 Learning from Incomplete Workflows

The analyses trace how supported local progress from incomplete workflows can be retained, reused with new inputs, and delivered through compact state and guidance. They report when correct records arise, how later uses fare, and the share of context and tokens devoted to memory.

D.6 Learning from Incomplete Workflows

  • 72.9% of audited failed executions contain a source-checked correct record by their midpoint, and correct material from 74.8% of those executions is retained for learning.The median first-record position is 28.6% of execution; the 29 audited executions span 16 tasks.Source: §D.6 · p. 26, Figure 10 · p. 26
  • Operators linked to 15 retained candidates later appear in other tasks’ prompts, with recorded lineage connecting those deliveries to ten correct destination uses.A documented chain starts with a correct phone-number acquisition in a failed source workflow and reuses its operator for a different number in a later task.Source: §D.6 · p. 26, Figure 11 · p. 27

D.7 Using Recalled Experience with New Inputs

  • Of 24 fields where the target’s required value differs from comparable source values, 20 match the new reference, one is incorrect, and three remain unresolved.The changed-reference test distinguishes obtaining the target task’s value from repeating a source value.Source: §D.7 · p. 27, Figure 12 · p. 28
  • Of 29 bound values matched to executed text entry, 23 (79.3%) reach the intended destination with the correct value.The test excludes 57 fields without a matching text-entry action and does not cover other input modes such as time pickers.Source: §D.7 · p. 27, Figure 12 · p. 28

D.8 Inference and Context Allocation

  • Across tasks, additional model calls account for a median 1.7% of recorded tokens (interquartile range 0.4–6.8%), while state and operator guidance account for a median 5.7% of actor-prompt characters (interquartile range 4.3–7.8%).The prompt-text measure covers 7,107 saved actor prompts. Across configurations, median token shares range from 0.5% to 13.4%, and median text shares from 4.1% to 6.3%.Source: §D.8 · p. 28
  • The reported profiles characterize explicit task state and reusable guidance as a compact addition to actor context.The paper notes that the small median token share for additional calls complements this representation.Source: §D.8 · p. 28

Analysis Protocols and Sample Definitions

The diagnostic analyses combine benchmark metadata, archived executions, paired state controls, and fixed-checkpoint readout tests, with distinct statistical units and eligibility rules. They assess information persistence and use, retained-value quality, and whether stored operations appear in later behavior.

Persistence protocol

  • The persistence cohort includes 106 bindings across 24 tasks; at 15 decisions, state and current XML/recent text contain 98.8% and 34.3% of tracked values.This literal-presence measure excludes images and other prompt blocks; the 15-decision endpoint uses a separate cohort of 88 bindings across 20 tasks.Source: Analysis Protocols and Sample… · p. 29

Readout sample

  • The fixed-checkpoint readout test selects 23 claims from 32 valid later-application occurrences, with source review resolving 20, including one incorrect stored claim.Three claims have unresolved source-object, quantity, or temporal references; the test concerns access to facts previously captured in TAM state.Source: Analysis Protocols and Sample… · p. 29

Readout comparisons

  • 3.85% error for TAM versus 19.23% for notes, 7.69% for full history, 11.54% for visual history, and 73.08% for recent context; leave-one-task-out sensitivity is an 8.3–16.7-point TAM advantage over notes.The sensitivity range is not a confidence interval; analyses reuse 100 responses, with 28 fields nested within 20 queries.Source: Analysis Protocols and Sample… · p. 29

Analysis sources and units

  • Table 12 separates benchmark metadata, historical executions, paired state controls, and fixed-checkpoint readouts; its units distinguish tasks, episodes, operations, fields, and repeated observations.The paired state study holds its two arms within each saved revision, while the readout study holds questions and checkpoints fixed as supplied context varies.Source: Analysis Protocols and Sample… · pp. 28–29, Table 12 · p. 30

Outcome review

  • Among 15 proposals with usable independent review decisions, TAM stores ten supported outcomes and none of five contradicted outcomes.The independent test includes all 20 proposals remaining after 85 of 105 admitted outcomes nominated by native evaluation were excluded; two proposals fail normalization and three have malformed review JSON.Source: Analysis Protocols and Sample… · p. 30

Resource quality

  • 94.9% correctness and 78.2% coverage for TAM, versus 98.8% and 76.4% for success-only selection, in the unweighted source-value comparison.The audit covers 234 complete reference slots across 20 tasks; correctness and coverage use different denominators.Source: Analysis Protocols and Sample… · p. 30

Failed-source reuse

  • 18 correct, two incorrect, and five unresolved values occur across 25 fields in 20 later bindings linked to stored failed-source operators.Those operators appear in 56 later episode–operator pairs across 26 tasks; the 29 failed-source candidates cover 16 tasks.Source: Analysis Protocols and Sample… · pp. 30–31

Reuse and computation

  • 206 first episode–operator deliveries occur across 168 executions and 60 tasks, comprising 165 acquisitions, 34 interface outcomes, and seven unresolved types.The first subsequent binding is fixed before scoring, so later repairs cannot replace an incorrect initial value.Source: Analysis Protocols and Sample… · p. 31

Related papers

Loading 2610.37482v1…