---
id: "conversa.agentes-e-provedores"
titulo: "Agents and providers in Conversation"
resumo: "Choose the conversation's agent knowing what each provider actually offers — attachments, permissions, rolling back, history and queue — instead of assuming they all do everything."
idioma: "en"
tipo: "conceito"
categoria: "telas"
aplicavelDesde: "0.0.16"
capabilities: ["chat.adapters.capabilities"]
estadoEditorial: "aprovado"
nivelEvidencia: "artefato-distribuido"
refFonte: "27574c339b58316408f6be2d62169d59041d07bf"
revisaoFonte: "2026-09-24"
revisor: "mantenedor (v1, 2026-10-03)"
rota: "/docs/en/conversa/agentes-e-provedores/"
fonte: "pt-br/conversa/agentes-e-provedores.md"
caminhoPublico: "docs/publica/en/conversa/agentes-e-provedores.md"
hashFonte: "sha256:d12ed7fcab9db6fda6957f3690ac47201136a3ba7e18a3dda2c0194a46bb26b6"
hashDestaPagina: "sha256:5c6ad4e6d0b876469dbeac782efdcf788b9e7c029601b00a8eecd8f5d8e68911"
traducaoAssistidaPorIA: true
traducaoDesatualizada: false
corpoRetido: false
---
<!-- traducao-assistida-por-ia: idioma=EN fonte=pt-br/conversa/agentes-e-provedores.md fonteHash=sha256:d12ed7fcab9db6fda6957f3690ac47201136a3ba7e18a3dda2c0194a46bb26b6 estado=atual -->

When you open a conversation you choose **which agent** it talks to. That choice is not cosmetic: each provider has its own protocol, and what the screen can offer depends on what that protocol delivers. The rule that organises the screen is this one — **show the control gated by the provider's capability, instead of promising universal parity**.

## Two groups of providers

The product splits providers into two groups, and the difference is not marketing — it is architecture:

|Group|Providers|What changes|
|---|---|---|
|**Native**|Claude, Codex, OpenCode and Grok|They speak a structured protocol with the application. This is the group where the conversation can have state of its own: typed approvals, rolling back, durable queue, history catalogue.|
|**Legacy**|Verboo, Cursor, Hermes and Pi|They still follow the older path. They keep working in Conversation, but without every port the native group has.|

## The matrix of what each provider can do

The table below answers "does the screen offer the control?", not "does the feature work on your machine" — the second question depends on the host.

|Capability|Claude|Codex|OpenCode|Grok|Verboo|Cursor|Hermes|Pi|
|---|---|---|---|---|---|---|---|---|
|Attaching a file or image|yes|yes|yes|yes|yes|yes|yes|yes|
|Rolling the conversation back to an earlier point|yes|yes|no|yes|yes|no|no|yes|
|Rolling **files** back along with the conversation|**yes**|no|no|no|no|no|no|no|
|History catalogue in the screen|yes|yes|yes|yes|no|no|no|no|
|Durable send queue|yes|yes|yes|yes|no|no|yes|no|

Three readings this matrix demands:

1. **Attachment is not the same capability as rolling back.** They are separate gates, and enabling one never enables the other.
2. **Rolling the conversation back is not undoing files.** They are two axes with different consequences — the conversation is the agent forgetting; the files are the disk changing. Only Claude offers the second, and even there as a separately declared operation.
3. **Absence does not become a disabled button.** Where the capability does not exist, the control is not drawn. The screen does not show a button that does nothing while you wait to find out on your own.

## Local, SSH and runtime VM

The same conversation answers differently depending on **where the agent runs**, and this matters more for Claude than for anyone else:

- **Local.** This is the most complete case.
- **SSH.** The SDK crosses the connection and the agent runs on the server — but what exists there is what is installed there, and the account that counts is the server's. Availability is asked **when the conversation is created**, not on the first send, so that the screen opens already explained.
- **Runtime VM.** Today it answers that the conversation is unavailable there.

**The rule that organises the remote path: Conversation never starts the CLI in a terminal.** Where the SDK cannot drive the agent, the screen says the conversation is **unavailable** on that host and explains why — whether the CLI is missing on the server, the host is not connected, the probe failed, or it is a runtime VM with no transport. Degrading to a terminal would trade a missing feature for wrong and silent behaviour: no approvals, no rolling back, no queue — and, when the CLI refused to start, whatever you typed into the conversation would become a shell command.

As a practical consequence: **a provider with no integrated conversation on that host remains reachable through the Terminal.** Conversation does not invent an alternative path; it explains the absence and you decide where to work.

## Limits worth knowing now

- **The capability depends on the adapter being in use.** The gates require the provider's structured path; when the surface is not on that path, the gate is false and the control does not appear.
- **Availability over SSH differs from local** and can vary by host, even for the same provider.