You assigned it to an agent and nothing happened

You assigned WEB-214 to your coding agent at 09:12. It is 11:40. The ticket still has the agent's name on it, the column has not moved, and nothing has been written to it since you hit save.

The reflex is to read the runtime logs. Go ahead, but the question that matters is one your board cannot answer: did the agent ever hear about this? An agent that picked the work up twenty minutes ago and is quietly reading files leaves exactly the same row as one whose process died at 04:00 and never received the event.

That ambiguity is not a model problem. It is a hole in your workflow, and it opened the moment you changed an assignee field and called it a handoff.

Disclosure: I work on Taskfolk, and one section here is about what we ship and what we do not. The argument is not ours. Several teams wrote parts of it down already, in specs nobody reads side by side.

Queued and working render identically

Your board stores one fact: assignee equals the agent. It stores nothing about whether the other side accepted the job. Two unrelated situations collapse into one row, and nobody on the team can separate them without leaving the tool.

Wei Wu documents the same shape in a longitudinal study of one production LLM agent runtime, eight weeks, 22 incidents with postmortems (arXiv:2606.14589, submitted 12 June 2026, checked 26 July 2026). The largest failure class there is not a bad model call. It is operational omission, defined in the paper's table as "declared state != runtime state", with silences lasting days to sixty days. The canonical incident is a job that was implemented, tested, registered and deployed, and never ran, because writing the crontab line was a human memory item. Then the sentence that should worry you: "the job's absence produced no log to scan."

An assignment nobody accepted is that failure in miniature. There is no error to find because nothing errored.

The Agent activity card seconds after assignment: a pending session under the agent name, no work reported yet.

Two neighbouring failures are out of scope. An agent that started and then went quiet mid run needs how to tell when an AI agent is stuck. An agent that started with no way to know what "done" meant has a problem upstream in the writing, covered in write tickets AI agents can finish. This post is only about the delegation that never began.

How long should you have waited?

Nobody gave you a number, so you invented one, and yours was probably "until I got annoyed". The systems that publish one disagree by three orders of magnitude. Call it T: the longest you are willing to wait for a first signal before you treat the delegation as unaccepted.

System	State while waiting for pickup	Deadline to leave it	If nothing comes back
A2A protocol v1.0.0	TASK_STATE_SUBMITTED	none anywhere in the spec	undefined
MCP Tasks extension	none, first status is working	ttlMs on every task handle	the handle expires
Linear agent sessions	pending, plus a real stale state	10 seconds to first activity	session marked unresponsive
Microsoft Planner agent	Queued, meaning busy elsewhere	none documented	not documented
GitHub Copilot coding agent	Queued in the UI	none on the queue, 59 minutes on the run	it sits there
Hermes subagent delegation	none, work starts immediately	child_timeout_seconds, off by default	timeout_phase: before_first_llm_call
Taskfolk	pending session	30 minutes to a Stalled badge	cancelled after 7 days

Every row checked 26 July 2026 against that system's own docs. Read Microsoft's small print: Queued there means the agent is assigned but currently executing another task, so the state at least implies the agent is alive. GitHub is blunter. Its docs cap a Copilot cloud agent session at 59 minutes of execution and call that a hard limit, while nothing bounds the queue in front of it.

The value of T matters much less than having one the system, not you, is responsible for checking.

The protocols each solved half of this

The A2A specification defines TASK_STATE_SUBMITTED as "indicates that a task has been successfully submitted and acknowledged," sitting before TASK_STATE_WORKING (specification v1.0.0, checked 26 July 2026). That is the exact state this post is about, agreed across vendors. Now search the spec for a timeout, a TTL, or an expiry. There is none. A state with no clock.

The MCP Tasks extension does the opposite (checked 26 July 2026). Its lifecycle table has five statuses: working, input_required, completed, failed, cancelled. There is no pending. The first status is working, which encodes exactly the assumption your board makes. Yet every task handle it returns carries a ttlMs and a pollIntervalMs, and the spec is explicit that "the task is durably created before the response is sent." A clock and a durable record, with no acknowledgement state to hang them on.

Take the acknowledgement state from one, the clock from the other, and the blind spot closes.

stateDiagram-v2
    [*] --> Delegated
    Delegated --> Acknowledged: agent claims the record
    Delegated --> Unacknowledged: no signal by T
    Unacknowledged --> Acknowledged: late claim
    Unacknowledged --> Expired: nobody ever claims it
    Acknowledged --> Working
    Working --> Review
    Working --> Failed
    Review --> Done
    Done --> [*]
    Failed --> [*]
    Expired --> [*]

Nobody was assigned to notice

One finding in that paper changed how I read my own dashboards. Across the 22 incidents, roughly 70% of silent failures were caught by a human looking at the product as a user. Tests and audits caught close to none, and that runtime carried 4,286 unit tests and 827 governance checks, all green while the failures ran. The rule that follows: an alert path must not depend on the failing subject. Their gateway down alert died with the gateway.

So the agent cannot be the thing that tells you it never started. If it could send that message, it was running.

This is ordinary, not exotic. In multica issue #4963 (opened 6 July 2026, checked 26 July 2026), a workspace snapshot shows a reviewer style agent at 138 of 523 tasks cancelled, 26.4%, and a builder style agent at 229 of 794, 28.8%. Those cancellations produced nothing, with no product signal and no automatic recovery. Roughly one delegation in four looked like a handoff and was not one.

GitHub community discussion #188644 (opened 4 March 2026, checked 26 July 2026) collects six people whose Copilot sessions failed at dispatch and stayed marked Queued, with no way to cancel them. One reports a session queued for three months. Another writes that he is "worried about receiving unexpected bill or it eating up my quotas when I wake up someday". No official reply on the thread. A state with no expiry does not stay empty; it fills up with garbage that still costs money.

The Agents hub roster: a pending count on an agent row, with the hint that these are delegations it has not picked up.

The rule, in four lines

Assignment mints a durable record instead of changing a field, and that record carries a named owner, the time it was created, and a state of its own.

The state has to render differently from in flight. The entire cost of this failure is that queued and working look alike.

A first signal deadline T applies to it. If nothing arrives by T the record flips to unacknowledged, and a human hears about it from something other than the agent.

Unclaimed work expires loudly. A delegation that quietly ages back into an ordinary ticket is how work disappears with nobody deciding to drop it.

sequenceDiagram
    participant H as You
    participant B as Tracker
    participant A as Agent runtime
    H->>B: assign the issue to the agent
    B->>B: mint a pending record with owner and clock
    B->>A: push the assignment event
    Note over A: process is not running
    B->>B: T passes with no claim
    B->>H: flip the record to unacknowledged

Contact centres have run the first three lines for years. A Salesforce Omni-Channel routing configuration carries a Push Time-Out: how long a routed work item sits in an agent's console before it is pulled back and sent elsewhere (checked 26 July 2026). The scope is narrow and honest about it. That timer bounds the unaccepted window and nothing after it.

What Taskfolk does, and where it stops short

Assigning an issue to a connected agent creates a pending session immediately, before the agent has heard anything. It shows on the ticket and on the Agents hub under the agent's name, so the delegation is a record rather than a field. The agent claims that row when it starts and can never move a session into pending itself. The code comment names where we took the pattern from: Linear. Mechanics are in how to delegate work to an agent; wiring the key and the event stream is in how to connect an AI agent.

Against the four lines: rule one, yes. Rule two, yes, the pending badge reads differently from running. Rule three, partly. After 30 minutes with no activity a quiet pending session picks up an orange Stalled badge, the same threshold a hung run uses, shared deliberately: both mean a human should look. Rule four, partly, through a worker sweep that cancels pending sessions after seven days, give or take, because the sweep itself runs every six hours.

An unclaimed delegation past thirty minutes carrying the orange Stalled badge, next to a healthy running session so the two read differently.

Now the part I would rather not write. Both of those clocks are silent. The Stalled badge is derived at read time for display and rings no bell, and the seven day expiry is a bulk update with no notification, so an ignored delegation dies without telling anyone. There is a second asymmetry in the same code: a running session that stops heartbeating is force cancelled after two hours, while an unclaimed one waits seven days. That treats a hung run as more urgent than a handoff nobody took, which is backwards.

Linear ships the stricter version of all of this. Ten seconds to a first activity or the session is marked unresponsive, stale as one of six first class session states, enforced at dispatch rather than derived half an hour later.

Until ours catches up, ask the question yourself on a schedule:

# needs the agents:read scope
curl -s "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions?state=pending" \
  -H "Authorization: Bearer tfk_live_a1b2..."

const res = await fetch(
  "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions?state=pending",
  { headers: { Authorization: `Bearer ${process.env.TASKFOLK_API_KEY}` } },
);
const { data } = await res.json();

import os, requests
r = requests.get(
    "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions",
    params={"state": "pending"},
    headers={"Authorization": f"Bearer {os.environ['TASKFOLK_API_KEY']}"},
)

{
  "data": [
    {
      "id": "0198f0c2-7b41-7c0a-9a3e-2f6d8c11ab90",
      "agent_id": "0198e7a1-4d22-7b19-8f55-91c0aa77de31",
      "agent_name": "Claude Code",
      "state": "pending",
      "title": "Fix the theme flash on first paint",
      "issue_key": "WEB-214",
      "started_at": "2026-07-26T09:12:04.000Z",
      "last_activity_at": "2026-07-26T09:12:04.000Z"
    }
  ]
}

Compare started_at against your T. On an unclaimed row it is the moment of assignment and never moves, so anything older than T is a delegation nobody accepted. The honest limit sits right here: Taskfolk delivers the trigger over its per agent event stream and stores the session record. It never runs your agent. If the runtime is down nothing on our side starts it, and the pending session is the evidence.

Doing this on Monday, whatever tool you use

None of this needs our product. Give the awaiting pickup state a name in the tool you already have, a label or a status column, and never let it share a cell with in progress. Pick a T and write it in the team doc so it is a rule and not a mood. Run one scheduled query for records older than T and route the result to a human, not to the agent. Then close the loop the other way: an automation rule can wake an agent when matching work appears, without anyone touching the issue (how to set up automations).

An automation rule with the notify agent action selected, so a matching ticket wakes the agent without a human sending anything.

With more than one agent the same discipline keeps a chain of handoffs honest; coordinating a triage agent and a coding agent shows the sequencing.

What this does not fix

A pending record with a clock tells you an agent did not start. It says nothing about whether the ticket was buildable, whether the agent has the scopes it needs, or whether the work that comes back is any good. Taskfolk flags a session that reaches review or done with no attributed activity or comment on its issue, but that badge is a heuristic and a single comment defeats it. Managing a team of AI agents covers the checking side, and human in the loop approval covers what happens before an agent's changes land.

One more limit, stated plainly. A session entering needs input, review, done or failed notifies the agent's owner and the issue's reporter, assignee and watchers. Nothing fires for a delegation that was never claimed, and our 14 event webhook catalogue has no agent session event to hang your own alert on. There is no mobile app and no push notification either. If your T is measured in minutes and you are away from a screen, the scheduled query above plus a pager you already own is the honest answer.

Go find the oldest ticket on your board with an agent's name and no activity on it. If you cannot tell from that row whether the agent ever started, you have found the thing worth fixing, and it is not the agent.