More and more product surfaces now sit in front of an AI agent rather than a conventional backend, and that one change quietly invalidates a set of assumptions front-end architecture has leaned on for years. An agent behaves nothing like the API a front-end was designed to talk to. A conventional API answers in tens of milliseconds with a response whose shape you already know; an agent answers in seconds, streams its output token by token, and decides the structure of that output at runtime. A front-end built around a single-page application and a REST backend assumes the opposite on every count. In advertising and media platforms the mismatch carries a direct cost: interface latency measured in milliseconds can decide whether a creative renders in time to enter an auction, so time an interface spends waiting on a model is inventory that may go unserved.
The reflex is to treat this as a connectivity problem — wire up the new endpoint, consume the stream, move on. In the systems I’ve worked on, that framing is where the effort stalls. Adapting a front-end to an AI-agent backend reaches into the transport layer, the rendering model, the build pipeline, and the accessibility layer at once, and those decisions interact. Scale, performance, and accessibility, normally budgeted against one another, end up governed by the same architectural choices. What follows is how they played out in high-load AdTech.
By Taran Goel, Senior Frontend Engineer, Amazon
Choosing the right channel for a streaming brain
The rework has to start at the transport layer, because how the agent’s output reaches the client shapes almost every choice above it. REST’s request-response model was built for short-lived calls with near-instant replies. Point it at a generative model and it falls apart: a substantive response can take several seconds, which produces timeouts, frozen interfaces, and the usual pile of workarounds, such as polling loops or multi-layer retries, that erode both the clarity of the system and the trust of the user.
WebSocket solves the perceived-latency problem by opening a persistent channel, but in this domain it’s the wrong tool for a subtler reason. When the client is mostly a passive recipient of a stream — a sequence of tokens, JSON fragments arriving from the model — you’re paying for full-duplex complexity you never use: handshakes, connection maintenance, load balancing, and the operational cost of keeping sockets healthy at scale.
Server-Sent Events sit exactly where the problem does. SSE runs over the standard HTTP stack, needs no elaborate connection setup, and delivers a native unidirectional stream from server to client. That makes it the natural fit for incremental token delivery, and, just as important in an enterprise setting, it reuses the encryption, authorization, and audit infrastructure you already have around HTTP instead of forcing a parallel stack. On the experience side, SSE is what lets you move to a streaming interface: generation becomes visible, individual regions of the screen update as content arrives, and perceived latency drops even when raw model latency does not.
Generative layouts: the front-end as interpreter
Transport is the enabling move. The architectural one is what you do with the stream. The old model hard-codes a fixed catalog of layouts — in one system I worked on, a handful of standardized ad formats lived as static configurations in the source. Every new format meant a full engineering cycle: change the code, run regression, coordinate, deploy. That paradigm quietly excludes you from auctions for non-standard slots and structurally caps how much inventory you can monetize.
The alternative is to stop shipping views and start shipping an interpreter. The front-end sends rich context to the agent, for example, slot parameters, device characteristics, the display environment, relevant user signals, and the agent returns not finished HTML but a formalized layout description in JSON. To render that safely, I built a strict TypeScript type system over the layout schema, so the client validates and interprets specifications it has never seen before rather than trusting arbitrary markup. The front-end becomes a universal interpreter of agent output instead of a bag of hard-coded screens.
That framing has a consequence teams tend to underestimate: if the front-end is going to render structures it has never seen, it also has to be the thing that refuses the ones it shouldn’t. The model may propose a layout; only the interpreter decides whether that layout is admissible. So the interpreter can’t be a parser bolted onto the stream — it has to be a pipeline with real authority over what reaches the screen.
In the version I settled on, every payload from the agent arrives inside a versioned envelope: the layout description travels with the schema version it was generated against, so the client always knows which contract to apply and old and new generation rules can coexist without a coordinated deploy. The envelope then passes through a six-stage interpreter — parse, schema validation, version resolution, policy validation, component resolution, and commit — where each stage can halt the payload before it ever influences the DOM. The stage that earns its keep is policy validation: a layout can be perfectly well-formed and still be inadmissible — a disclaimer omitted, a consent surface demoted, a slot arrangement that violates placement rules — and this is where the interpreter, not the model, enforces the constraints the business is actually accountable for. When a stage rejects a payload, the system doesn’t fail open or render whatever it can; it walks a deterministic fallback chain down to a known-good layout, so the worst case is a conservative interface rather than a broken or non-compliant one. The model’s creativity lives entirely inside a boundary the client controls.
The consequence is a step change in scale. The same client can render more than twenty thousand size-and-arrangement variations without a single source change; scaling moves to the model and its generation rules, which cuts engineering transaction cost and shrinks the surface for client-side regressions. In practice, this opened access to the non-standard slots that had been effectively invisible in the inventory, and I saw advertising revenue rise from expanded, better-filled supply, not pricing.
None of this holds together without a disciplined component vocabulary. A design system built on atomic-design principles gives the agent a fixed, reusable set of primitives to compose from — the thing that keeps thousands of generated layouts visually and behaviorally coherent. When it’s documented with clear contracts, it can also scale: the system I designed was adopted across other teams as a shared standard for visual consistency.
Performance belongs in the architecture, not in a cleanup pass
Streaming and generation buy you nothing if the shell is slow to paint, so the build pipeline has to be treated as architecture rather than as an afterthought. The starting point was replacing default Webpack parameters with an aggressive optimization scheme. Tree shaking, driven by extended static import analysis, strips unused modules and helper functions out of the final bundle — which matters most precisely where AI-generated UIs live, on top of large component libraries where dead weight accumulates fastest. Lazy loading and code splitting decompose the application into autonomous chunks, so the client fetches only the scripts the current interface region needs instead of pulling the full functional surface on first load. Server-side rendering of the critical path moves the initial render of key elements onto the server, which cuts First Contentful Paint directly.
Together these reduced client-side latency by roughly 30% in the platforms I’ve optimized, largely by lowering main-thread blocking time in the browser; the interface stays responsive, and the gain shows up most on low-powered devices and unstable mobile connections. None of it is free. An aggressive split-and-defer pipeline is harder to reason about and raises the risk of regressions from conditional loading, so it demands real performance-engineering discipline and a budget you actually enforce rather than a one-time cleanup. In AdTech that discipline pays back concretely: faster paint feeds straight into auction eligibility, which is why the Web Vitals here are worth wiring directly to the business metrics they move.
The pillar generative UIs quietly break
This is the part most teams discover too late. A generative, constantly changing interface is an accessibility problem of a different order than a static page. When elements appear, disappear, and rearrange without formal announcement, a screen-reader user loses their spatial and logical anchor entirely — navigation across sections breaks down, and the real risk is missing material information: disclaimers, consent prompts, warnings that carry commercial and legal weight.
The fix is architectural, not cosmetic. Dynamic changes have to be announced through ARIA live regions; focus points have to be predictable and stable rather than jumping with every re-render; and the content structure the agent produces has to be described for machine interpretation, not only for visual perception. The leverage is that the same JSON schema and design system that make layouts generative can carry accessibility semantics as a first-class field — so a11y scales with the generative system instead of collapsing under it.
One pattern earns its place here. Instead of showing a spinner while the model computes, a predictive interface uses prior request statistics and the model’s own confidence to render the most likely structure of the response immediately, then fills that framework as streamed content arrives. It sharply reduces perceived latency, but its quieter benefit is keeping the user’s cognitive control intact — the interface always presents a coherent, anticipated structure rather than a blank wait. That matters even more for assistive-technology users navigating a moving target.
The front-end stops being a rendering layer
Pull these together and the through-line is hard to miss: when the backend is an AI agent, the front-end stops functioning as a passive visualization layer and becomes an active environment that orchestrates requests, responses, context, and interaction state in real time. Treating that as a mere API connection is how projects end up with a frozen spinner, a frozen format catalog, and an interface that silently excludes disabled users.
The teams that will ship AI-native front-ends capable of holding up under real enterprise load are the ones who stop seeing scale, performance, and accessibility as three competing budgets and start seeing them as one architectural problem — solved once, at the layer where the user actually meets the machine.
