Docs

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.

View Markdown

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.send if the investigation leads to using messages.retry.
  • accounts.manage and an appropriate Manager role if jobs.redrive is 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

  1. Call operations_list to find the connection's recent operations.
  2. Call operations_get with the ID to investigate.
  3. Read the operation status, underlying jobs and returned errors.
  4. Cross-check related accounts or messages using permitted read operations.
  5. Classify the situation using the table below.
  6. 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.

  1. Only after an appropriate decision, read the schema for messages.retry or jobs.redrive.
  2. Call messages_retry when appropriate, or tools_run with the code jobs.redrive.
  3. 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.