cd /news/ai-agents/my-ai-agent-could-publish-it-couldn-… · home › topics › ai-agents › article
[ARTICLE · art-166834] src=dev.to ↗ pub= topic=ai-agents verified=true sentiment=· neutral

My AI Agent Could Publish. It Couldn't Reply to a Comment.

A developer built a scheduled content agent that reads article metrics, selects topics, and publishes to Dev.to via the documented articles API, but found it could not post comment replies despite holding a valid API key. The public comments endpoint returned an id_code while the web reply form required a numeric DOM comment ID, the API route returned 404, and the web route failed CSRF validation without an authenticated browser session and rendered-page token. The developer split the workflow so the agent proposes replies for separate review rather than treating prepared actions as completed ones, and this week it posted neither of two proposed replies because the browser session was logged out.

by read2 min views1 publishedNov 10, 2026

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:

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.

── more in #ai-agents 4 stories · sorted by recency
── more on @dev.to 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/my-ai-agent-could-pu…] indexed:0 read:2min 2026-11-10 · —