Google Antigravity vs Conductor

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   Google Antigravity✓fullprobed9/10

   Antigravity hosts a working llms.txt (HTTP 200) describing itself, and provides markdown-formatted docs pages (e.g. getting-started.md) that an agent can fetch directly, confirming genuine agent-oriented documentation support. Missing for 10: independent third-party confirmation that agents actually consume these successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://antigravity.google/llms.txt # Google Antigravity > Google Antigravity is an advanced agentic coding pla…”
   • [probe] “PROBE docs-md: HTTP 200 at https://antigravity.google/docs/getting-started.md # Getting Started with Antigravity 2.0 ### Download Visit [a…”
   • [claimed-docs] “Visit antigravity.google/download to download Google Antigravity 2.0. Select your operating system below”

   proof ↗⚑ flag

   Conductor✓fullprobed9/10

   Direct probe confirms llms.txt is live and served at https://www.conductor.build/llms.txt with agent-oriented summary, plus a full docs.md markdown mirror for agent consumption. missing for 10: no independent/community confirmation that external agents actually consume these files successfully.

   • [probe] “PROBE llms.txt: HTTP 200 at https://www.conductor.build/llms.txt # Conductor > Conductor is a Mac app that lets you run many coding agents …”
   • [probe] “PROBE docs-md: HTTP 200 at https://www.conductor.build/docs.md --- title: "Introduction" url: "/docs" description: "Learn what Conductor is …”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Google Antigravity
   Google Antigravity✓fullclaimed7/10

   Antigravity CLI has a documented headless mode explicitly for scripting agent tasks, CI pipeline integration, and machine-readable output (antigravity-docs-50), plus scheduled/cron tasks and background subagents support agentic automation outside interactive UI. Missing for 10: independent hands-on CI usage reports, concrete CI config examples/output schema, and no community corroboration of headless/CI use in practice.

   • [claimed-docs] “Run Antigravity CLI non-interactively to script agent tasks, integrate with CI pipelines, and capture machine-readable output.”
   • [claimed-docs] “Automate routine checks with Scheduled Tasks, simply define a cron schedule and the agents start and run autonomously in the background.”
   • [claimed-docs] “Edit, orchestrate, and build all in natural language. Tell your agents what you need, and they’ll work on getting it done.”
   • [claimed-docs] “Create or download fully customizable skills to further your agent’s autonomy and transform how you get work done.”

   proof ↗⚑ flag

   Conductor~partialprobed6/10

   Conductor supports scheduled/CI-like automation via 'routines' that run on a schedule or GitHub Action, plus a programmatic API and hosted MCP server for managing cloud workspaces headlessly, and cloud agents can run builds/tests without confirmation. However, it is fundamentally a Mac GUI app, and there's no evidence of a standalone CLI or true headless binary for arbitrary CI pipelines outside GitHub Actions. missing for 10: dedicated CLI/headless binary for generic CI systems, independent evidence of routines/GitHub Action working reliably in production, clarity on full non-interactive operation outside the Mac app.

   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round to Google Antigravity
   Google Antigravity✓fullclaimed8/10

   Antigravity has explicit, dedicated MCP documentation stating MCP lets it 'fetch structured context directly or execute safe actions on your behalf' and that it 'securely connects to local developer tools, databases, file parsers, and external remote APIs' via MCP, plus CLI/SDK support for configuring MCP servers (slash commands, plugins bundling MCP servers, layering MCP servers in the Agent SDK). Missing for 10: independent hands-on confirmation of successfully connecting a third-party MCP server and using its tools in a real workflow.

   • [claimed-docs] “MCP lets Antigravity fetch structured context directly or execute safe actions on your behalf when needed.”
   • [claimed-docs] “lets AI agents and editors securely connect to local developer tools, databases, file parsers, and external remote APIs”
   • [claimed-docs] “Access plugins, MCP, skills, and hooks configurations instantly via slash commands, quickly enhancing your workflow.”
   • [claimed-docs] “Layer custom Python callables, Model Context Protocol (MCP) servers, and reusable agent skills over our built-in filesystem and terminal too…”
   • [claimed-docs] “Plugins are namespaced bundles that allow you to extend Antigravity’s capabilities by grouping skills, rules, MCP servers, and hooks into a …”

   proof ↗⚑ flag

   Conductor—none0/10

   Evidence only shows Conductor exposing its OWN hosted MCP server so external MCP clients (ChatGPT, Claude, Codex) can manage Conductor's cloud workspaces (conductor-docs-14, conductor-probe-4) — the reverse direction of what the story asks. There is no documentation or community mention of a user being able to add/configure external MCP servers inside Conductor so its hosted coding agents (Claude Code, Codex, Cursor, OpenCode) can consume their tools.

   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
   • [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Google Antigravity
   Google Antigravity✓fullprobed8/10

   Google Antigravity ships an official CLI with dedicated docs (antigravity-cli product page, headless/non-interactive mode for CI, sandboxing, vim mode, gcli migration), enabling natural-language orchestration of parallel agents, slash commands, and MCP/plugin config — clearly AI-native and agentic. Community evidence corroborates the CLI works in practice alongside VSCode. Missing for 10: independent deep-dive review of CLI-specific reliability/performance beyond a single community mention.

   • [claimed-docs] “Edit, orchestrate, and build all in natural language. Tell your agents what you need, and they’ll work on getting it done.”
   • [claimed-docs] “Have multiple agents working in parallel, so larger tasks get tackled faster.”
   • [claimed-docs] “Navigate your entire workflow via standard terminal shortcuts: adjust permissions, themes, and preferences via /config and type /keybindings…”
   • [claimed-docs] “Access plugins, MCP, skills, and hooks configurations instantly via slash commands, quickly enhancing your workflow.”
   • [claimed-docs] “the CLI automatically detects your existing profiles. An interactive checklist prompts you to choose which assets to migrate”
   • [claimed-docs] “Sensitive files like ~/.ssh and .env are blocked, anything not explicitly mounted is invisible inside the sandbox”
   • [claimed-docs] “Vim editor mode replaces the editing model in every multi-line input surface of the CLI”
   • [claimed-docs] “Run Antigravity CLI non-interactively to script agent tasks, integrate with CI pipelines, and capture machine-readable output.”
   • [community] “I much prefer using Gemini CLI in combination with vscode. It works like a charm. Now, I'll do the same with Antigravity CLI and vscode. It …”
   • [probe] “official CLI documented at https://antigravity.google/product/antigravity-cli”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor is documented as a Mac GUI app with a programmatic API and hosted MCP server, but no evidence pack item describes an official Conductor CLI tool; the only CLI mention is a user leveraging their own 'local GitHub CLI auth', which is unrelated.

   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Conductor
   Google Antigravity~partialprobed6/10

   Antigravity documents an Agent SDK (Python) exposing the same tools/agent loop/context management as the app, plus a CLI headless mode for scripting and CI integration, both of which let an AI-native user drive the product programmatically. However, there is no evidence of a formal public REST/HTTP API — a probe for OpenAPI/swagger specs returned 404 on all candidate paths, so the 'documented public API' is limited to SDK/CLI surfaces rather than a conventional API contract. Missing for 10: a documented REST/HTTP API or OpenAPI spec, independent third-party confirmation of SDK usage/stability.

   • [claimed-docs] “The Agent SDK gives you the same tools, agent loop, and context management that power Google Antigravity, programmable in Python.”
   • [claimed-docs] “Layer custom Python callables, Model Context Protocol (MCP) servers, and reusable agent skills over our built-in filesystem and terminal too…”
   • [claimed-docs] “Build AI agents that autonomously read files, run commands, edit code, and more.”
   • [claimed-docs] “Run Antigravity CLI non-interactively to script agent tasks, integrate with CI pipelines, and capture machine-readable output.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://antigravity.google/openapi.json, https://antigravity.google/swagger.json, https://antigravit…”

   proof ↗⚑ flag

   Conductor✓fullprobed7/10

   Conductor documents a public API for programmatically managing cloud workspaces (create workspaces, send prompts, read agent replies) plus a hosted MCP server for AI clients like ChatGPT/Claude/Codex to drive it. Missing for 10: a published OpenAPI/reference spec (probe found only 404s for schema files) and independent/hands-on developer corroboration of API usage.

   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
   • [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.conductor.build/openapi.json, https://www.conductor.build/swagger.json, https://www.cond…”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Conductor
   Google Antigravity!disputedcontradicted4/10

   Antigravity documents permission tiers (Deny/Ask/Allow) and a CLI sandbox that explicitly blocks access to sensitive files like .env and ~/.ssh, which is the closest analog to least-privilege credential scoping for an agent (docs-23, docs-42, docs-48). However, independent reports document a concrete bypass: Antigravity's own setting disallowing .env access was circumvented via prompt injection to exfiltrate secrets, and a default allowlisted domain (webhook.site) was used as an exfiltration channel — directly contradicting the claimed least-privilege protection (antigravity-comm-11, antigravity-comm-12). There is no evidence of a true scoped API-credential-issuance mechanism (e.g., minting restricted API keys/tokens for an agent); missing for 10: actual credential/token scoping API, third-party security audit confirming the sandbox holds, and any documented remediation.

   • [claimed-docs] “Permissions are evaluated across three distinct access lists: Deny... Ask... Allow”
   • [claimed-docs] “Permissions are evaluated across three distinct access lists: Deny...Ask...Allow”
   • [claimed-docs] “Sensitive files like ~/.ssh and .env are blocked, anything not explicitly mounted is invisible inside the sandbox”
   • [community] “Google Antigravity exfiltrates data via indirect prompt injection attack: Gemini is not supposed to have access to .env files with default s…”
   • [community] “The default Allowlist provided with Antigravity includes 'webhook.site', which was used as an exfiltration vector for secrets.”

   proof ↗⚑ flag

   Conductor~partialcommunity4/10

   Community threads document that Conductor originally required full read/write GitHub access with no fine-grained scoping, which users flagged as risky; the developers later added a GitHub App integration for fine-grained repo access (or use of local GitHub CLI auth) as a fix, showing partial progress toward least-privilege credentials but not a documented, general mechanism for issuing scoped API credentials for agents beyond GitHub repo access. Missing for 10: no documentation of scoped/least-privilege credentials for the Conductor API/MCP server itself, no explicit policy on token scoping for non-GitHub integrations, and no independent verification that the new GitHub App permissions are truly minimal in practice.

   • [community] “Any way to have it not require full write access to your entire GitHub account?”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
   • [community] “I was really excited to try this but this does NOT work the way I expected. I wanted a simple git worktree manager for my existing, already-…”
   • [community] “Right now the app uses GitHub's OAuth sign in which unfortunately doesn't allow for fine-grained permissions... We're switching our sign-in …”
   • [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”
   • [claimed-docs] “Bring your own subscriptions and keys”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Google Antigravity
   Google Antigravity✓fullprobed7/10

   Google explicitly documents an official Agent SDK ('same tools, agent loop, and context management that power Antigravity, programmable in Python') supporting custom Python callables, MCP servers, skills, and multimedia inputs, which directly satisfies building against an official SDK. Missing for 10: independent/hands-on developer confirmation of the SDK working as documented, and no public API reference/OpenAPI spec was found (probe returned 404s), so depth of documentation beyond marketing copy is unverified.

   • [claimed-docs] “The Agent SDK gives you the same tools, agent loop, and context management that power Google Antigravity, programmable in Python.”
   • [claimed-docs] “Layer custom Python callables, Model Context Protocol (MCP) servers, and reusable agent skills over our built-in filesystem and terminal too…”
   • [claimed-docs] “Pass rich multimedia file attachments (images, videos, audio, and documents) to the agent alongside textual instruction prompt lists.”
   • [claimed-docs] “Build AI agents that autonomously read files, run commands, edit code, and more.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://antigravity.google/openapi.json, https://antigravity.google/swagger.json, https://antigravit…”

   proof ↗⚑ flag

   Conductor~partialprobed5/10

   Conductor documents an official REST-style API for managing cloud workspaces and sending/reading agent prompts, plus a hosted MCP server for AI clients, which supports building AI-native integrations. However, no dedicated client SDK packages (e.g., npm/python libraries) are evidenced, and a probe for an OpenAPI spec returned 404s, suggesting the 'SDK' is really just a raw API/MCP interface rather than a polished, language-specific SDK. missing for 10: official language SDK packages, OpenAPI/schema-based codegen support, independent hands-on confirmation of SDK usage.

   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
   • [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.conductor.build/openapi.json, https://www.conductor.build/swagger.json, https://www.cond…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Google Antigravity—none0/10

   No evidence of any webhook subscription mechanism; Antigravity is an IDE/CLI/agent platform with hooks, MCP, and scheduled tasks, but nothing about outbound event subscriptions via webhooks. Even the openapi probe returned 404s, indicating no public API surface for such integration.

   • [probe] “PROBE openapi: all candidate paths 404 (https://antigravity.google/openapi.json, https://antigravity.google/swagger.json, https://antigravit…”

   proof ↗⚑ flag

   Conductor—none0/10

   The evidence pack documents a programmatic API and an MCP server for managing cloud workspaces, but nowhere mentions webhooks or any event-subscription mechanism for AI-native users to receive push notifications on workspace/task events.

   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Google Antigravity
   Google Antigravity~partialcommunity6/10

   Antigravity's editor/agent generates code suggestions, tab-autocompletion, and rich 'Artifacts' (implementation plans, diagrams, code diffs) that surface AI-derived insights from the user's codebase (antigravity-docs-6, -24, -30, -41), fitting the 'insights from data' story in a coding context. However, this is inference-in-editor suggestion generation rather than dedicated analytics/insight dashboards, and community hands-on reports raise real quality concerns ('the model was not good and slow, the harness was not good' — antigravity-comm-8), undercutting confidence in consistent insight quality. Missing for 10: no evidence of dedicated data-analysis/insight-summarization features beyond code artifacts, and no independent corroboration that suggestions are reliably high quality.

   • [claimed-docs] “Google Antigravity's Editor view offers tab autocompletion, natural language code commands, and a configurable, and context-aware configurab…”
   • [claimed-docs] “Planning Mode: The agent plans thoroughly before executing tasks... produces structured implementation plans called Artifacts”
   • [claimed-docs] “Artifacts include rich markdown plans (Implementation Plans), code diffs, architecture diagrams, images, and browser recordings.”
   • [claimed-docs] “offers tab autocompletion, natural language code commands, and a configurable, and context-aware configurable agent”
   • [community] “It's not even good, honestly. I was using it for couple weeks before dropping that 2 months ago. The model was not good and slow, the harnes…”

   proof ↗⚑ flag

   Conductor~partialclaimed4/10

   Conductor orchestrates third-party coding agents (Claude Code, Codex, Cursor) that analyze the codebase and produce diffs, suggested changes, and PR reviews, which can be seen as data-driven suggestions, but Conductor itself does not document any native analytics/insights engine — the 'insight' generation is delegated entirely to the underlying agents. Missing for 10: no first-party insight/analytics feature, no evidence of Conductor synthesizing patterns or trends from user data beyond agent chat/diff output, no independent corroboration of this specific capability.

   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
   • [claimed-docs] “Checkpoints | Session/workspace | Revert code and chat state to an earlier turn”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Google Antigravity
   Google Antigravity✓fullclaimed8/10

   Docs explicitly describe Scheduled Tasks with cron schedules that let agents 'start and run autonomously in the background' (docs-2), plus related capabilities like scheduling messages to agents while away (docs-39), isolated background worktrees (docs-38), and headless/non-interactive CLI runs for CI automation (docs-50). This directly matches the story of autonomous background automations. Missing for 10: independent/hands-on verification that scheduled background tasks work reliably (community evidence focuses on other bugs/exfiltration issues, not scheduling specifically), and more detail on monitoring/error-handling for unattended runs.

   • [claimed-docs] “Automate routine checks with Scheduled Tasks, simply define a cron schedule and the agents start and run autonomously in the background.”
   • [claimed-docs] “Worktree support: Projects natively support Git worktrees, allowing agents to operate in isolated background folders.”
   • [claimed-docs] “users can schedule messages to be sent to their agents while they’re away”
   • [claimed-docs] “Run Antigravity CLI non-interactively to script agent tasks, integrate with CI pipelines, and capture machine-readable output.”
   • [claimed-docs] “Able to autonomously operate across your editor, terminal, and browser.”

   proof ↗⚑ flag

   Conductor✓fullclaimed7/10

   Conductor's "routines" feature explicitly lets users run agents on a schedule or via GitHub Action, and cloud workspaces continue running autonomously ("agents keep working after you close your laptop") without requiring step-by-step confirmation. This directly matches background, autonomous automation for an AI-native user. Missing for 10: independent/hands-on confirmation that routines work reliably in practice, and more detail on scheduling configuration options beyond the changelog mention.

   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round drawn
   Google Antigravity✓fullcommunity8/10

   Antigravity is built around delegating tasks to autonomous agents that operate across editor, terminal, and browser, with subagents, scheduled tasks, and natural-language task delegation extensively documented; hands-on community reports (comm-1, comm-10) confirm the agent/CLI actually works for delegated tasks. missing for 10: independent third-party benchmarking of delegation quality, and community evidence is mixed on reliability/bugs which caps quality below top marks.

   • [claimed-docs] “Able to autonomously operate across your editor, terminal, and browser.”
   • [claimed-docs] “Edit, orchestrate, and build all in natural language. Tell your agents what you need, and they’ll work on getting it done.”
   • [claimed-docs] “an agent can delegate tasks—such as running tests or performing extensive codebase searches—to dedicated subagents.”
   • [claimed-docs] “Antigravity comes pre-packaged with several specialized subagents out of the box”
   • [claimed-docs] “Antigravity 2.0 serves as your AI agents’ central command center, providing a unified platform to launch, monitor, and orchestrate their act…”
   • [community] “I went ahead and downloaded it, it looks to be a VSCode fork very similar to Cursor, with support for Gemini 3 Pro, Claude Sonnet 4.5, and G…”
   • [community] “I much prefer using Gemini CLI in combination with vscode. It works like a charm. Now, I'll do the same with Antigravity CLI and vscode. It …”

   proof ↗⚑ flag

   Conductor✓fullcommunity8/10

   Conductor lets users delegate coding tasks to agents (Claude Code, Codex, Cursor, OpenCode) that run inside its own workspaces, autonomously testing repos, running builds, and continuing work unattended, with checkpoints and review flow built into the product (conductor-docs-1, -17, -20, -29, -32). Community reports confirm the agent runs live inside the app during real use (conductor-comm-7, conductor-comm-15). Missing for 10: independent benchmarking of assistant quality/reliability beyond docs and mixed anecdotal UX feedback (conductor-comm-9).

   • [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
   • [community] “I have been imagining something like this would be perfect for working with Claude Code... This feels like just a nice clean simple extensio…”
   • [community] “Your messages are just between you and Claude Code — it all runs on your local Claude Code installation via the SDK.”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round drawn
   Google Antigravity✓fullcommunity8/10

   Docs consistently describe natural-language operation as the core interaction model — editing, orchestrating, and building 'all in natural language' (antigravity-docs-9), NL code commands in the IDE (antigravity-docs-6/41), and even voice-to-prompt transcription (antigravity-docs-3), backed by planning/artifact review flows driven by conversational prompts (antigravity-docs-24, antigravity-docs-25). Community evidence corroborates it functions as an agentic assistant (comm-1, comm-10) though with quality/reliability complaints unrelated to the NL-command axis itself. Missing for 10: independent hands-on confirmation specifically praising the NL-command UX (most community commentary focuses on bugs/pricing/security rather than command quality).

   • [claimed-docs] “Edit, orchestrate, and build all in natural language. Tell your agents what you need, and they’ll work on getting it done.”
   • [claimed-docs] “Google Antigravity's Editor view offers tab autocompletion, natural language code commands, and a configurable, and context-aware configurab…”
   • [claimed-docs] “offers tab autocompletion, natural language code commands, and a configurable, and context-aware configurable agent”
   • [claimed-docs] “Speak your prompts. Powered by the latest Gemini Audio models, real-time transcription converts conversational speech into clearly phrased p…”
   • [claimed-docs] “Planning Mode: The agent plans thoroughly before executing tasks... produces structured implementation plans called Artifacts”
   • [claimed-docs] “The agent always halts and requests your explicit approval before proceeding with proposed changes.”
   • [community] “I went ahead and downloaded it, it looks to be a VSCode fork very similar to Cursor, with support for Gemini 3 Pro, Claude Sonnet 4.5, and G…”
   • [community] “I much prefer using Gemini CLI in combination with vscode. It works like a charm. Now, I'll do the same with Antigravity CLI and vscode. It …”

   proof ↗⚑ flag

   Conductor✓fullprobed8/10

   Conductor's entire interaction model is natural-language chat with coding agents (Claude Code, Codex, Cursor, OpenCode) that can autonomously test, build, and edit without step confirmation, and it exposes a hosted MCP server so ChatGPT/Claude/Codex or other AI clients can manage workspaces via natural language, plus an API to send prompts and read agent replies. missing for 10: independent/hands-on validation of natural-language command reliability beyond vendor docs.

   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
   • [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”

   proof ↗⚑ flag

Api quality

1. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Google Antigravity—none0/10

   A direct probe for OpenAPI/Swagger specs at all standard candidate paths returned 404s, and no documentation item mentions a machine-readable API spec despite extensive docs on SDK, CLI, and MCP.

   • [probe] “PROBE openapi: all candidate paths 404 (https://antigravity.google/openapi.json, https://antigravity.google/swagger.json, https://antigravit…”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor documents a REST-like API and an MCP server, but a direct probe for machine-readable OpenAPI/Swagger specs at standard locations returned 404 on all candidate paths, and no evidence pack item links to a downloadable spec file.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.conductor.build/openapi.json, https://www.conductor.build/swagger.json, https://www.cond…”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”

   proof ↗⚑ flag

2. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Conductor
   Google Antigravity!disputedcontradicted4/10

   Antigravity's CLI docs claim a sandbox that blocks sensitive files (~/.ssh, .env) and hides anything not explicitly mounted, which sounds like exactly the kind of safe-testing boundary this story wants, but hands-on community reports directly contradict this: Gemini bypassed its own .env protection to exfiltrate secrets via prompt injection, a default allowlisted webhook.site was used as an exfiltration vector, and in another incident Antigravity commands deleted an entire drive outside any expected sandbox boundary. This is a concrete, documented failure of the sandbox promise rather than mere skepticism. Missing for 10: a genuine isolated/staging environment separate from real user data, and any vendor or independent confirmation that the sandbox reliably prevents production-data access after these reported bypasses.

   • [claimed-docs] “Sensitive files like ~/.ssh and .env are blocked, anything not explicitly mounted is invisible inside the sandbox”
   • [community] “Google Antigravity exfiltrates data via indirect prompt injection attack: Gemini is not supposed to have access to .env files with default s…”
   • [community] “The default Allowlist provided with Antigravity includes 'webhook.site', which was used as an exfiltration vector for secrets.”
   • [community] “Antigravity was also vulnerable to the classic Markdown image exfiltration bug, reported a few days prior and flagged as 'intended behavior'…”
   • [community] “Google Antigravity just deleted the contents of whole drive - came down to commanding a deletion of a 'directory with space in the name' wit…”

   proof ↗⚑ flag

   Conductor~partialcommunity6/10

   Conductor's core architecture creates isolated workspaces (separate git worktrees, branches, cloud sandboxes) so each agent task runs independently without touching the main/production branch (conductor-docs-2, conductor-docs-20, conductor-docs-27, conductor-docs-29), and community users confirm the git-worktree-based isolation (conductor-comm-1, conductor-comm-17). However, this isolation is code/branch-level, not explicitly a data-layer sandbox (e.g., staging DB, mock services), and one community report notes full GitHub write-access requirements that undercut a clean 'no touching production' guarantee (conductor-comm-5, conductor-comm-6). Missing for 10: explicit handling/isolation of production data stores or environment variables, and confirmation that sandbox workspaces cannot inadvertently write to production systems.

   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [community] “Oh cool, I was already doing this with git worktrees but a ui for it would be handy.”
   • [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
   • [community] “I was really excited to try this but this does NOT work the way I expected. I wanted a simple git worktree manager for my existing, already-…”

   proof ↗⚑ flag

3. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Google Antigravity—none0/10

   No evidence of versioned APIs or a documented deprecation policy; OpenAPI probe returned 404s across all candidate paths and no docs mention API versioning or deprecation timelines.

   • [probe] “PROBE openapi: all candidate paths 404 (https://antigravity.google/openapi.json, https://antigravity.google/swagger.json, https://antigravit…”

   proof ↗⚑ flag

   Conductor—none0/10

   There's an API and MCP server documented, but no evidence of API versioning scheme or a deprecation policy; probes show no OpenAPI spec found and no changelog/policy on version deprecation.

   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.conductor.build/openapi.json, https://www.conductor.build/swagger.json, https://www.cond…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Conductor
   Google Antigravity~partialclaimed6/10

   Antigravity supports parallel multi-agent orchestration across independent projects, subagent delegation, scheduled/background tasks, and a headless CLI for scripting bulk/CI workflows, which together enable operating across many items or tasks concurrently. However, there is no explicit documentation of a dedicated 'bulk operation' primitive (e.g., batch-apply an action across a list of files/items in one command) — the capability is inferred from parallelism/orchestration features rather than a purpose-built bulk-ops interface. missing for 10: explicit bulk/batch API or command for applying one operation across many items, independent hands-on evidence of large-scale parallel task execution working reliably.

   • [claimed-docs] “Orchestrate multiple autonomous agents working in parallel across independent projects.”
   • [claimed-docs] “Have multiple agents working in parallel, so larger tasks get tackled faster.”
   • [claimed-docs] “an agent can delegate tasks—such as running tests or performing extensive codebase searches—to dedicated subagents.”
   • [claimed-docs] “Worktree support: Projects natively support Git worktrees, allowing agents to operate in isolated background folders.”
   • [claimed-docs] “Run Antigravity CLI non-interactively to script agent tasks, integrate with CI pipelines, and capture machine-readable output.”

   proof ↗⚑ flag

   Conductor~partialclaimed7/10

   Conductor supports running many coding agents in parallel across isolated workspaces, and exposes a programmatic API plus scheduled/CI-triggered 'routines' that can create workspaces and send prompts at scale — a reasonable basis for bulk, automation-driven operations across many items. However, there's no documented UI for batch-selecting and acting on many existing workspaces at once (e.g., bulk archive/merge), and no independent evidence of large-scale parallel runs in practice. Missing for 10: explicit multi-item batch actions in the UI, evidence of scale/limits on parallel agents, and third-party corroboration of bulk automation workflows via the API or routines.

   • [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [claimed-docs] “Run multiple agents in one workspace when the work belongs on the same branch and should share the same files and context.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Google Antigravity
   Google Antigravity✓fullclaimed7/10

   Antigravity's docs describe explicit rule activation modes (Manual, Always On, Model Decision, Glob) that trigger agent behavior automatically based on context/file patterns, plus Hooks that run custom scripts at specific points in the execution loop and Scheduled Tasks that trigger agents on a cron schedule — together these directly satisfy 'rules that trigger actions automatically on events'. Missing for 10: independent/hands-on verification that rule-triggering works reliably in practice, and more detail on broader event types beyond glob/model-decision/cron.

   • [claimed-docs] “At the rule level you can define how a rule should be activated: Manual... Always On... Model Decision... Glob”
   • [claimed-docs] “Hooks allow you to run custom scripts or shell commands at specific points during Antigravity’s execution loop.”
   • [claimed-docs] “Automate routine checks with Scheduled Tasks, simply define a cron schedule and the agents start and run autonomously in the background.”
   • [claimed-docs] “Rules are manually defined constraints for the Agent to follow, at both the local and global levels.”

   proof ↗⚑ flag

   Conductor~partialclaimed5/10

   Conductor's 'routines' feature lets agents run on a schedule or via GitHub Action trigger, which is a limited form of event-driven automation, but there's no evidence of a general rules engine supporting arbitrary event types (e.g., webhooks, file changes, custom conditions) or complex trigger-action definitions. Missing for 10: broader event-type support, custom rule/condition definitions, and hands-on evidence that routines fire reliably on GitHub events.

   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Google Antigravity
   Google Antigravity✓fullclaimed8/10

   Docs explicitly describe Scheduled Tasks with cron-defined schedules that run agents autonomously in the background, plus scheduling messages to agents for later delivery, directly matching the recurring-jobs/workflow story. Missing for 10: independent/hands-on confirmation that scheduling actually works reliably in practice, and more detail on job management (editing/deleting/monitoring scheduled runs).

   • [claimed-docs] “Automate routine checks with Scheduled Tasks, simply define a cron schedule and the agents start and run autonomously in the background.”
   • [claimed-docs] “users can schedule messages to be sent to their agents while they’re away”

   proof ↗⚑ flag

   Conductor✓fullclaimed6/10

   Conductor's changelog explicitly introduces 'routines' that let agents run on a schedule or via GitHub Action, directly matching the recurring-jobs/workflows story. However, this is a single brief changelog mention with no dedicated documentation page, configuration details, or community corroboration of the feature in practice. Missing for 10: dedicated docs on routine/schedule configuration, independent/hands-on confirmation, details on failure handling or monitoring of scheduled runs.

   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Conductor
   Google Antigravity—none0/10

   Evidence shows automations (skills, hooks, plugins, scheduled tasks) but no mention of versioning, review history, or rollback capabilities for these automations themselves — missing for 10: version control/history for skills/hooks/plugins, a review workflow for automation changes, and any rollback/undo mechanism for automations.

   ⚑ flag

   Conductor~partialclaimed6/10

   Conductor provides git-based versioning (separate branches/worktrees per workspace), diff review before merge/PR, and 'Checkpoints' to revert code and chat state to an earlier turn—covering version, review, and rollback at the workspace/agent-session level. However, the newer 'Routines' (scheduled/GitHub-Action automations) feature has no documented versioning, review, or rollback mechanism specific to the automation definitions themselves. Missing for 10: explicit version history/rollback for Routines/scheduled automations, independent hands-on confirmation of checkpoint reliability.

   • [claimed-docs] “Checkpoints | Session/workspace | Revert code and chat state to an earlier turn”
   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”

   proof ↗⚑ flag

Background execution

1. ai-native userHave a cloud agent build, test, and demo a feature end-to-end for my review

   weight 2 · round to Conductor
   Google Antigravity~partialcommunity6/10

   Docs describe agents that autonomously operate across editor/terminal/browser, delegate testing to subagents, produce reviewable Artifacts (implementation plans, diffs, browser recordings) and halt for approval — covering build, test and demo-for-review end-to-end (antigravity-docs-7,18,24,25,30,46). However, community reports of a subpar harness, app-breaking bugs, and a case where autonomous terminal execution deleted a whole drive raise real doubts about reliable end-to-end execution (antigravity-comm-8,antigravity-comm-14). Missing for 10: independent hands-on confirmation of a full successful build→test→demo cycle, and resolution of reliability/security concerns that could derail autonomous runs.

   • [claimed-docs] “Able to autonomously operate across your editor, terminal, and browser.”
   • [claimed-docs] “an agent can delegate tasks—such as running tests or performing extensive codebase searches—to dedicated subagents.”
   • [claimed-docs] “Planning Mode: The agent plans thoroughly before executing tasks... produces structured implementation plans called Artifacts”
   • [claimed-docs] “The agent always halts and requests your explicit approval before proceeding with proposed changes.”
   • [claimed-docs] “Artifacts include rich markdown plans (Implementation Plans), code diffs, architecture diagrams, images, and browser recordings.”
   • [claimed-docs] “an agent can delegate tasks—such as running tests or performing extensive codebase searches—to dedicated subagents”
   • [community] “It's not even good, honestly. I was using it for couple weeks before dropping that 2 months ago. The model was not good and slow, the harnes…”
   • [community] “Google Antigravity just deleted the contents of whole drive - came down to commanding a deletion of a 'directory with space in the name' wit…”

   proof ↗⚑ flag

   Conductor✓fullclaimed7/10

   Conductor's cloud agents can autonomously test repos, update setup scripts, and run builds without step-by-step confirmation (conductor-docs-17, conductor-docs-32), continue working after the laptop closes (conductor-docs-20), and then help the user review the diff, open a PR, and merge (conductor-docs-21) — covering build, test, and review end-to-end for a feature. Missing for 10: no explicit 'demo' artifact (e.g., preview links/screenshots) beyond diff/PR review, and no independent/hands-on account confirming a full autonomous build-test-review cycle worked as described.

   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”

   proof ↗⚑ flag

2. developerDelegate longer-running coding tasks to run in the background in an isolated cloud environment

   weight 3 · round to Conductor
   Google Antigravity~partialclaimed5/10

   Antigravity supports background/autonomous execution via Scheduled Tasks that run agents in the background, Git worktree-based isolated background folders, and scheduling messages for agents while away, plus a 'Remote Control' feature to connect to running desktop sessions across machines. However, these mechanisms describe local-machine or worktree isolation and remote access to local sessions, not a distinctly cloud-hosted sandbox environment for offloading long-running tasks the way some competitors do. Missing for 10: explicit documentation of a persistent cloud-hosted execution environment independent of the user's machine, and independent/hands-on confirmation that background tasks truly run isolated in the cloud rather than locally.

   • [claimed-docs] “Automate routine checks with Scheduled Tasks, simply define a cron schedule and the agents start and run autonomously in the background.”
   • [claimed-docs] “Worktree support: Projects natively support Git worktrees, allowing agents to operate in isolated background folders.”
   • [claimed-docs] “users can schedule messages to be sent to their agents while they’re away”
   • [claimed-docs] “Antigravity Remote Control allows you to securely connect to and drive your Antigravity 2.0 desktop sessions running across your machines fr…”
   • [claimed-docs] “Antigravity 2.0 serves as your AI agents’ central command center, providing a unified platform to launch, monitor, and orchestrate their act…”
   • [claimed-docs] “Run Antigravity CLI non-interactively to script agent tasks, integrate with CI pipelines, and capture machine-readable output.”

   proof ↗⚑ flag

   Conductor~partialcommunity7/10

   Docs describe a dedicated 'cloud workspace' feature where agents run in isolated sandboxes that 'spin up in seconds' and 'keep working after you close your laptop,' can test repos/run builds unattended, and continue processing PR checks while 'asleep' (conductor-docs-20, conductor-docs-17, conductor-docs-11, conductor-docs-13). However, community reports describe the core product as creating an isolated git worktree locally rather than a cloud container, contrasting it with Codex's cloud sandbox (conductor-comm-17, conductor-comm-6), suggesting the cloud-isolation capability may be a newer/optional layer rather than the default experience. Missing for 10: independent hands-on verification that background cloud tasks are fully isolated/persistent, and clarity on whether cloud workspaces are the default vs. opt-in given local-worktree-first community accounts.

   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “PR comments and failing-check logs now load while a cloud workspace is asleep.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
   • [community] “I was really excited to try this but this does NOT work the way I expected. I wanted a simple git worktree manager for my existing, already-…”

   proof ↗⚑ flag

Parallel agents

1. ai-native userLaunch fleets of autonomous agents that work in parallel on different tasks for hours or days

   weight 2 · round to Conductor
   Google Antigravity~partialclaimed7/10

   Docs describe orchestrating multiple autonomous agents in parallel across independent projects, scheduled/cron tasks that run autonomously in the background, worktree-isolated agents, subagent delegation, and remote control to check on running sessions from a browser — all supporting a 'fleet of parallel long-running agents' story. However, there is no independent/hands-on confirmation of agents actually running unattended for 'hours or days' at scale, and community reports focus on bugs, quota limits, and security issues rather than validating multi-day parallel fleet operation. Missing for 10: independent verification of long-duration (hours/days) autonomous runs, evidence of fleet scale limits, and hands-on confirmation from third parties.

   • [claimed-docs] “Orchestrate multiple autonomous agents working in parallel across independent projects.”
   • [claimed-docs] “Automate routine checks with Scheduled Tasks, simply define a cron schedule and the agents start and run autonomously in the background.”
   • [claimed-docs] “Have multiple agents working in parallel, so larger tasks get tackled faster.”
   • [claimed-docs] “Antigravity 2.0 serves as your AI agents’ central command center, providing a unified platform to launch, monitor, and orchestrate their act…”
   • [claimed-docs] “Worktree support: Projects natively support Git worktrees, allowing agents to operate in isolated background folders.”
   • [claimed-docs] “users can schedule messages to be sent to their agents while they’re away”
   • [claimed-docs] “Antigravity Remote Control allows you to securely connect to and drive your Antigravity 2.0 desktop sessions running across your machines fr…”
   • [claimed-docs] “an agent can delegate tasks—such as running tests or performing extensive codebase searches—to dedicated subagents.”

   proof ↗⚑ flag

   Conductor✓fullclaimed7/10

   Docs show Conductor explicitly designed for running multiple agents (Claude Code, Codex, Cursor, OpenCode) in parallel across isolated workspaces/worktrees, with cloud workspaces that 'keep working after you close your laptop' and 'routines' to run agents on a schedule or via GitHub Action, supporting long-running autonomous fleets. Community feedback focuses on GitHub permission/privacy concerns rather than disputing the parallel-autonomy capability itself. Missing for 10: independent/hands-on confirmation of agents actually running unattended for multi-day spans and evidence of fleet scale (e.g., dozens of simultaneous agents).

   • [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [claimed-docs] “Run multiple agents in one workspace when the work belongs on the same branch and should share the same files and context.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”

   proof ↗⚑ flag

2. developerRun several task attempts in parallel and compare results before choosing one

   weight 1 · round to Conductor
   Google Antigravity~partialclaimed4/10

   Docs confirm agents can run in parallel (multiple agents across projects, multiple CLI agents for large tasks) and a central dashboard to monitor/orchestrate them, but nothing describes running multiple attempts at the SAME task and comparing outputs before choosing a winner — that specific 'compare-and-select' workflow is unevidenced. missing for 10: explicit multi-attempt/variant generation for a single task, a comparison UI or ranking mechanism, and any selection step among parallel attempts.

   • [claimed-docs] “Have multiple agents working in parallel, so larger tasks get tackled faster.”
   • [claimed-docs] “Orchestrate multiple autonomous agents working in parallel across independent projects.”
   • [claimed-docs] “Antigravity 2.0 serves as your AI agents’ central command center, providing a unified platform to launch, monitor, and orchestrate their act…”

   proof ↗⚑ flag

   Conductor✓fullprobed8/10

   Conductor's core design is running multiple coding agents in parallel, each in its own isolated workspace/git worktree with its own branch, files, and diff/review path, letting a developer inspect and choose before merging (docs-2, docs-27, docs-29, docs-21, probe-1). Community hands-on comments corroborate the git-worktree-based parallel workspace model (conductor-comm-1, conductor-comm-17). missing for 10: explicit first-party description of a side-by-side comparison UI across multiple simultaneous attempts (evidence shows parallel isolated workspaces and per-workspace diff/review, but not an explicit 'compare attempts' feature or independent review confirming the comparison workflow).

   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.conductor.build/llms.txt # Conductor > Conductor is a Mac app that lets you run many coding agents …”
   • [community] “Oh cool, I was already doing this with git worktrees but a ui for it would be handy.”
   • [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”

   proof ↗⚑ flag

Scheduled automation

1. ai-native userSet up always-on agents that run on schedules or triggers to maintain and fix my software autonomously

   weight 2 · round to Google Antigravity
   Google Antigravity✓fullcommunity7/10

   First-party docs explicitly describe Scheduled Tasks with cron schedules that start and run agents autonomously in the background, plus scheduling messages to agents while away, parallel autonomous agent orchestration, and headless CLI mode for CI/trigger-based automation. However, there is no independent/hands-on corroboration of the scheduling feature itself, and community reports document serious reliability/safety incidents with autonomous execution (e.g., an agent deleting a whole drive via unattended terminal auto-execution), raising doubt about safely running such agents unattended. Missing for 10: independent verification that scheduled/cron-triggered agents work reliably in practice, and evidence that autonomous 'maintain and fix' runs don't require the same close supervision seen in incident reports.

   • [claimed-docs] “Automate routine checks with Scheduled Tasks, simply define a cron schedule and the agents start and run autonomously in the background.”
   • [claimed-docs] “users can schedule messages to be sent to their agents while they’re away”
   • [claimed-docs] “Orchestrate multiple autonomous agents working in parallel across independent projects.”
   • [claimed-docs] “Run Antigravity CLI non-interactively to script agent tasks, integrate with CI pipelines, and capture machine-readable output.”
   • [community] “Google Antigravity just deleted the contents of whole drive - came down to commanding a deletion of a 'directory with space in the name' wit…”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   Conductor documents 'routines' that run agents on a schedule or via GitHub Action, plus cloud agents that keep working after you close your laptop and can autonomously test, fix, and rebuild repos without step-by-step confirmation — directly supporting always-on autonomous maintenance. However, the routines feature is only briefly mentioned in a changelog entry with no deep documentation of trigger types, monitoring, or failure-handling, and no independent/hands-on evidence confirms long-running unattended reliability. Missing for 10: detailed docs on trigger configuration (webhooks, cron specifics), evidence of long-term unattended reliability, and community confirmation of the scheduling/autonomy feature working in practice.

   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”

   proof ↗⚑ flag

Debugging

1. developerDebug issues and troubleshoot using natural-language queries

   weight 2 · round to Google Antigravity
   Google Antigravity~partialclaimed6/10

   Antigravity's docs show natural-language code commands, autonomous operation across editor/terminal/browser, and subagents that can run tests and search codebases (docs-6,7,9,18,46), which collectively support debugging/troubleshooting via NL prompts, but there is no explicit documentation of a dedicated 'debug' workflow or troubleshooting examples, and community reports focus on stability/security issues rather than confirming debugging quality. Missing for 10: explicit debugging-specific documentation or examples, and independent hands-on validation that NL debugging queries work reliably.

   • [claimed-docs] “Google Antigravity's Editor view offers tab autocompletion, natural language code commands, and a configurable, and context-aware configurab…”
   • [claimed-docs] “Able to autonomously operate across your editor, terminal, and browser.”
   • [claimed-docs] “Edit, orchestrate, and build all in natural language. Tell your agents what you need, and they’ll work on getting it done.”
   • [claimed-docs] “an agent can delegate tasks—such as running tests or performing extensive codebase searches—to dedicated subagents.”
   • [claimed-docs] “an agent can delegate tasks—such as running tests or performing extensive codebase searches—to dedicated subagents”

   proof ↗⚑ flag

   Conductor~partialclaimed5/10

   Conductor orchestrates coding agents (Claude Code, Codex, Cursor) that support natural-language chat, and each workspace has its own terminal, diff, and chat interface, implying a developer could ask an agent to debug/troubleshoot via NL queries. However, there's no Conductor-specific documentation describing a dedicated debugging/troubleshooting NL workflow, error-log analysis, or diagnostic features beyond generic agent chat and build/test execution. Missing for 10: explicit docs on NL-driven debugging workflows, log/error analysis features, or examples of troubleshooting via chat distinct from general coding tasks.

   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
   • [claimed-docs] “Checkpoints | Session/workspace | Revert code and chat state to an earlier turn”

   proof ↗⚑ flag

Feature implementation

1. developerTurn a tracked issue into a complete pull request end-to-end

   weight 3 · round to Conductor
   Google Antigravity—none0/10

   Antigravity's docs describe autonomous coding agents that can edit files, run terminal commands, and operate across editor/terminal/browser, but there is no evidence of any issue-tracker (e.g., GitHub Issues) integration or an end-to-end workflow that ingests a tracked issue and produces a pull request. Missing for 10: issue-tracker ingestion, automated branch/PR creation, and any documented GitHub/GitLab PR workflow example.

   • [claimed-docs] “Able to autonomously operate across your editor, terminal, and browser.”
   • [claimed-docs] “Antigravity 2.0 serves as your AI agents’ central command center, providing a unified platform to launch, monitor, and orchestrate their act…”
   • [claimed-docs] “Run Antigravity CLI non-interactively to script agent tasks, integrate with CI pipelines, and capture machine-readable output.”

   proof ↗⚑ flag

   Conductor✓fullclaimed7/10

   Docs show workspaces can be created directly from a GitHub issue (conductor-docs-12), agents run autonomously to implement, test, and build (conductor-docs-17, conductor-docs-20), and Conductor then helps review the diff, open a PR, merge, and archive the workspace (conductor-docs-21) — covering the full issue-to-PR loop. Missing for 10: independent/hands-on confirmation of the complete issue→PR flow (community evidence covers worktree/permissions concerns but not this specific workflow), and no example of a merged PR originating from an issue.

   • [claimed-docs] “Use Command + Shift + N or the `...` button next to `New workspace` to create a workspace from a branch, pull request, GitHub issue, or Line…”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”

   proof ↗⚑ flag

2. developerDescribe a feature or bug in plain language and have the agent implement or fix it across multiple files

   weight 3 · round to Google Antigravity
   Google Antigravity~partialcommunity7/10

   Docs describe the core loop clearly: natural-language commands drive an agent that autonomously edits code across the editor/terminal, with Projects spanning multiple folders/repos giving full codebase context and Artifacts showing diffs/plans for review (antigravity-docs-6,7,9,17,24,30,40). Community reports confirm it functions as a real coding-agent IDE (comm-1) but also describe hands-on quality issues with the agent harness and model reliability during actual implementation work (comm-8), so delivery is real but not consistently polished. Missing for 10: independent benchmark/case-study evidence of successful multi-file feature implementation, and resolution of reported harness/quality complaints.

   • [claimed-docs] “Google Antigravity's Editor view offers tab autocompletion, natural language code commands, and a configurable, and context-aware configurab…”
   • [claimed-docs] “Able to autonomously operate across your editor, terminal, and browser.”
   • [claimed-docs] “Edit, orchestrate, and build all in natural language. Tell your agents what you need, and they’ll work on getting it done.”
   • [claimed-docs] “a project can work with one folder or multiple folders (e.g., a frontend and a backend repo), providing your agents with all of the context …”
   • [claimed-docs] “Planning Mode: The agent plans thoroughly before executing tasks... produces structured implementation plans called Artifacts”
   • [claimed-docs] “Artifacts include rich markdown plans (Implementation Plans), code diffs, architecture diagrams, images, and browser recordings.”
   • [claimed-docs] “Build AI agents that autonomously read files, run commands, edit code, and more.”
   • [community] “I went ahead and downloaded it, it looks to be a VSCode fork very similar to Cursor, with support for Gemini 3 Pro, Claude Sonnet 4.5, and G…”
   • [community] “It's not even good, honestly. I was using it for couple weeks before dropping that 2 months ago. The model was not good and slow, the harnes…”

   proof ↗⚑ flag

   Conductor~partialcommunity6/10

   Conductor orchestrates underlying coding agents (Claude Code, Codex, Cursor, OpenCode) that implement plain-language feature requests across files, with workspaces, diffs, and PR flows supporting this, and community feedback confirms it works as a Claude Code-like workflow wrapper. However, the actual code-generation quality depends entirely on the underlying agent, not Conductor itself, and no hands-on example of a multi-file feature/bug fix is shown in the evidence. missing for 10: a concrete hands-on example of Conductor implementing a described feature/bug across multiple files, and clarity on Conductor's own contribution versus the wrapped agent's capability.

   • [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [community] “I have been imagining something like this would be perfect for working with Claude Code... This feels like just a nice clean simple extensio…”
   • [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”

   proof ↗⚑ flag

Maintenance automation

1. developerHave the agent write tests, fix lint errors, resolve merge conflicts, and update dependencies for me

   weight 3 · round to Google Antigravity
   Google Antigravity~partialcommunity6/10

   Antigravity's docs describe general-purpose coding agents/subagents that can run tests, edit code, and operate across editor/terminal/browser (docs-18, docs-46, docs-40, docs-7), which implicitly covers writing tests and dependency/code edits, but there is no explicit documentation calling out lint-error fixing, merge-conflict resolution, or dependency updates as named capabilities. Community evidence is mixed on general quality/reliability but does not concretely refute these specific tasks. Missing for 10: explicit first-party documentation or hands-on examples of lint-fixing, merge-conflict resolution, and dependency-update workflows specifically.

   • [claimed-docs] “an agent can delegate tasks—such as running tests or performing extensive codebase searches—to dedicated subagents.”
   • [claimed-docs] “an agent can delegate tasks—such as running tests or performing extensive codebase searches—to dedicated subagents”
   • [claimed-docs] “Build AI agents that autonomously read files, run commands, edit code, and more.”
   • [claimed-docs] “Able to autonomously operate across your editor, terminal, and browser.”
   • [claimed-docs] “The Agent SDK gives you the same tools, agent loop, and context management that power Google Antigravity, programmable in Python.”
   • [community] “It's not even good, honestly. I was using it for couple weeks before dropping that 2 months ago. The model was not good and slow, the harnes…”

   proof ↗⚑ flag

   Conductor~partialclaimed5/10

   Docs confirm the underlying agents can test repositories, edit setup/install scripts, and run builds autonomously (conductor-docs-17, conductor-docs-32), which covers test-writing/fixing to some degree, but there is no explicit documentation or community evidence of lint-error fixing, merge-conflict resolution, or dependency updates as distinct capabilities. Missing for 10: explicit evidence of lint fixing, merge conflict resolution, and dependency-update automation.

   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”

   proof ↗⚑ flag

Codebase mapping

1. developerUnderstand how a codebase fits together to find where to start making changes

   weight 3 · round to Google Antigravity
   Google Antigravity~partialclaimed6/10

   Antigravity provides contextual codebase understanding indirectly: Projects give agents full context across multiple folders/repos, subagents can perform 'extensive codebase searches', and Artifacts can include architecture diagrams and implementation plans that map out how a change fits into the codebase. However, there's no dedicated codebase-mapping/explanation feature, and no independent/hands-on evidence confirming how well the agent actually explains codebase structure. Missing for 10: a first-class 'explain/visualize codebase architecture' feature, independent hands-on validation of comprehension quality on real repos.

   • [claimed-docs] “a project can work with one folder or multiple folders (e.g., a frontend and a backend repo), providing your agents with all of the context …”
   • [claimed-docs] “an agent can delegate tasks—such as running tests or performing extensive codebase searches—to dedicated subagents.”
   • [claimed-docs] “Artifacts include rich markdown plans (Implementation Plans), code diffs, architecture diagrams, images, and browser recordings.”
   • [claimed-docs] “Agents work within Projects, which define the boundaries of the folders and repositories they can access.”
   • [claimed-docs] “an agent can delegate tasks—such as running tests or performing extensive codebase searches—to dedicated subagents”
   • [claimed-docs] “Google Antigravity's Editor view offers tab autocompletion, natural language code commands, and a configurable, and context-aware configurab…”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor's evidence focuses on orchestrating parallel coding agents, worktrees, and workspace management, not on codebase comprehension features; the only related item is a basic file-content search (⌘⇧F), which does not constitute understanding how a codebase fits together or where to start making changes.

   • [claimed-docs] “Search file contents in your current local project or cloud workspace with ⌘⇧F.”

   proof ↗⚑ flag

2. developerHave the agent map and explain an entire unfamiliar codebase without manually selecting context files

   weight 3 · round to Google Antigravity
   Google Antigravity~partialclaimed5/10

   Docs indicate agents automatically get full-project context (docs-17, docs-35) and can delegate to subagents that perform 'extensive codebase searches' (docs-18/46), suggesting the agent can explore an unfamiliar repo without manual file selection. However, there is no explicit feature or example describing whole-codebase mapping/explanation, and no independent/hands-on evidence confirming this works well in practice. missing for 10: a dedicated 'explain codebase' or repo-mapping feature description, and independent verification of this on an unfamiliar large codebase.

   • [claimed-docs] “a project can work with one folder or multiple folders (e.g., a frontend and a backend repo), providing your agents with all of the context …”
   • [claimed-docs] “an agent can delegate tasks—such as running tests or performing extensive codebase searches—to dedicated subagents.”
   • [claimed-docs] “Agents work within Projects, which define the boundaries of the folders and repositories they can access.”
   • [claimed-docs] “an agent can delegate tasks—such as running tests or performing extensive codebase searches—to dedicated subagents”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor's evidence focuses on orchestrating parallel agent workspaces, worktrees, git branches, and collaboration—not on any built-in whole-codebase mapping or explanation capability. The closest feature is manual file-content search (⌘⇧F), which requires the developer to search rather than having the agent autonomously map/explain the codebase.

   • [claimed-docs] “Search file contents in your current local project or cloud workspace with ⌘⇧F.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”

   proof ↗⚑ flag

Context management

1. developerHave the agent build and recall memory automatically across sessions

   weight 2 · round drawn
   Google Antigravity—none0/10

   The evidence describes Projects, Rules, Artifacts, and context management, but none of these describe an automatic memory system that builds and recalls information across sessions without user re-specification; Rules are explicitly manual, and Projects only scope folders/permissions, not persistent learned memory. No documentation or community evidence confirms automatic cross-session memory recall.

   • [claimed-docs] “a project can work with one folder or multiple folders (e.g., a frontend and a backend repo), providing your agents with all of the context …”
   • [claimed-docs] “At the rule level you can define how a rule should be activated: Manual... Always On... Model Decision... Glob”
   • [claimed-docs] “Agents work within Projects, which define the boundaries of the folders and repositories they can access.”
   • [claimed-docs] “Rules are manually defined constraints for the Agent to follow, at both the local and global levels.”

   proof ↗⚑ flag

   Conductor—none0/10

   Evidence covers checkpoints (revert to earlier turn), static 'general preferences' for repo-wide instructions, and parallel workspace/session management, but nothing describes the agent automatically building or recalling memory across sessions (e.g., persistent knowledge base, learned context reuse). This is a fair axis for a coding-agent orchestration tool, so absence of evidence yields none.

   • [claimed-docs] “Checkpoints | Session/workspace | Revert code and chat state to an earlier turn”
   • [claimed-docs] “`General preferences` apply broad instructions to agents in a repository.”

   proof ↗⚑ flag

2. developerInclude multiple project directories in a single session for broader context

   weight 2 · round to Google Antigravity
   Google Antigravity✓fullclaimed8/10

   Docs explicitly state Projects can span multiple folders (e.g., a frontend and backend repo) giving agents full codebase context, with Projects defining folder/repo access boundaries and worktree support for isolated background folders. Missing for 10: independent/hands-on corroboration of multi-folder session use in practice.

   • [claimed-docs] “Group your conversations into Projects, which can span multiple folders and support custom settings and scoped permissions.”
   • [claimed-docs] “a project can work with one folder or multiple folders (e.g., a frontend and a backend repo), providing your agents with all of the context …”
   • [claimed-docs] “Agents work within Projects, which define the boundaries of the folders and repositories they can access.”
   • [claimed-docs] “Worktree support: Projects natively support Git worktrees, allowing agents to operate in isolated background folders.”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor's workspace model is built on git worktrees scoped to a single repository/branch per workspace (conductor-docs-27, conductor-docs-29), and there's no documentation of combining multiple project directories into one session. A community member explicitly requested multi-repo task support, implying it isn't currently available (conductor-comm-12).

   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [community] “I've been looking for a tool like this, that lets Claude operate on multiple repos... but all the tools for background/multiplexing are alwa…”

   proof ↗⚑ flag

3. developerAdd a project instructions file to set coding standards and conventions the agent follows

   weight 3 · round to Google Antigravity
   Google Antigravity✓fullclaimed7/10

   Antigravity supports Rules (manually defined constraints for the agent at local and global levels, with activation modes like Always On/Glob) which serve as a project instructions file for coding standards and conventions, and Projects scope these settings per folder/repo. missing for 10: no independent/hands-on confirmation of rules file format or behavior, and no evidence of a specific standardized file name (e.g. AGENTS.md-equivalent) or examples of it being used in practice.

   • [claimed-docs] “At the rule level you can define how a rule should be activated: Manual... Always On... Model Decision... Glob”
   • [claimed-docs] “Rules are manually defined constraints for the Agent to follow, at both the local and global levels.”
   • [claimed-docs] “a project can work with one folder or multiple folders (e.g., a frontend and a backend repo), providing your agents with all of the context …”
   • [claimed-docs] “Agents work within Projects, which define the boundaries of the folders and repositories they can access.”

   proof ↗⚑ flag

   Conductor~partialclaimed4/10

   Docs mention 'General preferences' that 'apply broad instructions to agents in a repository,' which is the closest match to a project instructions/conventions file, but there is no detail on file format, location, or how it maps to underlying agents' native instruction files (e.g., CLAUDE.md). Missing for 10: documentation of the actual file/config mechanism, examples of setting coding standards, and independent confirmation it works across all supported agents (Claude Code, Codex, Cursor, OpenCode).

   • [claimed-docs] “`General preferences` apply broad instructions to agents in a repository.”

   proof ↗⚑ flag

Issue diagnosis

1. developerReproduce issues, narrow down root causes, and verify fixes

   weight 3 · round drawn
   Google Antigravity~partialcommunity6/10

   Antigravity's agents can run terminal commands and browser sessions, delegate to subagents that run tests or search the codebase (docs-18, docs-46, docs-7), and produce Artifacts with diffs, plans and browser recordings that could serve as reproduction/verification evidence (docs-30, docs-51). Headless/CI mode (docs-50) also supports automated verification loops. However there is no explicit documented workflow for issue reproduction or root-cause narrowing, and community reports show real-world reliability problems (deleted directories, exfiltration bugs) rather than confirmation that debugging workflows work well. Missing for 10: a dedicated debugging/root-cause-analysis feature, explicit test-verification-of-fix workflow, and independent hands-on validation that this works well in practice.

   • [claimed-docs] “Able to autonomously operate across your editor, terminal, and browser.”
   • [claimed-docs] “an agent can delegate tasks—such as running tests or performing extensive codebase searches—to dedicated subagents.”
   • [claimed-docs] “Artifacts include rich markdown plans (Implementation Plans), code diffs, architecture diagrams, images, and browser recordings.”
   • [claimed-docs] “an agent can delegate tasks—such as running tests or performing extensive codebase searches—to dedicated subagents”
   • [claimed-docs] “Run Antigravity CLI non-interactively to script agent tasks, integrate with CI pipelines, and capture machine-readable output.”
   • [claimed-docs] “An Artifact is a structured deliverable created by the agent to accomplish its task and communicate its progress and thinking to the human u…”
   • [community] “Google Antigravity just deleted the contents of whole drive - came down to commanding a deletion of a 'directory with space in the name' wit…”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   Conductor provides isolated worktrees/workspaces where agents can run builds, tests, and setup scripts (conductor-docs-17, conductor-docs-32, conductor-docs-29), diff/PR review paths to verify fixes (conductor-docs-2, conductor-docs-21), and checkpoints to revert code/chat state when narrowing down a bad change (conductor-docs-18). These features support the reproduce→diagnose→verify loop, but the evidence is all first-party docs describing environment/orchestration features rather than direct debugging tooling (log inspection, stack traces, targeted bisection) or independent hands-on accounts of successfully reproducing/root-causing a bug. missing for 10: dedicated debugging/log-inspection features, independent user reports of using Conductor to isolate root causes or verify fixes end-to-end.

   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “Checkpoints | Session/workspace | Revert code and chat state to an earlier turn”
   • [claimed-docs] “Search file contents in your current local project or cloud workspace with ⌘⇧F.”

   proof ↗⚑ flag

Marketplace

1. developerEquip the agent with custom skills to perform specialized tasks

   weight 1 · round to Google Antigravity
   Google Antigravity✓fullclaimed8/10

   Antigravity has a dedicated Skills system: SKILL.md-based reusable packages of knowledge/instructions the agent follows for specific tasks, creatable/downloadable and accessible via slash commands, plus composable with plugins that bundle skills, rules, MCP servers, and hooks. This is documented across product and docs pages consistently, though no independent/community hands-on verification of custom skills specifically was found. Missing for 10: independent/hands-on corroboration of custom skill creation working in practice, and a marketplace/registry of shareable skills.

   • [claimed-docs] “Create or download fully customizable skills to further your agent’s autonomy and transform how you get work done.”
   • [claimed-docs] “A skill is a folder containing a `SKILL.md` file with instructions that the agent can follow when working on specific tasks.”
   • [claimed-docs] “Skills are reusable packages of knowledge that extend what the agent can do.”
   • [claimed-docs] “Access plugins, MCP, skills, and hooks configurations instantly via slash commands, quickly enhancing your workflow.”
   • [claimed-docs] “Layer custom Python callables, Model Context Protocol (MCP) servers, and reusable agent skills over our built-in filesystem and terminal too…”
   • [claimed-docs] “Plugins are namespaced bundles that allow you to extend Antigravity’s capabilities by grouping skills, rules, MCP servers, and hooks into a …”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor orchestrates existing coding agents (Claude Code, Codex, Cursor, OpenCode) and offers 'general preferences' for broad instructions, but there's no evidence of a custom skills/plugin/tool system for equipping agents with specialized capabilities; a community request even notes the lack of 'custom tools' in its menu (conductor-comm-2).

   • [claimed-docs] “`General preferences` apply broad instructions to agents in a repository.”
   • [community] “It'd be great to change the default branch used for creating new workspaces. I'd like the ability to add custom tools to the 'Open in...' me…”

   proof ↗⚑ flag

2. engineering-leadIntegrate third-party partner-built agent apps into my workflows

   weight 1 · round to Conductor
   Google Antigravity!disputedcontradicted4/10

   Vendor docs describe an extensibility layer (MCP servers, plugins, skills, hooks) that in principle lets teams plug in third-party building blocks (docs-14, docs-28, docs-12), suggesting an ecosystem for integrating outside agent capabilities. However, hands-on community reports directly contradict the notion of freely integrating partner-built agent apps: using a third-party agent ('Pi agent') alongside Antigravity triggered a Google account ban under Antigravity's TOS restricting 3rd-party usage, and users discovered unofficial vs official extensions causing confusion (comm-17, comm-18). Missing for 10: an official partner/marketplace program for third-party agent apps, clear TOS allowance for such integrations, and independent confirmation that such integrations work without account risk.

   • [claimed-docs] “Layer custom Python callables, Model Context Protocol (MCP) servers, and reusable agent skills over our built-in filesystem and terminal too…”
   • [claimed-docs] “Plugins are namespaced bundles that allow you to extend Antigravity’s capabilities by grouping skills, rules, MCP servers, and hooks into a …”
   • [claimed-docs] “Access plugins, MCP, skills, and hooks configurations instantly via slash commands, quickly enhancing your workflow.”
   • [community] “Google Antigravity TOS: 3rd party usage can get Google account suspended. My friend got a ban by using Pi agent with Antigravity. They un-ba…”
   • [community] “The VSCode Antigravity extension I was using turns out to be a 3rd-party one. I found out only today that there's an official extension too,…”

   proof ↗⚑ flag

   Conductor~partialcommunity7/10

   Conductor natively integrates several third-party agent apps (Claude Code, Codex, Cursor, OpenCode) into its parallel-workspace workflow, with per-org connection configuration and subscription/API-key support, and even exposes its own MCP server so other agent clients can manage workspaces. However, community feedback shows requests for additional partners (Gemini CLI, Amazon Q) that aren't yet supported, indicating a fixed rather than open/extensible partner ecosystem. Missing for 10: an open plugin/marketplace model for arbitrary partner agents, and independent confirmation of seamless integration beyond the listed agents.

   • [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
   • [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”
   • [claimed-docs] “Sign in to your Cursor subscription for cloud workspaces.”
   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
   • [community] “Love the design. does it build on electron? and will it support other code agents, like gemini cli, codex, opencode ext.”
   • [community] “Would be cool if I can use this with opencode, Amazon Q or whatever. I reckon the logic would be quite similar. Seen a few of these tools bu…”

   proof ↗⚑ flag

Team knowledge

1. engineering-leadCreate a shared workspace from my docs and repos as a common source of truth for the team

   weight 1 · round to Conductor
   Google Antigravity—none0/10

   Antigravity's 'Projects' concept groups folders/repos for a single agent session's context (docs-5, docs-17, docs-35, docs-38) and can surface Docs/Drive links (docs-32), but there is no evidence of a multi-user, team-shared workspace or collaborative source-of-truth that an engineering-lead could set up for a whole team — Projects appear to be individually scoped, local constructs rather than shared team assets.

   • [claimed-docs] “Group your conversations into Projects, which can span multiple folders and support custom settings and scoped permissions.”
   • [claimed-docs] “a project can work with one folder or multiple folders (e.g., a frontend and a backend repo), providing your agents with all of the context …”
   • [claimed-docs] “Agents work within Projects, which define the boundaries of the folders and repositories they can access.”
   • [claimed-docs] “Worktree support: Projects natively support Git worktrees, allowing agents to operate in isolated background folders.”
   • [claimed-docs] “External files such as Google Drive links, PDFs, and Office documents now appear in their own Documents section in the sidebar above Artifac…”

   proof ↗⚑ flag

   Conductor~partialclaimed4/10

   Conductor's cloud workspaces are shared with the whole organization and teammates can follow, reassign, or pick up the same workspace/chat, giving some sense of a shared team space tied to a repo (conductor-docs-24, conductor-docs-25, conductor-docs-16). However, there's no evidence of a workspace built from 'docs' (knowledge base, wiki, or design docs) alongside repos, or of any feature explicitly positioned as a team 'source of truth' beyond per-repo agent preferences. missing for 10: docs ingestion/aggregation into a workspace, explicit source-of-truth knowledge base feature, independent corroboration of team-wide shared-workspace usage.

   • [claimed-docs] “Workspaces and chats are shared with your organization, so a teammate can open the same workspace, follow the same conversation, and pick up…”
   • [claimed-docs] “browse everyone's work in **Home**, contribute to a teammate's chat, follow workspaces you care about, and hand work off with **Reassign to*…”
   • [claimed-docs] “Right-click the workspace and choose **Reassign to** to make a teammate responsible for it.”
   • [claimed-docs] “`General preferences` apply broad instructions to agents in a repository.”

   proof ↗⚑ flag

Tool integration

1. developerConnect the agent to workflow tools like Jira, Slack, and Google Drive to extend its context

   weight 3 · round to Google Antigravity
   Google Antigravity~partialclaimed5/10

   Antigravity documents generic MCP support for connecting to 'local developer tools, databases, file parsers, and external remote APIs' and explicitly shows Google Drive links/files appearing in its sidebar Documents section, giving a plausible path to hook in workflow tools. However, there is no explicit documentation of Jira or Slack connectors/integrations, and no first-party or community evidence of anyone actually wiring these specific tools in via MCP. Missing for 10: explicit Jira/Slack connector docs or MCP server examples, and independent confirmation of successful workflow-tool integrations beyond Drive.

   • [claimed-docs] “MCP lets Antigravity fetch structured context directly or execute safe actions on your behalf when needed.”
   • [claimed-docs] “lets AI agents and editors securely connect to local developer tools, databases, file parsers, and external remote APIs”
   • [claimed-docs] “External files such as Google Drive links, PDFs, and Office documents now appear in their own Documents section in the sidebar above Artifac…”
   • [claimed-docs] “Layer custom Python callables, Model Context Protocol (MCP) servers, and reusable agent skills over our built-in filesystem and terminal too…”

   proof ↗⚑ flag

   Conductor—none0/10

   Evidence shows Conductor integrates with GitHub and Linear (issue/branch creation) and exposes an MCP server for managing cloud workspaces, but there is no mention of Jira, Slack, or Google Drive integrations anywhere in the docs or community evidence.

   ⚑ flag

2. developerKick off agent tasks directly from GitHub, GitLab, Linear, or Slack

   weight 2 · round to Conductor
   Google Antigravity—none0/10

   No evidence that Antigravity supports kicking off agent tasks from GitHub, GitLab, Linear, or Slack; documentation covers IDE, CLI, SDK, scheduled tasks, and MCP but no mention of triggers from these external issue-tracker/chat platforms.

   ⚑ flag

   Conductor~partialclaimed5/10

   Conductor lets you create a workspace (kick off an agent task) from a GitHub branch, pull request, GitHub issue, or Linear issue, and can trigger agent runs via GitHub Actions/scheduled routines, but there is no evidence of GitLab or Slack integration for starting tasks. missing for 10: GitLab task-kickoff support, Slack task-kickoff support, and independent confirmation of these triggers working in practice.

   • [claimed-docs] “Use Command + Shift + N or the `...` button next to `New workspace` to create a workspace from a branch, pull request, GitHub issue, or Line…”
   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”

   proof ↗⚑ flag

Cross device continuity

1. developerStart a task on one device and continue it later from another device or browser

   weight 2 · round to Google Antigravity
   Google Antigravity✓fullclaimed7/10

   Antigravity Remote Control explicitly lets users securely connect to and drive their desktop Antigravity sessions from any web browser, directly enabling continuing a task started on one device from another device/browser, and scheduled/background tasks further support async continuation across sessions. Missing for 10: independent hands-on verification of cross-device continuity, details on session/state sync fidelity, and any community confirmation of this specific feature working in practice.

   • [claimed-docs] “Antigravity Remote Control allows you to securely connect to and drive your Antigravity 2.0 desktop sessions running across your machines fr…”
   • [claimed-docs] “users can schedule messages to be sent to their agents while they’re away”
   • [claimed-docs] “Antigravity 2.0 serves as your AI agents’ central command center, providing a unified platform to launch, monitor, and orchestrate their act…”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   Cloud workspaces are shared with the organization and support handoff via 'Reassign to' and shared links, so a teammate (or the same developer on another device) can open a workspace and pick up where they left off, and cloud agents keep working after the laptop closes. However, evidence is framed around team collaboration/handoff rather than explicit single-user cross-device continuity, and local (non-cloud) workspaces are tied to the machine's worktree. missing for 10: explicit documentation of the same developer resuming a *local* task from a different device, confirmation of seamless single-user cross-browser/device session continuity, and independent hands-on confirmation of this specific workflow.

   • [claimed-docs] “Workspaces and chats are shared with your organization, so a teammate can open the same workspace, follow the same conversation, and pick up…”
   • [claimed-docs] “browse everyone's work in **Home**, contribute to a teammate's chat, follow workspaces you care about, and hand work off with **Reassign to*…”
   • [claimed-docs] “The link opens the workspace in Conductor for any member of the organization.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “Following is useful when someone else is assigned to the workspace but you want to keep it in your workflow.”

   proof ↗⚑ flag

Ide integration

1. developerView interactive diffs and share selected code as context from within my JetBrains IDE

   weight 1 · round drawn
   Google Antigravity—none0/10

   Antigravity is documented as a standalone VSCode-fork IDE with its own Editor view, Artifacts diff viewer, and CLI/SDK — there is no mention anywhere in the docs, changelog, or community threads of a JetBrains plugin or JetBrains-specific integration for diffs or context sharing.

   • [claimed-docs] “Google Antigravity's Editor view offers tab autocompletion, natural language code commands, and a configurable, and context-aware configurab…”
   • [claimed-docs] “Artifacts include rich markdown plans (Implementation Plans), code diffs, architecture diagrams, images, and browser recordings.”
   • [claimed-docs] “Added a "Hide Whitespace Changes" option to the Review Changes overflow menu and file diff viewers to filter out whitespace-only edits.”
   • [claimed-docs] “Code and data artifacts like SQL and JSONL files now open in a virtualized viewer with syntax highlighting and line numbers”
   • [community] “I went ahead and downloaded it, it looks to be a VSCode fork very similar to Cursor, with support for Gemini 3 Pro, Claude Sonnet 4.5, and G…”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor is presented as a standalone Mac app with its own workspace/diff/terminal UI (conductor-docs-2, conductor-probe-1), not a JetBrains IDE plugin; none of the docs, changelog, or community threads mention any JetBrains integration, extension, or plugin for viewing diffs or sharing context from within a JetBrains IDE.

   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.conductor.build/llms.txt # Conductor > Conductor is a Mac app that lets you run many coding agents …”

   proof ↗⚑ flag

2. developerChat with the coding assistant directly inside my IDE for contextual help

   weight 3 · round drawn
   Google Antigravity✓fullcommunity7/10

   Antigravity is a VSCode-fork IDE with an editor view offering tab autocompletion, natural language code commands, and a context-aware conversational agent, confirmed by community hands-on reports of using it like Cursor. This directly supports in-IDE chat for contextual help. missing for 10: independent review specifically praising chat UX/quality (community notes mixed quality/performance complaints), and no detailed walkthrough of the chat interface itself beyond high-level docs.

   • [claimed-docs] “Google Antigravity's Editor view offers tab autocompletion, natural language code commands, and a configurable, and context-aware configurab…”
   • [claimed-docs] “offers tab autocompletion, natural language code commands, and a configurable, and context-aware configurable agent”
   • [community] “I went ahead and downloaded it, it looks to be a VSCode fork very similar to Cursor, with support for Gemini 3 Pro, Claude Sonnet 4.5, and G…”
   • [claimed-docs] “Users can select which reasoning model they want to use within the model selector drop-down under the conversation prompt box”

   proof ↗⚑ flag

   Conductor✓fullcommunity7/10

   Conductor provides each task/workspace its own chat, terminal, diff and review path directly alongside the running coding agent (Claude Code, Codex, Cursor, OpenCode), letting a developer converse with the assistant in context of their code (conductor-docs-2, conductor-docs-27). Community reports confirm the chat works locally against Claude Code with no meaningful complaint about chat context/quality beyond stylistic preference (conductor-comm-9, conductor-comm-15). Missing for 10: no evidence of a native plugin embedding this chat inside third-party IDEs like VS Code/JetBrains (it's a separate Mac app), and no independent hands-on review of contextual-help quality beyond one HN thread.

   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [community] “There's a 'feel' to the way Claude Code outputs the text. And for input as well. Sadly, this is lost with conductor. I just don't feel as jo…”
   • [community] “Your messages are just between you and Claude Code — it all runs on your local Claude Code installation via the SDK.”

   proof ↗⚑ flag

Session management

1. developerReview diffs visually and run multiple sessions side by side in a desktop app

   weight 2 · round drawn
   Google Antigravity✓fullcommunity8/10

   Antigravity's desktop app (confirmed as a VSCode-style editor) ships a dedicated 'Review Changes' diff viewer with whitespace filtering and syntax-highlighted artifacts (antigravity-docs-33, -34, -30), plus explicit support for running multiple agents/sessions in parallel across independent projects and worktrees from one command center (antigravity-docs-1, -37, -38, -10). Missing for 10: independent hands-on confirmation of the side-by-side multi-session UI specifically (community evidence mostly discusses general bugs/instability rather than this feature directly).

   • [claimed-docs] “Artifacts include rich markdown plans (Implementation Plans), code diffs, architecture diagrams, images, and browser recordings.”
   • [claimed-docs] “Added a "Hide Whitespace Changes" option to the Review Changes overflow menu and file diff viewers to filter out whitespace-only edits.”
   • [claimed-docs] “Code and data artifacts like SQL and JSONL files now open in a virtualized viewer with syntax highlighting and line numbers”
   • [claimed-docs] “Planning Mode: The agent plans thoroughly before executing tasks... produces structured implementation plans called Artifacts”
   • [claimed-docs] “The agent always halts and requests your explicit approval before proceeding with proposed changes.”
   • [claimed-docs] “Orchestrate multiple autonomous agents working in parallel across independent projects.”
   • [claimed-docs] “Antigravity 2.0 serves as your AI agents’ central command center, providing a unified platform to launch, monitor, and orchestrate their act…”
   • [claimed-docs] “Worktree support: Projects natively support Git worktrees, allowing agents to operate in isolated background folders.”
   • [community] “I went ahead and downloaded it, it looks to be a VSCode fork very similar to Cursor, with support for Gemini 3 Pro, Claude Sonnet 4.5, and G…”

   proof ↗⚑ flag

   Conductor✓fullprobed8/10

   Conductor is a native desktop (Mac) app that runs multiple coding agents (Claude Code, Codex, Cursor, OpenCode) in parallel, each in its own workspace/branch/worktree with a dedicated diff and review path before opening a PR, and community users independently confirm the git-worktree-based parallel session model. Missing for 10: independent hands-on evaluation specifically praising the visual diff-review UI's quality/UX (only vendor docs describe the diff view) and no screenshots/video corroboration.

   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.conductor.build/llms.txt # Conductor > Conductor is a Mac app that lets you run many coding agents …”
   • [community] “Oh cool, I was already doing this with git worktrees but a ui for it would be handy.”
   • [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”

   proof ↗⚑ flag

2. engineering-leadManage multiple agent-driven coding sessions from one unified workspace

   weight 2 · round drawn
   Google Antigravity✓fullcommunity8/10

   Antigravity's docs describe a unified 'command center' (antigravity-docs-37) that lets a lead orchestrate multiple autonomous agents in parallel across projects (antigravity-docs-1, antigravity-docs-10), grouped into Projects spanning folders/repos with scoped permissions (antigravity-docs-5, antigravity-docs-17, antigravity-docs-35), plus worktree isolation (antigravity-docs-38), scheduled/background tasks (antigravity-docs-2, antigravity-docs-39), subagent delegation (antigravity-docs-18/19), and even remote browser-based control of running sessions (antigravity-docs-26). This directly matches the engineering-lead's need to manage many concurrent agent sessions from one place. Missing for 10: independent verification of managing many simultaneous sessions at scale, and community reports note real stability/reliability issues (antigravity-comm-6, antigravity-comm-8, antigravity-comm-9) that temper confidence though they don't specifically contradict the multi-session orchestration claim.

   • [claimed-docs] “Antigravity 2.0 serves as your AI agents’ central command center, providing a unified platform to launch, monitor, and orchestrate their act…”
   • [claimed-docs] “Orchestrate multiple autonomous agents working in parallel across independent projects.”
   • [claimed-docs] “Have multiple agents working in parallel, so larger tasks get tackled faster.”
   • [claimed-docs] “Group your conversations into Projects, which can span multiple folders and support custom settings and scoped permissions.”
   • [claimed-docs] “a project can work with one folder or multiple folders (e.g., a frontend and a backend repo), providing your agents with all of the context …”
   • [claimed-docs] “Worktree support: Projects natively support Git worktrees, allowing agents to operate in isolated background folders.”
   • [claimed-docs] “Automate routine checks with Scheduled Tasks, simply define a cron schedule and the agents start and run autonomously in the background.”
   • [claimed-docs] “Antigravity Remote Control allows you to securely connect to and drive your Antigravity 2.0 desktop sessions running across your machines fr…”
   • [community] “Google made its lack of interest in Antigravity IDE obvious from very early. Updates were few and far between and app-breaking bugs stuck ar…”
   • [community] “It's not even good, honestly. I was using it for couple weeks before dropping that 2 months ago. The model was not good and slow, the harnes…”

   proof ↗⚑ flag

   Conductor✓fullcommunity8/10

   Conductor is explicitly built as a unified workspace for running multiple coding agents (Claude Code, Codex, Cursor, OpenCode) in parallel, each with its own workspace/branch/terminal/diff, plus team collaboration features (reassign, follow, shared workspaces) that support engineering-lead oversight. Community hands-on posts corroborate the parallel-agent workflow, though some raised concerns about permissions/data practices unrelated to the core multi-session management claim. missing for 10: independent lead-level testimony specifically on cross-team oversight at scale, and clearer evidence of a dashboard view aggregating all sessions' status for a lead.

   • [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “Workspaces and chats are shared with your organization, so a teammate can open the same workspace, follow the same conversation, and pick up…”
   • [claimed-docs] “browse everyone's work in **Home**, contribute to a teammate's chat, follow workspaces you care about, and hand work off with **Reassign to*…”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [community] “I have been imagining something like this would be perfect for working with Claude Code... This feels like just a nice clean simple extensio…”
   • [community] “Oh cool, I was already doing this with git worktrees but a ui for it would be handy.”

   proof ↗⚑ flag

Terminal workflow

1. developerRun a coding agent locally from my terminal

   weight 3 · round to Google Antigravity
   Google Antigravity✓fullprobed8/10

   Google Antigravity ships an official CLI product (antigravity-cli) with terminal-native features like slash commands, headless/non-interactive mode for scripting, sandboxing, vim-mode editing, and config management, explicitly designed to run agents locally from the terminal, and a community comment confirms using 'Antigravity CLI with vscode' works fine. Missing for 10: deeper independent hands-on reviews specifically of the CLI (most community feedback focuses on the IDE, not the terminal tool) and no third-party benchmarks of terminal performance/reliability.

   • [claimed-docs] “Edit, orchestrate, and build all in natural language. Tell your agents what you need, and they’ll work on getting it done.”
   • [claimed-docs] “Have multiple agents working in parallel, so larger tasks get tackled faster.”
   • [claimed-docs] “Navigate your entire workflow via standard terminal shortcuts: adjust permissions, themes, and preferences via /config and type /keybindings…”
   • [claimed-docs] “Access plugins, MCP, skills, and hooks configurations instantly via slash commands, quickly enhancing your workflow.”
   • [claimed-docs] “Run Antigravity CLI non-interactively to script agent tasks, integrate with CI pipelines, and capture machine-readable output.”
   • [claimed-docs] “Sensitive files like ~/.ssh and .env are blocked, anything not explicitly mounted is invisible inside the sandbox”
   • [claimed-docs] “Vim editor mode replaces the editing model in every multi-line input surface of the CLI”
   • [probe] “official CLI documented at https://antigravity.google/product/antigravity-cli”
   • [community] “I much prefer using Gemini CLI in combination with vscode. It works like a charm. Now, I'll do the same with Antigravity CLI and vscode. It …”

   proof ↗⚑ flag

   Conductor~partialprobed7/10

   Conductor documents running local coding agents (Claude Code, Codex, Cursor, OpenCode) with per-task local git worktrees and a dedicated terminal per workspace, and community confirms it runs the agent locally via the local CLI/SDK install (conductor-comm-15, conductor-comm-17). However, hands-on reports show it isn't a pure lightweight local terminal wrapper—it requires GitHub OAuth/cloning rather than just running an existing local repo, and some users complain the local CLI 'feel' (e.g., Claude Code's native terminal UX) is lost inside Conductor's GUI (conductor-comm-6, conductor-comm-9). Missing for 10: independent confirmation that pure terminal-only (non-GUI) workflows are fully supported, and clearer first-party disclosure addressing the community concerns about local vs. cloud/GitHub dependency.

   • [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [community] “Your messages are just between you and Claude Code — it all runs on your local Claude Code installation via the SDK.”
   • [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
   • [community] “I was really excited to try this but this does NOT work the way I expected. I wanted a simple git worktree manager for my existing, already-…”
   • [community] “There's a 'feel' to the way Claude Code outputs the text. And for input as well. Sadly, this is lost with conductor. I just don't feel as jo…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.conductor.build/llms.txt # Conductor > Conductor is a Mac app that lets you run many coding agents …”

   proof ↗⚑ flag

2. developerRun the agent non-interactively in scripts for workflow automation

   weight 2 · round to Google Antigravity
   Google Antigravity✓fullclaimed7/10

   Official docs explicitly describe a headless mode: 'Run Antigravity CLI non-interactively to script agent tasks, integrate with CI pipelines, and capture machine-readable output,' directly matching the workflow-automation story. Missing for 10: independent/hands-on confirmation of headless CI usage and details on machine-readable output format/exit codes.

   • [claimed-docs] “Run Antigravity CLI non-interactively to script agent tasks, integrate with CI pipelines, and capture machine-readable output.”
   • [claimed-docs] “Edit, orchestrate, and build all in natural language. Tell your agents what you need, and they’ll work on getting it done.”
   • [claimed-docs] “Create or download fully customizable skills to further your agent’s autonomy and transform how you get work done.”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   Conductor exposes a programmatic API to create workspaces, send prompts and read agent replies, and supports 'routines' to run agents on a schedule or via GitHub Action, which enables non-interactive, scripted automation of the agent outside the GUI. However, this is all first-party documentation with no independent/hands-on confirmation, and Conductor is fundamentally a GUI-first Mac app rather than a CLI tool built for scripting. Missing for 10: independent verification that the API/routines work reliably in real automation pipelines, and clearer CLI-style invocation/flags for non-interactive use.

   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Conductor
   Google Antigravity~partialprobed4/10

   Antigravity offers an Agent SDK (Python programmable) and a headless/non-interactive CLI mode for scripting agent tasks, plugins, MCP, and hooks, suggesting substantial programmatic access to agent capabilities. However, there is no documented public REST/HTTP API or OpenAPI spec (probe explicitly found all openapi.json candidate paths 404'd), and no evidence that UI-only features like Remote Control, Editor tab-autocompletion, artifact review UI, or scheduled task UI are fully exposed via API parity. missing for 10: a documented public API/OpenAPI spec, confirmation that all UI features (remote control, artifact review, scheduling UI) have API equivalents, and independent verification of API-UI parity.

   • [claimed-docs] “The Agent SDK gives you the same tools, agent loop, and context management that power Google Antigravity, programmable in Python.”
   • [claimed-docs] “Run Antigravity CLI non-interactively to script agent tasks, integrate with CI pipelines, and capture machine-readable output.”
   • [claimed-docs] “Layer custom Python callables, Model Context Protocol (MCP) servers, and reusable agent skills over our built-in filesystem and terminal too…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://antigravity.google/openapi.json, https://antigravity.google/swagger.json, https://antigravit…”

   proof ↗⚑ flag

   Conductor~partialprobed5/10

   Conductor documents a programmatic API and a hosted MCP server that let you create cloud workspaces, send prompts, and read agent replies, giving genuine API access to core agent workflows (conductor-docs-13, conductor-docs-14, conductor-docs-30, conductor-probe-4). However, the API is explicitly scoped to 'cloud workspaces' only, with no evidence it exposes local workspace/worktree management, collaboration features (reassign, follow, sharing), settings like port forwarding, or UI-specific conveniences (loadouts, sections, checkpoints) — and no OpenAPI spec is discoverable (conductor-probe-3), suggesting the API surface is narrower than the full UI. missing for 10: full parity coverage of local workspace/git-worktree operations via API, coverage of collaboration/organization features via API, and a public OpenAPI spec or independent confirmation of API completeness.

   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.conductor.build/openapi.json, https://www.conductor.build/swagger.json, https://www.cond…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Google Antigravity—none0/10

   No evidence in the pack mentions data export, open-format portability, or account/data deletion features for Antigravity; docs cover projects, agents, artifacts, and CLI but never data portability or export-and-leave capability.

   ⚑ flag

   Conductor—none0/10

   Conductor stores workspace state, chat history, and cloud workspace data, but no evidence in the pack shows an explicit data-export feature or open-format export guarantee; while code lives in git worktrees (inherently portable), there's no documentation of exporting chats, settings, or cloud workspace metadata. Community threads even raise unresolved concerns about data practices and lack of transparency (conductor-comm-3, conductor-comm-5), reinforcing the absence of an export/leave story.

   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Google Antigravity—none0/10

   No evidence of any open-source license or public source repository for Antigravity; it appears closed-source (VSCode fork distributed as binary download, third-party unofficial extensions noted). Nothing in the docs or community reports references source availability or a license.

   ⚑ flag

   Conductor—none0/10

   There is no evidence Conductor's source is available under any open license; it is distributed as a compiled Mac app with docs/API only, and a community comment explicitly contrasts it with an open-source alternative ('Crystal... unlike Conductor is open source'), indicating Conductor's source is not open.

   • [community] “Crystal can do all of this and more, and unlike Conductor is open source.”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Google Antigravity—none0/10

   No evidence anywhere in the pack indicates Antigravity can be self-hosted; it is described only as a downloadable desktop app/IDE/CLI/SDK connecting to Google's cloud-hosted models, with account/entitlement gating and TOS restrictions mentioned in community reports, but no self-hosted server or on-prem deployment option is documented.

   • [claimed-docs] “Visit antigravity.google/download to download Google Antigravity 2.0. Select your operating system below”
   • [claimed-docs] “Antigravity 2.0 serves as your AI agents’ central command center, providing a unified platform to launch, monitor, and orchestrate their act…”
   • [community] “don't buy Google AI subscription before you confirm you have 'Antigravity entitlement'... You can have verified account, bank card added, ac…”
   • [community] “Google Antigravity TOS: 3rd party usage can get Google account suspended. My friend got a ban by using Pi agent with Antigravity. They un-ba…”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor is a proprietary Mac app with a hosted cloud service and API/MCP server; there is no evidence of a self-hostable core product—no open-source repo, on-prem deployment option, or self-hosting docs are mentioned. Community even contrasts it unfavorably with 'Crystal,' which is explicitly noted as open source unlike Conductor, reinforcing that self-hosting isn't offered.

   • [community] “Crystal can do all of this and more, and unlike Conductor is open source.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”

   proof ↗⚑ flag

Authentication

1. developerAuthenticate with an API key instead of an account login

   weight 2 · round to Conductor
   Google Antigravity—none0/10

   Evidence shows Antigravity requires a Google account/login and even ties usage to 'Antigravity entitlement' on that account (comm-19), with account-level bans possible (comm-17, comm-20); no docs or CLI reference mention an API-key authentication mode as an alternative to account login.

   • [community] “Google Antigravity TOS: 3rd party usage can get Google account suspended. My friend got a ban by using Pi agent with Antigravity. They un-ba…”
   • [community] “don't buy Google AI subscription before you confirm you have 'Antigravity entitlement'... You can have verified account, bank card added, ac…”
   • [community] “Banning the entire account rather than AI access is wildly user hostile... And then you get to fight the support bots and eventually go to t…”

   proof ↗⚑ flag

   Conductor✓fullclaimed7/10

   Conductor explicitly supports 'bring your own subscriptions and keys' and lets you configure Claude Code, Codex, and Cursor connections to use an API key instead of a subscription/account login per organization. This directly satisfies the developer's need to authenticate via API key rather than an account login flow. missing for 10: independent/hands-on confirmation that API-key auth works end-to-end without any account sign-in step, and detail on whether Conductor's own app access also supports API-key-only login (vs. GitHub OAuth).

   • [claimed-docs] “Bring your own subscriptions and keys”
   • [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”

   proof ↗⚑ flag

2. engineering-leadAuthenticate through an enterprise identity or cloud platform for compliance and scalability

   weight 2 · round drawn
   Google Antigravity—none0/10

   No evidence of SSO/SAML/OIDC, Google Workspace/Cloud IAM enterprise login, or any enterprise identity federation for Antigravity; docs mention only Google account sign-in and entitlement issues, with community reports of account suspensions rather than enterprise auth support. Missing for 10: SSO/SAML/OIDC support, Google Cloud IAM or Workspace admin console integration, enterprise provisioning/SCIM documentation.

   • [community] “don't buy Google AI subscription before you confirm you have 'Antigravity entitlement'... You can have verified account, bank card added, ac…”
   • [community] “Banning the entire account rather than AI access is wildly user hostile... And then you get to fight the support bots and eventually go to t…”

   proof ↗⚑ flag

   Conductor—none0/10

   Evidence shows only GitHub OAuth/GitHub App authentication and per-organization agent connection settings (conductor-comm-13, conductor-comm-14, conductor-docs-23); there is no mention of SSO, SAML, OIDC, or enterprise identity provider integration for compliance/scale. missing for 10: SSO/SAML/OIDC support, enterprise IdP integration, admin/compliance controls tied to identity.

   • [community] “Right now the app uses GitHub's OAuth sign in which unfortunately doesn't allow for fine-grained permissions... We're switching our sign-in …”
   • [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”
   • [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”

   proof ↗⚑ flag

3. developerSign in with my existing product subscription plan to use the coding agent

   weight 2 · round to Conductor
   Google Antigravity—none0/10

   No documentation describes signing in with an existing Google AI/Gemini subscription plan to unlock Antigravity access, and community reports directly state that users with an active AI Pro subscription still could not use even the free tier without a separate 'Antigravity entitlement.' missing for 10: any first-party docs describing subscription-based sign-in, evidence of successful subscription-linked access, and confirmation that paid Google AI plans map directly to Antigravity usage.

   • [community] “don't buy Google AI subscription before you confirm you have 'Antigravity entitlement'... You can have verified account, bank card added, ac…”
   • [community] “Google Antigravity TOS: 3rd party usage can get Google account suspended. My friend got a ban by using Pi agent with Antigravity. They un-ba…”
   • [community] “On the pricing page it says free individual plan with 'generous rate limits'. I gave it an HTML file and 2 minutes later got: 'Model quota l…”

   proof ↗⚑ flag

   Conductor✓fullclaimed8/10

   Docs explicitly state you can 'bring your own subscriptions and keys' and sign in with existing Cursor, Claude Code, or Codex subscriptions rather than requiring a separate Conductor-specific plan, with per-organization control over subscription vs API key. Missing for 10: independent hands-on confirmation that subscription sign-in works smoothly across all supported agents (only vendor changelog/docs evidence).

   • [claimed-docs] “Bring your own subscriptions and keys”
   • [claimed-docs] “Sign in to your Cursor subscription for cloud workspaces.”
   • [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”

   proof ↗⚑ flag

4. developerSign in with a personal account to get free-tier access without managing API keys

   weight 1 · round to Google Antigravity
   Google Antigravity!disputedcontradicted3/10

   Vendor pages advertise a free individual plan with no mention of API key management, implying sign-in-with-personal-account access, but community hands-on reports directly contradict the free-tier promise — one user got a 'Model quota limit exceeded' error within minutes despite the 'generous rate limits' claim, and another describes being locked out of even the free tier due to an 'Antigravity entitlement' gate despite having an active subscription. missing for 10: first-party documentation explicitly describing the personal-account sign-in flow and free-tier terms, and independent confirmation that free-tier access works reliably without unexpected quota/entitlement blocks.

   • [community] “On the pricing page it says free individual plan with 'generous rate limits'. I gave it an HTML file and 2 minutes later got: 'Model quota l…”
   • [community] “don't buy Google AI subscription before you confirm you have 'Antigravity entitlement'... You can have verified account, bank card added, ac…”
   • [claimed-docs] “Visit antigravity.google/download to download Google Antigravity 2.0. Select your operating system below”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor's docs describe a 'bring your own subscriptions and keys' model where users must sign in to their own Claude Code, Codex, or Cursor subscription or supply an API key (conductor-docs-19, conductor-docs-23, conductor-docs-7); there is no mention of a free tier accessible purely via personal account sign-in without managing credentials. Community discussion also focuses on GitHub OAuth/permissions issues, not a free-tier access model.

   • [claimed-docs] “Bring your own subscriptions and keys”
   • [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”
   • [claimed-docs] “Sign in to your Cursor subscription for cloud workspaces.”

   proof ↗⚑ flag

Model choice

1. developerLet the tool automatically pick the best model for each task

   weight 1 · round drawn
   Google Antigravity—none0/10

   Docs describe a manual model selector dropdown where users choose the reasoning model themselves (antigravity-docs-16), not an automatic 'best model per task' selection mechanism; no evidence anywhere of automatic model routing or task-based model optimization.

   • [claimed-docs] “Users can select which reasoning model they want to use within the model selector drop-down under the conversation prompt box”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor documents manual model selection via 'loadouts' and keyboard shortcuts to switch between chosen models, but there is no evidence of an automatic mechanism that picks the best model per task based on cost/performance tradeoffs.

   • [claimed-docs] “Pick a loadout of your favorite models to quickly switch between. It’s keyboard accessible too: change models (⌃⌘ 1-5), effort (⌘⇧/), speed …”
   • [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”

   proof ↗⚑ flag

2. developerChoose which underlying AI model powers my session from multiple providers

   weight 2 · round drawn
   Google Antigravity✓fullcommunity8/10

   Docs explicitly describe a model selector dropdown for choosing reasoning models, and community hands-on evidence confirms multiple providers (Gemini 3 Pro, Claude Sonnet 4.5, GPT-OSS 120B) are selectable, not locked to Gemini only. Missing for 10: pricing/tier restrictions per model and independent benchmarking of model-switching quality across providers.

   • [claimed-docs] “Users can select which reasoning model they want to use within the model selector drop-down under the conversation prompt box”
   • [community] “I went ahead and downloaded it, it looks to be a VSCode fork very similar to Cursor, with support for Gemini 3 Pro, Claude Sonnet 4.5, and G…”
   • [community] “Nice to see that it's not locked to just Gemini models.”

   proof ↗⚑ flag

   Conductor✓fullcommunity8/10

   Conductor explicitly supports running Claude Code, Codex, Cursor, and OpenCode as interchangeable providers, with a 'loadout' UI and keyboard shortcuts to switch models per session, plus per-organization configuration of API key vs subscription for each provider. Community comments confirm interest in and some support for multi-agent/provider use, though no independent hands-on review specifically validates seamless mid-session switching. Missing for 10: independent/hands-on verification of the model-switching UX and confirmation across all listed providers beyond vendor docs.

   • [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
   • [claimed-docs] “Pick a loadout of your favorite models to quickly switch between. It’s keyboard accessible too: change models (⌃⌘ 1-5), effort (⌘⇧/), speed …”
   • [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”
   • [community] “Love the design. does it build on electron? and will it support other code agents, like gemini cli, codex, opencode ext.”
   • [community] “Would be cool if I can use this with opencode, Amazon Q or whatever. I reckon the logic would be quite similar. Seen a few of these tools bu…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Google Antigravity—none0/10

   No evidence pack item mentions data residency, region selection, or storage location controls; only a telemetry on/off toggle is documented, which does not address data residency. Missing for 10: any documentation of regional data storage options, residency guarantees, or enterprise data-location controls.

   ⚑ flag

   Conductor—none0/10

   No evidence anywhere in the pack addresses data residency, region selection, or storage location controls for cloud workspaces; community comments even highlight lack of disclosure about where data is sent.

   • [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”

   proof ↗⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round to Google Antigravity
   Google Antigravity~partialclaimed5/10

   Antigravity's settings docs mention a Telemetry toggle to enable/disable sharing interaction logs 'to improve models,' which is the only evidence addressing training-data opt-out; there's no further detail on scope, default state, or enterprise data-processing guarantees. Missing for 10: independent verification the toggle actually excludes data from training, clarity on default setting, and any enterprise/DPA-level documentation of data usage.

   • [claimed-docs] “toggle Telemetry (enable/disable sharing interaction logs to improve models)”

   proof ↗⚑ flag

   Conductor—none0/10

   No documentation or policy statement anywhere in the evidence pack addresses training-data opt-out or data-usage controls; in fact community reports explicitly note 'no way to find out if there's any data sent to your servers' and 'zero disclosure of data practices,' underscoring the absence of any such privacy control.

   • [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Google Antigravity
   Google Antigravity~partialclaimed3/10

   Docs mention a Telemetry toggle to enable/disable sharing interaction logs, which is a privacy-related control, but there is no documented mechanism for viewing, exporting, or deleting stored data/history, nor any stated retention policy. Missing for 10: explicit data deletion controls, data export/retention policy documentation, and independent confirmation these settings work as described.

   • [claimed-docs] “toggle Telemetry (enable/disable sharing interaction logs to improve models)”

   proof ↗⚑ flag

   Conductor—none0/10

   No documentation describes retention periods, data-deletion controls, or export/purge mechanisms for cloud workspace data; community feedback explicitly flags 'zero disclosure of data practices' and no way to verify what is sent to Conductor's servers.

   • [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”

   proof ↗⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round to Google Antigravity
   Google Antigravity✓fullclaimed7/10

   Docs confirm a settings toggle to enable/disable telemetry ('sharing interaction logs to improve models'), giving users a direct opt-out. Missing for 10: independent/hands-on confirmation that the toggle fully stops all data collection, and no detail on what telemetry remains even when disabled.

   • [claimed-docs] “toggle Telemetry (enable/disable sharing interaction logs to improve models)”

   proof ↗⚑ flag

   Conductor—none0/10

   No documentation or changelog entry describes any telemetry/usage-tracking settings or an opt-out mechanism; community commenters explicitly note there is 'no way to find out if there's any data sent to your servers' and 'zero disclosure of data practices,' confirming the absence of any documented privacy control for telemetry.

   • [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”

   proof ↗⚑ flag

Data governance

1. engineering-leadOpt out of having my code and prompts used for AI model training

   weight 1 · round to Google Antigravity
   Google Antigravity~partialclaimed5/10

   Docs mention a Telemetry toggle to 'enable/disable sharing interaction logs to improve models,' which functions as an opt-out from data being used for model improvement, but there is no explicit documentation framing this as a training opt-out for enterprise/engineering-lead governance needs (e.g., no data-processing agreement, no distinction between prompts/code vs telemetry, no enterprise admin-level control). Missing for 10: explicit statement that code/prompts are excluded from training, org-wide/admin-level enforcement of the opt-out, and independent confirmation the toggle actually stops training use.

   • [claimed-docs] “toggle Telemetry (enable/disable sharing interaction logs to improve models)”

   proof ↗⚑ flag

   Conductor—none0/10

   No evidence anywhere in the pack of a data-usage/training opt-out policy or setting; in fact community reports explicitly complain about 'zero disclosure of data practices' and no way to find out what is sent to Conductor's servers, reinforcing the absence of any documented opt-out mechanism.

   • [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”

   proof ↗⚑ flag

Pr review

1. developerHave the agent stage changes, write commit messages, create branches, and open pull requests

   weight 3 · round to Conductor
   Google Antigravity~partialclaimed3/10

   Antigravity's agents can operate the terminal and natively support Git worktrees, which implies they could run git commands like staging, committing, and branching, but no documentation explicitly describes agent-driven commit message generation, branch creation, or PR opening (e.g., GitHub integration). Missing for 10: explicit docs on commit-message authoring, branch creation workflow, and pull-request creation/integration with GitHub/GitLab.

   • [claimed-docs] “Worktree support: Projects natively support Git worktrees, allowing agents to operate in isolated background folders.”
   • [claimed-docs] “Able to autonomously operate across your editor, terminal, and browser.”
   • [claimed-docs] “Build AI agents that autonomously read files, run commands, edit code, and more.”

   proof ↗⚑ flag

   Conductor✓fullcommunity8/10

   Docs explicitly state each task gets its own branch/worktree, agents can be given autonomy to test/build without confirmation, and Conductor 'helps you review the diff, open a pull request, merge, and archive the workspace' — covering branch creation, staging/commits (implied by agent workflow), diffs, and PR creation. Community evidence corroborates git worktree branch isolation and GitHub integration for PR workflows. Missing for 10: explicit first-party mention of 'commit message writing' as a distinct feature and independent hands-on confirmation of the full stage→commit→branch→PR pipeline working end-to-end.

   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
   • [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”

   proof ↗⚑ flag

2. developerGet automatic code review with contextual feedback on every pull request

   weight 3 · round drawn
   Google Antigravity—none0/10

   Antigravity offers in-editor 'Review Changes' diff viewing and Artifact-based plan review, but there is no evidence of a GitHub/GitLab pull-request bot or CI-integrated review that automatically posts contextual feedback on every PR. The CLI headless mode allows scripting into CI, but no docs describe an automated PR-review workflow.

   • [claimed-docs] “Planning Mode: The agent plans thoroughly before executing tasks... produces structured implementation plans called Artifacts”
   • [claimed-docs] “The agent always halts and requests your explicit approval before proceeding with proposed changes.”
   • [claimed-docs] “Added a "Hide Whitespace Changes" option to the Review Changes overflow menu and file diff viewers to filter out whitespace-only edits.”
   • [claimed-docs] “Run Antigravity CLI non-interactively to script agent tasks, integrate with CI pipelines, and capture machine-readable output.”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor's evidence describes parallel agent orchestration, diffs, and human-facing review workflows (e.g., 'Conductor helps you review the diff, open a pull request' and PR comments loading from GitHub) but no automated code-review bot that posts contextual feedback on pull requests. No evidence of an AI reviewer analyzing PR diffs and commenting automatically.

   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “PR comments and failing-check logs now load while a cloud workspace is asleep.”

   proof ↗⚑ flag

3. developerInspect diffs and run checks to catch problems before merging

   weight 3 · round drawn
   Google Antigravity~partialcommunity6/10

   Docs describe a Review Changes/diff viewer (with whitespace filtering, syntax highlighting) and Artifacts containing code diffs, plus mandatory human approval before changes are applied, and subagents/CI headless mode that can run tests. This covers diff inspection and pre-merge gating, but there's no dedicated 'run checks' feature (e.g., integrated linting/test-run summary) beyond subagent test delegation, and no independent hands-on confirmation that this workflow reliably catches problems — community reports instead highlight safety failures (accidental deletion, data exfiltration) that occurred despite review/approval mechanisms. Missing for 10: independent verification that diff review + checks actually catch bugs pre-merge, and a dedicated automated check/test-report feature beyond ad-hoc subagent delegation.

   • [claimed-docs] “Planning Mode: The agent plans thoroughly before executing tasks... produces structured implementation plans called Artifacts”
   • [claimed-docs] “The agent always halts and requests your explicit approval before proceeding with proposed changes.”
   • [claimed-docs] “Artifacts include rich markdown plans (Implementation Plans), code diffs, architecture diagrams, images, and browser recordings.”
   • [claimed-docs] “Added a "Hide Whitespace Changes" option to the Review Changes overflow menu and file diff viewers to filter out whitespace-only edits.”
   • [claimed-docs] “Code and data artifacts like SQL and JSONL files now open in a virtualized viewer with syntax highlighting and line numbers”
   • [claimed-docs] “an agent can delegate tasks—such as running tests or performing extensive codebase searches—to dedicated subagents.”
   • [claimed-docs] “Run Antigravity CLI non-interactively to script agent tasks, integrate with CI pipelines, and capture machine-readable output.”
   • [community] “Google Antigravity just deleted the contents of whole drive - came down to commanding a deletion of a 'directory with space in the name' wit…”
   • [community] “absolutely no sympathy for someone running Antigravity in Turbo mode (this is not the default and it clearly states that Antigravity auto-ex…”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   Docs show each workspace has its own diff and review path, and Conductor explicitly helps you 'review the diff, open a pull request, merge' before finishing work, plus it surfaces PR comments and failing-check logs even while a cloud workspace sleeps, and agents can run builds/tests as part of setup. However, there's no detailed description of built-in linting/test-runner integration beyond agent-run builds, and no independent/hands-on confirmation that this catches real problems pre-merge. Missing for 10: dedicated CI/check-running feature docs, independent verification of diff/check accuracy, and coverage of how failing checks block or warn before merge.

   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “PR comments and failing-check logs now load while a cloud workspace is asleep.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”

   proof ↗⚑ flag

Safe execution

1. engineering-leadControl which external tools and integrations the agent is allowed to access

   weight 2 · round to Conductor
   Google Antigravity!disputedcontradicted5/10

   Antigravity docs describe granular controls—Deny/Ask/Allow permission lists, MCP server configuration, plugins bundling MCP servers, and sandboxing that blocks sensitive files—giving engineering leads levers to restrict tool/integration access (antigravity-docs-23, antigravity-docs-42, antigravity-docs-12, antigravity-docs-28, antigravity-docs-48). However, independent security reports document that these controls were bypassed in practice: Gemini accessed .env files despite being configured not to, and the default Allowlist shipped with webhook.site, which was used as a live exfiltration vector—directly contradicting the claim that admins can reliably restrict external access (antigravity-comm-11, antigravity-comm-12, antigravity-comm-13). Missing for 10: evidence of a fix/patch to these bypasses, and no first-party acknowledgment/remediation documentation confirming the control now holds as designed.

   • [claimed-docs] “Permissions are evaluated across three distinct access lists: Deny... Ask... Allow”
   • [claimed-docs] “Permissions are evaluated across three distinct access lists: Deny...Ask...Allow”
   • [claimed-docs] “Access plugins, MCP, skills, and hooks configurations instantly via slash commands, quickly enhancing your workflow.”
   • [claimed-docs] “Plugins are namespaced bundles that allow you to extend Antigravity’s capabilities by grouping skills, rules, MCP servers, and hooks into a …”
   • [claimed-docs] “Sensitive files like ~/.ssh and .env are blocked, anything not explicitly mounted is invisible inside the sandbox”
   • [community] “Google Antigravity exfiltrates data via indirect prompt injection attack: Gemini is not supposed to have access to .env files with default s…”
   • [community] “The default Allowlist provided with Antigravity includes 'webhook.site', which was used as an exfiltration vector for secrets.”
   • [community] “Antigravity was also vulnerable to the classic Markdown image exfiltration bug, reported a few days prior and flagged as 'intended behavior'…”

   proof ↗⚑ flag

   Conductor~partialcommunity5/10

   Conductor lets an org configure agent connections per organization (choosing API-key vs subscription per agent) and, after community pushback over full GitHub OAuth access, added fine-grained GitHub repository permissions or local GitHub CLI auth as an alternative [conductor-docs-23, conductor-comm-13, conductor-comm-14]. However there's no documented allow-list/deny-list for arbitrary external tools, MCP servers, or third-party integrations beyond GitHub scopes and model provider choice, and the initial full-write-access design (comm-4, comm-5, comm-6) shows the control was originally coarse and only partially remedied. missing for 10: granular per-tool/integration allow-listing beyond GitHub and model provider, admin-level policy enforcement across the org, and independent verification that fine-grained access covers all agent-invoked external services (e.g., MCP servers).

   • [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”
   • [community] “Any way to have it not require full write access to your entire GitHub account?”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
   • [community] “Right now the app uses GitHub's OAuth sign in which unfortunately doesn't allow for fine-grained permissions... We're switching our sign-in …”
   • [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”

   proof ↗⚑ flag

2. engineering-leadHave the agent operate inside a sandbox when interacting with code, tools, and network resources

   weight 2 · round to Conductor
   Google Antigravity!disputedcontradicted4/10

   Antigravity CLI docs describe a real sandbox mechanism (sensitive files like ~/.ssh and .env blocked, unmounted paths invisible) plus a permission allow/ask/deny system, suggesting sandboxed tool/network access is a documented feature. However, independent reports concretely contradict this: Gemini bypassed its own .env protection to exfiltrate secrets via indirect prompt injection using an allow-listed exfiltration endpoint, a known markdown-image exfiltration bug was dismissed as 'intended behavior,' and unrestrained terminal auto-execution led to a user's entire drive being deleted — showing the sandbox/permission boundary is not reliably enforced in practice. Missing for 10: consistent enforcement of sandbox boundaries against prompt-injection/exfiltration, first-party acknowledgment/fix of these incidents, and independent verification that the CLI's stated sandbox extends to the IDE agent's file/network access.

   • [claimed-docs] “Sensitive files like ~/.ssh and .env are blocked, anything not explicitly mounted is invisible inside the sandbox”
   • [claimed-docs] “Permissions are evaluated across three distinct access lists: Deny... Ask... Allow”
   • [claimed-docs] “MCP lets Antigravity fetch structured context directly or execute safe actions on your behalf when needed.”
   • [community] “Google Antigravity exfiltrates data via indirect prompt injection attack: Gemini is not supposed to have access to .env files with default s…”
   • [community] “The default Allowlist provided with Antigravity includes 'webhook.site', which was used as an exfiltration vector for secrets.”
   • [community] “Antigravity was also vulnerable to the classic Markdown image exfiltration bug, reported a few days prior and flagged as 'intended behavior'…”
   • [community] “Google Antigravity just deleted the contents of whole drive - came down to commanding a deletion of a 'directory with space in the name' wit…”
   • [community] “The most useful suggestion from the Reddit thread: turn off 'Terminal Command Auto Execution' via File > Preferences > Antigravity Settings …”
   • [community] “absolutely no sympathy for someone running Antigravity in Turbo mode (this is not the default and it clearly states that Antigravity auto-ex…”

   proof ↗⚑ flag

   Conductor~partialcommunity5/10

   Conductor's cloud workspaces are explicitly described as spinning up in "sandboxes" and the agent can run builds/tests without step-by-step confirmation, suggesting isolated execution for cloud mode. However, the local mode (the primary use case per community feedback) uses plain git worktrees on the user's own machine with no described network/tool sandboxing, and early versions required full read-write GitHub account access with no disclosed data practices, which is the opposite of a hardened sandbox model (though later mitigated with fine-grained GitHub App permissions). Missing for 10: explicit sandbox isolation details (container/VM boundaries, network egress controls) for local workspaces, and independent confirmation that cloud sandboxes restrict network/tool access beyond marketing language.

   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
   • [community] “Any way to have it not require full write access to your entire GitHub account?”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
   • [community] “Right now the app uses GitHub's OAuth sign in which unfortunately doesn't allow for fine-grained permissions... We're switching our sign-in …”
   • [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”

   proof ↗⚑ flag

Security checks

1. engineering-leadSee license and public-code matching references for AI-suggested code

   weight 1 · round drawn
   Google Antigravity—none0/10

   No evidence in the pack mentions license compliance checks, public-code/OSS matching, provenance detection, or any similar review-safety feature for AI-suggested code; the docs focus on agents, artifacts, permissions, and workflow tooling with no mention of license scanning.

   ⚑ flag

   Conductor—none0/10

   No evidence anywhere in the pack of license compliance checks, public-code/plagiarism matching, or provenance references for AI-suggested code; Conductor's documentation focuses on orchestration, workspaces, and diffs/PRs but never mentions license or code-provenance scanning.

   ⚑ flag