Configura agents.md y corre microservicios en paralelo

Configurar un archivo agents.md en Antigravity es la manera de darle instrucciones específicas a cada microservicio para que trabaje con reglas propias. Si estás aprendiendo a orquestar subagentes con este IDE, aquí verás cómo crear estos ficheros, lanzar procesos en paralelo y aprovechar el plan de implementación antes de tocar una sola línea de código.

Este flujo es útil para quien ya conoce la interfaz del manager y el IDE, y quiere pasar de la teoría a las primeras configuraciones reales de un proyecto con front-end y servicio de autenticación corriendo al mismo tiempo.

Qué es un fichero agents.md y para qué sirve

Una vez familiarizado con la interfaz, el primer paso es abrir el IDE y crear las carpetas a mano si aún no existen. Sobre la carpeta de front-end generas un nuevo fichero llamado agents.md.

Estos ficheros son instrucciones que le entregas a cada subagente, en este caso a cada microservicio, para que tenga comportamientos o reglas específicas. Se apoyan en prompts predefinidos que encuentras en los recursos de la clase.

¿Qué es un archivo agents.md? Es un fichero de instrucciones que le das a un subagente o microservicio para definir reglas de comportamiento. Su punto de verdad sigue siendo el README, pero agrega capacidades e instrucciones extra.

Cuando copias el prompt de agents.md al front-end, básicamente le estás diciendo que su fuente de verdad siempre será el README, y encima sumas instrucciones adicionales. Por ejemplo:

• Usar el sistema de diseño ya presente en el repositorio.
• No crear componentes duplicados si ya existen equivalentes.
• No generar dependencias nuevas sin agregarlas al plan.

Estas reglas son típicas en la construcción de front-end y evitan que el agente improvise fuera de lo acordado.

Cómo aplicar reglas al microservicio de autenticación

El mismo proceso se repite para el microservicio de autenticación. Generas su propio fichero agents.md, vas a la ayuda y copias el prompt correspondiente.

Aquí la instrucción clave es de seguridad: como este servicio maneja toda la autenticación y las contraseñas, le indicas que nunca loguee esas credenciales ni tokens en texto plano. Un detalle pequeño en el prompt, pero decisivo para no exponer datos sensibles.

Este tipo de construcción de componentes, tareas e instrucciones es la base sobre la que se apoyan conceptos como el harness engineering, un tema que no se cubre en el curso pero que vale la pena buscar por tu cuenta [02:00].

Cómo correr front-end y autenticación en paralelo

Una de las características interesantes de Antigravity es lanzar dos procesos que corren de forma simultánea. Desde la interfaz del manager das clic en el proyecto y abres una nueva conversación.

Empiezas por el front-end: copias la conversación del scaffold completo, la pegas en el manager y eliges el modelo que ejecutará la tarea. Y aquí viene algo importante, no todos los modelos sirven para lo mismo.

• Los modelos de Gemini destacan en términos de diseño.
• Los modelos de Claude Sonnet o GPT funcionan para estructuras más específicas de desarrollo.

Como se trata de un front-end, la elección es Gemini 3.5 Flash con nivel medio de razonamiento, justamente para no disparar el consumo de tokens [03:20].

¿Qué modelo elijo para front-end o para autenticación? Para diseño y front-end, un modelo Gemini funciona mejor. Para estructuras de desarrollo más específicas, conviene Claude Sonnet o GPT. Ajusta el nivel de razonamiento para controlar el gasto de tokens.

Sin esperar a que el primer proceso termine, abres una segunda conversación y pegas el prompt del microservicio de autenticación, esta vez usando un modelo diferente como Sonnet. Ambas sesiones avanzan al mismo tiempo.

Qué permisos pide Antigravity durante la ejecución

Mientras los agentes trabajan, la plataforma va pidiendo confirmaciones. El front-end, por ejemplo, solicita ejecutar comandos por fuera del sandbox.

Algunos permisos típicos que aparecen:

• Ejecutar un NPX, que puedes permitir esta vez o configurar para que no vuelva a preguntar.
• Generar un fichero nuevo, algo que puede repetirse varias veces en la misma ejecución.

Tú decides si autorizas comando por comando o si dejas que ciertos comandos específicos se ejecuten sin preguntar de nuevo. Esa flexibilidad te ahorra clics repetitivos.

Por qué el plan de implementación es clave en Antigravity

Cuando el servicio de autenticación termina, genera un implementation plan. Al dar clic sobre él se abre una interfaz arriba a la derecha donde ves todo el plan y puedes modificar cualquiera de sus características, igual que en clases previas.

Esta es la interfaz de overview, una de las más importantes de Antigravity. Te muestra qué subagentes correrán, los cambios en los ficheros y muchos artefactos distintos, entre ellos el plan de implementación.

¿Qué es la interfaz de overview en Antigravity? Es el panel que reúne los artefactos de una sesión: subagentes activos, cambios en ficheros, el plan de implementación y las tareas. Sirve para entender qué va a pasar antes de modificar código.

A diferencia de otros IDEs, Antigravity plantea este artefacto todo el tiempo para que entiendas a fondo qué se va a ejecutar antes de cualquier cambio en el código. Como cada quien tendrá resultados distintos según su prompting, aquí simplemente aceptas el plan y das clic en proceder.

Cómo seguir las tareas en tiempo real

Al proceder, ya se empiezan a generar ficheros. Si vuelves al overview encuentras un nuevo artefacto llamado task o tareas.

Dentro puedes ver en tiempo real cómo la plataforma genera cada tarea y cuándo va terminando. Con el paso de la ejecución, cada componente de la task list se va chequeando solo.

También puedes escribir comentarios o modificaciones mientras todo corre, por si quieres ajustar algún elemento de esa lista sobre la marcha. En el front-end ocurre lo mismo: se genera su plan de implementación, lo revisas y procedes.

Llegado este punto, ambas sesiones seguramente te pedirán muchos permisos y quizá tengas que afinar el código que van generando. El reto es completar toda esta ejecución para, en la próxima clase, entender qué artefactos se producen mientras mantienes esa comunicación con cada sesión.

¿Te animas a lanzar tus dos procesos en paralelo? Cuéntame en los comentarios qué modelo elegiste para cada microservicio.