Orchestrating Multiple AI Agents in Parallel via Custom Skills
Series 1/2: Multi-Model Collaboration & Quota Management in Practice
As of Q4 2026, how do you collaborate with AI agents to get real work done?
Ever since we first opened ChatGPT and typed a prompt three years ago, we have been conditioned to ask an AI a question and wait for its reply. Whether on a free tier or a paid plan, whenever an agent gets stuck, gives an underwhelming answer, or hits a usage rate limit, our reflex has been to switch to another agent and try again.
Starting earlier this year, a wave of agent-switcher tools appeared to help developers jump between CLIs faster—soon followed by skills that back up, sync, and restore state so another agent can pick up where the last one left off. Even so, every handoff breaks your momentum, leaving the workflow fragmented and stop-and-go.
Since late last year, I have been distilling more than a decade of engineering notes and practices into a structured personal workflow and knowledge repository, paired with a lightweight translation layer so different agents can natively read and reason over the same context. I have validated that setup across Claude Code, Gemini CLI, OpenAI Codex, Pi, and more.
After receiving Early Access Program (EAP) access to Gemini 4 Argon ahead of its release last week, I began seriously shifting my primary driver to Gemini 4: running Google Antigravity (AGY, powered by Gemini 4 Argon) as the main control plane for long-context architectural reasoning and multimodal screenshot inspection, while still bringing in OpenAI Codex (gpt-6-sol) to stress-test edge cases and Claude Code (Sonnet 5.5) in a QA/PM role to review project and architectural details.
The old way of doing this was clumsily manual: open two terminal windows, copy-paste the same screenshot path and background context twice, wait for both runs to finish, and compare them by eye.
This week, I converged that entire loop into Google Antigravity's Skills (SKILL.md) and non-blocking invoke_subagent mechanism. Now I only have to mention the agents in a single prompt, and the primary agent automatically splits the task, runs them in parallel in the background, and wakes the main window back up to cross-compare the findings.
Built-In Slash Commands vs. Cross-Model Skills
Typing / in Antigravity already gives you three built-in multi-agent and deep-reasoning commands:
| Command | Under the hood | Best for |
|---|---|---|
/teamwork-preview |
Uses define_subagent and invoke_subagent to spin up role-specific subagents, optionally in isolated Git worktrees |
Splitting frontend, backend, and test work in parallel |
/boost |
Forces strategic planning and spawns multiple subagents to verify a problem from different angles | Architecture trade-offs and hard root-cause analysis |
/goal |
Runs an autonomous edit-verify-fix loop until the goal criteria pass | Long migration, build, and test-fixing runs |
Those built-in commands are great, but by default every subagent they spawn runs on the same underlying model family.
If a model family has a blind spot on a specific API or OS quirk, three instances of the same model can share the same blind spot. What I wanted was heterogeneous multi-model execution inside Antigravity—without bloating the main conversation's context window.
How It Works: Progressive Disclosure + Reactive Wakeup
Antigravity loads user skills from ~/.gemini/config/skills/<name>/SKILL.md using progressive disclosure:
At session startup, only the YAML frontmatter (name and description) is injected into the system prompt. The full SKILL.md instructions are read only when a prompt invokes that skill.
I added two global skills:
-
~/.gemini/config/skills/agent-codex/SKILL.md: Spawns a background subagent that invokescodex exec(gpt-6-sol). -
~/.gemini/config/skills/agent-claude/SKILL.md: Spawns a background subagent that invokesclaude(claude-sonnet-5-5).
The core of agent-codex/SKILL.md is straightforward:
---
name: agent-codex
description: Spawn an asynchronous Antigravity subagent that runs OpenAI Codex CLI (gpt-6-sol) in parallel with the primary agent, then synthesize both perspectives.
---
# SOP
1. Call `invoke_subagent` (`TypeName: "self"`, `Role: "Agent Codex (gpt-6-sol)"`).
2. Inside the subagent, pipe the task prompt and any image paths (`-i <img_path>`) to `codex exec -m gpt-6-sol --skip-git-repo-check -`.
3. Do NOT poll in a loop. Continue primary-track work or end the turn; Antigravity's Reactive Wakeup resumes automatically when the subagent returns.
4. When woken up, compare agreements, disagreements, and blind spots caught by each model.
The most important rule here is no polling.
When the primary agent calls invoke_subagent, it immediately gets back a conversationId and can keep working on the main track (or end its turn). When the background subagent finishes running codex or claude, Antigravity's Reactive Wakeup automatically resumes the main agent with the subagent's report:
sequenceDiagram
autonumber
actor Dev as Developer
participant AGY as Google Antigravity (Gemini 4 Argon)
participant Sub1 as Subagent · agent-codex (gpt-6-sol)
participant Sub2 as Subagent · agent-claude (Sonnet 5.5)
Dev->>AGY: Build & audit Leap EDGE across macOS and Ubuntu using agent-codex and agent-claude
par Parallel Non-Blocking Execution
AGY->>AGY: Primary track — macOS Swift CoreGraphics HUD & Universal Makefile
and Background Track A
AGY->>Sub1: invoke_subagent (Role = Agent Codex)
Sub1-->>AGY: Reactive Wakeup — catches missing Pace Badge draw call + builds Linux X11 client
and Background Track B
AGY->>Sub2: invoke_subagent (Role = Agent Claude)
Sub2-->>AGY: Reactive Wakeup — sets up headless Xvfb/X11 E2E screenshot verification
end
AGY->>Dev: Synthesizes code, fixes, and visual verification screenshots
Did It Actually Catch Bugs the Primary Track Missed?
Yes—on the very first run.
While building the initial macOS version of our quota widget (leap-edge.swift), the primary track wrote the JSON parser and CoreGraphics card renderer. Meanwhile, agent-codex audited the file in the background and flagged an immediate omission:
The parser computed
badgeText(▲ RUNS OUT 11:30vs.⏱ LASTS TO RESET), butdrawWinBlocknever actually drew the badge pill onto the card.
Along with patching the CoreGraphics pill renderer, it pointed out three energy optimizations for running an always-on widget on a fanless M1 MacBook Air:
- Observe
NSWindow.didChangeOcclusionStateNotificationso the 60-second clock redraw pauses whenever the desktop widget is completely covered by a full-screen window. - Cache
DateFormatterinstances instead of allocating them inside the draw loop. - Use
URLSessionConfiguration.ephemeralfor the 300-second quota poll to avoid unnecessary disk cache writes.
When we extended the widget to Ubuntu on a ThinkPad X1 Carbon and a Surface Pro 7 tablet (running Ubuntu X11 with auto-rotation), the same split workflow shone: agent-codex implemented the responsive horizontal/vertical card geometry, agent-claude ran the remote X11 capture pipeline, and Gemini 4 Argon inspected the resulting screenshots directly to catch text-overlap issues on narrow portrait cards.
When I Use Single-Track vs. Multi-Agent Parallel
Running three models on every typo fix would be a waste of quota. Here is the rule of thumb I use:
| Workload | Approach |
|---|---|
| Small copy edits or isolated UI tweaks | Single-track in the primary Antigravity session |
| Core algorithms, OS integration, or security boundaries | Primary track + agent-codex background source-truth audit |
| Feature implementation + test/verification harness | Auto-split across agent-codex and agent-claude in parallel |
| Cross-device UI layout tuning (macOS Retina / Linux X11 / portrait tablets) | Subagent edits & captures screenshots → Gemini 4 Argon inspects the images |
Once you start fanning work out across Gemini, Claude, and Codex simultaneously, though, you immediately run into a new operational problem:
Each provider has its own 5-hour and weekly sliding quota windows. Which one is about to hit a rate limit first?
In Part 2, I'll show how we built Leap EDGE—a 483 KB, 0% idle CPU native macOS and Ubuntu HUD that replaces useless "40% used" bars with pace-aware run-out predictions.


Top comments (0)