Sprint Zero

Plan smarter, ship faster.

Comment

Inspiration

We've both lived through the same miserable first week of a new project, more times than we'd like to admit. Someone spends two days re-configuring OAuth and repo settings they've configured a dozen times before. The work breakdown lives in a Google Doc that everyone reads once and never opens again. Standups get scheduled by gut feel instead of what actually depends on what, so the one sync that mattered happens on day nine instead of day four, after the thing it was supposed to unblock already went sideways. And somebody, always, is stuck writing the same "welcome to the project, here's what we're doing" email from scratch.

None of that is the interesting part of building software. It's the tax you pay before you get to the interesting part. We started calling it "Sprint Zero" as a joke between us (the sprint that isn't really a sprint, just setup), and at some point the joke turned into the question that became this project: what if an agent just did all of it?

What it does

You upload a project brief (a PDF) and a list of your team members. SprintZero reads the brief, reasons about what work needs to happen and who depends on whom, and then actually goes and does the Sprint Zero work for you:

  • Builds a full Work Breakdown Structure: tasks, owners, durations, dependencies, and writes it into a formatted Google Sheet
  • Schedules sync meetings on Google Calendar, but not on a fixed cadence. It looks at the dependency graph and places meetings where they'll actually matter (if Task 4 depends on Task 3, the sync happens right after Task 3 is due, not on some arbitrary "every Tuesday" schedule)
  • Writes a real, specific 3-bullet agenda for every meeting it schedules, based on your actual brief, and drops it directly into the calendar invite's description field, so nobody on your team copy-pastes a blank agenda ever again
  • Sends kickoff emails to your team members automatically

And you get to watch it happen. There's a live execution log that streams every step in real time: which agent is running, what it just decided, what it's calling next, so it never feels like a black box that disappears for two minutes and comes back with an answer.

How we built it

Under the hood, SprintZero is an agent pipeline built on Google's Agent Development Kit (ADK), and the design decision we're most proud of is how little of it actually touches an LLM. It's a SequentialAgent with three stages:

  1. An LlmAgent, the Planner, running on Gemini 3.5 Flash, reads the PDF and team list and produces structured JSON: the task list and the sync schedule, agendas included, validated against a strict schema.
  2. A ParallelAgent that fans out into two deterministic (non-LLM) agents running simultaneously: one writes the Google Sheet, the other writes the Calendar events.
  3. A final deterministic EmailAgent that sends the kickoff emails once everything else is done.

Only step one ever calls Gemini. Everything after that is a regular function calling the Sheets, Calendar, and Gmail APIs directly, with no unnecessary round-trips to an LLM just to move data it already has. It made the pipeline faster, cheaper, and a lot easier to reason about when something went wrong, because "wrong" almost always meant the Planner's output, not the plumbing.

The rest of the stack is deliberately boring in the best way: React + Vite on the frontend, Node + Express on the backend, one Cloud Run service hosting both. Auth is Google OAuth2 with offline access, refresh tokens encrypted before they ever touch Firestore, and session cookies so a returning user isn't asked to consent all over again. The live log streams over fetch + ReadableStream rather than a plain EventSource, because we needed it to work with a POST request carrying a file upload, which EventSource doesn't support.

We split the work cleanly: one of us owned the frontend and the OAuth flow, the other owned the agent pipeline and the Google API integrations, with day 5 set aside as a hard pair-programming block to wire everything together before we let ourselves touch anything else.

Challenges we ran into

Getting Gemini to reliably produce dependency-aware scheduling, not just a task list, took more iteration than we expected. It's easy to get an LLM to list tasks; it's harder to get it to consistently reason "Task 3 blocks Task 4, so the sync has to land after Task 3 is due" and encode that correctly into structured output every time. We ended up validating the response against a strict schema and retrying with a corrective prompt when the sync-meetings array came back missing or malformed, rather than trusting the first response blindly.

The live-log streaming was its own small fight. Our first instinct was EventSource, which is the obvious choice for server-sent events, until we remembered EventSource only supports GET requests, and we needed to POST a PDF. Swapping to fetch with a ReadableStream on both ends solved it, but it meant re-thinking how the frontend consumed the stream.

And then there's the boring-but-real challenge: making sure one bad email address in a team list doesn't take down the whole run. Google's Gmail API will happily throw on an invalid address, and the first version of our EmailAgent let that exception propagate and kill everything downstream of it, including work that had already succeeded. We rewrote it so each send is caught individually, logged as a warning if it fails, and the agent keeps going. It's a small thing, but it's the difference between a demo that looks fragile and one that looks like it was actually built to survive contact with real data.

Accomplishments that we're proud of

Watching a stranger's real, never-seen-before PDF go in one end and come out the other as a populated Sheet, a Calendar full of correctly-timed meetings with real agendas, and a set of sent emails, with zero manual intervention, never stopped feeling a little bit magic, even after we'd seen it run a hundred times ourselves.

We're specifically proud of the meeting-agenda feature, because it's the part that isn't just "AI wrote some text." It's AI reading your actual brief and writing something you'd have had to write yourself otherwise, and putting it exactly where a human would look for it, inside the calendar invite. And we're proud that the system doesn't fall over the first time something goes wrong with it: a returning user skips the consent screen, a bad email gets logged and shrugged off instead of crashing the run, and the whole thing still ends in a Success screen with working links.

What we learned

The biggest lesson was architectural: an "AI agent" doesn't mean every step needs to be an LLM call. The moment we split the Planner (which genuinely needs judgment) from Sheets/Calendar/Email (which don't; they need to execute a decision that's already been made), the whole system got faster, cheaper, and dramatically easier to debug. When something broke, we almost always knew immediately whether it was a reasoning problem or a plumbing problem, because those were now two different kinds of code.

We also relearned, the hard way, how much of "AI product" work is actually just careful engineering around the AI part: schema validation, retries, graceful failure, token encryption, session handling. The Gemini call is maybe 10% of this codebase. The other 90% is what makes that 10% trustworthy enough to point at someone's real Google account.

What's next for SprintZero

A few directions we're excited about:

  • Editable plans before execution: right now the agent goes straight from reasoning to action; letting a user tweak the generated WBS or reschedule a meeting before anything gets written to their Sheet/Calendar is the natural next step
  • More integrations: Jira, Linear, and Notion are the obvious next targets alongside Google Workspace, since not every team lives in Sheets and Calendar
  • Slack notifications alongside email, since that's where a lot of teams actually live day-to-day
  • Smarter dependency detection: right now dependencies come from what the brief states or implies; we'd like to let the Planner ask clarifying questions when a brief is ambiguous instead of guessing
  • Support for more input formats beyond PDF: Google Docs, plain text, even a Slack thread, so "upload a brief" stops being the bottleneck it can occasionally still be

Built With

Share this project:

Updates

Submission history