Connect your agents to the systems you already use.
Native integrations, MCP servers, and your own APIs. Agents search and act in connected systems — you decide which action is open to whom, and which one asks for approval.
No credit card required.
Action access
Example scenario- Search issues
- Create issue
- Delete issue
The user asks the agent
“Log the bug on the checkout page.”
What the agent does
The agent prepares the action and does not run it until the user approves.
Change an action’s setting; the agent’s behavior changes at once.
Three ways to connect
Turn on what is ready, plug in what is standard, define the rest yourself.
Native integrations for common business tools are ready to use. If a service offers an MCP server, you connect that. For any system with an API, you define actions, authentication, and triggers in the integration builder. All three meet in the same place: an action the agent can use.
Native integrations
Sign in with your account and the actions are ready.
Slack, Jira, HubSpot…
MCP servers
Connect the service’s own MCP server; its tools become actions.
GitHub, Notion, Stripe…
Custom integration
Define REST actions, authentication, and triggers.
Your internal systems
- under the same permission model
- with the same approval flow
- into the same record
Systems teams connect
Real names, not borrowed logos.
Below is a selection of systems teams commonly connect. The full list lives in the integration directory in the docs; a system that is not listed can be connected through MCP or a custom integration.
Communication and calendar
- Slack
- Microsoft Teams
- Outlook
- Gmail
- Google Calendar
- Zoom
Files and knowledge
- SharePoint
- Google Drive
- Confluence
- Notion
Work tracking and support
- Jira
- ServiceNow
- Zendesk
- GitHub
Customers and sales
- HubSpot
- Salesforce
Data and analytics
- Databricks
- Looker
- Metabase
- Microsoft Fabric
- Azure AI Search
Commerce and operations
- Shopify
- UiPath
- Google Maps
Availability depends on your workspace setup. Many connections need admin consent, scope selection, and network access.
Browse the integration directoryThe agent works with your permissions
If you can’t see a record, neither can the agent.
When you connect a system, a connection is created on your behalf. OAuth connections use delegated permissions by default: the agent reaches what the connection owner can reach, and nothing more. If a connection expires, is revoked, or is missing a required scope, the agent asks you to reauthorize.
Authentication types
| OAuth | You sign in to the service and approve the permission. Google, Microsoft 365, Slack |
|---|---|
| API key | You enter a key issued by the service. Custom integrations |
| Service account | An admin sets up a service-level account. Some enterprise tools |
| None | Services that expose public data. Public APIs |
Control at the action level
Turning on an integration does not open every action to everyone.
Admins can enable an integration for the whole workspace or share it with specific people and groups. Then each action gets its own decision: open to everyone, limited to certain groups and API keys, or off. Native actions that power core platform features are marked and always on.
People and groups
Open an integration only to the teams that need it.
Per-action access
Reading for everyone, writing for the owning group.
API keys
Share an action with your application’s key as well.
Approval flow
Put data-changing actions behind user approval.
Bring your own OAuth client
Your name on the consent screen, your policy in force.
When your identity policy requires it, integrations run through your own OAuth application. Define one client for the workspace and separate clients for specific groups. Scopes stay in sync with enabled actions, so only permissions that are actually used are requested.
Your branding
Your app name and logo appear on the consent screen.
Your policy
Your tenant policies and admin consent rules apply.
Per-group clients
Different groups use the same integration through different clients.
Scopes match actions
Requested scopes stay limited to enabled actions.
Connect once, use it everywhere
The same connection works in chat, agents, and workflows.
You don’t set up an integration separately for each surface. Call it on demand in chat, attach it to an agent as an action, or make it a step or trigger in a workflow. Permissions and access rules stay the same everywhere.
Bring the agent to where the team works
Every channel is a setup — know what it takes up front.
Besides the web app, agents can work in the channels teams already keep open. Each channel has its own setup and authorization step; the table below summarizes what is needed, and detailed setup guides are in the docs.
| Channel | Needed for setup |
|---|---|
| Slack | A Slack workspace admin installs the app |
| Microsoft Teams | Bot registration and Teams admin approval |
| A business account and number verification | |
| Telegram | Creating a bot and an access token |
| Website | Domain allow-listing and visitor identity settings |
| Outlook and Excel | Deploying the add-in through Microsoft 365 |
Channels are set up by a workspace admin, and the agent’s access rules still apply in every channel.
Open protocols, no walled garden
Standards for tools, interfaces, and other agents.
ajan.io supports open protocols for agents to talk to the outside world. A connection you build today keeps working with other tools tomorrow, and your internal systems are not trapped inside a closed product.
MCP · Agent ↔ Tool
Turns databases, APIs, and services into tools the agent can use.
MCP Apps · Tool ↔ Interface
An MCP tool can return an interactive UI that runs inside the chat: forms, tables, dashboards.
A2A · Agent ↔ Agent
An open protocol to discover agents on other platforms and delegate work to them.
Questions about integrations
What teams ask before they connect a system.
All FAQs
No. Many native integrations only need you to sign in with your account, but plenty need admin consent, scope selection, and network access. Setup guides are in the docs.
Connect your first system, grow the allow-list later.
Start with one integration in a free workspace; open new actions as your governance matures.