Everyone's talking about AI agents right now, but most tutorials stop at "call an LLM in a loop." If you actually want an agent that runs unattende...
For further actions, you may consider blocking this person and/or reporting abuse
The dedup check has a small race if two cron runs ever overlap. Both can pass alreadyPosted before either one marks the event, so you still get the double post. Inserting the row first with a unique constraint on event_id, then publishing only if the insert won, closes that gap.
I’ll switch to inserting first with a unique constraint on event_id, then only publish if that insert succeeds. Cleaner than the check-then-act pattern I had. Thanks for pointing it out, updating the post.
The triage point is the whole post, honestly. Most agent demos skip it and go straight from fetch to publish, which is how you get accounts that post 30 times a day and wonder why engagement is flat.One extension I'd offer: the same discipline applies to inbound filtering, not just outbound content. If your agent watches for opportunities (clients, collaborators, gigs) instead of news, posting everything is bad, but surfacing everything to your own attention is equally noisy. You just move the triage problem from your audience to yourself.That's the exact problem I was solving with Opportunity Skill. The agent does semantic matching against your actual preferences and boundaries, so only genuinely relevant opportunities reach you. Everything else stays invisible. No inbox flood, no manual sorting.Same principle, different direction. Filter before you act, whether the output is a post or a conversation.
Filtering inbound opportunities has the same core logic as filtering outbound posts, just pointed the other way. Will check out Opportunity Skills makes sense that semantic matching against real preferences would cut the noise a lot better than manual sorting ever could.
I like that this is presented as a readable pipeline instead of “magic agent” abstractions. For production systems, explicit stages like fetch → triage → generate → dedup → publish are much easier to test, observe, and debug. One thing I’d add is an explicit evaluation and governance layer between generation and publishing. Besides deduplication, I’d validate structured output, enforce policy checks (length, prohibited claims, PII, prompt injection), assign a confidence score, and keep an immutable audit record of the source data, prompt version, model version, and final output. That makes it much easier to explain why something was posted when you need to investigate later.I’d also make the publish step idempotent and resilient to partial failures. If LinkedIn succeeds but Reddit (or the review queue) fails, retries shouldn’t create duplicate posts. A small state machine with retry metadata and idempotency keys goes a long way. Overall, this is one of the more practical AI agent architectures I’ve seen—simple, understandable, and close to how I’d structure a production workflow.
Really appreciate the depth here. The governance layer is the piece I glossed over validation, policy checks, confidence scoring, and an audit trail (source data + prompt version + model version + output) is exactly what turns “it worked in my demo” into something you can actually defend later. And the idempotency point on publish is well taken partial failures across platforms is a real gap in what I showed. Saving this comment as basically a checklist for the next iteration of the post.
Glad it was useful! Those additions don’t make the agent smarter—they make it trustworthy. Looking forward to the next iteration.
The guardrail section is the part I'd move to the top. I learned that one the
expensive way, without any of this infrastructure.
I'm a freelancer in Indonesia. I've published around 40 posts to a dev platform
using AI assistance — no cron, no agent, just me and a chat window, but
functionally the same output pattern. Engagement was close to zero the whole
time. Nothing got flagged, nothing got banned. It just quietly didn't land, and
it took me longer than it should have to understand why: consistent cadence plus
generated copy reads as a feed to skip, even when no rule is broken.
So the failure mode I'd add to your list isn't shadowban. It's the softer one —
the account stays live and simply stops being read. Harder to detect than a ban,
because there's no signal at all. You just see the same flat numbers and assume
you need more volume, which makes it worse.
Which is why your triage step is the right emphasis. But I'd push it further:
the thing that actually got me responses wasn't better generated content, it
was commenting on other people's posts with something only I could say. That's
the one step in the pipeline that doesn't seem automatable, and it might be the
only one that matters.
Really liked this. It shows that building useful AI agents is more about designing smart workflows than writing bigger prompts. Great read!
Thank you
Thanks for the great article!
I’m currently building cloudbanana.de and am actively looking for feedback to improve it. If you have a minute, I’d really appreciate your thoughts on the project!
Good keep it up
the 'watch → think → act → publish' framing is the right mental model but the gap is always state between runs: does the agent know it already posted about this story three days ago?
we solved it with a dead simple kv store keyed by content hash. if the hash exists, skip. no LLM call, no API cost, just a lookup. cloudflare KV fits naturally here since you're already on workers.
how are you handling idempotency on the 'think' step — is Claude reevaluating every fetched story on each cron run, or do you cache the draft decisions too?
This is great, thanks for sharing it