Tracking What Your AI Agents Actually Did

To track what an AI agent actually did, give it its own identity and let the system record its changes - don't rely on its summary. In t0ggles, every agent gets an agent user, and every change it makes through the MCP server lands in the task's change history under that name: the field, the old value, the new value, and the time. Human edits sit in the same timeline. For a board-wide answer, the get-activity-log MCP tool returns the same events across every task.

The rest of this post walks through a real example: one bug task, two agents working on it overnight, and a priority change that never made it into the agent's summary. You will see where each piece of evidence lives, how to check an agent's night in two minutes, and what the board history does not cover. If your agents are not on a board yet, start with How to Give Your AI Agents a Task Board.

#Why the Agent's Summary Is Not Enough

Every coding agent ends a run with a summary: what it fixed, what it tested, where the PR is. Those summaries are useful and mostly accurate. But a summary is the agent's own account of its work, written by the same process that did the work. It covers what the agent thought was worth mentioning, not everything it changed.

That gap matters most for small side effects. An agent that decides a bug is less urgent than you thought, or that the deadline is unrealistic, can change the priority or the due date with one MCP call and not say so. Nothing is broken, the PR is good, and the board now says something you did not decide.

Accountability for AI agents works the same way it does for people on a project team: you trust the report, but you keep a record that does not depend on it.

#Step 1: Give Every Agent Its Own Identity

Attribution is only as good as the identities behind it. If three agents share your MCP token and act as you, the history will say you did everything. So the first step is one agent user per agent role, created in Board Settings > Services > Agent Users: Claude Developer, Claude Reviewer, Claude Planner, or whatever roles your workflow has. Each gets a bot user ID like BOT_CLAUDE_DEVELOPER and its own robot avatar.

The agent then passes that ID on every write:

{
  "name": "update-task",
  "arguments": {
    "boardId": "your-board-id",
    "taskId": "task-id",
    "statusId": "in-review-status-id",
    "assignedUserId": "BOT_CLAUDE_REVIEWER",
    "botUserId": "BOT_CLAUDE_DEVELOPER"
  }
}

botUserId is what puts the agent's name on the change history entry, the comment, and the notification you receive. It is supported on the tools that write: create-task, bulk-create-tasks, update-task, create-note, update-note, and create-comment.

One detail to get right: the ID must belong to an agent user on that board. If it does not, the change is recorded under the owner of the MCP token instead. Put the exact ID in the agent's instructions file (CLAUDE.md, AGENTS.md) or in its t0ggles Crew pipeline settings rather than letting it guess.

#Step 2: Read the Task's Change History

Here is the example. A person filed WEB-12, a high-priority bug due October 14: after a Stripe outage, failed webhooks were all retried at once and backed up the queue. They assigned it to Claude Developer and went home.

Overnight, Claude Developer picked it up, fixed it, and handed it to Claude Reviewer, which reviewed the PR and assigned the task back to the person. In the morning, this is the task's full history (Task details > History icon > Show full history):

Read it bottom to top and the night is reconstructed:

• 02:04 - Claude Developer moved the task from To-Do to In Progress.
• 02:31 - Claude Developer lowered the priority from High to Medium and moved the due date from Oct 14 to Oct 16.
• 02:48 - Claude Developer moved it to In Review and assigned it to Claude Reviewer.
• 03:20 - Claude Reviewer assigned it to the person.
• 09:12 - The person set the priority back to High.

Each entry carries the field, the previous value (struck through), the new value, the time, and the name and avatar of whoever made the change. Agent and human edits share one timeline, so the sequence is never ambiguous.

The full history records changes to the title, description, status, assignee, priority, start date, due date, tags, project, cover image, and every custom property, plus task creation and deletion. Time tracking entries appear there too. The compact view (the default) shows only who created the task, who started it, who finished it, and who touched it last, which is often enough for a quick check.

#Step 3: Compare the Trail With What the Agent Said

Now the comments on the same task:

The comments are good. They name the root cause, the branch, the PR, and the test. What they do not mention is the priority drop or the new due date. The agent may even have had a reason - the fix took longer than expected, or it judged the bug less severe once the cause was clear - but nobody approved that change, and without the history it would have gone unnoticed until the task slipped.

This is the pattern for reviewing agent work: the comment thread is what the agent says it did, the change history is what it actually changed. Read the comments for the reasoning and the artifacts, and skim the history for anything the comments do not explain. Fields worth a second look when an agent changes them:

• Priority and due date - these are planning decisions, and agents tend to adjust them when work turns out bigger than expected.
• Assignee - a task handed to the wrong person or agent stalls silently.
• Project and tags - a task moved out of its project disappears from that team's view.
• Description - an agent that rewrites the acceptance criteria can make its own work pass.

If you want agents to report these changes themselves, say so in their instructions: "If you change a task's priority, due date, assignee, or project, add a comment explaining why." The history is still your check that they did.

#Step 4: Check the Whole Board With the Activity Log

Opening tasks one by one works for one task. For a board with several agents running overnight, ask your assistant instead. The get-activity-log MCP tool returns task events for a board since a given date (the last 7 days by default, up to 200 events, newest first). Here is part of the real response for the example above:

{
  "events": [
    {
      "action": "update",
      "taskKey": "WEB-12",
      "fieldName": "dueDate",
      "oldValue": "2026-10-14",
      "newValue": "2026-10-16",
      "changedAt": "2026-10-12T06:31:09.000Z",
      "changedByEmail": "BOT_CLAUDE_DEVELOPER"
    },
    {
      "action": "update",
      "taskKey": "WEB-12",
      "fieldName": "priority",
      "oldValue": "high",
      "newValue": "medium",
      "changedAt": "2026-10-12T06:31:08.000Z",
      "changedByEmail": "BOT_CLAUDE_DEVELOPER"
    }
  ],
  "count": 8
}

Changes made by people come back with their email, and changes made by agents with the agent's bot user ID. Status and assignee values are IDs, so a good prompt asks the assistant to resolve them with list-statuses and list-users (agent users are included in the users list). A morning check can be a single prompt:

Use the t0ggles MCP server. Call get-activity-log for board <board-id> with
afterDate set to 6pm yesterday. Resolve status and user IDs with list-statuses
and list-users. Summarize what each agent changed, grouped by task. Flag any
change to priority, due date, assignee, or project that is not explained in a
comment on that task (check with list-comments).

That turns "what did the agents do overnight?" into a two-minute read, and the flagged list is exactly the set of tasks worth opening.

The board's Reports view gives the same picture as numbers: Activity Overview has a By User view that ranks the most active users, agent users included, and Workload by Assignee shows how many tasks each agent holds and has finished. A sudden spike for one agent or a pile of open tasks on another is the cue to look closer. On your dashboard, Recent Activity lists the last 14 days of changes you made and changes to tasks assigned to you, with agents named alongside teammates.

#Agent Workflow Tracing: Join the Layers by Task Key

The board history answers "who changed what on the task". A coding agent also leaves traces in two other places, and a full trace needs all three:

The thread that ties them together is the task key. If the agent's instructions say to name the branch WEB-12-webhook-retry-backoff and mention WEB-12 in the PR title, you can go from the board to the code and back without guessing. With the GitHub integration connected, a PR whose branch or title contains the task key is linked to that task, and merging it moves the task to Done. And when agents run through t0ggles Crew, each run is stored with its status, duration, summary, and complete output log, so the question "what exactly did the agent run at 02:31?" has an answer too.

#What the Board History Does Not Capture

An audit trail is only useful if you know its edges. The task change history does not cover everything an agent can touch:

• Comments are attributed to the agent in the comment thread, not as history entries. Edited or deleted comments do not leave a history record.
• Archiving, milestone links, and subtask moves are not field-level history entries. The compact view still shows when a task was archived.
• Code lives in git. The board history tells you the task moved to In Review, not what the diff contains.
• The agent's reasoning and tool calls live in its transcript or run log, not on the board.
• There is no one-click revert. The history keeps every old value, so restoring one is a manual edit, recorded under your name.
• History starts on January 17, 2026. Changes before that date were not collected.

For most teams that is the right split: the board records decisions and handoffs, git records code, and the run log records the session. Trying to make one tool hold all three usually ends with none of them complete.

#A Tracking Checklist for AI Agents

Whatever tools you use, these rules make agent work traceable after the fact:

• One identity per agent role, never a shared account and never yours.
• Every write carries the identity (botUserId in t0ggles), set in instructions, not left to the agent.
• The task key goes everywhere: branch name, commit messages, PR title.
• Agents comment when they change plans, and the history verifies that they did.
• Agents never delete tasks or close their own work. A person moves tasks to Done, so the last entry on every task is a human decision.
• One daily look at the activity log, by prompt or by report, instead of opening every task.

For where to put the human checkpoints in an agent workflow, see Human-in-the-Loop Workflows for Coding Agents. For how this fits next to observability tools, see task management for AI agents.

#Getting Started

1. Create a free t0ggles account and a board for your agents' work.
2. Add an agent user for each agent role in Board Settings > Services.
3. Connect your agent to the t0ggles MCP server and put its bot user ID in its instructions file.
4. Let it work a real task, then open the task's History and switch to the full history.
5. Add the morning activity log prompt above to your routine, or to a scheduled agent run.

The first time an agent's history shows a change its summary did not mention, the habit will stick.

#Frequently Asked Questions