IT defines the data access, actions and components AI can use. Teams describe what they need: an app, an agent, or a conversation with their business data. B1 brings it together, with governance built in.
Explore a question, build a reusable tool or give an agent a defined task. Start with the work you need to do.
These are three alternatives, not a required sequence. Agent suggestions remain drafts for human review.
Ask questions about business data and explore the results in interactive views.
Review open opportunities in a table or map.
A drawn conversation returning the three open opportunities as a table with stage and value, and the same three marked on a map.
Describe the tool your team needs. Assemble it from approved components and actions.
Turn a recurring opportunity review into a reusable view.
A drawn conversation returning a reusable opportunity review: summary figures, the opportunity table and a review note, assembled from approved components.
Give an agent a defined task using the data and actions IT has made available.
Prepare suggested next steps for selected opportunities, for a person to review.
A drawn conversation returning an agent draft — the task, two of the three opportunities in scope, the data and actions the agent may use, and two suggested next steps left for human review.
The homepage example shows the top three opportunities by value alongside a separate chart of all open opportunity value by stage. Its chart includes €60k in Closing beyond the three table rows. The three mode examples above use only their three named opportunities, totalling €515k; their agent draft covers two of those three.
A drawn conversation: a question about which open opportunities need attention, B1’s answer, the three highest-value opportunities as a table with stage and value, all open opportunity value as a separate bar chart by stage, and the capabilities IT pre-approved for it — CRM data access, a table component and a chart component.
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, from both seats.
Watch a sales opportunity view take shape, then see the approved building blocks behind it. This walkthrough demonstrates the shown setup; supported capabilities and operating requirements are confirmed for your pilot.
IT controls
IT approves the data access, actions and components available in B1. Work with business data, build internal apps and create agents for your team, using those approved capabilities.
The notes below distinguish mechanisms proven in the B1 Developer Framework, requirements to validate in your pilot, and features not yet generally available.
An approved catalog
IT defines the data sources, components and actions available in each environment. Apps use structured blueprints and a shared renderer. Unsupported references fail instead of becoming arbitrary application code.
Evidence: Framework mechanism proven in production
Teams decide what to do
Conversations · Apps · Agents
All three draw on the same pre-approved capabilities
Pre-approved by IT
Connect to
Your business systems
An explanatory model. The evidence below defines the scope to validate.
Illustrative example
AI assembles an answer, an app or an agent
and can use only
The catalog IT approved for this environment
Outside the catalog. An unsupported reference fails instead of becoming arbitrary application code.
Identity and data permissions
The product contract is that creating an app grants no new access. Framework authentication and permission patterns support this. Your pilot connects your identity provider and verifies permissions for data and actions, including your specific SSO, MFA and authorization requirements.
Evidence: Product contract plus framework mechanisms; verified in your pilot
Illustrative example
Signed in as Regional sales, Europe
so this view returns
Records inside that role’s access
Outside that role’s access. Further records exist in the same source and are not returned here.
Reviewable changes and audit scope
App definitions can be versioned in Git for review and reversal. Framework audit hooks and CI patterns provide a starting point. Your pilot defines and checks tests, policy gates, action and ownership records, and retention requirements for your environment.
Evidence: Framework patterns available; coverage proven in your pilot
Illustrative example
Allowed action: update the stage of an opportunity
used once, recorded as
An example trace of who requested what
Not a shipped audit or compliance product. Which entries are recorded, which gates run in CI and how long records are kept are defined and checked for your environment in the pilot.
Reversal here concerns an app definition, not an executed business action. Framework audit hooks are a starting point; they are not a shipped audit product with universal coverage.
Shared components and app lifecycle
The catalog and renderer ship together, so runtime improvements reach apps using them. App versioning, ownership transfer, update rollout and retirement for employee-built apps are specified, but are not yet generally available.
Evidence: Catalog behavior proven; app lifecycle specified, not yet generally available
Specified — not generally available
One employee-built app, three moves between versions
Drawn from the specification, not from a running product. Update rollout, rollback and retirement for employee-built apps are not yet generally available.
The expensive part of internal tools is owning them afterwards. A blueprint describes an app instead of generating a separate codebase. The following describes the Developer Framework's shared catalog and renderer; it does not make employee-built app lifecycle features generally available.
A blueprint names every component, data source and action the app depends on. IT can read that inventory for one app, or across all of them, without opening a codebase or asking the team that built it.
Apps reference catalog components by type, not by copy, and the catalog ships as one unit with the renderer. Improve what sits behind a type — a better table, an accessibility fix, a new theme — and every app using it moves with the next release.
Because apps are structured files rather than codebases, what they contain can be counted — which components appear in which apps, what the estate leans on, what a proposed change would touch. That analysis has been run across 2,355 production blueprint files in the Developer Framework. A usage dashboard is not a shipped product feature; the data one would read already sits in the files.
A blueprint is a typed object graph, not files somebody inherits. There is no generated output to review, refactor or eventually rewrite, and no framework-version debt piling up project by project.
Shared runtime maintenance replaces maintaining a generated codebase for every app. Apps remain readable, so IT can inspect what is in use. Ownership, compatibility checks and release decisions still need accountable people; employee-app versioning, ownership transfer, rollout and retirement are specified, not generally available.
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.
Architecture context from the Developer Framework. The mechanism described here is distinct from the new product's availability: your pilot verifies identity, permissions, review gates and operating setup. Employee-app lifecycle features remain specified, not generally available.
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.
UI as JSON, drawn by trusted client components. The model picks and configures components from a fixed set — it never ships code that runs.
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.
The diagram explains the framework composition and extension paths. Its automatic outcomes assume approved blocks and configured gates; pilot validation determines which paths are available in your environment.
Enterprise Integrations
IT defines which data sources, UI components, and actions exist as approved building blocks. AI assembles exclusively from these blocks.
Every block is a versioned, auditable blueprint — declarative and composable by AI.
IT defines which data sources, UI components, and actions exist as approved building blocks.
Building Blocks
FormTableChartDashboardMapGantt...QuerySchemaConnectorEntityFilter...ValidationWorkflowActionBPMNCode...AI can only assemble from pre-approved blocks
Not code.
Every block is a declarative blueprint — versioned, auditable, and composable by AI.
Ready to use. No code. No IT ticket.
Every employee gets answers, apps and agents
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 within the approved scope.
Framework composition explains this boundary. Pilot validation confirms approved capabilities, identity and data permissions, and the review gates required for your setup.
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.
The timing and auto-merge labels below describe this illustrative framework scenario, not a delivery promise. Your pilot defines required reviews, permissions and gates; human review can be required beyond new code entering the catalog.
An illustrative scenario, not a customer case.
“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.
Every block already in the catalog
Live the same day. Governed, because it could only be built from governed parts.
“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.
Two new blocks, written as code and reviewed
IT reviews the diff and approves. The connector joins the catalog.
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.
Back to composing — the catalog is one block bigger
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.
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.
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.
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.
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.
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.
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.
Environment fit
Give teams a shared place to work with company data, apps and agents. The available capabilities and operating setup are defined for your pilot.
Illustrative example
A drawn B1 workspace: navigation for conversations and saved views, a question about open service requests, and a saved view holding the three longest-open requests as a table and all open requests by priority as a bar chart, shared with the team for human review.
Use B1 capabilities from a compatible AI interface. The supported host, data connections and available actions are confirmed for your pilot.
Illustrative example
A drawn generic AI chat: a question about which suppliers missed the delivery window, and a B1 view returned inside the conversation showing the share of on-time deliveries per supplier against a 90% target, with two suppliers below it.
Examples, not a shipped connector list. Which of these are available in your environment — and which the approved catalog exposes to teams — is confirmed in your pilot.
Discuss open-source models and EU-hosted options for your environment. Available combinations, task quality and running costs are confirmed for your pilot.
B1 assembles approved building blocks instead of generating an entire application's code. This can reduce token usage and let smaller models handle suitable tasks. Measure quality and cost on your use case.
Pilot requirements are agreed for your setup. Self-service hosting, deployment and model controls remain roadmap capabilities.
Explore a governed pilot
Bring a process, a recurring data question or an internal tool idea. We will explore where B1 fits and what your business and IT teams would need to validate.
A good pilot starts with a recurring business task and business and IT colleagues willing to explore it together.
One business task, an accountable owner and the people who will use the result.
Business and IT agree which data, actions and components are in scope.
Test the selected experience and check its data access, operating requirements and usefulness.
A tested use case, documented requirements and a clear decision about the next rollout step.
Bring a use case from your own systems. We will walk through what the pipeline would build and how IT would govern it.