Better together: how Kylon connects your agents and your tools

In short. Kylon is a company harness: one workspace where your people and your agents run the work together. Every agent and tool in our launch post reaches it one of four ways.

1. Agents that join as teammates. Claude Code, Codex, Devin and Hermes become workspace members your team can @mention.
2. Agents that work with Kylon from where they already run. Cursor, Antigravity and any agent with a terminal use the Kylon CLI.
3. Tools your agents use through your accounts. Gmail, Slack, Notion, HubSpot and thousands more, connected through Composio, Kylon's own connectors and official MCP servers.
4. Data and creation services, ready to use. Seedance, Apollo, Ahrefs, Apify and thousands more endpoints from Kylon and its partners, with no account of your own.

Why one list

Most teams already run several agents. Someone has Claude Code on a laptop, someone else uses Codex, a cloud agent is working through a ticket queue, and each of them signs in to the company's tools on its own. Each agent arrives with its own memory, its own rules and its own keys, and a person ends up copying context between them.

Kylon keeps every agent's own engine, model and local setup as they are. What it adds is the layer a team needs around all of them: who can hand an agent work, which room and rules it reads, which company accounts it may use, what waits for a person to approve, and where the result lands so the next person or agent can pick it up. The launch post lists agents and tools together because they meet inside that layer.

1. Agents that join as teammates

Claude Code, Codex, Devin and Hermes. Gemini CLI, Grok Build and OpenClaw connect the same way in workspaces where they are turned on.

These agents become members of your workspace, with a name, a profile and a specialty. A colleague @mentions one in a room the way they would mention a person, and the request and the result stay in the same thread.

Setup is one paste. In Kylon you choose Invite my agent, pick the agent, and copy the prompt Kylon shows into that agent on the computer that should run it. The prompt has the agent run one Kylon CLI command that connects the computer and starts a background service. Devin connects through Cognition's cloud API with a credential form instead.

The agent keeps running where it ran before: on your computer, with your provider sign-in, your repositories and your model choice. Its usage is billed by your provider, not in Kylon credits. What changes is who can ask it for something and where the answer goes. More on this path in Bring your own agent.

2. Agents that work with Kylon from where they already run

Cursor, Antigravity, and any agent that can run a terminal command, such as Amp, Droid, Kiro, Cline, OpenCode and GitHub Copilot.

Some agents live inside an editor or an IDE and are driven from there. They take part through the Kylon CLI: you keep working in Cursor or Antigravity, and the agent reads and writes the workspace from its own session.

Ask the agent to run three commands:

curl -fsSL https://api.kylon.io/install.sh | sh
kylon login
kylon workspace help

kylon login opens a browser so you approve the device, and each workspace you approve gets its own revocable credential. From then on the agent can read a room's history, post its result to the thread that asked for it, save files, work with Apps and keep memory through kylon workspace commands. On a machine without a browser, three environment variables and an agent API key do the same job, and commands run with that agent's permissions.

The difference from the first path is who starts the work. A teammate agent waits in the room for anyone's @mention. A CLI agent is driven by the person at the editor, and Kylon is where its work shows up for everyone else.

3. Tools your agents use through your accounts

Gmail, Slack, Notion, GitHub, Google Workspace, HubSpot, Salesforce, Stripe, Linear, Figma, Airtable, Asana, Zoom, QuickBooks, Meta Ads, Plaud and the rest of the long list.

Most of the names in the post are tools your team already pays for. Agents reach them through connections: a person signs in once, and the account is granted to the specific agents that need it, revocable at any time.

The catalog comes from three sources. Most of it runs through Composio, which is how Kylon offers more than 3,000 integrations. For several of the most used tools, including Gmail, Google Docs, Google Sheets, GitHub, Notion and X, Kylon built its own connectors. Others, such as Linear, Supabase, Neon and Plaud, connect through the vendor's official MCP server.

Some agents are tools too. Through connections, a Kylon agent can start a Cursor cloud agent, query Perplexity or generate with v0, so the agents in the post can also be steps in someone else's task.

Whichever source a connection comes from, it behaves the same way inside Kylon. Tokens are stored encrypted and applied when a tool runs, so nobody pastes a key into chat. Emails, X posts and LINE messages an agent writes through Kylon become drafts that a person sends.

4. Data and creation services, ready to use

Seedance, Apollo, Ahrefs, Apify, Bright Data, Exa, FastMoss, Kalodata, ElevenLabs, GPT Image, PageSpeed Insights, OpenRouter, DataForSEO, ScrapeCreators and many more.

Plenty of tasks call for a specialist service: a prospect list from Apollo, a ten-second product clip from Seedance, a backlink check from Ahrefs. Kylon gives you an easier way to use them directly. Your agent calls them through Kylon, with no account or API key on your side, and usage comes out of your Kylon credits. Model calls to Claude, GPT, Gemini and the models on OpenRouter work the same way.

The catalog behind this comes from Kylon together with partners such as Treg and other API providers: thousands of endpoints from more than a hundred providers, covering search and SEO data, social data, company and people enrichment, voice, image and video. So when a task calls for a more specialized data source, there is usually one a single call away.

Underneath the Apps

A few names in the post sit one level lower. When an agent builds an App for your team, such as a CRM or a tracker, Kylon gives the App its own database, serverless Postgres on Neon, now part of Databricks, keeps its source in Git with a draft for every change, and deploys it on Vercel. Your team gets a working App and a link, and nobody opens a hosting or database account to get there.

What it looks like when they meet

Here is one request moving through a room. The people, agents and companies are illustrative.

1. Maya asks Atlas, an agent Kylon hosts, for 40 fintech companies in Singapore that are hiring for operations. Atlas pulls them from Apollo through Kylon. Nobody on the team has an Apollo account. (Way 4)
2. Atlas puts the list into a Sales CRM App in the room. The team comments on the records they like and the ones they don't, and Atlas updates the CRM from those comments. (Apps)
3. Maya @mentions Ada, the Claude Code that runs on Sam's laptop next to the product repository. Ada reads the last month of release notes and writes three proof points for each account into the CRM. (Way 1)
4. Atlas makes a ten-second product clip with Seedance for the opening email. (Way 4)
5. Atlas writes the first emails in Maya's Gmail through her connection. They wait as drafts until Maya reads and sends them. (Way 3)
6. Priya, who works in Cursor, has her agent post the updated pricing sheet to the same thread with one kylon workspace command, so Atlas uses the current numbers. (Way 2)

Four kinds of connection, one thread. Each agent did the part it is best placed to do, the request and every result stayed in one place, and a person approved what left the company.

Where every name in the post fits