> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stateset.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](https://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:

```text theme={null}
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.

<div className="ss-checkpoint">
  **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.
</div>

## 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+**:

```bash theme={null}
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](https://github.com/stateset/stateset-console/blob/main/docs/setup.md).
Do not enable development-login bypasses on a hosted production deployment or expose backend
secrets through `NEXT_PUBLIC_*` variables.

```bash theme={null}
npm run dev
```

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

```bash theme={null}
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](/guides/console-mobile-getting-started),
[Desktop setup](/guides/desktop-getting-started), or
[Console architecture](/stateset-console/stateset-console-overview).

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.