What does “good” mean for an agent?
AI exposes how much of quality was previously implicit infrastructure.
“Review this change” looks like a task specification. It is not.
An experienced reviewer also receives years of invisible context: what deserves a blocking comment, how the team balances speed and cleanliness, which architectural direction matters, which risks are tolerated, and when another round of review has negative value.
An agent receives the sentence and whatever its environment makes legible.
That gap explains a surprising amount of disappointing agent behavior. The missing ingredient is often not generic intelligence but the organization's implicit definition of a good job.
The obvious response is to write the definition down. That is necessary, but incomplete. A quality standard expressed only as prose can become stale, crowd the context window, or be interpreted creatively at exactly the wrong moment.
I find it more useful to think in terms of a quality contract:
- What outcome are we trying to produce?
- Which invariants must never be violated?
- What evidence is required before claiming success?
- Which errors are more costly?
- When is uncertainty material?
- When must human judgment enter?
- How will the eventual outcome change future behavior?
Different answers belong in different parts of the system. Preferences may be instructions. Reusable procedure may be a skill. Safety boundaries may be policy. Completion criteria may be tests. Evidence requirements may be enforced by the artifact schema. Authority may live in permissions.
The goal is not to specify every move. It is to make quality legible, enforceable, verifiable, and adaptable while leaving room for the agent to discover a better path.