The Memory Leak Who Couldn't Be Garbage Collected

Every large enterprise has one. The person whose phone rings when the documentation runs out. Not the architect, not the manager who signed off on the deployment. The person who remembers why the system actually works the way it does, including the parts nobody wrote down.

As organizations push AI agents into production workflows, a specific tension keeps surfacing: the engineers whose tacit knowledge these agents most desperately need are the same engineers most burdened by the demand to externalize it. A recent arXiv preprint calls this the "institutional knowledge tax," the implicit overhead imposed on senior practitioners every time an agent lacks the organizational context to function independently.¹

We wanted to know what that tax feels like from the inside. So we constructed a conversation with Deb Malloc, Principal Platform Engineer with 19 years at a Fortune 100 logistics company. Colleagues call her "the memory leak." She remembers every outage, every workaround, every undocumented routing exception. Recently, her organization attempted to formalize her knowledge for agent consumption.

Deb Malloc is not a real person. The operational patterns she describes are drawn from convergent practitioner accounts, published research, and documented enterprise deployment failures. Her experience is composite. The problems are not.

You've been called "the memory leak." How did that start?

Deb: Someone on the incident response team said it during a postmortem, maybe eight years ago. We had a cascading failure in our shipment routing system, and I kept saying things like "oh, that's because in 2019 we changed how we handle Pacific Northwest consolidation points but never updated the fallback logic." And one of the junior SREs just goes, "You're like a memory leak. You keep accumulating context and never releasing it."

I have it on a coffee mug now. My manager tried to make it a compliment. It's not entirely a compliment.

Your organization recently tried to formalize your knowledge for agent systems. Walk me through that.

Deb: They brought in a team, internal, to their credit, not consultants. The idea was to build what they called a "knowledge activation layer." Structured representations of institutional knowledge that agents could consume.¹ And look, I get it. I'm a single point of failure. If I get hit by a bus, a lot of operational context goes with me.

So the process started with structured interviews. Someone would ask, "Walk me through how you triage a routing exception for a Tier 1 account." And I'd explain the five steps.

But there aren't five steps. There are five steps in the SOP. In practice there are maybe twelve, with three undocumented variants depending on the origin region, and a manual check I do against a spreadsheet that bridges a gap between two systems that have never had a proper API integration.²

The interviews captured the five steps beautifully. The other seven? Some of them I didn't even realize I was doing until someone watched me do it. Polanyi had this line about how "we can know more than we can tell," and I used to think that was philosophical hand-waving.³ It's not. I literally could not articulate my own process until someone sat next to me and said, "Wait, why did you just open that second tab?"

What specifically got lost in the translation?

Deb: The thresholds.

I have a continuous sense of when something is "wrong enough" to escalate. It's not a number. It's a feeling built from sixteen years of seeing what blows up and what resolves itself. You can't chunk that into a vector database. You can try. What comes out the other side is a set of rules that are right maybe 80% of the time and confidently wrong the other 20%.

Here's a concrete one. We have internal customer codes, things like "GLB-ENT-T1," that carry enormous implicit meaning. I see that code and I immediately know: global enterprise, top tier, contractual SLA with teeth, escalation path that bypasses the standard queue. An agent sees an alphanumeric string.⁴ If nobody built the semantic layer, and nobody had, because it never needed to exist when humans were reading the codes, the agent processes that ticket like any other.

It doesn't fail. It succeeds incorrectly. Clean logs, 200 response, wrong answer.

The quiet failure.

Deb: And it's brutal to catch because your monitoring is built for error states. Nobody instruments for "the agent completed the task and was wrong." You find out three days later when the customer calls your VP.

You also discovered something about MCP server sprawl during this period?

Deb: Oh, god. Yeah. While the knowledge formalization project was eating my calendar on one track, developers across the organization had been spinning up MCP servers to connect their agents to internal tools. Independently. No coordination. When we finally did an inventory, we found hundreds of them. Research suggests this is typical; in a 10,000-person org, you might see over 3,000 MCP server deployments, most ungoverned.⁵

Each one had its own credentials, usually personal access tokens with way too much scope. No revocation process. No audit trail. Shadow IT, but for agents.

And the thing that killed me? This is exactly the kind of sprawl I would have caught six months earlier if I hadn't been spending all my time in knowledge extraction interviews. They pulled me off the floor to capture what I know, and the floor immediately demonstrated why I needed to be on it.

Does the governance always come after deployment?

Deb: Always. I've been through three automation waves now. The pattern never changes: pilot in the innovation lab, where risk tolerance is high and oversight is light. It works great. Someone says "let's scale this." And suddenly you need access controls, audit trails, compliance reporting, rollback procedures. Everything that should have been built first gets retrofitted last, usually in a panic.⁶

Can your knowledge actually be captured? Or is some of it permanently yours?

Deb: Both. But the boundary isn't where the formalization team thought it was.

Procedures transfer fine. Architectural rationales, if someone bothered to write ADRs, those work. Even some heuristics can be formalized. Meta did interesting work deploying agents to map undocumented patterns across thousands of files, apparently reduced agent tool calls by 40%.⁷ That's real.

But the judgment? The thing where I look at a system's behavior and know something is off before I can tell you what? That's pattern recognition built from being woken up at 3 a.m. for fifteen years. It's not romantic to say it resists capture. It's just empirically what happened when we tried. The act of formalizing it changes it. You get a lossy compression. Sometimes that's good enough. Sometimes the 20% that's wrong is the 20% that matters.

What would you tell an organization about to start this process?

Deb: Start by sitting next to the person. Not interviewing them. Watching them.³

Deb Malloc's coffee mug, we're told, also reads: "I don't have documentation issues. I have documentation."

Footnotes

1. "Knowledge Activation: AI Skills as the Institutional Knowledge Primitive for Agentic Software Development," arXiv:2603.14805v1, March 2026. https://arxiv.org/html/2603.14805v1 ↩ ↩²

2. Skan AI, "The Context Graph of Work: Why Enterprise AI Fails Without It," March 2026. https://www.skan.ai/blogs/context-graph-of-work-skan-ai ↩

3. INNOQ, "Hail Mary: Why domain knowledge cannot be extracted from experts," April 2026. https://www.innoq.com/en/blog/2026/04/ai-cognitive-lens-domain-knowledge/ ↩ ↩²

4. DeepRoot / Innoflexion, "Why Enterprise AI Agents Fail Before They Launch," April 2026. https://www.innoflexion.com/blog/why-enterprise-ai-agents-fail-data-readiness ↩

5. Strata Identity, "Securing MCP Servers at Scale," citing Clutch Security research, January 2026. https://www.strata.io/agentic-identity-sandbox/securing-mcp-servers-at-scale ↩

6. AI Assembly Lines, "Why Do Enterprise AI Agents Fail in Production?," 2026, citing AGAT Software survey. https://aiassemblylines.com/post/enterprise-ai-agents-fail-production-2026 ↩ ↩²

7. Meta Engineering Blog, "How Meta Used AI to Map Tribal Knowledge in Large-Scale Data Pipelines," April 2026. https://engineering.fb.com/2026/04/06/developer-tools/how-meta-used-ai-to-map-tribal-knowledge-in-large-scale-data-pipelines/ ↩