Agent harnesses for safe-level run triage
I started building agent harnesses for operational triage before it was fashionable, and for an unglamorous reason: I was tired of being the human who gathered the same context, in the same order, during every incident. The gathering is mechanical. The judgment is where I add value. So the obvious question was whether I could hand the mechanical part to an agent. Safely. And keep the judgment for myself.
"Safely" is the entire essay. An agent loose on production is a liability; an agent in a well-built harness is leverage. The difference is the harness, and after enough iterations I settled on a shape I still use.
What a harness actually is
A harness is the scaffolding around the model that decides what it can see, what it can do, and where it must stop. The model is the engine; the harness is the chassis, the brakes, and the seatbelt. Most people building with agents obsess over the engine and skip the chassis, which is exactly backwards for anything that touches a real system.
Mine is built on a few non-negotiables:
Read-only by default, for the whole triage phase. The agent can query metrics, read logs, inspect state, pull a runbook. Every operation that observes and none that changes. During diagnosis there is simply no code path by which the agent can mutate production. Not "it's instructed not to." It can't. The write capability isn't in the harness at that stage.
Scoped, least-privilege access. The agent gets exactly the read scope its task needs and nothing wider. Credentials are narrow. The tool surface is small and specific. Not "run any command" but "get the status of this, read the health of that." A tight tool surface is a small blast radius, and the tool surface is the whole risk.
A hard gate before any action. When triage produces a recommended remediation, that's where the agent stops and a human takes over. The agent proposes; the person disposes. Not because the diagnosis is usually wrong. It's usually right. But because the cost of a wrong action on production is catastrophic and asymmetric, and "usually right" is a terrifying property for an irreversible operation.
The pattern: propose, don't perform
The load-bearing idea is separating the thing that reasons from the thing that acts. The agent reasons freely across a bounded, read-only view of the system and produces a structured output: here's what I see, here's the likely cause ranked, here's what I'd check next, here's the remediation I'd recommend and how risky it is. That output is enormously valuable. It collapses twenty minutes of frantic context-gathering into a paragraph. And it changes nothing on its own.
A human reads it, understands the why, and executes the part that touches production. The agent made the human faster and better-informed; it did not remove the human from the decisions that can't be undone. That's the safe level: full autonomy on observation, zero autonomy on mutation, a clean handoff in between.
Why I keep it deliberately un-flashy
Every few months someone demos the fully-autonomous version. Detect, diagnose, remediate, no human. It's a great demo and a bad system, because it optimizes for removing the person when the actual goal is resolving the incident correctly. A harness that makes a good engineer twice as fast, while keeping them on every irreversible action, resolves incidents better than an autonomous agent that occasionally makes a confident, catastrophic mistake at 3am.
So my harnesses have stayed conservative on purpose. Read-only triage, scoped access, human on the trigger, everything logged so trust is earned across a hundred incidents before autonomy is ever widened. And even then, one careful notch at a time. It's less impressive in a demo. It's the version I'd actually run against something that matters. And it's the version I've been running, and refining, for a while now.