From 8a54883f49a945b7975c354089939528dd942ca8 Mon Sep 17 00:00:00 2001 From: rkoster Date: Thu, 17 Sep 2026 15:34:40 +0200 Subject: [PATCH 1/2] docs: add A2UI research note --- .../plans/2026-09-17-a2ui-research-note.md | 26 ++++++ .../2026-09-17-a2ui-research-note-design.md | 24 +++++ research/a2ui.md | 88 +++++++++++++++++++ 3 files changed, 138 insertions(+) create mode 100644 docs/superpowers/plans/2026-09-17-a2ui-research-note.md create mode 100644 docs/superpowers/specs/2026-09-17-a2ui-research-note-design.md create mode 100644 research/a2ui.md diff --git a/docs/superpowers/plans/2026-09-17-a2ui-research-note.md b/docs/superpowers/plans/2026-09-17-a2ui-research-note.md new file mode 100644 index 0000000..4720328 --- /dev/null +++ b/docs/superpowers/plans/2026-09-17-a2ui-research-note.md @@ -0,0 +1,26 @@ +# A2UI Research Note Implementation Plan + +> **For agentic workers:** Execute inline with validation checkpoints. + +**Goal:** Add a sourced A2UI research note and assess its Cloud Foundry relevance. + +**Architecture:** Describe A2UI as a data-only UI protocol: agents emit declarative component/data messages, clients resolve them against trusted native component catalogs, and renderers map them to platform UI widgets. + +**Tech Stack:** Markdown, YAML frontmatter, Devbox, Git, GitHub CLI. + +--- + +### Task 1: Write `research/a2ui.md` + +- [ ] Add valid frontmatter with A2UI sources, tags `[inter-agent-comms, governance, ecosystem-survey]`, and `cf_areas: [capi, uaa]`. +- [ ] Explain A2UI’s agent-to-client generation, transport, resolution, and rendering flow. +- [ ] Cover declarative safety, trusted component catalogs, incremental flat-list updates, data models/actions, framework portability, and renderer implementations. +- [ ] State the current early public-preview/version status accurately. +- [ ] Assess CF relevance for agents hosted on CF sending safe UI descriptions to client applications, including identity, session, and audit boundaries. +- [ ] Add questions about catalog governance, action authorization, client compatibility, transport, and sensitive data. + +### Task 2: Validate and publish + +- [ ] Run `devbox run validate`, `devbox run test`, and `git diff --check`. +- [ ] Stage only the note and approved spec/plan, commit `docs: add A2UI research note`, push `research/a2ui`, and open a checklist-complete PR targeting `main`. +- [ ] Verify PR metadata and CI with `gh pr view`. diff --git a/docs/superpowers/specs/2026-09-17-a2ui-research-note-design.md b/docs/superpowers/specs/2026-09-17-a2ui-research-note-design.md new file mode 100644 index 0000000..1ffce08 --- /dev/null +++ b/docs/superpowers/specs/2026-09-17-a2ui-research-note-design.md @@ -0,0 +1,24 @@ +# A2UI Research Note Design + +## Goal + +Capture a sourced research note on A2UI as a declarative, cross-platform protocol for agent-generated user interfaces. + +## Scope + +Cover A2UI's JSON component descriptions, trusted client catalogs, incremental updates, data +model/actions, transport independence, renderers, and early-preview maturity. Assess CF +relevance for agent-facing application UIs, keeping rendering and security in the client while +CF hosts agents, gateways, and backends. + +## Structure and evidence + +Create `research/a2ui.md` with the required four sections and frontmatter. Use the A2UI +repository, README, architecture, specification/version material, and renderer documentation. +Distinguish the public-preview status from a ratified standard and label CF analysis as +proposed integration. + +## Validation + +Run Devbox validation and tests, inspect whitespace/staged files, commit the note and plan on +`research/a2ui`, push, and open a PR targeting `main` without unrelated artifacts. diff --git a/research/a2ui.md b/research/a2ui.md new file mode 100644 index 0000000..bd831c3 --- /dev/null +++ b/research/a2ui.md @@ -0,0 +1,88 @@ +--- +title: "A2UI: Declarative Agent-Generated User Interfaces" +author: Ruben Koster (@rkoster) +date: 2026-09-17 +tags: [inter-agent-comms, governance, ecosystem-survey] +cf_areas: [capi, uaa] +status: draft +ratings: + platform-impact: + value: 70 + note: "A portable agent-to-client UI format could improve agent experiences without allowing agents to ship arbitrary executable UI code." + maturity: + value: 55 + note: "A2UI has functional implementations and a v0.9 protocol family, but the project identifies itself as an evolving public preview." + novelty: + value: 82 + note: "The trusted-catalog and declarative-data boundary addresses the security and portability problems of generated interactive UI." + actionability: + value: 64 + note: "CF-hosted agents could emit A2UI messages, but client catalogs, action authorization, and transport integration remain application concerns." +sources: + - https://github.com/a2ui-project/a2ui + - https://raw.githubusercontent.com/a2ui-project/a2ui/main/README.md + - https://github.com/a2ui-project/a2ui/blob/main/docs/public/concepts/architecture.md + - https://github.com/a2ui-project/a2ui/tree/main/docs/public +--- + +## Summary + +A2UI is an open-source format and library set that lets agents describe rich user interfaces +as declarative JSON rather than executable code. A client receives the description, resolves +its components against a trusted local catalog, and renders native widgets for its framework. +This separates agent-generated UI intent from client-side implementation and is relevant to +Cloud Foundry as a possible presentation protocol for agents hosted remotely. + +## Key findings + +- **A2UI separates generation from rendering.** An agent produces an A2UI response, a transport + carries it to a client, and the client renderer maps abstract components to its own widgets. + The agent does not need to know whether the client uses Flutter, Angular, Lit, React, or + another framework. +- **The payload is declarative data, not executable UI code.** Clients maintain catalogs of + trusted components such as cards, buttons, and text fields. The agent can request composition + using approved components, reducing the risk of executing arbitrary model-generated code. +- **The data model is designed for incremental updates.** A flat component representation with + identifiers and references can be generated and updated progressively, supporting responsive + interfaces as an agent conversation evolves. +- **Actions remain an authorization boundary.** Rendering a button or form does not itself + grant authority. The client and backend must authenticate the user or agent, validate action + inputs, and enforce permissions when an interaction invokes a tool or application operation. +- **Transport is separated from the UI format.** The project describes agent-to-client + delivery through channels such as A2A or AG-UI, while the renderer consumes the A2UI payload. + This allows the same UI representation to travel through different agent architectures. +- **A2UI has multiple renderer ecosystems.** The repository includes or references renderers + for different client frameworks, including Flutter-related integrations. Interoperability + depends on clients agreeing on catalog components and protocol versions. +- **Maturity is still evolving.** The repository describes the project as an early public + preview, reports a v0.9.1 production release in the v0.9 protocol family, and identifies v1.0 + as a release candidate. Implementations and specification details may change. + +## CF relevance + +Cloud Foundry-hosted agents could send A2UI descriptions to web or native clients without +embedding a particular UI framework in the agent process. A CF application could generate a +progressive form, approval card, dashboard, or action list, while the client owns rendering, +catalog safety, and user interaction. This fits a platform boundary where CF runs agents and +APIs but does not dictate the client UI stack. + +The main CF integration concerns are identity and action routing. A rendered action may invoke a +CF-hosted endpoint, MCP tool, or agent callback, so the client must preserve user/session +context and the backend must re-check authorization rather than trusting the UI description. +UAA or another identity provider could authenticate the user, while the agent identity and +conversation context are carried through a platform gateway. Loggregator-compatible events +could correlate generated UI updates, user actions, agent decisions, and resulting platform +operations. + +## Open questions + +- Which A2UI component catalogs should CF application and platform clients trust, and how should + catalogs be versioned and distributed? +- How should action authorization distinguish the human user, the agent, and the CF application + when an A2UI button invokes a privileged operation? +- Which transports should CF-hosted agents support, and how should reconnects and incremental + UI updates behave? +- How should sensitive data in UI data models be filtered, logged, cached, and isolated by + organization or space? +- Would CF benefit from reusable A2UI client components for platform operations, or should this + remain entirely an application-layer concern? From 1926ee4cf435e90d62bed107b9d62ce0df31488a Mon Sep 17 00:00:00 2001 From: rkoster Date: Thu, 17 Sep 2026 15:36:17 +0200 Subject: [PATCH 2/2] chore: refresh generated research map --- generated/research-map.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/generated/research-map.html b/generated/research-map.html index bbe5f21..4d46a39 100644 --- a/generated/research-map.html +++ b/generated/research-map.html @@ -23,9 +23,9 @@

Focus use cases

Attested Workload Authority and Mediated Tool AccessExchange platform-attested workload identity for scoped authority while credentials and outbound tool access remain mediated by the platform.Strategic decision: Decide whether CF should become the portable trust and policy layer between agent workloads and the tools they invoke.
Gap, experiments, and evidence
Current CF gap
CF issues workload identity certificates but does not exchange them for scoped tool authority, keep third-party credentials out of workloads, mediate off-platform access, or record delegation-aware audit events.
Candidate POC
Exchange a Diego instance identity certificate for a short-lived scoped token, invoke one allowed tool through a credential proxy and egress mediator, deny another, and emit attributable audit events.
Candidate RFC scope
Define workload token exchange, authority and delegation claims, credential brokering, outbound mediation and policy enforcement, audit events, revocation, and integration boundaries for UAA, routing, and service brokers.

Core

Supporting

-
Gap, experiments, and evidence
Current CF gap
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.

Core

Supporting

ResearchIdea

Platform Impact x Maturity

Emerging < Maturity > EstablishedLocal concern < Platform Impact > Platform-wide concern
Unplaced notes (0)
  • All notes are placed.
+
Gap, experiments, and evidence
Current CF gap
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.

Core

Supporting

ResearchIdea

Platform Impact x Maturity

Emerging < Maturity > EstablishedLocal concern < Platform Impact > Platform-wide concern
Unplaced notes (0)
  • All notes are placed.
 -