# The set-up mission > Ten steps from a new tenant to a working agent: what each one does, what it needs first, and how LightHouse determines that it is done. The **set-up mission** at **Setup and admin → Set-up mission** guides a client administrator from a new tenant to a first agent at work. It has ten steps and takes about 48 minutes in total (estimated). For the full path from sign-up, see [Organisation set-up](/enterprise/). Any step can be left for later, and steps can be taken in any order except where noted below. The rest of LightHouse operates while the mission is incomplete. The [Quickstart](/start/quickstart/) needs none of these steps; it issues a key and reads the API. The set-up mission is for configuring the tenant itself. The **Setup and admin** group appears in the sidebar only for people with the **Client administrator** (`client_admin`) role. ## Steps | # | Step | What it is for | Needs first | Est. | | -- | ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | ------ | | 1 | **Let your team sign in** | Connect the identity provider and set who may sign in. See [Single sign-on](/enterprise/single-sign-on/) | — | 3 min | | 2 | **Verify your domain** | Publish one DNS record to verify the organisation’s email domain, so that sign-in rules can name it. See [Verified domains](/enterprise/domains/) | — | 5 min | | 3 | **Make it yours** | The organisation’s logo and colours on the portal | — | 2 min | | 4 | **Settle how you pay** | A payment method or invoice terms, and the agreements accepted | — | 3 min | | 5 | **Choose where your agents run** | Own cloud, own servers (online or [air-gapped](/enterprise/air-gapped/)) or Atlantic-hosted, and the deployment profile | — | 5 min | | 6 | **See your stack report in** | Install the stack and receive a deployment’s first signed telemetry | Step 5 | 15 min | | 7 | **Choose your models** | A model per use case, Direct or Managed, filtered to the cloud and the data residency | Step 5 | 4 min | | 8 | **Connect your first data source** | One connector, read-only by default, with its credential kept in the organisation’s own secrets store, or under the tenant’s key until the deployment can keep it | — | 4 min | | 9 | **Put your first agent to work** | An agent from the library, on a deployment | Steps 7 and 8 | 5 min | | 10 | **Meet Octy** | Ask Octy™ a question about the estate; the answer cites what it read | — | 2 min | Dependencies: - **See your stack report in** and **Choose your models** require step 5. The models offered depend on the cloud chosen. - **Put your first agent to work** requires steps 7 and 8: an agent needs a model to call and a source to read. A step whose dependency is not done shows the dependency as blocking; the step can still be opened. ## Where to start, and what to skip 1. **Step 1, where other people will take part.** A tenant created by sign-up has one sign-in method: a one-time PIN sent to the registering address. Other people can sign in once an identity provider is connected and a rule admits them. The client administrator connects Microsoft Entra ID, Okta, Google Workspace, SAML 2.0 or OpenID Connect at **Access → Single sign-on** ([Single sign-on](/enterprise/single-sign-on/)); Atlantic configures GitHub and GitLab sign-in on request. Rules are set on the **Access** page (below). 2. **Step 4, before any spend.** Managed model calls require a payment method or invoice terms. In this step the administrator also accepts the master services agreement (MSA) and data processing agreement (DPA); LightHouse lists a new version of either as pending until it is accepted. See [Change notices](/trust/change-notices/). 3. **Step 5, before steps 6 and 7.** Choose the cloud, a region and a deployment profile. LightHouse produces the stack, and the organisation’s pipeline applies it. See [Clouds](/clouds/). 4. **Step 3, optional.** Branding changes the portal’s appearance only. To leave a step for later, choose **Leave for later** on it. To undo that, choose **Take this up again**. LightHouse records who made the choice in the audit trail. A step left for later no longer counts as outstanding and no longer blocks the steps that depend on it. ## Step 1 in detail: decide who may sign in **Settings → Users and roles** opens the **Access** page (`client_admin`, signed in as a person). It shows your **Identity providers** (each with its status and where its second factor comes from), the **Fixed rules** that no one can change, and **Who can sign in**: the rules that give people a role. 1. Under **Who can sign in**, choose **Add a rule**, or **Add a time-limited person (e.g. an auditor)** for a named person whose access should end on a date. 2. Set the **Role**: Viewer, Content viewer, Agent handler or Client administrator. See [Roles](/api/roles/). 3. Choose what the rule **Matches**: *Group in your identity provider*, *GitHub organisation or team*, *Email domain*, *Named person (email)*, or *Everyone in your identity provider*, and fill in the value. 4. Optionally set **Expires** (at most a year ahead) and a **Note** (up to 120 characters). 5. Choose **Save changes**. The page confirms *“Saved. Access is now at version N; the change is in the audit log.”* If a rule breaks a fixed rule, it says *“Not saved:”* and why. Someone matched by several rules gets the highest role. The fixed rules include: at least one client administrator rule must remain; a public mail domain (such as gmail.com) cannot be a domain rule; the one-time email code admits named people only; and Atlantic staff can be given at most content viewer. Under **Atlantic Agentic Labs staff**, you choose whether Atlantic’s engineers may also read content. The page’s **Access review (CSV)** and **Access review (JSON)** buttons download who holds which role. See [API security](/security/api/#roles-and-least-privilege). ## How LightHouse knows a step is done LightHouse reads the underlying configuration each time the mission is opened; no completion flag is stored. Step 1 reads the tenant’s identity providers and access rules, step 2 the verified domains, step 4 the billing account and pending agreements, step 6 the telemetry received from active deployments, step 8 the connections, step 9 the agents the deployments have reported and the accepted library requests, and step 10 whether Octy has answered a question in the tenant. A step can return to not done. Removing the identity provider reopens step 1; disconnecting the only source reopens step 8. Each step shows a sentence describing the current state of your tenant. For example: > Okta connected, and 3 rules deciding who signs in. > No identity provider yet: sign-in is by one-time PIN only. > Paying by invoice. MSA and DPA still to accept. > Still Atlantic’s own colours and mark. When step 5’s sentence includes a saving for running ephemeral rather than always-on, it is labelled estimated. It comes from the same versioned cost model as the **Deployments** page. See [Cost and token optimisation](/cost/). The mission reads and reports only and does not change the configuration. Each step links to its own page (**Do this step**, or **Open this step** once done), which does the work with its own confirmations and role checks. If the feature behind a step is temporarily unavailable, that step shows as not done with the sentence *“We could not read this just now; open the page to check.”* The other steps are unaffected. ## Reading it from the API `GET /api/v1/setup` returns the whole mission. Each step has its `step` id, `title`, `goal`, `minutes` (the estimate), `needs`, `done`, `skipped`, `blocked_by` and `outcome` (the sentence). The response also has `done`, `total`, `complete`, and `next`, which is the id of the first step that is neither done nor skipped. The step ids are `sign-in`, `verify-domain`, `branding`, `billing`, `where-agents-run`, `stack-reporting`, `models`, `first-data-source`, `first-agent` and `meet-octy`. ```bash curl -s "https://$AAL_TENANT.atlanticagenticlabs.com/api/v1/setup" \ -H "Authorization: Bearer $AAL_KEY" \ -H "CF-Access-Client-Id: $CF_ACCESS_CLIENT_ID" \ -H "CF-Access-Client-Secret: $CF_ACCESS_CLIENT_SECRET" \ | jq '{done, total, next, steps: [.steps[] | {step, done, outcome}]}' ``` Reading the mission needs `viewer` or above, so the quickstart’s read-only key is enough. See [Me and preferences](/api/reference/people-and-preferences/). Leaving a step for later is `PUT /api/v1/setup/{step}` with the body `{"skipped": true}` (or `false` to take it up again). It returns the refreshed mission, and is recorded in the audit trail as `setup_step_skipped` or `setup_step_resumed`. This route accepts only a person signed in to the portal with the `client_admin` role. An API key, or a delegated token from the CLI or an MCP client, is refused with `403 role_required`, whatever role it carries. In practice, use **Leave for later** in the portal. Other errors: | Status and code | Cause | | --------------- | ----------------------------------------------------------- | | `404 not_found` | The step id is not one of the ten | | `422 invalid` | The body is not `{"skipped": true}` or `{"skipped": false}` | See [Authentication](/api/authentication/) and [Roles](/api/roles/). The mission is also an MCP tool, [`setup`](/mcp/tools/setup/), so you can ask an assistant “What is left to set up?” and get the outcome sentences back. The tool only reads. ## When you are finished `complete` becomes `true` when every step is either done or left for later, and the mission’s summary reads **Your estate is set up**. Next: - **Watch a run**: **Agents → Activity** shows each run live, and the [run map](/build/run-map/) shows every step, its model, its cost and any sign-off. - **Add more sources**: [Connect your estate](/connect/). - **Set a limit before you need one**: [Limits and alerts](/operations/limits-and-alerts/). - **See what a reviewer or regulator can be given**: [Evidence](/concepts/evidence/) and [Trust](/trust/). Source: https://docs.atlanticagenticlabs.com/start/setup/