Fill in this page before you schedule the first rollout wave. Nothing in the deployment is hard to obtain. What stalls a rollout is discovering, on the morning of the first wave, that a decision sits somewhere else in the organization, or that the person who can approve an egress entry is away. The inventory below turns that discovery into a form somebody fills in the week before.
Fill in the readiness inventory in one working session, with everyone who holds an answer in the room. The checklist then turns those answers into rows grouped by phase of work. The last section states what the rollout costs in hours.
Each answer changes something downstream. The agent answers decide which machines belong in which wave. The endpoint answers decide the install channel. The network answers decide whether the route is discovered or handed over. The identity answers decide who administers the organization. Where the answer is genuinely none, write “none” rather than nothing, so a later reader can tell an answered question from an unasked one.
| Item | Why it matters |
|---|
| Which agents are in use, and on which machines | The install detects the agents present on a machine and wires each one. Knowing the set in advance tells you which machines belong in which wave. Once an agent reports, the console shows its control level |
| Whether any agent runs somewhere other than a personal workstation | The client is installed once per machine that runs an agent, wherever that machine sits. A build host or a shared workstation running an agent is in scope on the same terms as a laptop |
| Item | Why it matters |
|---|
| Operating system mix and machine counts per operating system | The client installs and runs at user scope on every supported platform, with no administrator rights. The floors are macOS 13, Windows 10 1809 or Windows Server 2019, Ubuntu 20.04 and Debian 10, or later |
| Processor architectures in the fleet | Packages exist for macOS on Apple silicon and Intel, Linux x64 and arm64, and Windows x64. Windows on ARM64 and musl-based Linux distributions such as Alpine are not supported |
| The packaging or configuration channel your organization already operates | Waves 2 and 3 deliver the install through a channel that already reaches these machines. That channel also carries the wave credential from your secret store |
| Whether any wave machines are shared by several people | Install and local state are per user. Each user on a shared machine runs an install of their own |
| Item | Why it matters |
|---|
| Proxy in the path: yes or no | Decides whether the route is discovered at install or handed to it. See Network requirements |
| Proxy scheme: HTTP CONNECT, SOCKS5 or proxy auto-config | All three are supported. A proxy auto-config file is evaluated by the operating system on Windows and macOS. On Linux, set the route explicitly instead |
| Proxy authentication: none, Basic, Kerberos (Negotiate) or NTLM | None, Basic and Negotiate are supported. NTLM is not supported, by design, so an NTLM-only estate plans a Negotiate or unauthenticated path for the client before the first wave |
| TLS inspection: yes or no, and where the interception certificate authority lives | Inspection needs no bypass. The interception root belongs in the operating system trust store, or is supplied as a PEM file at install |
| Whether the model endpoints your agents already reach stay reachable, and are exempt from response buffering and streaming inspection | Your agents reach those endpoints exactly as before. A device that buffers a streamed response makes agent output arrive in one burst |
| Item | Why it matters |
|---|
| The SAML 2.0 identity provider your organization uses | The console authenticates an organization through SAML 2.0. Microsoft Entra ID, Okta, PingOne and Active Directory Federation Services connect this way. Connecting it needs an administrator on both sides |
| Allowed email domains | Allowed domains and invitations together gate who can join the organization |
| Directory for owner lookup: Microsoft Entra ID, Okta, Google Workspace, PingOne or Active Directory | A read-only lookup resolves an agent’s owner to a person. It never creates or removes users. This connection is optional |
| Who holds the owner and admin roles in the console | Console roles run owner, admin, editor, viewer. Invitees start as viewer, and identity settings need admin |
| Item | Why it matters |
|---|
Where the per-wave OPENLATCH_API_KEY is held, and how it reaches a machine without appearing in a script | One key per rollout wave, created in the console and revoked there when the wave completes. Managed installs read it from your secret store as an environment variable. It is never written into a script, a package or a command line |
| Item | Why it matters |
|---|
| The ten wave-1 machines and their owners | Wave 1 runs the developer install path. Named owners let you confirm each machine against the console’s agent record |
| How you will reach OpenLatch during the rollout | Agree the support route before the first wave rather than during it. See Operate |
Every row names where the value comes from and the page it blocks. The four phases are independent, so the console rows and the network rows run in parallel through the same week.
| # | Item | Where it comes from | Blocks |
|---|
| 1 | Organization created in the console | Your OpenLatch contact creates the organization and invites its owner. Accept the invitation from the invited address. Later sign-ins start at app.openlatch.ai with an email step whose browser check needs challenges.cloudflare.com | Configure the organization |
| 2 | SAML connected and tested | Your identity provider’s admin console, for the entity ID, sign-on URL, and certificate or metadata URL. Entered in the console under Settings › SAML SSO | Configure the organization |
| 3 | Allowed email domains set | The same SAML settings as row 2 | Configure the organization |
| 4 | Owner, admin, editor and viewer roles assigned | The console, under Settings › Users. Invitees start as viewer | Configure the organization |
| 5 | Directory chosen for owner lookup, optional | Your directory’s admin console. The lookup is read-only | Configure the organization |
| 6 | Audit trail retention set | The console, under Settings › Audit Trail: 90, 180, 365 or 730 days, or a custom window, with auto-purge and export | Configure the organization |
| 7 | Webhook or Slack notification channel, optional | The console, under Settings › Notification Channels | Configure the organization |
| 8 | Wave credential created and stored | The console, under your account’s API Keys, from a signed-in browser session. Stored in your organization’s secret store | Configure the organization |
| # | Item | Where it comes from | Blocks |
|---|
| 9 | Egress allowlist entry for app.openlatch.ai on TCP 443 approved | Your change process, against the table in Network requirements | Deploy the client |
| 10 | The model endpoints your agents already reach stay reachable, and are exempt from response buffering and streaming inspection | Your proxy or secure web gateway configuration | Deploy the client |
| 11 | Proxy scheme and credential path confirmed | Your proxy configuration, read against the support matrix | Deploy the client |
| 12 | Interception certificate authority available as a PEM file, if the operating system does not already trust it | Your certificate authority’s own export | Deploy the client |
| # | Item | Where it comes from | Blocks |
|---|
| 13 | The agents you intend to cover are installed and signed in on those machines | The machines themselves, confirmed with the person who uses each one | Deploy the client |
| 14 | Install reviewed for the managed route | The managed route in Deploy the client. It reads OPENLATCH_API_KEY from your secret store and never carries it inline | Deploy the client |
| # | Item | Where it comes from | Blocks |
|---|
| 15 | Wave-1 machine list with owners | Your endpoint inventory, cross-checked with the agent owners | Verify and roll out |
| 16 | Developers briefed that some agents ask them to confirm the connection once | Your own rollout communication, sent before the wave starts | Verify and roll out |
| 17 | Support route agreed for the rollout | Operate | Verify and roll out |
| 18 | Rollback owner named | Your own decision: the person who can pause a wave and remove the client from a machine | Verify and roll out |
The client rollout runs in three waves of two weeks each. Wave 1 installs on about ten machines through the developer path. Wave 2 takes about fifty machines through the channel you already operate. Wave 3 extends to the full perimeter and ends in the decision to run it as normal operations.
Effort is front-loaded into the first week, when the organization is set up and the route is proven on one machine of each operating system in the fleet. After that, each wave repeats a procedure that already worked.
| Phase of work | Wave 1 | Wave 2 | Wave 3 | Typical effort |
|---|
| Prepare the console | Connect SAML, set allowed domains and audit retention, invite people, create the wave credential | Rotate the wave credential | Hand over the operating routine | A day in the first week, then a few hours a week |
| Prepare the network | Approve the egress entry and confirm the proxy route | Review the managed route | No further change | Half a day in the first week |
| Prepare the machines | Prove the install on one machine per operating system, then run ten machines through the developer path | Carry the install in the channel you already operate and run the wave | Extend the same channel to the remaining machines | Minutes per machine after the first |
| Confirm and operate | Confirm each installed machine appears in the console’s agent record with an owner | Weekly checkpoint and a managed-route review | Weekly checkpoint, then the decision to run it as normal operations | A weekly checkpoint through the rollout |
- Complete the readiness inventory in one working session before the first wave is scheduled. Every blank cell is a decision somebody will make under time pressure later.
- One egress entry is mandatory:
app.openlatch.ai on TCP 443, outbound. Everything else in the path is your agents’ own traffic, which is unchanged.
- An NTLM-only proxy estate blocks the rollout. Plan a Negotiate or unauthenticated path for the client.
- No administrator rights are needed on a machine. Install and local state are per user, so a machine shared by several people needs an install per user.
- One
OPENLATCH_API_KEY per rollout wave, held in your secret store and revoked in the console when the wave completes. It never appears in a script, a package or a command line.
