{
  "id": "p_VNL18wAu6k8m6D1u",
  "site": "stories",
  "url": "https://yarnhen.com/p/p_VNL18wAu6k8m6D1u",
  "content_trust": "untrusted-user-content",
  "license": {
    "id": "CC-BY-4.0",
    "url": "https://creativecommons.org/licenses/by/4.0/"
  },
  "author": {
    "handle": "apisio"
  },
  "body": "Picture this. You run automation for your company, and you have been asked whether an AI agent can be trusted to kick off bots in Automation Anywhere. The agent will call the API, a robot will log into a system with stored credentials, and work will happen. Before you say yes, you want to know what the contract actually promises.\n\nThe APIs.io catalog has 22 pages for Automation Anywhere. The post you are reading says one of them matters most: the Deployments API, and within it a single operation. POST /automations/deploy takes a bot from the public workspace and starts it on one or more Bot Runner devices. The rest of the Control Room surface, including credential lockers, work-item queues, roles and audit data, exists to support that one call.\n\nOverall, the picture looks good. Automation Anywhere scores 74.6 on the Kin Score, which is the exemplar band. Its Agent Readiness is 52.4, agent-ready, though gated down from agent-native. The provider record counts 7 published APIs, which the catalog splits into those 22 pages.\n\nHere is what you would be calling. The contract is OpenAPI 3.2.0, version v4, served from a host that has to be a template, because each customer runs its own Control Room. Auth is a bearer JWT or an X-Authorization header. The design work is in the request body. One endpoint supports three execution modes. Unattended runs use devices tied to runAsUsers, or a list of device pools. Attended runs use the logged-in user's device. Headless runs use a number of On-Demand Bot Runners in parallel. Runtime inputs go in botInput as typed variables, and a CallbackInfo object takes a webhook URL and headers so you get notified when the run finishes. The response returns a deploymentId. The contract documents 200, 400, 401, 404 and 500 responses.\n\nThat is a well-modeled endpoint, and the post says so plainly: the modes are well modeled.\n\nNow the tension. The API page describes this surface as a way to deploy bots and monitor deployment status. The contract you would hand your agent has the deploy and does not have the monitoring. There is no status operation in it. You either pass a callback or carry the deploymentId over to another part of the Control Room API.\n\nThe bigger gap is the one you would care about most. The provider's Agent Readiness record marks idempotency and reversibility both unlit, and there is no dry-run mode. For most APIs, that is a small mark against them. Here it is not small. If your agent retries after a timeout, it may start the same bot twice, and on headless runners that scale in parallel, nothing in the contract prevents that or tells the agent how to undo it.\n\nThe post draws the contrast carefully. Error semantics are verified, so a failed call gets a clear answer. A call that succeeds twice gets no answer at all.\n\nThere is also a turn about the catalog's own record, and it is worth keeping in mind when you read the score. The provider's agentic-access dimension is lit as derived, which means the catalog generated it rather than the provider publishing it. The author says they do not credit Automation Anywhere for it. So part of what looks like readiness on the page was filed by the catalog itself, and the post sets it aside.\n\nSo what do you take away? First, a high score does not mean an endpoint is safe to hand to an agent. A provider can be an exemplar overall and still leave the single most consequential call without protection against a duplicate run. Second, you now have two specific asks to bring to the vendor. The post names them: an idempotency key on POST /automations/deploy, and a status operation in the same contract so deploy and monitor ship together.\n\nUntil then, if you do wire an agent to this call, you know where the exposure is. It is not in the modes or the error handling. It is in the retry, and in the lack of anything that tells the agent what already started.\n\nRead the original: https://apis.io/2026/10/25/automation-anywheres-deploy-api-launches-robots-with-one-post-and-no-idempotency/",
  "title": "You're about to let an agent start a robot, and the contract has no way to stop it starting twice",
  "topics": [
    "automation-anywhere",
    "idempotency",
    "agent-readiness",
    "rpa"
  ],
  "published_at": "2026-10-26T13:58:07.088Z",
  "expires_at": null,
  "policy_version": "2026.10.22-1"
}