Abstractions
The API is the base every Product compiles to; App, UI, Agent and Service each add one small authored overlay and derive everything else.
StartupBuilder compiles every Product from one base, the API, plus four overlays: App, UI, Agent and Service. Each overlay adds a few authored fields; the rest derives from the same Nouns and Verbs.
Five abstractions, one definition
The five are not peers. The API is the base. An App is an Interface over it, the UI is design as data, and an Agent or a Service is a Product with one overlay:
| Abstraction | You author | It derives |
|---|---|---|
| API | Nouns, Verbs, and Offers | Endpoints, OpenAPI, SDK, CLI, MCP, Events, errors, filters |
| App | Personas, with their jobs and grants | Routes, screens, an inbox, a form for every Verb |
| UI | Components and Theme tokens | HTML for people, JSON for native clients, Markdown for agents |
| Agent | A Role and its eval cases | Tools, context, autonomy level, an agent card |
| Service | An Outcome Contract on an Offer | The work lifecycle, its Verbs, the hold on revenue, three Apps |
No abstraction has a second definition. Add one Verb, and that one write gives the API an endpoint, the App a button, the Agent a Tool and the reference a row.
The API is the base
The API names its seven parts and its two kinds of caller.
clinicslot.com is a Headless SaaS for physiotherapy clinics. Its definition declares an Appointment Noun with a reschedule Verb. From that one record, every Interface answers with the same name:
curl -X POST https:The SDK method is $.Appointment.reschedule, the CLI command is do Appointment.reschedule, and the MCP call runs the same code. The Event is Appointment.rescheduled, and the list filter ?rescheduledBy= comes free.
Every write returns one Action. It carries the status, the Mode, who it is by and for, and the record at its new Version. It reads the same whether code, a model, an Agent or a credentialed Human ran the Verb.
The Function behind a Verb never shows. A step moves from a person to an Agent with no change to the API. The response envelope specifies the shape.
Every Offer answers one question before any charge: can it deliver? Its quote Verb returns covered as yes, with or no. A with names what is missing, such as an Integration or a higher Limit.
Every Offer also declares earns: the Event that recognizes its revenue. Data and Software earn when the Action is done, an Agent on its verdict, and a Service on acceptance.
App: Personas over the API
An App is the human Interface of a Software Product. You declare who uses it and what each Persona may do; the App compiles from that.
tunedin.app is a marketplace that books piano tuners. It declares three Personas: the household that books, the tuner who works, and the admin. Each gets routes on the API's own addresses: a home Dashboard, an inbox, a screen per record, and a form per Verb it may call.
One address serves three readers. https: returns HTML to a browser, JSON to the native app, and Markdown to an Agent. The record and its Verbs come from the API in all three.
Authorization runs before any screen renders. A tuner sees only their own bookings and only the Verbs they may call now; nothing is hidden with CSS.
UI: design as data
A screen is a list of Components with props, filled from records and styled by a Theme. One catalog serves every Site, App and Dashboard, and three renderers draw it for people, devices and Agents. UI covers the catalog and its renderers.
Agent: a Role and its evals
An Agent has no API of its own. You author a Role, with its Permissions, Goals, Limits and Skills, and the eval cases that define good work. Everything else derives:
- Its Tools are the Verbs the Role may call, described in the same words as these docs.
- Its first context is the Role's Dashboard, rendered as Markdown.
- Its autonomy is earned per Verb, from evals.
Autonomy climbs three levels: assist, supervised and full. In assist a person approves each result, in supervised a person reviews exceptions, and in full a sample.
Promotion needs at least 95% agreement from an Evaluator over the Role's sample, and a regression demotes at once. The doer is never the checker: an Evaluator sharing the Agent's model is refused.
listsmith.ai sells an Agent that writes product listings for online stores. It bills per listing that passes its Evaluator. The Offer's earns is the verdict Event, never the Agent's own claim of done.
Service: an outcome, warranted
A Service is an Offer with an Outcome Contract. Five fields make the promise checkable: done, accept, assurance, remedy and earns. The Startup holds the work until done and answers for acceptance.
The contract compiles into a work record with its own lifecycle:
Read as text
- Ordered to Intake
- Intake to Working
- Working to Done
- Done to Accepted
- Accepted to Earned
- Done to Disputed
- Disputed to Remedied
- Remedied to Earned
Done is a claim; acceptance is a separate Event. Revenue stays on hold from the Order until the earns Event fires.
A certified translation Service shows the mix. An Agent drafts each document, and a credentialed translator certifies it as a human Function. Each step is a Verb on the work record, so a step moves between people and Agents without touching the Customer's contract.
The same compile produces three Apps: one for the buyer, a worklist for the translators that works offline, and one for the operator. Outcome contracts covers the five terms in depth.
Next
- The project structure: where each authored field lives in a repository.
- Interfaces: the API, MCP, CLI and SDK in depth.
- Agents: selling an Agent, with quotes and billing on verdicts.