OpenAI Responses vs Claude Messages vs Gemini Interactions API

OpenAI Responses API, Claude Messages API y Gemini Interactions API pueden admitir entrada multimodal, salida estructurada y workflows con tools, pero sus contratos de ejecución no son equivalentes. Responses usa items tipados de entrada y salida y puede gestionar continuidad server-side y hosted tools. Messages devuelve content blocks ordenados y mantiene stateless la petición base, por lo que la aplicación aporta el historial necesario. Gemini Interactions es la interfaz general recomendada para proyectos nuevos con state server-side opcional, execution steps y background runs; generateContent sigue estando soportado.

Para un workflow agentic nuevo, empieza por un capability manifest: modalidades requeridas, propietario del state, clases de tools, background execution, detalle de trace, límite de retención, presupuesto de latencia y semántica de recovery. Verifícalo contra la cuenta, región, modelo y revisión de API exactos. Ningún endpoint es universalmente mejor en calidad, seguridad o coste; esas conclusiones exigen el mismo corpus de tareas y mediciones bajo tus propias restricciones.

• Responses → buen encaje para hosted tools de OpenAI, items tipados y runs multi-step gestionados.
• Messages → contrato directo basado en blocks y orquestación de conversación propiedad de la aplicación.
• Interactions → nuevo default de Gemini para workflows stateful, agentic y en background.
• Plataforma neutral al proveedor → contrato interno de eventos más adapters separados y conscientes de capabilities.

Normalizar los tres proveedores a un único campo text solo es razonable para la generación más simple. Responses puede devolver messages, function calls y otros output items tipados. Messages representa la respuesta como un array de content blocks donde texto y tool use son tipos separados. Interactions devuelve una interaction con outputs y execution steps observables. Si un adapter elimina tipo, status, identificadores u ordering, la aplicación puede perder un tool request, refusal, citation o run incompleto y declarar éxito por error.

Define un ModelEvent interno para el contrato común mínimo: text delta, payload estructurado, tool request/result, citation, refusal, usage, error y terminal state. Conserva al lado el envelope específico del proveedor para auditoría y acceso a funcionalidades. No disfraces hosted web search, code execution o un managed agent como una function call normal: el adapter debe exponer executor, authority boundary, unidad facturable y evidence disponible.

Claude Messages es stateless en su contrato base: el cliente construye cada petición con los messages necesarios. Responses puede continuar una response o conversation anterior, e Interactions admite continuidad server-side opcional desde una interaction previa. El state server-side reduce el reenvío de contexto, pero crea un lifecycle que debe alinearse con retención, borrado, residencia e investigación de incidentes. Revisa la documentación vigente de data controls y el contrato en lugar de trasladar defaults entre APIs o planes enterprise.

El business state nunca debe existir solo dentro de una conversación del proveedor. Orders, approvals, mensajes enviados, revisiones de código y pagos pertenecen al system of record. El model state conserva contexto y referencias a artifacts; tras un timeout, la orquestación consulta el estado autoritativo por operation ID antes de cualquier retry. Para replay, conserva un input packet saneado, revisión del adapter/modelo, tool receipts y el domain verdict final, sin asumir que el objeto del proveedor estará disponible para siempre.

Los tres ecosistemas soportan tools de estilo function, pero difieren en loop ownership, paralelismo, hosted capabilities, identificadores, streaming events y devolución de resultados. Empieza con un ToolContract de aplicación que defina versión de schema, clase read/write, timeout, idempotency, salida máxima, taxonomía de errores y postcondition. El provider adapter solo traduce protocolo; un policy service separado valida identity, tenant, object, action, budget y approval.

Los tests negativos importan más que el happy path: argumentos malformados, tool desconocida, prompt injection en el resultado, scope revocado, 429, timeout antes del commit, timeout después del commit, duplicate call y drift del schema del resultado. Las hosted tools también requieren políticas de source trust, egress y validación de output. La descripción de una tool ayuda al modelo a planificar, pero no concede permiso ni demuestra que un side effect haya ocurrido.

• El modelo propone → la aplicación valida y autoriza.
• El executor ejecuta → el receipt registra intento e identificador externo.
• El system of record confirma → solo entonces el workflow declara completion.
• Resultado desconocido → primero reconciliation, después retry.

SSE o un iterador del SDK no es un protocolo universal de eventos. Cada adapter debe mapear eventos del proveedor a una state machine documentada: created, in progress, waiting for tool o approval, completed, incomplete, failed y cancelled. La UI no debe interpretar el último text delta como finalización mientras un tool loop, background job o payload estructurado siga abierto. Los eventos desconocidos se registran y hacen fail-safe en workflows con consecuencias, en vez de ignorarse silenciosamente.

Para runs largos, guarda correlation ID, provider object ID, último evento procesado o cursor, input fingerprint, expiry y cancel authority. Los webhooks verifican signature y deduplican entregas; el polling necesita backoff y timeout terminal. Rollback puede detener nuevos starts, pero no borrar una acción externa ya ejecutada: los runs en vuelo deben cancelarse o reconciliarse, y las compensating actions necesitan su propia authorization policy.

Un gateway neutral al proveedor es útil para routing, observability y migración controlada, pero una interfaz demasiado estrecha oculta capacidades valiosas. Separa un portable core—texto, partes multimodales, JSON Schema, application tools, usage y terminal errors—de capabilities opcionales como hosted search, code execution, server state, background mode, citations, prompt caching y provider-managed agents. El workflow declara capabilities required y preferred; el router rechaza targets incompatibles antes de ejecutar.

La portabilidad del prompt tampoco consiste en copiar un único system string. Versiona el semantic instruction contract, el rendering por proveedor, tool schemas y eval fixtures. Si una migración cambia endpoint, modelo y tool loop a la vez, la causa raíz de una regresión se vuelve ambigua. Migra una capa cada vez: adapter parity, evaluación congelada, shadow traffic, canary read-only y, después, activación separada de capabilities específicas del proveedor.

Construye un corpus común con generación simple, extracción de schema, input multimodal, flujos one-tool y multi-tool, refusal, contexto largo, stream interrumpido y side effect incierto. Aplica primero hard gates: violaciones de data policy, acciones no autorizadas, schemas inválidos, evidence ausente y efectos duplicados. Solo entre runs aceptados compara task success, esfuerzo del reviewer, tiempo hasta resultado verificado, uso de token/cache y coste unitario total. El resultado vale para revisiones concretas de modelo/API y una fecha, no como ranking permanente de vendors.

El decision record debe incluir capabilities requeridas, disponibilidad observada, evidence URLs, eval manifest, excepciones, owner y retest trigger. La promoción usa un feature flag del adapter y un canary estrecho. Rollback restaura el bundle anterior compatible de adapter-model-prompt, bloquea nuevos runs y reconcilia operaciones incompletas. Tras cambios materiales en status de API, event schema, retención, tool behavior o model snapshot, el veredicto anterior pasa a ser evidence histórica hasta completar regression testing.

• Gate → seguridad, authority, schema y evidence antes de promedios.
• Compare → runs aceptados con fixtures y budgets idénticos.
• Promote → canary estrecho con trace completo y kill switch.
• Retest → tras cambios materiales de proveedor, policy o workflow.