> ## 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. # Bounded Work and Approval > Follow a task from its recorded scope through investigation, exact approval, execution and independent verification. Cloud Adapter's agents take bounded work: one question, an identified target, selected inputs, permitted tools and a stopping condition. The work record carries that scope through investigation and collaboration. If the investigation leads to a change, the proposal, approval, execution and recovery observation remain distinct steps. ## Define the job | Field | Example | | - | - | | Target | `checkout-events`, its customer environment and exact Cloud Adapter configuration revision. | | Question | Which observations would distinguish a mapping problem, a workload change and a capacity constraint? | | Evidence | Configuration assessment, effective roster and the separately permitted runtime observations for the incident window. | | Tools | Named read-only checks; no write or resource change. | | Processing | Tool-only, or a separately approved exact model input and processing route. | | Limits | Duration, evidence volume and any permitted model consumption. | | Completion | Evidence-linked findings, uncertainty and the next discriminating check. | | Stop condition | Target changed, authority expired, allowance exhausted or required evidence unavailable. | Enforce these restrictions through current identities, tools and access controls. A task description explains the job; a prompt does not create permission. The same brief is useful when a person performs a step. ## Record work before executing it The work record exists before execution begins. It retains the original target, input revisions, request identity and limits. The dispatcher accepts only currently eligible work and records its attempt before calling the tool. Waking a worker does not establish that the job was accepted, completed or disclosed to another participant. For the configuration tool, the result describes the retained Cloud Adapter definition and effective service roster. A changed configuration needs a new assessment. An earlier success cannot be reassigned to the newer definition. | Work state | How to interpret it | | - | - | | Queued | The request is retained and awaits current admission. | | Running | An original attempt has accepted execution. | | Cancelling | Cancellation was requested; in-flight work is not yet proven stopped. | | Succeeded | The task produced its required result within its stated scope. | | Failed | The attempt produced a known failure. | | Cancelled | The work reached its confirmed cancellation outcome. | | Unknown | The original attempt or outcome needs reconciliation. A retry is not automatically safe. | A successful configuration assessment is not a healthy-service observation. Likewise, successful message delivery does not establish successful work. Follow the retained work record and its supporting evidence. ## Approve reasoning over selected evidence A tool-only result can be reviewed without model processing. To ask a model to interpret it, review the selected evidence and its processing terms: the input, processor, purpose, payer, allowance and expiry. Approving one result does not automatically cover later evidence, a different processor or a changed processing policy. The workflow reserves the approved model allowance before dispatch. An authoritative usage receipt reconciles actual consumption and the unused allowance. If dispatch may have happened but the outcome was lost, the unresolved reservation remains attached to the original attempt. Cancellation, room closure, closing a session or removing an agent runtime do not establish that the provider processed nothing. Model commentary stays separate from tool observations. It can suggest a hypothesis or proposal; it cannot approve its own action or establish that a resource changed. [Agents and Permissions](https://docs.tensor9.com/cloud-adapter/operations/agents.md) explains how tool, model and native identities fit together. ## Turn a finding into an exact proposal A change proposal should answer these questions before approval: 1. **What changes?** Name the exact target, configuration or resource revision, procedure and arguments. Identify the system that owns its desired state. 2. **Why this change?** Link the supporting and contrary evidence, expected benefit and uncertainty. Separate a measured fact from a hypothesis. 3. **Who can execute it?** Identify the native principal, current permissions and any required customer approval. 4. **What can it affect?** Include shared resources, other services, cost and operational dependencies. 5. **When must it stop?** Specify preconditions, expiry, time and consumption limits, stopping conditions and recovery or rollback steps. 6. **What establishes the outcome?** Define independent observations for success, no improvement, regression and an uncertain outcome. The customer's policy determines whether a narrowly defined procedure can be preauthorized or needs a human decision. A room message, model suggestion or configuration assessment cannot supply that approval. Changing the target, arguments or procedure requires a fresh decision; an approval is not a reusable authorization for similar work. ## Execute through the current owner At execution, recheck the exact target and current authority. An earlier approval cannot override a later withdrawal or a changed resource. The native executor uses the environment's applicable permissions and records the original attempt and actual response. Keep lasting changes in the authoritative configuration workflow. If a controller, operator or infrastructure definition owns a setting, update its permitted input rather than create a second writer that competes with it. A proposed rollback also needs current authority and must account for effects that cannot be undone, such as work already completed by the application. If the task affects a shared dependency, assess and coordinate that whole effect before execution. Do not keep changing resources after discovering a dependency outside the approved scope. ## Verify using new observations Repeat the affected assessment after a configuration change. After a runtime or target change, observe the actual affected service independently. For performance work, compare equivalent workloads and time windows, including correctness, cost and recovery behavior. See [Tuning with Agents](https://docs.tensor9.com/cloud-adapter/tuning/agents.md). For the queue example, an approved capacity or consumer change needs fresh queue, processing and backend measurements. A completed command is evidence of its own result, not proof that the reported latency improved. Record the work conclusion, action outcome and recovery observation separately. ## Reconcile an uncertain outcome before retrying A timeout after a possible write leaves an uncertain original outcome. Preserve its request and operation identity, inspect target state through an authorized read and decide whether another attempt is eligible. Reconnection, message redelivery or a process restart must not create another copy of the original effect. For an AWS SDK operation, keep the native response and any Explain receipt. Where your installed adapter supports the dedicated `t9` service, retrieve the explanation separately with the original request owner's authorized IAM credentials, including the same temporary session where applicable, and SigV4 signing name `t9`. A report identifier alone grants no access; retrieving the report does not replay the operation. See [Explaining SDK Requests](https://docs.tensor9.com/cloud-adapter/debugging/explain-sdk.md) for the exact endpoint, signing settings and retrieval procedure. Use the report's returned expiry as the deadline. Report lifetime starts at creation, defaults to 24 hours and is not renewed by reading. An explanation can be incomplete even when the native service operation succeeds. ## Continue safely when the bus is unavailable The bus carries coordination updates; it is not a substitute for the target's current authority or original operation record. Losing the bus does not grant broader tools or make an old approval current. Use an independently authorized local diagnostic or repair path when its required policy, credentials, procedure, conflict control and durable audit are available without the failed service. If a required dependency is unavailable, stop that action and record what is missing. Do not launch a competing repair merely because the original worker stopped responding. After connectivity returns, import the retained local observations and original operation references into the investigation. Catch-up reconstructs the history and its unresolved questions. It does not rerun the repair, clear uncertainty or establish recovery without new evidence. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.