The s-m-r-t application stack

A TypeScript stack in five layers. Every layer releases together, at the same version.

Foundations — one description of the application: what it stores, what it can do, and who is allowed to do it. Rules about who can see each record are enforced where the data lives.
Who can do what — accounts, sign-in, and roles. Every request is checked against the person or agent who asked.
Ready-made building blocks — working parts for common needs: articles, files, images, events, invoices, projects, messages, reports.
Agents included — an application comes with agents of its own: they follow written instructions, run on schedules, talk in chat, and learn from feedback. Outside agents can connect on the same terms, with their own identity and fixed lists of allowed actions — and an agent never has more power than the person it works for.
Screens and controls — pages, forms, and tables that people use directly, and that agents can read and describe where the application allows it.

0.44.0 · 61 documented packages · 285 components · 49 playground entries

01 Foundations 10
02 Who can do what 2
03 Ready-made building blocks 30
04 Agents included 5
05 Screens and controls 4

What you get · One description, every surface

Describe the record once

This is one record type, described once. The description says what the record stores, which actions are available on the web and to agents, and which fields are required, read-only, or secret. The surfaces it selects are generated from it: the storage, the forms, the web API, the agent tools, and the permissions.

src/lib/objects/Article.ts

typescript

import {
  field, smrt, SmrtObject
} from '@happyvertical/smrt-core';

@smrt({
  api: {
    include: ['list', 'get', 'create', 'update']
  },
  mcp: { include: ['publish'] },
  cli: false,
  ui: {
    label: 'Articles',
    description: 'Stories your team publishes.'
  }
})
export class Article extends SmrtObject {
  title = '';

  @field({ required: true })
  author = '';

  @field({
    readonly: true,
    description: 'Server-set; writes cannot touch it.'
  })
  viewCount = 0;

  @field({
    sensitive: true,
    exported: false,
    description: 'Editorial notes for the team.',
    ui: { group: 'Editorial', order: 10 }
  })
  authorNotes = '';
}

Change the description and every surface changes with it. There are no separate copies to keep in sync.

Read the Framework overview →

How it works · People and agents, same rules

An agent can propose a change. A person applies it.

Every button and field in a s-m-r-t application carries a description an agent can read: what it is, what values it accepts, and who may use it. In the demo below, an agent finds a field, checks a new value against the same rule a person sees, and sets its proposal beside the current value. Nothing changes until a person clicks confirm — and that click is something an agent cannot send. The red panel at the end is not an error: the agent asks for a protected field, and the application refuses.

An agent never acts on its own authority. It can do only what three lists all allow: what the signed-in person may do, what its kind of agent may ever do, and what its assigned role permits. The check runs everywhere — when the agent looks, when it offers, when it acts, and at the stored record itself.

Run each step below. The same demo, with its technical notes, is on the UI overview and in the Playground.

Shared definition One application model

Fields
Relationships
Operations
Permissions

Persons Use visible controls, natural language, chat, and voice.
Application agents Discover declared controls and operations within assigned authority.
Developers Define application behavior once and maintain fewer parallel interfaces.
Coding agents Read deterministic project knowledge and version-matched instructions.

Scripted demonstration · released registry

A proposal succeeds. A protected change fails.

This scripted adapter uses real controls, validation, classification, staging, and confirmation policies. No language model runs in this demo.

Small example object

Subject: Profile · 42
Form ID: profile-demo

Permitted proposal

Find and explainRead stable identity, label, constraints, and policy.
Validate the proposalUse the same rule as the visible form.
Stage separatelyKeep the proposal apart from the live value.
ReviewCompare the live and proposed values.
Confirm and applyA real click supplies the confirmation an agent cannot send.
UndoRestore the previous registry-held value.

Live valueWillow Reed

Proposed valueNot staged

Proposal checkNot checked

Policy refusal

Awareness is not authority

The registry can identify the recovery-key control. Its secret classification removes read and mutation authority.

No request sent The adapter supplies no protected value to this attempt.

Choose the first step to run the permitted proposal.

Static storyboard

The scripted flow finds and explains the public control, validates a proposal, stages it, reviews it, and applies it only after confirmation.

The refusal flow asks the released policy to stage a secret control. The policy returns sensitive_control without reading or showing the protected value.

The propose-then-confirm pattern ships with the toolkit as a released component (StagedControlReview) — not something each application builds for itself. This demo drives the same registry directly, one storyboard step at a time, so each stage keeps its own button.

Scope · The package catalog

Five layers, one release

This is what each layer contains. Every package releases together, at the same version. Each package name below links to its page in the catalog.

Foundations

One description of the application: what it stores, what it can do, who is allowed. Rules about who can see each record are enforced where the data lives. Runs out of the box with a local database.

Browse in the catalog

Who can do what

Accounts, roles, and sign-in. What a person may do also caps what their agents may do.

Browse in the catalog

Ready-made building blocks

Working parts for common needs: articles, files, images, events, invoices, projects, messages, reports.

Browse in the catalog

Agents included

An application comes with agents of its own: they follow written instructions, run on schedules, talk in chat, and learn from feedback. An agent can propose changes to its own instructions — nothing changes until a person approves. Outside agents can connect on the same terms, with their own identity and fixed lists of allowed actions; an agent never has more power than the person it works for. Making tools visible to outside agents is a choice each application makes, never a default.

Browse in the catalog

Screens and controls

The pages, forms, and tables people use, documented one by one. On pages that allow it, an agent can read and operate the same controls in the browser.

Browse in the catalog

These five layers place 51 of the catalog's 61 packages. The rest is native mobile — source-only and unpublished — plus the command-line, testing, and project-scaffold packages: see Tooling, the Mobile capability page, and the full catalog.

61 documented packages 285 documented components 49 working examples 8 building-block groups

UI · Tools people operate

What you can build

The building blocks come with their screens. These are the kinds of tools an application assembles from the released parts. This site is built from the same packages, and the Playground holds working examples from each group.

Working with records

Tables and forms for finding, reading, and changing records: search, filters, sorting, saved views, and changes a person reviews before they apply. The table below is one of these tools, running here — everything about its current view fits in a link that can be saved or shared.

Search surfaces

Released SMRT UI surfaces

DataTable	Collection	Local or manual	Released
Interaction registry	Form	Application policy	Released
AdminShell	Workspace	ShellState	Released
AgentChat	Conversation	Host callbacks	Needs shared preview
Field policy	Model form	Model and policy	Released
Browser AI	Browser capability	Configured adapter	Needs shared preview

Search: None
Filter: None
Sort: None
Page: 1
Expanded: 0

Includes: DataTable, forms with staged review → smrt-ui components

Content management

Writing, reviewing, and publishing: drafts, versions, review policies, corrections, and held submissions from outside contributors.

Includes: the content list with saved views, the governance screens → smrt-content components

Reports and analytics

Numbers kept current: reports declared once and refreshed on a schedule, with saved views and exports; visitor analytics from common providers alongside.

Includes: report tables and saved views → smrt-reports · smrt-analytics

Conversation

Chat rooms and threads where people and agents talk, with each agent's allowed tools set by the application. Voice input where the device supports it.

Includes: chat layouts, agent sessions, voice input → smrt-chat · smrt-svelte

Browse the UI overview → Open the Playground →

What you lose · Separate copies to keep in sync

Built for the people who build it

Developers

Describe the application once instead of keeping several copies in sync. A new application runs immediately, storing data locally, before any database is set up.

Coding agents

Read the same description of the project the application runs on, plus instructions written for the exact installed version rather than for some other release.

Explore developer and coding-agent Tooling →

Evidence · Release-audited claims

Every claim on this page has a source

Each row links a claim to the page that explains it and to the released source it was verified against.

Claim	Explained at	Verified in	Try it
One record description becomes both the human screens and the agent tools.	What is a SAADL?	Core release contract
Any control can be explained, validated, staged, confirmed, or refused through one registry.	Agent-assisted forms	smrt-ui release contract	Agent-aware form demo
Selected operations become agent tools with the same names, inputs, and policy as the human interface.	Agents	smrt-web release contract	UI overview
However a request arrives, the same permission checks apply — down to the stored record.	Security defaults	Application MCP release contract	Governed interaction demo
An application becomes visible to a live coding-agent bridge only when it explicitly turns that bridge on.	Agent-legible applications	Development MCP release contract
This site itself runs on the released packages it documents, not a separate internal build.	Component playground	Documentation site source

Guides and start paths

Follow one supported job from start to finish

Guides give tested procedures and expected results. Start with a basic application or inspect released behavior before installation.