BuildLoop
Inspiration
AI coding agents can increasingly plan, write, and modify software with very little human intervention. That is powerful, but it creates a new problem: how much authority should an autonomous coding agent actually have?
A coding task can begin as something harmless and eventually touch credentials, protected files, dependencies, infrastructure, or an irreversible action such as deployment.
BuildLoop was created around a simple idea:
Autonomy should increase productivity without removing human control.
BuildLoop is a governed autonomous software-delivery orchestrator. It completes bounded development tasks autonomously while preserving human control over security-sensitive and irreversible actions.
It is not intended to replace developers or act as another coding chatbot. Instead, it sits around the coding process and governs how work is planned, executed, checked, corrected, and approved.
What it does
A BuildLoop run follows a bounded lifecycle:
- A user provides a software-development goal.
- BuildLoop converts the goal into a task contract with explicit acceptance criteria.
- A coding worker receives the approved scope and performs the implementation.
- An independent checker evaluates the resulting evidence against the contract.
- If the failure is correctable, BuildLoop can send the task back for self-correction.
- Self-correction is strictly bounded to a maximum of two attempts.
- The run resolves to a clear state such as PASS, FAILED, or BLOCKED.
- Security-sensitive or irreversible actions stop the autonomous workflow and require human approval.
The key distinction is that the worker does not decide whether its own work succeeded. Verification and governance remain separate from execution.
Governed autonomy
BuildLoop treats autonomy as a permissioned capability rather than an unlimited one.
The orchestration layer can stop a run when it encounters conditions such as:
- protected paths;
- credentials or secrets;
- sensitive dependency changes;
- actions outside the approved task contract;
- security-sensitive operations;
- irreversible actions requiring human authorization.
Actions such as commit, push, merge, or deployment can therefore remain human-controlled instead of being silently performed by the agent.
This gives BuildLoop two important behaviors for the demo.
PASS scenario
A bounded and safe software-development task is converted into a contract, executed by the worker, checked independently, and completed after satisfying the acceptance criteria.
BLOCKED scenario
A task reaches a protected or sensitive boundary. Instead of continuing autonomously, BuildLoop stops the run and surfaces the reason to the user, preserving human control.
How we built it
BuildLoop separates the software-delivery lifecycle into distinct responsibilities rather than relying on one unconstrained agent.
The orchestration flow includes:
- task contract generation;
- preflight governance checks;
- worker selection and execution;
- independent verification;
- bounded self-correction;
- decision evaluation;
- evidence recording;
- approval boundaries.
Google Agent Development Kit (ADK) provides the agent orchestration path.
Gemini 3.6 Flash is used in the agent execution workflow. The model is particularly suitable for BuildLoop because the workflow involves coding, planning, and iterative agentic execution.
The backend is packaged to run using Google Cloud Run, providing the Google Cloud execution environment used for the hackathon prototype.
The application layer is built primarily with TypeScript and a React-based web interface, while the governance engine is intentionally kept explicit and inspectable instead of hiding the entire lifecycle inside model prompts.
For the demo, BuildLoop works against a real greenfield software project so that the workflow can demonstrate an actual software-development task rather than a synthetic chatbot conversation.
Architecture
At a high level, the workflow is:
User Goal → Task Contract → Governance Preflight → Coding Worker → Independent Checker → Bounded Correction → Decision → Human Approval when required
This separation matters.
The coding worker can propose or implement changes, but it cannot unilaterally redefine the acceptance criteria or declare itself successful.
The checker evaluates evidence independently, while the decision layer determines whether the result should pass, fail, retry, or stop.
Challenges
Distinguishing software failure from infrastructure failure
One of the most important challenges appeared while testing the Gemini/ADK execution path.
An upstream API quota failure could initially look like a failed coding attempt. That created the risk of BuildLoop wasting its correction budget trying to "fix" a task when the real problem was operational.
We changed the governance semantics so operational failures are classified separately from correctable implementation failures.
This reinforced an important lesson: an autonomous system needs to understand when not to retry.
Preventing false success
It would have been easy to let the worker return a success message and present that as completion.
Instead, BuildLoop separates worker output from checker evidence and the final decision. A run only passes when its acceptance criteria have actually been evaluated.
Balancing autonomy and control
Too many approval steps make an agent little more than a manual workflow tool.
Too few approval boundaries make it unsafe.
We therefore focused on a bounded vertical slice: allow autonomous execution and limited self-correction for safe work, but stop at protected and irreversible boundaries.
Keeping the prototype focused
There are many possible extensions: full GitHub automation, multi-tenant execution, deployment pipelines, larger agent teams, marketplace integrations, and enterprise policy engines.
For this hackathon we deliberately avoided those expansions and concentrated on proving one complete governed software-delivery loop.
What we learned
The biggest lesson from BuildLoop is that better autonomous agents do not only need better reasoning.
They need better boundaries.
Several design principles emerged during development:
- execution and verification should be separate;
- retries should have explicit limits;
- operational failures should not consume semantic correction attempts;
- acceptance criteria should exist before execution;
- sensitive actions should fail closed rather than continue optimistically;
- human approval is most useful at meaningful risk boundaries, not at every step;
- evidence is more valuable than an agent simply claiming that a task succeeded.
This changed how we think about agentic software development.
The important question is no longer only:
"Can the agent complete the task?"
It is also:
"Can we prove what it did, constrain what it may do next, and know when it should stop?"
That is the problem BuildLoop is designed to address.
What's next
BuildLoop currently focuses on one intentionally narrow vertical slice of governed software delivery.
Future work could extend the same governance model toward richer repository integrations, persistent execution, policy configuration, larger development workflows, and additional verification mechanisms.
But the underlying principle remains the same:
BuildLoop completes bounded software-development tasks autonomously while preserving human control over security-sensitive and irreversible actions.
How to test BuildLoop
The recommended evaluation path demonstrates the two core governance outcomes.
1. PASS scenario
- Sign in to the hosted BuildLoop application.
- Open the provided demo project.
- Select or create the safe demo task.
- Review the generated task contract and acceptance criteria.
- Start the run.
- Observe BuildLoop move through planning, preflight, worker execution, independent checking, and decision.
- The run should finish as PASS when the acceptance criteria are satisfied.
- Review the Evidence section to inspect the recorded execution and verification results.
2. BLOCKED scenario
- Select or create the protected-action demo task.
- Start the run.
- BuildLoop should detect that the requested operation crosses a governed boundary.
- The autonomous workflow should stop instead of executing the sensitive action.
- Review the displayed reason and human-approval requirement.
No destructive action is required to reproduce the BLOCKED scenario.
Demo credentials, when required, are provided privately to judges through the Devpost testing instructions.
Reproducibility
The repository README contains setup, environment configuration, local execution, testing, and PASS/BLOCKED reproduction instructions.
The submission uses:
- Google ADK for agent orchestration
- Gemini 3.6 Flash for agent execution
- Google Cloud Run for the deployed backend
- Cloud Firestore for orchestration run state and execution evidence
- Supabase for the application authentication and user-facing application layer
Google Cloud execution evidence is also demonstrated in the submission video.
Log in or sign up for Devpost to join the conversation.