Getting started

This page walks you from a brand-new Threada account to your first working pack. It assumes nothing — no command line, no API keys, no SDK install. The same flow applies whether you start in Work, Studio, Travel, or Invest.

Threada uses GCP Identity Platform behind the scenes. You can sign in two ways, with no password to manage:

Passwordless email link — enter your email; Threada sends a one-time link that signs you in.
Social sign-in — Google and Apple are supported. Pick a provider, approve the consent screen, and you’re in.

The chosen identity becomes your user in Threada. Users belong to tenants (your organization), and your role inside the tenant (Admin, Editor, or Viewer) controls what you can do.

2. Land in the right shell

After sign-in, Threada redirects you to the right shell: the first-party surface, chrome, and posture appropriate to what you’re trying to do.

Shell	Purpose
Work	Day-to-day operator surface — solutions, WorkItem queues, workspace, controls, timeline.
Studio	Builder surface — configure packs, intake channels, templates, policies, automations.
Admin	Governance — users, identity providers, billing, retention policies, audit.
Travel	Flagship consumer app, packaged on Threada’s runtime.
Invest	Flagship consumer app, packaged on Threada’s runtime.

If you don’t know where to start, Work is the right default for most operators; Studio for builders; Admin for IT/security.

3. Connect a channel

Threada normalizes requests from many sources into a single typed unit: a WorkItem. To start, connect at least one intake channel in Studio. The supported channel types are:

in_app — Threada’s web shells (no setup required)
web — externally managed web forms or embedded web intake; inbound only
slack, teams — chat channels
email — inbound email aliases
api — programmatic intake from your own systems
custom — bring-your-own webhook source

Each channel installation is tenant-scoped and origin-validated. See the integrations index for the full list of external systems Threada can pull from or push to.

4. Install or build a pack

Packs are the unit of value. They bundle the prompts, policies, templates, and workflows for a specific domain (refunds, escalations, travel-quote review, etc.). Two paths:

Install a pack in Studio — pick from the catalog, configure required variables, and publish to your workspace.
Build a pack in Studio — define intake schema, draft logic, evidence sources, and the actions operators can take.

Inside Work, installed packs appear as user-facing solutions with job-specific stages. Inside Studio, the same packs are visible as pack/workflow definitions.

5. Process your first WorkItem

When a request arrives on a connected channel, Threada:

Normalizes it into a WorkItem (subject, body, channel, customer).
Routes it via configured queues and SLA policies.
Drafts a response using the pack’s prompts plus retrieved evidence (see Grounded AI).
Holds for approval if the pack policy requires human review for that action class.
Executes the approved action — reply, ticket update, refund, integration call.

Every step is captured in the WorkItem’s timeline for audit.

Next steps

How grounded AI works — the RAG pipeline, evidence, and no-answer behavior.
Shells and packs — the product model in more detail.
Integrations — what is live, planned, or custom.
Security — how Threada protects your data and workspaces.

Running Threada locally (engineers)

Working on Threada itself rather than using a hosted account? The local stack is documented in the repo README.md. The one step that trips up fresh clones is the environment bootstrap: the .env.* files are gitignored, so before the first task dev you must reconstruct them from Secret Manager with an authenticated gcloud:

gcloud auth login
task dev:env ENV=dev                     # writes the gitignored .env.dev
task dev                                 # MongoDB + services + frontends

task dev fails fast with the exact command above if an env file is missing. For frontend-only or backend-only iteration, narrow the process-compose graph with task dev PROFILE=frontend or task dev PROFILE=backend. See the repo README.md (“Bootstrap your local environment” and “Faster iteration”) for the full flow. The local runner binds the process-compose control API to 127.0.0.1:18080 so public-bff can serve on 8080; detached process-compose commands must pass --port 18080.