I recently sat in on a call with an engineering team at a large SaaS platform, where they walked us through an incident. A change to how web tokens were signed had broken a downstream service. The logs told them something right away: a spike of 429s and 503s, a networking-layer failure. What the logs couldn't tell them was why.
When the incident hit, the team stood up a war room, pulling in the right people. Fortunately, a staff engineer remembered making that exact signing change himself, weeks earlier, which gave the team the clue it needed to figure out and fix the issue. It was a great outcome, and everyone agreed they'd been a little lucky to solve it so fast. All I could think about was what if that engineer had forgotten, or been out sick, or simply hadn't been the one paged. Then what?
So I asked them directly: what if that one key person hadn't been there? They told me plainly that they wouldn't have known the cause, and it would have taken them much longer to figure out.
Tribal Knowledge
This is the fundamental problem with trying to create collective knowledge. For all the work you put into building that shared understanding, it often comes down to a serendipitous finding. In other words, dumb luck. Assemble your best people, pull up the dashboards, and gather whatever else is on hand, and you still end up with a patchwork: pieced together from whoever's in the room that day, from memory, from telemetry, never a complete picture, just fragments reassembled under pressure.
Along these lines, I've always found the term tribal knowledge misleading. It sounds like something the whole tribe holds together, almost a nice image. In my experience it's usually fragmented across many people’s memories. There's a name for this in the field: bus factor, the number of people who could get hit by a bus before a project stalls. Most teams can name theirs if you ask them directly. Few do anything about it until the day they need the backup and discover it isn't there.
Knowledge Transfer
The common response is to document more, rotate people across more components, run more knowledge transfer sessions before someone leaves. That doesn’t work, for two reasons.
The first is scale. The total body of relevant knowledge is bigger than any one person can hold, and it accumulates over years, across a rotating cast of engineers, most of whom are gone by the time any of it matters again.
The second is drift. Even if that entire body of knowledge could somehow be captured and handed off cleanly, it wouldn't stay accurate. Every release changes something. Knowledge transfer assumes a fixed target you can document once and hand off. The target constantly moves, so the documentation is out of date before the next person needs it.
This is why the fix isn't about creating better processes around people. It’s about creating something that keeps up with the system automatically, at the same pace the system actually changes.
So What About AI?
With AI in the picture, the obvious question is why we can't just build that: a system that maintains a complete, current picture across infrastructure and code base, so the answer doesn't depend on who happens to be in the room. Without it, debugging systems with AI is a non-starter. However, with well-constructed context in place, AI can indeed investigate the root cause and help remediate issues. And, in the case of Herald, predict incidents before they manifest. The question is how.
Most teams build an internal agent: wire something into existing tools, point it at whatever data source seems most relevant. This is a reasonable approach, but two problems show up almost every time.
The first is hypothesis latching, where an agent forms a theory early and spends the rest of the investigation confirming it instead of testing it. It rabbit holes by overweighting a direction, even when the evidence doesn't fully support it.
The second, and the one that matters more, is trust. An agent that says "I think it's the database" without showing its work is close to useless at 2 a.m. Engineers need to see what it checked, what it ruled out, and why it believes what it believes. We wrote about this earlier in a post called The Glass Box AI SRE.
Solve both of those, and you’re further along, but still haven't solved the harder problem: keeping that understanding current as the system underneath keeps changing. Tribal knowledge also suffers from impermanence.
Like Tears in Rain
There's a scene near the end of the 1982 film Blade Runner where a dying replicant, Roy Batty, reflects on everything he's witnessed, and how none of it will survive him once he's gone. “You people wouldn’t believe the things I’ve seen… all those moments will be lost in time, like tears in rain." It's a dramatic way to put it, but it's a good way to think about tribal knowledge. The memory is real while someone's carrying it. The moment they're gone, so is everything they knew.
A well designed agent running over a well constructed graph means people no longer have to remember complex relationships, like which services depend on each other, what changed last time, which deployment caused which failure. The agent connects the failing service to the recent change, surfaces the deployment that introduced it, and shows why the two are related. It doesn't need to find the engineer who happens to remember. It already holds the relationship he was carrying in his head, and it holds it whether he's in the war room, on vacation, or three companies away by the time the next incident hits.
Time to Die
Teams are shipping more code to production with AI coding agents than ever before. Not only is it too much for the team to follow, but also foreign to them since they didn't write it themselves. Maybe I'm leaning on that Blade Runner scene harder than I should, but I think the point stands: the way teams reconstruct memory needs to change, at least if they want AI to help them debug the glut that AI coding agents are shipping. Great engineers are often the fastest path to an answer. The problem is that resilience can't depend on whether they're available or whether they remember the right detail at the right time. What stuck with me from that call wasn't really about tokens or signing. It was the team saying it themselves: without that one memory, they'd have been stuck much longer. Their process for finding people worked fine, and those people happened to know the answer. But that's not a resilient system, especially in the era of AI coding.