Agents and providers in Conversation

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.