PageMem: Structured Web Page Memory

• PageMem is a structured representation that organizes a web page’s DOM into semantically segmented sections with concise summaries.
• It enhances web agent performance by enabling selective attention, efficient token usage, and targeted element extraction.
• By unifying observation, memory, and action, PageMem supports persistent site memory and compound workflows across diverse websites.

Searching arXiv for the primary and closely related papers on PageMem and LLM/web memory hierarchies. PageMem is a structured representation of a single web page in WebChallenger, formally defined as $p = (u_p,\, n_p,\, \sigma_p,\, S_p,\, \mu_p)$, where the page is exposed as a hierarchy of semantic sections with short summaries rather than as an undifferentiated DOM tree or flat text blob. It is deterministically constructed from the DOM and serves as the shared substrate for selective attention, persistent memory of website structure, and site-agnostic compound action workflows (Hwang et al., 9 Jun 2026). In a broader systems sense, a plausible implication is that PageMem belongs to a wider family of page-centric abstractions for LLM systems, including demand-paged context management that treats the context window as an eviction-managed cache rather than as complete memory (Mason, 9 Mar 2026).

1. Definition and conceptual scope

In WebChallenger, PageMem is introduced to address three deficits in conventional web agents: lack of selective attention, lack of persistent memory of site structure, and lack of procedural fluency with common interaction patterns. The underlying claim is architectural rather than model-scaling-oriented: current LLMs are described as already “good enough” for many web tasks, while the missing component is scaffolding that aligns observation and action with human-like cognition. PageMem provides that scaffolding by organizing a page into semantic sections, each with a summary and typed interactive elements, so that the agent can skim, focus, remember, and act over a structured substrate instead of repeatedly consuming the full DOM or accessibility tree (Hwang et al., 9 Jun 2026).

The representation is explicitly positioned against raw DOM or accessibility-tree ingestion. Full-page textual input dilutes relevant information in irrelevant content and increases token usage, especially for smaller models. PageMem instead supports a divide-and-conquer regime in which section summaries function as a table of contents, list sections compress repeated structures, and detailed extraction is performed only for task-relevant regions. This design also differs from screenshot-centric approaches: WebChallenger uses a hybrid text-centric and visual approach, with DOM structure providing the primary segmentation and a VLM supplying page and section summaries.

PageMem is not merely an observation format. It is the state representation on which WebsiteMem, action generation, workflow dispatch, and exploration all depend. Because the same representation supports observation, memory, and action, the framework generalizes across websites without site-specific adapters. The paper treats this unification as the central architectural reason that open-weight models can approach or exceed many proprietary baselines on web-agent benchmarks.

2. Formal representation and hierarchy

PageMem sits within a four-layer hierarchy composed of WebsiteMem, PageMem, PageSection, and Element. The hierarchy is formally specified as follows (Hwang et al., 9 Jun 2026):

Layer	Formal object	Contents
WebsiteMem	$\mathcal{M}_w = (P_w, T_w, E_w)$	URL-to-page map, templates, global element set
PageMem	$p = (u_p, n_p, \sigma_p, S_p, \mu_p)$	URL, title, page summary, sections, page state
PageSection	$s = (\sigma_s, E_s, S'_s, \alpha_s, \mu_s)$	summary, elements, sub-sections, DOM attributes, mutable state
Element	$e = (\alpha_e, E'_e, \mu_e)$	DOM attributes, dropdown children, mutable state

At the website level, $\mathcal{M}_w = (P_w, T_w, E_w)$ stores a mapping from URL to PageMem, a list of template PageMems representing list-page shapes, and a global set of encountered elements. This level functions as persistent site memory. At the page level, $p = (u_p, n_p, \sigma_p, S_p, \mu_p)$ contains the page URL, title, one-sentence page summary, ordered list of PageSections in DOM order, and mutable page-level agent state such as extracted information or per-page history.

Each PageSection is represented as $s = (\sigma_s, E_s, S'_s, \alpha_s, \mu_s)$. Here, $\sigma_s$ is a section summary; $E_s$ is the ordered list of interactive elements in the section; $\mathcal{M}_w = (P_w, T_w, E_w)$0 is empty for ordinary sections but, for list sections, contains one sub-section per selected list item once expanded; $\mathcal{M}_w = (P_w, T_w, E_w)$1 contains immutable DOM-derived attributes such as tag, classes, id, bounding box, and a pointer to the DOM subtree; and $\mathcal{M}_w = (P_w, T_w, E_w)$2 contains mutable state including task-relevant extractions, cached VLM descriptions, and staleness indicators. Elements are similarly typed objects, $\mathcal{M}_w = (P_w, T_w, E_w)$3, where $\mathcal{M}_w = (P_w, T_w, E_w)$4 includes tag, class, id, role, input type, label, aria attributes, href, and exploration-derived flags, $\mathcal{M}_w = (P_w, T_w, E_w)$5 stores dropdown items if the element reveals options, and $\mathcal{M}_w = (P_w, T_w, E_w)$6 records state such as current input value or clicked status.

This hierarchy gives the system a typed interface between symbolic action selection and browser execution. The LLM sees simplified textual descriptions such as a button or textbox in a named section, while Playwright selectors and update logic operate over the richer DOM-grounded attributes. A plausible implication is that PageMem functions as an intermediate representation that compresses browser state while preserving sufficient structure for both reasoning and execution.

3. Construction from the DOM

PageMem is built in two stages: DividePage, which recursively partitions the DOM into an ordered list of empty PageSections, and UpdatePageMem, which populates sections with interactable elements, runs summarization, and computes diffs. DividePage starts from the DOM root, creates a new PageMem, sets the current URL and extracted title, and populates $\mathcal{M}_w = (P_w, T_w, E_w)$7 via recursive splitting. The recursion terminates when a node is a list section, when its tag belongs to the grouping set, or when it is not oversized (Hwang et al., 9 Jun 2026).

The terminal condition is

$\mathcal{M}_w = (P_w, T_w, E_w)$8

with

$\mathcal{M}_w = (P_w, T_w, E_w)$9

and

$p = (u_p, n_p, \sigma_p, S_p, \mu_p)$0

This combines DOM semantics with rendered geometry. The procedure descends until it finds semantically meaningful containers or visually bounded subtrees small enough to treat as atomic sections. Consecutive siblings with identical tag and class are grouped by GroupSiblings; any run of length at least $p = (u_p, n_p, \sigma_p, S_p, \mu_p)$1 is collapsed into a list-section node. List sections are always terminal, so large repeated structures such as search results or product cards are represented compactly at the section level and expanded only later if needed.

UpdatePageMem(p) runs at every observation step. For each section, UpdateSection(s) either summarizes a list section directly or performs element discovery, diffing, and conditional re-summarization. The diff is $p = (u_p, n_p, \sigma_p, S_p, \mu_p)$2, with newly added, removed, and changed elements respectively. Section summaries are recomputed when undefined or when $p = (u_p, n_p, \sigma_p, S_p, \mu_p)$3. This policy makes summarization incremental rather than append-only.

Clickable-element detection is formalized as

$p = (u_p, n_p, \sigma_p, S_p, \mu_p)$4

where

$p = (u_p, n_p, \sigma_p, S_p, \mu_p)$5

$p = (u_p, n_p, \sigma_p, S_p, \mu_p)$6

and

$p = (u_p, n_p, \sigma_p, S_p, \mu_p)$7

Accessible(v) filters hidden and disabled elements. Section and page summaries are produced by VLM prompts such as “Describe this section … in one sentence” and “Describe this page … in one sentence.” Because normal sections are bounded by the Oversized thresholds, each summary prompt remains small.

4. Selective attention, persistent site memory, and workflows

At each timestep, WebChallenger retrieves or constructs PageMem, selects a subset $p = (u_p, n_p, \sigma_p, S_p, \mu_p)$8 using only section summaries, extracts details for those sections, and synthesizes a short task-focused observation $p = (u_p, n_p, \sigma_p, S_p, \mu_p)$9. Section selection is performed by a prompt that receives the task instruction, interaction history, current page name and URL, and the list of section summaries. The model is instructed to select all sections that might be useful and to err on the side of inclusion. For each selected section, the system constructs a details string from the accessibility subtree and VLM-generated image descriptions, then runs an extraction prompt that emits a section-level summary and structured relevant details. Extraction is cached and reused if the section is unchanged (Hwang et al., 9 Jun 2026).

List sections are treated separately because they may contain thousands of items. Items are partitioned into chunks of size $s = (\sigma_s, E_s, S'_s, \alpha_s, \mu_s)$0. For each chunk, an LLM selects possibly relevant items, and a second LLM call checks whether scanning can stop early, for example because the ordering of the list implies the remaining items are irrelevant. After selection, the list section is rebuilt so that $s = (\sigma_s, E_s, S'_s, \alpha_s, \mu_s)$1 contains one sub-section per selected item, and only those selected items contribute elements and candidate actions. This makes long lists tractable without flattening them into a single context.

Persistent site memory is provided by WebsiteMem, built through offline exploration before task execution. Exploration begins at a homepage URL, recursively visits discovered pages to depth $s = (\sigma_s, E_s, S'_s, \alpha_s, \mu_s)$2, and uses budgets of at most $s = (\sigma_s, E_s, S'_s, \alpha_s, \mu_s)$3 elements per page, at most $s = (\sigma_s, E_s, S'_s, \alpha_s, \mu_s)$4 pages per site, and a $s = (\sigma_s, E_s, S'_s, \alpha_s, \mu_s)$5h timeout, with smaller budgets for Online-Mind2Web. ExplorePage builds full PageMem objects, performs template matching to avoid repeated exploration of structurally identical list pages, and calls IteratePage and ExploreElement to probe navigational and interactive behavior. ExploreElement skips off-site links, auth links, tel/mailto/print, and potentially destructive actions. If clicking an element leaves the URL unchanged but yields nonempty $s = (\sigma_s, E_s, S'_s, \alpha_s, \mu_s)$6, the new elements are treated as dropdown content and recursively explored. The resulting WebsiteMem stores reusable page maps, list-page templates, and known element behaviors.

Compound actions are also PageMem-native. Candidate actions are gathered from elements in selected sections, plus navigation candidates from visited URLs or selected bookmarks. Execution dispatch depends on the typed attributes in $s = (\sigma_s, E_s, S'_s, \alpha_s, \mu_s)$7 and exploration metadata such as dropdown_elements. A dropdown workflow clicks the element, runs UpdatePageMem, checks whether the URL changed or $s = (\sigma_s, E_s, S'_s, \alpha_s, \mu_s)$8 is empty, synthesizes a form section if the revealed elements resemble a form, or otherwise selects one of the newly revealed elements and clicks it. A form-submission workflow selects fields, updates the section after each edit, validates required or invalid fields, and runs a review loop of up to $s = (\sigma_s, E_s, S'_s, \alpha_s, \mu_s)$9 iterations before submitting or exiting. Because these workflows operate over sections and elements rather than hard-coded CSS selectors embedded in prompts, they remain tied to structural affordances rather than site-specific surface syntax.

5. Empirical performance and efficiency

WebChallenger reports the following benchmark results using GLM‑4‑32B with Qwen2.5‑VL‑7B (Hwang et al., 9 Jun 2026):

Benchmark	Result
WebArena	56.3%
VisualWebArena	48.7%
Online-Mind2Web	51.0%
WorkArena L1	70.9%

The paper characterizes these results as approaching frontier proprietary systems while remaining zero-shot and using open-weight models without fine-tuning. A backbone comparison isolates the role of architecture: GLM‑4‑32B in a generic minimal harness achieves $e = (\alpha_e, E'_e, \mu_e)$0, whereas the same model in WebChallenger reaches $e = (\alpha_e, E'_e, \mu_e)$1 on WebArena-lite. This suggests that the PageMem-centered architecture, rather than model scale alone, is the dominant source of improvement.

Ablation results make the role of PageMem explicit even though there is no direct “no PageMem” variant. Removing the observation pipeline, which replaces the multi-stage section-based process with a single prompt over the full accessibility tree and reduced history, drops average success on WebArena-lite from $e = (\alpha_e, E'_e, \mu_e)$2 to $e = (\alpha_e, E'_e, \mu_e)$3, a decline of $e = (\alpha_e, E'_e, \mu_e)$4 points. Removing compound actions reduces success to $e = (\alpha_e, E'_e, \mu_e)$5, and removing WebsiteMem reduces it to $e = (\alpha_e, E'_e, \mu_e)$6. The observation pipeline is thus the single largest contributor among ablated components.

Efficiency is reported in terms of steps and tokens. With the full system, average steps are $e = (\alpha_e, E'_e, \mu_e)$7, total tokens are $e = (\alpha_e, E'_e, \mu_e)$8M, and average tokens per prompt are approximately $e = (\alpha_e, E'_e, \mu_e)$9. Without the observation pipeline, average steps increase to $\mathcal{M}_w = (P_w, T_w, E_w)$0, average tokens per prompt rise to $\mathcal{M}_w = (P_w, T_w, E_w)$1, and the prompts become $\mathcal{M}_w = (P_w, T_w, E_w)$2 larger. The paper interprets this as evidence that PageMem-based decomposition trades a few large prompts for many smaller, focused prompts that are easier for a $\mathcal{M}_w = (P_w, T_w, E_w)$3B model to reason over. A plausible implication is that PageMem shifts the optimization target from raw prompt count to prompt structure and reasoning locality.

6. Broader memory-systems context and limitations

PageMem in WebChallenger is a page-level representation for web interaction, but the supplied literature places it within a broader page-based systems vocabulary. The Pichay paper argues that the context window of an LLM is structurally equivalent to physical RAM or L1 cache rather than to a full memory system, and introduces a demand-paging architecture in which a transparent proxy interposes on the message stream, evicts stale content, detects page faults when evicted material is re-requested, and pins working-set pages identified by fault history (Mason, 9 Mar 2026). In offline replay across $\mathcal{M}_w = (P_w, T_w, E_w)$4M simulated evictions, Pichay reports $\mathcal{M}_w = (P_w, T_w, E_w)$5 faults, a fault rate of $\mathcal{M}_w = (P_w, T_w, E_w)$6; in live deployment over a $\mathcal{M}_w = (P_w, T_w, E_w)$7-turn session under extreme sustained pressure, it reports $\mathcal{M}_w = (P_w, T_w, E_w)$8 evictions, $\mathcal{M}_w = (P_w, T_w, E_w)$9 faults, and peak compression from $p = (u_p, n_p, \sigma_p, S_p, \mu_p)$0KB to $p = (u_p, n_p, \sigma_p, S_p, \mu_p)$1KB, with classic thrashing when the working set exceeds the effective resident set. The paper also defines an LLM memory hierarchy with L1 generation window, L2 working set, L3 session history, L4 cross-session persistent memory, and backing storage. This suggests a systems-level analogy in which PageMem can be read as a structured, page-granular state object that could participate in eviction, recall, and compaction regimes beyond web agents.

Near-memory address translation provides a second, hardware-oriented analogy. DIPTA, the Distributed Inverted Page Table, constrains virtual-to-physical mapping to low associativity, distributes translation entries across memory vaults, and colocates translation with data so that translation and data fetch proceed in parallel rather than serially. The paper finds that $p = (u_p, n_p, \sigma_p, S_p, \mu_p)$2-way associativity essentially eliminates conflicts across several in-memory server workloads and reports speedups of up to $p = (u_p, n_p, \sigma_p, S_p, \mu_p)$3 over conventional translation with $p = (u_p, n_p, \sigma_p, S_p, \mu_p)$4KB pages and up to $p = (u_p, n_p, \sigma_p, S_p, \mu_p)$5 over conventional translation using $p = (u_p, n_p, \sigma_p, S_p, \mu_p)$6GB pages (Picorel et al., 2016). A plausible implication is that page-centric abstractions such as PageMem become more tractable when the memory system itself is organized around local, structured, eviction-aware page metadata.

The limitations of PageMem as implemented in WebChallenger are also explicit. The section decomposition, clickable heuristics, deterministic exploration, and workflows are hand-designed and may degrade on atypical sites or on heavy JavaScript frameworks that implement custom controls without informative ARIA roles or event attributes. Robustness to malicious pages, prompt injection, deceptive UI, and adversarial layout is not studied. The reliance on many small sequential LLM calls improves token structure but may worsen wall-clock latency. WebsiteMem remains a minimal memory instantiation focused on structural site knowledge rather than richer cross-task experience or skill learning. Future directions proposed in the paper include learned or more visual-aware segmentation, deeper use of visual signals, stronger safety guardrails, and richer memory built on PageMem and WebsiteMem as substrates.