AI Council and Serena: 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.

Serena is an MCP server and toolkit that gives an LLM agent IDE-like capabilities: finding and editing code at the symbol level rather than by lines. It relies on language servers (LSP) or a paid JetBrains plugin: 80+ language servers, name paths (Class/method), references, implementations, declarations, diagnostics, rename, safe delete, symbol-level edits with atomic writes. It offers two interfaces: individual MCP tools and a REPL (serena_repl with the facades s.lsp, s.edit, s.fs, s.mem, s.shell, s.cfg, s.ext, s.jb). It also has Markdown memory with mem: links, client hooks, a CLI, a dashboard and a JetBrains plugin. One active project per process; client-agnostic: Claude Code, Codex, Copilot CLI, JetBrains AI Assistant, Claude Desktop and others. License: GPL-3.0-or-later, with src/solidlsp under MIT.

Of all the projects we compare, Serena is the closest to Council in goal (giving the agent an understanding of code), but it gets there differently: precise symbols through a language server instead of a project graph. Serena doesn't keep knowledge, rules, review or tasks. It is a precision layer over the code, and Council complements it with a graph, knowledge and rules.

1. Understanding the code

2. Knowledge and rules

3. Requirements and tasks

4. Verification and models

5. Platform

Bottom line

Serena is the closest to Council in goal (giving the agent an understanding of code), but it gets there differently: precise symbols through a language server instead of a project graph. It doesn't compete with Council's knowledge, rules, review and tasks. It is a precision layer over the code, and Council complements it with a graph, knowledge and rules.

Where Serena is stronger:

• precise symbols, references, implementations, declarations, diagnostics, rename, safe delete;
• 80+ language servers;
• symbol-level edits: replace a symbol body, insert before/after, multi-file replace with occurrence ids, atomic writes;
• client-agnostic MCP: Claude Code, Codex, Copilot CLI, JetBrains AI Assistant, Claude Desktop; serena setup and per-client contexts;
• the remind hook, which catches the agent drifting toward grep/read and steers it back to LSP symbol tools, plus plan mode and auto-approve. Council's hooks steer the agent toward the knowledge base and the graph, not toward LSP;
• local, simple, open source (GPL/MIT), installs from PyPI/uvx.

Where Council is stronger:

• Sees the whole project, not just one symbol. 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. Serena is more precise at the LSP symbol level; Council sees the project's architecture, relationships and quality.
• Knowledge anchored to code and branches. An entry lives on a branch, reaches the agent when it touches the file, and goes back for re-checking when the code under it changes; the reviewer must provide a quote. Serena keeps memory in Markdown files with mem: links, but they are not anchored to code positions or checked against the code.
• Conventions are authoritative, checked rules. Three scopes (entities, paths, project), MUST/SHOULD, states, checks before an edit and against the diff. Hooks deliver rules with every message and file context on Read/Edit/Bash; the KB gate blocks reading code until the agent has queried the knowledge base. Serena steers the agent toward LSP, but has no team rules.
• Code and knowledge review as a service. A verdict for every file, a second pass, publishing to the MR without duplicates; a separate knowledge review with quotes and calibration. Serena provides symbol reads and edits, not a review service.
• Tasks on a VM, tickets, MRs, team. A task in a sysbox container lives for days and a person drives it from the UI; tickets, requirements tracing, companies, roles and licensing. Serena is a local tool for a single developer.
• Shared graph across repositories, architecture history, SonarQube. architecture_as_of, versioned edges, an external analyzer; ask_question returns excerpts with FQNs. Serena works with one active project through a language server.
• Observability and self-healing. Telemetry for every MCP call and hook without PII, about 22 Prometheus rules, System Health, tracing; Temporal reconciliation, orphaned data cleanup, backups with restore checks. Serena has logs and LSP diagnostics, but not per-call platform observability.

Can they work together? Yes, and they pair naturally: both are MCP servers, and one agent can connect to both. Serena provides precise symbol reads and edits; Council provides the graph, knowledge, rules and review. For example, Council finds the module and related knowledge, Serena reads and edits the exact symbol, and Council checks the diff against the rules and reviews it. They overlap on symbol and reference lookup: Council has find_usages, find_path, search_code; Serena has find_symbol, find_referencing_symbols. Serena is more precise at the LSP level, Council covers more of the project and its relationships. There is no built-in integration: for Council to deliver rules into Serena's context you need a shared layer, or both MCP servers connected to the same client.