An AI coding agent that encounters a policy violation for the first time might need several attempts to understand and fix it. An AI coding agent that has seen the same violation three times before should not need to rediscover the solution. More broadly, an organization running AI agents across dozens of sessions should not be paying for agents to repeatedly re-read the same files, re-run the same failed commands, or re-generate the same remediation that did not work last time.
Code intelligence memory is the component of coding-ethos that addresses this problem. It transforms the evidence ledger from a compliance record into an actionable memory system that helps agents learn from the past and spend their attention (and token budget) on new problems.
What code intelligence memory is
The code-intelligence system in Ethosure is a local repository-scoped database that stores:
- Hook and lint traces: every enforcement event, including which policies fired, what disposition was applied, and what remediation guidance was provided.
- SARIF findings: code-scanning results from all managed tools, linked back to the policies and principles that own them.
- Remediation outcomes: what happened after a suggestion was made – was the issue fixed, did it repeat, was the fix attempted but unsuccessful?
- AST code chunks: structured code symbols (functions, classes, configuration entries) indexed from the repository using Tree-sitter, a fast code-parsing library.
- Proxy events: body-free records of provider calls, tool calls, file reads, and cache hits from the Agent Proxy.
- Session snapshots: a structured summary of each agent session – what was read, what was written, what was blocked, how many tokens were used.
The canonical store is a local DuckDB file at `.coding-ethos/code-intel.duckdb`. DuckDB is an embedded analytical database – it lives inside the project directory, runs without a server, and supports SQL queries. No data leaves the repository.
How agents use it
Agents interacting with Ethosure through the MCP server can query the code-intelligence store before taking action. Relevant MCP tools include:
- `code_intel_search`: hybrid search combining exact text matching and vector similarity over stored findings, remediations, and code chunks. An agent that encounters a specific error can search for prior instances of that error and retrieve the fixes that worked.
- `code_intel_answer`: retrieve cited evidence for a specific repository question, with retrieval quality reported separately from answer confidence.
- `semantic_search`: find relevant code chunks by symbol name or semantic description before resorting to broad file reads.
- `code_intel_health`: identify high-risk refactoring targets ranked by repeated failure evidence, code complexity, and git hotspot signals.
- `code_intel_skill_health`: report which repair playbooks are frequently used successfully, which are failing, and which are stale.
The practical effect: an agent that would otherwise re-read an entire module to find a function can instead call `semantic_search` and retrieve the relevant code chunk directly. An agent that would otherwise attempt the same failed repair strategy can retrieve the recorded outcome from prior sessions and try a different approach.
Repeated failures and token waste
The code-intelligence system explicitly tracks what coding-ethos calls “repeated failures” – situations where the same policy fires repeatedly for the same agent, file, or command pattern. The documentation describes the goal: “Let agents find the right code, understand prior failures, and choose the enforced repair path before they run broad shell commands or repeat failed edits.”
It also tracks which sessions repeatedly read the same files and which events exceeded token budgets or triggered output compression. This pattern data feeds the skill health reporting, which identifies which repair playbooks need improvement (because they lead to repeated failures) and which are working well.
From a cost perspective, every repeated failure represents wasted compute. An agent that makes the same mistake three times before getting it right has spent tokens on two failed attempts that better memory could have prevented. The code-intelligence system does not eliminate all failures, but it gives agents access to the institutional memory of prior sessions – so each session starts smarter than the last.
The storage architecture: DuckDB plus duckdb-vss
The store has two logical layers:
DuckDB is the canonical fact store. All traces, findings, remediation outcomes, AST code chunks, and graph edges live in DuckDB as structured tables. DuckDB supports full-text search (via term indexes) and SQL queries – meaning complex questions like “which policies fired most often in the last 30 days on files in `/src/api/`” are answerable with a single query.
duckdb-vss is the vector backend. For similarity search – finding code that is structurally similar to a proposed edit, or remediations that are semantically related to a current failure – the system uses duckdb-vss, a DuckDB extension for vector similarity search. Vectors are derived artifacts: they are computed from the canonical DuckDB data and can be rebuilt from scratch if needed. This is a critical design constraint: vectors are never the source of truth. They are an accelerator for search, with all authoritative facts in DuckDB.
The design explicitly rejects using a hosted vector database or requiring a network connection for code-intelligence queries. Everything runs locally in the repository directory.
What this means for your organization
For cost management: token waste from repeated failures, redundant file reads, and verbose tool output is a real operational expense for organizations running large agent fleets. The code-intelligence memory reduces that waste by giving agents structured access to what has already been tried and what worked.
For security and compliance: the remediation-outcome tracking creates a record of not just what was violated, but whether violations are being resolved. An organization can query: “Which policies consistently produce repeated violations that are never fixed?” – which is a signal that the policy may need better guidance, or that an agent’s workflow has a structural problem.
For engineering: the code health scoring, built from repeated-failure evidence, git hotspot signals, and structural complexity measures, gives engineering teams a prioritized, evidence-backed view of where technical debt is accumulating – not from a static snapshot, but from the continuous signal of what breaks in practice.
