iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
For most conversational Microsoft Foundry hosted agents, start with Responses. It uses an OpenAI-compatible request contract and gives the conversation a managed history and streaming lifecycle. Choose Invocations when a caller needs a custom JSON contract, the work is not conversational, or your handler must control the payloads directly. A hosted agent can expose both, so this choice does not have to be permanent.
How Responses and Invocations differ
These protocols define how a client and a hosted-agent container exchange requests and responses. They do not determine which agent framework you use: Microsoft documents hosting for its Agent Framework as well as adapters that can work with LangGraph and custom code.
![The Microsoft Copilot Bible: [3 in 1] A Beginner's Guide to Harness AI in Office 365 to Automate Workflows, Generate Content, Analyze Data, and 10x Your Productivity](https://m.media-amazon.com/images/I/41+5Qv4pd2L._SL160_.jpg)
![The Microsoft Copilot Bible for Beginners & Busy Professionals: [5 in 1] How to Boost Productivity, Save Hours Every Week, and Automate Your Work with AI](https://m.media-amazon.com/images/I/41tTEg9fueL._SL160_.jpg)
| Decision point | Responses | Invocations |
|---|---|---|
| Typical work | Conversational assistants, including multi-turn questions, retrieval-augmented generation (RAG), and tool use | Webhooks, structured extraction or classification, batch work, and custom protocol bridges |
| Request contract | OpenAI-compatible Responses API shape | Arbitrary JSON defined by the handler |
| Container endpoint | POST /responses |
POST /invocations |
| Response format | JSON or server-sent events (SSE) | JSON or optional SSE, as implemented by the handler |
| Conversation history | Managed by the platform or adapter in the Responses flow | Not managed as conversation history by the platform; the application owns any state needed for continuity |
| Streaming | Uses the Responses event lifecycle | Handler can provide custom SSE and control its format |
| Client requirements | OpenAI-compatible SDKs can call the endpoint | Client must follow the agent’s custom contract |
| Can it coexist with the other protocol? | Yes | Yes |
Microsoft describes Responses as the default starting point for most conversational hosted agents. Invocations is the more direct fit when the caller’s existing schema or workload does not map naturally to that contract. Microsoft’s hosted-agent overview and runtime contract describe the distinction.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsWhen Responses is the better fit
Choose Responses when the caller can send the Responses API request shape and the agent behaves like a conversation. It is especially useful when later turns need the context of earlier ones: the Responses flow provides managed history behavior rather than requiring each client integration to invent its own continuity mechanism.
#1 Best Overall
- The client already uses an OpenAI-compatible SDK or can readily adopt that request contract.
- The interaction is multi-turn chat, including conversations that use tools or RAG.
- You want the adapter/platform contract to manage history hydration and the streaming event lifecycle.
In Microsoft Agent Framework’s hosting example, the server exposes POST /responses, and a subsequent turn can continue using previous_response_id. That guide also describes using an agent_session_id or a conversation ID when later turns need the same hosted sandbox filesystem. Those are framework-specific examples, not guaranteed convenience APIs across every adapter. See Microsoft’s Agent Framework hosting guide.
When Invocations is the better fit
Choose Invocations when a service needs to send its own JSON schema or when the job is a discrete operation rather than a continuing conversation. The handler defines the request and response behavior, so it can fit a webhook or an existing system more directly than reshaping that system around the Responses contract.
- The caller already emits a custom payload that should remain the integration contract.
- The task is structured extraction, classification, batch processing, or another non-chat operation.
- The application needs to choose how response events are shaped, including whether and how to emit SSE.
- The application is prepared to manage state itself if requests must share context across turns.
Invocations does not provide platform-managed conversation history. A session identifier can route requests to a session, but that routing alone should not be mistaken for conversation-history storage. In Microsoft Agent Framework’s example, the caller reuses the agent_session_id returned in a response header as a query parameter on a later request. This describes that guide’s session-routing pattern, not a general history guarantee.
Make the choice by following the caller’s needs
- Check the caller’s contract. If it can send an OpenAI-compatible Responses request, Responses is a straightforward option. If an existing webhook or service requires its own JSON shape, consider Invocations.
- Decide whether the task is a conversation. Multi-turn chat, tools, and managed history point toward Responses. Extraction, classification, and batch jobs point toward Invocations.
- Choose who owns state and streaming. Responses uses the adapter/platform’s history and event contract. With Invocations, the handler controls the payload and any application-managed state or custom SSE format.
- Keep room for another integration. If a later client needs the other contract, add that protocol rather than redesigning core agent logic solely to serve the new caller.
What the hosted-agent container must provide
A hosted-agent container must implement at least one protocol endpoint. Microsoft’s runtime contract specifies that the container listens on port 8088, responds to GET /readiness with 200 OK, consumes environment variables supplied by the platform, and shuts down gracefully on SIGTERM.
Microsoft’s protocol adapter packages handle much of the contract plumbing, including HTTP setup, health checks, protocol parsing and formatting, Responses history hydration, SSE infrastructure, OpenTelemetry instrumentation, environment-variable consumption, and graceful shutdown. The agent author supplies the handler logic. The documented package names are azure-ai-agentserver-responses and azure-ai-agentserver-invocations for Python, and Azure.AI.AgentServer.Responses and Azure.AI.AgentServer.Invocations for .NET. Confirm current package versions and compatibility in the runtime contract documentation before implementing, because those details can change.
Protocol choice is not framework choice
Responses and Invocations are integration contracts between Foundry and the container, not restrictions to a particular agent framework. Microsoft’s adapter guidance describes adding protocol support to hosted agents, and its hosting guidance covers the Agent Framework as well as adapters for other frameworks and custom code. A team can therefore select the protocol based on client and state-management needs without treating it as a decision to replace its agent framework. See Microsoft’s protocol adapter guide.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
