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, 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.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:
Keep unobserved distinct from healthy, and Unknown distinct from a confirmed failure or success. See Debugging with Agents for request investigations and Tuning with Agents for measured comparisons.