Inspect the audit worklog

The worklog is the primary source of evidence for what an agent did and why. This guide shows how to query it and what to look for when investigating a specific interaction.

What you can query by

The worklog is indexed by the same dimensions used across observability signals:

task_id — a single inference run.
session_id — a full conversation.
assistant_id — the agent.
agentspace_id — the organizational boundary.
user_id — the caller or channel sender.
Time range.

Start with the task_id when you need the complete story of one request.

Read a task’s worklog

Find the task identifier. It is returned to the caller when an inference starts and appears in traces and logs.
Query the worklog by task_id using the runtime API, database query, or your observability platform.
Walk through events in order. Each command and response shows one step of the execution loop.
Look for key events: shield verdicts, tool calls, LLM outputs, approval requests, and memory flushes.
Correlate with traces and logs using the same identifiers when you need timing or infrastructure context.

What to look for

Question	Where in the worklog
What did the user ask?	The incoming request event.
Did a shield block or flag the request?	Shield inference response events.
Which tools were called and with what inputs?	Tool execution commands and responses.
What did the LLM return at each step?	Response inference responses.
Was an approval requested?	Human approval required and response events.
How did memory affect the answer?	Context flush and persistence events.

Export and archive

For compliance, you may need to export worklog data periodically. Options include:

Database backups and point-in-time recovery.
Scheduled exports to object storage.
Streaming changes to a SIEM or data warehouse.

Set retention and encryption policies that match your regulatory requirements.