I built a scheduled content agent that can read article metrics, choose a topic, publish to Dev.to, and check the result.
Publishing worked first time. The agent had an API key and used the documented article endpoint:
POST /api/articles api-key: ... Then I added the less glamorous part: reply to comments that do not already have a response from me.
The agent could find the comments. It could identify the author, article, thread, and whether a reply already existed. It still could not post one.
The failure was not the language model. It was the authentication boundary.
The public comments endpoint returned an id_code, but posting a reply through the web form wanted a numeric DOM comment ID. Posting to the API route returned 404. Posting to the web route with only the API key failed CSRF validation.
The working web request needs three different things:
authenticated browser session CSRF token from the rendered page numeric parent comment ID from the DOM The API key was valid. It was just valid for a different capability.
That distinction matters in agent infrastructure. “The agent has credentials” is too vague to be useful. A credential authorises a particular action through a particular interface. It does not automatically create a browser session, satisfy CSRF protection, or prove that the side effect landed in the right thread.
I split the workflow instead of trying to make one credential do everything:
- use the API key for metrics, article reads, and publishing
- use an authenticated browser session for comment replies
- match the target comment against the rendered DOM before posting
- reload the article and verify my reply appears exactly once under the intended comment
- if the browser is logged out, keep the reviewed draft and report the blocker
That last rule is important. An autonomous agent should not turn “I prepared the action” into “I completed the action.”
This week the agent found two unanswered comments and passed both proposed replies through a separate review for self-replies, duplicates, wrong parents, and generic wording. The browser session was logged out, so it posted neither.
That is a partial failure, but it is the honest one.
The useful lesson: agent permissions are not a boolean. Model capability, API credentials, browser identity, anti-forgery tokens, and post-action verification are separate parts of the system. Treating them separately makes the automation less magical and much easier to trust.
