When a production incident fires, the first twenty minutes almost always look the same: pull the logs, check what deployed recently, scan for related past incidents, form a working theory. It's necessary work, but it isn't work that needs a person's judgment it needs speed and thoroughness. Ataccama's engineers looked at buying a ready made incident response tool to handle it and piloted a couple of options, but kept hitting the same wall: a generic tool has to be taught in every single conversation, what Ataccama's own infrastructure looks like which cluster, which service, which identity to authenticate as. So we decided to build an AI agent specifically tailored to Ataccama's needs, one that already knows how our systems fit together. Full credit to the crew who built it: David Polák, Nghia Le, Vladimír Volčko, Jan Krug, Tomáš Belada, Tomáš Rohrer, and Vladimír Blahož, with senior staff engineer Tomáš Hradec driving the effort.
The result is Suri, an AI teammate built on Anthropic's Claude Agent SDK. It lives inside Slack, where most of our company's communication and team collaboration already happen, ready to jump in the moment someone @-mentions it, an alert fires, or a new merge request is opened.
When an incident fires, Suri is usually already digging through metrics, logs, and recent deployments before the on call engineer has even opened their laptop, and it posts a first theory straight into the incident thread. The same agent reviews merge requests line by line, letting engineers accept or dismiss its suggestions inline, and increasingly helps the support team make sense of incoming customer tickets. None of it happens unsupervised: Suri investigates and recommends, but any action that changes something still needs a human's sign off.
We bet on agentic development early, and we got really far. Agents can navigate our codebase and make substantial changes. When the frontier models took a leap in late 2025, the next step was obvious: start automating whole processes and workflows. Not to replace people, but to take the boring work off their plate so their time goes to problems where human brainpower actually adds value. There was never a formal team owning Suri. States Jirka Brunclik VP of Engineering. Rather a working group of people from across the company (even outside of Engineering), who rallied around it because they were compelled by what we were trying to achieve. That was great to see, and I'm very proud of what the team has built. And we're just getting started: bug triage, CVE patching, incident response, many more flows we can hand to autonomous agents.
Suri started as a scrappy proof of concept in March 2026. A Slack bot bootstrapped in days to prove the idea was worth pursuing and grew, integration by integration, into a company wide service that reached general availability in July. After first month of fully operational mode Suri reports:
- ~1,250 incidents investigated automatically
- ~520 merge requests reviewed, with ~87% positive feedback
- ~50 active users across ~30 channels, powered by 10 custom plugins
Nobody owns Suri outright any engineer can extend it with a new skill, and dozens across the company already have. As Suri put it, in its own graduation announcement to the whole company: "It takes a herd to raise a llama."
Interview with: Tomáš Hradec, Senior Staff Engineer
Take us back to March. What stood behind the decision: “we should just build this ourself" instead of using available tools?
The idea had been sitting with us for a while. Using AI for incident investigation was something we'd considered for some time, the open question was maturity, whether the models were finally capable enough to warrant real investment. By early this year, we believed they were.
We started by evaluating the tools popping up in this space to see if any of them just worked for us. Two constraints turned out to be a challenge. First, much of our infrastructure is only reachable from inside our network perimeter. Second, we were satisfied with our existing observability stack and had no appetite for a vendor migration or the lock-in that comes with it. The goal was to extend what we already trusted, not replace it.
Once it was clear nothing out there fit those needs, building our own became the obvious path.
They say: "It takes a herd to raise a llama." Tell us who collaborated on this project and what does that actually look like in practice — who decides what it should do next, and how do you keep that from turning into chaos?
Suri has been a collective effort from the start. I delivered the first prototype, and around it we formed a working group of enthusiastic developers from all over the company, who each grabbed a part and started building.The fact that the group was so mixed turned out to be one of its biggest strengths. Because people came from different teams, they brought the needs and workflows of those teams with them, which meant we had an instant reality check on whether what we were building was actually useful. We reinforced this by moving into alpha testing roughly a month after kickoff, which gave us early feedback and the ability to adjust direction.
I'll be honest, I'm not a fan of heavy processes and ceremonies. I think a shared vision keeps people aligned far better than any amount of project management. So we've run Suri a lot like an open-source project, driven by the community. That common vision is precisely what keeps it coherent.
Let’s dive into how Suri actually works: could you walk us through what actually happens when the incident fires. First sixty (or other relevant number) seconds, what is Suri looking at, and how does it decide what's relevant?
Suri begins with the alert itself, which carries a lot of context: the originating cluster and service, the start time, and often a link to a runbook that Suri can read and follow as guidance.
From there it gathers the signals that matter for that time window. It pulls logs, metrics, traces, and dashboards. Those are the obvious ones. But it can also look straight into the Kubernetes cluster for events and pod details, check whether someone recently flipped a feature flag in PostHog, and correlate recent code changes and deploys, because those are usually the culprit. In parallel, it searches for similar past incidents through a RAG index over our Jira issues and Slack history, and for front-end issues it queries Sentry and correlates the error to the same trace.
So within the first few minutes, instead of an engineer starting from a blank page at 3 a.m., the alert is understood, the relevant data is gathered, and recent changes and past incidents are surfaced. It follows the same path an experienced engineer would take, just faster.
Why the Claude Agent SDK specifically, and what did the first working version look like? How long between "let's try this" and something real posting in Slack?
The honest answer is speed. The Claude Agent SDK let us skip most of the plumbing and handed us the things an agent actually needs: the multi-turn loop, session management so it remembers the conversation, and an easy way to connect our internal systems through MCP. It also enforces a least-privilege model, restricting the agent to explicitly approved tools, which is essential given the sensitivity of the systems Suri accesses. Yes, it ties us fairly closely to Anthropic, but for getting something real in front of people fast, that was a trade worth making.The first version proved it. A week in, we had a simple Slack bot backed by a Claude agent, wired to Grafana through MCP. It wasn't pretty, but it worked. You could point it at a problem and it would go pull the data and post back into the channel. Having something real in Slack that quickly told us almost right away that we were onto something.
Suri didn't stay an incident-response tool — it grew into code review and support-ticket triage. Was that expansion planned from day one, or did it happen because people kept finding new uses for it?
A bit of both. It wasn't planned in the sense that we set out to build one tool for everything. Around the same time Suri started, we had several other streams exploring where AI could help us: code review, CVE remediation, bug and issue triage, handling support tickets. They began as separate efforts. But as Suri gained traction, those streams naturally gravitated toward it and merged in, because underneath they were all the same kind of problem. The evolution didn't surprise me, though. All these use cases fit Suri really naturally, and if anything I'm genuinely curious to see what people come up with next.
Is there a specific catch — a bug Suri flagged in review, or an incident it got ahead of — that you point to as proof this was worth building?
Two moments come to mind. One from the early days really stuck with me. A CPU alert fired on one of our worker nodes. Suri traced it through the metrics to a MongoDB pod, pulled the slow-query logs, and surfaced the actual root cause: a missing index that was forcing a full collection scan on every query. What made it land for me was the reaction on the thread. The engineers were genuinely surprised at how far it had gotten on its own, without anyone holding its hand.
The support side gave us an even more convincing one. Suri identified the root cause of a blocker-level incident and laid out a step-by-step fix for the support engineer in about three minutes. He just had to get on a call with the customer and execute it, no outage process, no pulling in Engineering. Those are the moments that tell me this was worth building, because the time and the back-and-forth they save is real and immediate.
Previously, the support engineer would have had to reach out to the professional services expert who set up that custom configuration and knew how to make corrective changes on both sides of the platform. If they were unavailable, we'd pull in Engineering to work around the custom implementation and get the customer back to normal operation until a proper fix was ready. Full resolution could take days depending on who was available, shares Maksim Zhelyazkov, Support manager. Now, the support engineer on a call with the customer and executed the plan Suri created—no outage process, no pulling in additional resources.
Has Suri ever gotten it wrong in a way that taught you something important about trust, guardrails, or how much autonomy to give it? What did we learn from it?
Of course it gets things wrong sometimes. That's just the nature of the tool, and honestly it shaped how we've thought about it all along. People still need to bring their own experience and take what it says with a grain of salt.
That thinking runs through the guardrails too. Suri currently operates with mostly read-only access, so its realistic worst case is misleading information rather than actual damage. We also maintain a strong feedback loop: every response can be rated up or down and annotated with comments, which continuously improves it. Suri also tries to self-evaluate, attaching a rough confidence estimate to its answers as a hint for the reader about how much to lean on them. And in code review, it goes a step further and checks whether the follow-up changes actually address the findings it raised.
For any engineer out there reading this blog thinking “"I wish this tool existed" — what would you tell them about actually going and building it here?
That it's more approachable than it appears. If you have a problem worth solving, you can likely begin today.
Start by surveying what's already out there. The AI tooling landscape moves incredibly fast, so something may already solve your problem. Build only when nothing off the shelf fits. Then keep the scope narrow: ship a minimal version quickly, put it in front of real users, and iterate on their feedback. And from day one, monitor everything and keep an eye on cost, because these tools can get expensive quietly. With today's AI coding tools, moving from idea to working prototype is easier than it has ever been, so the hardest step is usually giving yourself permission to start.
What's next for Suri that you're personally most excited about?
The thing I'm most excited about is letting Suri actually do the work, not just investigate it. Today it's mostly read-only, which means an investigation often ends with an obvious next step that someone still has to do by hand. The next stage is closing that gap: letting Suri take the action itself, but always guarded by human approval. For example, Suri could update a Jira issue with the findings from its investigation, prepare a merge request with the fix, or resolve an incident by adjusting a deployment's resources. Crucially, nothing happens silently. When Suri needs to perform a sensitive operation, it pauses and posts an approval card in the thread describing exactly what it intends to do, and a person approves or denies it. The work stays in context, visible to everyone collaborating, and every decision is recorded in an audit trail.
Inspired to work on projects like Suri? Take a look at our current openings in Engineering.