Self-Organizing UIs

Abstract

Generative UI research has shown that foundation models can produce complete, custom interfaces for any prompt, but generation latency and per-prompt ephemerality make on-demand generation impractical for routine product surfaces. We introduce Self-Organizing UIs: per-user interfaces persisted as versioned artifacts and maintained by an autonomous agent harness that regenerates them when the underlying data or the user's stated intent changes. Each generated page is itself a dynamic web application, granted a typed function surface (memory access, storage access, and domain APIs) through which it reads and writes live data between regenerations: the harness maintains the interface's structure while its data stays continuously current.

I. From Static to Generative to Self-Organizing

For three decades, web interfaces have been one artifact shared by all users. Personalization meant parameterizing a fixed template: a recommender system selects which items fill predefined slots, but the structure, hierarchy, and visual language of the page are identical for everyone. The interface is code that renders data, and the code is written once, by hand, for the average user.

Generative UI breaks this assumption. Leviathan et al. (2025) demonstrated that a frontier model (Gemini 3 Pro), given tool access, planning-oriented system instructions, and a post-processing pass, can generate complete interfaces (HTML, CSS, JavaScript) in direct response to any prompt. In their evaluations, human raters strongly preferred these generated experiences over text and markdown outputs, and quality approached websites designed by human experts on their PAGEN dataset. The result establishes the capability: models can design and implement a full interface, per request, with no human in the authoring loop.

The same work also exposes the operational constraint: generation can take over a minute, and each prompt produces a new, ephemeral experience. That profile suits exploratory, single-session use (their "dynamic view" experiment) but not a product surface a user returns to daily. No one waits a minute for their portfolio page to render, and a page that is re-imagined from scratch on every visit cannot accumulate the continuity users rely on: yesterday's layout, yesterday's framing, yesterday's mental map.

A Self-Organizing UI inverts the lifecycle. The interface is generated ahead of visits, persisted as a versioned artifact, and maintained by an autonomous agent harness that reorganizes it when its inputs change: the user's data, the user's stated preferences, or the passage of time. Generation latency moves off the critical path entirely; the user always loads a finished page. And the finished page is not a frozen render: it is a working application with live connections to the user's data (Section III), so it remains current between the harness's structural passes. The interface behaves like a living application: it has versions, an editor (the harness), an owner (the user), a publication process, and a runtime of its own.

II. The Interface as a Versioned Artifact

On the Vicunous platform, this takes concrete form at two surfaces: vicunous.com/portfolio and vicunous.com/investments/$id. Each authenticated user who visits these routes receives a different document. Not different data in the same component tree: a different page, composed for that user, reflecting what the harness knows about their holdings, their history, and the way they have asked to see things. One user's portfolio page may lead with concentration analysis because they asked for it by email last month; another's may lead with a timeline because their activity suggests they think chronologically.

Within the V Stack, this is a deliberate relocation of the interface. Conventionally the interface lives only at L7, as code. A Self-Organizing UI is stored at L1 (V Artifacts) as a versioned artifact, produced through L6-style adaptation (structured analysis translated into a rendered surface for a specific audience of one), and served at L7 with no inference on the request path. The artifact itself is a self-contained web application: markup, presentation logic, and typed bindings to the function surface described in Section III. What is versioned is the application, and the versioning discipline is strict:

• Versioned objects. Each page is stored as {user}/portfolio/v1, v2, …, vN in user-scoped storage. Nothing is edited in place.
• An active-version pointer. A small registry records which version is live per user per page, along with generation status (idle, generating, failed).
• Atomic promotion. A new version becomes visible only when the pointer flips, after validation. A generation in progress never touches the live page.
• Rollback as a pointer change. Reverting to yesterday's page is a metadata update, not a regeneration.

This storage discipline is what makes autonomous maintenance safe to operate: every state the interface has ever been in is retained, auditable, and restorable, and a failed or rejected generation leaves the live surface untouched.

III. The Function Surface

A generated page would be of limited use if it froze its data at generation time. Valuations move between regenerations; an interface showing last week's numbers until the harness next runs is a report, not an application.

Self-Organizing UIs therefore separate two timescales of change. The harness governs slow, structural change: which sections exist, how they are organized, what the page emphasizes. The function surface governs fast, data-level change: the live values flowing through that structure. When the harness generates a page, it generates it against a manifest of functions the page may call at runtime:

• Memory access. Read and write access to the user's interaction memory: preferences, dismissed elements, view state. What the user does between regenerations becomes input to the next regeneration.
• Storage access. Read access to the user's documents and records in user-scoped storage, the same artifacts the harness itself reasons over when it composes the page.
• Domain functions. Typed platform APIs for domain operations: current valuations, cash-flow recomputation, transaction status, document retrieval.

The generated interface thus inherits the agent pattern one level down. Just as a V Agent's capabilities are an explicit tool manifest rather than ambient authority, a generated page's capabilities are an explicit function manifest: typed, versioned, and granted at generation time. Within that manifest the page composes calls freely, which is precisely what makes each user's page a genuinely different application rather than a differently-filled template. Outside that manifest, nothing is reachable.

This division also sharpens what "self-organizing" means. Data freshness does not require regeneration; the page keeps itself current through its function surface. Regeneration is reserved for reorganization: when the user asks for a different shape, or when the harness's freshness pass concludes that the data has changed in ways the current structure no longer serves (a new asset class appears, a position closes, a section loses its relevance).

IV. The Steward Loop

The harness that maintains these artifacts runs what we call the Steward Loop. It has two trigger classes:

1. Explicit instruction. The user tells the system how their pages should change, in natural language, through channels as low-friction as email: "add a risk section to my portfolio page," "show this investment's cash flows quarterly." Laymanization applies to the interface itself; reshaping your own UI requires no settings panel, no configuration schema, and no vocabulary beyond plain language.
2. Periodic freshness passes. On a schedule, the harness compares each live page against the current state of the underlying data. When the data has moved materially (a new investment, an updated valuation, a completed transaction), the affected pages are queued for regeneration. The interface stays current without the user asking.

Both triggers converge on the same protocol:

• A trusted orchestrator resolves identity and scope first. The triggering user is verified (for email, via sender authentication), and the set of pages and records that user may affect is fixed before any inference runs.
• The orchestrator opens an isolated harness session, mounting the user's current pages read-only alongside the relevant data, so the harness updates the interface rather than re-imagining it from zero. Continuity is preserved by construction.
• The harness reasons over the instruction, the data, and the current page, and produces a candidate version. It writes the candidate through a narrowly scoped, expiring write capability that permits exactly one upload path: that user's staging area for that job. The session holds no credentials.
• The orchestrator validates the staged candidate (structural checks, scope checks, policy checks), promotes it by flipping the active-version pointer, and notifies the user that their page has changed.

The design invariant across every step: the harness supplies content, never decisions. Which user, which pages, which destination paths, and which records are in scope are all determined by the trusted orchestrator from verified inputs before the session starts. Nothing the instruction says, and nothing the harness generates, can widen that scope.

V. Containing Self-Organizing UIs

A system in which an autonomous agent rewrites user-facing pages, triggered by free-form user input, has two untrusted boundaries rather than one, and both must be engineered for the assumption of compromise.

The input is untrusted. An emailed instruction is attacker-writable prose; prompt injection is the baseline threat, not an edge case. The mitigations are structural rather than model-dependent: identity is established by the orchestrator from authenticated signals, never from message content; each session is provisioned fresh per user per job and never reused across users; and network egress from the session is restricted to the exact storage endpoint required for staging. The isolation and zero-trust credential architecture underneath this is the Vicunous Harness Runtime: per-session microVM isolation, and scoped authorization enforced outside the sandbox boundary, so that even total session compromise yields no raw credentials and no reach beyond the invoking user's own scope.

The output is untrusted. A generated page is model output steered by user-supplied text, and it executes with live capabilities, so containment shifts from denying execution to bounding it. Pages are served from private, user-scoped storage through an authenticated route (the storage path derives from the session identity, never from a request parameter) and render inside a sandboxed frame whose content security policy permits network access to exactly one destination: the function gateway. Every function call is authenticated with the viewing user's platform session and authorized server-side against that same user's scope; the page holds no credentials and no ambient authority, and it cannot reach any other origin to exfiltrate what it displays. A malicious generated page, the worst case of a successful injection, can therefore only invoke the same functions the legitimate page could, for the same single user, under the same server-side authorization.

The resulting guarantee is a bounded blast radius. A fully compromised generation session, achieved through the strongest prompt injection an attacker can write, can do exactly one thing: produce a bad candidate page for the attacker's own account, whose runtime capabilities are the same scoped function calls the legitimate page already had, and which validation can reject and promotion can roll back. Other users' pages, other users' data, and the platform itself are outside the reachable set by construction, not by policy.

VI. The Cold-Start Problem

Not every page on the platform is a Self-Organizing UI. Authentication and a handful of other pages are designed in the conventional way, one artifact shared by every user; only the most important surfaces are self-organizing, the data-rich pages a user returns to, such as the portfolio and investment views of Section II.

For a new user, this raises a cold-start problem. With no holdings, no history, and no stated preferences, the harness has no individual signal to compose against, so we converge to the average: new users are served a built-in baseline page, the same kind of default a traditional SaaS product would ship. We still use what is known at the first visit, such as approximate location, to adjust that initial rendering. As the user acts and more data accumulates, the Steward Loop (Section IV) takes over and the page evolves from the shared baseline toward an interface composed for that individual.

VII. Key Findings

• Generative UI capability is established (Leviathan et al., 2025), but per-prompt generation latency and ephemerality make it unsuitable for recurring product surfaces; persistence and asynchronous maintenance are the missing operational half.
• Treating the interface as a versioned L1 artifact (generated ahead of visits, promoted atomically, rolled back by pointer) removes inference from the request path entirely while retaining full auditability of every interface state.
• Generated pages are dynamic applications, not static snapshots: a typed function surface (memory, storage, domain APIs) granted at generation time keeps data live between regenerations, separating fast data-level change from slow structural change.
• A two-trigger Steward Loop (explicit natural-language instruction plus periodic freshness passes) keeps per-user interfaces current and reshapeable without settings panels, applying laymanization to the interface itself.
• Not every page is a Self-Organizing UI; utility pages such as authentication stay conventional. For new users, the cold-start problem is handled by converging to a sensible default (a traditional-SaaS-style baseline) adjusted by first-visit signals such as location, with the page evolving toward an individual interface as data accumulates through the Steward Loop.
• The security posture must assume compromise on both untrusted boundaries: injectable input and generated, executing output. Scope fixed by a trusted orchestrator before inference, capability-based staging writes, per-session isolation, and a render-time policy that confines the page's network reach to a server-authorized function gateway bound the worst case to a single user's own pages and scope.

References

1. Leviathan, Y., Valevski, D., Natchu, V., & Matias, Y. (2025). Generative UI: A rich, custom, visual interactive user experience for any prompt. Google Research Blog, November 18, 2025.
2. Vicunous Research (2026). Vicunous Harness Runtime: Secure Execution Infrastructure for Autonomous AI Agent Harnesses. Vicunous Research.
3. Vicunous Research (2026). Building A3I: AI-Native, Agent-First, Adaptable Intelligence. Vicunous Research.

Disclaimer. This post describes Self-Organizing UIs, an interface architecture Vicunous is building for its platform surfaces. It reflects our current design; individual components are at varying stages of maturity, and aspects described here are the architecture we are building toward rather than fully deployed capability. Generated pages present information for the user's review; they do not make or execute financial decisions, and all agent workflows include human oversight appropriate to the domain, legal and regulatory considerations, and the decision stakes involved. Nothing in this post constitutes financial advice.