I let an AI agent run the social media for my own product.
The first thing I handed over was "post from our own account."
Honestly, that part isn't that scary.
The words are ours, and if it flops, we're the only ones embarrassed.
What I wanted next was the step after that: "like / reply / follow other people's posts."
The thing everyone calls react.
Engagement, basically — could I hand that to the agent too?
And the moment I started designing it, it hit me.
This has a different kind of scary than posting.
Don't put posting and reacting in the same box
Posting is planting your own flowers in your own garden.
React is walking up and knocking on other people's doors.
It looks like the same "operate a social account," but when it goes wrong, the direction flips.
A bad post comes back at you.
A bad react flies out at someone else.
Accidentally like a politically on-fire post and it instantly becomes your brand making a statement.
So the first decision was this.
Do not "add react as a feature" to the existing posting command.
Split them.
The command, the agent, the decision gates — stand them up as separate lineages.
Mix react's requirements into the posting gate and the strictness you need when touching other people bleeds — diluted — into your own outbound side.
Go the other way and the looseness of your own outbound leaks into operations that touch other people.
I don't want a leak in either direction, so I built a wall.
What you must not mix isn't the feature — it's the risk boundary.
The problem where one "OK" clears everything
When you let an agent do something irreversible, the scariest part is the granularity of approval.
A human "OK" is looser than you'd ever think.
You reply "yeah, looks good" once and the agent hears "so I can do all of it, right?"
If likes fly out to people you never meant, there's no looking at it.
So I split approval into two stages.
Stage one is approving the plan.
Who are you going to react to, and with what kind of react — approval of the design.
Stage two is approving the execution.
This person, this post, this exact reply text — approval of one concrete action.
And the important part: I decided the stage-two OK only applies to a single action, uniquely pinned down by "target + action type + body text."
Bulk approval is banned.
And "a reply came back" does not count as approval.
That's a lesson I've watched hurt before — a reply arriving is not the same as the content saying yes.
Even a "no" is still "a reply came back," so a sloppy implementation lets it through.
Only an explicit yes counts as approval.
Machine-filtering that the target is "real" and "not a landmine"
Before replying, I made vetting the target a required step.
Leave this to human gut feeling and the agent will happily march into a minefield.
Two methods.
One is a mechanical exclusion list.
Politics, religion, discrimination, health, minors, obituaries, people in active litigation, sensitive attributes, suspected impersonation, bots, anything unrelated to us.
Match even one of these and it's an instant, no-questions reject.
On top of that I required "clearly related to us, translation, or multilingual — one of those."
So "not suspicious" isn't enough; you have to stack all the way up to "actually relevant" before it's allowed to react.
The other is verifying the target's identity.
If you're going to reply, read the target's handle, display name, pinned tweet, and parent thread, and confirm they're not an impersonation or something sensitive — first.
Confirming our own account is correct is a given (running from the wrong account is a tragedy), but this time I made it read whether the other side is real, too.
Like checking, before you shake someone's hand, that the name and face they're presenting actually match.
The trap of "it's undoable, so it's light"
Likes and follows can be undone later.
So you slip into thinking they're "light operations."
But that's the trap: the instant you press it, a notification fires at the target, and a trace lands in the public log.
Undo it and the fact that you "did it once" doesn't disappear.
There's a specific dread to leaving behind evidence that you were quietly digging through someone's posts in the middle of the night.
So for like and follow too — even if the same weight of gate as reply is too much — at minimum I made "who am I" confirmation and an idempotency guarantee mandatory.
The idempotency part is plain, but it works.
Right before executing, leave a marker saying "I'm about to do this."
After executing, read your own like count back off the screen and check it's exactly +1.
If it's +2, or unchanged, stop right there.
It's to prevent the plain, worst-case accident of "the operation succeeded but crashed before recording it, and the restart pressed it twice."
The constraint of grabbing selectors by "reading only"
The last piece of the build was having the agent locate the on-screen buttons (like, the reply input field, and so on).
Here I added one constraint.
During the survey phase, no clicking and no typing, none.
Allow only the screen-reading tools, and seal away the pressing tools.
The reason is simple: if a "let me find where the button is" turns into actually pressing it in the momentum of exploration, that's already an irreversible react.
I went to scout the place and somehow opened the door and shook a hand — no thanks.
So during the scouting, keep the hands tied behind the back.
As a result, the locations around like and reply came out read-only.
Follow was the only one I couldn't grab — you have to open someone else's profile for that — so I punted it this time and honestly wrote down "not yet collected."
Leave this vague as "eh, later" and the next person to touch it (future me) melts five minutes, so writing down that a thing isn't there is the kindest move.
What I actually did today was "design and skeleton, that's it"
Let me be honest: in this session I never once fired a like or a reply at another person.
What I did was the design doc, a template that by default only shoots blanks (dry-run), and the button locations grabbed read-only.
Actually pulling the trigger for real is for another session, after another explicit approval.
When you let an agent do outward-facing operations, the idea that helped most was this.
Draw the line not at "is it undoable" but at "does it fly at someone else."
One like is scarier than a post.
Drop that fear into the design and you land on: two-stage approval, mechanical exclusion, verifying the target's identity, idempotent reconciliation, and "keep the hands tied during the scouting."
After that, I actually started running it.
So far, it's working without any particular trouble.
The funny thing is that nothing going wrong is not proof the design worked.
The number of times stage-two approval stopped something, the number of targets the exclusion filter rejected, the accidents that never happened — you can't count them.
Even so, shifting where I draw the line, from "is it undoable" to "does it fly at someone else," was not a mistake.
Top comments (0)