AIREITERCincuenta millones de líneas de Lean 4 para una sola demostración, 800.000 líneas de Rust seguro en dos semanas y kernels de TPU 4,09 veces más rápidos. La actualización de investigación de Google del 13 de noviembre deja claro hasta dónde puede llegar Antigravity Teamwork. Pero hay una condición importante: normalmente solo compensa en proyectos organizados por hitos que duran horas o días, porque una única ejecución puede consumir una parte considerable de la cuota semanal.
Qué es realmente Antigravity Teamwork
Antigravity Teamwork es el flujo de orquestación multiagente de Google para trabajos grandes y difíciles de verificar dentro de Antigravity. El comando /teamwork pone en marcha un equipo coordinado —Sentinel, Project Orchestrator, Explorers, Workers, Critic, Challenger, Auditor y Success Auditor— que planifica por hitos, trabaja en un directorio de proyecto independiente y exige una verificación externa antes de dar por cerrado cada hito.
Teamwork funciona en dos fases. La primera es una entrevista de alcance en la que el agente principal registra los objetivos, requisitos, métodos de verificación, criterios de aceptación y directorio del proyecto (por defecto, ~/teamwork_projects/{PROJECT_NAME}). La segunda es la ejecución autónoma mediante artefactos estructurados —solicitud, plan del proyecto y registros de progreso—, con propiedad exclusiva de los archivos para cada Worker y controles de Critic, Challenger, Auditor y Success Auditor antes de pasar al siguiente paso (documentación de Teamwork).
La entrevista también fija el nivel de exigencia mediante los modos de integridad:
development(predeterminado): iteración rápida; permite reutilizar código y frameworks, pero rechaza resultados inventados e implementaciones de fachada.demo: presentaciones reproducibles; prohíbe copiar la lógica central de proyectos open source, delegar el trabajo principal externamente y consultar el código de los tests para obtener las respuestas.benchmark: máxima exigencia; implementación desde cero usando la biblioteca estándar del lenguaje y evaluación independiente contra una referencia de verdad.
El flujo de ejecución adapta automáticamente la composición del equipo:
- Programación distribuida general (predeterminada): ingeniería y refactorizaciones que afectan a varios archivos.
- Programación iterativa: una corrección acotada cuando el prompt indica que hay que «mantenerlo pequeño».
- Revisión de documentos: análisis crítico de papers y documentos de diseño desde varios ángulos.
- Matemáticas / Proof y Matemáticas / Proof Large Team: razonamiento formal y campañas amplias de demostración de conjeturas.
En los planes de pago, el horizonte habitual es de horas a días, tanto en la aplicación de Antigravity como en la CLI (documentación de Teamwork).
Teamwork frente a Swarm, Boost y los subagentes
Antigravity Teamwork solo es la opción adecuada cuando el trabajo necesita hitos, controles de auditoría y un directorio dedicado. Para la mayoría de las tareas del día a día bastan alternativas más ligeras; elegir mal puede quemar cuota sin aportar nada.
| Herramienta | Ideal para | Cómo se inicia | Espacio de trabajo | Verificación | Horizonte habitual | Plan |
|---|---|---|---|---|---|---|
| Subagents | Tareas secundarias concretas: investigar un repositorio, comprobar el navegador o ejecutar tests | Automático o @subagent | Espacio de trabajo actual | El agente principal revisa la respuesta | De segundos a minutos | Todos los planes |
Boost (/boost) | Problemas difíciles pero acotados: condiciones de carrera, bugs complicados o algoritmos | /boost <task>, se inicia inmediatamente | Espacio de trabajo actual, con contextos aislados | Los Workers se cuestionan y vuelven a verificar el trabajo; el orquestador hace comprobaciones puntuales | De segundos a horas | Planes de pago |
Swarm (/swarm) | Trabajo amplio que se puede dividir con claridad: archivos, paquetes o suites de tests | /swarm <task>, se inicia inmediatamente | Espacio de trabajo actual o copias por Worker | Un @verifier dedicado revisa los diffs y ejecuta los tests | De minutos a horas | Google AI Pro y Ultra |
Teamwork (/teamwork) | Proyectos con varios hitos: migraciones, simulaciones o demostraciones formales | /teamwork <goal> + entrevista de alcance | ~/teamwork_projects/{PROJECT_NAME} dedicado | Controles de Critic, Challenger, Auditor y Success Auditor | De horas a días | Planes de pago |
Usa Teamwork para migrar una API REST a Fastify en decenas de archivos con cobertura completa de tests, crear un simulador ciclo a ciclo validado contra temporizadores de hardware o desarrollar una demostración formal comprobada con Lean 4. Elige Swarm para añadir validación a tres handlers de API independientes, con un Worker por archivo y un verificador que ejecute npm test. Boost encaja mejor con una única condición de carrera o una refactorización acoplada en la que la secuencia desafío-corrección-verificación sea más eficaz que varios Workers en paralelo. Para investigar algo en segundo plano mientras la conversación principal continúa, usa subagentes.
La confusión no es imaginaria. Un usuario de Antigravity lo resumió así:
«agy ya tiene demasiados modos y, sinceramente, empieza a ser confuso. Ahora mismo tenemos ... /teamwork (proyectos largos por hitos con controles de auditoría) ... y ahora también flujos dinámicos... siendo justos, no necesitamos todos. Menos modos significan menos confusión...»
— @Heamanth_alturi (X)
La regla rápida es sencilla: si el trabajo tiene una única definición de terminado y se puede completar en una sesión, Teamwork es excesivo. Si necesita un artefacto de planificación, otro de progreso y que alguien distinto del autor apruebe cada hito, Teamwork sí encaja.
Qué demostró realmente la actualización de investigación de noviembre
La actualización de Google Research del 13 de noviembre es un informe de resultados, no un anuncio de lanzamiento. Teamwork ya existía antes como /teamwork-preview para los planes de pago; la actualización documenta lo que consiguieron equipos organizados por hitos con Gemini 4 Argon, Carbon y Hydrogen. Los humanos siguieron definiendo los problemas, las restricciones y los sistemas de evaluación, mientras críticos nuevos revisaban el trabajo desde contextos limpios.
| Área | Proyecto de ejemplo | Escala de agentes | Resultado comunicado |
|---|---|---|---|
| Matemáticas | Demostración de la conjetura de Courtade–Kumar (Google, CUHK, USC, CMU) | Patrón de demostración larga, formalización en Lean 4 | Demostración completa en aproximadamente 50 millones de líneas de código Lean |
| Química | Estructura molecular a partir de datos de RMN | 30 agentes especializados + simulador físico | 95 % de coincidencias exactas en el top 1 y 100 % en el top 3 |
| Sistemas | Reescritura de Zircon de C++ a Rust | Campaña de Argon de dos semanas | Aproximadamente 800.000 líneas de Rust seguro, con arranque en arm64 |
| Hardware de ML | Optimización de kernels de TPU (DuoDiscover) | Evaluadores proxy (23 s frente a 7–32 min) | Aceleración media de 4,09 veces en 17 kernels de JAXBench |
Google también abrió solicitudes para que 10.000 investigadores académicos reciban acceso de primer nivel durante seis meses. Algunos de los flujos descritos en la publicación todavía se están desplegando para usuarios externos, así que conviene leer la tabla como una muestra de capacidades, no como una promesa de que todos los proyectos repetirán esos resultados.
La factura de cuota que las páginas oficiales no enseñan
La página de precios de Antigravity indica que Individual cuesta 0 $ al mes e incluye completado de Tab ilimitado y límites semanales básicos. Pro y Ultra ofrecen límites superiores y una bolsa flexible de créditos de IA, pero no publican el número exacto de solicitudes. Las cuotas de Pro y Ultra se renuevan cada cinco horas hasta alcanzar el límite semanal, y el exceso puede pagarse con créditos comprados mediante un ajuste Never o Always (documentación de planes). Teamwork y Boost requieren planes de pago; Swarm exige Pro o Ultra (documentación de Swarm). La propia publicación de Google sobre el sistema operativo advertía de que un par de tareas complejas de preview podían consumir una semana completa de cuota (publicación sobre Antigravity OS).
Los testimonios de usuarios son anecdóticos y no constituyen una muestra representativa, pero van desde un consumo razonable hasta un gasto considerable:
«madre mía, se pulió toda mi cuota en apenas 5 minutos (3.5 Flash (high))»
— u/Several_Bag_3665 (Reddit)
«en realidad es muy usable con la suscripción Ultra; tuve un preview de teamwork funcionando durante 50 minutos seguidos con gemini flash medium y consumió aproximadamente el 20 % de mi cuota de 5 horas, además de hacer refactorizaciones enormes correctamente»
— u/ningkaiyang (Reddit)
Dos mecanismos explican esta diferencia. La documentación de Antigravity para /swarm indica que cada Worker es un agente separado, que los Workers en espera no consumen tokens y que los que agotan la cuota se pausan en lugar de reintentarlo automáticamente hasta que haya una nueva publicación en el panel, un cambio de modelo o un mensaje directo (documentación de Swarm). La documentación de Teamwork no publica la misma afirmación sobre la reanudación, así que conviene tratarlo como un comportamiento multiagente compartido que hay que verificar según el plan. Teamwork también genera artefactos intermedios voluminosos —solicitud, plan y registros de progreso, además de notas de trabajo y logs de verificación de cada agente (documentación de Teamwork)—. Ese material representa el estado esperado del proceso, no necesariamente progreso real.
Cómo probar Teamwork sin quemar una semana de cuota
Iniciar Teamwork requiere un solo comando, pero la entrevista de alcance es la que determina el coste. En la aplicación, abre una conversación de proyecto y escribe /teamwork Migrate our REST API service from Express to Fastify, including full test coverage, TypeScript typing, and benchmark validation. En la CLI, ejecuta /teamwork Design and implement a cycle-accurate memory controller with lockstep simulation tests desde el directorio del proyecto. Puedes seguir el proceso desde el panel de subagentes o la barra de estado de la CLI, saltar a las aprobaciones con Alt+J y consultar en tiempo real los artefactos de planificación y progreso (documentación de Teamwork).
Considera la fase 1 como tu principal control de costes. Define qué quieres conseguir, no cómo: el objetivo, el público (demo, producción o benchmark), las restricciones estrictas y una comprobación objetiva por requisito, como una suite de tests o un script de métricas. Elige development para iterar y reserva demo o benchmark para los casos en los que importe demostrar algo de forma presentable o desde cero, porque una verificación más estricta implica más trabajo de los agentes. Antes de aprobar, confirma que el directorio dedicado sea el correcto.
Durante la ejecución, mantén la dirección centralizada. Canaliza los cambios de alcance a través del coordinador, integra los cambios de los Workers antes de eliminarlos y evalúa el progreso por los controles de los hitos y las pruebas, no por el número de archivos. En Settings, configura el exceso de créditos de IA como Never durante la primera ejecución para que, al agotarse la cuota base, el trabajo se detenga en lugar de gastar créditos silenciosamente (documentación de planes). Cuando la documentación del plan lo permita, combina un planificador más potente con una implementación más barata: Ultra admite Orchestrator (Carbon) y Orchestrator (Argon), que planifican con Gemini 4 Carbon o Argon mientras Gemini 4 Hydrogen implementa (página de precios). Es un equilibrio que también aparece en las comparativas entre Carbon y Argon.
Preguntas frecuentes
¿Cuál es la diferencia entre /teamwork y /teamwork-preview?
/teamwork-preview era el nombre anterior de la preview de investigación. La documentación actual de Teamwork utiliza /teamwork en los planes de pago; Google no ha publicado una declaración independiente sobre su disponibilidad general.
¿Se puede pausar o recuperar Teamwork después de agotar la cuota?
El comportamiento documentado de /swarm indica que los Workers que agotan la cuota se pausan hasta que haya una nueva publicación en el panel, un cambio de modelo o un mensaje directo (documentación de Swarm); la documentación de Teamwork no confirma la misma ruta de reanudación. Antes de reiniciar, revisa los artefactos de plan y progreso en ~/teamwork_projects/{PROJECT_NAME}, ya que los hitos parciales persisten como archivos.
¿Qué artefactos genera Teamwork?
Genera artefactos de solicitud, plan del proyecto y progreso, además de notas de trabajo de cada agente, scripts auxiliares y logs de verificación (documentación de Teamwork). Es normal encontrar una gran cantidad de contenido Markdown; mide el progreso por los controles de los hitos y las pruebas, no por el número de archivos.
¿Es seguro usar Teamwork en repositorios de producción?
Teamwork aísla el trabajo en un directorio dedicado, con propiedad exclusiva de los archivos y controles de auditoría, lo que reduce el riesgo de colisiones (documentación de Teamwork). Aun así, cualquier uso en producción requiere que una persona revise los criterios de aceptación, las pruebas y la pasada final de Success Auditor antes de hacer merge.
La lista de comprobación de 30 segundos antes de escribir /teamwork
Escribe /teamwork solo si se cumplen las cinco condiciones: el trabajo abarca varios hitos, cada hito tiene una comprobación objetiva, un directorio dedicado resulta útil, los controles de auditoría independientes son importantes y una ejecución que consuma mucha cuota sale más barata que semanas de trabajo manual. En caso contrario, usa Swarm para trabajos paralelizables, Boost para bugs difíciles y acotados o subagentes para tareas secundarias de investigación. Reserva Teamwork para el proyecto que realmente necesite un equipo.