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 platform for the past months. The architecture work that used to take months took days, and the answers the system gives are ones the people would 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 plain git.

A lean skills pattern, for process discipline. tw93’s Waza makes the case that agent quality is more about process than prompt, but with a sharper constraint than heavier frameworks impose: discipline should be scoped to exactly one workflow at a time. Each skill is a small, single-purpose SKILL.md with frontmatter naming its trigger phrases. An agent loads a skill only when a task matches, follows it as the mandatory workflow for that task, and stops. Skills do not chain into an automatic multi-step pipeline.

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, without the overhead of a heavier multi-skill system. That is the part I think most teams will not see coming, and the part that has a lot of value.

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 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, as 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 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:

Replaced an early-stage RAG prototype with an ECL repo seeded over a workshop.
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 lean skills pattern I borrowed from Waza is deliberately minimal, which makes it easy to audit and hard to misuse. My contribution is the integration and the implementation template. That part has been running on a real 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, CODEX or PI 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 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 workshop 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.

If your team keeps re-answering the same questions because the knowledge is scattered and contradictory, that is the problem ECL solves. Get in touch.