Define the job
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.
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 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:- What changes? Name the exact target, configuration or resource revision, procedure and arguments. Identify the system that owns its desired state.
- Why this change? Link the supporting and contrary evidence, expected benefit and uncertainty. Separate a measured fact from a hypothesis.
- Who can execute it? Identify the native principal, current permissions and any required customer approval.
- What can it affect? Include shared resources, other services, cost and operational dependencies.
- When must it stop? Specify preconditions, expiry, time and consumption limits, stopping conditions and recovery or rollback steps.
- What establishes the outcome? Define independent observations for success, no improvement, regression and an uncertain outcome.
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. 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 dedicatedt9 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 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.