The Problem
Building an Agentic RAG system in Azure means configuring resources across two services: Azure AI Search for retrieval — indexes, skillsets, indexers, knowledge bases — and Microsoft Foundry for the agent layer — agent definitions, instructions, tools, model deployments. Together they form a pipeline where agents query knowledge bases, which route to knowledge sources, which search indexes built from your data.
None of that configuration is managed by traditional IaC. ARM, Bicep and Terraform provision the services; the configuration inside them — the index schemas, skillset pipelines, agent instructions and retrieval rules that actually determine how your system behaves — lives in REST APIs and portal blades. Which means:
- No change history. Azure does not record who changed an index schema or an agent instruction, so a regression has no diff to look at.
- Portal drift. Ad-hoc changes are frictionless, and configurations silently diverge from what anyone remembers deploying.
- No review. Agent instructions and scoring profiles go live unreviewed, though they shape every answer your system gives.
- No pipeline. Nothing to validate in a pull request, deploy on merge, or check for drift on a schedule.
- Manual promotion. Moving dev → staging → prod means hand-exporting JSON across two services and re-pointing every cross-resource reference.
- Nothing for your AI tools to read. Ask Claude Code to help optimise your retrieval pipeline and it cannot see any of it.
What Rigg Does
rigg pulls resource definitions from Azure AI Search and Microsoft Foundry
into local files, versions them in Git, and pushes changes back. A
workspace (rigg.yaml) holds your environments; a project is the group
of resources you pull, push, review and deploy as one unit — and every resource
belongs to exactly one project, which is what keeps sync unambiguous.
That gets you Git history and code review over the whole stack, semantic drift
detection against both services, environment promotion that translates
infrastructure references rather than copying them, CI/CD with OIDC and no
stored secrets, and identity-first authentication — no file rigg writes ever
contains a credential, and rigg auth doctor derives the role assignments your
files require and can create them for you.
It also gets your AI coding tools a way in: rigg describe returns the full
dependency graph in one call, and a built-in MCP server lets Claude
Code, Copilot, Cursor and others pull, push, diff and explore through
structured tool calls.
Use rigg for Azure AI Search alone, Microsoft Foundry alone, or both. See docs/how-rigg-works.md for the mechanism.
Install
macOS, via Homebrew:
See INSTALL.md for pre-built binaries and shell completions.
Quick Start
# 1. Point rigg at your Azure services (discovered via the Azure CLI)
# 2. Group what you manage into a project
# 3. Adopt what already exists in Azure...
# ...or scaffold a pipeline from scratch instead
# 4. Review, then apply
Then connect your AI tool (optional but recommended):
Documentation
Start here: rigg concepts for the mental model, then
tutorial 1.
| Tutorial | What it covers |
|---|---|
| 1 — Pull an existing solution | init, adopt, bindings, the first commit, and a proven delete/push round trip |
| 2 — Build from scratch | blob → index → indexer → knowledge base → Foundry agent, with auth doctor --fix |
| 3 — Add an environment and promote | env add --like, promote as translation, the binding questions |
| 4 — Push to protected production | protected/strict-bindings, --confirm-env, ci init, the agent gate |
| Reference | What it answers |
|---|---|
| docs/README.md | The index: which page answers what |
| CLI reference | Every command, argument and flag (generated from the binary) |
| rigg.yaml · project.yaml | Every workspace and project key |
| Resource files · Annotations · APIs | The 12 resource kinds, x-rigg-*, the WebApiSkill contract |
| State · Environment variables | .rigg/, and every RIGG_*/AZURE_* variable |
| Exit codes and questions | Exit codes, the needs-input protocol, every question id |
Also: CONCEPTS.md — the model, including how rigg handles authentication; how-rigg-works.md — sync classes, bindings, the identity graph, promotion and the question protocol; MCP.md — the MCP server and its 14 tools; SKILLS.md — agent skills; samples/ — a runnable workspace with two projects.
Exit Codes
Standardized for scripting and CI (--non-interactive guarantees rigg never
blocks on a prompt):
| Code | Meaning |
|---|---|
| 0 | Success |
| 1 | Error |
| 2 | Usage error |
| 3 | Validation failed |
| 4 | Auth / permission denied |
| 5 | Drift or conflict detected |
| 6 | Needs input |
Exit 6 means a guided flow needs an answer it cannot prompt for: rigg prints a
needs-input JSON document (the questions, with ids, prompts and candidates)
instead of failing blind. Answer with --answer <id>=<value> (repeatable) or
--answers-file <path> and re-run; answered questions are never asked again.
License
MIT — see LICENSE.md.