The Enterprise Context Layer: Synthesis Over Retrieval

⬅️ Back to Tutorials

Article information

• Original article: https://andychen32.substack.com/p/the-enterprise-context-layer
• TMFNK implementation: TMFNK/Enterprise-Context-Layer

Andy Chen spent six months building a GTM question-answering bot at Abnormal Security before he realized the problem wasn’t retrieval. Glean (arguably the best document-retrieval system in the world) still couldn’t answer “how long do we keep data after a customer churns?” correctly. Because the right answer isn’t in any document. It’s: don’t answer this yourself, route it to the security team.

His solution: skip the ontology, the knowledge graph, and the semantic layer. Give twenty parallel LLM agents access to a Git repo and every primary source the company has, and tell them to write cited Markdown. Two days later: 6,000 commits, 1,020 files, 11 domains; 100% of every product, process, team, compliance framework, and competitive dynamic mapped, cross-referenced, and verified.

One-sentence takeaway

The Enterprise Context Layer solves synthesis over retrieval by encoding institutional reasoning frameworks as cited, conflict-aware Markdown in a Git repository, autonomously maintained by parallel agents that learn question routing.

Part 1: What Andy Chen built

The problem

Chen’s original task was deceptively simple: build a bot that helps GTM reps answer customer questions accurately. Questions like “Will X feature be available next quarter?”, “How are you different from Y competitor?”, “What’s your data retention policy?”

Four things have to go right simultaneously for an AI to answer any of these correctly:

Glean, which Chen praises explicitly as “really really good”, solves the first dimension through context graphs, trace learning, and per-customer embedding models. What it doesn’t do is synthesize organizational context: the judgment calls, the institutional memory, the “this question is actually dangerous and you shouldn’t answer it” knowledge that lives in Slack threads, Gong call recordings, and engineers’ heads.

The difference is noticeable. Ask “when does customer data get deleted after churn?” and a retrieval system returns the closest policy document. Chen’s system returns: “don’t answer unless you absolutely know what you are doing; this is a high-risk question that should be escalated immediately to the legal team, and if you’re not sure, route to the security team. Here’s why, and here are three cases where reps got this wrong.”

The implementation

Chen’s system is built on two ideas and one architectural trick.

Synthesis over retrieval

The ECL is not a search index. It’s a Git repository of Markdown files that encode how the company actually works, the reasoning frameworks experts use, not just the raw facts they cite. Every file is a synthesis of primary sources: source code, Slack threads, Jira tickets, Gong transcripts, policy docs, ADRs. Every claim carries an inline citation. If an agent can’t cite it, it doesn’t write it.

Document the conflict, not the winner

When sources disagree, the ECL doesn’t pick a side. It documents both, names the conflict explicitly, and records who should resolve it. A documented conflict is more useful than a silently chosen winner because it tells downstream agents and humans exactly why escalation is required.

File-based distributed locking

Chen adapted a task-locking pattern from Anthropic’s C-Compiler project (Nicholas Carlini, Feb 2026), in which parallel Claude agents coordinate through lock files in a shared Git repo, with no external dependencies: no message broker, no coordinator service, no database. In Chen’s adaptation, a maintenance agent continuously scans the ECL for gaps and staleness, writing task files into a tasks/ directory. Worker agents claim tasks by writing a lock file and pushing to main; Git’s push-rejection means only one agent gets a given task. The agent executes, writes or updates ECL files with citations, deletes the task and lock, commits, and pushes. Then it picks up the next task.

Twenty workers. Two days. 6,000 commits.

Infrastructure:

• ~1,000 lines of Python for the harness
• Modal sandbox for compute (plain bash access to the Git repo)
• Glean search API + in-house retrieval for source access (Slack, Jira, Gong, etc.)
• Git as the single source of truth; no message queue, no external database, no vector store

The prompt (Chen’s actual words):

You are an Enterprise Context Layer (ECL) Agent that builds and maintains internal mental models, the reasoning frameworks our experts use, not just raw facts. […] The ECL is not built for readability. It’s built for traceability and verifiability. Every claim, every statement, soft or hard, has to have an inline citation for the source(s) that it directly draws from.

That’s it. The rest emerges.

What emerged

The artifacts Chen describes as “otherwise impossible to produce manually”:

End-to-end customer journey

From first sales contact through deployment, onboarding, renewal, and churn, all annotated with handoff points, common failure modes, and playbooks. Cross-referenced against real support cases and Gong calls.

Detection model lifecycle

A document bridging engineering, support, and customer success into one coherent mental model that previously lived only in a few engineers’ heads. Maps all causes of detection behavior change to customer-visible impact, with Databricks dashboard links and real incident case studies.

Battle cards with closed evidence loops

A Gong call where a competitive claim surfaced, correlated against actual product capabilities, linked to the Salesforce case showing how the deal ended, tied to field team Slack discussion on what messaging worked.

Feature flag inventory

Every flag across proto files, each cited back to specific line numbers in source code, with GovCloud overrides and deprecation status. No human has ever maintained something like this; it would be out of date the moment you finished writing it.

Then there’s the routing behavior. When asked about data retention timelines, the system correctly declines to answer and routes to the security team. This behavior emerged from the citation architecture, not from a hard-coded rule.

Core insights

1. The taxonomy is the folder structure; the context graph is the backlinks.

No ontology engine. No graph database. No semantic layer. Plain folders and plain Markdown. When an agent discovers that data retention questions connect to GTM and privacy and engineering, it writes a backlink in each file, and explains why. Over thousands of runs, backlinks accumulate into a navigable web of cross-domain understanding. The context graph builds itself.

2. Every claim needs a citation; unverified claims are forbidden.

The single most important writing rule. Unsourced assertions are more dangerous than gaps because they create false confidence. This rule is also what makes the system self-correcting: if a claim is wrong, the next agent can find the source, compare, and correct it. Remove citations and you have a confident, uncorrectable error machine.

3. Document the conflict, not the winner.

Two sources disagreeing is more useful information than a silently chosen winner. The ECL’s job is to surface why something requires escalation, not to pretend the ambiguity doesn’t exist.

4. Architecture claims are durable; status claims are ephemeral.

Chen’s agents generalized this from experience: “We use API-based integration” is true for years. “Feature X is coming soon” can be unreliable within days. “This PM announces features before they ship, so we don’t commit to customers” is tribal knowledge that retrieval will never surface. Different claims need different verification cadences.

5. Three independent sources agreeing is the threshold for high confidence.

But five Slack messages from the same channel are one data point, not five. Source diversity matters more than source volume.

6. Meta-awareness emerges from seed files, not prompts.

This is the subtlest insight in the essay. Chen created meta/how-to-get-accurate-information.md with a single line of instruction: “put in here synthesis of how to use tools to cite right sources, what sources or things tend to be out of date.” The agents filled out everything else completely from accumulated experience, over thousands of runs. No prompt changes. No architecture changes. Just a seed and a directory. The system learned which Confluence pages are perpetually stale, which Slack channels are noise vs. signal, which source pairs consistently conflict. Pre-filling that file with expert knowledge would have encoded the expert’s biases. Leaving it empty let the agents discover the truth.

Broader connections

Context layers as practice, not product

Chen’s closing argument is that the ECL pattern is closer to DevOps than to Salesforce or Databricks. It’s something most companies will build in-house rather than buy. The moat is not the tooling. It’s the accumulated, verified, living body of institutional knowledge. That means the company that starts building its context layer today compounds its advantage over time in a way that can’t be replicated by a vendor.

Three layers of context for AI-native companies

Chen sketches a hierarchy that deserves its own treatment: (1) enterprise context layer, company-wide knowledge; (2) team or org context layer, function-specific playbooks; (3) personal context layer, individual preferences and style. Each layer sits above retrieval and below task execution. Agents read from the layer appropriate to the task; the layers accumulate independently and at different rates.

The ECL grounds computer-using agents

The a16z thesis on computer-using agents (The Rise of Computer Use and Agentic Coworkers) describes agents that navigate browsers, desktops, and legacy enterprise software. An agent that can navigate SAP is useful. One that knows when to navigate SAP, which queries require escalation, and who owns what is transformative. The ECL is the organizational memory those agents need to act correctly, not just efficiently.

Foundation Capital’s context graph thesis

Jaya Gupta and Ashu Garg’s December 2025 piece "AI's Trillion-Dollar Opportunity: Context Graphs" argues that the next trillion-dollar platforms will be built not on systems of record (Salesforce, Workday, SAP) but on systems that capture decision traces: the why behind actions, not just the what. The ECL is a working implementation of this thesis at the level of a single company. The folder structure is the taxonomy. The backlinks are the decision trace. The how-to-get-accurate-information.md file is the accumulated judgment.

Part 2: My implementation notes

What follows is my own extrapolation from Chen’s essay. The conceptual core: synthesis over retrieval, empty seed file, folder-as-taxonomy, is his. The 10-step build process, task schema, staleness tables, and repository structure in the TMFNK/Enterprise-Context-Layer repository are my interpretation: one way to implement the pattern, not the only way.

Frameworks and models

1. Source authority hierarchy

Not all sources are equally trustworthy. The table below is what I distilled from Chen’s essay and from reading the Anthropic C-Compiler post on how agents handle conflicting signals:

Operational reality beats documented ideal. Source code shows what the system does. Confluence shows what someone intended. When they conflict, the code is right and the doc is stale.

2. Staleness by claim type

Different facts have different half-lives. The ECL must encode this to avoid treating a feature flag inventory the same as a founding architecture decision:

3. The ECL architecture

Data Sources (Slack, Jira, GitHub, Confluence, Salesforce, Gong, Code)
    │
    ▼
Worker Agents (parallel)
  1. Pull latest ECL from git
  2. Claim a task (write lock file → push to main; retry if push fails)
  3. Read sources → synthesise → write ECL files with inline citations
  4. Document conflicts; add cross-domain backlinks
  5. Delete task + lock; commit; push
    │
    ▼
Git Repo (single source of truth)
  meta/              ← system-prompt.md, how-to-get-accurate-information.md (start empty)
  tasks/             ← YAML task queue + .LOCKED files
  domains/           ← one folder per knowledge domain
    product/
    engineering/
    gtm/
    legal/
    ...
  sources/           ← cited source snapshots (read-only)
  logs/              ← drift reports, error logs
    │
    ▼
Query Interface (Claude Code reading ECL files directly)

4. Adding Superpowers as an agent discipline layer

Jesse Vincent’s Superpowers framework (a skills-based workflow methodology for coding agents) is a natural complement to the ECL. Chen’s essay describes what agents should produce; Superpowers enforces how they should work while producing it.

My own extension in TMFNK/Enterprise-Context-Layer adds Superpowers integration to the ECL pattern. The canonical Superpowers workflow (brainstorming → using-git-worktrees → writing-plans → subagent-driven-development) maps well onto the ECL’s task lifecycle:

Skills turn good intentions into enforced workflows. An ECL agent with Superpowers doesn’t just intend to check for conflicts before writing; it’s required to, by the skill that activates before it writes anything.

A second integration worth doing: store team workflows as SKILL.md files inside the ECL’s domains/ folders. Incident response, deal-closing, customer data requests, all as skills with citations back to retrospective docs and real case studies. This makes process a first-class, citable artifact in the knowledge layer rather than a document that drifts in Confluence.

Applications

What to do:

• Start with one hard question, not all knowledge. Chen’s original scope was a GTM bot answering five types of questions. The ECL grew from there. Pick the question that causes the most customer-facing failures and let the system expand from it. Don’t try to map the whole company on day one.
• Seed with an empty template, not expert content. The how-to-get-accurate-information.md file should start with one line of instruction. If you pre-fill it with what you know, you encode your biases and blind spots. Let agents build it bottom-up from accumulated experience.
• Route, don’t answer, for sensitive questions. Build routing rules as first-class artifacts. Which questions should never be answered by reps? Which require legal review? Which require escalation? These should be documented in the ECL before anything else.
• Cross-reference across domains deliberately. When an agent discovers a connection between data retention policy, privacy team, and support case history, it should write that link explicitly in both files, with an explanation. Cross-domain understanding that stays implicit in one agent’s context vanishes the next time a different agent reads the file.
• Use the C-Compiler locking pattern for any multi-agent setup. Git push-rejection as a distributed mutex. No coordinator, no message broker. This works for 1 worker or 20 and adds near-zero infrastructure complexity.

What to avoid:

• Don’t confuse the ECL with a better wiki. Wikis contain documents. The ECL contains reasoning frameworks. If your “ECL” is organized Confluence pages with better tagging, you’ve built a taxonomy, not a context layer.
• Don’t skip the citation rule. This is the one rule that can’t bend. Without inline citations, agents produce confident, untraceable errors that the next agent will propagate rather than correct. The self-correcting property depends entirely on traceability.
• Don’t pre-fill seed files with expert knowledge. The seed file’s value is precisely that it’s empty; agents fill it with what they actually discover, not what an expert assumes they’ll discover.
• Don’t start too big. One domain, one worker, Claude Code as the query interface. Get that working first. The impressive-looking 1,020-file repo took two days because the pattern was right, not because someone planned 1,020 files.
• Expect the query side to be immature. Chen himself says his current approach, asking Claude Code questions over the file system, is not optimized for retrieval. Building a better query interface is on his roadmap. Don’t mistake “the build side works well” for “the query side is solved.”

References

Primary sources:

• Chen, A. (2026). “The Enterprise Context Layer.” Andy Chen’s Substack. https://andychen32.substack.com/p/the-enterprise-context-layer
• Carlini, N. (2026). “Building a C Compiler with a Team of Parallel Claudes.” Anthropic Engineering Blog. https://www.anthropic.com/engineering/building-c-compiler (Source of the file-based distributed locking pattern.)

TMFNK implementation:

• TMFNK/Enterprise-Context-Layer: Generic ECL implementation template (10-step build guide, C-Compiler-inspired task system, citation rules, staleness SLAs, RBAC, drift detection, Superpowers integration notes)

Skills framework:

• Vincent, J. (obra). Superpowers: Agentic skills framework. Canonical workflow: brainstorming → using-git-worktrees → writing-plans → subagent-driven-development. Available via Claude Code plugin marketplace: /plugin install superpowers@claude-plugins-official

Related TMFNK articles:

• The Rise of Computer Use and Agentic Coworkers: a16z thesis on computer-using agents; the ECL provides the contextual grounding these agents need to operate correctly in enterprise environments

Complementary reads:

• Gupta, J. & Garg, A. (2025). “AI’s Trillion-Dollar Opportunity: Context Graphs.” Foundation Capital. https://foundationcapital.com/ideas/context-graphs-ais-trillion-dollar-opportunity (Context graphs as living records of decision traces. This is the theoretical framing the ECL implements in practice.)
• Keenan, F. & Twomey, C. Enterprise Context Management Substack. (Enterprise context management as the layer between AI and enterprise reality.)
• Glean. https://www.glean.com (Industry-leading retrieval system; excellent at document finding. Chen uses Glean search API as a source for his ECL agents. Note that retrieval and synthesis are complementary, not competing.)
• PipesHub: The Open Source Glean Alternative: Open-source, self-hosted alternative to Glean for enterprise search and AI agents.

Crepi il lupo! 🐺