Where Octy runs

Octy™ runs inside the organisation’s deployment of the Atlantic Agentic Engine, in its own cloud account, on its own servers or air-gapped, beside its gateway and indexes. Questions, passages and answers are stored in the deployment. LightHouse™ receives counts, timings and costs.

LightHouse: in Atlantic's account

• Limits and cost: the monthly Octy limit, and the cost of its model calls
• Approvals: the cards Octy raises, approved by a person
• Portal Octy: answers from the tenant’s LightHouse data

Operational telemetry; no content

• Telemetry (upward): turns, routes, costs, timings and outcomes
• Signed commands (downward): limits, pauses and releases

Client deployment: wherever the engine runs

• Own cloud: AWS, Azure or Google Cloud, in the chosen region
• Own servers: Docker or Podman, beside the gateway and the knowledge database
• Air-gapped: no network path out; local models on the organisation’s GPUs
• Atlantic-hosted: the same engine, in a dedicated account run for the client

Octy runs in the client deployment, on the organisation's models. Operational telemetry is the only data sent to LightHouse; an air-gapped deployment sends it by file.

Where a profile runs

Each Octy profile runs where its knowledge is held:

Knowledge	Runs on	Reason
The organisation’s knowledge bases, connected sources and uploaded collections	One of the client’s deployments	Content is read in place, in the client’s account. LightHouse does not store it
The tenant’s LightHouse data	Atlantic-hosted	It is the portal’s own data, read under the person’s role
Atlantic’s public documentation and published knowledge	Atlantic-hosted	Atlantic’s own material, for Atlantic’s public profiles

In this table, Atlantic-hosted means that LightHouse answers the profile, in Atlantic’s account. An Atlantic-hosted deployment, run for a client in a dedicated account, counts as one of the client’s deployments. A profile cannot mix knowledge from both places. LightHouse sends a profile to the deployment that runs it as a signed command, or by command file to an air-gapped site, and shows whether the deployment applied it. See How a change reaches your deployment.

The deployment matrix

Where	How Octy runs there	Models	Status
AWS	A private service on the deployment’s load balancer, beside the client stack	Amazon Bedrock or the Claude API, through the gateway	Built
Own servers	The Octy container in the stack LightHouse generates, beside the gateway and the knowledge database. See On-premises	Any provider the gateway reaches, or a local model	Built
Air-gapped	As on the organisation’s own servers, with no network path out	An open-weight model on the organisation’s NVIDIA GPUs	Built
Azure	The same image on Azure Container Apps, behind the stack’s ingress	Azure AI Foundry, through the gateway	The image runs there; the one-click module is Coming
Google Cloud	The same image on Cloud Run, behind the stack’s ingress	Vertex AI, through the gateway	The image runs there; the one-click module is Coming
Atlantic-hosted	As on AWS, in a dedicated account that Atlantic runs for the client. See Atlantic-hosted	As on AWS	Built

In every deployment, Octy holds no provider key. The gateway holds the only model credential, the budgets and the kill switch. The Octy image contains no model SDK.

Air-gapped, on local models

Octy can run with no network path out of the organisation’s environment:

• Local models. An open-weight model runs on the organisation’s NVIDIA GPUs, served by vLLM, or by NVIDIA NIM under the organisation’s licence, and the gateway calls it on the local network. Prompts and answers remain on the organisation’s machines. See Self-hosted models.
• Local knowledge. Documents are indexed into the knowledge database in the organisation’s environment. The embedding model that builds the meaning index runs there too.
• Telemetry by file. The deployment keeps its telemetry as signed, numbered bundle files, which an operator carries to LightHouse. Commands come back in a signed command file. See Air-gapped operation.

With Octy profiles, an air-gapped site operates as follows:

• Profiles by command file. A change to a profile goes into the next command file, and the profile shows as waiting for it in LightHouse. The site applies the file, and the change shows as applied once the site’s next telemetry bundle is imported.
• Local models only. The router’s candidates are the models served on the site. A profile that names any other model is refused by the deployment.
• Question text on site. LightHouse shows counts, outcomes, costs and hashed clusters of equal questions from the imported bundles. The question text is on the site’s own Octy insights page, behind the site’s sign-in. See Question insights.
• Receipts signed on site. Answers are signed with the deployment’s own key and can be verified without a call to Atlantic.

Deployment profiles

Octy works under each deployment profile:

Profile	What it means for Octy
Always-on	Answers at once, at any hour
Ephemeral	Services sleep when idle. The first question after a quiet period wakes Octy, and is answered once it is ready
Scheduled	Warm in the configured wake window, such as working hours; outside it, woken on demand as under ephemeral

While a deployment wakes, the caller receives a notice that Octy is starting and the time after which to ask again. The website widget shows the notice and asks again automatically. On the organisation’s own servers, Octy runs continuously. The cost analysis shows the time of the first answer after a wake for each profile.

For Octy used only in working hours, the scheduled profile answers immediately during the wake window and costs less than always-on, estimated. See Estimated savings against always-on.

Residency

Octy keeps its inference in the region its deployment names. Cross-region model profiles are refused unless the deployment allows them, and the gateway’s policy refuses them again. Documents, indexes and conversations remain in the organisation’s account. See Data sovereignty and Regions.