AI Knowledge Hub
Menu
Back to the libraryGuide / Commerce & growth

A New Front Door: What OpenAI DevDay 2026 Means for Brands, Reach and Marketing Operations

What DevDay's connected announcements mean for brand discovery, persistent customer tasks, shared marketing work and software adoption, with a practical workflow for building and evaluating a useful service.

DevDay 2026 made the direction clear: ChatGPT is becoming a front door to products, services and work. For marketers, reach is moving closer to action. A person can describe a goal, discover a useful capability, try it beside the conversation and hand the follow-up to an agent.

Watching the keynote, I felt the energy of a platform opening up. Dots introduced persistent agents that can continue work across conversations. Spaces brought people, agents and shared context together. Plugins, which package services for use inside ChatGPT, gained homes, panels and file viewers. GPT-6.1 Sol supplied model capability. The Decisions API offered a way for software to classify inputs against defined criteria, while the Agents API provided infrastructure for running agents. The announcements felt connected: intelligence moving out of the answer box and into the work.

My reading of the keynote is that a brand will increasingly be found through what it can help someone do. Product data, service design, permissions and operational reliability become part of visibility alongside creative, reputation and media.

OpenAI’s advertising system is already taking shape through ChatGPT Ads and Sponsored Agents, which let someone enter a labelled conversation with a business-sponsored agent after clicking an ad. Alongside that system, DevDay expanded discovery, native product experiences, persistent agents, team workflows and enterprise procurement. The result is a richer route from intent to action, and a new brief for marketing teams: make the brand useful when a decision becomes work.

How the DevDay announcements connect

For marketing, two opportunities run through the announcements. A business can make its services available inside a customer’s task. It can also use agents and shared workspaces to improve the work behind those services: research, creative production, campaign checks and analysis. A customer choosing a product and a marketing team preparing its launch have different goals, accounts and permissions, even when they use related infrastructure.

The products support different parts of that work. A plugin supplies a capability; a dot can carry a responsibility over time; a shared space holds material people and agents work on together. A business can use one without adopting all three. Their value comes from the connections a particular task needs.

The announcements fit together more clearly when grouped by the work they enable. OpenAI’s DevDay documentation is a useful starting map; the individual product guides give the more precise operating limits. The availability notes below were checked on 24 October 2026.

Part of the systemRelevant developmentQuestion for the brand
Find and use a capabilityPlugin discovery, extensions, sidebar apps, panels and file interfacesCan someone recognise the service and complete the task in a suitable interface?
Continue the workDots and subscriptions to notifications when connected systems changeWhat should persist, what may trigger another run, and when should work stop?
Coordinate the teamSpace, Pages, Team Tasks and approved workplace connectionsWho owns the work, evidence and review?
Connect and adoptSign in with ChatGPT, eligible plan usage and enterprise Marketplace arrangementsWhich account, usage allowance and purchase does the customer actually qualify for?
Operate the systemModels, agent execution, classification against defined criteria and deployment controlsCan the service meet its quality, cost, response-time and governance requirements?

An appliance retailer makes both sides concrete. A customer could use its service to compare models, check dimensions and establish the delivered price. Inside the business, a marketing team could keep the product evidence, launch materials and later corrections consistent. The following sections trace what the announcements contribute to each kind of work.

Give the capability a usable home

Plugin extensions support sidebar applications, conversation panels, file viewers and editors, and structured forms. A service can offer a fuller working interface beside the conversation instead of returning only a block of text.

For appliance selection, a panel could keep dimensions, compatibility and total cost visible while the customer asks follow-up questions. The interface should make differences easier to inspect, particularly the details that would make a confident recommendation wrong.

Support varies by surface. The current extensions guide still describes web extensions for Free and Go users as coming soon; naming a plugin directly in the message composer is desktop-only. A design that works in one paid desktop account has not established reach across every ChatGPT user or device.

Public distribution also has a review process. OpenAI’s packaging guide distinguishes the public directory shared by ChatGPT and Codex, OpenAI’s coding agent, from local and team distribution sources. Packaging a capability is one step; acceptance, availability and customer adoption are separate steps. Portable Intelligence covers the package and compatibility work in more detail.

The directory guidelines say strong utility and user satisfaction may earn enhanced placement or proactive suggestions. That gives service quality a potential distribution consequence. It supplies neither a ranking formula nor a guarantee that improving one metric will produce more exposure.

Carry a customer task beyond the session

Dots introduce ongoing responsibility: an agent can keep working across conversations and connected apps. Where a plugin makes a service available, a dot can carry the person’s goal from one encounter to the next.

The commercial possibility is continuity. A person could ask an agent to revisit an appliance shortlist when stock changes, rather than start the comparison again. The retained information would include the customer’s requirements, the options already checked, and the reason the task remains open.

That changes who may encounter the brand next. The customer may return to the retailer directly, or their agent may compare its current offer with alternatives. A useful service could earn repeat use without a new visit to the retailer’s interface. When Your Customer Stops Opening Your App examines the wider relationship; DevDay supplies concrete infrastructure through which to explore it.

Human preference still matters. Creative work can make a brand memorable before the need becomes explicit. Reviews and reputation can supply reasons to consider it. Accurate product information and reliable execution then determine whether the service can fulfil the request. Delegating a comparison changes part of the route to choice; the person still brings preferences, experience and judgment to it.

Continuity needs an expiry date and a boundary. Watching for availability does not authorize an order. A previous approval may no longer apply after the price, product or delivery terms change. Stop conditions, permission changes and a visible way to cancel belong in the service design.

Events can supply another trigger. An event reports that something changed, such as a product becoming available. Model Context Protocol (MCP) is a standard through which a service exposes defined operations, called tools, to an agent. OpenAI’s MCP Events integration adds subscriptions: the user chooses what to monitor and how ChatGPT should respond, and the service sends matching notifications.

The integration currently requires MCP 2.0 and webhook delivery, meaning the service sends a notification to a receiving web address when the event occurs. It implements part of a draft specification and supports documented ChatGPT Work and dot surfaces. An event can restart the work; it does not create permission to place an order.

Dots themselves are rolling out gradually. Current documentation lists eligible Pro users outside the EEA, UK and Switzerland, alongside worldwide Business Premium and Enterprise rollouts; Enterprise access requires an administrator to enable it. Plan eligibility does not guarantee that an account already has access.

Give marketing work a shared context and owner

ChatGPT Space brings files, Pages and other shared work together. Within it, a space groups material around a project or team. A Page is a document people and ChatGPT can edit together: a brief, research record, plan or set of decisions. These give work a shared place to continue after the conversation that started it.

Team Tasks add work that runs on a schedule or when a specified event occurs. They use the team’s service account, a software identity for shared work, and configured connections to external apps. Those connections determine which app accounts and permissions the task uses. A task does not inherit its creator’s personal memories or chat history.

For the retailer’s marketing team, a product-launch brief could start a workflow that gathers approved specifications, identifies missing decisions and prepares a Page for review. When a specification changes, a configured task could identify affected comparison guidance and draft corrections. Later performance data could prompt an evidence summary and questions for the team to investigate. Each run would return to the same project material, with its sources and unresolved decisions visible.

The distinction from the customer’s agent matters. The customer’s agent is trying to find a suitable appliance. The team’s workflow is trying to keep the retailer’s work accurate and coordinated. One does not automatically gain access to the other’s context.

Agencies can apply the same pattern to creative variants and disclosures, campaign destinations and settings, performance investigations, or recurring customer-service issues. Where enabled, ChatGPT in Slack and Teams can connect this work to approved workplace conversations. The persistent value is the connection between approved evidence, working drafts, human decisions and later updates. People still decide which interpretation or creative response deserves to be taken forward.

Shared context does not mean universal access. Team connections may reach information that individual members could not access through their personal accounts. Review membership and connection scope together, and assign an owner for failures, updates and offboarding. That is the organisational work described in the enterprise adoption framework.

Separate identity, usage and procurement

These three can all affect adoption, but they remove different obstacles.

Identity answers who is connecting. Sign in with ChatGPT lets someone use an existing ChatGPT identity in a participating application. Plan usage concerns how supported AI requests are funded: an eligible user can apply some of their ChatGPT allowance in a participating application. For a software provider, fewer account and payment steps could shorten the path from discovery to first use.

The current DevDay documentation describes commercial Sign in with ChatGPT as a limited trial with selected partners; plan usage is available to open-source partners and selected private clients. A brand cannot assume it can offer either integration simply because launch partners could.

Enterprise procurement concerns how an organisation buys software. OpenAI Marketplace lets eligible enterprise customers apply part of an existing contractual spending commitment to qualifying partner products. A software purchase may therefore fit a budget relationship the customer already has. The initial process is managed with OpenAI and the partner, which contracts with and invoices the customer. It has no self-service checkout, and eligibility is assessed for the customer, product and purchase.

This enterprise software arrangement is separate from the rules governing purchases through a plugin. It does not make plugin-directory placement a software licence, transfer every user’s allowance to every tool, or make every product from a participating vendor eligible. The dependency is commercial as well as technical: OpenAI increasingly mediates how a service is encountered, connected and bought.

Choose an execution system that fits the job

The model helps interpret the request, classify information or decide which tool to call. The runtime is the software environment that runs the work. GPT-6.1 Sol and faster processing options expand implementation choices; cost and speed still have to be measured against the task’s quality requirements.

An API, or application programming interface, lets one piece of software use another’s functions. The Agents API provides a managed Codex harness, the surrounding software that keeps an agent’s work running. It maintains sessions, coordinates steps, manages what information remains available to the model and handles recovery. Applications supply tools and choose where code runs, including supported sandboxes, isolated environments that contain files and processes.

The Decisions API, now documented as generally available, handles a narrower job. It returns answers in a defined format, such as a category, probability or score against specified criteria. A retailer could use a classification to route a question to product advice, delivery or support, while a team could classify new issues for review. The application still controls the resulting action. Routing a request and carrying a long task through several steps are different needs.

A retailer may need only a narrow catalogue service for its first useful plugin. Adding persistent agents, several models or computer use should answer a demonstrated need. Privacy, network access and data residency require checking the chosen service and deployment terms; a platform-level trust announcement cannot establish that a particular workflow meets them.

The connection across DevDay is that more of this supporting work can use shared platform infrastructure. A business still has to decide which customer or team outcome justifies assembling it. The same question applies to distribution: being available in the environment is only the beginning of being chosen.

Keep three forms of visibility separate

The new service surfaces sit alongside advertising and information discovery. They do not collapse those systems into one ranking mechanism.

RouteWhat the brand is trying to earnWhat should be measured
Information discoveryInclusion in an answer or product resultAccuracy, source support and observed appearances across a defined test set
Capability discoverySelection of a service that can perform a taskAppropriate selection, followed by separately recorded invocation, completion and repeat use
Paid advertisingA labelled commercial placementDelivery, cost, attributed outcomes and experiments testing whether the ads caused additional outcomes

Information discovery includes cited content and shopping product results. Capability discovery concerns finding and selecting a service; invocation records a later call to it, and completion records whether it did the job. An ad may introduce the appliance retailer before any of those events. Success in one route does not establish success in the others.

OpenAI’s September advertising announcement introduced a US test of Sponsored Agents, reached through ads. Its October update announced a visual-format test, expanded measurement partnerships and brand-suitability pilots. These are paid-ad developments with their own access and rollout conditions. They do not establish paid plugin ranking or influence over an independent answer.

Who Owns the Pixel? examines the information boundary around advertising; the ChatGPT Ads playbook follows paid buying, event setup and a controlled campaign test. For a business considering a customer-facing capability, the next question is how to turn the platform opportunity into a service that can deliver what it promises.

See the complete customer task before choosing the tools

The appliance retailer provides one worked application of the wider DevDay changes. Its plugin could compare models against a kitchen’s dimensions, check stock and explain the delivered price. The package can combine instructions, access to current data, tools and an optional interface. A skill describes a reusable procedure, such as comparing compatible appliances; a tool performs a defined operation, such as checking inventory. The interface helps the customer inspect information or complete part of the work.

The host, ChatGPT in this example, runs the conversation and decides how to make those capabilities available. The retailer operates the product systems behind them. For the customer, the useful unit of design is the whole task:

Customer states a goal and constraints
    → a relevant capability is found and chosen
    → necessary access is approved
    → the service retrieves facts and prepares an outcome
    → a permitted action is confirmed and executed, if needed
    → the result is checked and explained
    → any continued work has a defined owner and stopping rule

A comparison may need no account connection. A purchase may finish on the merchant’s website. A continuing task may require a separately configured agent. Design the handoffs around what each step actually needs.

The boundaries matter. ChatGPT can interpret the request and select a tool. The retailer’s catalogue establishes product specifications; its stock system establishes availability; its authorization service determines whether this account may perform this action. A high-confidence recommendation cannot substitute for any of those checks.

The permitted commercial scope also shapes the design from the start. Current plugin commerce rules limit transactions to permitted physical goods and prohibit selling or upselling digital subscriptions through plugins. Existing subscribers can use features their subscriptions already cover. That makes an appliance comparison and purchase a suitable case to examine; a software provider must assess its own permitted service and purchase flow separately.

The plugin growth workflow

The following seven steps apply the customer-service part of the DevDay map. They connect the retailer’s offer to discovery, reliable execution, evaluation and continued use. An internal marketing workflow would need its own brief, shared access and review arrangements; publishing a public plugin is not a prerequisite for that work.

1. Choose the customer job and its success condition

Start where the brand owns useful expertise, data or execution: compare, configure, diagnose, quote, replenish, manage or resolve. Name the result in customer language before choosing a platform feature.

For the appliance service, the brief could be: “Return up to three available models that fit the supplied dimensions and budget, explain any unresolved compatibility question, and show the delivered cost.” Returning fewer options, or asking for a missing measurement, may be the correct outcome.

Name the business objective separately: a qualified enquiry, sale, resolved support issue or repeat use. A sale does not prove that the appliance fitted. The customer condition constrains what counts as commercial success.

2. Deconstruct the offer into facts, procedures and actions

The agent needs more than persuasive copy. It needs product attributes and exclusions, current stock and price, delivery charges, compatibility rules, return terms and the evidence behind each claim.

Give each part a clear role:

  • Skills carry procedures, such as comparing models against the stated requirements.
  • References explain approved specifications, policies and brand standards.
  • Tools retrieve current information or perform bounded operations.
  • Systems of record, the business’s authoritative databases and applications, establish facts such as inventory and order status.
  • Authorization controls decide which identity may access a record or change it.

A product database can establish the appliance’s depth. It cannot establish that the customer measured the available space correctly. The service must show that remaining uncertainty and ask when it affects the recommendation.

This is also where marketing and engineering meet. A promise of “fits your kitchen” creates a different evidence requirement from “matches the dimensions you supplied.” Choose language the service can support.

3. Define when the capability should be selected

Write the service’s contract in plain language: what it recognises, which inputs it needs, what it returns, when it asks a question, and what it declines. Metadata is the descriptive information that helps the host recognise the capability and its scope, including tool names, descriptions and required inputs. It should describe that scope accurately rather than instruct the host to prefer the brand.

Build a labelled prompt set, with an expected response for each case:

Test typeAppliance-service exampleExpected behavior
Direct“Use this retailer’s service to compare these two models.”Use the relevant comparison tool
Indirect“I need a slim dishwasher below this budget.”Recognise the supported job and gather missing constraints
Negative“Explain how dishwashers work.”Avoid an unnecessary commercial tool call
Ambiguous“Will this one fit?”Establish which model and which space before recommending
Boundary“Use my employer’s account to buy it for me.”Resolve account access and purchase authority separately

OpenAI’s metadata guidance recommends direct, indirect and negative prompts and repeated selection tests. Measure precision, whether activations were appropriate, and recall, whether appropriate opportunities were recognised. Change metadata methodically and rerun the set after revisions.

Those tests evaluate tool selection under recorded conditions. They do not reveal a directory ranking formula or prove that an unconnected customer will encounter the plugin. Keep discovery, selection and task completion as distinct questions.

4. Build the trust and deployment path

For a remote MCP service, the business or its vendor operates the endpoint, the network address where the host sends requests, and the systems it reaches. MCP provides the tool interface; the merchant’s service remains responsible for enforcing its business rules.

OpenAI’s authentication guide distinguishes identifying the connecting software from deciding what a user may access. Mutual TLS (mTLS) uses certificates to identify ChatGPT as the connecting client. OAuth 2.1 supplies the flow through which a user grants account access. The resulting access token is a credential the service must validate; its scope describes the access granted. On each call, the service still checks that credential, the account and permission to access the particular record or operation. An anonymous public-stock lookup and a private order lookup need different access rules.

The appliance service should separate comparison, preparation and purchase. A proposed cart can show the chosen model, current total and delivery terms before the customer approves an order. Recheck those conditions when executing, and make retries safe: a timed-out response must not cause a second order. Record an unknown result as unresolved and reconcile it with the order system.

Public MCP deployment guidance requires a stable HTTPS endpoint, using an encrypted connection, and production checks. Store credentials in a managed secrets service rather than in prompts or interface code. Limit which systems the service can contact. Set timeouts, which stop requests after a defined wait, and rate limits, which cap how many requests the service accepts over a period. Collect sufficient operational evidence without exposing sensitive data. Version the tool contract and optional interface together, monitor failures, and provide a way to disable a faulty operation.

An isolated sandbox or virtual machine can contain the agent’s files and processes, while the retailer’s service checks account authority and confirmation. An optional user interface also needs its own content security policy, which limits the websites and services it may contact or embed. The secure-agent architecture develops the separation between reasoning and authorised execution.

5. Test the outcome, including failure

Evaluate the appliance service across representative requests, then validate the current facts and permissions for each live use. The Agent Architect’s Playbook defines the shared evaluation, validation and policy responsibilities. Here they must protect both the comparison’s accuracy and the customer’s account.

Test stale stock, missing dimensions, conflicting policy text, expired access, the wrong account, slow tools, duplicate requests and partial execution. Include an instruction hidden in retrieved product text that tries to redirect the agent. Product text is evidence about an appliance, not permission to change the task.

Keep separate results for:

  • appropriate selection and clarification;
  • factual accuracy, compatibility and freshness;
  • completion of the customer’s stated job;
  • denied access and required confirmations;
  • recovery, escalation to a person, response time and cost;
  • downstream sales, returns, complaints and repeat use.

A service that always returns three products can look productive while concealing missing evidence. Correctly withholding a recommendation or handing the task to a person can be a successful result. Define release criteria before looking at the results, review failures, and repeat the evaluation when tools, policies, models or metadata change.

Use those tests to gather evidence before making deployment or performance claims. The discipline is the same as in Building to Learn: a convincing model response is the beginning of evidence gathering.

6. Launch with a measurement plan for both sides

Publish clear descriptions and starter prompts, complete the applicable review, and distribute the service through owned channels and partners as well as the directory. The listing should explain the useful job and required access without promising universal availability.

Distinguish what your service can observe from what the platform might expose:

Evidence layerPossible observationsLimit
Service-sideTool calls, errors, response time, checked comparisons, completed orders and support outcomesA call does not explain every earlier discovery event
Platform-side, where availableDirectory exposure, suggestions, installations, permission steps and selectionDo not assume the host supplies a complete publisher analytics feed

For the first layer, define which events are necessary, disclose collection and retention, minimise personal data and respect user controls. Keep internal diagnostics out of model-visible results unless needed for the task. The service receives explicitly supplied inputs and resources; it must not reconstruct a full conversation history.

Report the denominator for each rate: the set of requests or attempts being counted. Order completion among checkout attempts differs from successful comparisons among comparison requests. A change in the user mix can change either rate without improving the service.

If a host metric is unavailable, leave it unavailable. A controlled prompt test can estimate behavior on that test set; it cannot be relabelled as market-wide visibility. Use an appropriate experiment before attributing revenue lift to the plugin, and separate that result from platform-reported conversions.

7. Earn the next useful action

After a successful comparison, a customer may need a compatible accessory, order tracking or a later availability check. Offer the continuation only when it follows from the chosen task, explain the reason, and obtain the access or approval it needs.

The next offer must fit the commerce restrictions established when choosing the service. Checkout documentation recommends merchant-hosted external checkout for most developers; embedded payment-sheet access remains limited. A customer may complete the choice inside ChatGPT and finish the purchase on the retailer’s website.

For the appliance service, a compatible physical accessory may be a relevant next choice. An unrelated promotion, or a digital-service upgrade inserted into the task, would cross a different boundary. Completing the first job does not entitle the brand to expand the customer’s goal.

If the customer chooses continued monitoring, retain only the necessary state, set an expiry, explain notifications and make stopping easy. Review outcomes through a controlled change process. Remembering a preference, revising an instruction and training a model are different operations; none automatically improves the next recommendation.

The operating model behind the new front door

DevDay connects a broader change in reach to a change in how work is organised. On the customer side, a brand’s competence can become available during a task and useful again when the need returns. Inside the business, agents can help carry evidence, drafts and decisions across the work needed to fulfil that promise.

Those two sides meet across departments. Brand and creative teams make the offer meaningful and understandable. Product teams choose the job. Commerce and service teams maintain the facts and fulfil the promise. Engineering implements access, execution and recovery. Measurement distinguishes use from benefit, while a named owner decides when evidence warrants a release or a pause.

Agencies can help connect those responsibilities: design the customer task, prepare the product evidence, test discovery, build the review process and assess outcomes. They can also improve the work between launches: keeping approved material current, carrying corrections forward and returning unresolved choices to the right people. Persistent team workflows can reduce operational gaps, provided someone owns their connections, costs, failures and updates.

Discovery, continuity, collaboration and easier adoption can reinforce one another. They also give OpenAI a larger role in how services are encountered, connected and bought. A business should preserve its own product truth, order records, customer-service capability and permitted evidence of outcomes.

The Meta Connect comparison examines how rival platforms could turn those relationships into marketplace power. Distribution Alone Is Not a Moat asks what durable value a business can build from the reach while remaining dependent on a platform’s rules.

What stayed with me from the keynote was the connection between the announcements. More of the path from a goal to useful work can take place within the same environment, with people, services and agents contributing at different points. For marketing, the new front door leads both to the brand’s capabilities and to the work behind them. The opportunity is to make both worth returning to.

Publication history

Originally published by Performics Labs.