Skip to content

Team tasks

A team task is how a team's work stops living only in chat. Someone says "this needs doing", the platform records who needs it, who is doing it, since when and how it ended, and it tells the right person when it stalls. You don't have to remember to chase it.

You ask an agent to create, assign, park or finish a task for you; the agent calls the team task tools. The CLI has hadron team task commands for the same work (from release 0.21.0; parking, making ready and creating straight into the backlog need 0.22.0). The portal has no task views yet.

The two roles on a task: owner and assignee

Every task has exactly one owner and at most one assignee. They are different people on purpose.

  • The owner is who needs the work done. Alarms about the task go to the owner, and the owner decides what to do about them. When you create a task, you are its owner unless you name someone else who takes part in the App.
  • The assignee is who does the work: a worker, a person, or nobody yet.

Only the assignee starts a task, says it is making progress, and finishes it with a result. The owner (and whoever directs the task, see below) can hand the task to someone else, but cannot finish it on the assignee's behalf. That keeps a result honest: it is always set by the one who did the work.

A task can have child tasks. The assignee of a task creates the child tasks it needs, and owns them. A task with no parent is a root task; any participant in the App can create one. While a started task has open children it is waiting on child tasks, which pauses its no-progress alarm, because the work is happening below it.

Where a task is in its life

A task has one of five statuses.

Status What it means
Backlog Parked. Not ready to be worked yet. Nobody is assigned, the platform never picks it up, a parent never waits for it, and it raises no alarms.
Pending Ready to be worked, not started. With nobody assigned it is queued, waiting for the platform to find a worker.
Started The assignee has begun.
Finished Ended with a result: an outcome, a summary and evidence.
Cancelled Ended without being finished.

Finished and cancelled are final. A task that has ended never moves again and its result never changes; follow-up work is a new task that can cite the old one.

You can create a task straight into the backlog. That is the place for "we should do this, but not now": it stays out of every queue and every alarm until someone makes it ready. Making a backlog task ready, or assigning it, makes it pending. A backlog task can also be cancelled directly. A task already in the queue can be parked, but a task that has an assignee cannot.

How a queued task finds a worker

A pending task with no assignee is queued. The platform assigns it to the worker who is free, has the role the task asks for, is in the model families it allows (or not in the ones it excludes), and was assigned work least recently. Right now only workers with a live session are matched. If you would rather choose, assign it yourself.

Who may direct a task

Assigning, reassigning, cancelling, parking and making ready all take the same authority. It belongs to:

  • the task's owner;
  • a worker that the owner reports to, directly or up the chain (see Who a worker reports to);
  • whoever manages the App.

Everyone else in the App can read the task but cannot reassign, cancel, park or ready it. Starting, recording progress on and finishing are different: they belong to the assignee alone, whoever else directs the task. A task you cannot read looks as if it does not exist.

When a task goes quiet

The platform watches for work that is stuck, and tells the owner rather than leaving it to someone's memory. The conditions are:

  • Nobody could be assigned. A queued task stays without an assignee past the App's assignment window.
  • Not started in time. An assigned task is still pending past its start-by time, or past the App's start window (15 minutes by default).
  • No progress. A started task whose assignee has been silent for the App's no-progress window (60 minutes by default), unless it is waiting on children.
  • Owner didn't react. A child task finished and the parent's assignee has done nothing since, after the App's reaction window. That is what ships today. The rule is that it is the child's owner who is judged, and it also covers a cancelled child; hadron-server#1831 and #1830 bring that, and this page will follow when they ship. Until then, a parent that has been reassigned can show the difference.

Each of these raises one alarm per stall, not a stream of repeats. The alarm goes to the task's owner and then up the chain, and it keeps escalating until someone acknowledges it. Acknowledging stops the escalation; it does not fix the stall. The task moves only when it is reassigned, cancelled, or its assignee acts. Any owner in the chain, or whoever manages the App, can acknowledge. The windows are set per App.

A stalled assignee is also marked unavailable, so a queued task is not handed to a worker who has gone dark.

What is not here yet

  • The CLI's team task park, team task ready and team task create --status are written but not in a release yet.
  • The portal has no task views yet.
  • The hrn:agenttask: address a task is meant to have is not built; a task is identified by its id.