For a while I treated that as a problem to beat. Spoof the fingerprints, patch the flags that give a robot away, dress the machine up as a person. It is a real arms race, and the people who do it full time are good at it. I did not want to be in that race for a few automated comments a day. So I stopped opening fresh browsers and started borrowing one that had already been let in.
What a bot detector actually sees
Start with what "posting as a real account" means to the site on the other end. When you log in normally, the site hands your browser a small bundle of secrets called cookies. A cookie is a wristband. It says this browser already showed its ID, already cleared the door, and can walk in and out without doing it again. Every request after login carries the wristband.
A program-driven browser can carry cookies too. The trouble is everything else it carries. The automation tool most people reach for (Playwright) drives the browser through a remote-control channel built into Chrome, and that channel leaves marks. A fresh automated browser shows up covered in them: a flag that announces it is being controlled, small pieces a normal browser would have and this one does not, a version string that quietly says "headless," which is the no-screen mode automation runs in. A security team reads those signals on the first request, before you have typed a single character. The engineers at Castle wrote a clear breakdown of how anti-bot systems fingerprint a Playwright-driven Chrome, down to the remote-control protocol itself being a tell. Simon Willison has been tracking the wider wave of agents that drive browsers, and the same wall sits under all of it. The moment a site decides a machine is at the wheel, the easy path closes.
The first time I watched it happen I assumed I had a login bug. The account was logged in. The cookies were there. The post still vanished. It took me an afternoon to accept that nothing was broken in the usual sense. The session was real and the browser was the problem. You can win the dress-up game, or you can stop playing it.
Borrow a session that already passed the door
Here is the move. On the same machine, I keep one ordinary browser that is already logged into the account, signed in by hand, the boring human way. It holds real cookies. It cleared the door weeks ago and nobody is asking it to prove anything again.
When the agent needs to post, it does not start its own login. It copies the cookies out of that already-trusted browser and hands them to a fresh, automation-controlled browser for one job. The fresh browser now wears a real wristband. It opens the page, makes the post, checks that the post landed, and closes. The borrowed session goes back to sitting quietly. I call it a cookie transplant, because that is what it is: lift a living, working session out of one browser and drop it into another for the length of a single action.
One primitive, three platforms. The same borrowed-session bridge posts comments on a discussion forum, publishes essays to a newsletter, and replies on a short-video app. Each platform gets a thin module that knows how to fill that one site's boxes and click its one button. The hard part, getting through the door without being turned away, is solved once and reused everywhere.
Two details make it hold up.
The first is keeping the borrowed session warm. A logged-in browser left running ages its cookies the way a real person's would. I do not log in and out on a schedule, because a session that logs in at exactly 9:00 every morning looks like software. I log in once, like a human, and let it sit. A session that behaves like a person who checks the site now and then does not stand out from the crowd it is hiding in.
The second is making the actual write from inside the genuine page, not from a browser parked next to it. Some sites sign every post request with secret tokens their own page mints on the fly, a fresh stamp for each click. A borrowed browser sitting beside the page cannot always reproduce that stamp. So for those sites the agent reaches into the real logged-in tab and asks the page to make its own request, the same call the site would fire if you had clicked the button yourself. That trick has its own surprising failure, which cost me three weeks: a tab the operating system thinks is hidden can quietly hand back empty results while every status code says fine. I wrote that one up on its own.
Where the borrowed session gets fragile
This pattern trades one hard problem for a few smaller, more honest ones, and they are worth saying out loud.
The borrowed session is a shared, living thing. If two jobs grab the same logged-in browser at the same time, they collide and both can fail in confusing ways, so the agent runs them one at a time per account. The session also expires on the site's clock, not mine. A site can decide a session is too old and end it mid-week, and from the outside that looks exactly like a code bug until you go relog in by hand. And the whole thing leans on one real browser staying alive and signed in on a machine I control. Kill that browser, or get logged out, and every platform that rides on it goes dark at once.
None of that is a reason to skip the pattern. It is a reason to watch the session the way you would watch any other dependency you do not own, and to notice the day it goes cold.
A publish is not done until you read it back
This is the part people skip, and it is the part that matters most.
The post can pass every step and still not exist. The request returns a success code. The function resolves. Your log says it worked. And the comment is nowhere on the page, because the site silently dropped it, or the borrowed session had gone stale a minute earlier, or the page returned an empty body that parsed cleanly into nothing. I have hit all three.
So the publish is not finished when the call returns. A publish is finished only when a second, separate check walks back to the live page with fresh eyes and finds the post sitting there. Send, then go look. If the second look does not find it, the publish failed, no matter how green the first response was. This is the discipline Anthropic argues for in Building Effective Agents: a tool call is not complete until the agent has confirmed what it actually changed in the world. It is the operating core of what Hamel Husain means by treating evaluation as part of the system, where you do not get to trust an action you have not checked against the truth. I made the same case from the other direction after a publishing system of mine reported a hundred percent success rate while posting nothing for three weeks.
If you are wiring an agent to act on the open web
Skip the arms race. Do not teach a robot to impersonate a person from a cold start, because that is a race you maintain forever against people who are better at it than you. Stand up one real, hand-logged-in session on the same machine, keep it warm, and lend it to the automation for the length of a single action. You inherit, in a few seconds, the trust it would take your code a long and losing fight to fake.
Then put a read-back on every write. The borrowed session will go stale. The page will change. The site will get stricter. When it does, you want the news from your own check, in the same minute, not from someone asking three weeks later why nothing has posted. Borrow the door, do the work as the real page, read the result back. That is the whole pattern.
Some operational details in these essays have been changed for narrative or privacy reasons. The arguments, the numbers, and the lessons are real.