Before you begin
Have access to your Engine workspace, its tenant and brand, and a supported sign-in method. For a task that reads business data, also have a connection authorized for that system. A ResponseCX or NSR service key is not automatically a Desktop Engine login key.1. Install or run the app
For a packaged app, use your team’s approved distribution or the assets provided by the StateSet Desktop releases. Choose the available asset for your operating system and CPU architecture. The repository’s packaging configuration includes macOS, Windows, and Linux targets; this does not guarantee that every asset is available for every release. For development, use Node.js 22.12+ and the repository’s npm toolchain:.env for your deployment. The checked repository uses:
VITE_* variables; configure credentials through the app.
2. Sign in and verify scope
The login screen offers Email and API Key modes. Use the mode supported by your deployment. The email/password flow can return provisioned Engine credentials and workspace context; the API-key path validates the key against the Engine. If you need an account, use the app’s sign-up path when enabled or obtain access from your administrator. Check the tenant and selected brand before creating work. If native secure storage is unavailable, the login UI warns that the key is stored for the session only. A failed login should be diagnosed against the configured Engine, not by trying unrelated service credentials.3. Connect the tools your task needs
Open Connections and configure one required integration or hosted MCP server. For hosted MCP connections, use the app’s verification action to perform an actual initialize and tool-discovery handshake. Inspect the returned server identity and tools.
A successful desktop probe proves that the desktop can reach the server. Verify the cloud
execution environment can reach it too. Credentials may use the backend vault or encrypted local
fallback depending on deployment; a locally saved connection is not proof of cloud availability.
4. Create one bounded session
Use the dashboard’s create-agent flow. Choose the appropriate agent type or template, give the session a recognizable name, and inspect its configuration before selecting Create Agent. Review Custom Instructions, Max Iterations, Loop Interval (ms), and selected MCP servers. Set a small iteration bound for the first exercise rather than accepting a long-running loop without review. Resolve any warning about selected but unconnected servers. Use a task like this, replacing the bracketed values:5. Inspect execution and stop deliberately
Start the intended session and open its Agent Console. Inspect streamed messages, tool calls, metrics, and status events. Compare the answer with the retrieved record rather than treating a fluent response as proof of a successful integration. The dashboard can show an optimisticstarting state before the backend confirms the result.
Refresh and verify canonical session state after start, pause, resume, or stop. Losing the stream,
closing the window, or seeing cached data does not prove the remote session stopped.
Complete when: you have the correct tenant/brand, session ID, observed tool result, and a
verified final or stopped state. Save those together for the next operator.
Troubleshooting
Continue with web Console,
mobile Console, or the
Desktop architecture reference.
Source basis:
stateset-desktop README, package scripts, Login, Dashboard, CreateAgentDialog,
Engine API client, and docs/MCP_SERVERS.md, reviewed 2026-09-20. Installation and live Engine
execution were not performed as part of writing this guide.