Why AI agents need a Context Lake

Zohar Einy · article · 2026-05-27 source ↗ Reader 🖥️

Agent Governance (Internal)Agent Security Agent Tool Management Context Engineering Knowledge Base MCP (Model Context Protocol)Organizational Legibility Platform Engineering Vendor Self-Reported Metrics

Scaling AI agents beyond a single power user to an entire organization fails not because of model quality but because agents lack a queryable layer of organizational knowledge (ownership, dependencies, criticality, terminology) that tool access alone cannot supply — and building that layer, a "Context Lake," is what makes agent behavior consistent, safe to approve, and affordable at scale.

practical · mixed — Practical/argumentative: builds a case for adopting a specific architectural pattern ("Context Lake") to scale AI agents across an organization. Structured as problem-diagnosis (three walls) followed by a solution pitch, with anecdotal quotes and a walkthrough of the vendor's own product (Port) as the worked example.

Structure

Part	Role
Three walls (security approval, MCP tool-definition context bloat, brittle/guessing answers)	evidence / problem framing
AGENTS.md doesn't scale past one repo	context — rules out the incumbent alternative solution
Definition of "Context Lake" and its contrast with MCP and with human-facing service catalogs	conceptual core — introduces the proposed solution
Use cases (on-call, blast radius, terminology translation, prioritization)	evidence by illustration
"What becomes possible" workflows (PR routing, day planner, incident triage, delegation)	evidence by illustration — extends the pitch from Q&A to autonomous workflows
"How it works" — Port's own architecture (integrations, blueprints, scorecards, access controls, MCP server/API)	conclusion — the proposed solution instantiated as the author's own product
"What's next" — self-discovery, and an admission that not all data belongs in the lake	qualification — narrows the claim's scope and flags current limitations

Key terms

Context Lake
A unified, queryable layer of organizational knowledge (ownership, dependencies, criticality, terminology) that sits between agents and their tools, built for programmatic/agent access rather than human browsing — distinct from raw tool access (MCP) and from human-oriented service catalogs.
MCP tool chaos
The degraded agent performance, inflated cost, and higher latency that result from enabling many MCP servers/tools whose definitions all get loaded into the context window at once.
Blast radius Agent Security
The set of downstream services, teams, or systems affected if a given service or change fails or is modified.
Context engineering Context Engineering
Managing, curating, and delivering the right context to AI systems at scale — presented as the discipline that motivates building a Context Lake.

Propositions

explicit⚡ disputed & corroboratedEnabling many MCP servers/tools on an agent causes context-window bloat — Anthropic has documented agents consuming roughly 150,000 tokens just loading MCP tool definitions — which degrades response quality and raises cost and latency.conf: high
supportsCloudflare Launches Code Mode MCP Server to Optimize Token Usage for AI Agents · p1 — Both identify exposing many API endpoints as separate MCP tools as a direct context-window cost that degrades agent reasoning capacity.
contradictsAAIF's MCP Dev Summit: Gateways, gRPC, and Observability Signal Protocol Hardening · p4 — This piece treats MCP tool-definition bloat as an open wall requiring a new architectural layer; the MCP Dev Summit source frames the same bloat as a client-side engineering problem already largely solved with 85%+ token savings.
supports ←Graphify: Unifying Codebase Context to Streamline Agentic Software Engineering · p2 — Both diagnose raw context-window consumption as the mechanism degrading agent quality and cost — context-lake for MCP tool-definition bloat (~150k tokens), Graphify's premise for raw file/code text — converging on 'curate before you feed the model' as the fix, just applied to different sources of bloat.
supports ←Just Talk To It - the no-bs Way of Agentic Engineering · p6 — Anthropic's own documented finding that agents can burn roughly 150,000 tokens just loading MCP tool definitions backs up his specific GitHub-MCP-vs-gh-CLI token-cost example.
explicitcorroboratedAn agent with full tool/API access still cannot answer basic organizational questions (who owns this service, what counts as "open," who "me" is) because that relational and institutional knowledge does not exist in any API the agent can query.conf: high
extendsThis Week in AI: Production Viability · p19 — Names the same underlying phenomenon (tacit organizational knowledge as a moat that agents can't access) and proposes a structured, access-controlled way to expose it, rather than leaving it as an unrecognized capital expense.
supportsThree Pillars of Platform Engineering: A Virtuous Cycle · p5 — Both diagnose missing/undocumented organizational knowledge (tribal knowledge, 'who owns this') as a structural scaling problem rather than a people problem.
supports ←Presentation: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs · p2 — Matches the specific failure mode: an agent with tool/API access still cannot answer basic organizational questions (who owns this, which regime applies) without a relational knowledge layer.
extends ←Meta's Recipe for Building Agents as "Organizational Second Brains" · p1 — Extends the diagnosis that agents lack organizational/relational tacit knowledge by offering a concrete architecture meant to actually supply that missing expertise.
explicitPer-repo documentation approaches like AGENTS.md do not scale to an organization with hundreds or thousands of repos, because there is no mechanism to keep them synchronized or applied consistently across teams.conf: high
extendsFighting Tool Sprawl: The Case for AI Tool Registries · p1 — Generalizes the 'fragmentation is the predictable result of missing shared infrastructure' diagnosis from tool registries specifically to organizational knowledge/documentation more broadly (AGENTS.md doesn't scale for the same structural reason tool sprawl happens).
explicitcorroboratedA centralized, queryable layer of organizational knowledge (mapping tool/data-source output to business terminology, ownership, and relationships) produces consistent, repeatable agent answers instead of answers that vary depending on phrasing and which tools happen to be connected.conf: high
supportsEveryone Is Talking About Context for AI. Here's What Most Companies Still Miss. · p3 — Same claim from a different vendor's piece in the same genre: without operational/organizational context, agents cannot be trusted to make reliable decisions or take effective action.
extendsPresentation: Autonomous Data Products for the Autonomous Era: Rethinking Data Architecture for GenAI · p7 — Both propose a single modeled/semantic layer exposed through multiple consumption modalities (including MCP) rather than separate parallel integrations per consumer — Context Lake applies the same pattern to organizational knowledge rather than data products specifically.
supports ←Presentation: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs · p2 — Both argue a centralized organizational knowledge layer is what lets agents give consistent, org-specific (vs. generic) answers.
implicitcorroboratedAccess control for agents should inherit directly from existing human access-control systems — an agent acting on behalf of a user should only see what that user can see.conf: medium
supports ←Enterprise Analytics Beyond Dashboards: Intelligent Data Orchestration with LLMs · p7 — Khapekar's regional-VP-without-EMEA-access example is a concrete instantiation of the principle that agent access control should inherit directly from existing human access-control systems.

Arguments

Organizations need a Context Lake (a dedicated organizational-knowledge layer) rather than relying on MCP tool access or per-repo documentation alone. strength: medium

Explicit premises:

MCP gives agents tool access but not relational/institutional understanding (ownership, dependencies, meaning of terms like 'production-ready').
AGENTS.md-style documentation doesn't scale past one repo.
Agents need the same onboarding a new human employee needs, and that onboarding knowledge isn't captured anywhere machine-queryable today.

Implicit premises:

The relevant organizational knowledge (ownership, criticality, terminology, relationships) is stable and definable enough to be modeled once in blueprints, rather than being contested, situational, or changing faster than the model can be kept in sync.
A single centralized layer is the right shape for this knowledge, rather than distributing it across many smaller, team-owned sources (the article never considers a federated/domain-owned alternative).

Inferences:

If the modeling effort itself is nontrivial (as the piece admits — 'Building a Context Lake still takes effort'), then Context Lakes face the same scaling/incentive problem AGENTS.md faces, just moved up a layer: who does the modeling, and does it keep pace with organizational change?

Narratives

An anonymized platform lead at a large financial institution says it took over 9 months to get GitHub Copilot approved, and MCP servers remain entirely blocked.
→ Illustrates the 'security blocks you' wall — makes the approval-bottleneck claim concrete and credible without requiring named attribution.
A developer in VS Code uses GitHub Copilot to check the blast radius of a change by querying the Context Lake for downstream dependencies, and also checks approved libraries and next tasks.
→ Demonstrates the Context Lake in day-to-day use — makes the abstract 'unified layer' concrete as a workflow.

Questions addressed

✅ Why do AI agents that work well for one power user fail to scale to a whole team or organization?
Three walls: security/approval friction, MCP tool-definition context bloat, and missing organizational knowledge that produces guessing instead of answers.
⭕ How do you keep organizational context in sync and consistently applied across an organization with hundreds or thousands of repos/services?
Proposed direction (a centrally modeled, integration-fed Context Lake with blueprints and relationships) but the piece admits 'building a Context Lake still takes effort' and describes self-discovery/auto-modeling as future work, not a solved problem.
⭕ Who is responsible for keeping the Context Lake's model of ownership, criticality, and relationships accurate as the organization changes?

Gaps

incompleteNo benchmarks, quantified before/after metrics, or named customer deployments substantiate the central claim that a Context Lake produces 'consistent, deterministic answers.' The only human testimony quoted (the financial-institution platform lead) is about GitHub Copilot/MCP approval friction, not about Context Lake efficacy — it doesn't actually support the product claim it's placed next to. Given the author is Port's own CEO writing about Port's own product on a trade outlet, this is closer to a well-argued product pitch than a substantiated case study.
Read next: Independent case studies or third-party evaluations of internal developer portals / context layers (Port, Backstage, Cortex) actually reducing agent error rates or on-call resolution time at named organizations.
incompleteThe piece never addresses who is accountable for keeping the Context Lake's model current, nor the organizational incentives for teams to maintain accurate ownership/dependency data once it's captured — the same maintenance problem it diagnoses in AGENTS.md is reproduced one layer up, unacknowledged.
Read next: extract-fighting-tool-sprawl-ai-registries (gap on tool-sprawl incentive structures) raises the identical unresolved question for a related architecture; extract-privilege-drift-multi-agent-systems raises it for permission inventories.
closed byHow Claude Code works in large codebases: Best practices and where to start — Names who is accountable (a DRI or dedicated 'agent manager' role, typically sitting under developer experience/productivity) and on what cadence (configuration review every three to six months, or after major model releases) — directly answering the accountability-and-maintenance-incentive question that gap raised.
incompleteCentralizing ownership, criticality, and dependency data for an entire organization into one queryable layer that both agents and humans access creates a high-value single target; the piece describes access controls inherited from human permissions but never discusses the security posture of the Context Lake itself as an attack surface (e.g., what happens if an agent's session is compromised — it now has structured, pre-digested access to the organization's ownership and criticality map, arguably a richer target than scattered raw APIs).