The Agent Never Becomes Trustworthy. The System Becomes Legible.

Mallory Haigh, Head of Platform Education and Advocacy at Platform Engineering Consulting, published a piece this month with three questions she says an organization must be able to answer before it lets agents run: “Who is that dastardly agent? What was it prompted to do? By whose definition of done was this considered acceptable?”

Most engineering organizations can answer the first one. Some can answer the second. Almost none can answer the third, because the definition of done was never written anywhere. It lived in the heads of four or five people who reviewed everything important.

Her framing of the shift is the sentence worth arguing with: “The engineer was the institution of trust, and their digital signature at the bottom of the review was the proxy for an entire cultural value system.” That signature was never a statement about the code. It was a statement that a person carrying the organization’s unwritten standards had looked at the change and did not object.

Before going further, two disclosures about the source. The article is tagged sponsored on platformengineering.org and links repeatedly to the author’s own product. And it contains no measured data at all: no benchmarks, no survey, no incident counts. The “45-minute manual review” it describes is an illustration. Read it as a well-constructed argument, not as evidence.

The signature was doing invisible work

When a senior engineer approved a pull request, several checks ran that appeared nowhere in the diff. Does this pattern match how we handle retries in this codebase? Is this the kind of change that needs the data team told? Did the last person who touched this module leave a landmine we agreed not to step on? Would legal care that this logs a customer email?

None of that was in a linter. Some of it was in a wiki page nobody read. Most of it was in the reviewer.

That arrangement worked because the volume of changes was bounded by human throughput and because the reviewers stayed. Both conditions are now failing. Volume is no longer bounded, and the reviewers who carried the standards are being asked to review output they did not author, at a rate that leaves no room for the pattern-matching that made their approval meaningful in the first place.

We have argued before that tacit knowledge is governance debt and that team standards belong in executable form. Haigh adds something neither of those arguments settled: who is supposed to do the writing, and in what order.

Accountability moves from social to architectural

The old model was social. You trusted the reviewer because you knew them, because they had been burned by the same outage you had, because their name on the approval carried professional cost if it went wrong. Accountability flowed through a relationship.

An agent has no relationship to trade on. It has no career to protect, no memory of the 2 a.m. page, no standing in a team it wants to keep. Whatever accountability exists has to be built into the surrounding structure: the prompt that scoped the work, the policy that constrained it, the evaluation that judged it, the trace that recorded all three. Haigh’s phrasing is that agents need “the implicit to become explicit, in their language, at scale.”

That last clause is the load-bearing one. Plenty of organizations have written standards documents. Very few have written them in a form an agent can consume at the moment of decision, and fewer still have a way to test whether the agent honored them. A Confluence page describing your error-handling philosophy is explicit to humans and invisible to everything else.

The dig has an owner, and it is platform engineering

This is the part the industry keeps leaving unassigned. Everyone agrees the tacit standards need to be extracted. Almost nobody says whose job it is, so it becomes a shared aspiration and therefore nobody’s deliverable.

Haigh puts it on the platform team, and the argument holds. Platform engineering already owns the paved road. It already decides what the default pipeline enforces, which base images are blessed, what a service needs to pass before it can take production traffic. Every one of those is a codified standard that used to be tribal knowledge. Extracting the definition of done is the same category of work, applied to a harder domain.

Her description of that work is unusually honest: platform teams that understand this “are doing something that looks like therapy and acts like archaeology: surfacing the assumptions the organization never knew it was carrying, making them legible, and codifying them into something versionable and traceable.”

The therapy part is real. Ask two senior engineers what “done” means for a database migration and you will often get two answers, both confident, both partially undocumented, and a short argument neither of them expected to have. That argument is the deliverable. It was always there, resolved privately every time by whoever happened to review.

Versionable and traceable is the harder half. A standard that lives in a document drifts silently. A standard that lives in a policy file, with a commit history and a test suite, drifts loudly. The second one can be pointed at during an incident review.

Evaluation infrastructure comes first, not alongside

Haigh’s sequencing rule is the operational claim in the piece, and it is the one most teams are currently violating: “the evaluation infrastructure must exist before you grant the next level of autonomy.”

Not concurrently. Not as a fast-follow after the pilot goes well. Before.

The failure mode this prevents is familiar to anyone who has watched a capability outrun its instrumentation. A team lets agents open pull requests, sees good results for three weeks, expands the mandate to a second repository, then to migrations, then to production configuration. At no point did anyone build a way to measure whether the output met the standard, because at every point the previous stage had looked fine. The moment something breaks, the organization discovers it has no baseline, no regression suite for agent behavior, and no way to tell whether this was an anomaly or the fourth instance of a pattern.

The rule is a ratchet. Each level of autonomy is unlocked by the existence of a way to judge the level below it. That inverts how most pilots are run today, where evaluation is the thing you build after the value is proven.

The article also offers a four-level ladder for self-placement: executor, validator, orchestrator, constraint-setter. The progression is a useful mirror, and it comes from the author’s own commercial product, so treat it as a vocabulary rather than a maturity assessment you should be scored against. What it does well is force a specific question. If your engineers are still executing and validating individual changes, granting orchestration-level autonomy to agents means the humans skipped a rung too.

Do this now

Pick the single most consequential review your team performs. Deployment approval, schema change, anything touching customer data. Get the two or three people who actually perform it into a room for 45 minutes and ask one question: what makes you reject this?

Write down every answer. You will get rules that are already documented, rules that are documented and wrong, and rules that have never been written anywhere and that everyone in the room nonetheless agrees on. That third category is the excavation. It is also the reason your agents cannot be trusted yet, and it will not be produced by any tool you buy.

Then check the sequencing before you expand anything. For every autonomy grant currently in flight, ask whether an evaluation exists that would catch the failure you are worried about. If the answer is no, the grant is premature regardless of how well the pilot went.

The agent is never going to earn a reputation. The system around it can become inspectable, and that is the only thing that was ever really being trusted.

---

This analysis synthesizes Platforms are sitting on buried knowledge. Your agents are forcing you to dig it up (platformengineering.org, July 2026).

Victorino Group helps platform teams extract tacit review standards into versioned, testable policy before autonomy is granted. Let’s talk.