--- title: "Your agents, your tools: Guild's growing integration catalog" canonical: "https://www.guild.ai/blog/product/our-growing-integration-catalog" --- # Your agents, your tools: Guild's growing integration catalog - **Category:** Product - **Author:** Cory Waddingham - **Published:** Nov 13, 2026 - **Reading time:** 5 min ## An agent is only as useful as what it can reach An enterprise agent that can't touch your systems is a very expensive chatbot. The work your teams want to hand off lives in a ticketing queue, a repo, a CRM record, a shared drive, a Slack thread. If an agent can't read from those places and act in them, it can describe the work but never do it. That's why integrations sit at the center of Guild. Since August, our official catalog has more than doubled, from 32 integrations to 71, and that count now includes the 11 models and inference providers your agents run on. Every tool in it ships with the same thing underneath: a defined list of operations you can grant, or withhold, agent by agent. ## The tools people already know and love Nobody adopts an agent platform so they can switch tools. Developers have years invested in GitHub or GitLab, in Linear or Jira, in the observability stack they trust at 2 a.m. Business users live in Salesforce, HubSpot, Google Workspace, Notion and Slack, and they've built their processes around how those tools behave. Agents earn their place by meeting both groups where they already work. A support agent that triages in Zendesk and posts to Slack fits into a day that's already in motion. One that asks the team to move into a new system gets ignored, no matter how good it is. ## From 29 to 71 in under seven weeks The catalog started out slow and slightly dipped to 29 in late September when we retired the original versions of the Notion, Google Docs, Asana, and Turbopuffer integrations. It has climbed steadily since. Telegram, PostHog, and Ashby arrived in mid-October alongside returning and improved Notion and Google Docs integrations. On October 20, the 11 models and inference providers your agents run on joined the catalog as integrations in their own right. A batch of integrations then moved into the official guildai organization on November 4, and this week's catalog sync brought the total to 71. Treating models as integrations is intentional. Picking the model an agent runs on deserves the same documentation, and the same governance, as picking the tools it can call. ## Every integration is a list of operations Connecting an agent to a tool is the easy part. The harder one is making sure it only does what you meant it to do. In Guild, every integration is defined as a set of discrete operations. Each operation becomes one tool an agent can call: list issues, read a file, open a pull request, merge a branch, delete a repository. When you attach an integration to an agent, you choose which of those operations it gets. Everything else stays out of reach. For security and platform teams, that changes the question you have to answer. You aren't approving "access to GitHub." You're approving four specific actions, for one specific agent, and you can see exactly which four. ## Three agents, one repo, three different jobs Take a common engineering setup built on GitHub (the same pattern works on GitLab). You want help writing code, keeping an eye on review load, and getting finished work in front of reviewers. You could build one agent with full repo access and trust it to behave. Or you could build three, each holding only the operations its job requires. - **Coder** writes code on a working branch. It can read files, create a branch, and commit changes. It can't open, approve, or merge pull requests. - **Reviewer queue** reports on open work each morning. It can list pull requests and read pull request details. It can't write code or change any pull request. - **Publisher** packages finished work for review. It can create pull requests and add reviewers. It can't commit code, merge, or delete branches. The coder can't sneak its own work into main, because it has no way to open or merge a pull request. The reporting agent can't "helpfully" fix something it notices, because it can only read. The publisher can't rewrite the code it's submitting. Each agent's permissions match its design, so a confused prompt or a bad tool response can't push it into actions it was never built to take. A human still decides what merges. ## When the tool you need isn't in the catalog Some systems will never show up in anyone's catalog. A custom ERP your finance team has run for fifteen years. An internal HR tool. A product the vendor stopped supporting, which your operations still depend on. For those, Guild lets you build your own integration. Point it at an OpenAPI spec, and each endpoint becomes an operation, with the same per-agent controls as everything in the official catalog. The [Create an integration](https://docs.guild.ai/integrations) guide walks through it. Custom integrations are meant for those private, internal systems. For the widely used tools your teams share with the rest of the industry, our goal is that you never have to build one. That's what the official catalog is for. ## Connected, and in control Our goal is simple to say and a lot of work to deliver: it should be trivial to connect your agents to your knowledge, your processes, and your tools, and just as easy to make sure those agents only take the actions you want them to take. A growing catalog handles the first half. Operation-level scoping handles the second. We're adding integrations every week, prioritized by what Guild Members actually run in production. Browse the current catalog at [docs.guild.ai/integrations](https://docs.guild.ai/integrations), and if a tool you depend on is missing, [let us know](https://www.guild.ai/talk-to-sales). There's a good chance it's already on the list. ## Connect your agents to the tools you already use See how Guild connects agents to your knowledge, processes, and tools, with every action scoped to exactly what each agent needs. [See Guild in Action →](https://guild.ai)