Last week, I lost an entire afternoon to my own AI workflow.

Nothing broke. Nothing crashed. I'd just finished one PRD with Claude and was partway into the next one, except I had no idea where I'd left off. Which features were still open? Which chat window had the unresolved questions? I kept scrolling through conversation history, trying to piece together what was done and what wasn't.

By the time I actually got oriented, the afternoon was basically gone.

That's when I figured out I needed a real system, not just more browser tabs. Turns out GitHub issues are exactly the right tool for this, and I'm annoyed it took me this long to see it.

What "orchestrating AI agents" actually means

I'm not talking about some autonomous robot swarm where AIs coordinate with each other (though sure, maybe someday). I mean, you working with multiple AI coding sessions at the same time without completely losing track of which session is doing what.

Claude Code is VERY good at solving specific problems when you give it a clear context. The problem is that it has no idea what's happening in any of your other Claude tabs without some additional layer to help it. And if you're anything like me, you're also terrible at keeping track of which of your five open sessions is handling which feature. That's two sources of chaos compounding each other.

GitHub issues fix this by giving you a single source of truth. Instead of scattering context across chat windows, you use an issue as your command center. The issue describes what you want, the AI implements it, you review the results, update the issue with feedback, and keep going until it's done. The issue becomes both your audit trail and your handoff document, so you can see exactly what you asked for and how it evolved.

The iteration process, with a real example

Here's how I actually work through this. Last week, I needed to add drag-and-drop support to the calendar view in UnleashedPodcasts. Here's how it went.

Iteration 1: The brain dump

I started with basically a stream of consciousness:

# Add drag and drop support to /calendar view

The calendar page shows tasks in a grid, but everything is static. Want users to be able to drag tasks to different dates. Should save to the database when something gets dropped in a new spot.

This is intentionally rough (Grammarly was angry when I copied and pasted this into this post). I'm not trying to write perfect requirements, and instead I'm getting the idea out of my head and into an issue.

I opened Claude Code, pasted a link to the issue, and asked: "What information do you need to be 90% confident you can implement this?" (It's a little strange that we can just ask an LLM for its confidence level, but here we are.)

Claude came back with questions about what the draggable items actually were, how to persist the change, and whether the UI should move the item immediately or wait for server confirmation.

Iteration 2: Answering the questions

I updated the issue with Claude's questions answered:

# Add drag and drop support to /calendar view

Users should be able to drag Episode items to different dates on /calendar. Dropping an item on a new date saves the change immediately.

**Requirements:**
- Draggable items are `Episode` models with a `target_date` column in the current time range
- Persist via Livewire when drop happens
- Optimistic UI: move the item visually first, revert if the server returns an error

**Questions to resolve:**
- What happens if a task is dropped on a date that's in the past?

This time, when I gave Claude the issue link, it was enough to propose a specific implementation plan. I reviewed the plan, realized I'd said nothing about past-date validation, and updated the issue again.

Iteration 3: The implementation-ready version

After one more round, the issue looked like this:

# Add drag and drop support to /calendar view

Users should be able to drag Episode items to different dates on /calendar. Dropping an item on a new date saves the change immediately.

**Requirements:**
- Draggable items are `Episode` models with a `target_date` column in the current time range
- Persist via Livewire when drop happens
- Optimistic UI: move the item visually first, revert if the server returns an error

**User flow:**
1. User drags an episode to a new date on the calendar
2. Episode moves visually immediately (optimistic update)
3. Livewire request fires in the background
4. On success: nothing (item stays in new position)
5. On failure: revert the item, show a toast error

**Implementation order:**
1. Add `updateDueDate` method to Livewire Component
2. Update elements to support this.

At THIS point, I dropped the issue URL into Claude Code and said: "Implement this." Claude had everything it needed. The whole thing took maybe 20 minutes of back-and-forth.

Why this actually works

The magic isn't the issue tracker itself (you could use Notion or a text file if you wanted to). The magic is the PROCESS:

1. You start vague because you don't know all the details yet
2. The AI asks clarifying questions because it needs specifics to generate code
3. You refine the issue with those specifics
4. The AI implements based on the refined version
5. The issue becomes your documentation for what you built and why

I can go back to that calendar drag-and-drop issue six months from now and see exactly why we went with optimistic UI instead of waiting for server confirmation. It's all right there in the thread.

And when I have multiple issues in flight (which I always do), labels let me see at a glance which ones are still in brain-dump territory versus which ones are ready to hand off.

Where multiple agents actually help

Here's where this REALLY pays off: you can run multiple issues with multiple AI sessions simultaneously without losing context between them.

Last Tuesday, I had four Claude Code sessions going: - One implementing the drag and drop calendar feature - One refactoring my API error responses to be more consistent - One investigating a performance issue with my notification queries - One writing tests for a feature I'd already shipped (don't judge me)

Each session had its own GitHub issue. When I needed to switch context, I closed one Claude window and opened another with a different issue URL. No context mixing, no confusion about which session was doing what.

The drag and drop issue was at "implement." The error response issue was still at "proposed approach." The performance issue was in "investigate and report findings." The issues were tracked in the state, so I didn't have to hold it all in my head.

How to actually get started

If you want to try this yourself:

1. Pick one feature or bug you want to work on with AI help
2. Create a GitHub issue with a rough description (don't overthink it)
3. Open your AI tool (I use Claude Code, but this works with anything that can read URLs or interact with the gh CLI)
4. Give it the issue link and ask what information it needs
5. Update the issue with the answers to its questions
6. Repeat until the AI has enough context to implement
7. Let it implement and review what comes back

After a couple of rounds, you'll get a feel for how much detail is "enough" before moving to implementation. For me, it's usually 2-3 refinement cycles, depending on the complexity.

The real win is running MULTIPLE issues at once without your brain melting. The issues keep things organized, the AI gets a clean context, and you get an audit trail of what happened and why. It's a much better use of an afternoon than scrolling through chat history trying to remember where you left off.