DEV Community: Wuki

I Let an AI Agent Post on X for 60 Days — These 5 Guardrails Saved My Reputation

Wuki — Wed, 14 Oct 2026 13:05:24 +0000

P.S. If you want more AI agent workflows like this one delivered to your inbox every week, join builders getting them free: https://wuki.beehiiv.com

Last month I saw a line in a thread about autonomous agents that hasn't left my head: an agent's plan isn't permission. It sounds clever until you're the one who handed your X account password to a piece of software and told it to "go grow the audience."

I did exactly that for 60 days. It worked — and it nearly cost me my reputation twice. Here's what happened, and the five guardrails I'd never ship an agent without again.

What 60 days of an AI posting for me looked like

Week one was a honeymoon. The agent drafted threads, replied to mentions, and freed up hours I used to spend doomscrolling for material.

Week two is where it got interesting. The agent posted a "hot take" about a topic it knew nothing about, phrased with the confidence of someone who'd been in the industry for a decade. It had opinions. It had wrong opinions. I deleted the draft before anyone could screenshot it.

Week three: it replied to a customer complaint thread with a generic apology that managed to sound both robotic and smug. One single tweet, and I spent an afternoon firefighting DMs from people who assumed a human had written it.

The agent didn't need a better prompt. It needed fences.

Guardrail #1: approval mode for anything with a stake

The first fence was simple: drafts with stakes don't post themselves. Links, pricing claims, product announcements, anything opinionated — it hits a review queue and waits for a human thumb. "Engaging" filler like replies to friendly mentions can post on its own, within a per-day cap.

The rule of thumb: the more irreversible the post, the more human review it needs. An unprompted retweet is reversible-ish. A claim about your product's performance is forever.

Guardrail #2: sentiment and topic filters on replies

Autonomous replies are where agents cause the most damage with the least visibility. My fix was a three-layer filter on every outbound reply:

Sentiment check — the agent can be helpful, never combative
Topic blocklist — politics, religion, and a few other subjects are hard "no"
Escalation rule — if a reply thread gets heated, the agent stops and tags a human

Since the filters went in, the agent's reply quality went from "occasionally embarrassing" to "consistently boring." That's the goal. Boring is safe.

Guardrail #3: a fact-check pass on every number

AI agents hallucinate in ways that look confident. The most dangerous thing a brand account can do is state a false number with the weight of a quarterly report. So every numeric claim in a draft gets flagged for verification before it's allowed near the post queue. No verified source, no number.

Guardrail #4: hard rate limits

A bug in code crashes a server. A bug in an agent spams thousands of followers. I cap posts per day, replies per hour, and mentions per thread — enforced in code, not by a "please behave" instruction in the prompt. Prompts are suggestions. Limits are contracts.

Guardrail #5: the kill switch and the audit log

Last line of defense: one command halts every outbound action, and every action the agent takes is logged so I can review exactly what it did and when. When something feels off, I don't guess — I read the log.

Why this matters if you're building (or buying) agents

The reason most people give up on AI agents isn't that agents are dumb. It's that they're unpredictable — and unpredictability is unacceptable for anything that wears your name in public.

That's why, when I built xbeast.io to automate X posting, the approval queue and the hard rate limits weren't an afterthought — they were the first features I wrote. Autonomy is a feature; blast-radius control is the product.

If you're running an agent on any public channel today, take fifteen minutes and answer this: What's the worst thing this agent could post, and what stops it? If you can't answer both halves, your agent has more power than you have control.

I built my guardrails the hard way. Hopefully you get to copy them instead.

What's the first guardrail you'd put on an agent before letting it post publicly? Drop it in the comments — I'm building a fence checklist from this thread.

Failed Video Encodes Should Cost You $0 — What a Year of Serverless Transcoding Taught Me

Wuki — Sun, 11 Oct 2026 13:02:17 +0000

P.S. If you want more serverless and media-pipeline cost breakdowns like this one delivered to your inbox every week, join builders getting them free: https://wuki.beehiiv.com

Every video pipeline has a line item nobody wants to talk about: the encodes that never finished.

Not the slow ones. Not the expensive ones. The ones that died at 97% because a source file was corrupt, a codec flag was wrong, or the GPU instance got preempted mid-transcode. You delete the output, fix the input, and re-run it. And then you look at the bill — and the failed run is on it.

I ran my own video processing pipeline for a year, and failed encodes quietly cost me more than any single success. Here's what I learned about how video billing actually works, where the waste hides, and why the industry's default pricing model is backwards.

The four taxes on every video encode

1. You pay for failures (the big one)

Most hosted encoding services and cloud transcoding tools bill you by wall-clock compute time — the seconds your job held a worker, regardless of outcome. A 40-minute 4K transcode that crashes at minute 38 bills you for 40 minutes of GPU time. You output nothing, you pay full price.

It doesn't sound bad per-job. But failures cluster. One bad batch of source files — a camera that recorded with a broken timestamp, a batch of renders with a zero-byte tail — can burn through a week's encoding budget in an afternoon. I once had 14 of 20 jobs fail because a metadata field changed in a vendor export. Fourteen full-price bills for zero deliverables.

2. You pay for idle workers

When you self-host FFmpeg, your cost isn't the seconds FFmpeg runs — it's the seconds your server exists. Provision a box for your nightly batch and it sits idle 20 hours a day, still being billed. Autoscaling helps, but cold starts mean you keep a warm instance around "just in case," and "just in case" is a monthly line item.

3. You pay for spikes twice

Your median workload is 10 encodes a day. Your spike is 400 when a launch video goes viral. If you sized for the spike, you overpay 95% of the time. If you sized for the median, the spike queues for hours and your launch video ships late. Either way, you ate a cost that had nothing to do with the actual work done.

4. You pay minimums and round-ups

Per-second billing sounds precise until you read the fine print: minimum billable units, rounding up to the nearest minute, "burst" multipliers. Thirty 4-second clip renders shouldn't bill like thirty 60-second jobs — but they frequently do.

What I changed: bill on outcomes, not attempts

The fix that actually moved my numbers was switching my billing mental model from attempt time to successful output. Here's the key insight: charging for failed work is a tax on your own users' bugs, and it punishes the exact people you want to keep — the ones hammering your API with real workloads.

When I built my own encoding service (ffmpego.com — a serverless FFmpeg API I run as a side project), I made failed encodes free. The meter only runs on jobs that finish successfully. If your input is corrupt, your flags are wrong, or the job dies at 99%, you pay nothing. The economics work because the IDs that actually complete represent real work — and successful jobs are the ones users happily pay for.

Pricing by compute-second on success only also removed every other tax above:

No idle workers — the platform scales to zero between requests; your cost is literally zero when nothing is running
No spike premium — 400 jobs in a minute costs exactly 400 jobs' worth of compute, no warm-box overhead
No minimums — a 4-second clip bill is 4 seconds × $0.0036, not a rounded-up minute
Hard monthly caps — a spending ceiling you set, so a runaway loop can't silently empty your account at 3am

Why this matters more than the per-second rate

Frameworks and pricing tools obsess over the per-minute rate, and honestly, most of them are within a rounding error of each other. The real spread in your bill comes from what you're charged for that never should have been charged: failures, idle time, spike buffers, and rounding.

When I tracked my pipeline costs over a year, the "pure compute" part was about 60% of what I actually paid. The other 40% was taxes — and almost all of it was avoidable once the billing model aligned with outcomes.

Try the exercise yourself

Pull last month's encoding bill. Separate it into:

Jobs that produced the file you wanted
Jobs that failed, retried, or sat in a queue
Idle/provisioned time you paid for but didn't use

If line 2 or 3 is anything but zero, your pricing model is working against you. You don't need cheaper per-second rates — you need to stop paying for work that never happened.

What does your last encoding bill look like — what percentage went to work you didn't actually get? I'd love to compare notes in the comments.