Integrations: connecting workers to your business tools

What this is

An AI worker that cannot reach your tools can only talk. An integration is how a worker reads from and acts in a business system: your inbox, your calendar, your files, your chat, your CRM. This page explains how that works in Korps, which tools are connections today, and how to tell a real integration from a logo on a slide.

Who it helps

Anyone planning a workflow that touches real systems, and anyone who has been told "it integrates with everything" and wants to know what that means.

The one idea

In Korps, an application is a fact and the route to it is a choice. Every tool can be reached three ways:

1. Direct. Korps has its own registered connection to the app. You sign in once, the token is sealed in Korps's vault, and workers use the app's own interface. Korps never shows the token to a worker or a client.
2. Composio. A third-party platform that holds the sign-in relationship with the app and exposes the app's actions as tools. Optional; it uses your own Composio account.
3. MCP. Any server that speaks the Model Context Protocol, an open standard for connecting AI applications to tools and data. If a vendor or you run one, a worker can use it. See MCP explained.

Whichever route, the connection belongs to your organisation or to one person, every worker can use it unless you narrow it, and every call is written to Activity naming the system.

Korps connections today

These are the applications Korps's connector catalogue names, reachable by signing in once: Gmail, Google Calendar, Google Drive, Outlook, Microsoft Calendar, Microsoft Teams, OneDrive, SharePoint, Slack, GitHub, Notion, Linear, Salesforce, HubSpot, Dropbox, Jira, Asana and Stripe.

Other tools a worker can reach, through MCP, Composio or the browser rather than a Korps connection: Confluence, Trello, Zendesk, Intercom, Shopify, Airtable, Figma, Zoom and the like. Twilio is a metered messaging service on your own account, not a business app.

A note on honesty. A tool having an API, or a vendor publishing an MCP server, does not by itself mean Korps has a working integration with it. It means one of the three routes may be possible. Ask, or try it with a low-stakes assignment, before you build a playbook on it.

How access and approval work

• When you connect a tool, Korps lists what it offers and records each action as a tool a worker can be granted.
• A grant can say "requires approval". Then each use of that tool by that worker becomes a Needs You item before it runs. This is how sending email waits for you while reading it does not. See approvals.
• Some tools can send triggers back to Korps, for example "a new record was created", which lands in Activity and becomes a task for the worker you named.
• A connection can be removed at any time. Korps holds no password of yours; a direct connection holds a revocable token in the vault, and the Composio route holds the relationship on your Composio account.

Requirements and availability

• Available in Korps: the connector catalogue above, the three routes, per-worker grants with approval, triggers, browser sessions, and the Activity record.
• Composio and Browserbase are optional and are your own accounts. Korps says exactly what each needs when it is not configured.
• A connection needs the account you use for that tool. Korps cannot connect to a tool your organisation does not have.
• The free account is open now; the app that hosts workers opens at launch.

Limitations and approval points

• Start with read. Grant read access first, watch the worker for a while, then grant write or send with approval, then relax approval where it has earned it.
• The catalogue above is what the code names on the reviewed date. It changes; the product documentation is the authority.
• A tool reached through the browser is slower and more fragile than a connection, and can break when the vendor changes its pages.
• Connections respect the permissions of the account you sign in with. A worker cannot see more than you can.