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

# Agents and Permissions

> Understand the included agents, private swarms, runtime identities, tools, model processing and budgets.

Cloud Adapter includes agents for support and operations. They work on the selected Cloud Adapter using the context and tools you permit. Your own agent can contribute alongside them, and Tensor9 support can contribute through an admitted War Room. These participants can share a goal while retaining different identities, environments and responsibilities.

## Agent, instance and swarm

A **configured agent** gives a role a stable identity and Cloud Adapter scope. Its definition records how it connects or runs, which tools and processing choices it requests, and its limits. An **instance** is an actual execution observed in an environment, with its own identity and observation time. A requested deployment or connection is not evidence that an instance is running.

A **swarm** groups agents around an objective. For a queue investigation, the included Cloud Adapter agent might assess service mappings while your SRE agent examines workload changes. Their results contribute to the same goal, but each agent still uses its own permitted tools and processing route. Membership does not combine credentials or create new access.

Your private swarm belongs to your organization. Tensor9's support agents belong to Tensor9's workspace. They meet through a [War Room](https://docs.tensor9.com/cloud-adapter/operations/war-rooms.md), not through automatic access to one another's private tasks and conversations.

## Where the work runs

The included target-local agent operates near the Cloud Adapter and its supported services under the customer's granted identity. An externally connected agent operates in its own environment through its approved connection. Connecting an agent and deploying a runtime are separate choices; neither choice transfers all of the customer's native permissions.

Tensor9 supplies the software for the included agents. Package authorship does not give Tensor9 unrestricted access to your target project. What an agent can do depends on its current identity, the tools exposed to it, the exact target and the permissions for the requested operation.

| Choice | What it identifies | What still needs a separate decision |
| - | - | - |
| Provider recipe | How a built-in or customer-supplied agent connects or runs. | Enrollment, actual identity and execution. |
| Configured agent | Owner, role, revision and Cloud Adapter scope. | An observed instance and permission for each job. |
| Runtime instance | An execution in a named environment at an observed time. | Current reachability and continued permission. |
| Tool profile | Permitted reads or procedures on named targets. | Other tools, other environments and broader effects. |
| Model route | Processor, model/account arrangement and payer. | Permission to send the selected evidence for the stated purpose. |
| Budget | Bounds on time, evidence and model use. | Native resource authority and infrastructure spending. |
| Room admission | Participation in a selected shared workspace. | Private context, cloud credentials and resource changes. |

## From a question to a run

A work request identifies the question, target, evidence and limits. The retained work record precedes execution. Before accepting work, the service checks the current agent definition and assignment, the exact Cloud Adapter and the applicable permissions. A retired agent or removed swarm member does not gain permission from an old queued request.

For a configuration assessment, the tool reads the retained definition and resolves its effective service roster. It returns bounded configuration evidence, including selected mapping issues and omissions. It does not execute arbitrary shell commands, probe service health or resize infrastructure.

The result keeps its original source revision and observation time. If the configuration changes while work is queued or running, the old result cannot be relabeled as an assessment of the new configuration. Start a new assessment for the new target when appropriate.

## Local tools and model reasoning are different steps

A tool-only task can complete without sending evidence to a model provider. It can establish what the configured mapping describes, which requirements were checked and which questions remain open.

When you want model reasoning over a result, review the evidence to be sent and the processing terms: the processor, purpose, payer, limits and expiry. The approval applies to that selected input. It does not automatically cover later evidence, another processor or a changed policy. Selecting who pays does not authorize disclosure.

Model output is an explanation or proposal to evaluate against evidence. It cannot turn an unobserved condition into an observation, approve its own recommendation or grant another tool permission. If a room participant wants to use shared evidence with a model provider, that processing needs its own applicable permission too.

## Read the result within its scope

Suppose the configuration assessment finds that an AWS-to-Google Cloud definition meets the checked mapping requirements. That conclusion does not establish that a database exists, credentials work, a queue responds or the workload has enough capacity.

For an operational conclusion, identify the supporting observation:

| Conclusion | Evidence it needs |
| - | - |
| The configuration meets checked mapping requirements. | Assessment of the exact retained definition and effective roster. |
| A target service responded. | An authorized request and its actual result, target and time. |
| A runtime is running a particular build. | A runtime observation identifying that build and its freshness. |
| A change improved queue processing. | Comparable before-and-after workload measurements, including adverse effects and gaps. |

Keep **unobserved** distinct from **healthy**, and **Unknown** distinct from a confirmed failure or success. See [Debugging with Agents](https://docs.tensor9.com/cloud-adapter/debugging/agents.md) for request investigations and [Tuning with Agents](https://docs.tensor9.com/cloud-adapter/tuning/agents.md) for measured comparisons.

## Limits, cancellation and retained charges

A bounded run has limits for duration, evidence and model consumption. The model workflow reserves its approved allowance before dispatch and reconciles it with an authoritative usage receipt. An uncertain model result retains its unresolved reservation until reconciliation; closing a browser, cancelling work or retiring an instance does not prove that no request was processed.

Cancellation stops further eligible work and requests retirement of the current work. It is not evidence that an accepted native request was undone. The work record preserves the original attempt and its outcome or uncertainty. Retrying an uncertain request is a separate decision after readback, not an automatic way to recover a missing response.

Infrastructure costs are separate from model spending. A larger database or additional workers require their own resource owner, cost review and exact change approval. [Bounded Work and Approval](https://docs.tensor9.com/cloud-adapter/operations/bounded-work.md) describes that decision.

## When access changes

Removing an agent, changing its definition, withdrawing room admission or expiring a grant prevents newly ineligible work and disclosures. Reconnecting to a bus or rebuilding a local view rechecks current visibility; an old notification cannot restore removed access.

Keep the history needed to explain accepted work and unresolved outcomes. Current viewers see only what they are permitted to retrieve. Withdrawal can stop later retrieval through the service, but cannot erase material that a recipient already downloaded.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.