Három építészeti minta a generatív felhasználói felületekhez: Controlled, Declarative, Open-ended

A frontend korábban statikus volt: a tervezők lerajzolták, a mérnökök megépítették, a felhasználó pedig azt kapta, ami kiszállt. 2026-ban a helyzet megváltozott: az üzenetekre válaszoló agentek valós időben rajzolnak és renderelnek UI-elemeket is — nem csak leírják, mit kellene látni.

A generatív UI az a réteg, amely lehetővé teszi, hogy az agentek ne csak leírjanak, hanem meg is jelenítsenek. Három protokoll és három általános építési minta alakult ki; a választás jelentősen befolyásolja az architektúrát és a skálázhatóságot.

A protokollréteg röviden

• MCP: eszközök és agentek összekapcsolása.
• A2A: agentek közötti kommunikáció.
• AG-UI: agent és felhasználó közti streaming réteg; ezen fut minden: eszközhívások, A2UI sémák, MCP App események, állapotdelta-k. Az AG-UI általában SSE-n (Server-Sent Events) fut: az állapot mindkét irányban áramlik ugyanazon a streamen, így a felhasználói módosítást az agent azonnal látja, az agent módosítása pedig a felhasználó előtt jelenik meg.

A2UI a Google specifikációja arra, hogy az agentek UI-t sémaként bocsássanak ki; CopilotKit gyakorlatban is szállítja. A fejlesztők általában nem írnak saját parsert erre: CopilotKit klienskönyvtár dekódolja és kezeli a streamet.

Három gyakori minta (és amit összekevernek velük)

A spektrum a nagyobb kontrolltól a nagyobb rugalmasság felé halad:

1. Controlled (vezérelt): a frontend birtokolja a UI-t — előre megépített komponensek közül az agent kiválasztja, melyik jelenjen meg.
2. Declarative (deklaratív, A2UI): az agent sémát bocsát ki; az alkalmazás a sémát leképezi renderelhető komponensekre.
3. Open-ended (nyitott): az agent nyers HTML-t vagy teljes vásznat ír; az alkalmazás sandboxolt módon renderel.

Minden 2026-os Gen UI-keretrendszer ezek valamelyikén vagy a spektrum mentén helyezkedik el. A különbség nem csak kozmetikai: minden minta más-más módon törik meg a rendszert nagy skálán.

1. Controlled: a frontend a tulajdonos

Ez a legtöbb csapat kiindulópontja — és sokaknál itt akad el a projekt.

Lényege: előre megírsz egy React (vagy más) komponenst, hozzárendelsz egy eszköznévhez, az agent pedig meghívja az eszközt; a komponens inline renderel a chatben a paraméterekkel mint props. A frontend egy hookot regisztrál, az agent nem igényel plusz kódot.

Előnyök:

• A design rendszered marad irányító: pixelpontosság, konzisztens stílus.
• Egyszerű a hook-szintű integráció (például CopilotKit runtime-on keresztül).

Hátrányok:

• Token-költség: minden komponens definíciója (JSON séma és leírás) bekerül az agent kontextusába még a felhasználói kérés előtt. Egy tipikus eszközleírás ~400 token; 25 komponens ~10 000 token minden körnél — ez rendszeresen költséget jelent.
• Az agent tévesen választ komponenst, ha több leírás túl hasonló. 15–25 komponens után gyakori a hibaválasztás.

Mikor használd:

• Tíz vagy kevesebb magas értékű, pontos UI-folyam esetén.

Mikor nem:

• Ha a use-case-ek száma lineárisan nő; ha 25+ komponensre van szükséged, a kód és a token-terhelés problémát okoz.

Megoldások:

• Megosztott állapot esetén érdemes agent-oldali eszközt írni (például Pythonban), hogy az agent írja a session state-et, a frontend pedig feliratkozzon a változásokra — így nem kell minden interakciónál új lekérés.

2. Declarative (A2UI): az agent sémát ad vissza

Ez az a minta, amelyre a legtöbb éles agent-alkalmazásnak szüksége lesz.

Lényege: az agent JSON-sémát (A2UI) generál, amely leírja a komponensfát és a hozzátartozó adatmodellt. Az alkalmazás rendelkezik egy katalógussal (catalog) — a katalógus komponensdefiníciói Zod szerű sémákkal határozzák meg a propokat, a frontend rendererei kapcsolják a katalógus-elemhez tartozó React komponenseket. Az agent csak kitölti az adatot.

Működés:

• Az agent három műveletet ad vissza sorrendben: surface létrehozása, komponensfa feltolása, adatmodell frissítése. A komponensfa lehet fix (te írod előre) vagy dinamikus (egy második LLM állítja össze per turn a kontextus alapján).

Előnyök:

• Token-költség független a katalógus méretétől: az agent csak egy funkciót lát, így a komponenskönyvtár növekedése nem növeli a turn-onkénti tokenterhelést.
• Platformfüggetlen (mivel JSON), és rugalmasan bővíthető.

Hátrányok:

• Az LLM tulajdonolja az elrendezést: futásonként változhat a megjelenés az adott katalóguselemek keretein belül. Ha pixelpontosság vagy jogi/marketing szövegek pontos elhelyezése követelmény, ez a minta nem optimális.

Mikor használd:

• Sokféle kártya, widget vagy űrlap van; a long tail problémáját kell kezelni; token-költségérzékeny vagy.

Tipikus hibák:

• Katalógus azonosítók (CATALOG_ID) nem egyeznek a frontend és az agent oldalon — ilyenkor a frontend fallbackre ugrik és a várt egyedi komponensek helyett generikus megjelenést kapunk.

3. Open-ended: nincs katalógus, nincsenek szabályok

A legvégső ellenkezője a Controlled-nek: sem katalógus, sem séma; az agent szabadon írhat UI-t.

Két alvonal létezik:

• MCP Apps: az MCP szerverek teljes vásznat adnak az agentnek (például Excalidraw-szerű rajzolós felületek). CopilotKithoz jár MCPAppsMiddleware, ami egyszerűsíti az MCP kliens implementálását.
• Sandboxed HTML: az agent nyers HTML-t generál, amit a kliens sandboxolt iframe-ben renderel. A runtime regisztrál egy HTML renderelési eszközt és szolgáltatja az agentnek.

Előnyök:

• Maximális rugalmasság: az agent teljes kontrollt kap, és kreatív, komplex vizualizációkat hozhat létre.

Hátrányok:

• Márka- és stílisztikai inkonzisztencia: az agent kinézete naponta változhat, ha nincsenek szigorú stílusinstrukciók; a promptban megadható szabályok segítenek, de nem garantálnak teljes konzisztenciát.
• Biztonsági és működési problémák: iframe sandbox beállításai gyakran túl szűkek (gátoltak a gombok és űrlapok) vagy veszélyesen engedékenyek (allow-same-origin), ezért ajánlott korlátozott engedélyeket adni (például allow-scripts és allow-forms, de soha allow-same-origin).

Mikor használd:

• Egyszeri, eldobható vizualizációkhoz vagy kísérleti sandbox-hoz. Nem javasolt alapfelületnek.

Hogyan válasszunk mintát?

Elsődleges döntési fa:

• Van a designernek pixelpontos mockupja az adott folyamathoz? → Controlled.
• Több tucat kártya vagy widget várható? → Declarative.
• Egyetlen alkalmi vizualizáció, amit a felhasználó soha többet nem lát? → Open-ended.

Ha bizonytalan, a javasolt alapértelmezett: Declarative. Később importáld a legfontosabb, top 3 flow-t Controlled módba. Open-endedet sose válassz alapértelmezettnek.

Ha már élő rendszered van: számold meg a render eszközöket; ha több mint ~15 van, valószínűleg Controlled jellegű falba ütközöl. Érdemes még a héten A2UI-t bekötni.

Összegzés — három fogadás

• Controlled: a csapatra fogad; előre épített komponensek, pixelpontosság, költséges 25+ komponensnél.
• Declarative: a séma a szerződés; az agent kitölti az adatot; skálázódik laposan.
• Open-ended: a modellre fogad; nyers HTML vagy teljes vászon; jó eldobható dolgokra, törékeny, ha ismétlődően kell működnie.

A valódi hiba nem az, hogy rossz mintát választanak, hanem hogy nem tudatosan választanak. Sok csapat a framework alapértelmezése miatt kerül Controlled módba, majd később váltás nélkül kiderül, hogy skálázási gondjaik vannak.

Referenciák és további források

A szerző a CopilotKit és AG-UI köré épített tapasztalatait írta le, és a Generative UI Agents mintákat az awesome-llm-apps gyűjtemény Generative UI Agents szekciójába helyezte el referenciaként. A szerző követhető a @Saboo_Shubham_ Twitter-címen további anyagokért.

A cikk célja, hogy segítse a csapatokat tudatos döntés meghozatalában: melyik minta illik az adott problémára, és milyen kompromisszumokkal jár a választás.

body_en: ## Three patterns for generative user interfaces Frontends used to be fixed: designers sketched them, engineers built them, users received whatever shipped. By 2026 that changed — agents now generate UI in real time from user requests, producing tables, cards or full canvases instead of just textual descriptions.

Generative UI is the layer that enables agents to stop describing and start showing. Three protocols support this space (MCP, A2A, AG-UI), and three architectural patterns have emerged for how apps should consume agent-driven UI. Which pattern you pick matters for token costs, consistency, and scalability.

The protocol stack

• MCP connects agents to tools.
• A2A connects agents to each other.
• AG-UI is the streaming layer that carries tool calls, A2UI schemas, MCP App events and state deltas over SSE. State flows both ways on the same stream: user edits are visible to the agent, agent mutations show up to the user.

A2UI is Google’s spec for agents emitting UI as JSON schema; CopilotKit ships a runtime that decodes the AG-UI stream and handles A2UI.

The three patterns teams often confuse

The spectrum runs from tight frontend control to maximum agent flexibility. Every Gen UI framework sits somewhere on this line.

1. Controlled: Pre-built components live in the frontend; the agent selects which one to render.
2. Declarative (A2UI): The agent emits a schema; the app maps schema nodes to components from a catalog.
3. Open-ended: The agent produces raw HTML or drives a canvas; the app renders it in a sandbox.

Each pattern is an architectural choice — not merely a cosmetic one — and each fails differently at scale.

Pattern 1 — Controlled: frontend owns the UI

Most teams start here. You pre-build components and register them (for example via a hook) with the runtime. The runtime advertises the tool over AG-UI; when the agent calls the tool, its arguments stream down and your component renders inline in chat.

Pros:

• Design system stays in control: consistent visuals, pixel precision.
• Simple integration: one frontend hook, no agent code required for the UI.

Cons:

• Token tax: every registered component description and JSON schema enters the agent’s context before the user asks anything. A typical tool description is ~400 tokens; 25 components are ~10,000 tokens per turn.
• Agent chooses the wrong component when definitions overlap semantically — common after ~15 tools.

When to use Controlled:

• Ten or fewer high-value flows where design precision matters.

When not to:

• If your codebase and component count grows linearly with use cases; 25 components mean 25 tool definitions in every agent turn.

A common mitigation is to move shared state agent-side: have an agent-side tool write session state and let frontend subscribers re-render without an extra LLM call.

Pattern 2 — Declarative (A2UI): agent emits schema

This is what most production agent apps eventually need. The agent emits JSON that describes a component tree and a data model. Your app maintains a catalog that maps catalog component definitions (with Zod-like prop schemas) to renderers. The agent typically issues operations like create_surface, update_components, update_data_model.

Pros:

• Token economics scale: catalog size doesn’t add to token cost per turn.
• Framework-agnostic: it’s just JSON and can be rendered by React, Svelte, Flutter, etc.

Cons:

• The LLM owns layout decisions within the catalog’s constraints. If you need exact pixel placement or legal/marketing text in precise locations, Declarative may be inappropriate.

When to use Declarative:

• You have more use cases than time to pre-build. You care about token costs past prototyping. You need to scale a long tail of card and widget types.

What breaks:

• Catalog ID mismatches between agent and frontend cause silent fallbacks to a basic catalog; the custom card won’t appear and there may be no console error.

Pattern 3 — Open-ended: no catalog, no rules

This is the opposite extreme: full agent control.

Two sub-patterns:

• MCP Apps: an MCP server exposes canvases the agent drives (Excalidraw-like examples). CopilotKit includes MCPAppsMiddleware to integrate MCP Apps servers with agents.
• Sandboxed HTML: the agent writes raw HTML which the client renders inside a sandboxed iframe. The runtime registers an HTML rendering tool and injects it to the agent.

Pros:

• Maximum expressiveness; the agent can create novel visuals and interfaces.

Cons:

• Brand inconsistency: without strict style rules in the agent instruction, rendered UIs can vary wildly. Prompted style constraints help but don’t guarantee uniform brand.
• Operational fragility: iframe sandbox flags can block expected interactions, or be too permissive. Use allow-scripts and allow-forms, but never allow-same-origin.

When to use Open-ended:

• One-shot, disposable visualizations and sandbox experiments. Never as your primary surface.

How to pick

Decision guidance:

• Designer has pixel-perfect mockups for the flow? → Controlled.
• Dozens of card types or widgets? → Declarative.
• One-shot disposable visualization? → Open-ended.

If unsure, default to Declarative. Move a few top flows to Controlled for precision. Avoid making Open-ended your default.

If you’re already shipping and unsure which pattern you used, count render tools: past ~15 suggests you’re in Controlled and approaching the scaling wall; start wiring A2UI.

Three bets

• Controlled bets on pre-built UI and the team’s ability to own visuals; it becomes expensive beyond ~25 components.
• Declarative bets on a schema contract; it scales flat as your catalog grows.
• Open-ended bets on the model’s output; it’s good for throwaway experiences but brittle for repeatable surfaces.

The real mistake is not choosing explicitly. Many teams end up in Controlled because their framework defaults to it, then hit a wall and drift toward Open-ended demos without making a conscious architectural decision.

Pick on purpose: Controlled for exact flows, Declarative for the long tail, Open-ended for disposable experiments.

Resources

The article’s author points to example templates and an "Generative UI Agents" section in awesome-llm-apps as references for implementing all three patterns. Follow @Saboo_Shubham_ for more updates.