create-dpas-appOne capability layer for your UI, your copilot and MCP

One command scaffolds a Dual-Plane Agent Stack application: one typed registry instead of a product and a parallel agent API, governed on the server and testable without a model.

Get started

The dual-plane model

Security model

🧬

One app, not two

A capability is a single typed declaration. The UI calls it directly, the copilot receives it through the host, external clients get it over MCP. No tool wrappers mirroring your procedures, no second schema to keep in sync, no product that drifts from the agent's view of it.

🔭

Deterministic discoverability

The catalog is composed per request from identity, route and mounted components: computed, not prompted. Both planes compile to committed inventory files, so what the model can see changes only when you change it, in a diff a reviewer can read.

🛡️

Governance that holds up to audit

Authorization runs on the server on every call. A capability the current identity lacks does not grey out; it disappears, and asking for it directly answers `Capability not found`. Consequential mutations return an approval card, and nothing moves until a human decides.

🪟

Two planes, never blurred

View capabilities are registered by the components that own the state and execute in the browser. Domain capabilities are oRPC procedures, governed and re-authorized on the server. The model sees one catalog and cannot tell them apart.

🧭

An agent host you own

The browser↔server protocol, per-request catalog composition, executor routing, correlation ids and run limits are application modules you can read and change, not framework glue.

🧪

Deterministic tests, no LLM

Governance and capability contracts are unit-tested, and Playwright drives a production build through the live pipeline under a scripted model: the real host, the real approval flow, no provider key. CI never needs credentials.

bash

pnpm create dpas-app my-agent-app
cd my-agent-app && pnpm dev

Open http://localhost:3000. Filter, sort and hide columns, all URL-synced, so a narrowed view is shareable. Open a chase dialog and record a reminder. Switch identity in the header: as Ada, the analyst, issue-invoice does not grey out, it disappears, and asking the server for it directly answers Capability not found.

Add a provider key, press ⌘J, and ask:

Which invoices are overdue, and by how much?

The copilot reads the ageing ladder on the server, narrows the table in your browser, reads the rows back, and answers from what it read. The table moves because the agent called the same setter your toolbar calls; it has no privileged channel into the UI.

Then ask it to issue a draft. It will not: a model-initiated issue-invoice comes back as an approval card, and nothing moves until you decide.

Reading paths

“Show me what this is.” Getting started → The dual-plane model → Architecture
“I'm adding my own capabilities.” Anatomy of a capability → Adding a capability → Testing
“I'm reviewing its security.” Security model → Scaffolder guarantees → Host protocol → Decision records
“I'm putting it in front of real users.” Connecting a model → Configuration → Deploying

Everything on this site describes the app the scaffolder actually generates, built on the published @agent-surface/* and @orpc-agent/* packages, Mastra and assistant-ui. The architecture, capability and security guides are the same markdown that ships inside every generated app, so the two cannot drift.