System Manual
Integrations
The two ways agents act on your systems: the MCP connector registry for tools with an API, and Reach, the browser tool with approval gates, for systems without one.
The MCP gateway
Agents act on your existing systems through an MCP gateway. The gateway holds a registry of integration tools, runs them with each org's own credentials, and can run several in parallel. Each connector has a set of named tools. The Stripe connector, for example, has stripe_get_customer, stripe_get_invoice and stripe_list_charges. Credentials are looked up per organization, so an agent acting for one org cannot reach another's systems.
The connector catalogue
The connectors, by category:
| ERP | SAP, NetSuite, Microsoft Dynamics Business Central, Odoo |
| Accounting & payments | QuickBooks, Xero, Stripe |
| CRM & commerce | Salesforce, HubSpot, Shopify |
| HR & payroll | Workday, BambooHR, ADP |
| Productivity & documents | Notion, SharePoint, AWS S3, DocuSign, Gmail |
| Support & ITSM | Zendesk, Freshdesk |
| Project management | Jira, ClickUp, Monday |
| Messaging & automation | Slack, Microsoft Teams, WhatsApp, Make |
Reach: the browser tool
For systems with no API, agents use Reach. Reach drives a real browser session inside a scope. Every action is given a risk level and logged, and risky ones are held for a person to approve.
Scope: the allow-list
A Reach session runs inside a ScopeConfig that bounds what the agent may touch:
| allowed_urls | URL patterns (glob or prefix) the agent may visit |
| allowed_domains | Domains the agent may operate on |
| read_only_mode | When true, the agent may only observe and navigate. It never fills or submits |
| dry_run | Plan, then approve: the agent plans every action before it executes any |
| auto_save | For systems that persist on change (Notion, Salesforce, React ERPs): fills are treated as submit-level risk and approved BEFORE the keystroke |
| blur_saves | For systems that persist on blur: a navigate following a fill also requires approval |
Risk levels and approval
Every proposed action is given one of five risk levels. Low-risk steps run automatically. Risky ones pause the session in an awaiting_approval state, with a screenshot taken before the action, until a person approves or rejects.
| observe | Read the page. Automatic |
| navigate | Move to an allowed URL. Automatic, unless blur_saves is set and the previous action was a fill |
| fill | Type into a field. Needs approval when auto_save or blur_saves is set, and the approval comes before the keystroke |
| submit | Submit a form or click a primary action. Always needs approval |
| destructive | Delete, or anything that cannot be undone. Always needs approval |
dry_run mode every action, even an observe, needs approval.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 or terminated. If the process restarted mid-session it ends as interrupted, which tells 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, the session pauses with a screenshot and the message "About to click Submit on Invoice #4471 for $47,230". A person approves, the action runs, and the after-screenshot and the approver are logged. Had the agent tried to leave the portal's domain, the scope check would have refused it.