Should WorkWingman let an AI draw its own screens? (plain version)

Engineer version with all the detail: ../technical/a2ui-assessment.md

Google recently released something called A2UI ("Agent-to-UI"). The pitch: instead of a developer hand-building every screen, an AI agent sends a description of a form or panel as data, and the app draws it on the fly. We spent time digging into whether this is useful for WorkWingman. Short version: interesting idea, no real job for it here yet.

What A2UI actually is

Think of a form builder that an AI fills out instead of a person. The AI doesn't write real code — it can only pick from a fixed toolbox of pieces the app already trusts (a text box, a checkbox, a dropdown, a button, and a dozen or so others). It describes which pieces to use and how they connect, sends that as a block of structured data, and a small piece of code in the app (a "renderer") turns that description into an actual on-screen form. When the person using the app types something or clicks a button, that gets reported back to the AI the same structured way. It's designed to be safe specifically because the AI can't run arbitrary code — it can only ever ask for pieces from the approved toolbox.

Google built a version of this renderer for several frameworks, including one for Angular (the framework WorkWingman's frontend is built in) — that part is a genuinely good sign. But it's brand new (released this year, explicitly labeled "early preview" by Google itself), it's built for a slightly older Angular version than WorkWingman uses, and there's no ready-made toolkit for .NET (WorkWingman's backend language) — only Python and Kotlin. Using it from WorkWingman's backend would mean writing that missing plumbing by hand.

Where we looked for a fit

We checked three places in WorkWingman that sounded like plausible matches:

1. The oddball custom questions on job applications. Every company's application form asks different screening questions in a different order with different-looking boxes — sounds like exactly the "no fixed shape, AI draws the form" problem A2UI is for. But when we actually read the design for how WorkWingman handles this (on the feature-answer-mapping branch), it turns out the app already solves this a different way: it keeps a maintained list of the ~50 question types that show up across job sites (name, work authorization, "why do you want to work here," etc.) and matches each incoming question to one of those known types before it ever reaches a screen. By the time a person would see anything, it's not actually an unknown shape anymore — it's one of a small number of familiar ones, which the existing hand-built screens already handle fine. The messy, no-fixed-schema problem gets solved in the matching step, not the screen-drawing step.

2. The "judgement call" popup, where the app pauses mid-application and shows the person a short list of Claude's best guesses to pick from. This is already about as generated as it needs to be — it's a ranked list of buttons, always the same shape. Using A2UI here would just be a fancier way to draw a list of buttons that already exists and works.

3. The generated documents and study-plan screens. The words here are AI-written (a tailored resume blurb, a study plan), but the screen around those words — a box with a copy button, an approve button — never changes shape. Same conclusion: nothing here varies enough to need an AI drawing the layout itself.

The honest tradeoff

A2UI earns its keep when an app genuinely can't predict what shape a screen needs to be until the moment it's shown — a chat assistant that might answer with a table, a chart, or a form depending on the question, for instance. WorkWingman doesn't have that problem anywhere today. Its screens are hand-built, but that's mostly a feature here: this app leans hard on being predictable and well-tested (see testing), and swapping "screen a developer wrote and tested" for "screen an AI improvises at runtime" trades away exactly the thing this project has invested in, for a problem it doesn't currently have.

What we built anyway

Rather than just write "no" and move on, we built a small, disconnected demo so the claims above are checkable rather than taken on faith: a page at /a2ui-lab (not linked from anywhere in the real app) that renders one realistic job-application question form from a block of structured data, using a stripped-down, hand-written stand-in for the real A2UI message format — showing concretely what this would look like without pulling in the actual not-yet-stable library or touching any real screen. Nothing about the real app changed.

Bottom line

Not now, for either the current Playwright-based app or the PageAgent variant being researched separately. PageAgent (a different research spike) doesn't even have a user-facing screen of its own for A2UI to plug into — it's a background page-clicking agent, not something a person watches and interacts with. If WorkWingman ever grows a feature where the screen's shape is genuinely unknown until the AI decides in the moment, this is worth a second look — Google's own roadmap and the Angular renderer's maturity should both be further along by then too.