The set-up mission

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.

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 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	—	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	—	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) 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); 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.

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.

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.
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.

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.

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.

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.

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 and Roles.

The mission is also an MCP tool, 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 shows every step, its model, its cost and any sign-off.
• Add more sources: Connect your estate.
• Set a limit before you need one: Limits and alerts.
• See what a reviewer or regulator can be given: Evidence and Trust.