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 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.
ouroboros is a local layer on top of the agent the developer already uses (Claude Code, Codex and others). It runs a pipeline of interview, spec, execution with verification, evaluation and evolution. It has no model of its own. Python, about 351k lines, single user, a single SQLite file.
| AI Council | Q00/ouroboros | |
|---|---|---|
| Who reads the code | Council itself: it parses the repositories and builds the graph. No model is called during analysis | It doesn't read code itself. The host agent reads it, and findings come back into the interview as [from-code] answers |
| When | On project creation, on push to main (polling), on demand, and nightly. After every file edit by the agent (Write/Edit), the file and its dependents are recomputed | — (only detects an existing project by git or config) |
| 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 clustering, aggregates, events); files that change together in git; code smells; ISO 25010 quality and fitness functions; diagrams (C4, dependencies, layers) | — |
| Languages | Python, PHP, TypeScript, JavaScript, Java, Kotlin, C#, C, C++ | Whatever the host agent can write |
| Multiple repositories | Yes, one shared graph per project | One directory |
| External analyzers | SonarQube: imports its findings. Its own scanner: text-based languages, JVM with a build, .NET, .NET Framework on a Windows worker | — |
| Architecture history | Edges are versioned after every run; architecture_as_of shows the architecture as of a date | Only the history of its own runs |
| Search | Semantic; regex (grep_code); find_usages, find_path, dependency graph, similar implementations. ask_question answers with excerpts from the knowledge base, not a model's paraphrase | None of its own |
| AI Council | Q00/ouroboros | |
|---|---|---|
| Knowledge base | Decisions, notes, Mermaid diagrams (syntax checked on write), changelogs. Each entry is anchored to code and reaches the agent when it touches that file | No; a log of its own runs |
| Freshness | An entry holds its place in the code on its branch. It goes back for re-checking when the code under it changes (by AST fingerprint), when the entry itself changes, when a similar entry appears, or when the branch is merged. The reviewer model (read-only token) must quote the source verbatim. The outcome is a label: stale, conflicts with code, disputed or superseded. The entry text is never touched. Reviewer accuracy is measured against known answers. On/off switch, models and daily budget are in project settings | — |
| Branches | Knowledge and the graph are stored per branch. The agent sees its own branch, the parent, and whatever was merged into them. On merge, entries move with the code. A branch graph is computed as a separate layer next to the main one | A separate worktree per task |
| Where knowledge comes from | Agents and people write it. Tickets from the tracker are parsed into history entries automatically (this is how hundreds of entries from the 882 ouroboros tickets ended up in its knowledge base). Drafts from MR history. Documents from Google Drive | Specs and results of its own runs |
| Rules | Three kinds of conventions: for code entities; for paths (they apply even to a file that doesn't exist yet); for the whole project. MUST/SHOULD levels, draft, retired and deleted states, a default set. Checked before an edit and against the diff | No |
| How it reaches the agent | Claude Code hooks. Project rules are added to user messages in rotation. Before an action, a wide channel (about 200k characters). File context on every Read/Edit/Bash. A checklist at the end of the turn. KB gate: the agent can't open code until it has queried the knowledge base, and only a person can lift the gate. A reminder when a matching entry already exists. A rule is delivered whole or not at all | Installs its own skills and instructions into the agent (how to use ouroboros itself) |
| MCP | About 60 tools; profiles (minimal / dev / review / ops); per-session modes; unknown arguments are rejected; XML responses with a size cap | About 40 ouroboros_* tools; long operations run as background jobs |
| Moving knowledge | Bulk export and import, copying between projects | — |
| AI Council | Q00/ouroboros | |
|---|---|---|
| Requirements | Traces tests to requirements by tags: coverage and gaps; "no test" is a tri-state, not requirements management | The core of the product: an interview runs until ambiguity is ≤ 0.20, then produces an immutable spec with hidden checks. A product manager interview that outputs a PRD |
| Tickets | Jira (Cloud/DC), GitHub Issues, Redmine: reading, parsing into knowledge, recommend_for_ticket (graph-based advice without a model), find_tickets_for | Only exports a spec to GitHub issues (ooo publish) |
| Working on your own machine | The agent is the developer's Claude Code or Codex. Council supplies context and rules via hooks and MCP and recomputes the graph after edits. Local diff review (review_local_changes), diff walkthrough (brief_me_on_diff), diff check against rules (check_diff_conventions) | Runs inside the developer's host agent |
| Tasks in a workspace | Stages: created, analysis, in progress, MR, closed. A task can live for days. The agent runs on a VM: its own sysbox container and home directory per task, environment setup (deployment recipe, secrets), app preview. In the UI chat a person can step into a running turn, answer the agent's question, allow a tool or stop it. Turn length is not capped: a turn ends when the agent goes quiet. History is written as it goes; if the agent session dies, there is a summary to resume from. A mentor agent reads the output and steers | Autonomous: acceptance criteria by level, run in parallel by background agents. Retries, splitting, switching to another agent, pausing when quota runs out, worktree, a commit per accepted criterion |
| What goes out | Diff; commit message per convention; commit; push with one-time credentials, a branch protection check and a check for growth in critical code smells; MR in GitHub / GitLab / Bitbucket; task closes on merge; a quality report on the task's changes | Local commits; issues via gh |
| AI Council | Q00/ouroboros | |
|---|---|---|
| Acceptance against a spec | No. There is review, a report on the task's changes, and push is blocked when critical code smells grow | Its strongest part: seven layers of verification. The agent's claims are checked against its tool-call log; a hidden verify_command runs after every attempt; held-out checks are collected before the agent starts and run against the original code; a sandbox (Landlock/seccomp, no network). A model can only veto acceptance |
| Formal evaluation | — | Three stages: automated checks (mechanical.toml), then semantic evaluation, then consensus. Only a passed first stage can approve. Consensus is manual by default, or triggers on rejection or uncertainty > 0.3; voters see only the artifact text |
| Code review | A separate service. It looks only at what changed in the branch; file groups are handed out in waves. A finding is a judgment plus zero or more locations; the model quotes the code and the line number is derived from the quote. A verdict is required for every file ("couldn't check" is not "clean"). A second pass drops a finding only if it is shown to be wrong. Publishing to the MR: comments on added lines and one summary note, without duplicates. MRs are picked up automatically, including MRs from forks. When rules change, past results are invalidated | None as a separate step |
| Self-improvement | Knowledge is re-checked when code changes; the graph fixes its own drift | An evolution loop (find problems, analyze, new spec, execute, evaluate) until convergence, stagnation or a limit. StagnationDetector is written but never called |
| Models | A model is required: on the host, two processes use the vendor's OAuth: the operator AI chat (Claude, Codex) and six background jobs (file group review, second review pass, knowledge review, ticket parsing, document import, branch naming). The model's response is checked for refusal before use | The model belongs to the executing agent. Three price tiers (1/10/30) with escalation, enforced only on Claude SDK, claude_mcp and Codex; on the rest it is just a recommendation. The savings report always says "not enough data"; the tournament of several implementations is dead code |
| Agents | Claude Code and Codex (hooks, MCP); MCP is open to any client | About 13 executors: Claude Code, Codex, OpenCode, Copilot, Gemini, Hermes, Kiro, GJC, Goose, Pi, OMP, Zcode, Antigravity, Grok |
| AI Council | Q00/ouroboros | |
|---|---|---|
| Users | Companies, members, roles (can be scoped to one project), permissions. Company API keys. Data is separated by company: a request without a company is rejected. Per-installation license and seat limits | One person |
| Interface | About 50 pages: dashboard, code, graph, branches, quality, rule compliance, review, conventions, knowledge, knowledge review, tickets, tasks with chat and diff, operator AI chat, MCP Live, administration, System Health | Two terminal UIs, a read-only web kanban (no password login, same machine only), a web settings page |
| Monitoring | Telemetry for every MCP call and hook event, with no personal data; an agent repeating a search signals a poor first answer. About 22 Prometheus rules with tests; every signal has a "nobody is watching this" rule. System Health screen, tracing | Event log; anonymous events go to the developers' PostHog (can be turned off) |
| Self-healing | Reconciles Temporal with the database, cleans up orphaned data before analysis, deletes projects in batches in the background, nightly backup and weekly restore check, purges old telemetry, checks disk space before a rollout | Recovers runs from the log, cleans up orphaned runs on startup |
| Storage | Neo4j, Qdrant, PostgreSQL per service, Temporal, NATS, Redis | A single SQLite file (append-only events) |
| Isolation | On the developer's machine, the agent runs the way the developer configured it. In a workspace: a sysbox container per task, one-time credentials for push, exec through an allowlist. The knowledge reviewer is read-only, permission checks go through a single gateway, SSRF protection, credentials are encrypted | The executor has full host permissions; the sandbox covers only verification commands |
| Delivery | A distribution for self-hosted installation, or SaaS; on the developer's machine, MCP and hooks | pip / uv / brew |
| License | Proprietary | MIT |
Council covers much more ground:
architecture_as_of, SonarQube. 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.ouroboros is narrower but goes deeper in one area: taking a task autonomously from spec to an acceptance check the agent can't fake. That is a different axis, and a real one. Council has no spec interview and no hidden acceptance checks.
Both live inside the developer's agent via MCP, so they fit together. ouroboros deliberately leaves code understanding to the host agent, and that is exactly the slot Council fills. In one Claude Code session, ouroboros can drive the process (interview, spec, acceptance) while Council supplies code, rules and knowledge.
In sum: ouroboros is stronger at autonomous task completion and acceptance that can't be faked. Council is stronger at code understanding, knowledge, rules, review and teamwork. Neither axis cancels the other.
Connect AI Council to one of your repositories and see the project graph, rules and review on your real code.