Build Agent Teams That Ship PRs
Most of us have a coding agent that works. You give it a task, it goes away, and something reasonable comes back. Then you try to run three at once and it falls apart. One agent doesn't know what the other two changed, half the context is in a terminal you already closed, and reviewing the output takes longer than writing the code would have.
The fix isn't a better prompt. It's treating your agents like a team: one shared workspace they can all see, work split into roles, and a review stage sitting between their code and your main branch.
In this workshop we'll take a real GitHub issue and run it through a team of agents in AgentGrid, with planning, implementation, and review as visible stages, until it comes out the other side as a pull request you'd actually merge. You'll see how to lay agents out on a shared canvas, hand work between harnesses like Claude Code, Codex, and Cursor, and keep enough context in one place that you can tell what every agent is doing without opening ten terminals.
We'll cover:
How to break a feature into work a planner, an implementer, and a reviewer can each own
Running several coding harnesses side by side, and switching cleanly when one hits a usage limit
Giving agents shared context, including notes, terminal output, a browser, and each other's work, instead of isolated chats
Delegating from a lead agent to workers, and what to do when a handoff goes wrong
The review stage: catching the PR you should not merge before it reaches your team
Where a team of agents genuinely beats one long-running agent, and where it does not
You don't need an existing multi-agent setup to follow along. If you've used a coding agent at all, you'll be able to keep up.
This is a live build with real code, so bring the workflow you're wrestling with and we'll work through it together.
The recording and everything we build will be available to everyone who registers.