Made on
Tilda
AI Council is a self-hosted platform for engineering teams. It parses your repositories into a code graph on its own: stack, structure, dependencies and cycles, calls, data, architecture, DDD, patterns, style, code smells, and quality per ISO 25010. On top of the graph sits the project knowledge base: decisions, notes, diagrams, and changelogs. Each entry is tied to a place in the code and to a branch, and reaches the agent when it touches the relevant file. Conventions live separately. They are rules with three scopes (code entities, paths, and the whole project), with MUST/SHOULD levels, states, and checks before an edit and on the diff. Around this you get review with publishing to the MR, tickets, tasks, and companies with roles and a license. Static code 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 CLI/OAuth. The model lives on the host, not in the Council stack.
You can work with Council in two ways. 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. In a workspace, a task runs on a VM in an isolated sysbox container, lives for days, and a person drives it from the web UI, from analysis and diff to commit, push, and MR.
graphify is a local Python CLI tool (the PyPI package is graphifyy). It builds a knowledge graph from a project folder. The graph covers code (about 50 languages and formats) and, with the help of a model, also documents, PDFs, images, video, and audio. The graph is served to the agent through an MCP server, a skill and rules for ~16 agents, and Claude Code hooks. It is stored in graphify-out/ files on the developer's machine. It is single-user.
Of all the tools we compare, it is the closest to Council in kind: both build a project graph and feed it to the agent via MCP and hooks. The difference is in the depth of analysis and in what is built around the graph.
| AI Council | graphify | |
|---|---|---|
| Who builds the graph | The Council server, per project | A CLI on the developer's machine (graphify extract, update); output is files in graphify-out/ |
| When it updates | On project creation, on push to main (polling), on demand, nightly. After every file edit by the agent (Write/Edit), the file and its dependents are recomputed | Git hooks post-commit, post-checkout, post-merge, post-rewrite rebuild the graph in the background; watch mode; update. Includes a git merge driver for the graph file |
| Languages | Python, PHP, TypeScript, JavaScript, Java, Kotlin, C#, C, C++, with full layer analysis | About 50 languages and formats: dedicated extractors plus a generic fallback engine. Includes COBOL, Fortran, Pascal, Verilog, Solidity, Terraform, SQL, PowerShell. Accepts SCIP indexes as a precise symbol source |
| Beyond code | Google Drive documents, into the knowledge base | A model extracts nodes and edges from Markdown, HTML, text, PDFs, images (vision), docx/xlsx. Transcribes audio and video. Reads Postgres schemas, Cargo, dependency manifests, Google Workspace; accepts data from MCP |
| What it extracts | Layers L0–L10: stack and framework guides; structure; dependencies and cycles; metrics and call graph; data layer (ORM, DDL); architecture style and forbidden dependencies; design patterns; code style; DDD (bounded contexts via Leiden, aggregates, events); file coupling from git co-changes; code smells; quality per ISO 25010 and fitness functions; diagrams | Entities and edges (imports, calls, definitions, inheritance), hyperedges; communities (clustering, with community labels from a model); "god nodes"; metrics. No architecture layers, DDD, code smells, or quality scoring |
| Duplicate entities | — | Duplicate merging: MinHash, with a model when needed |
| Multiple repositories | A project spanning several repositories with a shared graph | Global graph: project graphs are merged, cross-repository calls are computed |
| External analyzers | SonarQube: imports its findings; own scanner (text-based languages, JVM, .NET, .NET Framework on Windows) | — |
| History | Edges are versioned after every run; architecture_as_of shows the architecture as of a date | The graph reflects the current state; affected shows what a change touches |
| Graph queries | Semantic and regex search, find_usages, find_path, dependency graph, similar implementations; ask_question returns excerpts from the knowledge base without a model paraphrase | query: seed nodes from the words in the question → BFS/DFS traversal → subgraph as text within a token budget (no model). Plus path, explain, god-nodes, affected |
| AI Council | graphify | |
|---|---|---|
| Knowledge base | Decisions, notes, Mermaid diagrams, changelogs. Each entry is tied to code and reaches the agent when it touches the relevant file | No separate knowledge base: the graph plus "working memory". save-result stores questions and answers with an outcome rating (useful / dead end / fixed); reflect condenses them into LESSONS.md, which the agent reads at the start of the next session |
| Freshness | An entry holds its place in the code on its branch and goes back for re-checking when the code under it changes, the entry itself changes, a similar entry appears, or the branch is merged. A read-only reviewer model must cite a verbatim quote; the result is a label, the text is not changed | The graph is rebuilt from code; memory is not re-checked against code |
| Branches | Knowledge and the graph are stored per branch; the agent sees its branch, the parent, and what was merged; on merge, entries move over | On branch switch, a hook rebuilds the graph; there is one graph for the current state |
| Rules | Conventions of three kinds: for code entities, for paths (they apply even to a file not yet created), for the whole project. MUST/SHOULD levels. Checks before an edit and on the diff | None. It installs its own "how to use the graph" rules into the agent (CLAUDE.md / AGENTS.md / GEMINI.md) |
| How it reaches the agent | Claude Code hooks: project rules with every user message; a broad channel before an action; file context on every Read/Edit/Bash; a checklist at the end of the turn. KB gate: code can't be opened until the agent has queried the knowledge base; only a person can lift the gate | A skill and persistent rules for ~16 agents: Claude Code, Codex, Cursor, Copilot, Gemini, OpenCode, Kiro, Aider, Amp, Kilo, Trae, Droid, Hermes, Antigravity, Pi, Kimi. Claude Code hooks on search (Grep, grep in Bash) and Read suggest "ask graphify query". In strict mode, Read of a file is blocked, and the agent gets a summary of the file from the graph (functions with line numbers) and a hint to use graphify explain. For Gemini, a BeforeTool hook |
| MCP | About 60 tools; profiles; per-session modes; XML responses with size limits | 10 tools: query_graph, get_node, get_neighbors, get_community, god_nodes, graph_stats, shortest_path, list_prs, get_pr_impact, triage_prs; stdio and streamable HTTP |
| Portability | Bundle export and import of knowledge, copying between projects | Graph files; merge-graphs; export |
| AI Council | graphify | |
|---|---|---|
| Requirements | Traceability from tests to requirements via tags: coverage and gaps; "no test" is a tri-state, not requirements management | — |
| Tickets | Jira, GitHub Issues, Redmine: reading, parsing into knowledge, advice on a ticket from the graph | — |
| Working on your own machine | The agent is the developer's Claude Code; Council supplies context and rules; review of the local diff, diff breakdown, diff check against the rules | The only mode |
| Workspace | Tasks on a VM in a sysbox container, living for days; a person drives the agent from the UI chat; a mentor; diff → commit → push → MR | — |
| PR | Review with publishing to the MR (GitHub, GitLab, Bitbucket) | Via gh: PR list, PR impact on the graph, PR sorting (triage) |
| AI Council | graphify | |
|---|---|---|
| Code review | A separate service: looks at what changed, a verdict per file, a second pass, publishing to the MR without duplicates | None; it estimates a PR's impact on the graph |
| Models | A model is required: on the host, two processes work through the vendor's OAuth, the AI chat and six background jobs (review, knowledge review, ticket parsing, and others). Without a model, only static code analysis remains. | Needs your own key (Anthropic, OpenAI, Gemini, DeepSeek, Moonshot/Kimi, Azure OpenAI, Bedrock), or local Ollama, or the Claude CLI. Includes a cost estimate. The model can be turned off (GRAPHIFY_BACKEND=none), in which case only code parsing remains |
| AI Council | graphify | |
|---|---|---|
| Users | Companies → members → roles → permissions; data is separated by company; license | One person, locally |
| Interface | About 50 pages of web UI: code, graph, branches, quality, rules, review, knowledge, tickets, tasks, MCP Live, administration, System Health | Interactive graph HTML, HTML for the call graph and project tree, a local web server (serve), wiki, text report, export to Obsidian and Neo4j |
| Monitoring | Telemetry for every MCP call and hook, Prometheus rules with tests, System Health | diagnose, benchmark, cache-check |
| Storage | Neo4j, Qdrant, PostgreSQL per service, Temporal, NATS, Redis | Files in graphify-out/ (graph, cache, memory); in-memory graph (networkx); Neo4j only as an export target |
| Security | Task isolation, one-time credentials, permission checks in a single gateway, SSRF protection | A dedicated module guarding against SSRF and escaping the project root; external content and web output go through it |
| Delivery | A distribution for self-hosted installation, or cloud; on the developer's machine, MCP and hooks | pip install graphifyy, then graphify install for the agent you use |
graphify is the closest to Council in concept: a project graph fed to the agent via MCP and hooks. Like Council, it nudges the agent toward the graph instead of grep and Read, and in strict mode it blocks Read, which is effectively the same gate.
These are different axes. The number of agent hosts measures install reach, and the number of layers measures depth of analysis. You can't add them into one score.
Where graphify is stronger:
Where Council is stronger:
architecture_as_of shows the architecture as of a date, and edges are versioned after every run; SonarQube is pulled in as an external analyzer. graphify builds project graphs but does not keep a history of architecture snapshots.Connect a real repository and see how the platform behaves on your code, not on a canned demo.