A2UI
An agent-to-UI protocol: the model emits a description of the screen, and the client renders it from a component catalog the host declares. No markup or script crosses the boundary.
From data to mini-app.
Enterprise systems provide the data. IT defines the building blocks. AI assembles them into complete, governed workspaces — instantly.
[01]
AI must not write code across a trust boundary.
Within twelve months, Google, Vercel, and OpenAI and Anthropic together arrived independently at the same architecture: the model assembles a screen from a trusted catalog of typed components — and the client keeps control of execution.
json-render
UI as JSON, drawn by trusted client components. The model picks and configures components from a fixed set — it never ships code that runs.
MCP Apps
Interactive interfaces inside chat, declared over MCP. The server offers components; the client stays in control of what actually renders.
“A code injection attack waiting to happen.”
This is the architecture B1 is built on — and has been running in production since before it had a name.
[02]
How it works: From data to mini-app.
Enterprise Integrations
Enterprise Apps
SAPSalesforceServiceNowDynamics 365HubSpot+ more
Databases
PostgreSQLpgvectorOpenEdgeProgress ABLMulti-DB+ more
API Protocols
RESTOpenAPIGraphQLWebhooks+ more
Auth / Identity
OAuth2Azure ADOIDCSAMLJWTBetterAuth+ more
What IT controls: Every building block.
IT defines which data sources, UI components, and actions exist as approved building blocks. AI assembles exclusively from these blocks.
Structured Data. Not Code.
Every block is a versioned, auditable blueprint — declarative and composable by AI.
What IT controls:
Every building block.
IT defines which data sources, UI components, and actions exist as approved building blocks.
No UI hallucinations
No uncontrolled data access
No shadow IT
Guardrails are structural
Building Blocks
Visual Blocks
50+ typesFormTableChartDashboardMapGantt...Data Blocks
14 typesQuerySchemaConnectorEntityFilter...Logic Blocks
20+ typesValidationWorkflowActionBPMNCode...AI can only assemble from pre-approved blocks
Structured Data.
Not code.
Every block is a declarative blueprint — versioned, auditable, and composable by AI.
Version-controlled
Fully auditable
Declarative definitions
Composable by AI
type: DataObject
source: PostgreSQL
fields: [name, rev...]
version: 3.2 ✓
source: PostgreSQL
fields: [name, rev...]
version: 3.2 ✓
The blueprint is the app
AI selects & assemblesPicks the right blocks for your task
Customer Overview
Mini-App
Sarah Johnson
Head of IT · GreenLeaf Inc.
DATA
Revenue
€ 2.4M
Status
Active
Recent Orders
VISUAL
ORD-1842€ 12,400
ORD-1837€ 8,200
Trigger Follow-up WorkflowLOGIC
CI-compliantLive dataAudit-logged
The Employee's Mini-App
Ready to use. No code. No IT ticket.
Every employee gets instant apps
because every block is pre-approved.
AI doesn't write code. It assembles from building blocks that IT has explicitly permitted. The guardrails were set before the first prompt — that's what makes instant delivery safe.
[03]
A sales manager builds a tour-planning app.
Speed and control are not a trade-off here — they are two lanes in the same pipeline. One request, two versions, and exactly one place where a human has to look.
Version 1
Same day
“Plan my customer visits on a map, grouped by region.”
Everything this needs already exists in the catalog. The agent composes it: the customer data source, a map, a filter form, the route logic. Data access and permissions arrive with the blocks — they are not decided again per app.
Composer lane → auto-merge
Live the same day. Governed, because it could only be built from governed parts.
Version 2
Needs something new
“Also show live traffic and visit history from our field-service tool.”
That data source does not exist yet. So a coding sub-agent with repository access builds the connector and its data-source object — real code, in a real pull request, against the same CI gates a developer faces.
Type-author lane → IT review
IT reviews the diff and approves. The connector joins the catalog.
And then
Composition resumes
The sales manager's agent finishes version 2 back in the composer lane. The new connector is now part of the catalog — so the next team that needs field-service data is not waiting on anybody.
Composer lane → auto-merge
The catalog grew by one governed increment, through use.
Speed wherever composing existing blocks is enough. A human gate exactly where code enters the system — decided from the change itself, not from a policy document.
[04]
There is no ceiling.
Everything so far describes what happens when composing existing blocks is enough. When it isn’t, developers drop into an ordinary engineering platform — the same repository, the same pull requests, the same test gates. The governed path never removes the option to write code.
A standard stack
Vue 3 and Nuxt on the front, NestJS and PostgreSQL behind it, Tailwind for styling. There is no proprietary language to learn — developers extend the platform with the tools they already use every day.
Four ways in
Blueprints and tenant overlays for configuration · custom components for new object types · data adapters for new systems · backend services for everything else. Each one is a documented extension point, not a workaround.
Your repository, normal pull requests
Blueprints export to JSON and live in the repository next to the code. Changes ship as pull requests on protected branches, semver-tagged and versioned — the application definition is a file you own, not a row in somebody else’s database.
The same gates for people and agents
Jest unit tests, Playwright end-to-end runs with visual diffs, ESLint. A change authored by an agent clears exactly the checks a change authored by a developer does. There is no fast lane around the tests.
Developers go as deep as they need to — and what they build lands in the catalog as safe building material for everyone else. The platform grows through the work people were already doing.
[05]
Nothing was generated, so nothing decays.
The expensive part of internal tools is not building them — it is owning them afterwards. Every generated app is a codebase somebody inherits, and every framework upgrade is a migration wave. A blueprint has neither property.
The app is a description, not a codebase
A blueprint is a typed object graph: screens, data, rules and the links between them. Nothing is generated into files that somebody then owns — there is no output to review, refactor, or eventually rewrite.
Catalog and renderer ship together
The component catalog and the rendering engine are one deployment unit. A blueprint can never reference a component the engine does not know, so the version drift that fragments other host-rendered UI formats has nowhere to start.
Upgrade once, everything moves
Improve the renderer and every application improves with it — a better component, an accessibility fix, a new theme. No per-app UI migrations, and no framework-version debt piling up project by project.
Which makes the honest answer to “who maintains all these apps?” nobody in particular. No generated code to inherit, no migration wave to schedule — the two costs that make internal tools expensive long after they were cheap to build.
[06]
Built on proven technology.
3
Live enterprise applications
1,500+
Users in production
1,000+
Screens generated
5 yrs
Continuous production
Production data from the B1 Developer Framework, the technological foundation of the platform. It is proof that the architecture carries real enterprise load. It is not usage, revenue or customer validation of the new B1 product.
[07]
The full demo — both sides.
Eight and a half minutes, unedited in substance: a sales rep describes the app they need and watches it get built on live Salesforce data — then the same platform from the IT side, where every object is visible, a policy change is stated in one sentence, and the migration stops at the app that needs a human. The pipeline above, from both seats.
Want to see it in action?
Bring a use case from your own systems. We will walk through what the pipeline would build and how IT would govern it.