Skip to content
Back to blogPrivacy & Terms
Product28 min readRepath Khan

Critique v6.1.1: Agent Stack Integrations — When the Merge Gate Meets RWX, Swytchcode, and Iron Book

Coding agents do not ship in a vacuum. v6.1.1 adds upstreamSignals on the Merge Gate API so build validation, API execution, and runtime agent IAM ride on the same Change Passport as PASS / WARN / FAIL — without Critique pretending to be CI, an integration kernel, or enterprise IAM.

Agent stack integrations

v6.1.1 · upstreamSignals on the merge gate

critique.sh

v6.1.1
upstreamSignals + stack docs + cookbooks
0
Max signals per review queue request
0
First-class provider enums + custom
0
New partner cookbooks on /merge-gate-api

Why v6.1.1 exists — the stack got real before the passport did

In v6.1 we stopped making orchestrators discover the merge gate by accident. `POST /api/v1/reviews`, `?findings=all`, signed webhooks, MCP `queue_review`, the /merge-gate-api product page, and the Merge Gate essay all say the same thing: the agent that wrote the code should not be the only thing that approves it.

That shipped. Then the questions changed. Not “how do I queue review?” — but “we already run RWX / Swytchcode / Iron Book — where does Critique sit, and what do we pass you?” Platform teams wiring agent supervisors at 2 a.m. do not want four separate audit PDFs. They want one Change Passport that says: this agent (Iron Book), this build (RWX), this merge judgment (Critique), these blockers (findings), this override (if any).

The agent stack — four layers, four questions

Who owns which question

Critique complements these vendors; it does not replace them. If we tried to rebuild CI, 2000 API manifests, or enterprise agent IAM, we would lose the merge-boundary story that v4–v6 spent a year earning.

LayerExample vendorQuestionCritique v6.1.1
Runtime IAMIdentity Machines (Iron Book)Who is this agent and what may it touch?Record agent DID / trust on passport via identity_machines signals
Build / CIRWXDoes this commit build and pass tests?Record green RWX run via rwx signals before queueing judge
Merge / change controlCritiqueMay this PR merge — with evidence?PASS / WARN / FAIL + findings[] + merge policy + export
API executionSwytchcodeDid the prod API call succeed safely?Record swytchcode tool policy beside repo changes

Notice what is not on this table: another coding host, another comment bot, another “AI review” that paraphrases the diff. Critique’s job stayed constant since v4 change control: governance at the merge boundary — passports, Checkpoint, merge policy, evidence runs, Remedy proof, compliance export.

What we shipped in v6.1.1

upstreamSignals

Optional array (max 8) on `POST /api/v1/reviews` and MCP `queue_review`. Each signal has `provider` (rwx · swytchcode · identity_machines · custom), required `kind`, optional `status`, `label`, `externalId`, `url`, `recordedAt`, and opaque `metadata`. Critique validates shape, stamps recordedAt if omitted, stores on the review run, echoes on poll + webhooks, and copies into passport snapshot provenance for export.

POST /api/v1/reviews → upstreamSignals[]
Partner packaging

[Agent stack integrations](/docs/platform/agent-stack-integrations) operator guide. Four new cookbooks on /merge-gate-api: RWX green → gate, Swytchcode + gate, Iron Book provenance, full stack loop. OpenAPI QueueReviewRequest updated. `/merge-gate-api` product page Agent stack section. Changelog, llms.txt, and docs index cross-links.

Docs · cookbooks · product page

upstreamSignals — field-by-field

Think of each signal as a structured footnote on the review queue request — machine-readable, exportable, webhook-friendly. Not prose in a check-run summary.

Signal schema (REST + MCP)

Zod-validated on ingress. Invalid arrays return 400 on POST /api/v1/reviews.

type UpstreamSignal = {
  provider: 'rwx' | 'swytchcode' | 'identity_machines' | 'custom'
  kind: string              // e.g. ci_run, tool_policy, agent_identity
  status?: 'pass' | 'warn' | 'fail' | 'unknown'
  label?: string            // human summary
  externalId?: string       // run id, tool id, agent DID
  url?: string              // partner dashboard link
  recordedAt?: string       // ISO-8601; Critique sets now if omitted
  metadata?: Record<string, unknown>
}

Use `custom` for internal platforms (Buildkite job, internal policy engine, custom agent registry) without waiting on a new enum. Use `metadata` for partner-specific fields — trust scores, CapBAC policy ids, Swytchcode canonical tool ids — that you want in export JSON but do not need Critique to interpret yet.

Where signals land after you queue review

Data flow — one queue request, four surfaces
  1. 1
    Review run metadata
    Stored under upstreamSignals on the `ReviewRun`. Survives re-queue on the same head SHA when your orchestrator re-attaches signals.
  2. 2
    GET /api/v1/review-runs/:id
    Poll responses include `upstreamSignals` alongside verdict, risk band, and findings. Use `?findings=all` when you need blockers and signals in one round trip.
  3. 3
    Webhooks
    Both installation lifecycle (review.run.completed) and per-run (review.completed) payloads include `upstreamSignals` (empty array when none were sent). Dedupe on `reviewRunId` when both fire.
  4. 4
    Change Passport export
    Passport snapshot provenance copies signals from the evidence run. `GET /api/v1/passports/:id/export` bundles them for GRC handoff next to merge policy, evidence, and timeline.

RWX + Critique — build first, judge second

RWX optimizes the agentic dev cycle: validate without commit/push, sandboxes that share config with CI, content-based caching, per-task OCI images. Their pitch is speed and a tight inner/outer loop. Critique’s pitch is the next gate: green RWX does not mean safe merge — it means the branch compiles. Semantic risk, missing tests, auth holes, and policy still live on the diff.

RWX → Critique (recommended)
Agent iterates with rwx run→Writer opens PR→Orchestrator POST /reviews + rwx signal→Critique PASS/WARN/FAIL→Fix loop on findings[]→Your merge policy

Cookbook on /merge-gate-api: RWX green → Critique merge gate. Pass the RWX run URL in `url`, status `pass`, kind `ci_run`. Your supervisor can refuse to queue Critique until RWX succeeds — Critique does not enforce that in v6.1.1, but the passport will show you skipped attestation if you queue without signals.

Swytchcode + Critique — repo changes vs prod API calls

Swytchcode sits at the tool-calling layer: schema validation, tooling.json allowlists, swytchcode exec, MCP integration. Agents fail on Stripe field renames and false 200s — Swytchcode catches that before prod. Critique catches what lands in main — architecture, security specialists, merge policy, Checkpoint on agent PR shape.

Swytchcode owns
  • Deterministic API execution
  • Schema drift detection
  • Auth, retries, idempotency on tool calls
  • 2000+ manifests, one CLI model
Critique owns
  • Diff-level review + sandbox evidence
  • PASS / WARN / FAIL merge verdict
  • Change Passport + signed export
  • Merge policy separate from tool policy

Typical agent workflow: Swytchcode handles `stripe.create-payment` in prod orchestration; the same agent opens a PR changing integration code. Queue Critique with a `swytchcode` signal (kind: tool_policy, externalId: stripe.create-payment) so auditors see both layers on one passport.

Identity Machines (Iron Book) + Critique — runtime IAM vs SDLC judgment

Identity Machines sells Iron Book — zero-trust agent identity, CapBAC, trust scores, Entra/Cognito mapping, immutable action logs. That is runtime: who may call which MCP tool, right now. Critique is SDLC: what code that agent committed, what evidence blocked merge, who overrode policy, what the signed export says months later at audit time.

Enterprise buyers often evaluate Iron Book and Critique in the same quarter. The win is not “pick one” — it is Iron Book on the agent session, Critique on the PR. Attach `identity_machines` signals with agent DID, trust score in `metadata`, and CapBAC policy id so passport export answers both “was the agent allowed?” and “was the change allowed?”

Full stack — the diagram we put in docs

Iron Book → RWX → writer opens PR → Critique gate → merge → Swytchcode for post-merge side effects. Cookbook Full stack on /merge-gate-api copies this loop with a single `POST /api/v1/reviews` body carrying multiple `upstreamSignals` plus optional per-run `webhook`.

Queue review with RWX + Iron Book signals

From the v6.1.1 cookbooks — replace crt_… and SHAs.

curl https://critique.sh/api/v1/reviews \
  -H "Authorization: Bearer crt_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "repositoryFullName": "acme/platform",
    "pullRequestNumber": 120,
    "headSha": "abc123def4567890abcdef1234567890abcdef12",
    "upstreamSignals": [
      {
        "provider": "identity_machines",
        "kind": "agent_identity",
        "status": "pass",
        "externalId": "did:ironbook:ship-agent.v1"
      },
      {
        "provider": "rwx",
        "kind": "ci_run",
        "status": "pass",
        "url": "https://cloud.rwx.com/mint/acme/runs/RUN_ID"
      }
    ],
    "webhook": {
      "url": "https://orchestrator.example/hooks/critique",
      "secret": "replace-with-at-least-32-random-characters",
      "events": ["review.completed"]
    }
  }'

What we deliberately did not build

Scope discipline matters when agent infrastructure is consolidating fast. v6.1.1 adds plumbing and docs, not three new product lines:

Not in v6.1.1
TemptationWhy we skipped it
Critique CI / RWX cloneRWX owns build/runtime; we consume attestations
2000 API manifestsSwytchcode owns execution kernel; we record tool-policy signals
Agent IAM / Iron Book cloneMulti-year enterprise IAM; we reference identity on passport
Auto-block merge on upstream failOrchestrator policy first; optional Checkpoint rules later
Partner API verificationv6.1.1 is attest-only; verification hooks may follow

How this relates to v6.1 and the Merge Gate essay

If you have not read The Merge Gate API: Why Agent Teams Need a Judge That Is Not the Writer, start there for writer / judge / fixer roles, structured `findings[]`, two webhook channels, and Checkpoint-first orchestration. v6.1.1 is the companion release for teams whose stack already includes adjacent vendors — it does not change verdict semantics, credit pricing, or merge policy evaluation.

Same `crt_` keys. Same scopes (`write:reviews`, `read:reviews`, `read:passports`, `manage:webhooks`). Same Change Passport graph. New: `upstreamSignals` on queue, four cookbooks, and [Agent stack integrations](/docs/platform/agent-stack-integrations).

Operator checklist — ship v6.1.1 in your org

Week-one integration path
  1. 1
    1. Map your stack
    List which layers you already run: CI (RWX or other), API runtime (Swytchcode or per-service SDKs), agent IAM (Iron Book or internal), merge gate (Critique). Critique only replaces the last — record the rest as signals.
  2. 2
    2. Update your orchestrator
    When calling `POST /api/v1/reviews`, attach `upstreamSignals` after upstream steps succeed. MCP `queue_review` accepts the same array.
  3. 3
    3. Extend webhook receivers
    Parse `upstreamSignals` on `review.run.completed` and per-run `review.completed`. Store beside `findings[]` for fix-agent context.
  4. 4
    4. Compliance export
    Pull `GET /api/v1/passports/:id/export` after merge — provenance now includes partner attestations next to evidence and policy.
  5. 5
    5. Start optional
    You do not need every partner on day one. One `rwx` signal on agent PRs alone improves audit story. Add `identity_machines` when security asks for agent DID on the passport.

FAQ

No. Same Critique plan and review credits as v6.1. `upstreamSignals` is additive on the Merge Gate API — no new SKU.
Not in v6.1.1. Signals are orchestrator-attested. Your supervisor should only queue review after upstream steps pass. Future releases may add optional verification webhooks.
No automatic block in v6.1.1. Omission means the passport lacks partner context — not a failed review. Enforce upstream gates in your orchestrator or wait for Checkpoint rules keyed on signals.
Both. `queue_review` input schema includes `upstreamSignals` with the same validation as REST.
v6.1 named the judge role and fattened findings/webhooks. v6.1.1 connects Critique to adjacent agent infrastructure without competing on their turf — docs, cookbooks, and `upstreamSignals` on the same API.
Agent stack integrations · Merge Gate API · /merge-gate-api cookbooks · GET /api/v1/openapi
Agent stack guide

RWX · Swytchcode · Iron Book · Critique

Operator reference for upstreamSignals, recommended loops, and honest scope boundaries.

Merge Gate API

Cookbooks + keys

Four new partner cookbooks, Agent stack section, queue review with upstreamSignals.

Merge Gate essay

Writer ≠ judge

v6.1 deep dive — roles, webhooks, findings=all, and why self-review loops fail.

Primary sources
Changelog v6.1.1
Ship notes
Agent stack integrations
Operator docs
Merge Gate API reference
REST + MCP
Merge Gate product page
Cookbooks
Change control platform
Passports + policy

Wire your stack to the merge gate.

Attach upstreamSignals on your next POST /api/v1/reviews, read the agent stack guide, and copy a partner cookbook from /merge-gate-api — RWX green, Swytchcode tool policy, or Iron Book agent identity on the same passport as your verdict.

Read agent stack integrations →
← All essaysPrivacy & Terms

Ask about this essay

Nemotron-3-Super
Ask about the argument, the evidence, the structure, or how the post connects to Critique.
Not editorial advice · The essay above is the source of truth · Not saved to your account · OpenRouter privacy