AI Council and agent-memory-mcp: what each one does

In short

AI Council is a platform for development teams, cloud or self-hosted. It parses your repositories into a code graph on its own: stack, structure, dependencies and cycles, calls, data layer, architecture, DDD, patterns, style, code smells and ISO 25010 quality. On top of the graph sits the project knowledge base: decisions, notes, diagrams and changelogs. Each entry is anchored to a place in the code and to a branch, and reaches the agent when it touches that file. Conventions live separately: rules at three scopes (code entities, paths, the whole project) with MUST/SHOULD levels, states, and checks before an edit and against the diff. Around this sit review with publishing to the MR, tickets, tasks, and companies with roles and licensing. Static analysis does not use a model, but without a model that is all you get: review, knowledge review, AI chat and workspaces run through a host worker, a bridge and the vendor's CLI/OAuth. The model lives on the host, not inside the Council stack.

There are two ways to work with Council. On a developer's machine, Claude Code or Codex connects to it via MCP and hooks: project rules arrive with every message, file context on Read/Edit/Bash, and a checklist at the end of the turn. In a workspace, the task runs on a VM in an isolated sysbox container, can live for days, and a person drives it from the web UI: from analysis and diff to commit, push and MR.

agent-memory-mcp is a single Go binary that works as both an MCP server and a CLI. It gives the agent three things: typed long-term memory in SQLite, RAG search over the repository's documents (docs, ADRs, RFCs, changelogs, runbooks, postmortems, CI, Helm, Terraform, K8s), and a knowledge maintenance layer: session consolidation, steward scans, verification, a canonical layer, a temporal model and a knowledge graph. 50 MCP tools, or 8 when grouped; three Claude Code hooks; a session tracker; two SQLite files and zero external databases. MIT.

Of the projects we compared, it is the closest to Council's knowledge layer: it has trust, a canonical layer, a review queue, drift detection, verification, temporal validity and knowledge maintenance. But it is a project knowledge bank, not a code understanding tool: it doesn't build a symbol graph, keep conventions, review diffs, run tasks on a VM, or know about companies and roles.

1. Understanding the code

2. Knowledge and rules

3. Requirements and tasks

4. Verification and models

5. Platform

Bottom line

Of the projects we compared, agent-memory-mcp is the closest to Council's knowledge layer. It has things most local tools don't: trust, a canonical layer with a provenance gate, a review queue, a steward with scanners and an inbox, a drift scan, verification, temporal validity, sedimentation and a knowledge graph. But it doesn't understand code: there is no symbol graph, RAG reads documentation and configs, there are no conventions or diff review, and no tasks on a VM or team model.

Where agent-memory-mcp is stronger:

• a project knowledge bank with engineering types, trust metadata, a canonical layer and a project bank;
• a review queue stored as memory entries rather than a separate table; resolve_review_item and steward_inbox_resolve;
• a steward covering duplicates, conflicts, structural contradictions, stale entries, expired working entries, canonical health, drift and verification candidates;
• a temporal model: valid_from/valid_until, superseded_by, replaces, recall_as_of, knowledge_timeline;
• sedimentation from surface to episodic to semantic to character;
• a triple graph and multihop recall;
• session consolidation (extract, plan, apply) without LLM rewriting, with Jaccard dedup and a review gate;
• RAG over documents and configs: semantic + BM25, weighted fusion/RRF, a per-document cap, ExpandSection, source-aware boosts;
• 50 MCP tools and an 8-tool grouped mode;
• three Claude Code hooks and a session tracker;
• local-first with two SQLite files, a single Go binary, MIT;
• measured defaults and 692 tests.

Where Council is stronger:

• Understands code, not just text about it. The L0–L10 graph covers stack, structure, dependencies and cycles, calls, data, architecture and forbidden dependencies, patterns, style, DDD, co-change, code smells, ISO 25010 and diagrams. Static analysis doesn't call a model or spend tokens. agent-memory reads documents and configs, but doesn't build a symbol graph or see the architecture.
• Knowledge anchored to a code position and a branch. An entry lives on a branch and reaches the agent when it touches the file. When the code under it changes, it goes back for re-checking: the reviewer must provide a quote, and the outcome is a label. On branch merge, entries move with the code; merge_knowledge/supersede_knowledge preserve history. agent-memory has trust metadata and temporal validity, but no anchoring to code positions and no check against the code.
• Conventions are authoritative rules, not observed norms. Three scopes: code entities, paths (including files that don't exist yet) and the whole project; MUST/SHOULD, draft, retired and deleted states; checks before an edit and against the diff. Hooks deliver rules with every message and file context on Read/Edit/Bash, and the KB gate keeps the agent from reading code until it has queried the knowledge base. This is enforcement, not an entry in a bank.
• Code and knowledge review as a separate service. A verdict for every file, a second pass, publishing to the MR without duplicates. Knowledge review checks a claim against its AST position, requires a verbatim quote, and keeps a log and calibration. agent-memory has a review queue for entries, but no diff review and no publishing to MRs.
• Tasks run on a VM in a sysbox container. They last for days and a person drives them from the web UI: analysis, diff, commit, push, MR. One-time push credentials, isolation, RBAC and SSRF protection. agent-memory is a local knowledge bank without tasks or a workspace.
• A platform around the code. Jira/GitHub/Redmine tickets parsed into knowledge with graph-based advice; tracing tests to requirements; companies, members, roles (including per project), permissions; license and seats; self-hosted (including air-gapped) or SaaS. agent-memory doesn't have this layer.
• Shared graph across repositories and architecture history. architecture_as_of shows the architecture as of a date, edges are versioned after every run, and SonarQube findings are imported as an external analyzer. agent-memory stores knowledge, not the project's architecture.
• Observability and self-healing. Telemetry for every MCP call and hook without PII, with repeated agent searches visible as a signal of a poor first answer; about 22 Prometheus rules with tests, System Health, tracing; Temporal reconciliation, orphaned data cleanup, nightly backup with restore checks, and retention. A local knowledge bank doesn't need this; a team platform does.
• The model isn't a key inside the stack. Static analysis runs without a model; review, knowledge review, AI chat and workspaces go through the host worker, bridge and vendor CLI/OAuth. This doesn't mean Council works without a model: without one, only static analysis remains. But keys and quotas aren't stored in Council.

Can they work together? Yes, they are different layers. agent-memory-mcp is a project knowledge bank and document RAG for the agent; Council is the code graph, conventions, review and tasks. Both are MCP servers, so one agent can connect to both. They overlap on knowledge and the review queue: agent-memory stores decisions, runbooks and session lessons; Council stores knowledge anchored to code positions and team rules. There is no built-in integration. A practical setup: agent-memory for "what we know and what we discussed", Council for "where it is in the code, which rules apply, and what review says". Don't run the same review queue in both systems: each one should own its own subject.