Getting AI Agents to Delegate Work and Review Each Other’s Code

My model-delegation setup includes Gemini through Antigravity CLI (agy), Claude, and Codex. Having one model review the other’s work has caught defects I would otherwise have published. The useful reviews find something I can check: a missing requirement, an incorrect assumption, or a case the tests did not cover.

I also delegate implementation work to agents. That needs a different set of rules. Splitting a substantial task can help, but asking another agent to change one link creates a briefing, a handoff, and a report for work the main agent could have finished directly.

I wrote a model-delegation skill to make those decisions more consistent. It covers what the main agent should keep, what it can delegate, and when another model should challenge the result. I maintain versions for Claude and Codex, with Gemini available as a reviewer in both. The reviewer changes depending on which tool is doing the implementation and what context the review needs.

Get my model-delegation skill on GitHub (opens in a new tab). The MIT-licensed version is adapted from my local skills. I have removed model-version tables, prices, and machine-specific wrapper paths so the instructions can be used with a different setup.

Give delegation and review different jobs

My skill separates two uses of another agent:

The main agent keeps responsibility for the result. A subagent can write code within its assigned scope. The reviewer reports findings and never writes production code in this workflow. The main agent decides which findings are valid, makes the fixes, and checks them.

That distinction matters when I have more than one AI subscription. I can use Codex for implementation and ask Gemini or Claude to review the change. When Claude handles implementation, Codex or Gemini can take the review. I get another use for tools I already have without moving the whole task between them.

A skill does not connect those accounts or combine their usage allowances. My local setup uses CLI wrappers to invoke the reviewer. A manual handoff works too: start a separate session, provide the review material, and bring the findings back to the main agent. I have not measured a cost saving from this workflow; the benefit I can point to is defects caught before I publish a change.

Keep small and unclear tasks with the main agent

The first decision is whether another agent is useful at all.

For a small change, I want the main agent to act. For an unclear problem, I want it to investigate until there is a task worth handing over. Asking an agent to “look into this” while another agent does the same investigation usually gives me two accounts of the problem and another decision to make.

A good delegation candidate has a clear boundary. During this website’s move from JSX articles to Markdown, groups of posts could be converted independently once the content format was agreed. The shared renderer and routing decisions needed to stay coordinated by the main agent.

My Codex version of the skill also distinguishes reasoning effort from model choice. If the runtime supports that control, I consider more reasoning before switching models. A well-defined mechanical task can use a lighter model; a task that needs judgment gets a more capable one. I keep the exact model names in my local configuration because those choices change.

Do not delegate something that would take more effort to explain and review than to do.

Make the assignment specific

An implementation task needs a result and a boundary. Here is the kind of brief I would use for one part of the blog migration:

Convert the three assigned articles to Markdown.

Scope: only the three destination files listed in this task. Preserve the current prose, links, examples, and published section IDs. Use the agreed frontmatter and diagram format. Do not change the shared renderer or delete the source pages.

Compare the conversion with the source. Report any content you could not represent, the checks you ran, and the files you changed.

The main agent would supply the actual paths and the format definition alongside that brief. The subagent should not need to infer which files it owns.

I avoid assigning two agents the same files. If their work depends on a shared interface, I settle that interface first. Otherwise, parallel work turns into reconciliation: both agents can finish their assignments and still produce changes that do not fit together.

Ask the reviewer to challenge the change

My local skills call for review in three cases: a high-risk change, an architecture sanity check, or a disagreement that needs a tiebreak. I prefer a different provider and use the reviewer’s default or strongest available model. I do not add a subagent from the same model family just to verify the main agent’s work; the main agent already owns those checks.

By adversarial review, I mean looking for reasons the change might fail. I want the reviewer to question assumptions and trace behavior beyond the edited lines. I do not want it to invent problems to satisfy a request for criticism.

This is the shape of the review request I use:

Review this change against the supplied requirements. Do not edit files.

Look for incorrect behavior, missed requirements, edge cases, and tests that pass without checking the intended result. Inspect relevant callers and configuration where your read-only tools allow it.

For each finding, give the location, impact, and supporting evidence. Separate reproduced defects from suspected issues and optional improvements. State what you could not inspect or verify.

Report significant findings first. If there are none, say so.

The reviewer needs the requirements as well as the code. It cannot identify a missing behavior if nobody told it that behavior was required. I also provide what was tested and any relevant limits, such as a service that cannot be run locally.

A diff is sometimes enough for a narrow fix. For a migration, I prefer a reviewer that can inspect the repository. New files may be missing from the supplied diff, and callers or configuration can explain behavior that looks correct in isolation. The reviewer does not inherit the conversation that produced the change; that context has to be supplied deliberately.

What Claude caught on this website

The Markdown migration is a useful example because it happened on a personal project, and the findings are specific.

Codex converted all twelve existing posts to Markdown and added a shared article route. The work included preserving URLs, section anchors, code examples, diagrams, and related articles. Tests and the production build passed. I then asked Claude to review the changes without editing them.

Claude found problems that the checks had missed:

The review also identified a likely contents-highlighting problem. The old implementation observed full sections; the new IDs were on headings. Scrolling back up could leave the lower heading selected. We changed the selection logic and checked both scroll directions in the browser.

Some findings needed careful attribution. The title regression came from the article rewrites around the migration. A Docker health-check problem predated the migration entirely. Both were worth fixing, but they were not evidence that the Markdown conversion had lost content.

Claude’s review was not exhaustive either. A Markdown code example still had a layout bug: Prism’s table token class collided with Tailwind’s display: table utility. I noticed that on the page, and we fixed it separately. The same code block and conflicting styles existed before the migration; this was another pre-existing defect.

This is why I value the extra review. It produced concrete corrections. It is also why I would not turn this one example into a claim that a particular model pair is always better, faster, or cheaper.

Verify findings before accepting them

A finding is a claim about the code. I want the main agent to check it, not treat another model’s confidence as authority.

For a reported failure, that might mean running the supplied reproduction, adding a focused test, inspecting the generated output, or checking the page in a browser. A style preference does not carry the same weight as a broken route. A suspected issue should stay labelled as suspected until there is evidence.

The loop also needs an end. After a small confirmed fix and the relevant checks, I do not automatically ask for another complete review. I ask again when the fix changes the design or leaves a material concern unresolved. Otherwise, review can keep generating work after the original task is complete.

Read-only means a permission boundary

My local skill points to wrappers that start the reviewer with restricted tools. The reviewer reports findings, and the main agent makes the changes. Keeping those roles separate makes the result easier to inspect.

In the website example, I asked Claude not to edit files, and it reported that it had left the files unchanged. That establishes compliance with a prompt, not an enforced read-only boundary.

“Do not edit files” in a prompt is an instruction. The tool permissions or workspace restrictions have to enforce it. A review environment also needs access to enough context to do useful work. My local wrappers differ in that respect: one can inspect repository files, while another only sees the material passed into its isolated workspace. In my setup, the Claude review wrapper can inspect the repository. The Antigravity CLI review wrapper runs in an isolated workspace, so I must supply the diff and any surrounding code it needs. That is a limit of my wrapper configuration, not a general limit of Gemini.

The skill records that distinction so the main agent does not assume both reviewers saw the same evidence. If a reviewer cannot inspect a caller, it should say so. That is a reason to supply more context or choose another review route, not to quietly give the reviewer write access.

Connect the tools with an existing plugin

You do not need to write your own CLI wrappers to try this. My skill supplies the rules for deciding when to delegate or review. A plugin can handle calling the other tool and returning its result.

These projects cover several directions. I checked their documentation for this article; I have not tested every integration end to end.

For Google’s terminal workflow, this article uses Antigravity CLI (agy). Google’s transition announcement (opens in a new tab) ended Gemini CLI access through its free individual, Google AI Pro, and Ultra plans on June 18, 2026, while retaining enterprise and paid API access. If you have an older setup, follow the Antigravity CLI migration guide (opens in a new tab).

• Codex inside Claude Code — OpenAI’s official plugin (opens in a new tab). It provides /codex:review for a read-only review and /codex:adversarial-review for a review with a specific focus. It uses your local Codex installation and authentication. It also supports implementation handoffs, which go beyond the reviewer role I give external models in my workflow.
• Claude Code inside Codex — community plugin (opens in a new tab). This project exposes your local Claude Code CLI through an MCP server, so Codex can request a review, plan, or second opinion. It requires Claude Code to be installed and signed in. It is a community integration, not an official counterpart to OpenAI’s plugin.
• Antigravity CLI from Claude Code or Codex — Ask Antigravity (opens in a new tab). This community plugin calls agy for reviews and delegated tasks. It requires the Antigravity CLI to be installed and authenticated; installing the IDE alone is not enough. Its review commands return findings to the main agent. The host must enforce filesystem restrictions for a read-only review.
• Codex from Antigravity CLI — community plugin (opens in a new tab). This project calls your local Codex CLI from Antigravity. Its agy integration provides review and adversarial-review commands, along with background job controls. Follow its Antigravity CLI installation instructions; the app and IDE use a different interface.

For example, OpenAI documents this setup inside Claude Code:

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup
/codex:review

Start with one explicit review. Some plugins can trigger reviews automatically or delegate edits as well. Choose the review command and check its permissions before treating it as the read-only workflow described here. Connecting the tools does not grant permission to share a repository with another service.

Similar skills worth reading

Other authors have packaged this idea too. Two examples are particularly close to the review part of my workflow:

• Trail of Bits: second-opinion (opens in a new tab). A skill for reviewing uncommitted changes, branch diffs, or individual commits with an external CLI. Its current instructions cover Codex and Antigravity CLI (agy). It returns findings without applying fixes.
• PGHQdev: second-opinion (opens in a new tab). A Claude Code plugin and portable skill focused on reviewing risky plans before implementation. Its hook can request an adversarial review through tools such as Codex or OpenCode. It includes a self-review fallback, which differs from my preference to skip a redundant same-family verifier.

If you only need an external review, one of these may already cover the job. My skill also covers whether to delegate implementation, how to divide file ownership, and when to stop asking for more reviews. You can use those rules with an existing integration instead of maintaining another set of wrappers.

Try the skill on one substantial change

The published SKILL.md (opens in a new tab) keeps the main decisions from my local versions and adds rules for a portable setup. The additions cover when to stop reviewing, reproducing findings, avoiding a quota of findings, keeping file ownership separate, and not installing services or buying access without permission. It does not include the CLI wrappers or assume that every tool supports the same models and reasoning settings.

For a repository-scoped experiment, save it as .claude/skills/model-delegation/SKILL.md for Claude Code or .agents/skills/model-delegation/SKILL.md for Codex. Invoke it with /model-delegation in Claude Code or $model-delegation in Codex CLI. These locations and invocation methods are covered in the Claude Code skills documentation (opens in a new tab) and OpenAI’s skills documentation (opens in a new tab).

Give it one change with clear acceptance criteria. Check whether it keeps small work local, hands off a useful task, and gives the reviewer enough evidence. Keep a record of the findings you accept and reject. That will tell you more about whether the workflow helps than the length of either model’s report.

I use my writing standard alongside this skill to keep the handoffs and findings readable.