Applications and workspaces

An application represents your business product. Each application contains test and production workspaces, accessible through application membership.

Organization
└── Application
    ├── Test workspace
    └── Production workspace

Application-level settings

Application members, feature permissions and available business scenarios are managed at the application level. One membership covers both workspaces.

Workspace isolation

Content	Isolation
Characters, scenario forms and AI task implementations	Configured and published per workspace
Model routing, tools, knowledge and media libraries	Maintained per workspace
Users, conversations, messages and memories	Belong to the current workspace
Integration credentials and callback URLs	Configured per workspace

The same external user identifier in two workspaces represents separate user records. Editing or publishing prompts in the test workspace does not affect production.

Tests execute real actions

The test workspace does not simulate business callbacks. Connect it to your test system, and connect the production workspace to your production system.

Credentials identify the workspace; your requests do not need an additional sandbox/production environment field. Missing valid callback configuration causes an explicit delivery failure, not simulated success.

Preparing production

Prepare production characters, AI tasks, models and callbacks independently. Automatic synchronization or one-click promotion is not currently promised. Verify production configuration against your tested setup, and do not reuse credentials or callback signing keys across workspaces.

Console interactive testing uses a separate channel: messages go to the platform inbox rather than your message callback. Synchronous business tools can still invoke real endpoints. Use the public API to verify end-to-end callbacks in the test workspace.