Maelstrom: The interface framework for the age of AI

The interface framework for the age of AI

“When I was a kid, the future was different.”

— Frank Walker, Tomorrowland (2015)

Across several projects, we kept running into the same frustration: models were getting better at understanding complex requests, but using them still meant typing into a box and reading paragraphs of text. The technology was improving, but the experience often wasn’t.

Text itself wasn’t the problem. As developers, we love terminals. But even there, visual feedback matters, whether it’s a red error message or a terminal interface with buttons and charts. Some things are simply easier to understand visually. So why did our AI features so often rely on text alone?

We already knew how to make complex information usable through charts, forms, maps, and controls. Yet we were asking people to read explanations of things the application could show them directly. The model understood the request, but users still had to turn its answer into action: find the right view, apply the filters, open another panel, and arrange the information they needed.

That gap was the spark behind Maelstrom. We wanted applications to respond not just with answers, but with interfaces people could use to act on them. We spent almost a year shaping the idea before we began building in earnest.

Consider a developer investigating an incident:

“Put the errors from last week next to our deployments.”

Suppose the application already has an error view and a deployment timeline, with filters available to the model. The application could place those views side by side and set both to the requested period. The developer would get a workspace for investigating the incident, not instructions for assembling one.

We call this intent-driven UI: the user describes what they need, and the application brings together the relevant components and capabilities to help them do it.

Why build on existing components?

Letting a model generate an interface offers another possibility. Instead of describing a chart or a form, it can produce something visual. That freedom can be useful when exploring an idea without an established interface.

But we were starting with existing applications. Their components already embodied domain expertise, business logic, validation rules, and design decisions. Some of that knowledge was documented; some lived only in the people within an organization.

Asking a model to recreate those interfaces risked losing that context. It could invent behavior, miss constraints, or produce interactions poorly suited to the task. Generating and refining those interfaces could also add latency.

We wanted to build on the knowledge of the designers, engineers, and product teams who had shaped the experience—not ask a model to reconstruct their decisions from scratch.

Generating an interface does not have to mean inventing it from scratch. A2UI, for example, provides a protocol for describing interfaces that clients render using a catalog of developer-designed components. That work overlaps with our interests: there are more possibilities than a choice between text-only assistants and models inventing arbitrary interfaces.

Our question became more specific: how can AI coordinate an existing workspace, its component arrangements, states, and actions, without taking over the design of the components themselves?

Maelstrom

Maelstrom is a library for building interfaces that adapt to what people are trying to do. You design the components and define their capabilities; AI brings them together, arranges the screen, and invokes the actions you expose.

These components are called Vessels. For each one, developers define:

• Purpose: What the component does, so the model can decide when to use it.
• States: The states the component supports and that the model can select.
• Size requirements: How much space the component needs and how it can be resized.
• Available actions: The operations the application explicitly allows the model to invoke.

The model uses these definitions to choose and arrange Vessels, resize them, change their states, and invoke available actions. Your application’s code determines how those changes and actions are carried out.

The boundary is deliberate. You define the pieces and what they can do; AI coordinates them around the user’s intent. Maelstrom does not replace your product’s design or business logic.

This is the space we want to explore: situations where the components already exist, but the useful combination depends on what someone is trying to do. Choosing what to display is only part of it. We’re also focusing on how those components share the workspace and which operations are available within them.

This also explains the name. We imagine the components as Vessels in a sea of possibilities. Each is deliberately built for a purpose, but they can form different arrangements. For us, Maelstrom evokes the force bringing those Vessels together around the user’s intent.

Join our private beta

We are inviting teams into Maelstrom’s private beta to test the library against real product requirements. We want to hear about bugs, rough edges, and missing capabilities.

Dense developer tools, analytics applications, and React-based products whose features are hard to discover seem like promising places to start. In those environments, we want to test whether arranging existing capabilities around a user’s intent can meaningfully reduce the effort required to use them.

We suggest starting with one workflow. Identify a situation where users know what they want but spend too much effort getting there. Turn a handful of relevant components into Vessels, describe their states and actions, and observe what happens.

Does bringing the components together actually help? What happens when the model moves something the user is still working with? Can developers understand an unexpected transition? How should users correct a misunderstood request, and which actions need confirmation?

Declaring available capabilities doesn’t mean the model will always choose the right ones. These questions matter more to us than whether the interface looks impressive in a demo.

Some workflows will be better served by a fixed arrangement and familiar navigation. We want to understand where adaptation helps, not assume every screen needs it.

Bring a workflow to explore. Join the beta community on Discord .