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.
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.
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 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.
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
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.