Arcade.dev sits in the path of every action an agent takes, so the fair question is what happens when something breaks. If the runtime goes down, does every agent go with it? It helps to separate two different worries hiding inside that one question. The first is the everyday failure of the systems an agent acts on. The second is the availability and blast radius of the runtime itself. Arcade is built to absorb the first and to give you control over the second.
Most failures come from the remote systems your agents call
Let’s start with the failures that have nothing to do with whether Arcade is up.
When an agent calls a remote tool, it’s really calling a third-party API, and those fail in ordinary ways. A service times out, rate-limits you, returns a partial result, or a token expires mid-workflow. (Local tools an agent runs on its own aren’t in this path, so they don’t touch Arcade’s concern.) Left unhandled, these turn into stuck agents and half-finished actions. Arcade is built to keep them from cascading: it runs remote tool calls with parallelized execution and MCP server failover, and its tools are hardened so a failure comes back as a clean, classified result the agent can act on rather than a mystery.
When a tool call fails, Arcade’s Engine retries it automatically, a configurable number of times. Those retries are simple by design, a fixed number of attempts rather than anything clever. When those retries run out, Arcade returns the error along with additional context about what went wrong, so the agent and its framework can make an informed decision about what to do next instead of guessing. That decision, whether to try again, take a different path, or stop, belongs to the agent.
Arcade also gives the agent a clear read on each tool. Every tool carries metadata its developer defines, describing how the tool behaves, whether it only reads data or changes it, what kind of operation it performs, and what type of service it touches. That is what tells the agent whether repeating an action is safe, so a retry doesn’t double-charge a card or duplicate a record. Token expiry is handled at the runtime through managed refresh and rotation, and either way the agent gets a predictable, classified result instead of a hung workflow it has to reason its way out of.
A compromise is contained
A single point of failure is a security worry as much as an availability one. If everything funnels through one place, does one breach expose everything? Arcade’s design keeps the blast radius small. Credentials are encrypted and never exposed to the model, and every action is scoped to a single user’s permissions rather than a broad service account. So a bad prompt or a poisoned input cannot walk away with a master key, because there is no master key to take. Revocation is respected on the next action, and because every call is logged and attributable, a prompt injection attempt becomes a logged event instead of a breach. The worst case is bounded by what one user was allowed to do, not by what the whole system could do.
That is the practical difference between a runtime and a shared credential store: the thing that sits in the middle of every action is also the thing enforcing the limits on it.
You decide how available the runtime is
Availability is where “single point of failure” is usually aimed, and the answer depends on how you deploy. Arcade Cloud runs the managed service with parallelized execution and automatic failover, and publishes its uptime on a public status page. If you would rather not depend on anyone else’s cloud, you can self-host the runtime in your own private cloud, your preferred region, on-premises, or a fully air-gapped network. Self-hosted, Arcade runs inside the same infrastructure you already make resilient, under your own redundancy, monitoring, and recovery practices. Because tool execution is stateless, the runtime scales horizontally rather than concentrating load in one fragile node.
Arcade is built to absorb and contain top-level failures
Tool-level failures are expected, and Arcade is built to absorb them with retries, failover, and idempotency so they don’t cascade. A security compromise stays contained, because credentials are isolated and every action is scoped to one user. Runtime availability is your call: lean on Arcade Cloud’s failover and status page, or self-host inside infrastructure you already run for high availability.
