How we built ChatGPT’s novel ad stack for user trust and relevance
OpenAI explains how it built ads for ChatGPT around conversation context instead of discrete search events, with privacy and relevance controls.
Extract
Traditional advertising systems are built to respond to discrete units of user intent. A user searches for or views something online, the ads system receives those queries and page views as events, and the system looks for matching ads based on those events. Building an ads stack for ChatGPT was different: user intent develops across conversations and shifts over multiple turns of a conversation, sometimes without a fitting advertising moment. To support this new paradigm, we built a bespoke ads delivery system. This new type of ad stack is based on a custom, post-trained frontier LLM that makes tool calls for retrieval (identifying the top options), ranking (predicting user engagement), relevance (evaluating the usefulness of the ad), and running auctions for final ad selection and pricing.Our ads system supports the nuance of evolving user goals by making three key design decisions: 1) implementing stateful ads sessions, meaning information is remembered across turns of a conversation and across multiple conversations, 2) relying on a custom, post-trained LLM that uses a tool call architecture to interpret a conversation’s context and underlying intent, and then effectively select, rank, and deliver ads, and 3) running the ads selection process separately from ChatGPT’s answer generation, in its own service, to keep ads from influencing answers and maintain ChatGPT’s neutral voice. We use our post-trained LLM to orchestrate the entire ads flow, determining the right ad to surface at the right time based on both the user’s current turn and conversation history. While bootstrapping a self-improving ads system like this used to take years, ChatGPT Ads reached $1 billion in annualized revenue run rate less than 200 days after launch; now, more than 100,000 advertisers have run ads on ChatGPT since launch.How should ads work in agentic chat?A conventional advertising request usually starts with a well-defined event. A user submits a search query or opens a webpage and the ads system receives a request. This type of system is fairly simple: it retrieves potential ad candidates, ranks them, runs an auction to appropriately price the opportunity, and shows the resulting ad to the user. ChatGPT does not naturally produce such a concrete moment.In a ChatGPT conversation, people arrive with goals rather than a one-answer search query. They might be planning a trip, choosing software for their business, furnishing a home, or learning a new hobby. This doesn’t all …
Explained
What happened
OpenAI described the ad system behind ChatGPT, which reached a $1 billion annualized run rate in under 200 days with over 100,000 advertisers.
- Classic ad systems react to a single event, like a search query or page view. In chat, intent builds over many turns and sessions, and often there is no good moment for an ad at all.
- So the system keeps a stateful ads session that remembers and updates context across turns and, if the user opts in, across conversations.
- A post-trained LLM orchestrator runs the ad flow as an agent. It calls tools for retrieval, eligibility filtering, ranking, relevance checks and the auction.
- The orchestrator summarizes the conversation into one or more short queries, embeds them, and retrieves candidates by semantic similarity. Multiple queries keep separate needs apart, such as flights versus hotels on a trip.
- Ad selection runs in a separate service with separate models and code, in parallel with answer generation. ChatGPT does not depend on it: if ads are slow or down, the answer still ships. Returning no ad is a normal, successful result.
- As the conversation grows, the orchestrator can rerun tools and send better ads, which the client uses if they arrive in time.
Why it works
The hard part is not ranking, it is understanding intent: telling current intent from stale context, hypotheticals from real plans, and mentions from purchase interest. An LLM with tool calls can do that reading, while the proven ad pieces (retrieval, auctions, budgets) stay as deterministic tools. Running the pipeline beside the answer path, not inside it, keeps ads from changing answers and keeps ad failures from hurting the product.
The bigger pattern
Two known patterns combine here. One is the retrieval, ranking, auction funnel that every ad and recommendation system uses. The other is isolating a non-critical dependency so it can fail without hurting the core path, similar to a sidecar with a timeout and a fallback of doing nothing. What is new is an LLM acting as the planner that decides when and how to call each stage, plus sessions that span many turns instead of one request.
What it means in practice
- When adding a revenue or enrichment feature to a core path, run it in parallel with a deadline and make "nothing" a valid answer. The core response should never wait on it.
- For conversational or multi-step products, model user state as a session that evolves, not a stream of independent requests. A store like Redis with a TTL per session fits this well.
- Use the LLM where judgment is needed (query rewriting, intent) and keep budgets, eligibility and pricing in deterministic code you can audit.
- Several focused retrieval queries often beat one compressed query for mixed intent.