Anti-Patterns

Workflow-Success vs Business-Validity Gap

Anti-pattern: a terminal success status from the agent or its workflow engine is read as proof the deliverable is business-correct, when it certifies only technical completion.

Problem

Technical completion and business validity are two different properties, and the exit signal only measures the first. A run that finishes without error has proven that the steps executed, not that the deliverable is right for its purpose: a generated article can be on-format, on-length, and on-time yet factually wrong, off-brand, or unpublishable. When the green status is trusted as a quality verdict, business-invalid output flows downstream unreviewed and is discovered only by a customer, an auditor, or a regulator, long after the run was marked done.

Solution

The remedy is to split the two signals and never collapse them. Keep the workflow's terminal status as a statement about execution only, and add an explicit business-validation step that scores the deliverable against the rules that decide whether it can ship: factual grounding, brand and policy conformance, completeness against the brief, and any domain checks the format alone cannot express. A run that exits cleanly enters a held state pending that validation rather than a published state. Surface the two outcomes separately on the dashboard, so a green execution status with a failing business check is visible as a problem rather than hidden behind a single tick.

When to use

  • A workflow or agent harness publishes a terminal success status when a run finishes.
  • A controller, dashboard, or operator decides what to ship based on that status.
  • The deliverable has business-correctness rules that a clean exit and a valid format do not capture.

Open the full interactive page

Diagram, neighbourhood map, code examples, related patterns and full provenance.

Related