In two weeks, four companies shipped models that do one narrow thing: take some state, answer a typed question about it, and say how sure they are. TypeSafe launched Jev on September 15. Fastino followed on September 24 with GLiNER2.5-Decide, an open-weight version small enough to run on a CPU. On September 29, OpenAI put its Decisions API into limited preview on GPT-6 Luna, and the same afternoon Liquid AI announced d1, claiming the top spot on a decision index that already ranks more than thirty open models.
A day later Databricks brought it into the warehouse. Its new ai_decide function, in beta, runs Jev as a function you call from SQL over governed data, or from a REST endpoint inside an app.
When four vendors ship the same shape in a few weeks, one of them gives the weights away, and a data platform turns it into a line of SQL, that part of the stack is on its way to becoming a commodity. For anyone building generative UI, the question is no longer which model to use. It is what you hand the model, and the launch coverage says almost nothing about where that comes from.
Personalization was never short of ideas
For a decade, personalization has mostly meant rules and segments. Someone writes a condition, a nightly job sorts visitors into groups, and the page shows variant B to the group that qualifies. Teams did not settle for that through lack of imagination. They settled because two things were expensive. Rendering a different page for every visitor meant designing every variant in advance. Deciding which one to show meant a hand-written rule someone had to maintain, or a model someone had to train, serve and watch.
So teams made few decisions, made them in advance, and made them about groups instead of people. Most of what gets called personalization today is segmentation with a better name, running on what a visitor did yesterday.
The render side is already solved, in the open
Generative UI removed the first cost, and the frontend community did it without a single enterprise contract. Vercel’s open source json-render lets you define a catalog of components with typed schemas, has a model return a spec that uses only those components, and renders it in React, Vue, Svelte or React Native. The model never writes markup, so the page cannot contain anything you did not ship.
It is not alone. Google’s A2UI is an open spec for describing an interface that each platform renders natively. MCP Apps lets a tool return an interface as well as data. CopilotKit created AG-UI, an open protocol that carries an agent’s state and actions into the frontend and supports those specs. In September Thesys released OUI-1, open weights for a model that writes screens from a developer’s approved components and runs on a single workstation GPU.
That should worry anyone still selling a proprietary page builder with a personalization tab. Rendering is free, typed and portable.
These tools are also deliberately neutral about what the model knows. json-render renders whatever spec it is handed. AG-UI carries whatever the agent sends. That is the right design, and it leaves exactly one input open: the state.
Then the deciding got cheap
Decision models remove the second cost. Each slot on the page becomes one typed question: which section leads, which proof to show, which objection to answer. You write the allowed answers ahead of time, every answer comes back with a confidence, and a low confidence is a reason to keep the default layout rather than gamble. The call is quick and cheap enough to sit on the render path, which was never true of a general chat model.
Distribution arrived as fast as the models did. Within days of Jev’s launch, Vercel, Cloudflare and LangChain had wired it into their stacks, so developers reach it through tools they already use.
Put the two together and the old excuse is gone. You can afford a real decision, for this visitor, on every render, and a page rendered to fit it.
The decisioning premium is over
The packaged suites turned the old scarcity into a business. Dynamic Yield, Optimizely, Adobe Target and their peers sell the decision as the product, bundled with a visual editor, an experiment suite and a recommendations catalog, on enterprise contracts priced for a problem that looked hard. For a long time it was hard, and the price reflected a data science team nobody else had.
The last two weeks repriced it. A typed decision about one visitor is now an API call from four vendors, a free download from one of them, and a function in a Databricks query. A developer can try any of them this afternoon without talking to sales. If four companies can ship the deciding in a few weeks, the deciding was never the part that justified an enterprise contract.
What the suites still own is the workflow around the decision: the editor, the approvals, the reporting a marketing team lives in. That is worth paying for. It is also not what most of those contracts were sold on, and buyers renewing this year should ask which of the two they are paying for. Teams that keep a suite will still need to hand it what the visitor is doing right now, and Signals can feed it.
Every guide stops at the same sentence
Read the guidance that came with these launches and a pattern shows up. TypeSafe’s own docs say accuracy falls as the state fills with detail the question does not need, so filter in code first. A community guide to the Decisions API gives the same advice and names what a good state holds for a routing call: the ticket, the account tier, and recent events.
Recent events is where every guide stops. None of them say where those events come from, how current they are, or how they get from a click to the model before the page renders. That is the hard part, and it is the part the launch threads skip while they argue about benchmarks and calibration.
Tealium’s post on what Jev makes possible shows why it matters. A visit to a cancellation page says little by itself. Yesterday’s support message and a drop in usage are what give it meaning. The same holds on any page. Two visits to pricing are ambiguous. Two visits to pricing after reading the security page, and skipping the code sample, are a question about cost and risk. A model that sees only the route and the props cannot tell those visitors apart, however well it scores on an index.
The benchmarks measure the wrong variable
A decision index scores models on fixed states. That is the right way to compare models, and it hides the variable that matters most in production. On a live page, the state is what changes, and it changes on every click.
Our view is that a strong model reading last night’s segment will lose to an ordinary model reading the current session, for most of the decisions a page makes. That is testable: hold the model and the questions fixed, vary only how fresh and complete the state is, and measure what the page gets right. That benchmark would say more about generative UI than another point on a leaderboard.
The model is the part you will swap
Decision models will keep getting better and cheaper, and you will probably change yours more than once. The state is the part you will live with for years, so it should not be tied to whichever model is winning this quarter.
In August, Hightouch argued that context should stay in systems you own and be usable by any model. We agree with the principle. Where we would add something: brand rules, campaign history and past orders are the slow-moving half of context. The session is the half that goes stale in a minute, and it is the half a page composing itself needs most.
Databricks’ launch makes the split visible. ai_decide decides over governed data, which is exactly where history belongs: reviews to tag, tickets to route, past orders to score. For most teams, though, this visit reaches those tables after the page it should have shaped has rendered. Both kinds of decision are useful. Only one can change what this visitor sees next.
Where Signals fits
Signals is real-time customer context. It answers one question for your app, and for the model behind it: what is this visitor doing right now? It does three things.
- It collects. Add a Snowplow SDK to your web, mobile or server app and behavioral events start flowing in, validated on the way, under your own consent settings. There is no event stream to build first.
- It computes. You describe what you want to know about a visitor, such as how often, how recently and in what order. Signals keeps each answer current as the events arrive.
- It serves. Your app reads those answers as JSON while the visitor is still on the page. Signals can run in your own cloud, so the data stays there.
What Signals does not do is decide or render. The model you choose does the choosing, and the renderer builds the page from a catalog only you can add to. Signals hands the model the state it decides on. Because that state is plain JSON, it reads the same whichever model you call next, or a switch statement.
See it working
A storefront with no page designed in advance. The shopper browses, Signals keeps the session, Jev picks what goes in each slot, and json-render renders it from the catalog.
The generative UI page shows how it is wired, with the prompt that has your coding agent build the same thing. The read and the model call, as real code, are on the System One models page.
Where this goes
Look at the three pieces of a page that composes itself. Rendering is open source. The deciding is an API call or a download, and the vendors who charged most for it are about to find out how much of their price was the decision. What stays scarce is knowing what this visitor is doing right now, current as of this click and in a shape a model can read before the page renders.
The teams that get generative UI right will not be the ones with the best model. They will be the ones whose model can see the session.
To see what Signals computes from your own traffic, start free. The free tier runs on the real engine, needs no card, and shows an attribute updating against your own traffic in the first session.