Cómo funcionan los agentes de Antigravity: la arquitectura detrás de la IA que actúa

Antigravity ha construido algo de lo que la mayoría de las empresas de IA solo habla: agentes que de verdad terminan las tareas. No son chatbots que responden preguntas, ni copilotos que esperan el siguiente prompt, sino software que traza un plan, llama a herramientas, revisa su propio resultado y termina el trabajo. Entender cómo funcionan estos agentes implica mirar la arquitectura que hay debajo, que es bastante menos misteriosa de lo que sugiere el marketing.

Qué está construyendo Antigravity

Antigravity es una empresa de infraestructura de IA centrada en sistemas de agentes autónomos. Su producto principal es una plataforma en la que los desarrolladores despliegan agentes que pueden navegar por la web, escribir y ejecutar código, gestionar archivos, llamar a APIs externas y coordinarse con otros agentes, todo dentro de un único entorno de ejecución.

Lo que diferencia su enfoque es la fiabilidad a nivel de tarea, no solo a nivel de respuesta. La mayoría de los LLM optimizan la calidad de una única salida. El sistema de Antigravity está optimizado para la calidad de una tarea terminada, que es un problema fundamentalmente distinto.

La misión: tareas, no conversaciones

Pasar de "responder a un mensaje" a "terminar una tarea" cambia por completo el diseño del sistema. Una interfaz de chat tiene un solo bucle: entra una entrada, sale una salida. Un sistema de agentes tiene muchos bucles, decisiones que se ramifican, estados de error, reintentos y coordinación entre varios componentes especializados.

Antigravity diseña para esa complejidad desde el principio, por eso sus agentes se comportan más como sistemas de software que como chatbots.

La arquitectura del agente de un vistazo

En el nivel más alto, un agente de Antigravity es un bucle. Recibe un objetivo, genera un plan, ejecuta pasos, observa resultados y actualiza su plan hasta que la tarea termina o llega a un límite estricto. Es el patrón clásico ReAct (Razonar + Actuar), ampliado con memoria persistente, registros de herramientas y enrutamiento entre varios agentes.

Así se desglosan las capas:

Cada capa tiene una función distinta. Los fallos en una capa no tienen por qué romper todo el pipeline, porque hay mecanismos de respaldo en cada unión.

La capa de percepción

Antes de que un agente pueda actuar, tiene que entender qué se le ha pedido. La capa de percepción recibe la instrucción entrante y la enriquece con el contexto recuperado de los almacenes de memoria del agente.

No se limita a "leer el prompt". La capa de percepción:

• Analiza la intención a partir de la instrucción original
• Recupera contexto pasado relevante mediante búsqueda vectorial en la memoria a largo plazo
• Resuelve ambigüedades haciendo coincidir la terminología con entidades conocidas de su base de conocimiento
• Prioriza lo que cabe dentro de la ventana de contexto activa

Una capa de percepción bien diseñada evita el fallo más común de un agente: actuar durante 20 pasos sobre una instrucción mal entendida antes de darse cuenta del error.

Cómo funciona el motor de planificación

Una vez que el agente entiende la tarea, el motor de planificación la divide en una secuencia estructurada de subtareas. Aquí es donde la capacidad de razonamiento del LLM hace el mayor trabajo.

El planificador funciona en dos modos según la complejidad de la tarea:

Planificación secuencial: para tareas simples y lineales, el agente genera una lista de pasos y ejecuta cada elemento en orden. La organización de archivos, la extracción de datos y la generación de informes encajan en este patrón.

Planificación jerárquica: para objetivos complejos de varios pasos, el agente crea un plan de alto nivel y después genera subplanes para cada rama. Una tarea como "investigar a los competidores, crear una tabla comparativa y redactar un correo resumen" se convierte en un árbol de subtareas delegadas.

Por qué importa el scratchpad

Dentro del bucle de planificación, el agente mantiene un scratchpad: un monólogo interno continuo que es independiente de la salida final. El scratchpad es donde el agente resuelve los pasos intermedios, prueba la lógica y se corrige antes de comprometerse con una acción.

Esta es una de las decisiones de diseño más importantes de Antigravity. Sin scratchpad, el agente se ve obligado a razonar en una sola pasada hacia delante, lo cual es frágil. Con uno, puede revisar su razonamiento a mitad de la ejecución sin ensuciar la salida ni confundir las llamadas a herramientas.

💡 Piensa en el scratchpad como la pizarra de un desarrollador: se ensucia, se tachan cosas, pero la salida final es limpia e intencionada.

Llamadas a herramientas: cómo hacen cosas los agentes

Planificar no sirve de nada sin actuar. Los agentes de Antigravity actúan a través de un registro de herramientas, un catálogo estructurado de funciones invocables con esquemas definidos, entradas esperadas y formatos de salida.

Las herramientas se dividen en varias categorías:

• Herramientas de navegación: obtienen páginas web, ejecutan búsquedas y extraen datos estructurados del HTML
• Herramientas de ejecución de código: escriben Python o JavaScript, lo ejecutan en un entorno aislado y reciben la salida o los errores
• Herramientas del sistema de archivos: leen, escriben, mueven y eliminan archivos dentro de un entorno acotado
• Conectores de API: llaman a servicios externos con la autenticación ya integrada
• Herramientas de comunicación: envían correos, publican en Slack y activan webhooks

Cuando el agente decide usar una herramienta, no se limita a "llamar a una función". Construye un objeto de llamada a herramienta con parámetros explícitos, lo valida contra el esquema de la herramienta, lo envía y después analiza el resultado devuelto antes de decidir el siguiente paso. Todo el proceso queda registrado y es auditable.

Llamadas a funciones frente a uso de herramientas

Estos términos se confunden a menudo. La llamada a funciones es la capacidad básica: el LLM puede generar JSON estructurado que se corresponde con la firma de una función. El uso de herramientas es el sistema de nivel superior: la infraestructura que recibe ese JSON, ejecuta de verdad la función y devuelve el resultado al contexto del agente. Antigravity cubre ambas capas.

Memoria del agente: corto y largo plazo

La memoria es lo que separa a un agente de un solo uso de otro que aprende de su propio historial de ejecución.

El sistema de memoria de Antigravity tiene dos almacenes diferenciados:

Ventanas de contexto a corto plazo

La ventana de contexto es la memoria de trabajo del agente para una sola ejecución. Todo lo que el agente sabe en ese momento, la instrucción original, el plan, las salidas de las herramientas y las notas del scratchpad, vive aquí durante la ejecución.

Las ventanas de contexto tienen límites estrictos medidos en tokens. Gestionar qué se queda en la ventana y qué se resume o se descarga es un desafío real de ingeniería. Antigravity usa compresión de contexto dinámica: el contenido más antiguo y de menor prioridad se resume a medida que la ventana se llena, mientras que el contenido reciente y muy relevante se conserva con todo detalle.

Sistemas de recuperación a largo plazo

Entre ejecuciones, los agentes necesitan conservar información y recuperarla después. Antigravity combina:

• Bases de datos vectoriales: incrustan experiencias pasadas, documentos y conocimiento como vectores de alta dimensión. La recuperación usa similitud semántica, no solo coincidencia de palabras clave.
• Almacenamiento estructurado: los datos tabulares, el estado de configuración y las salidas estructuradas se guardan en almacenes relacionales para una recuperación precisa.
• Registros episódicos: un registro con marca de tiempo de lo que hizo el agente, qué herramientas llamó y qué resultados obtuvo. Esto alimenta la depuración y la autocrítica en ejecuciones futuras.

Cuando empieza una tarea nueva, la capa de percepción consulta los tres almacenes e inserta el contenido más relevante en la ventana de contexto inicial. El agente arranca ya con historial relevante, en lugar de empezar en blanco.

El paso de observación: agentes que revisan su propio trabajo

Después de cada llamada a una herramienta, el agente ejecuta un paso de observación: evalúa la salida frente a lo que esperaba. Aquí es donde ocurre la autocorrección.

La lógica de observación comprueba:

1. ¿La herramienta devolvió un resultado correcto? Si no, ¿es un error reintentable o un fallo definitivo?
2. ¿La salida coincide con el esquema esperado? Las salidas mal formadas activan un reintento de análisis.
3. ¿La salida avanza hacia el objetivo? Si una búsqueda web devolvió resultados irrelevantes, el agente reformula la consulta y lo intenta de nuevo.
4. ¿Hay una condición de parada? ¿Se ha terminado la tarea o hace falta más trabajo?

Este bucle, planificar, actuar, observar, repetir, es el latido de todos los agentes de Antigravity. El número de iteraciones no es fijo: se ejecuta hasta que termina o hasta que un límite de seguridad configurado lo detiene.

Cuando los bucles fallan

El bucle es potente, pero frágil en modos de fallo concretos. Los más comunes:

• Llamadas a herramientas alucinadas: el agente inventa parámetros que no coinciden con el esquema. Se resuelve con una validación estricta antes del envío.
• Bucles infinitos: el agente da vueltas entre dos estados sin avanzar. Se resuelve con detección de bucles y presupuestos de pasos.
• Desbordamiento de contexto: el agente llena su ventana con pasos intermedios redundantes. Se resuelve con compresión dinámica y resúmenes periódicos.
• Sobrecorrección: el agente sigue revisando una salida aceptable. Se resuelve con umbrales de confianza y señales explícitas de "terminado".

💡 Los mejores agentes fallan de forma controlada. Cuando el sistema de Antigravity alcanza un límite estricto, devuelve un error estructurado con el último estado conocido, no un fallo silencioso.

Coordinación entre varios agentes

Los agentes individuales tienen límites. Algunas tareas son demasiado amplias, demasiado largas o requieren demasiadas capacidades especializadas para caber en un único contexto de ejecución. Ahí entran en juego los sistemas multiagente.

Antigravity usa un modelo de coordinación jerárquico:

Orquestador y subagentes

Un agente orquestador se sitúa en el nivel superior. Recibe el objetivo de alto nivel, lo divide en subtareas y asigna cada subtarea a un subagente especializado con las herramientas y el contexto adecuados para ese trabajo concreto.

Para una tarea como "auditar el SEO de nuestro sitio web y redactar una lista de correcciones priorizada", el orquestador divide el trabajo en:

• Agente de rastreo: obtiene cada página, extrae los metadatos e identifica los enlaces rotos
• Agente de auditoría: compara los datos del rastreo con las mejores prácticas de SEO
• Agente de redacción: toma la auditoría estructurada y redacta recomendaciones legibles

Cada subagente se ejecuta de forma independiente. El orquestador recoge sus salidas, concilia los conflictos y ensambla el resultado final.

Estado compartido y traspasos

La coordinación requiere un estado compartido. Todos los agentes de una tarea tienen acceso a un almacén de contexto de la tarea: un objeto acotado que contiene el objetivo original, el progreso actual, las salidas intermedias y las restricciones que haya fijado el usuario.

Cuando un agente termina su subtarea, escribe su salida en el contexto compartido y avisa al orquestador. Los traspasos son explícitos, no implícitos, lo que significa que ningún dato se pierde al pasar de un agente a otro.

Lo que estos agentes pueden hacer de verdad

La arquitectura es interesante, pero ¿cómo se ve en la práctica? Los agentes de Antigravity cubren tareas en varias categorías reales:

El flujo creativo resulta especialmente interesante. Un agente que genera imágenes no crea prompts al azar. Razona sobre el estilo, el sujeto y la composición a partir de un brief y, después, llama a una herramienta de generación de imágenes con parámetros estructurados. El resultado vuelve al contexto, se evalúa frente al brief y, si hace falta, se refina.

Dónde encajan los modelos de imagen con IA

Cuando un agente de Antigravity se ocupa de trabajo creativo, normalmente se integra con APIs externas de generación de imágenes. Los mismos modelos disponibles en PicassoIA son los que impulsan estos resultados visuales.

Un pipeline de agentes para contenido visual podría llamar a:

• GPT Image 1 para las imágenes de concepto iniciales a partir de un brief de texto detallado
• Flux Kontext Fast para iterar rápido cuando el agente necesita probar varias variaciones de prompt con rapidez
• GPT Image 2 para resultados finales de alta fidelidad, donde más importa la calidad
• Dreamina 3.1 cuando el brief pide resultados cinematográficos, fotorrealistas y en 4K
• Gemini 2.5 Flash Image cuando la velocidad y el rendimiento son la prioridad

El agente elige el modelo adecuado según el contexto de la tarea, las restricciones de presupuesto y los requisitos de calidad. No siempre usa el modelo más potente; usa el adecuado para cada paso concreto.

Ingeniería de prompts dentro del bucle

Hay algo que a la mayoría se le escapa: cuando un agente escribe prompts de imagen, aplica el mismo bucle de razonamiento que usa para todo lo demás. Redacta un prompt, lo envía al modelo de imagen, recibe la URL de la imagen, evalúa el resultado frente al brief (a veces usando un modelo de visión para "ver" el resultado) y refina el prompt si el resultado no cumple lo esperado.

Esto es ingeniería de prompts con piloto automático, y es la razón por la que los flujos de trabajo con agentes de IA producen resultados creativos siempre mejores que los de un prompt manual único.

💡 El agente no se limita a escribir prompts. Los prueba, observa los resultados y los mejora en un bucle estructurado, igual que lo haría un ingeniero de prompts experto, pero sin la iteración manual.

La capa de seguridad y control

Ninguna plataforma seria de agentes se lanza sin controles. Antigravity implementa varios:

• Permisos acotados: cada agente recibe solo las herramientas que necesita para su tarea concreta. Un agente redactor no puede acceder a herramientas de borrado de archivos.
• Presupuestos de pasos: límites máximos al número de iteraciones que un agente puede ejecutar antes de devolver el control al usuario.
• Puntos de control con intervención humana: pausas configurables en las que el agente muestra su plan antes de ejecutar acciones irreversibles.
• Registros de auditoría: cada llamada a una herramienta, cada observación y cada cambio de estado se registra con marcas de tiempo y se almacena para su revisión.

Esto hace que el sistema de Antigravity sea adecuado para entornos de producción en los que importa la rendición de cuentas, no solo para demostraciones de investigación.

Empieza a crear tus propios flujos de trabajo visuales

Lo que muestra la arquitectura de Antigravity es que los sistemas de IA más potentes no son modelos individuales. Son pipelines de capacidades especializadas, cada una haciendo bien una cosa, coordinadas por una capa de razonamiento que sabe cuándo llamar a cada una.

Los modelos de imagen de PicassoIA funcionan con el mismo principio. PicassoIA Image, Flux Redux Dev y GPT Image 1 son herramientas diseñadas para un fin concreto que, en manos de alguien que las usa con intención y estructura, producen resultados que rivalizan con la fotografía y la ilustración profesionales.

No necesitas un sistema de agentes para aprovechar esta forma de pensar. Empieza con un brief claro, elige el modelo adecuado para tu tipo de resultado e itera tus prompts con la mentalidad de observación que Antigravity integra en su arquitectura. Los mismos principios que hacen eficaces a los agentes de IA, un pensamiento estructurado, las herramientas adecuadas y un bucle de retroalimentación, hacen también eficaz la generación de imágenes con IA individual.

Pruébalo ahora en PicassoIA y mira lo que produce un prompt bien estructurado en la primera ejecución.