For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
Logo
Resources
Log inGet a demo
Get startedConnectorsAPI reference
Get startedConnectorsAPI reference
    • Overview
    • How it works
    • Quickstart
    • Use cases
  • Setup
    • Building an agent
    • Context layer for employees
    • Local development
  • Build
  • Secure
    • Security Gateway
    • Standard Entity Rules
    • Custom Regex Rules
    • Violations and alerts
    • Rule Tester
  • Observe
    • Tool Call Logs
    • API Request Logs
    • Audit Trail
    • Webhooks
    • Playground
  • Administer
    • Team and roles
    • Single sign-on
    • SCIM provisioning
    • Multi-factor authentication
    • Access Keys
    • Application Credentials
    • Billing and usage
  • Resources
    • Troubleshooting
    • FAQ

Get started

  • Overview
  • Introduction
  • Unified API
  • Linked Account
  • Merge Link
  • Use cases

Implementation

  • Sandboxes
  • SDKs
  • API access
  • Syncing data
  • Writing data
  • Data minimization
  • Supplemental data
  • Errors
  • Integration metadata

API reference

  • ATS
  • HRIS
  • Accounting
  • Ticketing
  • CRM
  • File Storage
  • Knowledge Base
  • Chat

Resources

  • Help Center
  • Merge.dev
  • Changelog
© Merge 2026Terms of usePrivacy policy
UnifiedAgent HandlerGateway
UnifiedAgent HandlerGateway
Resources
Log inGet a demo
On this page
  • At a glance
  • Building an agent
  • Context layer for employees
  • Local development
  • Choosing

Use cases

Building an agent, context layer for employees, or local development. A comparison so you know which setup guide to read.
Was this page helpful?
Previous

Quickstart

Next

Building an agent

At a glance

Agent Handler runs three ways - same product surface, different end user and auth model. Most teams pick one; some run two in parallel.

Building an agentContext layer for employeesLocal development
Who’s the end user?User of your productYour employee, in their own AI assistants and toolsYou, a self-serve developer
Agent Handler authYour API keyOAuth via your IdP (SSO)OAuth via merge login
Third-party authThrough Link, embedded in your productThrough Magic Link, returned to the employee’s AI assistantThrough Magic Link, returned to your agent
Where does the MCP URL live?Your backend (kept private)The user’s MCP client configYour MCP client config
Tool set scoped byThe Tool Pack in your MCP URLSet of tools mapped to the user and their IdP GroupTools selected by the user during merge login
Setup guideBuilding an agentContext layer for employeesLocal development

Building an agent

Your product has an agent, and the people using it connect their own Salesforce, Slack, GitHub. The end user can be a customer’s user (B2B SaaS) or one of your own employees on an internal product. Either way, you never touch their credentials directly - Agent Handler holds them, scoped to one Registered User per person.

Pick this when:

  • You’re shipping an agent feature inside your own product, B2B or internal.
  • You need credential isolation per user (one user’s Salesforce token can’t be used to read another’s data).
  • You want to render Link inside your own UI so the auth flow feels native.

Read Building an agent.

Context layer for employees

Your employees plug an MCP URL into their own AI surface - Claude, ChatGPT, Cursor, Claude Code, any MCP-compatible client - or into agents they build for their own work. Auth runs through your IdP (Okta, Azure AD, Google Workspace, whichever). SCIM provisions users into Agent Handler. IdP Groups map to Tool Packs.

Pick this when:

  • You want employees to reach company tools from inside their personal AI assistant, coding tool, or an agent they’re building themselves.
  • Your security team requires SSO + SCIM and wants role-based access tied to IdP Groups.
  • You don’t want to embed Link or maintain a credential-management surface in your own product.

Read Context layer for employees.

Local development

Self-serve setup for an individual developer. You’re not shipping a product to customers, and you’re not standing up employee access for an org - you just want tools in Cursor or Claude Desktop on your own machine. Use the Merge CLI or the simplified MCP URL with your own login.

Pick this when:

  • You’re prototyping an agent for yourself, not building a product around it.
  • You’re testing a Connector or Tool Pack before wiring it into either of the setups above.
  • You want a personal agent for personal accounts (your GitHub, your Gmail) without involving an organization.

Read Local development.

Choosing

The two-question version: who is the end user, and who controls their identity?

  • User of your product, identity in your app’s database → Building an agent.
  • Your employee, identity in your IdP, agent lives in their AI assistant or coding tool → Context layer for employees.
  • Just you, prototyping for yourself, not shipping a product or governing an org → Local development.

If you’re not sure, start with Local development to feel out the surface, then move to Building an agent or the Context layer for employees once you know which shape your product is.