Use cases

Building an agent, context layer for employees, or local development. A comparison so you know which setup guide to read.

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.