Your AI Agent Knows Nothing About Your Org

Picture the most brilliant engineer you've ever hired. Day one, they walk in knowing nothing—not your internal tooling, not why the CTO shut down that integration six months ago, not that your team uses a factory pattern as a near-religious convention. They're smart enough to eventually piece it together, but for a while, you're babysitting them.

That's your AI agent every single time you fire it up. Every. Single. Time.

Brandon Walsenuk, who works at Unblocked, made this case at the AI Engineer conference this week, and the framing is so clean it almost hurts. He describes an engineer arriving at a new company and slowly building competence: the rejected PRs, the hallway conversations, the gradual accumulation of institutional knowledge. "You became very good at your job," he told the audience, "because you asked good questions and you knew how to gather accurate context and shred stuff that wasn't helpful for you." Your AI agent, by contrast, starts from zero every session. You're not just its employer—you're its entire memory.

The solution Walsenuk is selling is a context engine, a layer that reasons across your codebase, Slack history, PR patterns, and org structure to build what he calls a "research packet" before the agent writes a single line of code. The benchmark he presented—self-reported by Unblocked, worth noting—is striking: the same prompt, same agent, same model, run with and without the engine. Without it: 2.5 hours, 20.9 million tokens, multiple rounds of human correction, and code that compiled fine but would have broken the entire system in production. With it: 25 minutes, 10.8 million tokens, one senior-engineer nitpick, approved merge.

I find the core diagnosis credible, even if the scoreboard comes from the company selling the solution.

The Three Things People Think Will Fix This (And Don't)

If you use GitHub Copilot or Claude in your workflow, you've probably already bumped into the problem Walsenuk is describing, even if you couldn't name it. Here's what most teams try first, and why each one falls short.

Naive RAG — RAG stands for retrieval-augmented generation, which is a fancy way of saying "let the AI search your documents before answering." The problem, Walsenuk explains, is something called "satisfaction of search," a cognitive bias that's well-documented in radiology: a radiologist finds one thing on an X-ray and stops looking, because finding something feels like finding the answer. AI search does exactly the same thing. Ask it to implement a Zendesk integration, it finds the first relevant pattern in your docs, and it stops. Whether that pattern is current, correct for your architecture, or superseded by a Slack thread where your CTO said "this approach was wrong"—the agent doesn't know and doesn't keep looking.

More MCP connections — MCP servers are basically pipes that give AI agents access to different data sources: your GitHub, your Jira, your Confluence. More pipes sounds like more knowledge. But Walsenuk's point is sharp: "They're there. They're pipes. That's great. But they don't provide understanding or reasoning across it." You, on day one at a new job, didn't magically understand the org just because you had access to the file server.

Giant context windows — Newer AI models can hold enormous amounts of text in their working memory—over a million tokens in some cases. Walsenuk's claim is that stuffing them full doesn't work: the model can't effectively reason over that volume of unstructured information. This is a contested area in AI research—long-context performance varies considerably by model and task—but his point isn't really about the ceiling. It's that raw capacity isn't the same as structured understanding.

The context bottleneck in AI systems is increasingly recognized across the industry, and Walsenuk's framing aligns with a broader shift away from "give the model more data" toward "give the model the right data."

What a Context Engine Actually Does

Think of it less like a search engine and more like a really well-briefed research assistant who knows your company. When a query comes in—"how do I implement this feature?"—a context engine isn't just doing keyword search. It's asking: Who is asking? What codebases do they work in? What's their PR history? Are there conflicting signals across sources, and if so, who said what and how authoritative are they?

That last piece is where it gets genuinely interesting. Walsenuk gives a scenario I recognize from real security incident investigations: the production code says one thing, a Slack thread says the CTO called that implementation wrong, and these two sources are in direct conflict. A naive system picks one. A context engine, as Walsenuk describes it, resolves the conflict by reasoning about the social graph—who has authority here, what's the most recent signal, what should the agent actually be told?

The output isn't "here's everything we know." It's a compressed, curated packet: here are your factory patterns, here's your fallback infrastructure (Bedrock, in their case, which the naive agent famously missed), here's the relevant precedent. The agent starts informed instead of starting blind.

As Walsenuk put it: "The gap is not intelligence at this point. It is context."

Here's the Part Nobody in That Room Talked About

I've spent enough time doing security work to know exactly what kind of system Walsenuk just described, and it's not just a productivity tool.

A context engine that ingests your Slack conversations, Microsoft Teams messages, PR histories, code review comments, and organizational hierarchy is, from a security standpoint, a comprehensive institutional knowledge graph. It knows who talks to whom. It knows who has authority. It knows what the CTO said privately about a technical decision. It knows your fallback infrastructure. It knows which engineers work on which systems.

That is an extraordinarily valuable breach target.

Walsenuk does address data governance, and to his credit, the framing is thoughtful: Unblocked uses OAuth to carry permissions through the system, so private Slack messages only surface to the person who wrote or received them. "If it's you, we will return responses from private chats, but if someone else asks a question, we will never show them private chats that aren't theirs." The permission model, as described, is sound.

But sound permission logic in a vendor's product doesn't answer the deeper question for teams evaluating whether to build or buy: do you want a third party holding this graph at all?

Because here's the uncomfortable math. You're being asked to hand a vendor continuous access to your institutional memory—the informal decisions, the architectural debates, the organizational power dynamics—in exchange for faster agent outputs. When you frame it as "AI productivity tooling," it sounds like a no-brainer. When you frame it as "we are giving a SaaS company a real-time map of how our organization actually functions," the risk calculus looks different.

The data aggregation risks that come with centralizing this kind of institutional knowledge aren't hypothetical. Any breach of a context engine doesn't just expose code—it exposes the social and organizational layer that code sits inside.

Teams serious about this decision should be asking vendors: Where does the graph live? Who can query it, and how is that access logged? What's the data retention and deletion policy? What happens to our institutional knowledge graph if we cancel the contract? What's the breach notification window? If a vendor can't answer those questions specifically, that's informative.

The build-vs-buy calculus here is genuinely different from most SaaS decisions. Building your own context engine is hard—Walsenuk's talk is a good window into just how hard—but it keeps the knowledge graph inside your perimeter. Buying gets you faster, but you're trusting a vendor not just with your data, but with a structured, reasoned map of your organization.

I'm not saying don't do it. The productivity argument is real, and the benchmark numbers—even self-reported—suggest meaningful efficiency gains. What I'm saying is: the question isn't whether your AI agents need better context. They do. The question is who you're comfortable letting hold that context, under what contractual terms, with what security guarantees.

Before you sign up for any context engine, vendor-built or otherwise, ask your security team one question: if this system were breached tomorrow, what exactly would the attacker walk away with? If the answer makes you uncomfortable, that discomfort is data.

---

Rachel "Rach" Kovacs is Buzzrag's Cybersecurity & Privacy Correspondent. Former white hat hacker, reformed corporate InfoSec director, current explainer of things that matter.