Agentes e provedores na Conversa

Ao abrir uma conversa você escolhe com qual agente ela fala. Essa escolha não é cosmética: cada provedor tem o seu próprio protocolo, e o que a tela consegue oferecer depende do que aquele protocolo entrega. A regra que organiza a tela é essa — mostrar o controle condicionado à capacidade do provedor, em vez de prometer paridade universal.

Dois grupos de provedores

O produto separa os provedores em dois grupos, e a diferença não é de marketing — é de arquitetura:

Grupo	Provedores	O que muda
Nativos	Claude, Codex, OpenCode e Grok	Falam um protocolo estruturado com o aplicativo. É o grupo onde a conversa consegue ter estado próprio: aprovações tipadas, volta no tempo, fila durável, catálogo de histórico.
Legados	Verboo, Cursor, Hermes e Pi	Ainda seguem o caminho antigo. Continuam funcionando na Conversa, mas sem todas as portas do grupo nativo.

A matriz do que cada provedor sabe fazer

A tabela abaixo responde “a tela oferece o controle?”, não “o recurso funciona na sua máquina” — a segunda pergunta depende do host.

Capacidade	Claude	Codex	OpenCode	Grok	Verboo	Cursor	Hermes	Pi
Anexar arquivo ou imagem	sim	sim	sim	sim	sim	sim	sim	sim
Voltar a conversa a um ponto anterior	sim	sim	não	sim	sim	não	não	sim
Desfazer arquivos junto com a conversa	sim	não	não	não	não	não	não	não
Catálogo de histórico na tela	sim	sim	sim	sim	não	não	não	não
Fila de envio durável	sim	sim	sim	sim	não	não	sim	não

Três leituras que essa matriz exige:

1. Anexo não é a mesma capacidade que volta no tempo. São portões separados, e ligar um nunca liga o outro.
2. Voltar a conversa não é desfazer arquivos. São dois eixos com consequências diferentes — a conversa é o agente esquecer; os arquivos são o disco mudar. Só o Claude oferece o segundo, e mesmo ele como operação declarada à parte.
3. Ausência não vira botão desabilitado. Onde a capacidade não existe, o controle não é desenhado. A tela não mostra um botão que não faz nada esperando que você descubra sozinho.

Local, SSH e VM de runtime

A mesma conversa muda de resposta conforme onde o agente roda, e isso vale mais para o Claude do que para qualquer outro:

• Local. É o caso mais completo.
• SSH. O SDK atravessa a conexão e o agente roda no servidor — mas o que existe lá é o que está instalado lá, e a conta que vale é a do servidor. A disponibilidade é perguntada na criação da conversa, não no primeiro envio, para que a tela já abra explicada.
• VM de runtime. Hoje responde que a conversa está indisponível ali.

A regra que organiza o caminho remoto: a Conversa nunca sobe o CLI num terminal. Onde o SDK não puder dirigir o agente, a tela diz que a conversa está indisponível naquele host e explica o motivo — se falta o CLI no servidor, se o host não está conectado, se a sondagem falhou ou se é uma VM de runtime sem transporte. Degradar para um terminal seria trocar um recurso ausente por um comportamento errado e mudo: sem aprovações, sem volta no tempo, sem fila — e, quando o CLI recusasse subir, o que você digitasse na conversa viraria comando de shell.

Como consequência prática: um provedor sem conversa integrada naquele host continua acessível pelo Terminal. A Conversa não inventa um caminho alternativo; ela explica a ausência e você decide onde trabalhar.

Limites que valem saber agora

• A capacidade depende do adapter estar em uso. Os portões exigem o caminho estruturado do provedor; quando a superfície não está nesse caminho, o portão é falso e o controle não aparece.
• A disponibilidade em SSH difere do local e pode variar por host, mesmo para o mesmo provedor.