zipcode Cloud Relay: Field Coding Agent for Low-Connectivity Teams
Inspiration
Modern coding assistants are powerful, but they assume the developer is always online and allowed to send source code to a cloud service. That does not match a lot of real work: disaster-response laptops, rural school labs, clinics, NGOs, public infrastructure sites, and field engineering teams often face weak connectivity, privacy limits, or compliance rules.
The original zipcode prototype was built for that gap: a local-first coding agent that reads a bounded workspace, gathers evidence, and produces a grounded patch plan without uploading source code. For the Google Cloud Rapid Agent Hackathon, the project becomes zipcode Cloud Relay: a real-world field coding agent that can work locally when the network is unavailable and then sync approved engineering actions through Google Cloud and GitLab when connectivity returns.
What it does
zipcode Cloud Relay helps a field operator or developer:
- inspect a local code workspace inside a strict sandbox,
- gather file lists, selected file contents, and search evidence,
- ask Gemini for a grounded patch plan based only on approved evidence,
- preserve an audit-friendly transcript,
- prepare a connected handoff once the operator approves the plan,
- use GitLab MCP to create issues, draft merge requests, summarize review context, and track the fix workflow when the network is available.
The point is not to turn the agent loose without oversight. The point is to give people in difficult environments a controlled coding assistant that can reason, plan, and take useful engineering actions while keeping the human in charge.
How I built it
The base agent is a small Python CLI. It uses only the standard library for the local path: workspace sandboxing, file listing, file reading, text search, and transcript generation. The previous version used a local Gemma model path for fully offline operation.
For this hackathon direction, the Google Cloud architecture adds a connected relay:
- The local zipcode agent collects bounded local evidence and a human-readable task.
- Google Cloud Agent Builder orchestrates the connected agent experience with Gemini.
- Gemini reasons over the approved evidence bundle and plans the fix workflow.
- GitLab MCP gives the agent actionable software delivery tools: issue creation, merge request drafting, code review notes, and status updates.
- The operator reviews and approves any action before the agent pushes workflow changes to GitLab.
This keeps the most sensitive part, raw source inspection, local and bounded, while still using Google Cloud and GitLab MCP for the real-world actions that make an agent more useful than a chatbot.
What makes it useful
The strongest part is the hybrid workflow. Many agents are either cloud-only or local-only. zipcode Cloud Relay is designed for teams that move between those worlds. A field team can troubleshoot offline, save evidence and a patch plan, and later turn that plan into tracked engineering work in GitLab without retyping the whole context.
That makes the agent practical for real environments: clinics, public-interest teams, field robotics programs, disaster logistics software, school labs, and privacy-sensitive internal tools.
Challenges
The hardest design choice is deciding what the agent should not do. In a sensitive or low-connectivity setting, fully autonomous code changes can be risky. The project therefore uses a human approval model: the agent gathers evidence, proposes a plan, and prepares GitLab actions, but the operator remains the decision point.
Another challenge is making the Google Cloud layer meaningful without destroying the local-first privacy story. The solution is to send only approved evidence and workflow metadata to the connected relay, not a blind upload of the whole repository.
Accomplishments
- Built a working local-first zipcode prototype with workspace sandboxing.
- Created a clear field coding scenario around water sensor parser debugging.
- Designed the Google Cloud Agent Builder extension around Gemini and GitLab MCP.
- Kept the workflow auditable: every action ties back to local evidence and explicit operator approval.
What I learned
The most useful agents are not just models with tools. They are workflows with boundaries. For this problem, the boundary matters as much as the intelligence: what files can be read, what evidence can leave the machine, what actions require approval, and what gets recorded for later review.
What's next
Next steps are a hosted demo UI, a public repository with the Google Cloud relay code, GitLab MCP wiring, a three-minute demo video, and a stronger approval queue for turning patch plans into merge requests. Later versions could add transcript signing, packaged installers, local multimodal evidence, and connectors for issue trackers used by public-sector and field teams.
Log in or sign up for Devpost to join the conversation.