Microsoft MVP Rafael Ferreira shares how he uses loop engineering to build safer, more reliable AI agent workflows for high-stakes infrastructure work. Drawing on his experience with GitHub Copilot, Azure, Terraform, AKS, and GitHub Actions, he explains how lightweight hooks, verification gates, restricted tools, and human approval can help engineers automate repetitive tasks while keeping judgment and accountability firmly in human hands.
By Guest Blogger Rafael Ferreira, Microsoft MVP in Azure, Cloud & DevOps engineer based in Florianópolis, Brazil. Community organizer with Azure User Groups Brasil, speaker at DevOpsDays, TDC and KCD, and volunteer mentor in cloud and DevOps programs. He writes in Portuguese at orafaelferreira.com.
From prompting agents to designing reliable loops
I have been working with LLMs and coding agents for about two years, most of that time with GitHub Copilot. Over the last few months, the shape of the work changed: I stopped writing prompts and started designing the thing that writes them.
That shift has a name now: loop engineering. You replace yourself as the person who prompts the agent and design the system that does it instead. But the interesting part is not the autonomy. It is that a loop only works when something outside the model can say "this is wrong." Agents need ground truth from the environment, not from their own opinion.
My context makes that impossible to skip. I work on multi-tenant platform engineering on Azure: Terraform, AKS, GitHub Actions. When an agent is wrong in application code, a test turns red. When an agent is wrong here, an environment goes down.
I use AI agents this way because the stakes in my work are real: a mistake here does not just fail a test; it can take a shared production environment down. Letting the agent handle the repetitive, error-prone checking, and keeping every judgment call for myself, is what lets me move faster without handing away the decisions only a person should make.
That matters beyond my own setup. Loop engineering gives us a practical way to use AI agents safely in high-stakes engineering. Lightweight hooks, explicit verification gates, restricted tools, and human approval make repetitive work easier to automate while keeping judgment and accountability with the engineer.
My story: four guardrails that held up in practice
The cheapest verifier in my setup has no AI in it: a thirty-line shell hook catches a mistake and feeds the correction back into the loop. When the hook exits with code 2, whatever it writes to stderr is added to the model's context as an error. The model receives the correction at the exact moment of the mistake, expressed in words I chose. That is the feedback path from the theory, implemented in Bash.
Guardrails before generation, not after. The standard pattern is generate, then verify. I moved part of it earlier: my rules force the agent to validate provider versions and resource schemas through an MCP server before it writes the first line of Terraform. The cheapest verifier in the world is the rule that keeps the error from existing.
Order the gates by cost and risk. In infrastructure, each later check runs closer to the real environment and carries a greater potential blast radius. So, the verification ladder is explicit: lint first, validate the configuration and schema, run the plan, then perform health checks after apply. The agent never skips a rung. It is the test pyramid, priced in operational risk rather than execution time.
Separate the writer from the checker through tools, not instructions. Telling an agent that it is read-only relies on compliance; withholding write tools enforces the boundary. My reviewer agents cannot edit, real clusters give agents read-only access, and only a local cluster accepts agent-initiated writes. That asymmetry is the guardrail.
One more hook I would write first if I started over: every destructive operation stops and asks for confirmation, in every permission mode, including the one where I told the tool to stop asking. I have already told the story of the Friday I took production down with my name on the log; I am not curious about the version where an agent typed the command. In twenty days, that hook intercepted 100 destructive operations, about five a day. A simple confirmation gate can prevent an automated action from proceeding unchecked.
Impact and insights
Two habits changed my results more than any model upgrade.
The first is an anti-reward-hacking rule: when the agent adds a regression test, it has to prove the test fails if you revert the fix it protects. Agents are excellent at writing tests that pass. "Write a test and show me it catches the bug" is a different request.
The second is letting the agent read CI results directly, but only the failed steps. The command gh run view --log-failed returns the broken portions of a GitHub Actions run rather than the complete workflow log. That keeps the relevant error visible and avoids filling the agent's context with unrelated output.
The piece that surprised me most is a weekly scheduled routine that reviews my working sessions and turns recurring patterns into written procedures. On its first real run, it proposed one new procedure worth keeping, improved two existing ones, rejected four and recorded why, and corrected one of my notes that was simply wrong. The loop does not just execute the process; it improves the memory that guides future runs.
Start with guardrails, not autonomy
The part I will not delegate is the outer loop. The objective comes from a work item, and the merge is mine. Delegating the inner loop is leverage; delegating judgment is abdication.
If you want to start, do not start with autonomy. Write one hook that blocks destructive commands and forces you to confirm, especially in the mode where you already told the tool to stop asking. It protects against you on autopilot, not against the model, and it costs an afternoon.
Key learnings
Safer AI agent workflows begin with clear boundaries: ground truth from the environment, verification gates ordered by risk, tools that enforce permissions, and human control over objectives and final decisions. Together, these guardrails turn repetitive automation into dependable engineering practice without giving away accountability.
What is one guardrail you could add today to make your next AI agent workflow safer? Let us know in the comments.
Want to Learn More About the MVP Program?
To find an MVP and learn more about the MVP Program visit the MVP Communities website and follow our updates on LinkedIn or #mvpbuzz.
Join us for a future live session through the Microsoft Reactor where we walk through what the MVP program is about, what we look for, and how nominations work. These sessions are designed to help you connect the dots between the work you’re already doing and the impact the MVP Program recognizes — with time for questions, examples, and real conversations.
Microsoft