Agent Inspect

/agent-inspect — Deep Task Inspection

When a task is weird, this is where you go.

Prerequisites

Endpoints used (adapt to your agent's API):

• GET /api/tasks/:id — task metadata
• GET /api/tasks/:id/log — execution log
• GET /api/tasks/:id/events — event stream
• GET /api/tasks/:id/review — review verdict (if your agent runs review)
• GET /api/tasks/:id/deps — task dependencies / dependents

Usage

/agent-inspect <task-id>

Workflow

1. Pull metadata

curl -s -H "Authorization: Bearer $AGENT_API_TOKEN" \
  "$AGENT_API_URL/api/tasks/<task-id>" | jq

Capture: status, prompt, model, project, created_at, updated_at, attempt count, parent task (if subtask), priority, cost.

2. Pull events timeline

curl -s -H "Authorization: Bearer $AGENT_API_TOKEN" \
  "$AGENT_API_URL/api/tasks/<task-id>/events" | jq

Build a timeline. Look for:

• State transitions (queued → running → review → done/failed)
• Retry attempts
• Worker reassignments
• Review pass/fail rounds
• External events (was the agent restarted? did the worker die?)

3. Pull log

curl -s -H "Authorization: Bearer $AGENT_API_TOKEN" \
  "$AGENT_API_URL/api/tasks/<task-id>/log"

Read the last 100 lines for failures. For successful but mysterious tasks, scan for unusual patterns: long pauses, retries, tool errors, low-confidence verdicts.

4. Pull review verdict (if applicable)

If your agent runs review on output:

curl -s -H "Authorization: Bearer $AGENT_API_TOKEN" \
  "$AGENT_API_URL/api/tasks/<task-id>/review"

Capture: verdict (PASS/WARN/FAIL/NEEDS_REVIEW), reviewer model, specific issues raised.

5. Pull dependency graph

curl -s -H "Authorization: Bearer $AGENT_API_TOKEN" \
  "$AGENT_API_URL/api/tasks/<task-id>/deps"

Identify:

• Parent task (if this is a subtask)
• Sibling subtasks (other subtasks of the same parent)
• Dependent tasks (what's waiting on this one)

Output format

TASK INSPECTION — <task-id>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

METADATA
  status:     <state>
  project:    <project>
  model:      <model>
  attempt:    <N> of <max>
  created:    <relative time>
  updated:    <relative time>
  duration:   <total / current>
  cost:       $<amount>
  parent:     <parent-task-id or "—">

PROMPT
  <first 200 chars of prompt; truncate if longer>

TIMELINE
  <ISO time>  queued
  <ISO time>  running (worker <N>)
  <ISO time>  review-requested
  <ISO time>  review-failed (<reason>)
  <ISO time>  retried
  <ISO time>  failed

REVIEW VERDICT
  verdict:    <PASS/WARN/FAIL/NEEDS_REVIEW>
  reviewer:   <model>
  issues:
    • <issue 1>
    • <issue 2>

DEPENDENCIES
  parent:     <parent or "—">
  siblings:   <count>  (passed: <N>, failed: <N>, pending: <N>)
  dependents: <count>  (waiting on this task)

LOG TAIL (last 30 lines)
  [paste last 30 lines, with line numbers]

DIAGNOSIS
  [1-3 sentences synthesizing what likely happened, based on timeline + log + verdict]

RECOMMENDED ACTION
  [specific next step: requeue / dead-letter / amend prompt / fix env / inspect parent]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Diagnostic patterns

Notes

• Don't truncate the log until you've read it. A 500-line log with the answer in line 247 means truncation lies.
• For very long logs (>2000 lines), summarize structurally (count of each event type) and quote only the last 30 lines verbatim.
• If diagnosis is uncertain, say so. Don't fabricate a cause.