How do I have one AI coding agent review another agent's work?

Summary

• Run the reviewer as a separate agent, ideally from a different vendor, and let a person make the final call. Omnigent, an open-source meta-harness (Apache 2.0, "Status: alpha"), supports this: its README says you can "Ask one agent to review another's work."
• Omnigent's built-in orchestrator, Polly, runs the loop. Each implementer opens its own PR, the /cross-review skill sends the diff to a different-vendor reviewer, Polly never merges, and the human decides.
• To build your own, declare a reviewer under tools: with type: agent. Each sub-agent picks its own executor.harness and model, so a coder and a reviewer can run on different harnesses.
• Builtin policies add guardrails: read_only_os keeps a report-only agent from changing code, and ask_on_os_tools pauses file and shell operations for user approval.
• On Databricks, Omnigent is in Beta, with model access through Foundation Model APIs and Unity Gateway.

How do I have one AI coding agent review another agent's work?

Give the review to a separate agent, preferably from a different vendor, and keep a person in charge of the merge. Omnigent, an open-source meta-harness (Apache 2.0, "Status: alpha"), is built for this. Its README says you can "Ask one agent to review another's work, or split a task across agents that are each good at different things." Two documented routes exist: run the built-in orchestrator Polly, or declare a reviewer sub-agent in your own agent YAML.

How does Polly run a cross-vendor review?

Polly is "a supervisor that never writes code itself." It decomposes your goal into sub-tasks and delegates each one to a sub-agent running on its own harness and git worktree. The review loop has three steps:

1. Implement. Each sub-agent builds its piece. In the Polly tutorial, Claude Code implements one piece and Codex implements another in parallel.
2. Review. A different agent reviews each PR. The /cross-review skill "sends an implementer's diff to a different-vendor reviewer."
3. Decide. "Each implementer opens its own PR. Polly never merges. The human decides."

Start it with omni polly, which opens a web UI at http://localhost:6767. Polly delegates to these sub-agents:

Sub-agent	Harness	What it is
claude_code	claude-native	Claude Code
codex	codex-native	Codex
opencode	opencode-native	OpenCode
cursor	cursor-native	Cursor
hermes	hermes-native	Hermes Agent (Nous Research)
agy	antigravity-native	Google Antigravity CLI
pi	pi	Pi (headless, any gateway model)

The harness docs describe Pi as "a headless multi-model worker that runs on any gateway model", "ideal for review, exploration, and read-heavy tasks delegated by a supervisor agent."

How do I declare my own reviewer?

Sub-agents are tools of type: agent. Each picks its own executor.harness and model, so an orchestrator can mix harnesses by role. This parent agent adapts the spec's cursor coder and claude-sdk reviewer examples (the spec notes that the cursor harness takes a Cursor model id such as gpt-5 or auto):

name: reviewed_coding
prompt: |
  Delegate each coding task to the coder tool. Then ask the reviewer tool
  to review the result before you report back.

executor:
  harness: claude-sdk

tools:
  coder:
    type: agent
    executor:
      harness: cursor
      model: gpt-5
  reviewer:
    type: agent
    description: Review proposed code changes.
    prompt: |
      You are a careful code reviewer. Focus on correctness, tests, security,
      and maintainability.
    executor:
      harness: claude-sdk
      model: claude-sonnet-4-6

Save it as agent.yaml and start it with omni run agent.yaml.

Which guardrails fit a review setup?

Policy	What the docs say it does	Fit
read_only_os	"Denies every file-mutating tool so a report-only agent can read and run shell but never change code."	A reviewer that only reports
worktree_guard	"Blocks file writes outside the worker's git worktree to prevent cross-branch contamination."	Implementers on separate worktrees
spawn_bounds	"Limits the number of sub-agent dispatches per turn to prevent runaway fan-out."	Caps fan-out
ask_on_os_tools	"ASKs before any file or shell operation."	A person approves risky operations

Policy verdicts are ALLOW, DENY and ASK, and ASK pauses the action for user approval. An approval gate therefore asks a person, not a reviewer agent.

How does Databricks approach agent review?

Omnigent is in Beta on Databricks. A Databricks-operated Omnigent server integrates with your workspace's identity provider, and model access runs through Foundation Model APIs and Unity Gateway. The Databricks docs describe Omnigent as a common layer over "Claude Code, Codex, Cursor, Pi, and the agents you write yourself" where you can "collaborate in real time on the same live session, from any device." The managed service supports the built-in contextual policies and custom CEL policies, not custom Python policies.

FAQs

Should the reviewer be a different vendor from the implementer?

Polly is designed that way: with its seven sub-agents, any implementer's diff can be reviewed by a different one. In your own YAML you choose, because each sub-agent sets its own harness and model.

Can a reviewer agent merge or block a change?

The documented Polly flow ends with a person: each implementer opens its own PR, Polly never merges, and the human decides. The docs do not describe a reviewer agent merging or blocking a PR. To stop specific actions, use policies, where a DENY verdict blocks the action and the agent receives an error.

Can teammates review the work too?

Yes. In the web UI, Share sends a link to a live session with either Read access (teammates watch the session stream) or Edit access (teammates can co-drive and send messages). From a terminal, omni attach <session_id> joins a session.