Rigovo Teams
Your virtual AI engineering team. Describe a task — get production-ready code.
What Is Rigovo Teams
Rigovo Teams assembles a coordinated team of AI agents to turn task descriptions into production-ready code. Each agent has a specific role, learns from past work, and is governed by quality gates that enforce real standards.
You describe what needs to be done. Rigovo handles the rest:
- Scans your codebase to understand context
- Detects intent — brainstorm, research, fix, or build — and allocates resources accordingly
- Classifies task type and complexity
- Assembles the right team (2–12 agents depending on intent)
- Executes each agent with tools, quality gates, and automatic retries
- Reviews code via parallel reviewer, security, and QA agents
- Learns from every task — memories and skill profiles persist across projects
The Team
| Role | What It Does | Default Model |
|---|---|---|
| Planner | Reads the codebase, produces a structured plan for the team | Sonnet |
| Coder | Implements the task — writes code, runs tests, uses tools | Opus |
| Reviewer | Reviews code for logic errors and improvements | Sonnet |
| Security | Scans for vulnerabilities, injection risks, auth issues | Haiku |
| QA | Writes and runs tests | Haiku |
| DevOps | CI/CD, Docker, GitHub Actions, infrastructure config | Haiku |
| SRE | Observability, alerting, SLOs, runbooks | Haiku |
| Tech Lead | Final review across all agent outputs — SHIP or HOLD | Opus |
| Docs | API docs, READMEs, architecture decision records | Sonnet |
All models are configurable per-agent from the Settings → Agents tab in the desktop app, or via rigovo.yml.
Intent Detection — Smart Resource Allocation
Before any agent runs, Rigovo detects what kind of task you're asking for and allocates resources accordingly. This is zero-LLM, pure regex, under 5ms.
| Intent | Max Agents | Token Budget | File Reads | Planner Mode |
|---|---|---|---|---|
| Brainstorm | 2 | 50K | 0 | Think (no codebase) |
| Research | 3 | 150K | 15 | Survey |
| Fix | 5 | 300K | 30 | Survey |
| Build | 12 | 500K | Unlimited | Survey |
A brainstorming task that only needs a conversation won't burn 500K tokens assembling 12 agents. Intent detection ensures you only pay for what the task actually needs.
The Pipeline
scan → classify → intent_gate → route_team → assemble
↓
[Optional] plan_approval → REJECTED → done
↓ approved
execute_agent → quality_check
│ │
│ pass ↓
│ next agent or parallel fan-out
│
│ fail → retry with fix packet (up to 5x)
│ fail → replan → retry once more
↓
[reviewer ║ security ║ qa] ← parallel execution
↓
[Optional debate] ← if reviewer requests changes
↓
[Optional] commit_approval
↓
enrich → evaluate_skills → store_memory → finalize
Quality Gates
After every code-producing agent, 23+ deterministic quality gates run automatically (no LLM cost, under 1 second):
- File size limits, type hints, naming conventions
- Error handling (no bare
except:), magic number detection - Async safety, import validation, forbidden content
- Hallucinated imports, secrets detection, command injection
- Output contract and persona boundary validation
When gates fail, a fix packet tells the agent exactly what's wrong and how to fix it. The agent retries automatically (up to 5 attempts). If retries are exhausted, a replan generates a corrective directive and the agent runs once more.
Smart deep mode adds LLM-powered analysis selectively — for critical tasks, security roles, high-retry agents, and final pipeline steps.
Every completed task receives a confidence score (0–100) based on gate pass rate, retry count, violations, and deep analysis results.
Memory and Learning
Rigovo learns from every task:
- Memories — extracted learnings stored as vectors, retrieved by semantic similarity for future tasks. Works across projects.
- Enrichment — agent-specific pitfalls (e.g., "Never use bare except in auth code") persist and are injected into system prompts on subsequent tasks.
- Skill profiles — rolling performance metrics per agent (success rate, avg tokens, common violations) that improve team composition decisions over time.
Desktop App
Cross-platform Electron app with dark/light theme.
Key screens:
- Task Input — describe what you want, select workspace
- Agent Timeline — watch agents execute in real-time
- Pipeline Map — visual DAG topology of the running pipeline
- Agent Detail — execution logs, tool calls, cost, consultation threads
- Approval Cards — approve/reject at plan and commit stages
- Settings — API keys, per-agent model selection, orchestration config, quality gates
Settings are hot-reloaded — changes apply to the next task immediately, no restart needed.
Getting Started
Prerequisites
- Python 3.10+
- Node.js 20+ and pnpm 9+ (desktop app)
- API key: Anthropic, OpenAI, Google, DeepSeek, Groq, or Mistral
- WorkOS account (optional — for auth in desktop app)
Install
pip install rigovo
Initialize a Project
cd your-project
rigovo init
# Creates: rigovo.yml, rigour.yml, .env, .rigovo/
Validate Setup
rigovo doctor
# Checks: Python, config, API keys, database, Rigour CLI, git
Run a Task (CLI)
rigovo run "Add input validation to all API endpoints with proper error responses"
Desktop App (Development)
./scripts/e2e_desktop.sh
Desktop App (Production Build)
pnpm -C apps/desktop install
pnpm -C apps/desktop run build
pnpm -C apps/desktop run dist
# Output: apps/desktop/release/ (macOS .dmg, Windows .exe, Linux .AppImage)
Configuration
API Keys
API keys are stored encrypted in SQLite — not in plain text files. Set them via the desktop Settings page or .env for CLI usage.
# .env (CLI usage)
ANTHROPIC_API_KEY=sk-ant-...
Per-Agent Model Configuration
Three ways to configure which model each agent uses (highest priority wins):
- Settings UI — Desktop app → Settings → Agents tab (saves to
rigovo.yml) - rigovo.yml —
teams.engineering.agents.<role>.model - Environment variable —
LLM_AGENT_MODELS='{"coder":"claude-opus-4-6","qa":"claude-haiku-4-5"}'
rigovo.yml
version: "1"
teams:
engineering:
agents:
planner:
model: "claude-sonnet-4-6"
coder:
model: "claude-opus-4-6"
reviewer:
model: "claude-sonnet-4-6"
orchestration:
max_retries: 5
max_agents_per_task: 10
consultation:
enabled: true
replan:
enabled: true
strategy: deterministic # deterministic | llm
approval:
after_planning: true
before_commit: true
quality:
deep_mode: "smart" # never | final | smart | always | ci
database:
backend: sqlite # sqlite | postgres
local_path: ".rigovo/local.db"
Auth (WorkOS)
# .env
WORKOS_CLIENT_ID=client_01...
RIGOVO_IDENTITY_PROVIDER=workos
Redirect URI must be http://127.0.0.1:8787/v1/auth/callback — set this in your WorkOS dashboard.
API
POST /v1/tasks Create a task
GET /v1/tasks/{id} Task status + outputs + confidence score
GET /v1/tasks/{id}/detail Full detail with events + execution logs
GET /v1/ui/inbox Task list
GET /v1/ui/approvals Pending approvals
POST /v1/tasks/{id}/approve Approve
POST /v1/tasks/{id}/deny Reject
GET /v1/settings Current settings
POST /v1/settings Update settings (hot-reloaded)
GET /v1/auth/url WorkOS auth URL
GET /v1/auth/callback Auth redirect handler
GET /v1/auth/session Current session
POST /v1/auth/logout Clear session
GET /v1/projects List projects
POST /v1/projects Register project
GET /health Health check
Running Tests
# Python (946 tests)
pytest tests/ -q --ignore=tests/unit/infrastructure/test_dashboard.py
# TypeScript (zero errors)
cd apps/desktop && npx tsc --noEmit
Project Structure
src/rigovo/
├── api/control_plane.py # FastAPI endpoints + event streaming
├── application/
│ ├── graph/
│ │ ├── builder.py # LangGraph pipeline builder
│ │ ├── edges.py # Conditional routing
│ │ ├── state.py # TaskState (pipeline data)
│ │ └── nodes/ # Pipeline nodes (scan, classify, intent_gate,
│ │ # route_team, assemble, execute_agent,
│ │ # quality_check, replan, enrich, finalize)
│ ├── context/ # Codebase scanning, memory retrieval
│ ├── commands/run_task.py # Task execution entry point
│ └── master/ # Classification, routing, enrichment
├── domains/engineering/ # Agent roles, tools, rules
├── infrastructure/
│ ├── llm/ # LLM providers (Anthropic, OpenAI, etc.)
│ ├── persistence/ # SQLite + PostgreSQL
│ ├── quality/ # Rigour quality gate builder
│ └── filesystem/ # Sandboxed tool executor
├── config.py # Config loading (rigovo.yml + .env + env vars)
└── container.py # Dependency injection + hot-reload
apps/desktop/
├── src/main/ # Electron main process
├── src/preload/ # Context bridge
└── src/renderer/src/components/ # React UI (TaskDetail, AgentTimeline,
# Settings, ApprovalCard, etc.)
License
MIT — see LICENSE
Built on LangGraph · Governed by Rigour · Authenticated by WorkOS
Metadata
Release files for rigovo 1.2.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| rigovo-1.2.0.tar.gz | 281.9 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| rigovo-1.2.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 624.1 kB
Release files / rigovo-1.2.0.tar.gz
| Download URL | rigovo-1.2.0.tar.gz |
|---|---|
| Size | 281.9 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
b8d8d8a6bddc01a88ff06dbd3c5997428c331ec879e7102cfade614c384d604a
|
|
BLAKE2b-256 checksum How to use checksums |
b99490c4335d88d5d410beac27a3a6f9218d6442aa1cecb5377b21283ccac1a0
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.7
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Mar 2, 2026.
Transparency logRelease files / rigovo-1.2.0-py3-none-any.whl
| Download URL | rigovo-1.2.0-py3-none-any.whl |
|---|---|
| Size | 342.2 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
e049c7e692d50d0ab5b1ff7e60e806b37082d94c8d26991e4269e4e7d2f629ea
|
|
BLAKE2b-256 checksum How to use checksums |
1f3145d33c2d0bb8a54fefd4cf638cf8244f794770118a1ef1622eee1f85c6e1
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.7
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Mar 2, 2026.
Transparency log