System Manual

Integrations

The two ways agents act on your systems: the MCP connector registry for API-backed tools, and Reach — the approval-gated browser tool — for everything without an API.

The MCP gateway

Agents act through your existing systems via an MCP gateway: a registry of integration tools that the gateway exposes to agents, executes with per-org credentials, and can run in parallel. Each connector ships a set of named tools (for example, the Stripe connector exposes stripe_get_customer, stripe_get_invoice, stripe_list_charges, and more). Credentials are resolved per organization, so an agent acting for one org can never reach another's systems.

The connector catalogue

Connectors ship for a broad set of business systems, grouped by category:

ERPSAP, NetSuite, Microsoft Dynamics Business Central, Odoo
Accounting & paymentsQuickBooks, Xero, Stripe
CRM & commerceSalesforce, HubSpot, Shopify
HR & payrollWorkday, BambooHR, ADP
Productivity & documentsNotion, SharePoint, AWS S3, DocuSign, Gmail
Support & ITSMZendesk, Freshdesk
Project managementJira, ClickUp, Monday
Messaging & automationSlack, Microsoft Teams, WhatsApp, Make
Note:These 27 connectors are the API-backed tools an agent calls directly. Anything not on this list — or any system without an API at all — is reached through the browser tool below.

Reach — the browser tool

For systems with no API, agents use Reach, an approval-gated browser tool. Reach drives a real browser session inside a scope and treats the browser as a first-class, governed surface — every action is risk-classified, logged, and (where risky) held for human approval.

Scope — the allow-list

A Reach session runs inside a ScopeConfig that bounds what the agent may touch:

allowed_urlsURL patterns (glob or prefix) the agent may visit
allowed_domainsDomains the agent may operate on
read_only_modeWhen true, only observe and navigate — never fill or submit
dry_runPlan-then-approve — the agent plans every action before executing any
auto_saveFor systems that persist on change (Notion, Salesforce, React ERPs): fills are treated as submit-level risk and approved BEFORE the keystroke
blur_savesFor systems that persist on blur: a navigate following a fill also requires approval

The risk taxonomy & approval gating

Every proposed action is classified into one of five risk levels. Low-risk steps run automatically; risky ones pause the session in an awaiting_approval state with a before-screenshot for a human to approve or reject.

observeRead the page — auto
navigateMove to an allowed URL — auto (unless blur_saves and the previous action was a fill)
fillType into a field — requires approval when auto_save or blur_saves is set (the approval happens before the keystroke)
submitSubmit a form / click a primary action — requires human approval
destructiveDelete or irreversible action — always requires human approval, with a reason
Important:Reach enforces its scope at the browser layer: an attempt to act outside the allowed URLs or domains raises a scope violation and is refused, regardless of trust level. In dry_run mode every action — even an observe — requires approval, for full plan-before-execute control.

Every action is written to the session's action log: the risk level, who approved it, before/after screenshots, and success or error. A session ends as completed, failed, terminated, or — if the process restarted mid-session — interrupted, signalling the user to retry.

Worked example: paying an invoice in a legacy portal

Example · A supplier portal with no API

An agent must mark an invoice paid in a vendor portal that has no API. A Reach session opens with a scope allowing only that portal's domain, with auto_save: false. The agent observes the dashboard (auto), navigates to the invoice (auto), and fills the payment reference (auto, since the form has a Save button). When it prepares to click Submit — "About to click Submit on Invoice #4471 for $47,230" — the session pauses with a before-screenshot. A human approves; the action executes and the after-screenshot and approver are logged. Had the agent tried to navigate off the portal's domain, the scope check would have refused it outright.

◳ Screenshot

A Reach approval card: the session task, the scope (allowed domain), the pending action with its risk badge ('submit'), a before-screenshot of the page, the human-readable description ('Click Submit on Invoice #4471 for $47,230'), and Approve / Reject buttons.