How I Made Claude Code Finish Tasks That Outlast Its Memory

You know the moment. You're 45 minutes into a big task — processing a batch of files, refactoring a module, running a multi-phase workflow. Claude has been crushing it. Then the responses get vague. It starts repeating itself. It forgets what it already did. Context window: full.

You start a new conversation. Re-explain everything. Hope it picks up where it left off. It doesn't — it redoes half the work, skips the other half, and misses the files that were tricky the first time around.

I got tired of being the relay mechanism between conversations. So I built one.

The Idea: Tag-Team Relay

The concept is stolen from wrestling. When a wrestler is gassed, they tag in a fresh partner. The fresh partner knows the game plan, knows what's been tried, and picks up where the last one left off.

/tag-team does this for Claude Code. A lightweight dispatcher spawns worker agents one at a time. Each worker makes as much progress as possible, then writes a structured handoff file before its context fills up. The next worker reads that file and continues.

/tag-team Extract JSON docs from all 200 files in /tmp/batch.txt

That's it. Three workers later, all 200 files are processed. Zero re-prompting.

What Actually Happens

The dispatcher — your main conversation — stays lean. It never does the real work. It just:

1. Spawns Worker 1 with the task
2. Worker 1 processes files until context gets high, writes a handoff file, returns
3. Dispatcher reads the result, spawns Worker 2 with a pointer to the handoff
4. Worker 2 reads the handoff, continues from exactly where Worker 1 stopped
5. Repeat until done or max iterations reached

The key insight: the Agent tool returns only a short summary to the dispatcher. So even after 10 iterations, the dispatcher's context has barely grown. It can keep spawning workers indefinitely.

The Part That Actually Matters: Handoff Files

The handoff file is the entire trick. Without it, this is just "start a new conversation and hope for the best." With it, each worker has perfect context about what happened before — without needing conversation history.

Here's what a real handoff looks like (abbreviated):

## Mission
- Goal: Extract JSON documentation from all 200 API endpoint files
- Status: 40% complete (80 of 200 files processed)
- Next step: Continue from file 81 (src/api/payments/refund.ts)

## Key Decisions
- Decisions made: Using the compact schema format, not the verbose one.
  Output goes to docs/api/{module}/{endpoint}.json
- Dead ends: Tried batch-reading 20 files at once — hit context limits
  fast. Switched to batches of 6 with interleaved writes.

## Progress
- Completed: Files 1-80 (auth/*, users/*, orders/*)
- In progress: None (clean handoff)
- Remaining: Files 81-200 (payments/*, inventory/*, shipping/*, admin/*)

## Resume Instructions
Read the file list from /tmp/batch.txt. Skip to line 81. Process files
in batches of 6: read 6 files, write their JSON docs, repeat. Output
path pattern: docs/api/{module}/{endpoint}.json. Use the compact schema
format — see docs/api/auth/login.json for reference.

Notice the Dead ends section. Worker 1 tried batch-reading 20 files and it blew up. Worker 2 doesn't repeat that mistake — it already knows to use batches of 6. This is the thing that separates tag-team from naive restarts. Each worker inherits not just the progress, but the lessons.

Context Warning Protocol

Workers don't just blindly run until they crash. The proxy monitors context usage and injects warnings at configurable thresholds:

• 70% — Finish your current file. Don't start new large operations. Start composing your handoff mentally.
• 80% — Stop immediately. Write the handoff file. Return.
• 90% — Emergency. Dump whatever state you have and get out.

There's also a safety net: if a worker makes 50+ tool calls without seeing a context warning, it hands off anyway. Belt and suspenders.

Wrapping Other Skills

The part I didn't expect to be useful — but turned out to be the most useful — is the --skill flag:

/tag-team PROJ-12345 --skill develop

This wraps my /develop skill (a 12-phase Jira-to-PR orchestrator) inside the tag-team relay. If /develop runs out of context mid-implementation, it doesn't die — it hands off to a fresh worker who picks up at the same phase.

Any skill that might outlive a single context window becomes automatically resilient. The skill doesn't need to know about tag-team. Tag-team doesn't need to know about the skill. They compose.

Resume and Status

Sessions survive crashes:

/tag-team resume     # Pick up from the latest handoff file
/tag-team status     # Show progress log and list all handoffs

Old sessions get archived automatically when you start a new one, so you never lose historical state.

The Numbers

For a real batch of 200 files:

• Without tag-team: Manual restart 4-5 times, re-explaining context each time, ~30% of work redone across restarts
• With tag-team: 3-4 workers, fully automatic, zero rework, progress file showing exactly what happened at each stage

The raw time is similar. The difference is I walked away and came back to a completed task instead of babysitting context windows.

When to Use It

Tag-team shines for:

• Batch processing: Extracting, transforming, or generating files from a large input set
• Long workflows: Multi-phase skills that might exhaust context
• Refactoring at scale: Renaming, restructuring, or updating patterns across many files
• Any task where you'd normally restart the conversation mid-way

It's overkill for tasks that fit in a single context window. If your task completes in one worker, the dispatcher overhead is wasted. The sweet spot is work that would take 2-10 context windows.

Try It

The skill is four files — a dispatcher (SKILL.md), worker instructions, cross-phase policies, and a config. Drop them into .claude/skills/tag-team/ and you have relay-capable Claude Code.

The full implementation is in my skills repo. The deep dive into the architecture — handoff format, config options, how the dispatcher loop works — is in the companion technical reference.

---

This is part of a series on scaling Claude Code for enterprise workflows. Previously: How I Stopped Losing Work to Context Window Overflow, How I Taught an AI Agent to Save Its Own Progress, and Centralized Skill Management for Claude Code.