Your product has a second audience.

Because a chatbot answers and generative UI acts. A text box bolted onto a dashboard asks the user to describe, in prose, something they could have clicked, and then hands back a paragraph they have to act on themselves, so it loses to the existing UI on every task the existing UI already does. Generative UI assembles the interface around the request: ask for churn by cohort and you get the chart, the filter and the export button, wired to the same data layer and the same permissions as the rest of the product. The useful test before we build anything is whether the answer needs a component or a sentence. Jobs that end in a decision need components. If a job genuinely ends in a sentence, we will tell you a chat surface is the right call and keep it small.

The honest answer is that the choice depends on where your product already is, not on which library is loudest this quarter. For most React codebases the default is the Vercel AI SDK with AI Elements for streaming and tool-use surfaces. assistant-ui and CopilotKit are strong when you want a maintained in-product assistant shell over your own data. Google A2UI is the one to look at when the same generative surface has to render on more than the web. MCP Apps is the right primitive when the interface has to live inside an assistant rather than inside your product. We keep the model layer behind an interface of your own and the rendering inside your existing design system, so the primitive stays a swappable dependency instead of an architecture decision you have to live with. This part of the stack rotates fast, and we design for that.

No rewrite. We integrate alongside what you run now, in your repo, in your components. The pattern is consistent: scope one user-facing job, pick the surface that fits it (generative UI, in-product agent, voice, or an inline action), wire the model layer with structured output so the response is typed rather than parsed out of prose, connect your data through MCP tools with your existing auth and permissions, and put observability and evals in from the first commit rather than after the first incident. Scoped builds are fixed price against a defined scope, and the first production behavior is deliberately small enough to judge on real usage instead of a demo.

Ranking and being usable by an agent are different problems, and the second one is a Frontend job. Search ranks documents for a human who will click through and then operate your interface. An agent does not operate your interface. It needs to resolve what you are as an entity, read the page without executing a click-heavy flow, and then find a structured action it can actually call. A site can rank first and still be unusable to an agent, because the action layer is missing entirely. That layer is what WebMCP and MCP servers provide: safe, typed tools on top of the app you already have, rather than an agent guessing at your DOM. The discoverability work (extractable answers, resolvable entity, structured data, retrieval-bot opt-ins) is the readable half. The tools are the operable half. Start with a free AgentReady scan to see which half you are missing.

Less than a replatform, more than a schema tag. The protocol stack settled during 2026: the Universal Commerce Protocol covers how an agent discovers products and transacts with a merchant, the Agent Payments Protocol carries the authorization underneath it, and both lean on MCP for tool access. What that asks of your Frontend is a product catalog an agent can read without rendering your grid, agent-callable tools for the steps that matter (availability, cart, checkout), and a checkout flow that can be completed by a caller who never sees your UI, without weakening it for the humans who still click. We build those surfaces on top of your existing commerce backend. The reason to look at it now is that this audience does not show up in your funnel as a bounced session. It does not show up at all.

By treating it as a product surface with a failure mode, not a demo with a disclaimer. Structured output with a schema, so a malformed response is a caught error rather than a broken render. Evals on the behaviors you actually care about, written before launch and run in CI, so a model or prompt change that degrades quality fails a build instead of surprising a user. Tracing on every run, so an unexpected answer can be reproduced instead of argued about. Explicit fallbacks and confidence signals in the interface, so the product degrades honestly when the model is unsure. And a scope where the model handles the part it is good at while your existing logic keeps the parts that must be deterministic. Guardrails are what make AI features safe to leave running.

Fixed price against a defined scope, always. You get the scope, the deliverables and the price before the work starts, and we do not bill hourly. Builds are shipped either by a scoped project team, by senior engineers embedded in your team on a monthly retainer with a six-month minimum, or through a Frontend Delivery Factory already installed on your codebase, which is usually the cheapest route once the factory exists. Agentic-web capability is the standard bar for our engineers rather than a premium tier, so it is priced into the normal engagement and not quoted as an add-on.

They point in opposite directions and the test takes one sentence. The Factory changes how your organization ships: it is delivery infrastructure installed on your codebase so people outside the Frontend team can merge production Frontend. Frontend AI changes what your product does for the people and agents using it. If your problem is that good ideas queue behind a small Frontend team, you want the Factory. If your problem is that your product needs to do something it cannot do yet, you want Frontend AI. Teams often arrive through one and add the other later, and a factory already running is the fastest way to ship the second. What we will not do is sell you one while describing the other.