Monarch vs Arcade for Enterprise AI Agents

Arcade helps developers build and control the tools an agent uses. Monarch helps enterprises make more of their existing business systems usable by agents.

Monarch is an AI agent integration platform for extending what your agents can do across the software you already run, including old and internally built applications. Your team should not have to build and repeatedly repair each missing application step from scratch.

Arcade provides the infrastructure around a tool: connect the user’s account, check access, and run the action. Developers can use existing tools or implement their own application logic.

Monarch’s core technology is its Product Graph, a maintained map of how the applications themselves work. It discovers the available actions, the records they need, and the steps that depend on them. Agents reuse that knowledge across different business workflows.

For example, a procurement agent may already have a tool to create a request but no way to check a supplier in an internal system. Arcade supplies infrastructure for implementing and controlling the tool. Monarch tackles the application knowledge and access needed to make that missing step work.

What each platform is for

Arcade custom tools, Contextual Access, Monarch Product Graph.

Arcade gives tool developers an authorisation and execution layer

Arcade's authorised tool-calling flow lets an application request access for a user, check whether authorisation has completed, and execute a tool under that user identity. It handles supported OAuth flows, API keys, and user tokens around access to external services.

Arcade also distinguishes server-level and tool-level authorisation. One controls access to the MCP server; the other supports a tool's access to a third-party API on the user's behalf.

Check who the caller is, which external account the tool uses, and what that account permits. Then establish the separate business approval for the requested change. Authorising access to a procurement application does not by itself approve a particular purchase.

Custom tools can contain substantial application knowledge

Arcade's catalogue is one starting point. Developers can also build their own MCP servers, implement tools, and declare their inputs. Its custom-tool authorisation guide shows how a tool declares required OAuth scopes and uses Arcade-managed authorisation.

A custom tool can check a supplier's status, validate an amount, or call an internal service before creating a record. That logic can be valuable work your team already owns.

If an action is missing, assess the implementation route. An engineer who understands the interface may be able to add a focused tool. Where the application is poorly documented, the work also includes finding the operation, learning its required state, and proving the result.

Evaluate Arcade's policy hooks as part of the design

Arcade's Contextual Access lets teams connect their own logic at tool listing, before execution, and after execution. Those hooks can control visibility, allow, or deny requests, change inputs, and filter outputs.

For example, a team could supply a pre-execution check that rejects a requisition request without the approval reference its policy requires. The team still needs to implement the rule, decide what makes an approval valid, and test the check against the target system.

The stage matters. An output filter runs after the tool executes. A consequential write needs its required checks before execution, plus a way to establish what happened afterwards.

Include that policy work in the comparison. Arcade offers a route to enforce customer-defined logic around tools; the value depends on the rules and application behaviour in the actual implementation.

Monarch starts with the application operations the job needs

Monarch's Product Graph discovers application behaviour available to the connected account, including public APIs, private web capabilities, and UI paths where available. It represents the operations discovery has captured and verified, alongside their requirements and dependencies.

That is useful when a person knows how to complete a step inside a portal but the agent has no reusable way to perform it. Discovery can establish the operation and what it needs before the workflow relies on it.

An application map helps connect that operation to the records and checks around it. Your people still define which supplier record is authoritative and who can approve a requisition. Application discovery does not make that purchasing decision.

Monarch pairs agent reasoning with deterministic code for repeatable steps. Test whether that combination reduces the work needed to understand the applications and run the complete workflow. A custom tool that already performs the same job should remain part of the comparison.

Use discovered operations across more than one workflow

Giving an agent a purchase-request tool is one useful step. The larger opportunity is to make the underlying purchasing and finance systems available for other work as well. Monarch maintains a reusable map of verified operations, then orchestrates agentic workflows across that coverage.

A requisition workflow and an invoice investigation can use the same supplier records and approval states, with different rules about what happens next. Established process patterns can shorten the design work, provided your team adapts them to its own controls and tests the result.

Arcade can remain part of a design that needs its tool authorisation and execution services. Compare the work needed to expose and maintain each operation, and define the interface between platforms. Neither a tool definition nor an application map removes the need to assign ownership of the full business process.

Follow a purchase request through to a verified requisition

Consider an illustrative employee equipment request. The agent reads the request ticket, checks the supplier in a procurement system, gathers the required approval, and creates a requisition in an internal application. It then records the requisition reference in the original ticket.

The difficult part may be a custom approval field or a supplier restriction visible only in an internal portal. Give both implementations the same rule, source records, and account permissions.

With Arcade, identify the tools that cover each step and the custom implementation required for the gap. Decide whether the approval check belongs in the tool, the surrounding workflow, or a policy hook, and test how those pieces work together.

With Monarch, demonstrate the required operation under the account the workflow will use. Check that the discovered route handles the relevant record state and that the business rule and approval point are included in the workflow.

Completion means the approved requisition exists with the intended details and the ticket points to it. It does not mean an order has been placed with the supplier or equipment has arrived.

Include a failed second write. If the requisition is created but the ticket update fails, the next attempt needs to find that requisition and finish the update without creating another one.

Also test a changed supplier status or revoked approval before execution. The system should return enough evidence for an operator to understand why the case stopped and what remains to be done.

Own-cloud deployment has several meanings

Arcade supports full-platform self-hosting and a separate hybrid model. Its Helm deployment runs the platform on a Kubernetes cluster the customer manages, including control of the upgrade cadence.

In the hybrid MCP server model, the tool server runs on customer-controlled infrastructure while Arcade's cloud Engine handles identity, routing, and governance. Requests reach that server and responses return to the Engine. Review that path when deciding what data the tool should return.

Arcade's Enterprise plan also lists SSO, role-based access control, audit logs, and private registry access. Those capabilities belong in the evaluation; own-cloud deployment and enterprise governance are available beyond Monarch.

Monarch offers hosted AWS deployment in the US and Australia, as well as customer-cloud deployment as an Enterprise add-on. Its security approach includes customer-controlled accounts, review of consequential writes, and audit evidence.

For either vendor, trace the actual deployment through model processing, tool execution, and retained data. Agree the location and handling of logs, credentials, and support access. A hosting region alone leaves parts of that picture unanswered.

Inspect the evidence behind a completed case

Arcade distinguishes administrative audit logs from tool execution history. Execution records include the tool, user, status, timing, and attempts; access to recorded inputs and outputs has additional restrictions.

For the requisition example, ask the reviewer to follow one case through those records and the target applications. They should be able to connect the approval, attempted action, resulting requisition, and any recovery work.

Apply the same test to Monarch. The useful evidence establishes the business result and explains incomplete work. A collection of successful tool calls can still leave the original request unresolved.

Compare the implementation your team will operate

Monarch saves verified, repeatable steps in code to reduce repeated agent reasoning. Its application map is maintained as the underlying operations change, with focused repair rather than an assumption that yesterday’s action still works. For the supplier check, change a required input and test whether the repaired workflow returns the correct record.

Use the same cases and completion standard. Include denied access, changed records, and partial failures, then record the operator effort needed to recover. That work will recur after the pilot, so give it an owner and a cost.

Price the workflow, including authorisation and upkeep

Arcade's pricing lists Free, Team, and custom Enterprise plans, with auth events and tool calls as usage categories. Enterprise pricing includes annual bundles and deployment choices. Get the terms for the architecture and volume you intend to run.

Monarch uses platform and per-action pricing. Compare quotes against the same workflow, including reads, writes, model use, deployment, and support. Add any customer engineering required to build tools or maintain application knowledge.

Track the cost of all attempts alongside completed cases and human intervention. Our guide to cost per completed workflow explains how to keep retries and recovery in the calculation.

Bring one cross-system job and the actions it needs to a Monarch pilot discussion. We'll work through the application knowledge, controls, and completed result the pilot should prove.