Inspiration
Most of the distance between a filed GitHub issue and a merge ready pull request is not writing code. It is reading the codebase, turning a vague request into a spec, choosing an approach that fits what already exists, writing tests, and documenting why. That work is real but repetitive. The Taskmaster track is about an event triggering autonomous routing across systems, and "issue labeled" to "pull request opened" is exactly that shape. I had built a multi agent system before on LangGraph, so the typed state and multi node model carried over. This time the framework was Google ADK.
What it does
Label a GitHub issue agent-ready. A webhook fires, and a pipeline of seven agents plus a deploy step carries the issue through the full SDLC with no manual steps in between. It ends in an opened pull request containing the code change, generated tests, and an architecture decision record, with Closes #<issue> in the description.
The agents run in sequence:
- Context searches the real repository through the GitHub MCP server, so every later agent is grounded in actual code.
- Requirements turns the issue into a structured spec with acceptance criteria.
- Design proposes an approach under a hard rule: no new frameworks, no new architecture, no restructuring.
- Code writes the implementation and its own unit tests, then loops on itself until those tests pass.
- Test adds a regression suite over the existing code and an end to end suite over the whole system.
- Review critiques the diff and either approves or routes the run back to Code.
- Documentor writes the decision record from the full run history.
Then a plain deploy function clones the repo, branches, commits, pushes, and opens the PR.
Three feedback loops run through this: Code looping on its own tests, Review sending work back to Code, and Test repairing its own generated test file when it fails to even parse.
How I built it
- Google ADK for every agent. The orchestrator is a plain sequential async function that wires the eight steps together and runs the loops as real control flow.
- Gemini 3.5 flash lite for every model call, through Vertex AI.
- Cloud Run hosts the webhook receiver and the pipeline. It scales to zero.
- Firestore in Native mode holds shared state, one document per run, one field per agent as it completes. Documentor reads the whole document to write its record.
- GitHub MCP server gives Context agentic search over the live repo, running as a binary over stdio inside the container.
Build order: infra and webhook receiver first, then every agent standalone against fixtures, then the orchestrator and run store, then real runs on Cloud Run.
Challenges I ran into
- Rate limits. The AI Studio free tier is 15 requests per minute. One pipeline run makes many times that in its first minute, and duplicate webhook deliveries multiplied it. I learned that the Gemini Developer API and Google Cloud are separate billing systems, so the hackathon Cloud credit does not top up an AI Studio key. Moving every agent to Vertex AI fixed both the quota and the billing.
- MCP in a serverless container.
docker runfor the GitHub MCP server does not work on Cloud Run, and the hosted MCP endpoint returned 400 through ADK's client. The working transport was a binary copied out of GitHub's image, run over stdio. - Silent degradation. When the deploy agent's MCP tools failed to load, ADK ran it tool less and the model fabricated an empty pull request result while the run still reported success. I replaced that agent with a plain function that returns a real PR or raises. The lesson generalized: mechanical steps should fail hard, not improvise.
- Executing generated code. A per run isolated Cloud Run job is the right sandbox, but it is a second deployable with its own IAM and failure modes. On a ten day timeline I built a subprocess sandbox behind a clean
execute(files, tests)interface so it can be swapped later, and baked the demo repo's importable dependencies into the image so generated imports resolve. - Real failure versus authoring bug. A generated test file with a syntax error is not a test result. The Test agent now self heals a collection error at the source, but passes a genuine failing assertion straight through to Review as real signal.
Accomplishments that I am proud of
- A full run on live infrastructure: from labeling the issue to an opened pull request in about four minutes, on Vertex Gemini 3.5, Google ADK, Cloud Run, and Firestore.
- Real pull requests on a demo repo, including a backend change that threaded through the app's actual request path, not just a static frontend tweak.
- All three feedback loops working as real control flow, including agents catching and correcting their own mistakes with no human watching.
- Turning several silent failure modes into hard, visible failures.
- Stage by stage observability straight from the Cloud Run logs, no custom dashboard required.
- The stack satisfies all three mandate requirements: Gemini 3.5 through Vertex, a Google agent framework, and Google Cloud infrastructure.
What I learned
- ADK's agent and tool model, and how MCP tools plug into it.
- Where MCP earns its place, agentic search over a live repo, versus where a plain function is simpler and more reliable.
- LLM systems fail silently by fabricating confident output. The architecture has to force hard failures at every boundary.
- How to design a swappable execution boundary under time pressure instead of building the full version and running out of days.
What's next for Agentic SDLC Pipeline
- Run the code sandbox as its own isolated Cloud Run job per run.
- A live dashboard reading the same Firestore state so the stages are visible without opening the logs.
- Move Design and Review to a larger Gemini model, which is two environment variables.
Log in or sign up for Devpost to join the conversation.