← Back to Writing
Infrastructure for Scale Agentic AI Guardrails Reoclo MCP NITHUB Talk

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

Open full deck →
1 / 40 View all 40 slides →

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.

%%{init: {'theme':'base','themeVariables':{'fontFamily':'ui-monospace, monospace','primaryColor':'#1b2430','primaryTextColor':'#e8edf2','primaryBorderColor':'#3d5168','lineColor':'#6b7f99','clusterBkg':'transparent','clusterBorder':'#2a3645'}}}%% flowchart TD F["Deploy fails,<br/>platform rolls back on its own"] --> D["Agent reads the deploy,<br/>follows the verified recipe"] D --> R["Finds the missing secret,<br/>names it, never prints the value"] R --> P["Proposes the fix:<br/>add the secret, redeploy"] P --> STOP{"Privileged action.<br/>Stop and ask a human."}:::gate STOP -->|I approve| APPLY["Secret added, redeploy,<br/>health goes green"]:::live classDef gate fill:#3a2f12,stroke:#d6a32e,stroke-width:2px,color:#f4e6c2; classDef live fill:#10301d,stroke:#43c282,stroke-width:2px,color:#bff0d6;

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:

  1. Constrain the procedure. The agent follows a verified recipe. It does not improvise steps from training data.
  2. Gate the privileged action. Diagnosis is free. Acting on secrets or live data stops and asks a human.
  3. 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.

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 .env files. 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.

[ Resources ]

Enjoyed this? Let me know

45claps