The reference architecture for an agent that operates infrastructure is more settled than it was a year ago. An orchestration layer running the reason-act-observe loop. A tool layer exposing Kubernetes, the cloud account, the deployment system and the observability stack. An approval layer. Memory across tasks. Audit logging.
The components are right. The interesting part is where the safety actually lives, and published architectures are usually ambiguous about it in the same place.
Read the system prompt as a list of hopes
Here is the shape of the rules block in one of these, condensed:
CORE RULES (never violate these):
1. Before any write action (apply, delete, modify, merge), call request_approval().
2. Never take multiple write actions in sequence without approval for each.
3. If uncertain about root cause (confidence < 80%), investigate before remediating.
4. Always check recent deployments before concluding a non-deployment cause.
5. Log every significant finding with log_finding() before acting on it.Read that as an operator and it looks like a safety system. Read it as a control and every line has the same property: the agent complies by choosing to.
Rule one asks the model to call a function before deleting a deployment. If the model does not call it, the deletion proceeds. Nothing in the prompt is capable of stopping it, because a prompt is text the model reads, not a mechanism it runs inside.
The capitalised “never violate these” adds no force. Emphasis is not enforcement.
Sort every measure into two columns
The exercise takes twenty minutes and changes what you build.
| Measure | Enforced or requested |
|---|---|
| System prompt says to request approval before writes | Requested |
| The write tool itself blocks until approved | Enforced |
| Credentials scoped so delete is not permitted at all | Enforced |
| ”Never take two writes in sequence” | Requested |
| A turn cap in the runner | Enforced |
| ”Investigate more if confidence is below 80%“ | Requested, and unmeasurable |
| Audit log written by the tool layer on every call | Enforced |
| ”Log every finding before acting” | Requested |
The pattern is not subtle once the column exists. Everything enforced is code that runs regardless of what the model concluded. Everything requested is a sentence.
That is the same distinction as hooks against instructions: deterministic code at a fixed point produces a guarantee, and everything else in the stack is probabilistic. It is the difference between “the agent has been told not to” and “the agent cannot”.
The good news is that these systems usually do both
Look further into the same architectures and you find, quietly, a line like # wrap write tools with approval gate.
So the gate is real. The tool wrapper intercepts the write, blocks, and waits. The prompt rule is redundant, and redundancy is fine.
The risk is not that these systems are unsafe. It is that the prompt and the wrapper look equally load-bearing in a diagram, so a team can remove the wrapper during a refactor, keep the prompt, and believe the control survived. It reads the same in review. It behaves the same in every test where the model happens to comply.
Then it behaves differently exactly once, at three in the morning, on the unusual input. Which is where a probabilistic control always fails, because typical inputs are what it was tuned against.
So the useful discipline is to write down which layer holds each control, and to treat a prompt rule that has no mechanism behind it as an open item rather than a feature.
The threshold that cannot mean anything
Rule three deserves its own paragraph, because the number makes it look rigorous.
“If confidence is below 80%, investigate further” asks the model to estimate its own certainty and act on the estimate. There is no calibration behind that figure. A model reporting 85% is not right 85% of the time; it is producing a plausible-looking number in a field that expects one.
The failure is quiet and specific. Confident-and-wrong is the exact state in which the rule permits remediation, so the check disengages precisely when it was needed.
What works instead is external and boring: has this hypothesis been corroborated by a second signal, did the deploy timeline actually line up, does the metric move when the proposed cause is removed. Those are checkable by something other than the thing being checked, and an unmeasured judge relocates uncertainty rather than removing it.
Where prompts genuinely earn their place
None of this makes the system prompt useless. It makes it the wrong home for guarantees.
The same block usually contains an investigation order — scope the impact, check recent changes, look at current state, read logs, form a hypothesis, then propose a remediation. That is excellent, and it belongs exactly where it is.
The difference is what happens when it is not followed. Skipping a step in the investigation order produces a worse diagnosis, which a human reviews. Skipping the approval call produces a deleted namespace. Prompts are good at ordering work and useless at preventing harm, and most rule blocks mix the two without marking which is which.
A small formatting habit helps more than it should: keep guidance and constraints in separate sections, and for each constraint name the mechanism that backs it. A constraint with no mechanism named is a constraint you have not built yet.
The objection: enforced gates get clicked through
Worth meeting head-on, because it is the real operational failure of this design.
Make every write require approval and the approvals arrive constantly. A human who is asked forty times a day stops reading the description and starts pattern-matching on the shape of the dialog. At that point the gate is enforced and worthless, which is a different failure from the prompt rule but lands in the same place.
The fix is not fewer gates. It is fewer classes of action behind a gate:
- Reversible and scoped — scale a deployment, restart a pod, add a log filter. No approval, full audit.
- Consequential but recoverable — apply a config change, merge to a release branch. Approval, and the reviewer sees a diff rather than a sentence.
- Hard to undo — delete persistent state, rotate credentials, touch a database. Approval, and a named person, every time.
The middle row is where the description matters. An approval request saying “modify service configuration” trains people to click; one showing the actual diff gives them something to disagree with. What decides whether a gate works is not that it fires, it is whether the person can tell a good request from a bad one in five seconds.
What to check in yours
- For every “never” in the prompt, find the code that makes it true. No code, no control.
- Scope the credentials to the smallest set the job needs. The cheapest enforcement available, and it holds even when everything above it is wrong — the least-privilege reading of agent configuration applies to infrastructure access most of all.
- Cap turns and wall-clock in the runner. An unbounded loop with production credentials is a slow drain that nobody gets paged for.
- Log from the tool layer, not from the agent. A log the agent writes is a log the agent can skip, and the run you most want a record of is the one that went strangely.
- Delete self-reported confidence thresholds. Replace them with a corroborating signal or with a human.
The architecture in these guides is sound and the components are the right ones. Just be exact about which layer each safety property lives in, because the diagram makes them look alike and only one of them is still there when the model has an unusual day.