# Pulse · September 16, 2026

> OpenAI launches Sponsored Agents and a Shopify ads app, Cloudflare splits AI-training blocks from search crawling, and Gemini 3.8 Live takes over Search Live.

Canonical: https://brandonlazovic.dev/pulse/2026-09-16/  
Author: Brandon Lazovic  
Published: 2026-09-16

## OpenAI launches Sponsored Agents and opens ChatGPT Ads to Shopify and HubSpot

Status: Confirmed  |  Topics: agentic-commerce, chatgpt-assistants

OpenAI announced on September 16, 2026 that it is testing Sponsored Agents, a feature letting ChatGPT users open a business-sponsored conversation after clicking an ad. The test runs with select US advertisers. OpenAI also launched a ChatGPT Ads app in the Shopify App Store, pulling products straight from Shopify Catalog, and a HubSpot integration; Shopify is OpenAI's first ecommerce partner and HubSpot its first customer relationship management (CRM) partner. International Shopify availability starts September 23.

In plain terms: A Sponsored Agent is a separate mini chat a shopper can open after clicking an ad, where they can ask follow-up questions about that specific product before deciding whether to click through and buy.

Why it matters: Shopify merchants can run ChatGPT ad campaigns straight from their existing product catalog, which raises the stakes on feed data quality for the same reasons Google Shopping and OpenAI's own organic feed already do.

Our take: I wrote in June about OpenAI splitting ChatGPT product visibility into two pipelines, an organic feed gated by is_eligible_search and an ads feed gated by is_ads_eligible, after Instant Checkout's in-chat purchase flow got retired for weak conversion. Sponsored Agents and the Shopify ads app extend that same ads pipeline rather than reviving in-chat checkout, so the practical lever for a merchant is still feed hygiene on the ads-eligible fields, not conversational-commerce readiness.

- [OpenAI: Reimagining advertising with AI](https://openai.com/index/reimagining-advertising-with-ai/)

## Cloudflare splits AI-training blocks from search crawling so sites can stop training without losing Googlebot

Status: Confirmed  |  Topics: crawling-indexing-rendering

Cloudflare announced a Disallow AI Training setting that publishes no-training preferences in robots.txt through the Google-Extended and Applebot-Extended tokens, letting a site block AI model training while still allowing Googlebot, Applebot and Bingbot to crawl for search. That differs from Cloudflare's existing Block option, which stops those same mixed-purpose crawlers outright because it blocks every behavior, training or search, at once. New defaults take effect September 15, 2026; Bing's equivalent token support is targeted for early 2027.

In plain terms: Robots.txt is the file a site uses to tell automated visitors what they may fetch. Google, Apple and Bing's crawlers do double duty, feeding both search results and AI training, so a rule meant to stop the training half was also stopping search indexing by accident. This setting adds a line to that same file that targets the training half only.

Why it matters: Sites that toggled a blanket AI-training block for unrelated reasons have a documented fix as of September 15, rather than the support-ticket workaround the same collision required a month earlier.

Our take: I reran a 15-origin probe across 14 large US retailers plus my own site in August, reaching 14 of those origins, and found 12 of them named zero AI crawlers in robots.txt with none carrying Cloudflare's Content Signals directive either, meaning most sites weren't making any training-versus-search distinction to begin with. This setting only helps sites that already manage that distinction inside Cloudflare; the bigger problem in my sample was sites with no signal set at all, which a toggle does nothing to fix unless someone turns it on.

- [Cloudflare Blog: Accountable mixed-use AI crawlers](https://blog.cloudflare.com/accountable-mixed-use-ai-crawlers/)
- [Cloudflare Blog: Your site, your rules, new AI traffic options for all customers](https://blog.cloudflare.com/content-independence-day-ai-options/)

## Google puts Gemini 3.8 Live inside Search Live for real-time voice troubleshooting

Status: Confirmed  |  Topics: ai-overviews-ai-mode, llm-models-agents

Google said on September 15, 2026 that Gemini 3.8 Live powers Search Live, the voice-and-video mode inside the Google Search app, giving it step-by-step, real-time troubleshooting help. The same rollout reaches the Gemini API, Google AI Studio, and Google Workspace's Docs, Gmail and Keep Live tools, plus a private preview in Gemini Enterprise. A companion model, Gemini 3.8 Live Extended Thinking, adds live progress narration for multi-step background tasks.

In plain terms: Search Live is the version of Google Search a person talks to out loud, using their phone's camera or microphone, and as of September 15, 2026 it runs on the same real-time voice model Google built for its other products, instead of an older one.

Why it matters: Search Live becoming a live-model voice interface rather than a scripted assistant changes what counts as visibility for how-to and troubleshooting queries that used to land on a text results page.

Our take: Folding a general-purpose live model into Search Live blurs the line between Google's assistant and its search product, which matters for anyone tracking where how-to and troubleshooting queries go once a spoken answer replaces a results page. Google's own post does not say whether a Search Live session ever surfaces a clickable source link, and that omission is worth watching, since a voice answer with no visible URL removes the one signal a publisher uses to check whether it was the source.

- [Google: Introducing Gemini 3.8 Live and 3.8 Live Extended Thinking](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-8-live-gemini-3-8-live-extended-thinking/)

## Google tests sending shoppers straight to the merchant page from product grid results

Status: Observed  |  Topics: product-feeds-shopping, platform-ecommerce

Search Engine Roundtable reported on September 16, 2026 that Google is testing a change to free product grid listings in core Search: clicking a product opens the merchant's own product page directly instead of the multi-retailer overlay panel. The report is based on a discovery SEO consultant Brodie Clark shared on X, and notes Google piloted a similar direct-link approach inside the separate Google Shopping tab back in June 2026.

In plain terms: Clicking a product in Google's free shopping results often opens a pop-up panel that shows the same product at several stores. This test skips the pop-up and sends the shopper straight to that one store's own product page instead.

Why it matters: A direct-to-merchant click skips the overlay where a shopper previously compared several retailers carrying the same product, which changes both the traffic an eligible listing can expect and the visibility smaller retailers lost inside that overlay.

Our take: This follows a pattern of Google testing changes to the layer that sits between a Shopping result and the merchant's own page, from AI-rewritten ad copy on the paid side to a routing change here on the free side. It is worth tracking once this test is visible in server logs, since Google Search Console's existing Shopping filters won't separate direct-from-Search sessions from Shopping-tab sessions without a merchant checking referrer data directly.

- [Search Engine Roundtable: Google Search Product Listings Tests Linking Directly To Merchant Site](https://www.seroundtable.com/google-product-listings-direct-merchant-42089.html)

## Snowflake ships per-user spending quotas for AI Functions and Cortex Agents

Status: Confirmed  |  Topics: ai-data-stack

Snowflake announced general availability on September 15, 2026 of per-user quotas that cap individual spend on governed AI services, covering Cortex AI Functions such as AI_COMPLETE and AI_SUMMARIZE, Cortex Agents, CoWork, and warehouse compute. Block enforcement automatically pauses a single user's access to a specific service once they hit a daily or monthly limit, resuming on the next cycle, replacing blanket access controls with per-person guardrails.

In plain terms: Instead of an administrator deciding upfront who may use the company's AI tools at all, this lets everyone have access while automatically cutting off any single person once their AI usage for the month gets too expensive.

Why it matters: A team running LLM classification or extraction jobs inside a client's Snowflake instance can be capped without losing access outright, which changes how that access gets negotiated with the client's data team.

Our take: Per-user, per-service caps are a more surgical version of a control that usually ships as an all-or-nothing access grant. The detail worth watching is whether block enforcement fails open or closed for a client-facing agent mid-conversation, since a hard pause on Cortex Agents mid-task is a different failure mode than a pause on a batch AI_SUMMARIZE job that picks up again next cycle.

- [Snowflake Blog: Per-User Quotas for AI: Govern Individual Spend in Snowflake](https://www.snowflake.com/content/snowflake-site/global/en/blog/per-user-quotas-ai-generally-available)
