Tracking AI-agent task execution across a small development team

Feedback General
,
1

I’ve been exploring how small teams can keep AI-agent work visible without creating another disconnected workflow.

Imagine this setup:

  • A developer creates a task.

  • An AI coding agent receives the assignment.

  • The agent executes the task using its connected coding Runtime.

  • Progress, blockers, and results are recorded.

  • A human reviews the output before accepting it.

The challenge is not only triggering an agent. It’s keeping the task context and execution status visible to everyone.

Sharkly.ai approaches this through a shared task workspace where both people and agents can be assignees. It can be used alongside automation tools, although I’m not claiming a native n8n integration.

A possible n8n workflow would be to receive task-status events through a webhook, log them in a database or spreadsheet, and notify a team channel when an agent is blocked.

For small teams, Sharkly currently offers its full product free for up to five people. Model execution still uses the team’s own connected coding plan or API account.

How are you currently tracking agent runs and failures in n8n workflows?

2

Hi @Herve_Kom1, good framing — the hard part really is visibility, not just triggering the run.

The pattern I use in n8n is to treat every agent run as a first-class record, not as a log line buried inside an execution:

  1. One webhook per status event — started, progress, blocked, failed, completed — carrying task_id, run_id, agent, status, and a short error or blocker note. Each event appends to a table (a spreadsheet works fine for a small team), and a second view shows only the latest status per task_id, so the team always sees the current state without digging through executions.
  2. A heartbeat / stale-run check — a scheduled workflow that flags any run still showing as “running” past its expected window. That catches the silent failures that never send a “failed” event, which in my experience are the ones that actually slip through.
  3. A human review gate before “accepted” — the agent’s output lands as “ready for review”, and only a human approval moves it to accepted. That keeps the audit trail clean: attempted, reviewed, and accepted are three different states, not one vague “done”.

For a small team, I would keep it boring on purpose: one table, one status webhook, and one daily digest of blocked and stale runs to the team channel. The fancy dashboard can wait until the statuses themselves are reliable.

Curious — are your agents reporting back over HTTP today, or would that status webhook be a new piece to add?