Give the agent a concrete question
Useful context includes the Cloud Adapter and configuration revision, the origin service and selected backend, the affected operation, and the time window. Add the expected behavior, what you observed and the effect on your application. Configuration assessment and the effective service roster help establish which mappings the configuration describes. Request results, Explain reports, target-service observations and workload measurements answer different questions. A compatible configuration alone does not establish that the target is healthy, credentials work or capacity is sufficient. For request investigations, preserve the native response and any Explain receipt before retrying. Use Getting Help to prepare a useful evidence bundle. Keep originals private and provide reviewed copies when sharing. An agent should identify missing evidence explicitly and propose a bounded way to obtain it.Choose the right kind of work
A support investigation can lead to any of these. Keep the original question and evidence attached when the work changes. A diagnosis, a tuning recommendation and permission to change a resource remain separate decisions.
Keep diagnosis bounded
Agree on the question, permitted evidence, allowed reads, time limit and stopping condition. Start with the smallest observation that can distinguish the likely causes. For example, check the effective queue backend and visibility setting before proposing more infrastructure. An agent’s access follows its configured tools and the native identity used for each operation. Bundling an agent with Cloud Adapter does not give Tensor9 unrestricted access to your target environment. Reading a configuration, retrieving an owner-protected report and changing a target resource each require the appropriate authority. A report identifier alone does not grant access. Model processing also needs an approved input, processor, purpose and budget. Selecting who pays does not authorize disclosure. Model output is commentary to evaluate alongside tool evidence; it is not a configuration observation or approval. See Agents and Permissions for these controls.Worked example: duplicate queue jobs
Suppose your notification workers sometimes process the same job twice. The affected queue uses the SQS Standard mapping to Google Pub/Sub. You have observed jobs taking roughly three minutes, while the queue’s effective visibility timeout is two minutes.- Establish the case. Identify the actual queue and backend, adapter version, relevant configuration revision and incident window. Preserve representative job IDs, receive times, completion times, acknowledgment results and any request receipts. Keep message bodies private unless their contents are necessary and approved for the investigation.
- Compare the evidence. The configuration identifies the intended mapping; an authorized queue read confirms its effective setting. Compare the processing interval with each receive’s actual visibility duration, including per-request overrides or lease extensions. A two-minute lease can expire before a three-minute job finishes, but timing alone does not prove the cause of every duplicate. Check acknowledgment failures, consumer retries and the application’s idempotency behavior too.
- Propose the next step. A bounded test might compare the current lease with a supported longer lease while keeping the workload and consumer count fixed. A longer lease also delays recovery after a worker crashes. Review that tradeoff and the backend’s limits in Tuning AWS SQS before approving a change. Standard queues still require duplicate-safe processing.
- Verify the result. After an approved test, compare successful jobs, duplicate effects, latency, retries and recovery behavior. Restoring the old setting does not undo completed business actions or release every outstanding claim. Record what was changed, what was observed and which questions remain open.