Made on
Tilda
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 merge request (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.
PR-Agent is an open-source AI agent for pull requests. It takes a PR/MR from a git provider (GitHub, GitLab, Bitbucket Cloud and Server, Azure DevOps, Gitea, Gerrit, AWS CodeCommit) or a raw unified diff, gathers context (description, commits, tickets, repo-context files, skills, CI artifacts), calls an LLM through LiteLLM and publishes the result back: a comment, inline comments, the PR description, labels, a CHANGELOG commit, a check run, or output to stdout, JSON or external sinks. Commands: /review, /describe, /improve, /ask, /ask_line, /add_docs, /generate_labels, /update_changelog, /similar_issue, /config, /help; /help_docs is disabled. It has a CLI, a GitHub Action, webhook servers, polling, AWS Lambda, the MOSAICO A2A server, and plain-diff/local modes. MIT.
It is a direct competitor to Council's review service and PR publishing, but not to its code understanding and knowledge layer. PR-Agent reads the diff and the context it gathered, not the whole repository; it doesn't build a graph, keep a knowledge base or conventions, or run tasks. Of the projects we compared, it is the strongest at PR mechanics: providers, commands, inline suggestions, persistent finding state, ticket context, and honest reporting of diff coverage.
| AI Council | PR-Agent | |
|---|---|---|
| Who reads the code | Council itself: it parses the repositories and builds the graph. No model is called during analysis | The model reads a prompt assembled from the diff and context. PR-Agent doesn't do static analysis: it gets patches from the provider and, when needed, fetches full files (up to 50 files on GitHub), repo-context files (AGENTS.md by default, up to 500 lines), skills, CI artifacts and tickets. No graph, repository index or layers |
| When | On project creation, on push to main (polling), on demand, and nightly; after the agent edits a file, the file and its dependents are recomputed | On a PR event (opened, synchronize, a command in a comment), a CLI call or an A2A request. No background repository analysis |
| What it extracts | Layers L0–L10: stack, structure, dependencies and cycles, metrics and calls, data (ORM, DDL), architecture and forbidden dependencies, patterns, style, DDD, files that change together, code smells, ISO 25010 quality, diagrams | The diff and file patches, file languages, commits, PR description, tickets, repo-context, skills, CI artifacts. No code structure, dependencies, architecture, DDD, patterns, style, code smells or ISO 25010 |
| What's missing | — | A graph of the code and the whole repository: PR-Agent sees the PR and whatever fits into the prompt. No dependencies, cycles, architecture layers, DDD, patterns, quality metrics or architecture diagrams |
| Languages | Python, PHP, TypeScript, JavaScript, Java, Kotlin, C#, C, C++, with full layer analysis | Language is determined by the provider and an extension map (language_extensions.toml); no per-language analysis, the model works with diff text. language_handler.py classifies files but doesn't build layers |
| Multiple repositories | A project made of several repositories with a shared graph | One PR per run. Sibling repositories are read only through a host allowlist (repo_context_sibling_repos) with an access check; no shared graph across repositories |
| History | Edges are versioned after every run; architecture_as_of shows the architecture as of a date | Incremental mode by commits (IncrementalPR, unreviewed_files_map) and persistent finding state between runs. No architecture history |
| Search | Semantic and regex search, find_usages, find_path, dependency graph, similar implementations; ask_question returns excerpts from the knowledge base without a model's paraphrase | No code search: the tool receives the diff and files. /similar_issue is a vector index of issues (GitHub, LanceDB/Pinecone/Qdrant), not code. Beyond that, questions about the diff via /ask and /ask_line |
| AI Council | PR-Agent | |
|---|---|---|
| Knowledge base | Decisions, notes, Mermaid diagrams, changelogs. Each entry is anchored to code and reaches the agent when it touches that file | No knowledge base. Context exists only in the prompt: PR description, commits, tickets, repo-context, skills, artifacts. Between runs, a narrow persistent state lives in PR comments: identity markers, finding state, inline comment fingerprints, suggestion history. That is review state, not knowledge about the code |
| 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. The reviewer must provide a quote; the outcome is a label | Findings are checked against head_sha: ACTIVE becomes RESOLVED only with full coverage and a new head; a finding that reappears becomes REOPENED. This is careful freshness for findings, not knowledge; outside of review there is no check of whether an entry still matches the code |
| Branches | Knowledge and the graph are stored per branch; the agent sees its own branch, the parent and whatever was merged; on merge, entries move with the code | Work happens on the PR branch; incremental mode is anchored to commits and the check type (review/suggestions). No per-branch knowledge or knowledge merging |
| Rules | Conventions at three scopes: code entities, paths (they apply even to a file that doesn't exist yet), the whole project. MUST/SHOULD, draft, retired and deleted states. Checked before an edit and against the diff | No conventions engine. There are layered .pr_agent.toml files, prompt TOML, skills (opt-in), prompt fragments, custom labels and extra instructions in a command. Repository and comment settings are limited by allowlists of host-only keys, but that is a security boundary, not an authoritative rule anchored to entities and paths. The model may follow an instruction during review, but there is no deterministic check of the diff against conventions |
| How it reaches the agent | Claude Code hooks: project rules with every message, a wide channel before an action, file context on Read/Edit/Bash, a checklist at the end; the KB gate | No hooks. PR-Agent is triggered by a PR event, a comment command, the CLI or an A2A request, and publishes its result to the PR. It doesn't feed context to the developer's agent |
| MCP | Server: about 60 tools, profiles, modes, XML with a size budget | No MCP server. Interfaces: CLI, webhooks, GitHub Action, Lambda, A2A (MOSAICO), REST-like provider servers |
| Moving knowledge | Bulk export and import of knowledge, copying between projects | Configuration is portable: .pr_agent.toml, prompt TOML, skills, repo-context. No knowledge bundle |
| AI Council | PR-Agent | |
|---|---|---|
| Requirements | Traces tests to requirements by tags: coverage and gaps; "no test" is a tri-state, not requirements management | No test-to-requirement links. There is ticket compliance: the model checks whether the PR matches the ticket and returns ticket_compliance_check |
| Tickets | Jira, GitHub Issues, Redmine: reading, parsing into knowledge, graph-based advice per ticket | GitHub Issues, GitLab issues, Azure work items, Jira Cloud, Linear, Asana: reads the description and acceptance criteria, pulls in sub-issues, checks compliance. It doesn't create or manage tickets |
| Working on your own machine | The agent is the developer's Claude Code or Codex; Council supplies context and rules via MCP and hooks; local diff review, diff walkthrough, diff check against rules | The pr-agent CLI, plain-diff mode (--stdin, --diff-file) and local mode (a git repository on disk), doctor to check the key and ping the model. No MCP or hooks |
| Workspace | Tasks on a VM in a sysbox container, living for days; a person drives them from chat; a mentor agent; diff, commit, push, MR | No tasks or workspace: PR-Agent works with a PR that is already open or a ready diff |
| PR | Review with publishing to the MR (GitHub, GitLab, Bitbucket) | This is the core of the product: 10 providers, comments, inline suggestions, PR description, labels, CHANGELOG commit, check runs, threads, reactions. Broader than Council in the number of providers and PR actions |
| Process | A task state machine: created, analysis, in progress, MR, closed; a person defines what happens at each step | No task process. An event model instead: PR opened/synchronize/comment/review, auto commands, push triggers, polling. State is finding state in comments, not a task |
| AI Council | PR-Agent | |
|---|---|---|
| Code review | A separate service: looks at what changed, a verdict for every file, a second pass, publishing to the MR without duplicates; knowledge review is separate | /review is the main tool: key issues, security concerns, todo, can-be-split, effort 1–5, risk level, merge recommendation, failure modes, priority files, contribution time, score, relevant tests, ticket compliance. Large PRs are chunked; results are merged conservatively (union of findings, minimum score, worst risk/merge); a coverage footer honestly lists remaining/partial files. Persistent finding state ACTIVE/RESOLVED/REOPENED, inline key issues with a publish check, fingerprint dedup. The review has no graph and no knowledge about the code |
| Models | A model is required: on the host, two processes use the vendor's OAuth: AI chat and six background jobs (review, knowledge review, ticket parsing and others). Without a model, only static code analysis remains | No LLM of its own: LiteLLM, a provider key or ambient authentication (Azure AD, Bedrock, Vertex). Models are split into weak/regular/reasoning; default gpt-6.1-sol, fallback gpt-6-luna; a fallback chain, precise token budgeting, prompt caching for Claude, extended/adaptive thinking, streaming. Normally one call per tool; /improve adds self-reflection |
| Agents | Claude Code and Codex (hooks, MCP); MCP is open to any client | PR-Agent is itself the agent for PRs: GitHub App/Action, GitLab, Bitbucket Cloud/Server, Azure DevOps, Gitea, Gerrit, polling, Lambda, A2A/MOSAICO. No Claude Code hooks and no MCP |
| Measurement | Telemetry for every MCP call and hook; an agent repeating a search signals a poor first answer | 380 unit test files, about 145k lines; e2e with real providers, health smoke tests, CI. We did not run the test suite (dependencies were not installed). No public review benchmark in the repository. Council's analysis of the PR-Agent codebase: maintainability 0.68; 3 of 7 fitness functions pass (no cycles, no layer violations, naming 1.0); 39 god classes, 771 long methods, 188 cyclomatic complexity violations, type coverage 0.14, docstrings 0.18, 985 code smells |
| Guarantees | Test gates, review, conventions | Contract tests: capability guard, dead config keys, config reference, required provider methods and line links, regressions for silent errors, webhook verification before parsing, body size limit, Docker hardening, packaging of help docs. CI: build-and-test, docs, e2e, pre-commit, provider-smoke, CodeQL |
| AI Council | PR-Agent | |
|---|---|---|
| Users | Companies, members, roles (can be scoped to a project), permissions. Company API keys. Data is separated: a request without a company is rejected. License and seat limits | Self-hosted, without companies, roles or licensing. There is an identity provider for permission to run a command (everyone is ELIGIBLE by default) and restricted_mode to block push_code. Settings are isolated per request, but there is no multi-user platform |
| Interface | About 50 pages: code, graph, branches, quality, rules, review, knowledge, tickets, tasks, MCP Live, administration, System Health | CLI, 10 git providers, webhook servers, GitHub Action, Lambda, the MOSAICO A2A server, a Docusaurus docs site. No UI of its own |
| Monitoring | Telemetry for every MCP call and hook without PII; about 22 Prometheus rules with tests; System Health, tracing | OTel is opt-in (otel.is_enabled=false), a multiprocess Prometheus exporter, RunDetails (models, tokens, cost, call count), structured logs. No telemetry by default; no System Health |
| Self-healing | Reconciles Temporal with the database, cleans up orphaned data, deletes projects in batches, nightly backup with restore check, telemetry retention | Retries the same call, fallback models, chunk recovery with the next model, restores state from comments, publishes config errors, guards against duplicate webhook delivery. No nightly backup or restore check |
| Storage | Neo4j, Qdrant, PostgreSQL per service, Temporal, NATS, Redis | The core has no database: state lives in PR comments; a vector DB is used only for /similar_issue (LanceDB/Pinecone/Qdrant); settings are TOML and env. No graph database or code index |
| Isolation | A sysbox container per task, one-time credentials for push, read-only knowledge reviewer, permission checks in a single gateway, SSRF protection | Per-request deepcopy of settings, a credential snapshot in the handler, contextvars, an SSRF guard for image URLs and public diffs, HMAC/JWT/Basic webhook authentication, a 5 MiB body limit, a container running as uid 10001. No sandbox or task isolation; prompt injection protection relies on boundaries in the prompt, not a sandbox |
| Delivery | A distribution for self-hosted installation, or SaaS; on the developer's machine, MCP and hooks | PyPI pr-agent, Docker with 12 targets, GitHub Action, Lambda, A2A; MIT |
| License | Proprietary | MIT |
PR-Agent is a direct competitor to Council's review service and PR publishing, but not to its code understanding and knowledge layer. It is the best of the projects we compared at PR mechanics: 10 providers, a rich command surface, precise token budgeting, chunking with honest coverage, conservative merging, persistent finding state, inline suggestions with anchor checks, ticket context and compliance. Council covers more ground: a code graph, knowledge anchored to code positions with freshness checks, conventions, tasks on a VM, team and permissions.
Where PR-Agent is stronger:
/review with a rich schema: risk, merge recommendation, effort, security, tests, failure modes, priority files, contribution time, ticket compliance;head_sha, with no resolution allowed on partial coverage;/improve with self-reflection and validation of anchors, Python syntax and existing code;Where Council is stronger:
architecture_as_of, versioned edges, an external analyzer; ask_question returns excerpts with FQNs. PR-Agent sees one PR and its diff.Can they work together? Yes, they play different roles in the same PR process. PR-Agent is a fast PR bot: description, review, suggestions, questions about the diff, ticket context and publishing. Council is the source of truth about the code and rules: graph, knowledge, conventions, deep review and tasks. Both publish to the PR, so you need to split the work: either PR-Agent does the first pass and Council the deep review with graph and rules, or the other way round, but not two independent comments about the same thing. There is no built-in integration. PR-Agent has no MCP, so Council can't hand it knowledge and conventions directly; you would have to pass them through repo-context files or CI artifacts.
Connect AI Council to one of your repositories and see the project graph, rules and review on your real code.