> ## 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. # Operations with Agents > See how Cloud Adapter's agents investigate, retain evidence and work with your team and Tensor9. ![Observe the selected Cloud Adapter, propose bounded work, obtain customer review, and verify authorized execution. Commentary, authority and recovery evidence are distinct.](https://mintcdn.com/tensor9/ufP2gYsEkScmc1Bt/images/cloud-adapter-early-access/diagrams/agents/operations-hero-responsive-wide-dark.svg?fit=max\&auto=format\&n=ufP2gYsEkScmc1Bt\&q=85\&s=8de5501a667426fbfbcff95969681614) ![Observe the selected Cloud Adapter, propose bounded work, obtain customer review, and verify authorized execution. Commentary, authority and recovery evidence are distinct.](https://mintcdn.com/tensor9/ufP2gYsEkScmc1Bt/images/cloud-adapter-early-access/diagrams/agents/operations-hero-responsive-wide-light.svg?fit=max\&auto=format\&n=ufP2gYsEkScmc1Bt\&q=85\&s=72bb8890ac1dc19b8568c2985daab76a) ![Observe the selected Cloud Adapter, propose bounded work, obtain customer review, and verify authorized execution. Commentary, authority and recovery evidence are distinct.](https://mintcdn.com/tensor9/ufP2gYsEkScmc1Bt/images/cloud-adapter-early-access/diagrams/agents/operations-hero-responsive-stacked-dark.svg?fit=max\&auto=format\&n=ufP2gYsEkScmc1Bt\&q=85\&s=aca6759aec0fe677cca0cadf095a3979) ![Observe the selected Cloud Adapter, propose bounded work, obtain customer review, and verify authorized execution. Commentary, authority and recovery evidence are distinct.](https://mintcdn.com/tensor9/ufP2gYsEkScmc1Bt/images/cloud-adapter-early-access/diagrams/agents/operations-hero-responsive-stacked-light.svg?fit=max\&auto=format\&n=ufP2gYsEkScmc1Bt\&q=85\&s=ff37e27b05b438198e8844d0d130d28b) Cloud Adapter comes bundled with agents for support and operations. They help operate a specific Cloud Adapter and the services it adapts: establish what is running, investigate a question, compare evidence, propose the next step and verify an authorized change. You can work with the included agents, your own agents and Tensor9 specialists in the same investigation. The operating model has two workspaces and a shared meeting place. Your team and agents keep their tools, conversations and working evidence private. Tensor9's support agents investigate in Tensor9's own workspace. A **War Room** connects named participants around one incident or activity, with the findings you choose to share. The agent bus keeps permitted work and updates recoverable across those workspaces. ## Start with the Cloud Adapter you operate Operations begins with one selected Cloud Adapter, its customer environment and its exact configuration. That scope follows the work into agent tasks, incidents, War Rooms and proposed changes. A finding about your test deployment does not become a finding about production, and an assessment of an earlier configuration does not silently apply to a newer one. Keep three kinds of information distinct: | Information | What it tells you | | - | - | | Declared configuration | The services and backends you intend to use, including explicit and inherited mappings. | | Runtime observation | What an authorized check observed at a particular time, with the relevant runtime and resource identity. | | Agent explanation or proposal | An interpretation of evidence, unresolved questions or a suggested next action. | The configuration-assessment agent checks the retained definition and its effective service roster. Its result can identify mapping requirements and missing checks. It does not measure queue latency, establish current reachability or prove that a deployed service is healthy. Those conclusions need their own authorized observations. See [Adapter Configuration](https://docs.tensor9.com/cloud-adapter-early-access/configuration/overview.md). ## The moving parts | Part | What it does for the investigation | | - | - | | Agent | Takes a defined job, uses its permitted tools and records findings with their sources. An observed instance identifies where that agent is actually executing. | | Swarm | Organizes agents around a goal. For example, one examines Cloud Adapter behavior while another examines workload changes. Each keeps its own identity, tools and limits. | | Work record | Retains the question, exact target, permitted inputs, progress, findings and outcome. It distinguishes queued work, accepted execution and a completed result. | | Agent bus | Carries authorized work and evidence updates from durable records. It lets participants catch up after interruption without treating a notification as the result. | | War Room | Gives named customer and Tensor9 participants a shared timeline for selected questions, evidence, proposals and verification. | | Approval and executor | Separate the decision to make a change from the native identity that can perform that exact change. | A swarm is private to its organization. A War Room is where organizations collaborate. Adding a Tensor9 participant to a room does not add that participant to your private swarm or disclose its working history. ## How an agent takes work Give the agent a question and a bounded operating profile: the selected Cloud Adapter, permitted evidence and tools, processing choices, time and consumption limits, and a stopping condition. A task can begin as a private assessment or as a directed request to an admitted agent in a War Room. The work is recorded before execution. The agent uses the original target and configuration, records the observations it obtained, and returns a conclusion with limitations and a next check. Current permission and target checks still apply when the work starts and when its result is made available. A changed target, expired access or exhausted allowance stops further work rather than expanding the job. Not every event needs a model call. A configuration tool can produce a useful assessment on its own. When reasoning uses a model provider, the exact input, processor, purpose, payer and limits are a separate decision. Model commentary remains distinguishable from the tool observations it explains. [Agents and Permissions](https://docs.tensor9.com/cloud-adapter-early-access/operations/agents.md) describes the choices. ## How the bus keeps the investigation connected The bus separates **durable history** from **notifications**. A retained record says that a task was accepted, a finding was produced or selected evidence was released. A notification tells an authorized participant that there may be something new to retrieve. Duplicate or missing notifications do not create a second task or change the original outcome. Each organization consumes its own private work and the shared records currently permitted to it. Shared records are deliberate publications, not a mirror of both organizations' private logs. A newly admitted participant receives only the history authorized for that participant. When a participant starts or reconnects, its trusted client obtains a permitted snapshot and catches up with later updates. The local view retains a checkpoint so an interruption can resume from known progress. Rebuilding a view replays records; it does not rerun tools, send another model request or repeat a resource change. Observation times remain the original times, so catching up does not make old evidence fresh. Your application's request path does not wait for an agent conversation or a Tensor9 support response. Agent coordination can be unavailable while the application continues serving. Recovery of the affected service still needs its own observations and permitted operating path. ## Worked example: queue processing is getting slower Suppose `checkout-events` uses an adapted SQS service in Google Cloud. Your team reports that work is waiting longer before completion. ### 1. Establish the incident and the question Record the affected Cloud Adapter, service, configuration revision, time window and application impact. This is a human report of a symptom, not proof of a service failure. Use the incident's War Room to keep the investigation and its decisions together; it can initially contain only your own participants. ### 2. Ask for the smallest useful observations The included agent checks the configured mapping and effective service roster. Your permitted runtime checks compare queue age, time spent processing each job and backend request latency over the same time window. The [Support Agents queue example](https://docs.tensor9.com/cloud-adapter-early-access/support/agents.md#worked-example-duplicate-queue-jobs) shows how processing duration and visibility settings can suggest a specific next check. Your own SRE agent can examine a recent workload change under its separate permissions. The agents compare those sources rather than infer health from configuration compatibility. A missing observation remains missing. A timing correlation becomes a hypothesis to test, not an established cause. ### 3. Bring Tensor9 into the selected work If the evidence points to an adaptation question, invite a named Tensor9 investigator; after the recipient accepts, admit the participant to the room. Release the relevant configuration findings and reviewed diagnostic derivatives for that investigation. Message bodies, credentials, unrelated logs and private agent conversations stay out of the shared record. Tensor9's support agent can investigate the released material in its own workspace and return a question, explanation or proposal. Sharing evidence with a room participant does not automatically authorize sending it to that participant's model provider. See [War Rooms](https://docs.tensor9.com/cloud-adapter-early-access/operations/war-rooms.md). ### 4. Review a proposal before changing resources A proposal identifies the exact candidate setting or procedure, target revision, expected benefit, cost, preconditions, rollback or recovery steps, and measurements that would show whether it helped. The customer decides whether to approve it. An authorized executor applies only the permitted change through the environment's authoritative configuration or operating procedure. ### 5. Verify recovery in the customer environment Repeat the relevant observations against the changed target. Compare equivalent workloads and time windows when performance is the question. A successful Tensor9 reproduction, accepted recommendation or completed command does not establish that your application recovered. Keep the task result, action result and recovery observation separate. If a response was lost after a possible change, retain the original operation as **Unknown** and inspect the target before considering another attempt. [Bounded Work and Approval](https://docs.tensor9.com/cloud-adapter-early-access/operations/bounded-work.md) explains this lifecycle. ## Use the right workspace for the question | Work | Focus | Continue with | | - | - | - | | Support | Understand the adapter, organize evidence and get the right help. | [Support Agents](https://docs.tensor9.com/cloud-adapter-early-access/support/agents.md) | | Operations | Own, perform and verify a scoped task against a named environment. | This section | | Debugging | Distinguish possible causes using request and service evidence. | [Debugging with Agents](https://docs.tensor9.com/cloud-adapter-early-access/debugging/agents.md) | | Tuning | Compare a supported change with a measured workload and its cost and reliability requirements. | [Tuning with Agents](https://docs.tensor9.com/cloud-adapter-early-access/tuning/agents.md) | Operations groups incidents, War Rooms and planned activities. Agent management identifies the configured agents, observed instances and swarms contributing to that work. Routine assessments and maintenance can have private work records without inventing an incident. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.