How Agento Tracks Agent Tasks: From Turn to Dashboard

Your agent processed 247 leads today. It ran 89 competitor checks. It delivered 31 morning briefings.

Until now, you'd have no idea. Agento tracked tokens, costs, CPU, and memory, but the most important metric was missing: how many tasks did my agent actually complete?

We just shipped task tracking. Here's how it works and why it was harder than it sounds.

What Counts as a Task?

A "task" in Agento is one complete turn: user sends a message, agent responds. This maps directly to how LLM APIs work. One user prompt in, one assistant response out.

We considered counting tool calls, sessions, or messages, but turns are the cleanest signal. One turn means one unit of work. Five tool calls within a single turn is still one task, just a complex one.

The Sliding Window Problem

OpenClaw (the runtime that powers every Agento agent) writes session data to JSONL files. But these files use a 100-line sliding window. After compactions and long conversations, older turns scroll off the end of the file and are gone.

If you count assistant messages in the JSONL, you get the turns visible in that window, not the total. An agent that processed 500 tasks might only show 12 in its current session file.

Stats.json: The Cumulative Counter

The fix is simple: keep a separate counter. After every turn, we write a stats.json file with cumulative counts:

• Turns completed
• Sessions started
• Tool calls made
• Errors encountered
• First and last activity timestamps

The file lives inside the agent's state directory, which is volume-mounted. It survives container restarts, image upgrades, and session resets. One atomic write per turn, using the same tmp-file-plus-rename pattern that prevents corruption if the process crashes mid-write.

Four Hops to Your Dashboard

The count travels through four systems before you see it:

1. OpenClaw writes stats.json after each turn. Fire-and-forget. If the write fails, the agent keeps working normally.

2. agentod reads stats.json from the container every 30 seconds via Docker exec. If the file exists, it uses the cumulative turn count. If not, it falls back to counting assistant messages in the JSONL window. The count goes into Redis alongside all the other session metrics.

3. The metrics collector picks up the turn count from Redis, computes the delta since the last collection (same logic as tokens and cost), and inserts it into ClickHouse. This gives us time-series data: how many turns happened in each 30-second interval.

4. The orchestrator API queries ClickHouse with conditional SUMs to produce time-windowed counts: tasks today, this week, this month. The frontend fetches this and displays it on your agent card.

Adaptive Display

Not every agent runs every day. Showing "0 tasks today" for a weekly cron agent would be misleading. So the display adapts:

• If there are tasks today, show "47 tasks today"
• If today is zero but this week has data, show "12 tasks this week"
• If the week is zero too, fall back to "3 tasks this month"
• If nothing at all, don't show the metric

This way the number is always meaningful. You see recency-appropriate activity.

Delta Tracking

The trickiest part is delta computation. ClickHouse stores incremental metrics, not cumulative totals. If your agent has 500 total turns and we just inserted 500 every 30 seconds, the historical sum would be wildly wrong.

Instead, the metrics collector remembers the last snapshot. If the previous collection saw 498 turns and the current one sees 500, the delta is 2. That "2" is what goes into ClickHouse. Sum all the deltas and you get the true total.

This is the same pattern we use for tokens and cost. Turns just slot into the existing pipeline.

What's Next

Task counts are the foundation. With time-series turn data in ClickHouse, we can build:

• Activity charts on the agent detail page
• Alerts when an agent goes silent (zero turns for X hours)
• Usage reports for billing and capacity planning

The data is flowing. The dashboard is live. Go check your agents.