I watched the discussion on agentic loops grow louder and peaking last week. But for me, the reality is simpler: prompt engineering has shifted from individual tasks to systems design, and the workflow (not the model) is now my primary constraint in software engineering.
I categorize the work we give to our agents into several distinct tiers:
- A simple question: This does not require an agent; an assistant can answer it.
- A task / idea: This is one where a single prompt can zero-shot it. I love using AI Studio for quickly transforming ideas to functional prototypes.
- An app / larger feature / story: The kind of work that required weekly planning and splitting into subtasks before AI. This is where loops start to make sense for execution and full-featured agents, like Antigravity make a difference.
- A project / epic: A few features that make a cohesive story when connected. Loops here might help with planning too. This is also where one needs to go beyond simple turn-based prompting.
- A system: All the projects and tasks seen from a bird’s eye view. This is the deep end, where one would create skills, set up sidecars, and configure an instrument cluster to keep themselves on top of everything. Loops at this level make the biggest difference.
Why the loop?
The baseline of software development is shifting. This shift represents a basic law of human nature: we seek the highest leverage possible, moving from manual labor to delegation, and finally to orchestration. With attention being the new bottleneck, anything that allows the work to continue with less interruption could make a move in the right direction. By early 2026, empirical research of open-source projects estimated that coding agent adoption had reached between 15% and 22% of active repositories on GitHub. Those who master agentic workflows now operate with a level of leverage that elevates their entire team’s productivity, however this also increases the cognitive load on everyone who is taking responsibility at the systemic level.
To understand this shift, let’s trace the technical lineage of loops and set some high level expectations.
Academic foundations
The academic seed was Yao et al.’s ReAct paper in October 2022, which interleaved reasoning traces with tool calls. It beat reinforcement learning baselines by 34% on ALFWorld and 10% on WebShop by reasoning before acting, mirroring human nature: we perform better when verbalizing plans. Then came AutoGPT in early 2023, raising millions in venture funding. While its early iterations frequently spun in infinite loops, it proved developers wanted hands-off automation, highlighting the need for structural guardrails.
Stateless experimentation
Consequently, practitioners sought simpler architectures. In mid-2025, developers ran stateless bash loops that piped prompts into command-line agents and reset context files on every tick. Resetting context prevented cognitive bloat, acknowledging that human memory limits also apply to models. It successfully built self-hosting compilers over months of automated runs. By spring 2026, major tool environments absorbed this pattern, shipping native commands like /goal to let agents run unattended loops.
The mathematics of autonomy
Let’s take a simple theoretical example:
If you put your agent in a flat sequential chain to complete multiple tasks in a row, its success rate degrades exponentially. When each of its individual steps operates as an independent probability event, a sequence of N steps has a cumulative success rate of p^N. For instance, if you run a task requiring 20 consecutive file modifications with a model that has p = 0.95 accuracy, you face a success rate of only 36%. Without your structural interventions, they will fail almost certainly.
This is why we need evaluation loops. A verification gate should not force your agent to retry indefinitely (which causes infinite spinning runaways). Instead, it should pinpoint where the error occurred and allow the model exactly one targeted retry to fix it. If your agent has a 95% base accuracy, and your evaluation loop has a 95% chance of spotting and fixing the error on that single retry, the effective step success probability rises to 0.95 + (0.05 x 0.95) = 99.75%.
Even if fixing fails, just spotting the error with a 95% accuracy, allows you to jump in and manually realign the system while keeping the same 99.75% subagent accuracy and only paying the cost of human-in-the-loop intervention.
What about context bloat?
If each step in a chain adds approximately 1% of context in tokens, we end up with a chain that is not much longer than 50 steps before we require compression. A 95% base accuracy that can be evaluated (and course corrected with 95% accuracy for each dimension that we care about) should keep us at good success rates for such individual running agents. If we establish a scalable way to divide and conquer problems, we can apply similar principles to drive our subagents. As we can see, at 20 steps, a 95% accuracy paired with a single-retry corrective loop yields a 95% end-to-end success rate (assuming the correction itself stays under our 20 steps soft limit) while keeping context size reasonable. Note that there is no explicit requirement for the correction to be AI or human driven, but rather it needs to produce accurate and verifiable results.
This is where I place my bet: dividing problems into tasks that require a small number of steps each. If a problem is more complex than this, it remains approachable, but it must be divided into smaller subproblems, and so on. For our example, this means allocating up to 20 steps for each level agent / task / trajectory and another 20 steps for the next level supervisory agent to consolidate contributions. To prevent drift, this also means establishing separate evaluations at all subagent and supervisory levels, alongside final acceptance criteria.
Lastly, we must evaluate these metrics ourselves at least once for each level to verify that they measure the right target before running automation at a higher level. These are ballpark estimations, but I keep them in the back of my mind to quickly decide whether I should split a problem, repeat a step, or commit results and move on.
In practice, your numbers will look different, but the scaling laws will be similar.
How to build a durable system
What started as a source of friction has now become one of my primary driving curiosities: how do we build automation when we still have a lot to learn about the craft itself? I have a few ideas.
To build a loop that does not run off a cliff, we must establish core guardrails that will keep accuracy high and will allow us to debug and intervene whenever necessary. Specifically, these are the pillars I identified:
- Durable state: Git-backed checkpoints ensure that your agent can resume work after a crash.
- Verification gates: Automated test suites and compilers deterministically check that the changes are correct. When done properly, they will have >95% accuracy. However, you should be on the lookout for edge cases you might have forgotten about. Especially if verification, evaluation, or manual validation success rates diverge for any of your features.
- Evals: Anything that cannot be deterministically verified but is important should have an evaluation or benchmark which you can later inspect for accuracy. Try to write them in a way that will keep answers to a simple yes or no and accuracy high, ideally over 95%. If you’re getting results that point to confusion or unexpected failures, you probably need to split the criterias into simpler ones.
- Halt conditions: Turn limits (as we saw above, 20 seems to be the sweet spot) and token or dollar cost ceilings stop runs before API budgets get out of control.
- Standardized skills: Reusable utilities, documented in the SKILL.md format, preferably bundled with code and source of truth references.
Platform native systems
Platforms like Antigravity have codified these patterns (/grill-me and /goal) into native primitives, shifting the work from custom scripts to platform capabilities for most straight forward use-cases. I would encourage you to give these a try. Do remember, however, to keep an eye on trajectory lengths and look for model confusion.
I myself frequently rely on the native /goal primitives in Antigravity 2.0 when coordinating multi-turn tasks that require extensive validation and measurements before completion. To anchor this execution, I used the /grill-me command for an interactive interview to lock in design constraints before running my /goal loops.
Constructing the metrics for this technical article and then editing it is just one example of how I use these execution loops.
By pairing /goal with /grill-me, you can establish an effective pair-programming dynamic: alignment on intent, followed by autonomy in execution.
Custom DIY loops
To understand the evolution of loops, we can compare two distinct architectures for DIY agentic loops:
Stateless five-liner
Geoffrey Huntley’s “Ralph” loop is a prime example of stateless architecture. Here’s the simplest working version of an Antigravity CLI loop:
limit=20
for ((i=1; i<=limit; i++)); do
agy -p - < prompt.md || break
./commit-and-test && break
done
While simple, the stateless loop is fragile for multi-file coordination because resetting context discards thinking logs.
A good agent skill could fix much of this limitation by instructing the model to output relevant progress reports in wiki-like markdown files and track changes by looking at git logs.
Still, this complexity has led to developer challenges in larger multi-agent environments, for which custom loops seem to hold the promise.
So what if you want to go to the deep end?
If you want to try your hand at writing a custom loop from scratch, here is a practical Python implementation using the Google Antigravity SDK. Specifically, this loop initializes an agent session, executes a task, verifies the output, and enforces strict iteration budgets. Far from being a production-ready solution, this is an experimental starting point that you can adapt to suit your individual needs:
import asyncio
from google.antigravity import Agent, LocalAgentConfig
async def verify_output(workspace_path: str) -> bool:
"""Verification gate with tests and evals."""
# TODO: Run tests, linters, and evals here.
return True
# 1. Define subagent configurations with a limit of 20 iterations and a token budget
research_config = LocalAgentConfig(
system_instructions="You are a research subagent. Analyze the codebase and find implementation paths.",
max_iterations=20,
token_budget=50_000
)
feature_config = LocalAgentConfig(
system_instructions="You are a feature implementation subagent. Write robust code and fix compiler errors.",
max_iterations=20,
token_budget=100_000
)
# 2. Expose the researcher and implementation configs as subagents for the supervisor
supervisor_config = LocalAgentConfig(
system_instructions="You are a supervisor agent. Delegate to your research and feature subagents to complete tasks.",
subagents={
"researcher": research_config,
"feature_implementer": feature_config
},
token_budget=200_000
)
async def run_agentic_loop(prompt: str, max_iterations: int = 20) -> bool:
"""Supervisory loop. We only instantiate and run the supervisor explicitly."""
async with Agent(supervisor_config) as supervisor:
iteration = 0
success = False
while not success and iteration < max_iterations:
iteration += 1
print(f"[Supervisor Loop] Running iteration {iteration}/{max_iterations}...")
# Send prompt to the supervisor; it spawns subagents autonomously as needed
response = await supervisor.chat(prompt)
await response.text()
# Enforce token budget limits across the supervisor session
usage = supervisor.conversation.total_usage
if usage.total_token_count and usage.total_token_count > supervisor_config.token_budget:
print(f"❌ Loop halted: Token budget of {supervisor_config.token_budget} exceeded.")
break
# Verify the output in the workspace
success = await verify_output("./workspace")
if success:
print("🎉 Goal completed successfully.")
break
prompt = f"The previous attempt failed tests with the following error:\n{error_msg}\nFix the compiler errors and retry."
return success
if __name__ == "__main__":
asyncio.run(run_agentic_loop("Refactor types.go to use explicit interfaces.", max_iterations=20))
For developers who prefer not to build and host their own custom SDK loops from scratch, Google provides the Antigravity Agent, an autonomous, asynchronous coding agent. It operates in a secure, isolated Google Cloud virtual machine. This way one can create similar agentic loops by using managed agents to orchestrate execution plans under Google managed infrastructure.
No one size fits all
You must establish a clear boundary for each of your validation systems that allows you to stay in control. No matter how perfect your loop, if you, as the responsible human, cannot sign off your agent’s output, there is minimal value in any of the artifacts it is producing. The good news is that building a quality evaluation scorecard or a loop algorithm uses a similar process to producing any other type of software artifact. So, much of the execution will be automated.
Finally, to make a sound judgment, you should observe each loop from the inside. As you see things working out, with this acquired confidence you step one level up. This is the only way to learn where the agent struggles and how to improve the process itself. One can only tune the machinery when they sit in the operator’s seat.
How to Build a Durable Agentic Systems with Antigravity: From Instructions to Loops was originally published in Google Cloud – Community on Medium, where people are continuing the conversation by highlighting and responding to this story.
Source Credit: https://medium.com/google-cloud/how-to-build-a-durable-agentic-systems-with-antigravity-from-instructions-to-loops-4f96c057aedd?source=rss—-e52cf94d98af—4
About the Author
