AI agent playbooks
Investigate a failed job or unclear outcome
Read operation evidence, distinguish held jobs from failed jobs and retry only with supporting evidence and any required confirmation.
Goal
You find out why an operation did not complete and propose an evidence-based response. Do not treat “no success seen yet” as sufficient reason to create another send attempt.
Permissions needed
You need read permissions appropriate to the data involved, such as accounts.read, messages.read or audit.read.
messages.sendif the investigation leads to usingmessages.retry.accounts.manageand an appropriate Manager role ifjobs.redriveis needed.
Do not request retry permissions upfront if your task is only to investigate.
Ask the person before
Ask for the operation ID, time, account and expected result. Ask whether the person has already retried through the web or another system.
Clarify whether the person wants a cause report or recovery. Permission to investigate is not consent to repeat an effect on Telegram.
Check first
Call whoami. Confirm that the operation is within the connection's scope.
operations_list only lists operations initiated by the current connection. Having this tool does not give you a browser for all workspace jobs. For another connection's operation, refer it to an authorized person or use the connection that created the job.
Steps
- Call
operations_listto find the connection's recent operations. - Call
operations_getwith the ID to investigate. - Read the operation status, underlying jobs and returned errors.
- Cross-check related accounts or messages using permitted read operations.
- Classify the situation using the table below.
- Record the evidence and propose the next step.
| Situation | Decision |
|---|---|
| Queued or running | Monitor the existing operation |
held |
Read the reason and when it can resume; do not duplicate the job |
failed or expired |
Investigate the cause, then consider whether to retry |
An unverified job or outcome_unknown operation |
Reconcile; do not resend blindly |
| Already succeeded | Do not run it again “to be sure” |
messages.retry retries messages according to its own rules. jobs.redrive is for eligible dead jobs and creates a new job linked by replay_of. It does not make the old job count as never having run.
- Only after an appropriate decision, read the schema for
messages.retryorjobs.redrive. - Call
messages_retrywhen appropriate, ortools_runwith the codejobs.redrive. - Track the new operation with
operations_get.
Check after
Record both the old and new IDs. Redrive checks current permissions again. The new job still passes through current safety gates, limits and do-not-contact checks.
Do not report successful recovery just because the redrive call was accepted. Wait for the execution result.
On errors
If a rerun is rejected, read the reason instead of changing the payload to force it through. For held, address the hold cause. For an unclear outcome, move to reconciling an unverified send.
When to stop
Stop when you have identified the cause and a response, when the evidence cannot rule out duplicates, or when a person's confirmation is needed but no decision has been received.