Agentes IA ya manejan tu pipeline de fotos

El 3 de septiembre de 2026, OpenAI lanzó GPT-6 Astra, un modelo diseñado para manejar software por sí solo: rellenar formularios, navegar por páginas web, llevar a cabo tareas de varios pasos en un ordenador, no solo responder preguntas sobre ellas. El propio cofundador de OpenAI lo llamó un paso hacia la AGI. Merezca o no esa etiqueta, la dirección es clara.

No es la historia de una sola empresa. Claude, de Anthropic, sabe manejar un ordenador desde 2024. Operator, de OpenAI, hizo lo mismo a partir de 2025. El modo agente de ChatGPT fusionó ambas ideas en un solo producto más tarde ese mismo año. Astra es la entrada más reciente y capaz de un patrón que ya acumula varios lanzamientos: sistemas de IA que no se limitan a decirte qué hacer, sino que lo hacen ellos mismos.

Ese cambio redefine lo que "diseñado para IA" tiene que significar para cualquier software que un agente pueda tocar. Una interfaz de chat es suficiente para una persona. Un agente necesita algo completamente distinto: un endpoint que pueda llamar, un job que pueda iniciar y consultar, un resultado que pueda recuperar cuando el trabajo esté hecho. Un software que solo ofrece un campo de prompt y un botón de descarga es un callejón sin salida para un agente, por bueno que sea el modelo que hay detrás.

La parte que On-Model ya había resuelto

Cubrimos esta idea desde el lado del comprador en La infraestructura de IA para las imágenes de moda: On-Model se construyó como infraestructura que un retailer conecta a su pipeline, no como una herramienta creativa que una persona abre para crear una imagen. Esa distinción resulta importante hoy por un motivo completamente distinto. La infraestructura, por definición, está construida para que la llame algo distinto de una persona haciendo clic en una interfaz. On-Model tiene una API REST, IDs de job asíncronos, webhooks y procesamiento por lotes desde antes de que "IA agéntica" fuera un término que usara nadie. No lo construimos para agentes. Lo construimos porque un pipeline de producción tiene que funcionar sin supervisión, y resulta que esa es exactamente la forma de interfaz que también necesita un agente.

Ya sea que quien llama sea una persona en la aplicación, un script en una tarea cron nocturna, o ahora un agente autónomo que actúa sobre un objetivo expresado en lenguaje natural, la interacción de fondo es idéntica:

El agente recibe un objetivo
        │
Autenticarse (token Bearer)
        │
Crear o reutilizar un proyecto
        │
Subir cada imagen de producto  →  recibe un file_id
        │
Iniciar un job — model swap / flat-to-model / packshot / garment recolor
        │
Vigilar el progreso (stream de eventos o webhook)  →  status: completed
        │
Recuperar los resultados  →  URLs de las imágenes finales
        │
Entregar al PIM / DAM / tienda online

Para que un agente maneje la API no cambia nada en la API. Ese es el punto.

Lo que un agente llama en realidad

Un framework de agentes no lee nuestra documentación, lee una definición de herramienta (tool). Aquí está, a grandes rasgos, la forma que registrarías para el endpoint de model-swap, construida directamente a partir de los campos reales de la petición:

{
"name": "start_model_swap_job",
"description": "Swap an approved brand identity onto one or more uploaded product images and start an async job.",
"parameters": {
  "type": "object",
  "properties": {
    "identity_code": {
      "type": "string",
      "description": "The approved model identity to apply"
    },
    "project_id": { "type": "string" },
    "images": {
      "type": "array",
      "items": { "type": "string" },
      "description": "Uploaded file_id values"
    },
    "swap_options": {
      "type": "object",
      "properties": {
        "model": { "type": "string", "enum": ["auto", "onda", "nano_banana_2"] },
        "num_variations": { "type": "integer", "minimum": 1, "maximum": 4 },
        "use_anchor": { "type": "boolean" }
      }
    }
  },
  "required": ["identity_code", "project_id", "images"]
}
}

Llámalo, recibe un job_id, y luego consúltalo periódicamente o deja que un webhook te avise cuando termine. Todo lo demás — flat-to-model, create-packshot, garment recolor — sigue el mismo patrón: pedir un job, dejarlo correr, recuperar los resultados. Está documentado de la misma manera, ya sea que quien lea sea un desarrollador o que lo que genere la petición sea un modelo de lenguaje.

Una tarea de lunes por la mañana

Supongamos que una responsable de operaciones le dice a su agente: "La colección de sudaderas de otoño acaba de llegar. Aplica nuestra identidad Priya y prepara las tallas de Zalando y Shopify antes del standup." Un agente capaz no necesita a una persona que traduzca eso en clics. Puede:

1. Revisar el feed del PIM en busca de las nuevas SKU y extraer las imágenes flat-lay.
2. Subir cada una y recopilar los valores de file_id.
3. Iniciar un job model-swap con identity_code fijado en la identidad de marca aprobada, use_anchor activado para que el modelo parezca la misma persona en todo el set.
4. Vigilar el stream de eventos del job hasta que cada imagen indique completed.
5. Recuperar los resultados, y redimensionar según las especificaciones del marketplace en la misma llamada o iniciar un job posterior con la width/height correcta para cada plataforma.
6. Devolver los archivos terminados al DAM y responder "hecho" con un enlace.

Es exactamente el mismo playbook que hoy sigue a mano un coordinador de producción, solo que ejecutado por algo que no duerme entre los pasos 2 y 5. Nada en esa secuencia es especulativo. Son seis llamadas a una API que ya existe.

Por qué toda la categoría va en esta dirección

Los agentes computer-use van a seguir mejorando precisamente en el tipo de trabajo tedioso, de varios pasos y estructurado del que está hecho un pipeline de contenido: revisar el feed, procesar el lote, enrutar la salida, confirmar que llegó. Eso favorece al software construido desde el principio como infraestructura frente al que siempre esperó a una persona al otro lado de la petición. Una herramienta de campo de prompt no le da a un agente nada a lo que agarrarse. Un sistema construido en torno a jobs, IDs y comprobaciones de estado es exactamente la superficie que un agente está diseñado para manejar.

On-Model no tuvo que volverse compatible con agentes. Ya lo era, porque lo construimos como infraestructura desde el principio, no como herramienta creativa. GPT-6 Astra no crea ese hecho, simplemente lo hace relevante de una forma nueva. A medida que los agentes asumen más del trabajo operativo que los equipos de moda hoy hacen a mano, las plataformas que ya hablan API, no solo chat, son las que un agente puede realmente tomar y ejecutar.

• Integración API — endpoints, inicio rápido y ejemplos de código para conectar On-Model a un pipeline
• Documentación de la API — autenticación, forma completa de petición/respuesta para cada tipo de job
• La infraestructura de IA para las imágenes de moda — por qué construimos On-Model como un pipeline, no como un campo de prompt
• Cinco tipos de entrada, una sola plataforma — los tipos de job que un agente (o una persona) puede iniciar
• Prueba On-Model gratis — consigue un token API y lanza tu primer job en minutos