Pre-Flight: The Checks That Run Before an Agent Publishes

The instinct is to solve output problems with better prompting. It works about seventy percent of the time, which is a catastrophic reliability figure for anything that publishes under a real name. The remaining thirty percent is what pre-flight is for.

Pre-flight runs after generation, after critique, before the publish call. It is ordinary code with no model in the path, so it behaves the same way every time, which is the entire point.

The nine

1. Banned phrases. String match against the voice profile ban list. Zero tolerance, instant block.
2. Placeholder detection. [INSERT, TODO, XX, Lorem, {{, your company here. This check has saved us twice and both would have been humiliating.
3. Unresolved template variables. Anything matching {{\w+}} or ${...} that survived rendering.
4. Claim-to-evidence linkage. Every sentence containing a number must reference an evidence ID from the brief. Numbers with no provenance are the highest-risk content in any draft.
5. Link validation. HEAD request every URL. A 404 in a published post is a small, permanent embarrassment.
6. Duplication window. Similarity check against everything published in the last 90 days. Above threshold, block and surface the near-match.
7. PII scan. Emails, phone numbers, and anything shaped like a customer identifier. Regex plus a named-entity pass against your CRM.
8. Length and format. Channel-specific limits enforced before the API rejects them, so failures surface in review rather than at 6am.
9. Attribution completeness. Every borrowed statistic has a linked source. Missing source is a block, not a warning.

Ordering matters more than it looks

Run the cheap deterministic checks first. Banned phrases, placeholders, and template variables cost microseconds; link validation costs network round trips; the similarity check costs an embedding call. There is no reason to pay for embeddings on a draft containing the string TODO.

tier 1 (free, instant): banned, placeholder, template, format
tier 2 (local compute): PII regex, claim-evidence linkage
tier 3 (network/cost): link HEAD checks, duplication similarity

fail fast at the first tier that blocks

What pre-flight cannot do

It cannot tell you the post is boring, wrong-headed, or badly timed. Those are judgement calls, and they belong to the critic model and the human reviewer respectively. Pre-flight has exactly one job: ensure nothing mechanically defective reaches an audience.

Conflating the two is a common design error. Teams put "is this interesting?" into the pre-flight layer, it returns a probabilistic answer, and now the deterministic gate is no longer deterministic. Keep the layers separate: judgement upstream, mechanics at the door.

Instrument the checks themselves

Log every pass and block by check name. Over a few months the distribution tells you where the generation stage is genuinely weak. If the claim-evidence check blocks 15% of drafts, that is not a guardrail success story, it is a research stage failing to attach evidence. Guardrails should get quieter over time. If yours are not, they are papering over an upstream defect.

Related: evals or it did not ship and autonomy levels.

Every check in our gate, with the reasoning behind each one, is listed at my site↗ (opens in a new tab). The enforcement layer is built and maintained at TechTide AI↗ (opens in a new tab). A gate nobody can override is not a gate, it is a wall.