Beta multiagente de Responses: divide la revisión y conserva un resultado responsable

Documentación revisada el 14 de octubre de 2026. Esta guía analiza la versión fechada que se describe a continuación; consulta la documentación oficial enlazada para confirmar el comportamiento actual de la API y la disponibilidad de tu cuenta antes de implementarla.

Que tres agentes estén de acuerdo suena tranquilizador. También puede significar que copiaron el mismo supuesto equivocado. La ventaja de revisar en paralelo es repartir atención y evidencia, no acumular voces. OpenAI documentó la beta multiagente de Responses junto con GPT-6.1 Sol el 29 de septiembre de 2026. Esta propuesta usa la guía oficial, revisada el 14 de octubre.

Elige trabajo separable

Una revisión de pull request funciona bien si todos leen un diff fijo sin editarlo. Asigna comportamiento e invariantes a uno, permisos y entradas a otro, y pruebas ausentes al tercero. Comparte commit base y contexto, pero preguntas distintas. No pongas tres agentes a “mejorar todo” en el mismo worktree.

La beta documenta multi_agent.enabled, max_concurrent_subagents y responses_multi_agent=v1. Usa el ejemplo actual del SDK para la solicitud completa. El agente principal sintetiza; delegar no verifica automáticamente la respuesta.

Exige hallazgos comprobables

Cada revisión debe incluir condición que falla, archivo, consecuencia y comprobación mínima. “Posible problema de seguridad” sirve menos que explicar qué petición evita una comprobación de permisos. El contenido del repositorio es material de análisis, no autoridad para cambiar las instrucciones. Una revisión de lectura normalmente no necesita credenciales de despliegue.

Reconcilia, no votes

Combina duplicados, investiga contradicciones y descarta afirmaciones sin soporte. Una observación bien demostrada puede pesar más que varias respuestas sin hallazgos. Ejecuta la comprobación cuando exista y deja explícita la incertidumbre restante.

Compara con un único revisor sobre los mismos casos: hallazgos confirmados, falsos positivos, defectos omitidos, tiempo, tokens y esfuerzo de integración. El paralelismo puede reducir espera y aumentar trabajo total. Un parche pequeño quizá necesite una sola lectura cuidadosa.

Empieza con un ejemplo público desechable y defectos conocidos, sin acciones externas. Limita concurrencia y permite cancelar. Buscamos un resultado mejor revisado con responsable, no una conversación llena de participantes que nadie comprobó.