Many automation checks only prove that the expected thing exists: the build produced files, the service answered, or the report was written. That is necessary, but it leaves a blind spot. Safe agent work also needs negative checks: proof that the run did not leave behind an unsafe, stale, or unintended state.

A negative check asks the agent to verify absence. It turns “the task is done” into “the task is done, and the common bad leftovers are not present.”

Why absence matters

Agents are good at following the visible success path. They can create the requested artifact and still miss a risky side effect: a draft marked public too early, a temporary file committed by accident, a debug flag left enabled, or an outdated generated index that still points at old content.

Negative checks catch those problems before they become operational debt. They are especially useful when the final artifact is public, scheduled, or reused by another automation step.

Useful negative checks include:

  • No secret-shaped content: generated output does not include credentials, tokens, private identifiers, or raw logs.
  • No stale generated files: indexes, manifests, feeds, or maps were regenerated when source content changed.
  • No unintended surface area: only the expected routes, files, or configuration sections changed.
  • No debug leftovers: temporary flags, verbose tracing, scratch files, and draft markers are absent.
  • No silent partial success: skipped steps, failed probes, and warnings are reported instead of hidden.

Add them near the end of the runbook

Negative checks work best after the main action and before deployment, publishing, or handoff. They should be concrete enough for an agent to execute without guessing.

Instead of saying “make sure nothing bad happened,” name the forbidden states:

Before reporting success, verify that no generated output contains secrets or private identifiers, no draft-only content is marked public, no temporary debug files are included, and no required index remains stale. If any forbidden state is present, stop and report the blocker instead of publishing.

Keep the list short

A negative-check list should cover the common failure modes for that workflow, not every theoretical risk. Three to seven checks are usually enough. If the list grows longer, split it into reusable categories such as privacy, generated artifacts, deployment surface, and cleanup.

The goal is not paranoia. The goal is to make the absence of known hazards part of the definition of done.

Rule of thumb: a readiness gate should prove both that the desired artifact exists and that the most likely unsafe leftovers do not.