Stop Describing the Change. Start Pointing at It.

Anyone who has used AI chat for real work knows the small humiliation of the follow-up. The answer arrives, and it is nearly right. So you type: “Not that one. The one with the stairs. No, the other stairs.” You are describing something you could have touched in half a second.

That friction is the best way into a change now showing up around AI agents. The interesting developments are not only smarter replies. They are places where you can take part in the work: pick a row in a live table, open a file beside the conversation, use a web page together with the agent, publish a small tool others can open. The conversation stops being the whole workplace and becomes one room in a larger building.

Those rooms do different jobs, and the vocabulary around them (skills, plugins, MCP Apps, extensions, WebMCP, Sites) can make them sound like one thing under six names. They are not. Each answers a different question about where the work lives and who is allowed to change it. To keep that concrete, the rest of this piece follows an invented example.

The scenario is illustrative. It is not a product run, a test or a record of anything that happened.

---

The Scene: A Repair Café That Needs a Room

Imagine a six-person volunteer group planning a one-day repair café, where neighbors bring broken lamps and torn jackets and volunteers help fix them. Over a few weeks they have three jobs. They must choose a venue. They must make a five-slide pitch for the local council, which holds the grant. Then they must share a small planning tool so volunteers can claim shifts and bring equipment.

None of this is exotic. That is the point. Each job needs a different relationship between the people, the agent and the thing being made. Watch where that relationship changes.

---

Stage One: Teach It How You Judge (Skills and Plugins)

Before anything appears on screen, the group has a quieter problem. They have opinions about venues that live only in people’s heads. Step-free entry matters more than a nice view. Power sockets matter more than parking. Noise matters because someone will run a sewing machine next to a soldering iron.

This is where a skill fits. Per the documentation, a skill packages reusable instructions with supporting references, scripts or assets. For the group, that could be a short written method: how to score a venue, what to flag, how to phrase a recommendation, and a reference sheet of accessibility questions. Nothing about it is visual. It is a way of making “how we decide” something the agent can pick up again next week without being re-briefed.

A plugin is a different kind of thing. The same documentation describes a plugin as a way to distribute a bundle that can include skills, MCP tools or connections, and hooks. A plugin that includes a connection to a booking calendar might let the agent see which halls are free. But a plugin does not have to contain every one of those parts, and the plugin label alone does not tell you what is inside.

There is one honest limit worth stating here, because it applies to everything below. Installing a package, or having good instructions, does not establish that the agent has authorized access to anything. It also does not establish that a task was completed. A skill gives the agent a method. A plugin may give it reach. Neither is a result.

What this stage changes: the agent starts from your standards, not from generic ones. It does not yet change what you can touch.

---

Stage Two: Choose Inside the Answer (MCP App UI)

Now the agent has found eight candidate venues. In plain chat, you would get a list in prose, and the “the one with the stairs” problem begins.

MCP App UI addresses this. According to the documentation, an interactive interface can appear in the conversation so a person can inspect structured output, choose and edit. For the group, that means a real table inside the chat. It would have columns for capacity, step-free access, hire cost and noise rating. You could sort it, tick two venues to compare, and correct a capacity the agent got wrong.

Two details in the documentation matter for how you think about this. First, standard MCP Apps are described as providing portable UI patterns, while optional OpenAI extensions add host-specific features. Some of what you see may therefore depend on where you are working. Second, a widget’s selected state is not automatically the authoritative, durable record. Ticking “Hall B” in the table tells the agent something about your intention. It does not make Hall B booked, or even saved in the group’s spreadsheet. The real record lives in whatever service stands behind the table, and whether that service accepts your change depends on the tool it connects to.

This is the first genuine shift in the relationship. You are no longer a describer. You are a participant who can say “this one” with a click. The service still holds the truth.

What this stage changes: selection and correction become direct. The authority stays with the underlying tool.

---

Stage Three: Work Beside the Conversation (Plugin Extensions)

The group picks the community hall and now needs the council pitch. A slide deck is a poor fit for a chat bubble. You want to see it, edit a headline yourself and ask for a change to slide three without losing your place.

The plugin extensions guide describes this territory: sidebar surfaces, file viewers and editors, and richer forms alongside the conversation. The conversation stays on one side. The thing being worked on sits on the other, where both you and the agent can act on it.

The distinction from Stage Two is subtle but real. In this example, the table helps the group compare a set of results, while the file panel gives them room to shape an artifact. These are useful design choices rather than hard categories: MCP App UI can also support editing and richer presentations.

Practical limits are documented too, and it is worth knowing them before you plan around this. Composer mentions are desktop-only. Extensions on free and Go web plans are described as coming soon. The guide’s examples involve Canva, Figma and Adobe, but those are the documentation’s illustrations, not anything we have tested, and nothing in them suggests you should install anything. If the group has no design tool they already rely on, there is no reason to go looking for one.

What this stage changes: the artifact becomes visible and editable by both parties at once, so “make it shorter” can become “I shortened it; now fix the transition.”

---

Stage Four: Share the Page with the Agent (WebMCP and Site Tools)

The hall has its own online booking page. Held slots and a deposit form live there, and nobody wants an agent guessing at a form it cannot see.

WebMCP is a proposed standard, and the documentation describes ChatGPT’s use of it as site tools. A website can offer predefined actions, such as “check availability for a date” or “start a hold.” An agent can use them in the same live page and session as the person. You are both looking at the same booking page. You watch it happen, and you can step in.

The key contrast is with MCP connections. A connection can run independently of any open webpage. Page tools cannot: they depend on the page being there. That makes page tools useful when the website itself is the place where the action must occur; they do not replace a connection designed to work independently of that page. Native browser control, where the agent operates a page like a person would, is a separate path and serves a different purpose. Site tools use actions the site chose to expose. Browser control operates the visible interface rather than calling only the actions registered as site tools.

The implementation details are narrow, and they are clearly documented. Current ChatGPT support covers tools registered through top-level JavaScript (document.modelContext.registerTool). It does not cover declarative HTML-form tools or tools inside iframes. So whether the hall’s booking page can take part depends on how that page was built, which the group cannot assume. Some volatile setup details (supported models, plan eligibility) are in the dated note at the end instead of here, because they are likely to change.

What this stage changes: the live website becomes a shared workspace, but only where the site chose to offer actions.

---

Stage Five: Publish the Thing (Sites)

The venue is chosen, the pitch is drafted and the council has said yes. Now the volunteers need somewhere to sign up for shifts, see the equipment list and find the hall’s address.

Sites is in public beta and is described as a way to make hosted websites, apps and games. Here the shape of the relationship changes again. Everything before this was about the group and the agent working on something. This is about the group making a place for other people.

The documentation draws several lines worth noticing. Saved versions and deployment are separate, so having a draft is not the same as having published one. Durable storage and audience controls exist under documented configuration, which matters for a shift list that has to survive past the session and probably should not be public. Visitor-specific connected data is available for enabled, workspace-private Sites. It is not a feature of public anonymous sites. A public sign-up page does not automatically inherit the creator’s connections. What visitors can see and change depends on the application’s data and access rules.

A Site is also not automatically a plugin or an MCP App. It is its own thing: a destination. That framing opens a broader idea. The documentation notes that an article can become an explorable experience, not only a page of text. The group could publish its own story, with the venue table, the map and the shift planner, as something readers move through.

What this stage changes: the result stops being a file for the group and becomes a place for others, which makes saving, deploying and permissions matter in a way they did not before.

---

What Actually Changed

Run the scenario back and the pattern shows. Each surface answers one question: where does this thing live, and who can touch it?

• A skill keeps your method and carries it forward.
• A plugin may bring reach to other tools and data, depending on what it includes.
• An MCP App UI puts a choice in front of you inside the answer.
• An extension puts a document beside the dialogue.
• A site tool puts a live website in shared use.
• A Site gives others somewhere to go.

The deeper shift is in who holds authority. In plain chat, the agent holds the whole draft and you hold a vague sense of what you wanted. In the richer surfaces, the person can see the object and act on it. That can give the person a more direct way to inspect and change the work. But it exposes a new habit worth building: always ask what the source of truth is. A ticked row is an intention. An edited panel may be a draft. A booked slot is something only the booking service can say. A good session with these tools keeps those three things from blurring.

There is also a limit on the enthusiasm that is worth keeping, because it is what keeps the enthusiasm useful. The documentation describes mechanisms, not guarantees. A surface appearing does not mean it works in your account, on your plan, with your tools or on the website you need. The DevDay 2026 page places the announcement of plugin extensions, connected Sites and related features on September 29. That tells us when the pieces were presented together. It says nothing about how widely they are used or how well they work in practice.

---

Choosing Your Next Step

You do not need all six. Use the situation to pick.

1. If you keep re-explaining your standards, write them down as a skill-style set of instructions first. It is a small first step and needs no custom interface.
2. If you keep saying “not that one,” look for a tool that offers an interactive table or form in the conversation.
3. If you are shaping a document or file, look for a workspace that sits beside the chat, and check desktop and plan availability first.
4. If the task happens on a particular website, check whether that site offers its own tools before reaching for general browser control.
5. If other people need to use the result, consider a Site, and settle audience, storage and deployment before the design.

The best first experiment is small and reversible: one table, one file, one page, with nothing sent to anyone yet. The point of a richer medium is not that the agent does more. It is that you can stay in the work and keep your hands on the parts that are yours.

Sources and scope

This is a source-based explanation with a fictional repair café, not an account trial. Product documentation was originally checked on 15 October 2026; the core OpenAI interface, WebMCP and Sites pages were rechecked on 23 October. Availability depends on the host, plan, rollout and workspace settings. The surface-selection argument is editorial interpretation. CodexWork is independent and unofficial.