The pattern
Most agent prompts carry two kinds of instruction mixed together. Some describe taste: what a good headline sounds like, which layout suits a launch, when a joke lands. Others describe obligations: always review before assembling, never publish without approval, always use the brand’s capitalisation. The pattern is to split them. Obligations that must hold every time go into the code that runs the agent. Taste stays in the prompt, where the model can weigh it.
LangChain describes arriving at this rule while building its internal design agent, which turns Slack requests into videos, graphics and decks. In How We Built Our Design Agent (27 October 2026), the team writes that it first put the review order in the skill’s instructions, and that “the agent sometimes skipped a review to save time.” The fix was to enforce the sequence in the pipeline. Their summary of the rule: “The order that must always hold lives in code, and the judgment stays in the prompt.”
The same post reports that “the median request now costs about 50 cents in model spend, down from about $8 in mid-September.” LangChain does not attribute that drop to any single change, and the post describes other changes in the same period, including a migration to its Managed Deep Agents platform. Read it as evidence that a gated pipeline can run cheaply. The post gives no figure for the gates’ own effect on cost.
When to use it and when not
Use it when a step is non-negotiable and skipping it has a real cost:
Review and approval. Anything public-facing: social posts, client deliverables, newsletter sends. LangChain’s agent shows “an approval card before anything goes public”.
Measurable rules. Word counts, banned phrases, brand spelling, required links, file formats, image dimensions. LangChain notes that capitalisation “used to come up frequently in reviews, but an automated check now catches every instance.”
Order dependencies. Fact-check before drafting the summary; render the preview before the final; validate the data before the chart.
Skip it, or keep it light, when:
The rule is a matter of taste. “Make it punchy” cannot be checked by a function. Writing it as one produces brittle regex that blocks good work.
The task is exploratory. Fixed ordering over-prescribes open creative work. LangChain’s first harness shipped 115 reusable UI components, and “the agent would just repeat the same layouts and animations for each frame without much variety.”
The rule only patches an old model’s weakness. The team found that “rules designed to compensate for a model’s weaknesses become less useful as models improve” and removed most hard-coded rules after a stronger model arrived.
How it works (input → step → output)
Input: a request plus the context the agent needs (brief, brand defaults, attachments).
Steps:
The pipeline calls the agent for the creative stage. The prompt contains only judgment: goals, tone, examples, what good looks like.
The agent returns a draft as structured output (for example JSON with fields for text, links and hashtags) so code can inspect it.
Code runs the deterministic checks. Each check returns pass or a specific failure message.
On failure, the pipeline sends the exact failure messages back to the agent for a bounded number of retries. On repeated failure, it stops and reports.
On pass, the pipeline runs the review stage, a second model call or a separate reviewer prompt that judges the subjective quality.
The pipeline posts an approval request to a human with the draft, the check results and the review notes.
Only an explicit approval event unlocks the publish step. The agent has no way to trigger the publish step itself.
Output: a published asset with a log showing which checks ran, what the reviewer said and who approved it.
The key property is that steps 3, 6 and 7 are not tools the agent may choose to call. They are lines in the program that run regardless.
Components
A state machine or linear pipeline. States such as
drafting → checked → reviewed → awaiting_approval → published. Transitions happen only in code.Check functions. Small, pure functions:
max_words(text, 280),no_banned_terms(text, list),has_link(text),brand_case(text, "HackrLife"). Each returns a clear reason when it fails, because the agent fixes errors better when told exactly what broke.A reviewer prompt. Separate from the drafting prompt, focused on the judgment you cannot code. Our risk-tiered code review breakdown covers how to decide how much review a given change deserves.
An approval channel. A Slack button, a Telegram message with Approve/Reject, or a row in Airtable with a checkbox. The approval writes a record the pipeline checks before publishing.
A run log. Every check result, retry and approval, with timestamps. This is what you audit when something slips.
Minimal implementation
Plain pseudo-code; the same shape works in Python, TypeScript or n8n.
CHECKS = [
max_words(280),
banned_terms(["game-changer", "revolutionary"]),
brand_case({"HackrLife": r"(?i)hackrlife"}),
requires_link(),
]
def run(request):
draft = llm.draft(prompt=JUDGMENT_PROMPT, input=request)
for attempt in range(3):
failures = [c.reason for c in CHECKS if not c.passes(draft)]
if not failures:
break
draft = llm.revise(draft, feedback=failures)
else:
return notify("Failed checks after 3 tries", failures)
review = llm.review(prompt=REVIEW_PROMPT, draft=draft)
approval = request_human_approval(draft, review) # blocks
if approval.status != "approved":
return log("Rejected", approval.note)
publish(draft)
log("Published", draft, review, approval)In n8n, the same flow is: Webhook trigger → AI Agent node (drafting prompt) → Code node (checks, returns failures[]) → IF node (failures empty?) with a loop back to the agent capped at three → second AI node (reviewer) → Slack “Send and wait for response” node with approve/reject → IF approved → publish node (Buffer, beehiiv, WordPress). The publish node sits after the approval IF, so the agent has no path to reach it directly.
The important detail is that the agent never holds the publish credential. If the drafting model has a publish tool, it can skip your gates, however firmly the prompt says not to.
Failure modes and evals
Failure modes to watch:
Gate as a tool. You wire the check as a tool the agent “should” call. It works in testing and gets skipped under pressure. Fix: call checks from the pipeline, not from the model.
Vague check messages. “Failed validation” makes the agent guess. “Post is 341 words; limit is 280” gets fixed in one retry.
Infinite fix loops. Without a retry cap, a stubborn failure burns tokens. Cap at two or three and escalate.
Over-gating taste. A regex that bans every exclamation mark blocks legitimate copy. Keep gates to things you would reject 100% of the time.
Rubber-stamp approval. If you approve everything without reading, the gate is theatre. Show the check results and reviewer notes in the approval message so a glance is enough.
Stale workaround rules. Revisit gates when you change models; delete the ones that only existed to prop up the old one.
Evals:
Skip test. Feed 20 requests and confirm from the log that every run passed through checks, review and approval in order. The target is 20 out of 20; one skip means a path exists around the gate.
Check accuracy. Build ten known-bad drafts (too long, banned word, missing link) and ten known-good ones. Every bad one should fail with the right reason; every good one should pass.
Retry yield. Track what share of failed drafts pass after one retry. If it is low, your failure messages are too vague.
Cost per published asset. Total model spend divided by approved outputs, so retries and rejections count against you. Our read-back verification loop post pairs well here for checking actions before they run, and held-out test sets help when you start tuning the reviewer prompt.
Build-it-this-weekend exercise
Take one agent workflow you already run, such as drafting social posts, newsletter intros or client update emails.
Audit the prompt (20 minutes). Highlight every sentence containing “always”, “never”, “must” or “before”. Sort each into “measurable”, “order” or “taste”.
Write the checks (1 hour). Turn each measurable rule into a function that returns a specific failure reason. Start with three: length, banned terms, required link.
Move the order (1 hour). Rebuild the flow so checks, review and approval are pipeline steps. Delete those rules from the prompt; leave the taste guidance.
Add the approval gate (30 minutes). Slack or Telegram button. Remove the publish tool from the agent.
Run the skip test (30 minutes). Twenty requests, then read the log. Note how many drafts failed a check on the first try; that number is how often the old prompt-only version would have shipped a mistake.
By Sunday you should have a workflow where the agent still writes, but the program decides what it is allowed to ship.
Sources
LangChain, How We Built Our Design Agent, Amal Irgashev and Shreya Talegaonkar, 27 October 2026 (accessed 29 October 2026)
