The agent stopped halfway and the board still says in progress

You get back from a fifty minute meeting and the terminal pane is gone. The branch has fourteen changed files and a commit message that stops mid sentence. The ticket still says In Progress, still assigned to an agent avatar, and the last comment is ninety minutes old: starting the migration. Nobody knows whether the migration ran.

Search for this and you get answers to a different question: what an agent should record so a fresh model session can resume. Real problem, and a recent paper measures it. Not the one on your screen. A work item is telling four people something false, and the thing it names as owner died ninety minutes ago.

The hour you spend working out what it already did

You open the diff. Then you try to remember which tests it said it ran, and whether "ran" meant executed or predicted. You check whether the migration applied locally. You look for a PR. You read the last three comments hoping one is a status, then go back to the files.

That hour is not the diff's fault. It is rediscovery: reconstructing intent from artifacts, because whoever held the intent is gone.

Someone has measured the machine version. A June 2026 paper on handoff debt built 181 handoff points from 75 coding tasks and had three models take each over. Structured notes, rather than the repository alone, cut median agent events by 20 to 59 percent and prompt tokens by 42 to 63 percent. Your currency is minutes, not tokens, but the shape holds: takeover cost is mostly rediscovery.

This post is the ownership half: the board is wrong and someone has to fix it. Whether the unfinished work is worth keeping is a review question.

Is it dead, or is it just quiet

For the first thirty minutes you cannot tell, and neither can we.

An agent's work in Taskfolk is a session on the ticket, in one of seven states: pending, running, needs_input, review, done, failed, cancelled. Writes to the session move a heartbeat. After thirty minutes of silence the row renders as stalled, an orange badge derived at read time and never stored. It covers pending too, because an unclaimed delegation and a hung run mean the same thing to you.

One caveat: the heartbeat moves only when the agent touches the session, with a PATCH or a usage report. Comments on the issue do not count. An agent that chatters on the ticket for an hour without patching its session still reads as stalled.

At two hours, a sweep running every fifteen minutes flips a silent running session to cancelled and stamps its end time, so session lists and cost rollups stop counting it as live work. It notifies nobody.

Thirty minutes is the best we can do, for a structural reason: Taskfolk does not run your agent. Linear can call a session unresponsive after ten seconds because Linear delivered the webhook and is timing its own round trip (Linear docs, checked July 2026). We sit at the far end of a process on a machine we never see, so a missing heartbeat is all the evidence there is. Catching the stall while it happens is the post before this one.

A dead run leaves two lies on the board

Status is the first. A card in In Progress claims something is actively moving it. That was true this morning and false since the last comment.

Assignee is the second, and it does more damage. The card belongs to an identity that will not read your Slack message and will not pick the work back up. Everyone reads it as owned, so the teammate with two free hours scrolls past.

The asymmetry is the whole problem. A session dies on its own schedule. A work item never does.

flowchart TD
    A["Agent process dies"] --> B["Session still says running"]
    B --> C["At 30 minutes it renders as stalled"]
    C --> D["At 2 hours the sweep cancels it"]
    A --> E["Work item still says In Progress"]
    E --> F["Work item still assigned to the agent"]
    F --> G["It moves only if a person or a rule moves it"]

So the auto cancel tells the truth about the session and nothing about the ticket. There is no reassign on crash. The card moves when the agent's own API call moves it, a person does, or a rule you wrote does.

What the usual answers assume about the reader

The answer	What it assumes	Where the state lands
claude --resume	You launched it here	JSONL in your home directory
A HANDOFF.md in the repo	The reader can reach that disk	The box that ran the agent
A comment on the work item	Someone opens the ticket tomorrow	The tracker the team reads

claude --resume is genuinely good, and single player. Session ID lookup is scoped to the current project directory and its git worktrees, and runs started with claude -p or the Agent SDK never appear in the picker, though you can resume one by ID from the directory it started in (Claude Code docs, checked July 2026). Every constraint there assumes the person resuming is the one who launched it.

A HANDOFF.md outlives the process. It still assumes the next reader can reach the disk it was written to, and if the run happened in CI or a container since recycled, the file went with it. The best version of the list is the seven item session handoff checklist on hermes-agent.ai: goal and status, source of truth, files changed, commands run and their output, verification gaps, assumptions and risks, next safe action. Right items. Wrong address.

The exit contract, and where it has to land

Change one thing about those seven items: they are owed to the work item, not a scratch file. The agent posts them as a comment on the issue, over the first party MCP server or /api/v1, with its own API key, so the comment and the activity row carry its name instead of yours. The audit trail comes free.

The shape to ask for:

**Checkpoint 3.** Goal: theme cookie survives a hard refresh (WEB-142).
Done: token map, ThemeProvider, cookie write on toggle.
Not verified: auth suite has not run since the provider change.
Risk: SSR reads the cookie before hydration, untested in Safari.
Next: `npm test -- auth` on branch theme-cookie.

curl -X POST \
  "https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues/WEB-142/comments" \
  -H "Authorization: Bearer tfk_live_a1b2c3d4e5f6" \
  -H "Content-Type: application/json" \
  -d "$(jq -Rs '{body_md: .}' checkpoint.md)"

{
  "issue_key": "WEB-142",
  "author": {
    "email": "[email protected]",
    "name": "Codex Bot"
  }
}

The session row carries the short version. PATCH is the heartbeat, so the call that says still alive also updates the note and hangs the PR link on external_url. The note is capped at 2,000 characters. The comment thread is the record.

PATCH /api/v1/workspaces/acme/agent-sessions/0198f2b7-9a44-7c31-8f10-2d4e6a8b1c05
Authorization: Bearer tfk_live_a1b2c3d4e5f6
Content-Type: application/json

{
  "state": "needs_input",
  "note": "Migration 0031 local only. Auth suite not run.",
  "external_url": "https://github.com/acme/web/pull/812"
}

What we cannot do is make an agent write it. Taskfolk holds the contract and puts it where a person looks. Filling it in is your job: AGENTS.md, the skill file, or the prompt.

Timing decides whether any of this survives. A dead process cannot file its own report, so the checkpoint is not an exit step; it gets written repeatedly while the run is healthy. The hermes checklist triggers on outcome rather than a clock: after any run that changed something real, and before anything that resets context.

sequenceDiagram
    participant A as Agent
    participant T as Taskfolk
    participant H as Teammate
    A->>T: Checkpoint comment on the issue
    A->>T: Patch the session note and PR link
    A->>T: Move status and reassign to a person
    Note over A: Process dies
    H->>T: Opens the ticket
    T->>H: Last checkpoint, note, PR link

Routing: status and assignee both have to move

Board columns are per project and you name them. Each maps to one of seven fixed categories: backlog, todo, in_progress, in_review, done, failed, cancelled. So "Needs a human" is a real column rather than a label pretending to be one, and mapping it to in_progress keeps reports counting it as open work. Custom statuses are also how two agents hand work to each other.

Two controls hang off those columns and they are not equally strong. Allowed transitions are enforced: a forbidden move is refused on every write path, server actions, v1 API, bulk edits and automations alike. WIP limits are not. You can set one per column and read it back over the API, but no write path checks it, and the over limit colouring runs off built in defaults behind a view toggle. For a gate rather than a hint, use a transition rule.

Then move the assignee. The picker keeps people and agents in separate groups, so handing a card back is two clicks.

Linear made the opposite call, and for this failure theirs is the better one. Assigning an issue to a Linear agent sets it as delegate and leaves the human as assignee, so ownership never leaves a person and nothing needs moving back when a run dies. It costs accountability: an agent that is never the assignee never quite owns anything. Jira and GitHub went the other way, and in Jira you add the agent from the Assignee field (Atlassian support, checked July 2026).

Tool	Where the agent sits	When the run dies
Jira	The Assignee field	Not documented
GitHub Issues	Assignee, plus a live queued/working/completed status	No documented state for a dead run
Linear	Delegate, the human keeps the assignee	Session goes stale, assignee untouched
Taskfolk	Assignee, plus a session row	Session self cancels at two hours, the card does not move

None of them documents what the work item shows when a run does not finish.

Verified versus claimed, when you were not watching

You were in a meeting, so the agent's account is the only account you have. No tracker fixes that. What we do is weaker, and worth stating precisely.

A session in review or done, anchored to an issue, with no external URL and no activity row or comment attributed to that agent between its start and end times, gets an unverified badge. Setting external_url short circuits the check before the evidence query runs, so a PR link clears the badge. So does one comment.

The badge means no attributed evidence, not bad work. An agent that comments diligently and tests nothing will never earn one, so a clean hub is not a clean codebase. Reading the trace itself is covered in managing a team of agents.

One instruction, one column, one rule

The instruction is agent side. Put the seven items and the checkpoint trigger in AGENTS.md or the skill file. The care that goes into writing a ticket an agent can finish belongs in the note it leaves on the way out. Pair it with a field allowlist, fourteen issue fields per agent enforced at one API choke point, so a confused agent cannot rewrite the ticket while it is failing. It cannot stop an agent touching code, and we never see its terminal.

The column is "Needs a human", mapped to in_progress. If you would rather nothing reach done unseen, that is a human in the loop approval gate and a different column.

The rule is an automation on issue.assigned: when a card lands on an agent, post a comment stating the checkpoint cadence you expect. This is where the setup runs out of road. There is no trigger for a session going wrong. All ten triggers hang off an issue or a sprint, so "when the session fails, reassign to a human" is not a rule you can write today. The exception is a workflow run, where a stalled agent stage flags the run for attention and notifies its creator, on a sweep that runs every six hours.

Better to name that gap than let you find it ten minutes into building the rule. The rest pays for itself in a morning: an hour of reading fourteen files becomes ninety seconds of reading a comment.

Open the last ticket an agent finished for you and read only the ticket. If it does not say what changed, what ran, and what was never checked, put the exit contract in your agent instructions before the next run.