> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # Architecture > Understand the request path, operational path and state boundaries of Cloud Adapter. Cloud Adapter is a runtime translation layer between software that speaks an origin cloud API and the native services selected for its target environment. The request path stays inside your environment. The local Tensor9 CLI configures and operates that runtime, but does not proxy application traffic. ![An application sends origin API requests through a Cloud Adapter service adapter to native target services. The Tensor9 CLI provides configuration outside the request path.](https://mintcdn.com/tensor9/ufP2gYsEkScmc1Bt/images/cloud-adapter-early-access/diagrams/cloud-adapter-architecture-light.svg?fit=max\&auto=format\&n=ufP2gYsEkScmc1Bt\&q=85\&s=db68ae20fb241ecc611d3aa309a2e00a) ## The request path Each request crosses three adapter stages: 1. **API endpoint.** Your existing SDK, CLI or infrastructure tool sends an origin-shaped request to the configured Cloud Adapter endpoint. 2. **Service adapter.** The selected origin-to-backend mapping interprets the request and translates its supported behavior. 3. **Target client.** Cloud Adapter calls the native target service using the backend identity configured for that mapping. The response follows the reverse path. Cloud Adapter translates the target result into the origin API's response shape. When emitted, [diagnostic response headers](https://docs.tensor9.com/cloud-adapter-early-access/debugging/response-headers.md) can supply correlation identifiers or narrowly defined request-effect evidence. A cloud adapter is therefore composed of service adapters. Each service adapter owns one origin-service-to-backend mapping; the cloud adapter gives those mappings one operating boundary for a particular origin-to-target direction. ## The operations path The local Tensor9 CLI reads the installation's configuration, validates changes and coordinates setup and updates. Configuration has two scopes: * **Cloud adapter configuration** defines settings shared by the installation, such as its origin and target clouds, networking and deployment shape. * **Service adapter configuration** selects a backend and supplies the settings needed for one service mapping. Both scopes feed the runtime, but neither sits in the application request path. This separation lets the CLI stop after an operation while the adapters continue to serve traffic. See [Configuration](https://docs.tensor9.com/cloud-adapter-early-access/configuration/overview.md) and [Deployment](https://docs.tensor9.com/cloud-adapter-early-access/deployment/overview.md). Cloud Adapter's included agents extend this operational workflow. [Support Agents](https://docs.tensor9.com/cloud-adapter-early-access/support/agents.md) investigate questions using permitted configuration and request evidence. [Operations with Agents](https://docs.tensor9.com/cloud-adapter-early-access/operations/overview.md) gives tasks an owner, tool scope, budget and verification record; [War Rooms](https://docs.tensor9.com/cloud-adapter-early-access/operations/war-rooms.md) coordinate admitted participants and selected evidence. These activities remain separate from application request serving. Agent identity, native tool authority, model processing and evidence sharing each retain their own permissions. ## Identity and trust boundaries Cloud Adapter crosses distinct security boundaries. Treat them separately: | Boundary | Governs | | - | - | | Application to adapter | Which callers can reach and use the origin API endpoint. | | Adapter to target service | Which native operations the backend identity can perform. | | Operator to target environment | Which infrastructure and lifecycle changes the local CLI can make. | An origin-shaped request does not inherit permission to the target service. Likewise, a target-cloud credential does not decide who may call the adapter. Apply least privilege independently at each boundary and keep provisioning credentials separate from runtime credentials. ## Where state lives Application data belongs to the selected target service. For example, an S3-to-Cloud Storage adapter stores objects in Cloud Storage; it does not keep a second object copy inside Cloud Adapter. Configuration is another durable input. Keep it under review and change control, because changing a backend can change data ownership and migration requirements even when the file remains syntactically valid. ## How deployment mode changes the topology Both modes use the same service implementations. What changes is where the serving runtime runs: | Mode | Runtime topology | Additional infrastructure | | - | - | - | | [Local development mode](https://docs.tensor9.com/cloud-adapter-early-access/deployment/single-binary.md) | One serving image in local Docker, against your own cloud. The container launcher is pending. | Local Docker and target-cloud resources. | | [Full mode](https://docs.tensor9.com/cloud-adapter-early-access/deployment/provisioned.md) | The serving image in a fabric installed through `tensor9 adapt cloud install`, for development or production. | Target-cloud compute, networking, identity and lifecycle resources. | A mode does not expand a service mapping's operation coverage. The in-memory emulator is separate from both modes. See [deployment modes](https://docs.tensor9.com/cloud-adapter-early-access/deployment/overview.md) for current availability and the pending local launcher. An investigator with the original request owner's IAM credentials can use the [signed SDK report retrieval flow](https://docs.tensor9.com/cloud-adapter-early-access/debugging/explain-sdk.md#retrieve-without-replaying) against the published t9 endpoint and signing region. Decode the outer AWS JSON response's `body` string to read the rendered report. This diagnostic read neither starts an adapter nor changes the original operation. ## Observe a request Use [`tensor9 explain`](https://docs.tensor9.com/cloud-adapter-early-access/debugging/using-explain) to inspect the directed service profile without contacting a deployment. To preview one deployed request, send a normal IAM/SigV4-authenticated request to the synthetic AWS endpoint with a signed `x-t9-explain` control and explicit mode `Explain`. The completed preview returns a native `ExplainedNotPerformed` service error and a report ID; retrieve the explanation separately through the dedicated synthetic AWS `t9` service, with SigV4 signing name `t9` and its configured endpoint and region. During live diagnosis, combine the report with the adapter's [response headers](https://docs.tensor9.com/cloud-adapter-early-access/debugging/response-headers.md), runtime logs and the resulting target-service state. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.