From Chat Completions to Responses API: why Azure OpenAI’s new paradigm changes everything.

Key points

• Responses API stores conversation state server-side with unique IDs, eliminating the need to resend full history on each turn, reducing token costs and improving reliability.
• Responses API is agentic by default, enabling models to call multiple tools and external services within a single request, unlike Chat Completions which requires manual orchestration.
• Business Central’s System.AI namespace currently wraps Chat Completions and provides guardrails, telemetry, and managed resources that make it worth using today, but the underlying design is extensible for future Responses API support.
• Responses API supports background execution mode for long-running tasks, context compaction for extremely long interactions, and richer streaming events, capabilities unavailable in Chat Completions.
• Chat Completions requires developers to manage conversation state client-side, causing quadratic cost growth as conversation length increases, while Responses API keeps state on the server.

AL objects mentioned

As named in the post. A name that matches one object page by exact type and name links to it; the others stay as named.

• codeunit “AzureOpenAI”
• codeunit 7763 “AOAI Chat Messages”
• codeunit 7761 “AOAI Chat Completion Params”
• codeunit 7770 “AOAI Operation Response”
• enum 7773 “AOAI Model Type”

Not found in BC28-30: codeunit “AzureOpenAI”.

Context

• Features: Responses API, Chat Completions API, stateful conversations, agentic tool calling, context compaction, background execution mode, server-side state management, response lifecycle management

Source: Stefano Demiliani, community blog. Summary, key points and quotes are derived (CONTENT-NOTICE.md); read the original for the full text.