The loop that goes missing when AI picks up a task
Teams adopt an AI coding agent and expect status meetings to shrink. Instead they get the opposite problem: nobody can say with confidence when the agent actually started a task, how long it spent, or whether it's genuinely ready for review — because none of that got logged anywhere durable.
start_work and end_work exist to close exactly that gap. They're not a time-tracking nicety bolted onto the workflow — they're the two events that bookend focused work, human or agent, and make the loop auditable instead of anecdotal.
What the two calls actually do
start_work marks the moment a task moves from "assigned" to "in progress" and pulls the task's context — acceptance criteria, prior comments, linked knowledge pages — into the agent's working context via get_context_pack. An agent that skips this step is working from whatever it happened to have in its prompt, not from the task's actual record.
end_work closes the loop: it logs the time spent and marks a readiness state. Paired with submit_for_review, it hands the task to a human reviewer with an honest record of how long it took and what state it's actually in — not a guess.
Between the two, one rule matters most: no new assignment mid-flight. A manager dropping an urgent task on an agent that's mid-focus-window breaks the one signal — time-in-focus — that makes the loop worth measuring in the first place.
Why teams skip this and pay for it later
Tool tourism. Enabling start_work/end_work without changing the weekly rhythm around them — nobody actually checks the log, so nobody notices when it stops happening.
Invented precision. When a tag or a time entry is missing, the tempting move is to fill the gap with a guessed number instead of naming the gap. A missing entry is more useful than a fabricated one.
Duplicate systems. Approvals still happening over email in parallel with submit_for_review in-tool — now there are two records and neither is authoritative.
A weekly rhythm, not a one-time setup
Week one is setup: permissions, and the habit of calling start_work before picking anything up. Week three is when it becomes routine rather than a reminder. By week six, exceptions surface in the tool before they surface in a hallway conversation — that's the actual signal the loop is working, not just installed.
| Role | Question they ask | Where the answer lives |
|---|---|---|
| PM | Are we surprised this week? | Board + task search |
| Lead | Who is actually blocked? | Queue + task history |
| Executive | What needs my decision? | Executive brief + decision inbox |
| Finance | Is spend aligned with the plan? | Finance summary |
Anti-patterns
- No mid-flight assignment discipline — a manager interrupting an active
start_workwindow with a new "urgent" task defeats the whole point of a focus signal - Blame framing — using the time log to score individuals instead of finding the system bottleneck it's actually pointing at
- Skipping
end_work— a task that just moves to "done" with no close-out leaves no honest record for the next retro to calibrate against - Duplicate approval paths — email approvals running alongside
submit_for_reviewsplit the record in two
What good looks like after a month
Nobody asks "what's the latest version?" because the board, brief, or digest already answered it in writing. Leadership meetings shorten because exceptions were triaged async instead of narrated live. A new hire — or a newly connected agent — onboards faster because the rhythm is documented, not tribal knowledge sitting in one senior PM's head.
Honest limits
This doesn't fix unclear ownership or a stakeholder who won't commit to a decision. The tool surfaces signal; humans still negotiate trade-offs. When data is genuinely missing, the right answer in a standup is "we can't see that yet" — not a polished number that papers over the gap.
Keep MCP and chatbot reading the same data
When smart_search or the connected chatbot reads from the same source as the weekly digest, an answer given in a standup thread is verifiable against the actual task record — grounded, not a plausible-sounding guess.
FAQ
How fast can a team actually adopt this? Most see real value by week two, once permissions are set and one weekly rhythm exists around checking the log. Week one is setup.
Does this replace time tracking entirely, or the whole stack? It's the loop's two bookends — start and end — not a replacement for deeper reporting. Deep APM, ERP, or external support tooling typically stays separate.
What if our task data is incomplete? Name the gap in the retro and fix the tagging — don't backfill an empty field with a guessed number.
Where should we start?
Pick one active project, run start_work/end_work consistently for four weeks — human and agent tasks alike — then expand once the habit holds.
Ready to put this into practice?