Every social platform rewards the same thing, and it isn't a secret: showing up regularly. The hard part isn't writing. It's deciding what to say t...
For further actions, you may consider blocking this person and/or reporting abuse
Really interesting failure sequence, Eugeniya. I think all three cases share the same deeper problem: the evidence was real, but the meaning assigned to it was stronger than the evidence justified. 🔍
The Zapier posts are a great example. The agent correctly observed that those records existed, but “you published this to your audience” and “you promised a follow-up” were additional claims that required provenance the post history did not contain.
So I really like the rule:
observation != interpretation != fact
I would almost want every historical item the agent consumes to carry context such as source, audience, purpose and confidence before it is allowed to reason from it.
The cross-platform case is the same problem from the opposite direction. The agent did not hallucinate anything, it simply had an incomplete evidence boundary and no way to know that the missing context existed elsewhere.
And the slop checker is probably my favorite failure here. It passed because it was measuring properties inside the draft, while the thing your colleague noticed depended on context outside the draft: reuse, recent history and the cumulative effect of individually reasonable patterns.
So the checker was not necessarily wrong. The property being asked of it was larger than its observation surface.
That makes the final “stop at the draft” boundary especially important. The model can propose, the checker can catch a subset of problems, but neither gets publishing authority simply because both are green.
I think the architecture starts looking like:
history -> provenance/context -> inference -> human confirmation -> draft -> local checks -> publish decision
Really good example of why agent memory becomes much more useful when it remembers where a fact came from and what it actually proves, not just the fact itself. 🧠🔐
"The meaning assigned to it was stronger than the evidence justified" — that's the sentence I wish I'd opened the article with. All three were three stories to me; you've written them as one, and you're right.
The provenance idea is where it gets practically interesting. Attaching source, audience, purpose, confidence to each historical item is exactly what would have stopped the Zapier misread at the root — a QA run tagged audience: none, purpose: test never gets read as a promise. The catch is that provenance has to be captured at write time, by the thing that created the record, and most systems don't. My test posts went into the feed with no marker because nothing along the way had a reason to add one. So the architecture is right, but it pushes the cost upstream: the feed has to start carrying context it currently throws away, and retrofitting that onto records that already exist is the hard part.
Your read on the slop checker is more generous than mine and also more correct. "The property being asked of it was larger than its observation surface" is the honest version of what I called a failure. It answered the question it could see. I was holding it responsible for a question that lived outside the file, which isn't the checker's fault, it's a category error on my part about what that tool is for.
And the pipeline you drew is the one I backed into without naming: history → provenance → inference → human confirmation → draft → local checks → publish. The one thing I'd underline is that the human-confirmation step and the publish-decision step are different gates doing different jobs — one asks "is the premise real," the other asks "should this go out," and collapsing them is how "both checks are green" quietly becomes publishing authority. Neither green light is the same as a decision.
I really like that distinction.
I think separating those two human gates makes the pipeline much clearer:
human confirmation = is the premise actually true?
publish decision = even if it is true, should we act on it?
Those are different claims and they need different evidence.
A factual premise can be completely valid and still lead to a bad publishing decision because the timing, audience, tone or context is wrong.
And the reverse is also important: a draft can look perfectly publishable at the surface while resting on a premise that was never actually established.
That makes me think the pipeline is really preserving two different kinds of uncertainty:
epistemic uncertainty about whether the underlying claim is true and decision uncertainty about whether publishing is the right action If those collapse into one green/red state, the system can accidentally turn “the premise seems supported” into “publish this”.
Your point about provenance being captured at write time also feels important here. Retrofitting context later is always weaker because by then the original audience, purpose and creation conditions may already be gone.
So maybe the stronger architecture is:
record creation -> provenance captured -> historical retrieval -> inference -> premise confirmation -> draft -> local checks -> publish decision
That makes both provenance and human review part of the evidence path instead of treating them as cleanup steps at the end. 🔍🧠
The epistemic vs decision split is the part I hadn't named cleanly, and it's the right cut. "The premise is true" and "acting on it is correct" really are different claims with different evidence, and you're right that the danger is collapsing them into one state. That's exactly how "seems supported" quietly becomes "publish" — one green light standing in for two separate questions it was never qualified to answer.
The provenance-at-write-time point is the one I keep coming back to, because your pipeline makes it structural rather than polite. Once creation conditions are gone, you're reconstructing audience and purpose from whatever survived, which is guesswork wearing a confident face. Capturing it at write time is more expensive up front and far cheaper than being wrong later.
The one honest snag is cost. Provenance only works if something records it at creation, and most systems don't, because at write time nobody feels the absence yet. The missing field doesn't hurt until the day you need it. So the architecture is right, and the hard part isn't the diagram, it's getting people to pay for context they can't yet see they'll need.
This is a fascinating breakdown, especially the part about structural "slop". You're totally right that vocabulary checkers are fighting yesterday's war. The real AI tells are the predictable rhythms: the dramatic single-sentence paragraph, the neat paradoxes, and those perfectly balanced three-item lists.
Since you built the logic with Claude, I'm curious about how you are handling the prompt for the actual draft phase now. Have you tried passing negative constraints to specifically ban those structural clichés (e.g., "Do not use three-item lists" or "Avoid dramatic one-line paragraphs"), or does Claude end up ignoring them when trying to mimic your voice? Would love to know if negative prompting worked for your use case!
Great question, and the honest answer is that negative constraints in the draft prompt didn't carry the load for me, so I stopped leaning on them. "Don't use three-item lists" works right up until the model is also trying to match my voice and hit a length — then the structural habit slips back in, because it's not reaching for a list on purpose, it's falling into a rhythm, and a rule it isn't actively thinking about doesn't fire.
So I moved the anti-slop work out of the draft prompt and into a separate pass that runs after. Generate first, then check against the tells as its own step, rather than asking the model to avoid them while it's busy doing three other things. The catch — which is basically the whole point of that article — is that a checker only sees what's inside the text, so the structural pass still misses the cross-post repetition and the "four defensible choices add up to a machine" problem. Those I still catch by reading.
Short version: negative prompting helped a little, a post-draft check helped more, and neither one replaces a human read. Have you had better luck getting the constraints to actually stick in-prompt?
That makes perfect sense. I've had similar struggles where negative constraints work for a sentence or two, and then the model completely forgets them by paragraph two! Treating the drafting and the editing as two distinct steps instead of one mega-prompt is a brilliant workaround. Thanks for sharing the behind-the-scenes on this, it’s definitely given me some ideas for my own workflows!
The Zapier validation posts are a clean example of a failure mode I keep hitting: retrieval returned the right rows and the wrong claim. The agent didn't hallucinate the text — it hallucinated the speech act. A hanging-thread detector that only looks at topic continuity will keep inventing promises. I'd gate that suggestion behind an explicit marker (you literally wrote "coming soon" / "I'll follow up") before it counts as unfinished business.
"It hallucinated the speech act, not the text" is a sharper name than anything in my post — I was calling it "inference stated as fact," but yours is more precise, because the words really were mine. Retrieval was correct. What it invented was that those words were a promise to anyone.
And gating on an explicit marker is the better fix. My rule makes the agent ask instead of assert, which is a softer failure but still a failure — it'll still surface a non-promise and make me say no every time. Requiring "coming soon" / "I'll follow up" before a thread counts as unfinished raises the bar at the source instead of catching it at the confirmation. I'm adding that — topic continuity alone clearly isn't enough signal to call something a promise.
The part that lands is that the promise was real to the reader even though you never made it. Your posting history is a record other parties, human or agent, will mine for commitments, and the writer's own memory is the worst place to look them up. The agent didn't hallucinate the promise; it inferred one from a pattern you'd stopped noticing. That's the uncomfortable thing about giving agents read access to your own record: they end up being more consistent readers of you than you are.
"More consistent readers of you than you are" is the line I'll be thinking about. You're right that the promise was real to the reader — the agent didn't misread the data, it read it more literally than the audience ever would, and both of those are truer than my own memory of what I posted.
The uncomfortable part cuts both ways, though. That same consistency is exactly why the read access is useful — it catches the thread I genuinely dropped, the follow-up I actually owe. The failure isn't that it reads me too well. It's that it can't tell the difference between "you committed to this" and "this pattern looks like a commitment," and only one of those is mine to answer for. Which is why the rule ended up being "show me what you saw and let me say what it was," not "decide what I meant." The agent gets to be the consistent reader. It doesn't get to be the author of my intent.
Choosing the topic is the part that stalls me too, the actual sentences usually show up once I know which small moment I am telling.