Why I built ECL: synthesis over retrieval for enterprise knowledge

I have shipped enough RAG systems to know what they cannot do. They retrieve the closest matching document. They do not tell you that two documents disagree, that one of them is wrong, or that you should not be answering the question in the first place.

That gap is what I built Enterprise Context Layer (ECL) for. It is open source under GPL-3.0 and I have been running it on a client platform for the past few months. The architecture work that used to take months took days, and the answers the system gives are ones the client’s senior engineers actually trust.

This post is about why I built it, what it borrows from, and where the RAG pattern hits a wall.

Where RAG breaks

The RAG promise is straightforward. Chunk your documents, embed them, retrieve the top-k chunks for a query, hand them to an LLM. For “what does the policy say about X” it works fine. For most real semantic questions inside a company, it does not.

Take one I keep seeing in the wild: how long do we keep customer data after churn? The answer lives in four places. A legal policy document. An engineering deletion runbook. A Slack thread from eight months ago. The head of one senior engineer who has rebuilt the pipeline twice. They do not all agree.

A retrieval system returns the closest match. It does not flag the conflict, does not know which source has authority, and does not know that this question should probably be routed to the security team rather than answered to a customer at all. The retrieval layer treats every chunk as equally valid. That is the bug.

In my GDPR audit work I have watched this fail audits three times. Auditors do not want “the closest paragraph.” They want a cited, reasoned answer with a defensible chain back to the primary source. RAG cannot give them that without bolting on machinery that ends up looking suspiciously like ECL.

What ECL actually is

ECL is a git repo of markdown files. LLM agents read the company’s source systems (Slack, Jira, Confluence, code, calls) and write synthesised, cited knowledge into the repo. Every claim has an inline citation. Every conflict between sources is documented in place rather than silently picked. The git history is the audit trail.

The original idea is Andy Chen’s, from his Substack piece The Enterprise Context Layer. He built the first production version at Abnormal Security. The line from his post that stuck with me: retrieval and synthesis are different problems. Glean finds the best matching document. ECL builds the reasoning framework an expert uses, and tells you which questions should never be answered at all.

The version I open-sourced takes Andy’s pattern and combines it with two other ideas that solve problems his original write-up did not fully cover.

What I added

The C-Compiler pattern, for parallel agents. Nicholas Carlini’s Building a C Compiler with Parallel Claudes at Anthropic showed how to coordinate multiple Claude agents without a message broker. Each task is a YAML file. An agent claims a task by writing a .LOCKED sidecar and pushing to git. If the push is rejected, another agent got there first. Git’s push rejection is the mutex.

I wanted ECL to scale to ten or twenty workers running on whatever compute is cheap that day, without a central coordinator. The C-Compiler pattern gave me that for free. No Redis, no RabbitMQ, no Kubernetes operator. Just git.

Superpowers, for process discipline. Jesse Vincent’s Superpowers makes the case that agent quality is more about process than prompt. Before any non-trivial task, an agent loads a SKILL.md file that defines the mandatory workflow for that task type.

I store team workflows as skill files inside the ECL itself. The “how we close a deal” workflow lives in domains/skills/closing-a-deal/SKILL.md. It has citations, a last_verified date, and gets re-flagged when the underlying process changes. Process becomes a first-class, versioned, citable artifact. That is the part I think most enterprise teams will not see coming, and the part that has paid off most for the client I built this for.

Why the result holds up where RAG does not

A few things fall out of the design that I did not have to design for.

Conflicts are visible. When two sources disagree, the topic file documents both, cites both, and either resolves the conflict with a note or routes the question. Nothing is silently picked. This is what auditors want. It is also what senior engineers want, because it preserves the disagreement instead of pretending it did not exist.

Sensitive questions get routed, not answered. Each topic file can carry a routing note. “Do not answer data deletion timeline questions directly in customer-facing contexts. Route to the security team.” That instruction sits next to the cited answer, so any agent or human reading the file sees both. RAG has no equivalent. RAG always answers.

The system gets smarter from use. There is a file called meta/how-to-get-accurate-information.md. It starts empty. Agents add to it as they discover stale sources, unreliable APIs, and questions that should always be escalated. After a few hundred runs it becomes a dense, experience-grounded guide to the company’s specific information landscape. You do not pre-fill it. Invented wisdom is worse than none.

The audit trail is git. Every synthesis is a commit. Every conflict resolution is a commit. Every error is committed before the agent process can crash. I have watched this pay off in two audits already. Showing an auditor git log for a topic file is a different conversation than showing them a vector database.

What the client deployment looked like

Here’s what I can say:

• We replaced an early-stage RAG prototype with an ECL repo seeded over a 90-minute interview.
• Worker agents populated the first three domains in two days.
• Architecture decisions that previously needed three or four meetings to reach consensus on were resolved by reading the relevant topic file, because the conflict between two source systems was already documented and routed.
• The architecture phase finished in roughly half the time I had budgeted for it.

The headline result was that the team stopped re-litigating the same questions. The ECL made the company’s existing disagreements legible. That alone changed how the client’s engineers worked.

Is it production-ready

I would call it solid beta, edging into prod-ready. Andy ran the original at scale at Abnormal. The C-Compiler coordination pattern is tested at Anthropic. The Superpowers skill model has thousands of users. My contribution is the integration and the implementation template. That part has been running on a real client platform without me having to babysit it.

The repo is at github.com/TMFNK/Enterprise-Context-Layer. It is GPL-3.0. There are three README files, one for humans, one for agents, one for engineers who want the design rationale. If you give the agent README to Claude Code or CODEX and tell it to follow the Quick-Start Checklist, it will interview you and scaffold the repo for your company.

What I’d do differently next time

Three things.

One: write the routing rules before the agents run. I let the first client deployment populate domain files before we had a finalised list of sensitive topics. The agents wrote good content, but some of it should have been a routing note, not an answer. We had to go back and edit… Define what must not be answered before you let agents answer anything.

Two: keep how-to-get-accurate-information.md empty. I was tempted the first time to seed it with my guesses about which sources were reliable. Well, I was wrong about most of them. The file is more useful when it grows from real agent experience than from my upfront assumptions.

Three: budget for the interview. The 90-minute interview that bootstraps the ECL is essential. The quality of every later answer depends on the domain mapping and source authority hierarchy that come out of that conversation. Treat it like the discovery phase of an audit, not like onboarding paperwork.