Arcade.dev vs. klanex

Arcade.dev is an authorization and governance runtime for agents: it lets an agent act as a real user with per-user OAuth scoping, and ships a large MCP tool catalog with enterprise deployment and compliance. klanex is an execution reliability layer for any API: it makes each tool call survive hallucinated payloads, rate limits, outages, and crashes. Arcade decides whether the agent is allowed and as whom; klanex makes the call itself succeed.

Capability	Arcade.dev	klanex
Per-user identity — agent acts as a real user with scoped OAuth	Yes — this is the core product	Out of scope — klanex isn't an identity layer
Enterprise deployment (cloud, on-prem, air-gapped, hybrid)	Yes	Hosted service — scales to zero on GCP
SSO / RBAC / published SLAs / compliance program	Yes — built for regulated enterprises	Lighter — dashboard SSO + API keys, not an enterprise IAM
Large pre-built MCP tool catalog	Yes — thousands of tools	Not a catalog — point it at any API you already have
Keeps raw credentials out of the model's environment	Yes — just-in-time auth	Yes — KMS-sealed, decrypt-in-worker, redacted everywhere
Exposes tools over MCP	Yes — an MCP runtime	Yes — Streamable HTTP `/mcp` endpoint
Async, durable execution that survives the agent process crashing	No — calls resolve in-request	Yes — `execution_id` in ~15 ms; state persisted, queue redelivers
Automatic retries with exponential backoff + per-host circuit breakers	Reduces retry cost — no durable retry engine	Yes — queue-driven backoff (10s→600s), breakers, DLQ after 15 tries
Hard JSON Schema gate that returns a machine-readable fix	Tool quality / evals	Yes — `422` + an `llm_hint` the model self-corrects from
Exactly-once idempotency (a retry can't double-execute)	Do it yourself	Built in — `idempotency_key`
Durable signed webhooks + dead-letter queue	No	Yes — persisted delivery log, retried until the budget is spent
Byte-exact replay after an outage — no LLM round-trip	No	Yes
Per-call human approval before a destructive action	Policy / authorization	Yes — `requires_approval` pauses for approve/reject (Slack, dashboard, API)

Capability

Arcade.dev

klanex

Per-user identity — agent acts as a real user with scoped OAuth

Yes — this is the core product

Out of scope — klanex isn't an identity layer

Enterprise deployment (cloud, on-prem, air-gapped, hybrid)

Yes

Hosted service — scales to zero on GCP

SSO / RBAC / published SLAs / compliance program

Yes — built for regulated enterprises

Lighter — dashboard SSO + API keys, not an enterprise IAM

Large pre-built MCP tool catalog

Yes — thousands of tools

Not a catalog — point it at any API you already have

Keeps raw credentials out of the model's environment

Yes — just-in-time auth

Yes — KMS-sealed, decrypt-in-worker, redacted everywhere

Exposes tools over MCP

Yes — an MCP runtime

Yes — Streamable HTTP /mcp endpoint

Async, durable execution that survives the agent process crashing

No — calls resolve in-request

Yes — execution_id in ~15 ms; state persisted, queue redelivers

Automatic retries with exponential backoff + per-host circuit breakers

Reduces retry cost — no durable retry engine

Yes — queue-driven backoff (10s→600s), breakers, DLQ after 15 tries

Hard JSON Schema gate that returns a machine-readable fix

Tool quality / evals

Yes — 422 + an llm_hint the model self-corrects from

Exactly-once idempotency (a retry can't double-execute)

Do it yourself

Built in — idempotency_key

Durable signed webhooks + dead-letter queue

Yes — persisted delivery log, retried until the budget is spent

Byte-exact replay after an outage — no LLM round-trip

Yes

Per-call human approval before a destructive action

Policy / authorization

Yes — requires_approval pauses for approve/reject (Slack, dashboard, API)

Two different layers of the agent stack

Arcade's center of gravity is authorization and governance: an agent acting as a specific user, with the right OAuth scopes, inside an enterprise's identity and compliance boundary. If your hard problem is "which user is this agent acting as, what is it allowed to touch, and can I prove it to an auditor" — especially in a regulated, multi-user, self-hosted setting — that's what Arcade is built for, and it's genuinely strong there.

klanex's center of gravity is per-call execution reliability. Once a call is authorized, someone still has to make sure it survives a hallucinated field, a 429, a 30-second timeout while the model is thinking, a pod recycle mid-flight, and a retry that must not fire twice. klanex owns that: durable async execution, backoff, per-host circuit breakers, idempotency, a dead-letter queue, and byte-exact replay.

What an execution engine does that an authorization runtime doesn't

Durability. Submit the intent, get an execution_id in milliseconds; the retries and breakers live on a queue, independent of whether your agent process is still alive.
A schema gate with a self-correction contract. Better tools and evals lower the odds of a bad payload; a hard JSON Schema gate stops the bad call from leaving and hands the model an llm_hint to fix itself.
Exactly-once and recovery. An idempotency_key so a retry can't double-execute, durable signed webhooks with a DLQ, and one-call replay after an outage.

Where Arcade is honestly ahead

klanex is not an identity or authorization platform. It doesn't do per-user OAuth scoping, on-prem or air-gapped deployment, or an enterprise SSO/RBAC and compliance program. If those are your requirements, Arcade is built for them and klanex isn't trying to be.

They can sit in the same pipeline

Let your authorization layer decide who the agent is and what it may do. Route the calls that touch money, external systems, or flaky APIs through klanex for the execution guarantees. It's a single HTTP call — or an MCP tool — so it drops in without rewriting your agent.

One call, and the execution is guaranteed

klanex takes the authorized intent and owns everything after: the schema gate, the retries, the breakers, the idempotency, and the signed webhook.

agent → klanex → target API

$ curl -s https://api.klanexai.com/v1/executions -H "X-API-Key: klx_…" -d '{
    "target":  { "url": "https://api.stripe.com/v1/refunds", "headers": { … } },
    "payload": agent_json,
    "payload_schema": { "type": "object", "required": ["charge_id", "amount"] },
    "idempotency_key": "refund-ch_9f2k", "requires_approval": true }'

{"execution_id": "exe_4d0c85a6", "status": "PENDING_APPROVAL"}   # waits for a human, then executes reliably

Two different layers of the agent stack

What an execution engine does that an authorization runtime doesn't

Where Arcade is honestly ahead

They can sit in the same pipeline

One call, and the execution is guaranteed

Authorize with your stack. Execute with klanex.