Why use apra-fleet when Claude and Antigravity both support native agents?

[kumaakh]

Both Claude Code and Antigravity (agy) support agentic orchestration natively -- subagents, background tasks, and large-context planning. You can run a multi-step workflow in either CLI without any extra infrastructure. So why add Fleet on top?

What native orchestration can't do

Native subagents are single-provider. Claude's subagents are Claude processes; agy's are agy processes. Neither system can dispatch across the boundary: you cannot have a Claude PM send a task to an agy doer and then route the output to a Claude reviewer -- not without writing that coordination yourself. Fleet makes that routing a first-class operation.

Cross-provider collaboration

Fleet treats every LLM CLI process as a "member" with a uniform lifecycle: register, dispatch, monitor, remove. The PM doesn't know or care whether a member is running Claude or agy. That means:

• A Claude PM can dispatch an agy doer (Gemini 3.1 Pro) for construction, then a Claude reviewer (Opus) for architecture sign-off.
• An agy PM can dispatch Claude doers on a long-context task and route findings back.
• A sprint workflow written for Claude runs against agy with no code change -- the PM skill is provider-agnostic.

Neither native system can express "send this task to a different provider and collect the result." Fleet's execute_prompt does it uniformly across Claude, agy, Codex, Copilot, and Gemini.

Cross-machine fleets

Native subagents run as local child processes on a single machine. Fleet members can live on any host reachable over SSH: your laptop, a build server, a GPU box. One PM can dispatch agy doers on one machine and Claude reviewers on another, with Fleet managing transport, auth, and process lifecycle transparently. No orchestration YAML, no dashboards -- you describe what you want in conversation and Fleet carries it.

Tier-based model selection

Fleet's dispatch API takes a tier hint -- cheap, standard, or premium -- and each provider maps the tier to its own model. For agy today: cheap maps to gemini-3.5-flash-lite, standard to gemini-3.5-flash, and premium to claude-sonnet-4.6 (written into the workspace settings before each dispatch). For Claude: haiku, sonnet, and opus. The PM requests a tier; Fleet handles the provider-specific model ID. A user-level config override (config.json) is coming in a follow-on release. Native CLIs leave model selection as a per-call argument with provider-specific IDs -- no portable abstraction across a mixed fleet.

Provider-agnostic infrastructure

The PM skill, beads task tracking, MCP server configuration, git authentication, and the credential store all work uniformly across any provider combination. You write a sprint workflow once; it runs whether your PM is Claude or agy, and whether your doers are local or remote. Native subagent systems each impose their own task model and tooling surface.

When to skip Fleet

If your entire workflow is single-provider and single-machine, native subagent orchestration is lighter. Fleet's value scales with the number of providers and machines you want to coordinate. For a solo Claude-only session, claude -p is all you need.

---

A note for users still on the standalone Gemini CLI

Google is phasing out the standalone Gemini CLI in favor of Antigravity (agy). If your Fleet setup currently uses gemini, consider migrating to agy:

1. Google's new coding-agent investment is in agy; the gemini-cli repo now points new users at agy.
2. Agy supports parallel dispatch; the standalone gemini CLI does not (gemini PMs serialize all fleet operations).
3. Agy gives access to the Gemini family + Claude models + GPT-OSS through one CLI.
4. Fleet supports agy as a first-class provider with the same flags and workflows.

Migration is straightforward: apra-fleet install --llm agy on the PM, point new sprints at it. The gemini-CLI path in Fleet stays supported for existing users.

[kumaakh]

Short answer: Native agents solve bounded reasoning tasks elegantly within a single provider session. Fleet solves execution, persistence, and cross-provider orchestration -- and uses native agents internally for the parts they are good at.

---

The standout advantage: one session, any provider

From a single Claude Code PM session you can dispatch work simultaneously to a Claude Code member, a Gemini CLI member, an Antigravity (agy) member, and a Codex CLI member -- each running their native CLI on any machine including but not limited to the local machine, coordinated by one PM that speaks to all of them through the same interface. No provider lock-in. No separate orchestration tool per provider. One session drives the whole fleet.

Native agents cannot do this. A Claude subagent can only spawn Claude children. A Gemini ADK orchestrator can only spawn Gemini children, and there are nuances which make long running tasks still difficult. Fleet is the only path to a genuinely mixed-provider team for long to very long running tasks.

---

Where the gaps appear

Concern	Native API Agents	apra-fleet
Mixed providers (Claude + Gemini + agy + Codex)	No -- single provider only	Yes -- any mix, one PM session
Parallel subagents	Yes (Claude) / No (Gemini, sequential only)	Yes -- each member is an independent process
Cross-machine execution	No -- API only	Yes -- SSH to any remote machine
Local execution (no SSH)	Yes	Yes -- local members run natively, no overhead
Real shell / build tools	No -- every tool must be explicitly wrapped	Yes -- full CLI session, git/npm/cargo/make out of the box
Long-running tasks (hours)	No -- context window bound, no resume	Yes -- progress.json + git survives overflows and restarts
PM restart survival	No -- state lost	Yes -- state lives in files on disk
Short bounded reasoning tasks	Yes -- clean and fast	Yes -- local members are equally fast; remote adds SSH latency

The Gemini CLI gap specifically: The gemini CLI does not support running subagents in the background. Every subagent call blocks until it returns -- you can only run one at a time. Claude Code's Agent(run_in_background=True) dispatches dozens of parallel subagents simultaneously. If Gemini is in your stack, fleet is the only practical path to parallel multi-agent execution.

---

Claude, Gemini, and agy as fleet members

Fleet supports all three as execution targets today:

Feature	Claude Code member	Gemini CLI member	agy member
Background parallel subagents	Yes	No -- sequential only	Yes -- parallel dispatch supported
Full shell / file system access	Yes	Yes	Yes
Long-running sessions	Yes	Yes	Yes
Local execution (no SSH)	Yes	Yes	Yes
Auth automation (provision_llm_auth)	Yes	Yes	No -- agy auth is per-machine, set up out of band: interactive browser OAuth or ANTIGRAVITY_API_KEY env var
Workspace .ignore MCP block (local)	Yes	Yes	Not yet (issue nx4)
Tier-to-model mapping	Fixed per model name	Fixed per model name	Configurable per workspace via settings.json
Supported in fleet today	Yes	Yes	Yes (v0.2.1+)

---

Fleet already uses native agents -- for the right layer

Fleet is not an alternative to native agents. The PM spawns Claude API subagents to manage parallel fleet calls -- each approach doing what it does best:

PM (Claude Code)
  +-- Agent(run_in_background=True)   <- native API agent: parallelism, context isolation
        +-- execute_prompt            <- fleet: real CLI session on a real machine
              +-- claude -p / gemini / agy running on target OS

---

Where this is heading

Google's A2A (Agent-to-Agent) protocol -- open-sourced April 2025, with growing cross-vendor support -- defines a standard JSON-RPC interface for agents from different frameworks to communicate. Fleet's inter-member messaging roadmap (issue #152) is tracking A2A as a potential transport, making the cross-provider story even stronger: members become standard endpoints, not just SSH targets.

---

The honest summary

For bounded single-provider reasoning tasks, native agents are simpler. Fleet wins when you need work to run in real CLI sessions, outlast a context window, survive a restart, span multiple LLM providers, or reach remote machines. The multi-provider angle alone -- driving Claude, Gemini, agy, and Codex from one PM session -- is something no native agent framework offers today.