Blocks Studio turns plain-language descriptions into working applications and reports all directly inside the Blocks platform organizations already use.
Instead of waiting for a development cycle, the people who understand the work can now describe the software they need and get a functional result they can refine through conversation.
From description to working software
Studio starts with a simple request. Describe what the tool should show, who will use it, and what they need to do. Studio turns that description into a working application or report.
For example, a user can ask for a page showing this quarter’s regional sales against last quarter’s, filterable by product line. Studio generates the interface and connects it to the relevant data within the Blocks environment.
That context is what separates Studio from generic AI page builders. Studio does not start with a blank web page. It generates within an environment that already understands the organization’s data, services, users, roles, and access rules.
Build, then refine by asking
The workflow is deliberately simple:
- Describe the tool. Type the request as you would say it. No configuration screens, no field-by-field forms, no component palette. A useful description names the same things a colleague would ask for: which information the tool should show, who will use it, and what those people do with it. The sales page mentioned above is a complete request, and it is the kind Studio works from.
- Studio builds it. The AI engine behind Studio converts the description into a functional interface. It runs on the same agent infrastructure that powers the platform’s other AI capabilities, so the machinery answering the prompt is the one the organization already trusts for AI work, and it improves as the platform’s AI improves.
- Refine by asking. The result is working software, and the conversation continues after it works. A column sorted another way, a filter added, a second view for the regional leads: ask for the change the same way you asked for the tool. Iteration costs a sentence, so a tool can evolve at the speed the work around it changes.
Two kinds of output
Studio produces applications and reports, and each has its own job.
Reports turn live organizational data into working views. Because they are generated inside the platform, they use the platform’s governed data services and existing access rules, so each person sees what they are authorized to access.
Applications provide functional interfaces with lists, forms, filters, and actions. They can support use cases such as approval tracking, shared registers, and departmental workflows, while using existing organizational accounts, roles, and sign-on.
Blocks-aware by design
Studio’s key differentiator is its Blocks-aware context.
A standalone AI generator knows how to create interfaces. Studio works within a platform that already knows the organization: its data structures, services, users, and roles. The generated software therefore connects to the environment where the business already operates rather than becoming another disconnected tool.
Studio and Blocks Agents also share the same underlying agent infrastructure, including configurable assistants, organizational knowledge, AI guardrails, and model flexibility. Blocks Agents applies this infrastructure to conversations; Studio applies it to interfaces and working software.
Built for the long tail of software
Studio is designed for the software that often falls between spreadsheets and full development projects:
- Internal tools: trackers, approval pages, registers, and departmental applications.
- Reports: live views of business data that can evolve as questions change.
- Prototypes: ideas that can be tested quickly by the people who have them.
Production frontends and customer-facing products remain the domain of professional developers. Studio addresses a different opportunity: the long tail of small internal software that is often too important to ignore, but too small to justify a full development cycle.
Already a part of Blocks
For organizations already running on Blocks, Studio is part of the existing platform environment. It uses the same identity, projects, data, and services, with no separate installation required.
If Blocks is new to the organization, start at the platform portal, os.seliseblocks.com. Create an account, set up a project, and the environment comes up with its ten services, Studio among them. Generated tools live inside that project, and colleagues reach them through the accounts and roles the project already manages.
Developers can work the same ground from the terminal with the Blocks CLI:
npm install -g @seliseblocks/cli-os@latest # install the CLI
blocks login # sign in via a browser confirmation
blocks projects list –json # see the projects you can reach
The CLI is the platform’s control plane for everything beside generation: scaffolding applications, defining data, pushing translations, triggering deployments. Studio covers the describe-it-and-use-it tier; the CLI covers the build-it-properly tier. Most teams end up using both.
Self-hosting organizations get the same result from the open-source stack: the platform’s service inventory brings Studio up behind the platform’s edge on the studio address of the hosted domain, governed by the same identity and audit machinery as everything else in the stack.
Read it, audit it, or run the app yourself.
