The Protocols Explained — Hosted Agents: Concepts

An agent is not useful just because it can reason. It becomes useful when other software can reach it reliably, send it the right kind of input, and understand what comes back. That shared convention is the protocol. The practical lesson is simple: most teams should begin with the managed conversational protocol, then add custom, real-time, channel, or agent-to-agent options only when a real use case demands them.

What a protocol really decides

A protocol is an agreed format for a conversation between two programs. It says what the request looks like, what the response looks like, whether replies can stream back gradually, and who is responsible for remembering what has already happened.

Think of the difference between a formal letter and a phone call. Both can carry the same message, but they set different expectations. A letter has a fixed shape and a delayed reply. A phone call is live and interactive. Agent protocols work the same way: they are not about how smart the agent is, but about how another system talks to it.

Hosted agents often support more than one protocol at the same time. That matters because you are not choosing one door forever. You are choosing the right first door, then opening more doors only when the work requires them.

A protocol sets the request shape, the response shape, whether replies stream, and who keeps state.

Responses: the managed conversation

Responses is the default choice for a conversational agent. It is built for chatbots, assistants, question-answering systems, and agents that use tools while carrying on a conversation.

Its main value is that the platform handles much of the conversation machinery. It can keep the message history, stream the answer as it is generated, and manage background work so a caller can start a long task and check on it later. You write the agent behavior; the platform provides the plumbing around the conversation.

Because Responses follows a widely used chat pattern, ordinary chat client libraries can usually call it without special wiring. That makes it the lowest-friction starting point for most teams.

✅

Start here. If the interaction looks like a conversation, Responses is usually the simplest and most capable first protocol.

Responses gives a managed conversation; Invocations gives full control of the request and response.

Invocations: full control of input and output

Invocations is for work that does not fit the normal chat shape. The caller may be a webhook from another system, a batch process, a classifier, an extraction job, or a custom application with a strict data contract.

With Invocations, you define the request and the response. The input can be any structured or unstructured data you choose, and the output can have any shape your caller needs. That flexibility is the point.

The trade-off is responsibility. When you leave the managed conversational shape, you also take on more of the contract yourself. You decide how sessions are tracked, how input is validated, what errors look like, and how streaming should be formatted if you stream at all.

Real-time streaming: when turns are not enough

Some interactions cannot wait for one complete request followed by one complete response. Voice is the common example. Microphone audio is arriving continuously while the agent is also sending speech back, and the delay must be low enough to feel natural.

For that case, a real-time streaming protocol keeps a single persistent two-way connection open. A WebSocket is a common way to do this: it lets both sides send data over the same live connection instead of opening a new request for every turn.

Use this style when the product genuinely needs continuous, low-latency, bidirectional exchange. For ordinary chat, task execution, and structured data processing, request-and-response protocols are simpler to build, test, and operate.

⚠️

Use it deliberately. Real-time streaming is valuable for voice and live interaction, but it adds operational complexity when a simpler request-and-response protocol would do.

Bridges: channels and other agents

Some protocols are better understood as bridges. A channel bridge publishes a conversational agent into a workplace tool, such as a team chat application. The bridge translates between the channel’s format and the agent’s Responses-style conversation so you do not have to build that adapter yourself.

An agent-to-agent (A2A) bridge lets one agent hand work to another agent or delegate part of a task. This is useful when teams split responsibilities across specialized agents, such as one agent for triage and another for deep technical support.

These bridges are not usually the first protocol you design around. They are added when distribution or coordination becomes part of the problem.

The decision leaders and practitioners actually face

Protocol choice is not only an engineering preference. It affects delivery speed, integration cost, security review, support burden, and how easily the agent can be reused later.

For a product leader, the question is: which protocol gets the first useful version into users’ hands without closing off the next use case? For an architect or engineer, the question is: where does the contract live, and who owns the failure modes?

The sound default is to start with Responses when the user experience is conversational. Add Invocations when a caller needs a custom contract. Add real-time streaming when the experience is live and bidirectional. Add bridges when the agent must appear inside a channel or coordinate with other agents.

Choose Responses for chat, assistants, question answering, tool-using agents, and background conversational tasks.
Choose Invocations for webhooks, structured payloads, batch jobs, classifiers, extractors, and custom application contracts.
Choose real-time streaming for microphone-in and speech-out voice or another live bidirectional experience.
Choose channel bridges when the agent must be published into a workplace tool.
Choose agent-to-agent bridges when one agent must delegate to or hand off to another.

Start with Responses when the experience is conversational, or Invocations when the caller needs a custom contract.

Every protocol is also a security surface

Every endpoint you expose is a place where untrusted input reaches your agent. That is true whether the input is a friendly chat message, a webhook payload, audio, a workplace channel event, or another agent’s request.

With Responses, the platform manages much of the conversation handling, which means you write less request-handling code and have fewer chances to make basic plumbing mistakes. That does not remove the need to treat user content, tool results, and retrieved text as untrusted.

With Invocations, you define the contract yourself, so validation belongs squarely in your design. Malformed payloads, unexpected fields, oversized inputs, and malicious content need clear handling. The same principle applies to bridges: translation does not make input trustworthy.

⚠️

Name the owner. For every protocol endpoint, write down who validates the incoming data and what the agent must reject.

A simple test to run this week

Take one agent you are building or considering, and map each caller to the shape of data it sends. Do not begin with the list of available protocols. Begin with the real interaction: who calls the agent, what do they send, what do they expect back, and how quickly?

If the answer is a conversation, start with Responses. If the caller sends its own structured format, use Invocations. If the exchange is continuous and live, use real-time streaming. If the agent must appear inside a workplace channel or coordinate with another agent, add the appropriate bridge.

Then add one operational question beside each endpoint: who treats this input as untrusted? If that question is blank, the design is not finished.

Is the interaction basically conversational?
Does the caller send data that is not a chat message?
Does the experience require continuous two-way streaming?
Does the agent need to appear inside another channel?
Does another agent need to call or delegate to it?
Who validates the input at each exposed endpoint?

Key takeaways

A protocol is the agreed shape of the request, the response, and the conversation around them.
Responses is the managed conversational default and is the right starting point for most agents.
Invocations gives you full control for non-chat input, custom contracts, and structured processing.
Real-time streaming is for continuous low-latency exchange, especially voice.
Channel and agent-to-agent bridges are added when the agent must appear in workplace tools or coordinate with other agents.
Every exposed protocol endpoint receives untrusted input, so validation ownership must be explicit.

Glossary

Protocol: An agreed format that defines how two programs send requests, return responses, and handle the conversation between them.
Responses: A managed conversational protocol where the platform handles history, streaming, and background work for chat-style agents.
Invocations: A flexible protocol where you define arbitrary input and output shapes and take responsibility for the custom contract.
Real-time streaming: A communication style that keeps a live two-way connection open so both sides can send data continuously with low delay.
WebSocket: A persistent network connection that allows two programs to send data to each other over the same open channel.
Channel bridge: A translator that lets a conversational agent appear inside another tool, such as a workplace chat application.
Agent-to-agent (A2A): A protocol or bridge that lets one agent hand off work to another agent or delegate part of a task.
Webhook: An automatic message sent by one system to another when an event happens, usually in the sending system’s own format.
Endpoint: A reachable address or interface where another program can send requests to an agent or service.