How OpenAI's Sites Turns a Spreadsheet or Prompt into a Live, Personalized Web App

John introduced himself as the lead engineer for Sites and said that, although many people know Sites as a web hosting service launched earlier this year, it is more than that. He said he initially joined OpenAI to work on internal web apps for researchers. He found it frustrating to deploy those tools within OpenAI's infrastructure, so he prototyped an easier way to deploy full-stack web apps within the company directly from Codex.

He described how the prototype spread: other engineers passed it around, then non-engineers unexpectedly began adopting it, and apps started spreading throughout the company. A team was formed, some of whose members were in the audience, and a few months later Sites shipped.

John said that although Sites had shipped only a couple of months earlier, OpenAI was already hosting 8 million Sites. He added that at OpenAI, over 70% of employees were making their own Sites.

He listed some of the most common use cases: jamming on ideas with others, replacing slide decks with more interactive presentations, replacing spreadsheets with dedicated UIs, and creating internal tools built for each team. He said that people in go-to-market, IT, product management, design, and engineering were all building prototypes and production tools, and that he was personally excited about games. He said the team shares these without sweating the details, and that at OpenAI there is now a site for everything.

John observed that because Sites connects to users' context, plugins, and agents running in ChatGPT, it makes it easy to create personalized software and collaborative experiences for both internal and external use cases. He then outlined the session: building a site from a single prompt, making it collaborative and personalized, and making it agent-friendly.

Katia said her team keeps a spreadsheet, updated regularly, to track DevDay launches. It holds context on the several launches at DevDay, the progress on each project, and links to other assets and documents. She said the sheet is a good way to see at a glance what is happening, but it is not very practical for getting details on each project, and that it is a bit boring to look at.

On screen, she asked Codex to turn the sheet into a launch radar app in a new folder and publish it as a site, using the shared DevDay UI library and the Sites system. She specified that milestones and items needing attention should be shown with launches visible on the first screen, and that users should be able to filter by product area, switch between list, board, and calendar views, and open each launch's docs and assets. She then asked Codex to keep the site up to date every morning using the launch briefs linked from the sheet.

While Codex built the site, John explained plugins. He said plugins are the way ChatGPT and Codex bundle connectors and skills so that Codex and ChatGPT can access data from third-party services. As examples, he said a plugin lets Codex read which tasks are assigned to a user in Linear, search Slack messages, or post PR comments in GitHub on the user's behalf. Codex can use plugins to fetch up-to-date data and then update the site.

He said that combining plugins with scheduled tasks means Codex can keep a site up to date even while the user is asleep. A task can be scheduled from the thread to run every hour, every day, or every week, and it fetches data from whichever plugin has it. He gave the example of asking it to use Google Drive. Sites also includes a SQLite database, so when the data the site shows changes, the source code does not need to change; the task updates the database directly, and the site updates instantly without redeploying. He said scheduled tasks for sites were launching that day, that tasks and sites can be linked for easier management, and that Codex will suggest scheduling when it is relevant.

John described Sites' built-in authentication, powered by Sign in with ChatGPT. A site can be made publicly available on the internet, with a landing page for anonymous users, and a link can let users sign in to ChatGPT to enable additional functionality, like a standard web app. Before publishing, however, he said that all new sites are private by default. When a site is private, the team makes sure only the intended people can access it, and visitors must sign in with ChatGPT first, where the site checks that they are who they say they are before letting them through.

He added that starting that day, teammates who sign into a private site can also bring their ChatGPT plugins to the site they are visiting.

John said that with plugins and Sites, a site can directly access a teammate's data from services like Drive, Slack, and Linear, and that this also works with a team's internal-only connectors. Katja described the intended behavior: when she visits a site with plugins implemented, she sees her own data, fetched when she first loads the page, and when John visits the same site he sees his own data from his connectors.

John said that implementing this only requires asking Codex. Katja then asked, on stage, that Codex be shown doing it.

Katja sent a follow-up prompt to the existing thread asking Codex to deploy the site as soon as possible and to add the Linear connector with read and write access. She asked that each person see their assigned tickets alongside the relevant launches, and that she be able to change a ticket's status or description and save it back to Linear. The app was still publishing while she explained it.

On screen, she opened the built app and said Codex had built what was requested: the launches, the views she asked for, and the design system she had specified. She said it was built in a few minutes while John was talking. Katja stated that instead of a simple spreadsheet for updates, the team can get an interactive site to share with the team with zero effort. She said this was not only a demo, that OpenAI does not use this particular spreadsheet because far more launched that day, but that the same approach was used across the company to prepare for the event.

Katja explained that a site can be shared with specific people. She searched for John and added him as an invitee. She said that she could also add him as an editor, which would allow him to edit the app later.

She described the editor permission as a different type of access that lets anyone in the workspace with editor access push updates to the hosted site. She also noted that she could save the sharing settings. In the demo, a scheduled task linked to the site appeared in the interface.

Katja said the site has a scheduled task linked to it that updates the site daily based on updates to the documents in Drive. She said that when a site has a scheduled task, the site suggests one, so the user does not need to think about updating the site, because it updates on its own.

She then checked the site's plugin implementation. It was still running but was now live, and she opened it. The site had already logged her in. The page showed her own Linear tickets, which she said she saw after adding only the Linear plugin.

Katja asked John to access the site. He said it looked very similar and was indeed the same site, but scrolling down showed his own tickets. She explained that this data was fetched when he loaded the site and was retrieved through his existing Linear connectors from ChatGPT.

Katja emphasized that no third-party integration is needed: no API keys, no API docs to reference. The functionality comes out of the box with Sites, leveraging each user's existing connectors, so the builder does not have to think about permissions or access. Because the site also has write access, she tried updating one of her own tickets, which first loaded, then she changed its status and saved it, and the save succeeded.

Katja opened the app in the ChatGPT in-app browser and said she wanted to edit it. She explained that the browser has a feature called annotations, where she can pick out specific elements to change. She said that starting that day, the ChatGPT in-app browser has a new feature, annotation extensibility, which lets developers prepare custom annotations for users of any web app. The annotations are embedded directly in the HTML, and they signal to Codex how it can edit the site, for example through custom controls or suggested prompts, so editors can more easily discover what they can change. She said this is especially useful for design systems and component libraries.

John demonstrated the editing flow. He clicked the Edit UI button and was shown a suggested prompt built into the site, which made it easier to know what could be changed. He activated annotation mode and selected an element. As he selected it, the change was applied automatically, allowing a preview. To commit the change, he told Codex to make it, and Codex worked on it and then sent it.

He said these options were baked into the site's HTML, so if a site is shared to be edited by other people, contributing becomes much easier. He concluded that sites can be made more personal with plugins and collaborated on effectively with custom annotations, which he said is great for internal apps shared within an organization, but that sites can also be powerful web apps for a general audience.

Katja presented a GIF Studio app she said was built with Sites, offered as a gift for John. She explained the app creates a custom GIF box. In the first step, the user takes a picture with the camera, and the app generates a design. She said this runs behind the scenes using the OpenAI image API with the newest image model. That is possible because Sites lets developers add secrets as environment variables. She said an OpenAI API key was added in this case, but any third-party service can be integrated the way it would be in any full-stack web app. The GIF box was then ready.

For the second step, filling the box, Katja said she could browse the catalog manually, but preferred to have the agent do it automatically. She introduced WebMCP as a new browser standard that lets an agent interact with a site through exposed tools. Any app can expose WebMCP tools, and when they are used within a WebMCP-enabled browser such as ChatGPT's in-app browser, users can work with their agents to take actions that update the live app.

Katja said the difference from something like computer use is that the agent can use a site through tools instead of clicking through the UI. Depending on the use case, she said, this can be much faster and cheaper. With computer use, the agent has to click, open each item, and see its metadata. With WebMCP, the agent can query the backend directly. She said it is the user's own agent taking action, so it has access to the user's data and apps when it calls the WebMCP tools.

In the demo, she asked the agent to look through Slack for what John was into and then show gift recommendations from the catalog above the box. The agent read Slack, then updated the UI with suggestions, including toys for a dog, after finding that John loved his dog. Katja then removed some items, with a budget she said would be kept under $100, and added the remaining items to her basket. Because the suggestions appear in the UI, she said she could collaborate with the agent directly from there.

For the final step, Katja said she wanted to write a personal message but that ChatGPT remembers previous discussions better than she does. She asked the agent to create a personalized message based on their previous discussions and update the UI with it. The agent produced a message she said she liked, and she confirmed it, and the gift box was ready.

John then summarized the idea: if you build a site and want it personalized to your users, you can let your users' agents know how they can use what they know about the users to take action on your app. He said that as users bring their agents with them to navigate the web, apps can be built to work well with agents, and that with Sites this requires no extra work, because a site's plugin knows how to implement WebMCP and it should be added automatically where relevant.

John said Sites allows you to build all kinds of experiences, from presentations, ideas, and experiments into websites that are kept updated automatically, but that they are more capable than that. Sites can be full-stack web apps that scale automatically, come with auth and a database, and now have access to teammates' data via plugins. They are optimized for both people and agents.

He encouraged developers building for this agentic era to rethink their experiences and to add custom annotations and WebMCP to make it easier for both people and agents to contribute and interact with their apps. The talk ended with thanks.