Apps

An app is an optional user-facing experience over your backend. It is an ordinary workspace package in your repository, built and deployed with everything else. An app might be a client portal, marketing site, field team application, operational workspace, or dashboard.

An app uses a typed client over the project's operating model contract to read objects and call tools. It does not own business rules, and it does not keep its own copy of the data. Two apps over the same operation see the same state because there is only one.

The Continual agent and work queue are the default interface for conversation, proactive questions, exceptions, and approvals. Build an app when conversation is the wrong shape for the work:

• reviewing or editing many records at once;
• monitoring a high-information operation;
• spatial, visual, or tightly structured work;
• a public website or customer portal;
• a repeated workflow where direct manipulation is faster than conversation.

An app is not required for a project to be useful. The Continual agent and external agents may operate through the backend's MCP contract with zero custom apps.

What belongs in an app

• Layout, navigation, and presentation.
• Gathering input and validating it for the user's benefit—the tool validates again for the system's.
• Showing what agents are doing and what changed.

What does not

• Business rules. If a screen decides whether an order may be approved, the next surface to touch that order will decide differently.
• Direct writes. An app calls a tool.
• Multi-step writes. One user intent is one tool call, so it either fully happens or does not.

Apps and deployment

A release records the backend and every app build resolved from one source revision. Those executables may deploy independently, but each declares the backend contract version it requires. The platform must reject an incompatible deployment rather than let an app run against a contract it was not built for.