FAQ

By construction, not by policy. Argus's entire ADO surface is a five-tool MCP server, and the three mutating tools are post a reply, create an inline thread, and resolve a thread — no approve, complete, merge, or push tool exists, and the service identity holds no such permission. A hostile prompt cannot invoke a tool that does not exist. Humans keep the gate. See Architecture and About the name — the watchman, not the warden.

Session id = the per-PR key (org/project/repoId/prId), so Service Bus delivers every job for one PR in order, to one consumer at a time, while different PRs run in parallel. Without that, a push arriving mid-review could interleave two reviews of the same PR — duplicate threads, races on last_reviewed_sha. The sessions checkbox is immutable after queue creation, which is why every deployment doc shouts about it. See Architecture.

• To the inference endpoint (Anthropic first-party, or Claude on Microsoft Foundry if you route there): the assembled prompt — diff, relevant repo content read during the review, rules, thread history. That is inherent to an LLM reviewer; choose the endpoint your procurement allows (OD-1).
• To Azure DevOps, Postgres, and Service Bus: your own tenant's services.
• Nothing else. Production worker egress is restricted to exactly those four destinations; credentials never enter model context; the optional Opik eval export is off by default and can be pointed at a self-hosted instance for full data residency. See the security model and Evals & quality.

The largest lever is review tiering, roughly a 5–10× spread per PR:

• Single-shot tier — one model call over the scoped diff, for small, low-risk PRs (at or under REVIEW_TIER_MAX_CHANGED_LINES, default 1500 changed lines, touching no risky path).
• Full agentic tier — the harness explores the repo, for large diffs or anything touching RISKY_PATH_GLOBS (shared code, RBAC, pipelines).

On top of tiering: prompt caching within threads, diff scoping (lockfiles and generated code excluded), incremental review of only the delta after a push, and two hard ceilings — PER_PR_TOKEN_CEILING (posts a "review truncated" note on breach) and ORG_DAILY_TOKEN_CEILING (pauses new reviews). Token usage is recorded per event in reviewer.event_log, so cost per PR is measured, not estimated. See Configuration.

• One PR or one repo: set reviewer.pr_session.status = 'paused' by SQL (resume with 'active') — there is no CLI for this yet.
• Whole service, instantly: disable the three service hooks in ADO (Project settings → Service hooks → Disable) — cheapest and most visible — or scale the worker to zero replicas (queued jobs wait for resume).
• Narrow the scope: set PROTECTED_BRANCHES so only certain target branches are reviewed; unset means review all.

The operations section of the deployment runbook (infra/deploy-azure.md in the repo, step 10) covers all three. See Deployment.

After a fixed number of back-and-forth replies in one thread (default 4), it posts a final message escalating to a human reviewer and bows out — a stalemate with an AI is not a good use of anyone's tokens. Volume is also capped per PR and per hour. See Getting started.

No and no, deliberately, in v1. The ADO mirror is the review surface, and Argus reads code rather than executing it — it will never claim a test passed. Both are explicit non-goals in the PRD (PRD.md, §3).