Handing off a Cursor task mid-flow - when you hit your usage limit or the work needs someone else

Guides
,
1

Two things reliably kill a good Cursor session on our team: hitting the usage limit halfway through a task, and realising the task actually needs someone else - different repo access, different domain knowledge, or just someone who isn’t asleep.

The limit itself isn’t the painful part. The painful part is that everything the agent worked out - which files matter, what you already ruled out, the half-finished approach - lives in a chat the next person can’t see.

Why “paste a summary into Slack” doesn’t hold

We tried it. Three problems:

  • The summary gets written by whoever is tired and out of budget, so it’s the worst version of the context.
  • It goes stale immediately. The branch moves, the summary doesn’t.
  • The next person’s agent can’t read it. A human has to re-type it into a new chat, which is exactly the work you were trying to avoid.

The pattern that worked: let the agent write its own handoff

Instead of summarising by hand, give the agent a tool that writes the task state somewhere another agent can read it. The agent has the context; it should be the one serialising it.

One entry in ~/.cursor/mcp.json (or Settings > Cursor Settings > MCP):

{
  "mcpServers": {
    "tracker": {
      "url": "https://your-tracker/api/mcp"
    }
  }
}

Then, at the point you’re about to run out:

Create a ticket for the remaining work. Include the files you’ve already read, the approach you settled on and why, what you tried that didn’t work, and the exact next step.

The agent writes a far better handoff than you would, because it isn’t summarising from memory.

What actually needs to be in the handoff

  1. What was ruled out and why. Without this the next agent repeats your dead ends. Highest-value field, and the one a human summary always omits.
  2. The files already read. Saves the next session a whole discovery pass.
  3. The next concrete step, not the goal. “Add the migration for users.locale” beats “finish i18n”.
  4. Anything environment-specific - a local flag, a seeded DB, a branch that isn’t pushed.

Failure modes we hit

  • Don’t let the agent pick up its own ticket immediately. It’ll just continue in the same session and burn the budget you were trying to preserve.
  • Titles aren’t context. If the pickup tool returns only a title, the next agent starts work off the title and gets the scope wrong. It has to return the whole ticket in one call.
  • Rules files get dropped under context pressure. “Always update the board first” is the first instruction to fall out of a long session. Returning the workflow instructions from the tool itself, alongside the ticket, was much more reliable than keeping them in a rules file.

Disclosure

We build one of these trackers (Wagglet), so I’m not a neutral party - the MCP endpoint and tool list are at MCP Workspace setup and permissions — Wagglet if you want to see what the tools look like in practice. But the pattern is the point and works with anything exposing equivalent tools; the four handoff fields above are tracker-agnostic and took us the longest to get right.