Keep work moving
How to Catch a Dropped Handoff Before It Costs You a Week
The PR looked fine on both boards. Nobody owned it. Here's how a handoff disappears between two clean-looking views, and how to catch it.

Look at either person’s board and everything’s fine. No overdue items, nothing flagged red, nothing obviously stuck. And yet a pull request has been sitting untouched for a week, because the person who said “I’ll take it from here” never actually became its owner anywhere a tracker could see.
A dropped handoff looks like nothing happening: person A assumes person B has it, person B doesn’t know it was handed off at all, and no tool flags the silence, because nothing was technically left undone on either side. That’s what makes this specific failure mode so hard to catch with the tools most teams already have. Nothing’s broken. Nothing’s overdue. Something just isn’t anyone’s job right now, and no dashboard has a column for that.
How do you catch a handoff that quietly dropped between two people?
You have to look for the handoff itself, not for a stuck ticket, because the ticket usually doesn’t look stuck at all. Most handoffs happen in conversation: “can you take this from here,” said in a Slack thread or a standup, not entered anywhere a tracker records as an ownership change. The words are clear enough between two people in the moment. The system of record never hears them. So the only reliable way to catch a dropped handoff is to notice when a handoff got mentioned somewhere without a matching ownership change showing up where the work actually lives.
That’s a genuinely different thing to watch for than what most tools already check. A stalled-ticket alert looks for an item that’s been open too long with no activity. A dropped handoff can have plenty of activity, just none of it moving the work forward, because both people involved reasonably believe it’s the other one’s turn.
Why is this invisible to a board view?
Because both the old owner’s view and the new owner’s view look completely clean. The person who said “I’ll take it from here” doesn’t have the item assigned to them, so it doesn’t show up as theirs, overdue or otherwise. The person who handed it off does have it assigned to them, technically, but they’ve mentally closed the loop, since they said the sentence that was supposed to move it. Neither board shows a problem, because neither board actually reflects what happened in the conversation. The tracker still says the original person owns it. The conversation says otherwise. Nothing in either view surfaces that disagreement, because a board only shows what’s written down, and the handoff itself never got written down anywhere.
One PR, one week of silence
Walk it through concretely. On Tuesday, an engineer named Marcus opens a PR and posts in the team’s busy Slack channel that he’s swamped this week: “@Dana, mind grabbing review on this one? I’m underwater.” Dana is heads-down in back-to-back meetings that afternoon, notifications muted, and the message scrolls past under everything else posted in the channel that day. She never actually sees it. Marcus, having named her directly, considers it handled: he asked, so in his head it’s hers now.
Nobody assigns Dana as a reviewer on the PR itself, and nothing about that changes afterward. The GitHub tracker still shows the PR with no reviewer, exactly as it did before Marcus posted, and it stays that way, because the handoff Marcus believes happened never actually reached Dana. Marcus isn’t tracking it anymore, since as far as he’s concerned he handed it off. Dana isn’t tracking it either, since she has no idea it was ever asked of her. Neither of them is being careless. Marcus did what the conversation, from his side of it, implied he should do. Dana simply never received the other half of that conversation.
By the following Tuesday, the PR still has no reviewer assigned, and it still shows the same author, the same open state, nothing about the record itself has changed at all. It doesn’t show up on Marcus’s list of things to follow up on, because he mentally closed the loop the moment he posted the ask. It doesn’t show up on Dana’s either, because nothing was ever formally routed to her and she never read the message that would have. It sits in exactly the kind of gap that survives a week of standups, because standups surface what’s actively blocked, not work that stopped being anyone’s assigned responsibility without a word said about it.
What does Thor actually surface here?
The mismatch itself: a handoff mentioned in Slack or GitHub with no corresponding ownership change in the tracker. Thor reads the same channel Marcus posted in, sees him naming Dana directly and asking her to take review, and checks that against the PR’s actual reviewer field and Dana’s own activity. When Dana’s never replied, reacted, or shown any sign of having seen the ask, and the reviewer field is still empty days later, that gap between what was asked and what actually happened is the specific signal worth flagging, not a generic “this PR is old” alert, which wouldn’t have fired yet anyway since a week-old open PR isn’t unusual on its own.
| What a stalled-item alert catches | What a dropped-handoff flag catches |
|---|---|
| A ticket open too long with no activity | A handoff spoken out loud that never became an ownership change |
| Something visibly stuck on someone’s own board | Something invisible because it isn’t on anyone’s board correctly |
| Triggers after enough time has passed | Triggers at the moment the mismatch is created, days earlier |
Why does catching this early matter more with agents in the loop?
Because a person might eventually notice a dropped handoff on their own, and an agent won’t. Marcus could plausibly remember, two weeks later, to ask Dana what happened to that PR. It’s not guaranteed, but it’s possible, because people occasionally circle back on things they said out loud. An agent working from the tracker has no equivalent instinct. It sees a PR with no assigned reviewer and no reason to believe anyone verbally claimed it, so it has nothing prompting it to ask. If an agent is the one deciding what to review next, or summarizing what’s outstanding for a standup update, a dropped handoff like this one simply doesn’t exist for it, because the only record of it ever happening was a sentence in Slack the agent never connected to the PR at all.
That’s the same underlying pattern behind why AI agents confidently do the wrong thing: the failure isn’t the agent malfunctioning, it’s the agent working correctly from a system of record that’s missing the one fact a person said out loud and never wrote down. Research on coordination in organizations backs this up as a general pattern, not something specific to software teams: people consistently underestimate how much of a handoff needs to be explicitly tracked, because the conversation itself feels like enough closure in the moment it happens.
What happens once it’s flagged?
A person confirms who actually owns it now, and that confirmation becomes the real record going forward. Thor isn’t deciding on its own that Dana owns the PR just because Marcus named her in a message; a mention isn’t the same as a confirmed assignment, and treating it as automatically official would just replace one kind of unfounded assumption with another. What Thor does is put the mismatch in front of someone, Marcus, Dana, or whoever’s checking what’s moving and what’s stalled, so a person makes the actual call: yes, Dana should take it, assign her as reviewer now that she’s actually seen it, or no, someone else should pick it up instead. The gap gets closed in seconds once it’s visible. The entire cost of this failure mode is the time between when it happens and when someone notices, and that gap is exactly what a surfaced mismatch collapses.
FAQ
Doesn’t a “hey, can you take this?” in Slack count as a real handoff?
Between two people in the moment, yes. The problem is that a tracker doesn’t hear Slack messages by default, so the handoff exists in conversation but not in the system anyone else, including an agent, actually reads from.
How is this different from a ticket that’s just stalled?
A stalled ticket looks stuck on someone’s board. A dropped handoff usually looks clean on both people’s boards, because neither one shows an item that’s clearly, visibly theirs and overdue.
Does Thor automatically reassign the item once it sees a handoff mentioned?
No. It surfaces the mismatch between what was said and what the tracker shows, and a person confirms the actual ownership change. Nothing gets reassigned just because a message implied it should be.
Would this have eventually gotten caught anyway?
Maybe, if someone happened to remember and circle back. That’s not a reliable mechanism, and it gets less reliable as more of the day-to-day tracking shifts to agents that have no reason to ask.
Does this only apply to PR reviews?
No, the PR example is one common case. The same gap opens for any handoff that happens in words, a Slack message, a comment, a hallway conversation, without a matching change in whatever tool actually tracks who owns what.
See how Thor catches a dropped handoff before it turns into a dropped ball. Book a demo.

