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 (updated July 2026): TMFNK/Enterprise-Context-Layer
  • README.md — overview and how to run
  • readme-for-humans.md — design rationale and deep background
  • readme-for-agents.md — full build spec with runnable Python (~70 KB)
  • AGENTS.md — harness grounding hook for Claude Code, Codex, Pi

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: The TMFNK implementation (updated 2026)

What follows is my extrapolation from Chen’s essay, now shipped as a full template repo. The conceptual core — synthesis over retrieval, empty seed file, folder-as-taxonomy, git push-rejection locking — is still his. The TMFNK/Enterprise-Context-Layer repo grew significantly in 2026: three audience-specific docs, a complete agent build spec (readme-for-agents.md), runnable ecl-runner.py worker and maintenance loops, lean SKILL.md workflows inspired by Waza, RBAC tiers, and drift logging. One way to implement the pattern, not the only way.

What’s in the repo now

Build path: clone the repo, open Claude Code / Codex / Pi, and run:

Read readme-for-agents.md fully. Then follow the Quick-Start Checklist at the bottom of that document.
Before you write any files, ask me the discovery questions in Step 1.

Expect 30–90 minutes of human interview (domains, sources, authority hierarchy) before any worker runs. Stop for human review of meta/system-prompt.md after Step 4. That file governs citations, routing rules, and what counts as a trusted source.

Operate path (after bootstrap):

# one worker to start
uv run ecl-runner.py worker --repo .

# scale out (git is the only coordinator)
for i in $(seq 1 5); do
  ECL_AGENT_ID="agent-$i" uv run ecl-runner.py worker --repo . &
done

# maintenance every 6 hours (cron-friendly)
uv run ecl-runner.py maintenance --repo .

Workers claim YAML tasks in tasks/ by writing a .LOCKED sidecar and pushing; rejected push means another agent won the race. Maintenance scans for stale last_verified dates, missing mapping-notes.md entries, unresolved conflicts, and outdated skills, then drops new tasks for workers.

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 (2026 layout)

Data Sources (Slack, Jira, Confluence, GitHub, Gong, CRM, code)
    │
    ▼
Worker Agents (parallel, stateless)
  1. Pull ECL; claim task via .LOCKED + git push
  2. Load matching domains/skills/{name}/SKILL.md if task type matches
  3. Read sources → synthesise with inline citations → document conflicts
  4. Append domains/{domain}/mapping-notes.md; commit; release task
    │
    ▼
Git Repo (single source of truth)
  AGENTS.md           ← harness auto-grounding
  meta/
    system-prompt.md
    how-to-get-accurate-information.md   ← starts empty; agents fill from experience
    domain-index.md                      ← domain → owner → primary sources
  tasks/              ← YAML queue + .LOCKED files
  domains/            ← cited topic files + mapping-notes per domain
    skills/           ← lean SKILL.md workflows (incident response, deals, etc.)
  sources/            ← read-only cited snapshots
  logs/               ← drift reports, agent error logs
    │
    ▼
Query (Claude Code, Pi, or rg + any LLM)
  → cite ECL paths; surface conflicts; obey routing notes

Topic files carry YAML front matter (last_verified, confidence, agent). Conflicts stay visible after resolution. Sensitive questions get routing notes, not answers.

4. Lean skills instead of a heavy skills framework

The repo’s third pattern is Lean Skills (Waza shape): one SKILL.md per workflow under domains/skills/, with trigger phrases in frontmatter. An agent loads the skill only when the task matches, follows it once, and does not auto-chain into a multi-skill pipeline.

Examples in the spec: incident response, closing a deal, customer data requests. Skills are versioned ECL content like anything else: citations, last_verified, re-verified when the process they describe drifts.

Superpowers-style discipline (brainstorm before synthesis, plan before harness changes) still fits as optional agent hygiene. The template itself does not require the Superpowers plugin; domains/skills/ is the built-in mechanism.

5. Recommended worker counts by phase

Tier models by task if you want to save tokens: frontier for synthesise and conflict-review, cheaper models for verify and backlink (Pi makes this a per-invocation setting).

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.
• Store workflows as lean SKILL.md files in domains/skills/, not only in Confluence. Process becomes citable, versioned, and subject to the same staleness checks as product docs.
• Use mapping-notes.md per domain to audit what the fleet actually did. Without it you only see Markdown output, not which sources were read or which conflicts were found.

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.
• Don’t mistake the ECL for finished. Target state is continuous maintenance, not a complete wiki. The maintenance loop and worker loop run indefinitely.
• Don’t skip human review of meta/system-prompt.md. The bootstrap agent will guess at sensitive topics and routing rules; you sign off once, then workers inherit that contract.
• Expect the query side to stay simple. Claude Code or Pi reading the repo is the v1 interface. rg plus an LLM is the lightweight alternative. Dedicated RAG is optional, not required.

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 (GPL-3.0):

• TMFNK/Enterprise-Context-Layer: Full template — readme-for-agents.md build spec, ecl-runner.py, task locking, staleness SLAs, RBAC tiers, lean skills, drift detection

Prior art (three patterns the repo synthesises):

• Chen, A. (2026). The Enterprise Context Layer — synthesis over retrieval; folder taxonomy; backlinks as context graph
• Carlini, N. (2026). Building a C Compiler with Parallel Claudes — git push-rejection task locking
• tw93. Waza — lean SKILL.md shape adapted as the ECL Lean Skills Pattern

Optional agent discipline:

• Vincent, J. (obra). Superpowers: Optional workflow discipline for coding agents building or extending the harness; not required by the template

Related TMFNK content:

• The Rise of Computer Use and Agentic Coworkers Computer-using agents need organizational memory; the ECL is one way to supply it.
• PipesHub: The Open Source Glean Alternative Retrieval stack for finding sources; the ECL synthesises on top of what retrieval surfaces.
• Obsidian Agent Client: Bring Claude Code Into Your Vault Same pattern of grounding agents in a Git-native knowledge base you control.

Complementary reads:

• Gupta, J. & Garg, A. (2025). AI’s Trillion-Dollar Opportunity: Context Graphs — decision traces as the asset; the ECL’s backlinks are a plain-text version
• Glean. https://www.glean.com — Chen used Glean search as a source API; retrieval and synthesis complement each other

Crepi il lupo! 🐺