Skip to main content
A Prisme.ai workspace is built the way your developers already work, not locked into a proprietary language. When a use case needs a UI, it is a standard React application. The backend logic (automations and agentic workflows) is described in YAML, for one practical reason: it versions cleanly in Git and stays reproducible. Together they form the workspace’s declarative, versionable definition, what we call DSUL: the Infrastructure-as-Code layer that keeps agents and applications reproducible instead of scattered across silos.

​
A workspace fits the use case

A workspace is not always a front-end. You use only the parts your use case needs.

Endpoint or MCP server

Expose an API endpoint or an MCP server from your automations. No UI required.

Scheduled agentic workflow

An automation that runs on a schedule, for background and agentic jobs. No UI required.

Single-page app

A standard React front-end on its own, for a focused user experience.

Full-stack

A React front-end plus endpoints and agentic workflows, fully integrated in one workspace.
A workspace can also be simply agent-as-code: a tool used only to provision agents and version everything in Git, with no UI at all.

​
Open, not locked in

Declarative platforms often raise the same fear: getting trapped in a proprietary language you cannot leave. Prisme.ai is built the opposite way.

A framework your devs know

When there is a UI, it is a normal React single-page application. No proprietary UI language to learn.

YAML only where it earns its keep

Automations are YAML for one reason: they version and review in Git. A practical choice for reproducibility, not a cage.

Open and reversible

Open-source, exportable, and portable. Your code lives in your Git repository, so you can always take it with you.

Scoped code access by design

Writing raw code is deliberately limited to reduce the risk of security issues and data leaks. Most builders stay in safe, governed building blocks; code is opened only where it is needed.

​
Everything is a workspace

The unit DSUL describes is a workspace: a self-contained application that runs on the platform. Every product (Chat, Agent Creator, Knowledges, and the others) is itself a workspace. Builder is the tool that creates workspaces and opens them to edit.
A workspace bundles Pages (React UI), Automations (agentic workflows), Imports (apps and SDKs, pinned), Files, and Activity. Products are workspaces too, opened and edited in Builder.

​
Apps are SDKs

Publish a workspace and it becomes a versioned App in the App Store, behaving like an SDK. Import that App into another workspace and its instructions become available inside your automations. It is workspaces composing workspaces.
Publish a workspace as a versioned App in the App Store, then import it into another workspace so its instructions enrich that workspace's automations. Agent Creator is the product; Agent Factory App is the importable SDK.

​
Build it all from VS Code, over MCP

The whole platform, whether self-hosted or cloud, is reachable from VS Code over MCP, authenticated with your own access tokens. From your editor you build any of the shapes above, with or without a UI.
1

Connect VS Code to the platform

Use the MCP connection so your editor can read and write workspaces with your access tokens.
2

Build what the use case needs

An endpoint or MCP server, a scheduled workflow, a React SPA, a full-stack app, or agent provisioning. For SPA and full-stack, start from the starter SPA.
3

Version with Git

Commit to your own repository. Every change is reviewable through a merge request. See versioning.
4

Push to a workspace

Deploy to a sandbox for fast iteration, or promote through Git for a structured, auditable release. See deployment.

​
Core components

  • Pages: the front-end, a standard React SPA. Optional, only when the use case has a UI (start from the starter SPA)
  • Automations: backend logic and agentic workflows, described in YAML so they version in Git. Can expose an endpoint, an MCP server, or run on a schedule
  • Imports: connectors, apps, MCP servers, and custom code installed into the workspace
  • Files: documents and assets used by the workspace
  • Activity: the workspace’s execution events, for observability
  • RBAC: fine-grained access control over all of the above

​
Why this model for the enterprise

  • A framework devs already know: React for the front-end, YAML only for automations, no proprietary stack to adopt.
  • Reproducible by default: everything lives in Git, with merge requests and environment promotion. See versioning and deployment.
  • Shared, standardized infrastructure: many workspaces run on the same multi-tenant platform with logical isolation, instead of dedicated infrastructure per agent. See Platform Overview.
  • Cloud and LLM agnostic: the same workspace runs on any major cloud or on-premises, with no vendor lock-in.
  • Native observability and traceability: every action is a normalized event with a correlation ID, so monitoring and audit are built in.
  • Governed by design: RBAC, audit trails, and central policy across every workspace, with code access scoped to limit security and leak risk. See Governe.

​
Next steps

Starter SPA

The React starter for SPA and full-stack workspaces, in VS Code

Builder

Create and edit workspaces: pages, automations, imports, and activity

App Store

Publish and import Apps and MCP servers as reusable capabilities

Platform Overview

Architecture, development lifecycle, and governance

Related topics

Overview