Best integrations for engineering teams

Engineering teams automate more than most, which makes the gaps stranger. The build is automated, the tests are automated, and then someone still opens four tabs every morning to work out what happened overnight.

The tools below close that gap, and they are worth connecting in a specific order. One of them is far narrower than you would expect, and it is on the list anyway — the reason is the useful part of this guide.

GitHub

GitHub is the anchor for the same reason Notion is for marketing: it holds the thing everything else refers to.

The integration exposes repository and issue operations — listing and reading repositories, and listing, creating, reading, and updating issues. That combination is what makes a morning brief possible: the assistant can read what changed and then file what needs filing, rather than reporting and leaving you to do the entry.

→ GitHub integration · used in daily repo brief and first-pass code review

Linear

If GitHub holds the code, Linear holds the work about the code, and most planning questions live in the relationship between the two.

Linear exposes teams, projects, and issue search, creation, and updates. Search matters more than it looks: it is the difference between "make me a ticket" and "make me a ticket unless one already exists", which is the version that survives contact with a real backlog.

→ Linear integration · used in triage the engineering backlog and plan the next sprint

Sentry

Sentry is a narrow integration with a high-value job: list project issues, list events, and update an issue.

Four actions is enough for the thing that actually hurts, which is not knowing an error spike exists. The assistant can read what is firing, group it, and take it somewhere a human will see — and update the issue once it has been picked up.

→ Sentry integration · used in investigate an error spike and open an incident with context

Vercel

Vercel is the widest integration on this list by a distance, covering deployments in depth — listing, inspecting, creating, cancelling, promoting, and reading deployment events and files.

Breadth is genuinely warranted here, because "what is deployed" is a question with many precise forms. It is also the integration where the approval gate matters most: reading deployment state is safe, and promoting a deployment is not the kind of thing that should happen without you.

→ Vercel integration · used in ship the latest commit

Figma

Here is the narrow one. Figma exposes exactly three actions, all about comments: list them, post one, delete one. It cannot read your design files.

That looks like a disappointing integration until you look at where design-to-engineering handoffs actually stall. It is rarely the file. It is the thread of comments agreeing what the file means, which then has to be turned into tickets by someone reading both. The comment surface is the part that converts into work.

It is worth stating plainly rather than implying otherwise: if you want the assistant to interpret the design itself, this integration does not do that.

→ Figma integration · used in turn a design into tickets

Slack

Slack is where the output goes, and for engineering that is usually the whole point — the brief, the spike alert, the deploy confirmation.

It reads channel history and threads and posts messages and replies, which also makes it an input: catching up on a busy channel is a real task, not just a delivery mechanism.

→ Slack integration · used in daily repo brief and write the sprint recap

What the action counts tell you

Line these six up and the range is striking: Figma exposes three actions, Sentry four, Linear seven, GitHub sixteen, Vercel fifty-six.

That spread is not a quality ranking. It reflects how wide each tool's domain genuinely is, and how much of it is worth exposing as a named action. Deployment state has many precise questions; design commenting has about three. An integration that mirrored every endpoint would be harder for the assistant to select from, not easier — more surface to choose wrongly within.

Choosing wrongly is a named, measured failure mode. Benchmark work presented at the ICML 2026 Workshop on Failure Modes in Agentic AI ran six frontier models across 580 tool-use scenarios and separated incorrect tool selection from omitted and repeated calls, finding wrong selection accounted for up to a quarter of weaker models' failures while the best configuration still reached only 74.8 overall accuracy. The scenarios are adversarially weighted, so treat that as evidence about the shape of the failure rather than about how often your agent will hit it.

The practical read: judge an integration by whether it covers the handoff you are stuck on, not by how many actions it lists.