A Bounded Agent Near a Live Deploy: What It Fixed, and What I Kept for Myself
July 30, 2026 · 5 min read
Created July 30, 2026 · Updated August 2, 2026
Slide deck
Building Technology Infrastructure for Scale
This is the companion page to my NITHUB Innovation Fair masterclass, Building Technology Infrastructure for Scale. If you just scanned this from the room, welcome. Whether or not you write code, the idea you watched is simple, and it matters most on the day your product suddenly gets popular. If you found this later, the short version is below, and the slides, the code, and the full write up are all linked from here.
What you just saw
An AI agent operating real infrastructure. A deploy had already failed before the agent was involved: a new part of the app needed a secret (a password or key) that nobody had added, so it failed its startup health check, and the platform quietly held the previous version and rolled back on its own. Production never went down. No agent and no human had to do anything. That is the floor everything else stands on.
Then the agent went to work. It read the failed deploy, followed a verified recipe instead of improvising, and worked out exactly which secret was missing. It never printed the value, because it does not need to see a secret to know one is absent. It proposed the fix, which was to add the secret and redeploy. And then it stopped, and asked me first.
That stop is the entire talk. Writing a credential is a privileged, hard to undo action, and the system will not take an action like that without a human, no matter how confident the agent is. I approved it, the secret went in, and the redeploy went green. Diagnosis was automated. The decision was mine. That is the split.
Why this matters the day you go viral
The day your product takes off is the day you are changing it the most, under the most pressure, with the most people watching. That is exactly when a confident, wrong, irreversible action does the most damage. Everything in this demo is about making that day survivable: a platform that fails safely on its own, and an agent that helps with the tedious half of the work while a human stays in charge of the half you cannot take back.
The three guardrails
Everything in the demo comes down to three limits, and you need all three:
- Constrain the procedure. The agent follows a verified recipe. It does not improvise steps from training data.
- Gate the privileged action. Diagnosis is free. Acting on secrets or live data stops and asks a human.
- Limit the blast radius. The agent never needs to see the secret to know it is missing, so a value cannot leak through it.
None of that makes the agent trustworthy. It makes it bounded, and bounded is what you can actually put in front of a live product.
Read the whole thing
I wrote the talk up as a four part series. Each part stands on its own, and each is written for someone building a product that they hope will have to survive success.
- Automated Rollback Is Not AI. It Is Competent Defaults. The safety property that has to exist before any agent shows up.
- Where an Agent Belongs in Your Infrastructure, and Where It Does Not. The honest split between the work to delegate and the work to keep, when you are a small team.
- Three Guardrails for Letting an Agent Operate Real Infrastructure. How you enforce the line, instead of hoping the model respects it.
- The Most Important Thing My Agent Did Was Refuse. The ninety second stop, and the one class of action I keep out of reach entirely.
The one thing I did not demo
I do not let the agent near database migrations, the operations that change the structure of your live data. Not gated, not approved, not at all. A bad migration is not a failed deploy that rolls back, it is data you may not get back. The agent can tell me a migration broke. It does not get to fix it. Deciding which class of action to keep out of reach entirely is a human judgment about consequences, and no tool makes that call for you.
The tools on screen
- Reoclo, the platform doing the blue-green deploys, health checks, and automatic rollback. DevOps as a service, under Boxmarshall. docs.reoclo.com
- The demo app, the two service project you saw, including the deploy that fails. on GitHub
- envsitter-guard, a small tool that keeps AI coding tools out of your
.envfiles. on GitHub - with-context-mcp, persistent and supervised memory for agents. on GitHub
Work with me
I am David Ibia. I build and run infrastructure through Boxmarshall, and Reoclo is how I turn that into something a team can buy rather than something one person absorbs as an unpaid second job. If the failed deploy in this demo looked familiar, or if you are staring down the day your own product might get popular, that is usually where the conversation starts. Come find me after the talk, or reach out through Reoclo.
Read the series
Enjoyed this? Let me know