Get Started with Console on the Web

Sign in, connect an operations system, select agent tools, and verify a first task in the StateSet web Console.

Outcome: one Console conversation reads a known business record and returns a result you can verify. Start with a single task before creating an autonomous workflow.

This is the stateset-console application, distinct from the ResponseCX support-agent app and the NSR decision console. Web Console and its mobile client use the Console backend. Desktop uses an Engine connection; credentials and session views should not be assumed interchangeable.

1. Open the correct deployment

Use the Console URL supplied for your organization. The mobile repository’s checked build profiles point to console.stateset.app; existing documentation also links to console.stateset.com. Confirm the intended deployment with your administrator rather than assuming these hosts share a session, configuration, or data.

Sign in with the supported email/password or Console access-token flow. Continue with SSO appears when that deployment enables it. Complete any email verification or organization setup shown. If SSO succeeds but tenant provisioning is incomplete, resolve that state before starting agent work; a successful identity-provider login is not backend readiness.

2. Connect one operations system

Open Integrations and choose the system containing your test record. Use the offered OAuth or credential setup for your deployment. Check the connection state and available verification result before returning to the assistant.

A catalog entry can be connected, ready to configure, beta, or coming soon. Its presence does not establish that your organization has credentials or that an agent can use its tools. Keep credentials in the integration setup, not the conversation text.

3. Select tools and send a first task

The main Console provides a conversation area, agent configuration, and session controls. Review the selected MCP servers and base tools. The runtime builds its available tool set from organization configuration and credentials; selecting a tool name alone does not provision it.

Submit a task with one known test identifier:

Read only. Inspect [record ID] in [connected system] for this organization.
Report its current state and the tool evidence supporting your answer.
If you cannot access the record, identify the missing permission or connection.
Do not send a customer reply, modify data, issue a refund, or start a loop.

Inspect the streaming response and tool results. Keep the conversation/session identifiers available in the UI and compare the result with the source system. A task can consume model and sandbox resources even when it requests no business mutations.

Complete when: the actual tool result identifies the intended record and supports the answer. An integration badge or a successful sign-in does not replace that check.

4. Understand approval and execution boundaries

If a task requests a sensitive action, review its exact target, arguments, and approval context. Decline unexpected actions instead of approving them merely to finish the walkthrough. Prompt instructions do not replace server-side permissions and guardrails.

After an authorized action, inspect its execution result and the owning system. Approval, request acceptance, and a completed business operation are separate states. If a stream ends or a request times out, inspect existing work before submitting a duplicate action.

Use autonomous sessions or loops only after the first bounded task works. Confirm scope, execution budget, connected tools, and stop behavior. Closing a browser tab or stopping the visible stream is not proof that remote work has been cancelled.

Run the web app locally

For contributors, use Node.js 20.20.0+ and npm 9+:

git clone https://github.com/stateset/stateset-console.git
cd stateset-console
npm ci

Create .env.local using your deployment’s approved configuration. At minimum, account for:

Area	Configuration to obtain
Authentication	Session-signing secret and enabled login/SSO configuration
Persistence	Hasura endpoint and server-side credentials
Execution	Selected runtime backend, its endpoint, and authorized credentials
Model access	Required server-side model credential for the selected path
Integrations	Only the provider connections needed for your test

The repository supports direct Sandbox execution and an orchestration-to-sandbox path. Configure the intended one using its setup guide. Do not enable development-login bypasses on a hosted production deployment or expose backend secrets through NEXT_PUBLIC_* variables.

npm run dev

Open http://localhost:3000. Check the local service before testing a real task:

curl --fail-with-body --silent --show-error http://localhost:3000/api/health
curl --fail-with-body --silent --show-error http://localhost:3000/api/ready

Inspect the readiness response for backend-specific blockers. A running Next.js page is not proof that Hasura, the Engine, Sandbox, or provider connections are ready. Local setup uses real configured services unless you deliberately run the repository’s fixture tests.

Troubleshooting

Symptom	Next check
Sign-in succeeds but agent work fails	Organization provisioning and selected execution backend readiness
Integration appears but tools are unavailable	Actual saved connection, scopes, MCP selection, and backend credentials
Chat returns no useful record	Exact identifier, connected organization, and tool-call result
Stream disconnects	Existing session state before starting another task
Local UI loads but requests return errors	Server configuration and /api/ready results

Next: mobile setup, Desktop setup, or Console architecture.

Source basis: stateset-console package scripts, sign-in and main Console pages, Integrations, lib/agent/mcp-builder.ts, setup docs, and the readiness handler, reviewed 2026-09-20. This guide does not claim a live deployment or provider test was performed.