> This page is for Workforce. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.merge.dev/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.merge.dev/_mcp/server. # Overview > What Merge is, which capabilities you can adopt on their own, what you configure, and how employees connect to tools and models. Start here before rolling AI access out to your workforce. Your employees are already using AI at work. Merge decides what that AI can reach: which models, which company systems, and under whose permissions. You configure it once from one dashboard. Employees keep the tools they have (Claude, ChatGPT, Cursor, Claude Code) and point them at Merge, which checks every request against your identity provider, scans it for sensitive data, and writes it to a log. Use it when the people using AI work for you. When the AI user is your customer, you want [Agent Handler](/merge-agent-handler/setup/building-an-agent). [Agent Handler for Employees](/merge-agent-handler/setup/agent-handler-for-employees) is the tool half of this on its own, no models, skills, or desktop client, and it bills per provisioned user rather than per seat. Merge pushes approved models, MCPs, and skills into the tools employees already run, so the sanctioned path is also the one that needs no setup. ## Pick the capabilities you need | Capability | What you govern | Start here if | | ------------------------------------------------------ | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | **AI Gateway** | Which models each team can use, how requests route, and what they cost | Model spend is the problem you have this quarter | | **[Connectors](/merge-workforce/connectors/overview)** | Which company systems an employee's AI can touch, and what data those calls carry | AI needs to reach Slack, Jira, Salesforce, or Drive, scoped per team | | **Skills and agents** | The procedures and MCP servers employee agents load, and a record of what they ran | Employees are running agents and you want them following your playbooks | All three read the same identity, the same Groups, and the same dashboard. Adding the second capability is a configuration change, not another rollout. Run AI Gateway and Connectors together and a single log covers both halves of a request: the model that answered, and the system it touched. ## What you configure | Surface | What it does | Start here | | --------------- | ----------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | **Identity** | Connects Okta, Azure AD, or any SCIM-compatible provider, so employees arrive and leave with your directory | [SCIM provisioning](/merge-workforce/provisioning/scim) | | **Tool access** | Assigns Tool Packs to Groups, with overrides for the people a Group does not fit. Thousands of maintained tools sit behind it | [Managing tool access](/merge-workforce/provisioning/groups) | | **Guardrails** | Reads tool call payloads against entity and regex rules, then flags or blocks on a match | [DLP rules](/merge-workforce/security/overview) | | **Models** | Sets the models each team can use and routes their traffic through AI Gateway | [AI Gateway](/merge-workforce/models/overview) | | **Skills** | Publishes your procedures so agents run them instead of inventing their own | [Publishing skills](/merge-workforce/skills/publishing-skills) | | **Devices** | Ships a light desktop client through your MDM to configure machines and enforce policy locally | [Workforce desktop client](/merge-workforce/devices/overview) | | **Logs** | Keeps tool call logs and the Audit Trail in the dashboard, and streams both to your SIEM | [Tool Call Logs](/merge-workforce/logs/tool-calls) | | **Insights** | Reads those logs and returns findings your admins can act on, from routing gaps to idle Connectors | [Insights](/merge-workforce/insights) | Configure only the rows for the capabilities you adopted. Most teams begin with identity plus either AI Gateway or tool access, then add the desktop client when they want device-level inventory and enforcement. ## How your employees connect Tools and models are separate connections. An employee can have one, the other, or both. ### To tools One MCP endpoint, one SSO sign-in. A consent screen lists the tools the employee's Group grants, and the client renews its own token after that. [Connecting tools over MCP](/merge-workforce/get-started) covers the setup: SCIM, Group mapping, and the endpoint itself. Ask for something outside that set and the call fails, then surfaces in your dashboard as an access request. Approve it, decline it, or widen the Group. ### To models Point the AI tool at AI Gateway instead of the model provider: the Gateway base URL, and a Gateway API key where the provider key used to go. In Claude Code that means `ANTHROPIC_BASE_URL` and `ANTHROPIC_AUTH_TOKEN`. Every harness has an equivalent, and [Coding agents and IDEs](/merge-gateway/coding-agents/overview) works through them one at a time. For direct API use, start with [Get started](/merge-workforce/models/overview). From there your [routing policy](/merge-workforce/models/routing) chooses the model and the team's [budget](/merge-workforce/models/budget) caps what it can spend. Doing that for one machine is a five-minute change. Doing it for everyone is a rollout, and there are two ways to run it: the desktop client, deployed through the MDM you already run, or letting employees set it up themselves. [Roll out models](/merge-workforce/rollout/models) compares them and says which AI clients each one reaches. ### Or let the desktop client do both The desktop client writes both connections on the employee's machine: MCP configuration for tools, and a Gateway base URL and a key minted for that employee for models. Skills reach the agent through the MCP server rather than the disk. The employee configures nothing. See [Workforce desktop client](/merge-workforce/devices/overview). ### Or have the employee run one command On machines you do not manage through an MDM, the [Workforce CLI](/merge-workforce/rollout/workforce-cli) does the model half from the terminal: the employee signs in through your identity provider and gets a credential scoped to that one machine. It configures nothing on the device and enforces nothing, so prefer the desktop client wherever you can deploy it. Either way, access is bound to identity. Deprovision someone in your identity provider and their tokens go with the account, so AI access ends when the rest of their access does. ## What it is not * **Not a customer-facing agent platform.** If the end user is your customer, read [Building an agent](/merge-agent-handler/setup/building-an-agent). * **Not an AI client.** Employees keep Claude, ChatGPT, Cursor, and Claude Code. Workforce governs what those clients can reach. ## Next steps #### [Connect tools over MCP](/merge-workforce/get-started) Set up SCIM, map Groups to tools, hand employees the MCP endpoint #### [Workforce desktop client](/merge-workforce/devices/overview) Deploy through your MDM, inventory the AI already installed, enforce policy on the device #### [Guardrails](/merge-workforce/security/overview) Catch sensitive data in a tool call before it reaches a third-party system #### [AI Gateway](/merge-workforce/models/overview) Set the models each team can use and see spend by team, tool, and model #### [Roll out to your fleet](/merge-workforce/rollout/overview) Get every employee routing through Gateway, by desktop client, MDM, or self-setup #### [Browse Connectors](/merge-workforce/connectors/browse) Search every Connector your employees' AI can reach, and the tools each one exposes