How Superhuman's Security team made Rootly the central system for closing security incidents faster

Superhuman (formerly Grammarly) is the AI productivity platform on a mission to unlock the superhuman potential in everyone. The Superhuman suite of apps and agents brings AI wherever people work, integrating with over 1 million applications and websites. Superhuman empowers over 40 million people, 50,000 organizations, and 3,000 educational institutions worldwide to eliminate busywork and focus on what matters. Learn more at superhuman.com.

Founded: 2009 in Kyiv, Ukraine

Size: ~1,500 employees

When something goes wrong at Superhuman, nobody goes hunting through a thousand Slack channels. The incident lives in one place. Rootly spins it up, pulls in the right people for that incident type, creates the documents, starts the tracking, opens the bridge and captures its transcript, and builds the timeline as events happen. Thijn Bukkems, who leads security detection and response at the company behind Grammarly, Docs, Mail, and Go, calls that record the central system: If you want to know anything about an incident, you go to Rootly.

“Every capability Rootly ships is one my team does not have to build. That is the whole value for me: We spend our time on security, not on the tooling that runs incident management.” —Thijn Bukkems, Security Tech Lead

All in one place, for the right eyes only

Raising a security incident at Superhuman is as easy as hitting a button and filling out the short form that populates automatically. Rootly creates the incident, and based on the incident type, it knows who belongs in it: Some people are pulled in, others deliberately are not, and anything sensitive is raised as a private incident so the circle stays as small as it should be. The documents are created. The tracking starts. Rootly opens the Zoom bridge and captures its transcript without anyone requesting it. The timeline assembles itself as the incident unfolds, and the post-incident housekeeping is, in Thijn’s description, largely handled by the platform.

For a security team, that second point matters as much as the first. Who can see an incident is not a detail; it is the reason a tool is usable for sensitive work at all. Rootly’s access controls determine who can see and do what, incident types drive membership automatically so the right responders arrive without anyone hand-picking them under pressure, and private incidents keep restricted matters restricted. That principle extends to automation as well: Rootly’s MCP server deliberately limits which API paths are exposed, so an AI agent’s reach is scoped rather than total.

What all of it produces is a single record that links outward to every relevant ticket, document, and channel. Months later, when someone needs to understand what happened and why, they do not reconstruct it from memory and scattered threads. They open Rootly.

“Rootly is the central point for figuring out what happened, instead of having to search a thousand Slack channels and tools.” —Thijn Bukkems, Security Tech Lead

Follow-through after the pressure is off

This record also made it easier for Superhuman’s Security team to learn from incidents.

During an active incident, momentum is easy. The problem is fresh, the people are present, and mitigation arrives quickly.

Moving from mitigated to properly resolved means final cleanup, writing the post-incident review, getting the right stakeholders into a review meeting, agreeing which action items are real, turning those into tickets someone actually owns, and only then closing the incident. Each one of those steps competes with work that feels more urgent, because by then the pressure is off. Then there is the long tail, where action items outlive the incident in familiar ways: The owner changes teams or leaves the company, and the ticket sits with nobody attached to it.

Rootly ships agents, tasks, and follow-ups built exactly for this work. As a provider of AI assistance and agents, Superhuman drove it from the agent stack it already runs, which carries deep context on their systems and their people. Rootly’s MCP server is what made that a configuration choice rather than an integration project.

Rootly as part of Superhuman’s AI workflows

Rootly’s MCP server turns Rootly into a first-class participant in an AI toolchain, and it is purpose-built rather than a thin API wrapper. It generates its tools dynamically from Rootly’s OpenAPI specification, so the surface stays current as the API evolves. It restricts which API paths are exposed, both to keep an agent’s context manageable and to control what an AI can see and do. It paginates incident responses by default so an agent does not overflow its context mid-task. And it ships incident intelligence rather than raw endpoints, including tools that find historically similar incidents and mine past resolutions for suggested fixes. It is open source under Apache 2.0 and works with Claude, Cursor, Copilot, and other MCP-compatible clients.

With that in place, the work that used to wait on someone prioritizing it now moves on its own, and the agents draw on both what Rootly knows and the context they hold from everywhere else.

“The Rootly MCP server bridges the gap between what Rootly knows about an incident and the context our own AI already has. Incidents move to completion faster; it is simply less work because it goes and does it for you.” —Thijn Bukkems, Security Tech Lead

Through four acquisitions, Rootly just kept working

Rootly has been in place longer than Thijn has, through a stretch in which Superhuman grew to roughly 1,500 employees, acquired four companies, and rebranded itself from Grammarly to Superhuman. Asked whether Rootly had grown alongside Superhuman, with the MCP server simply the latest stage of that as the company’s processes matured and automated further, his answer was unequivocally yes.

The part worth drawing out is what did not happen along the way. As Rootly shipped capability, Superhuman adopted it and retired whatever it had been doing in the meantime, rather than accumulating internal tooling it would own forever. That is the difference between a platform that keeps pace and one that quietly hands you a maintenance burden: Every stopgap that never becomes permanent is engineering time returned to the security team.

“If it is already a capability in Rootly, and when it comes to incidents and reliability it most likely is, it makes no sense to come up with your own special tools or process because that is time you could spend doing other work.” —Thijn Bukkems, Security Tech Lead

What changed

	Before	With Rootly
Post-mitigation work	Needed to be prioritized amid other high-importance work	Driven forward automatically
Post-incident reviews	Written when someone got to it	Drafted automatically, then reviewed by people
Review meetings	Scheduled manually	Scheduled and transcribed automatically
Agreed actions	Had to be assigned and tickets created	Converted into tracked tickets with owners
Orphaned action items	Manual reassignment and the new owner had to catch up	Reassigned automatically using the Rootly incident record
Learning from history	Someone had to sit down and analyze it	Ask Rootly directly and review trends

Closing the loop without a person pushing

Agents working through Rootly’s MCP server look at every open incident and orient themselves on the details and status of each one. If a post-incident review needs a meeting, the agent finds the time and schedules it, then reads the transcript afterward so that whatever was agreed or explicitly rejected in the room becomes a ticket on someone’s backlog. Only then does the incident close. None of this is work anyone enjoys, and all of it determines whether the organization learns anything.

Finding the owner when the owner has left

The long-tail problem has a particularly nice solution, and it depends entirely on the record. When a follow-up ticket is orphaned because its owner changed teams or left the company, the answer comes from the Rootly incident itself: what happened, who was involved, what was documented at the time. That context is usually enough to identify who should own it now. As Thijn puts it, the MCP server bridges the gap between what Rootly knows and the tribal knowledge an AI assistant has picked up elsewhere.

Asking your incident history to show you trends

Because Rootly holds a complete, structured history and its MCP server makes that history directly available, Superhuman can interrogate it rather than merely store it. This used to require someone taking valuable time to sit down and do the analysis. Learning from incidents and not repeating the same mistake became materially easier the moment history became something you could simply ask questions of, along with the trends and problems Rootly surfaces today.

“Rootly has grown alongside us at every stage, and that has meant less for my team to build and maintain, not more.” —Thijn Bukkems, Security Tech Lead

Every incident platform will tell you it shortens outages. The harder and more valuable thing is to become the place where an incident actually lives: where it is declared, staffed, documented, reviewed, closed, and later understood. That is what Rootly is for Superhuman’s Security team, and it is why the slow half of the lifecycle could be automated at all. An agent can draft a review, find the right owner, or spot a recurring failure mode only if the record underneath it is complete, structured, and safe to reach into. Get that right and closing incidents stops depending on who remembers to push them along. Superhuman has been doing it for years now, through a period in which the company pivoted, rebranded, and greatly expanded its product offerings, and it’s never had to keep a piece of incident tooling alive themselves to make it work.