Agentes y proveedores en Conversación

Al abrir una conversación eliges con qué agente habla. Esa elección no es cosmética: cada proveedor tiene su propio protocolo, y lo que la pantalla puede ofrecer depende de lo que entregue ese protocolo. La regla que organiza la pantalla es esta: mostrar el control condicionado a la capacidad del proveedor, en lugar de prometer paridad universal.

Dos grupos de proveedores

El producto separa los proveedores en dos grupos, y la diferencia no es de marketing — es de arquitectura:

Grupo	Proveedores	Qué cambia
Nativos	Claude, Codex, OpenCode y Grok	Hablan un protocolo estructurado con la aplicación. Es el grupo donde la conversación puede tener estado propio: aprobaciones tipadas, volver atrás, cola duradera, catálogo de historial.
Heredados	Verboo, Cursor, Hermes y Pi	Todavía siguen el camino antiguo. Siguen funcionando en Conversación, pero sin todos los puertos del grupo nativo.

La matriz de lo que sabe hacer cada proveedor

La tabla de abajo responde “¿la pantalla ofrece el control?”, no “¿la función funciona en tu máquina?” — la segunda pregunta depende del host.

Capacidad	Claude	Codex	OpenCode	Grok	Verboo	Cursor	Hermes	Pi
Adjuntar archivo o imagen	sí	sí	sí	sí	sí	sí	sí	sí
Volver la conversación a un punto anterior	sí	sí	no	sí	sí	no	no	sí
Revertir archivos junto con la conversación	sí	no	no	no	no	no	no	no
Catálogo de historial en la pantalla	sí	sí	sí	sí	no	no	no	no
Cola de envío duradera	sí	sí	sí	sí	no	no	sí	no

Tres lecturas que esta matriz exige:

1. Adjunto no es la misma capacidad que volver atrás. Son compuertas separadas, y habilitar una nunca habilita la otra.
2. Volver la conversación no es revertir archivos. Son dos ejes con consecuencias diferentes — la conversación es que el agente olvide; los archivos son que el disco cambie. Solo Claude ofrece el segundo, y aun así como operación declarada aparte.
3. La ausencia no se convierte en un botón deshabilitado. Donde la capacidad no existe, el control no se dibuja. La pantalla no muestra un botón que no hace nada esperando que lo descubras por tu cuenta.

Local, SSH y VM de runtime

La misma conversación responde distinto según dónde corre el agente, y esto vale más para Claude que para cualquier otro:

• Local. Es el caso más completo.
• SSH. El SDK cruza la conexión y el agente corre en el servidor — pero lo que existe allí es lo que está instalado allí, y la cuenta que vale es la del servidor. La disponibilidad se pregunta al crear la conversación, no en el primer envío, para que la pantalla abra ya explicada.
• VM de runtime. Hoy responde que la conversación no está disponible allí.

La regla que organiza el camino remoto: la Conversación nunca levanta el CLI en un terminal. Donde el SDK no pueda dirigir el agente, la pantalla dice que la conversación está no disponible en ese host y explica el motivo — si falta el CLI en el servidor, si el host no está conectado, si la sonda falló o si es una VM de runtime sin transporte. Degradar a un terminal sería cambiar una función ausente por un comportamiento equivocado y mudo: sin aprobaciones, sin volver atrás, sin cola — y, cuando el CLI se negara a arrancar, lo que escribieras en la conversación se volvería un comando de shell.

Como consecuencia práctica: un proveedor sin conversación integrada en ese host sigue siendo alcanzable por el Terminal. La Conversación no inventa un camino alternativo; explica la ausencia y tú decides dónde trabajar.

Límites que conviene saber ahora

• La capacidad depende de que el adaptador esté en uso. Las compuertas exigen el camino estructurado del proveedor; cuando la superficie no está en ese camino, la compuerta es falsa y el control no aparece.
• La disponibilidad en SSH difiere de la local y puede variar por host, incluso para el mismo proveedor.