Where an Agent Belongs in Your Infrastructure, and Where It Does Not
July 30, 2026 · 5 min read
Created July 30, 2026
Part two of a four part series on building infrastructure that survives success, following my NITHUB Innovation Fair masterclass, Building Technology Infrastructure for Scale. Part one argued that competent defaults, not the model, are what make an agent safe to try at all. This part is about where an agent actually earns its place when you are a small team, and where it quietly costs you.
Here is the situation a lot of you are in, or soon will be. You built something. It is starting to work. And you are the whole team, or close to it. You cannot hire a night shift, you cannot be awake for every alert, and an AI agent that reads your logs and tells you what broke sounds like exactly the teammate you cannot afford to hire. It can be. But only if you are clear about which half of the job you hand it.
The common mistake is to treat an operations agent as a general fixer: point it at everything and let it do whatever the prompt suggests. The version worth running is narrower and more honest. It does the half of the job where being wrong is cheap, and it stays away from the half where being wrong is expensive and hard to take back.
The split I actually use
| Safe to hand the agent (cheap to get wrong) | Keep in human hands (expensive or impossible to undo) |
|---|---|
| Reading through more logs than any human wants to | Touching passwords, API keys, and other secrets |
| Working out which change caused a failure | Running changes against your live database |
| Drafting a fix for you to review before it ships | Anything with no undo button |
| Writing the runbook nobody got around to writing | Acting on something it half remembered instead of checked |
| Explaining a 2am alert to whoever is awake | Anything where being confidently wrong is costly |
Look at the two columns and notice the divide is not difficulty. Reading a wall of logs and tying it back to the change that caused it is genuinely hard, and an agent is good at it. Setting one configuration value is trivial, and it still belongs firmly on the right. Capability is not the axis. Consequence is.
The real question is whether you can take it back
Everything in the left column shares one property: if the agent gets it wrong, you find out cheaply and you recover cheaply. A wrong guess about what caused an outage is a paragraph you disagree with. A bad draft fix is a code change you simply do not accept. The cost of the mistake is small, and you catch it before it touches anything real.
Everything on the right is the opposite. A password written to the wrong place, a change run against your live database, any action with no undo: the cost is unbounded, and you usually find out after the damage is done. So before you hand the agent any task, it comes down to two questions.
That is the whole test, and you can apply it without knowing anything about how the model works. If a mistake is cheap to notice and cheap to reverse, let the agent help. If it is either expensive to notice or impossible to reverse, keep it in human hands.
The trap: agents sound most sure where they should be least trusted
Here is the part that catches people, and it matters more the less technical your team is. An AI model is often most confident exactly where it should be trusted least. Ask it to write a change to your database, or to name a setting on a service it half remembers, and it will produce something clean, plausible, and specific, whether or not it is correct. It always sounds sure. On the left side of the table that is fine, because you were going to check its work anyway. On the right side, that same confidence is how you end up taking a wrong, irreversible action against something you cannot restore, because it sounded right and nobody paused.
This is why the answer is not a better prompt. You cannot prompt your way out of handing the agent the wrong kind of job. The agent will always be willing. The judgment about what to hand it has to live outside the agent, with you.
What this looks like in practice
In the demo I run on stage, the agent diagnoses a failed deploy. It reads the deployment, works out that a new route needs a secret (a password or key the app requires) that is not set, and it proposes the fix. All of that is the left column, and it is genuinely useful. It just compressed a chunk of stressful debugging into about a minute. Then it reaches the right column, which is writing the secret and redeploying, and it stops. It does not act. It asks.
That stop is not the model being polite. It is the system drawing the line for it, on purpose, at the exact boundary between the two columns. How you draw and enforce that line, so it holds even on your busiest day, is the next part of this series.
Next: the three guardrails that let a small team put an agent on real infrastructure without holding their breath.
From the talk
Enjoyed this? Let me know