Traces - Invoke

Every action that goes through Invoke is recorded in your workspace’s ledger as it happens: who asked, what each check decided, what the tool returned, and who looked at it afterwards. A trace reads that record back as one run.

Reading a run

const read = await invoke.call({ tool: "linear.get_issue", params: { issue_id: "DRA-8" } })
const run = await invoke.trace(read)

for (const stage of run.stages) console.log(stage.label, stage.value, "—", stage.detail)

This is a real run from production, exactly as Invoke reported it:

✓ Agent     coding-agent         claude-code · may use linear.get_issue, linear.update_issue · cap $1.00
✓ Identity  key-bound            coding-agent's own key inv_live_AW8...wUWk · linear.get_issue is on coding-agent's allowlist
✓ Task      DRA-8                claimed by coding-agent · exclusive · task now done
✓ Context   issue state          DRA-8 · Done · High · v3 · read via receipt #e59a65d7
! Policy    allowed              no policy matched · default allow (0 evaluated)
✓ Budget    reserved             $0.0010 held at admission → committed · workspace $4.9910 left · coding-agent $0.9950 left
✓ Action    linear.get_issue     DRA-8
✓ Result    committed            142 ms · via gateway
✓ Receipt   #746787e1            HMAC-SHA256 · signature verified
· Trace     not seen yet         no other agent has read it since the commit · 63 ledger events

The Policy stage is flagged: nothing in the workspace governed this read, so it ran on the default allow. A trace shows gaps like that as plainly as passes.

The stages

Each stage has a label, a value, a detail and a state (ok, warn, fail, skip or pending):

Stage	What it answers
Agent	Who acted, and what that agent may use and spend
Identity	How we know: its own key (key-bound), or a name the caller gave (asserted)
Task	The work item the action belongs to, and who holds its claim
Context	What the agent read before acting, and from which receipt
Policy	Which policy decided, and how
Budget	What was reserved, and whether it was committed or released
Action	The tool and the change it asked for
Result	What happened: committed, failed or unknown, how long it took, and what the tool reported
Receipt	The receipt, and whether its signature still verifies
Trace	Who has read the result since

run.events holds the ledger events behind the stages, in order. Among them: admission.denied (a check refused the action), budget.reserved, policy.matched, approval.requested, effect.committed, effect.failed with budget.released, effect.unknown, and effect.replayed (a repeat answered with the original receipt).

Where to read traces

The SDK. invoke.trace(result), or invoke.trace(effectId) for any earlier action.
The console. Every run, with the same stages.
The CLI. invoke inspect last shows a run’s pipeline, cost and ledger slice.

Next steps

How It Works: the checks behind each stage
Approvals: the approval stages of a run
Reconciliation: what an unknown result means