ChatGPT plugins can now provide a place to work alongside the conversation and receive events that start work later. Those are two different design choices. Build a panel when the user needs to inspect or edit a stateful object; add an event trigger when a defined change should start a bounded task.
Written October 1, 2026 and dated September 29, 2026, using the dated announcements cited below. Later product developments are outside this article’s scope.
- 01Use a panel for persistent stateA file preview or editable record can be clearer than another long chat response.
- 02Events need lifecycle handlingSubscription creation, delivery, cancellation and duplication all need deliberate behavior.
- 03The specification is proposedChatGPT’s supported implementation is narrower than the complete draft design.
- 04Separate delivery from acceptanceA callback received is not a task completed; keeping the two apart is what lets a failed analysis be retried without repeating a write.
01 — The evidenceWhat extensions add to a plugin
OpenAI’s extension guide describes sidebar homes, interactive panels and file viewers. The recap advertises broad plan availability, but the implementation docs read October 1 still say Free and Go web support is forthcoming and composer mentions are desktop-only. Check the surface you intend to support rather than treating a plan name as proof of identical behavior everywhere.
Choose an extension around an object the user needs to understand. A report with filters, a file that needs a custom viewer or a form with several dependent fields can benefit from a panel. A short answer may not. The purpose is to make the state and available actions visible, not to reproduce your entire application inside a smaller window.
Keep the conversation and panel consistent. If the agent says a draft changed, the panel should show the current draft and indicate whether it is saved. If the user edits the panel, the next agent action should operate on that version. Ambiguous ownership of the current state produces mistakes even when each individual interface looks correct.
02 — Practical implicationsWhat MCP Events does and does not standardize
The MCP triggers and events working group is developing the specification. OpenAI’s implementation guide describes webhook delivery with callback verification, durable subscriptions and the list, subscribe and unsubscribe operations. Its supported integration does not include every draft transport or notification type. Describe it as support for a proposed specification, not a ratified universal standard.
The user asks for work
Use a direct tool call when the current request provides the necessary authorization and inputs.
The user works with an object
Keep edits, saved status and available actions understandable alongside the chat.
A defined change starts work
Specify the trigger, permitted response and cancellation behavior before subscribing.
An event says something happened. It does not automatically authorize every action the agent could take in response. A new support item might justify preparing a draft, while sending the reply needs a separate rule. Keep the subscription’s purpose narrow enough that a reviewer can tell whether a delivered event belongs to it.
Current docs describe support in Work chats on web, desktop Work with Cloud selected and dots, subject to workspace controls. Those implementation details were checked October 1; they should not be used to invent a broader launch-day entitlement.
03 — DeliveryTreat event delivery as an application protocol
Store enough information to identify a subscription, its owner and the action it can trigger. When a callback arrives, verify it using the documented mechanism and associate it with that subscription before starting work. A payload should be treated as task data, including any text supplied by a third party, rather than as new operating instructions.
| Condition | Expected behavior |
|---|---|
| Repeated event | Recognize the same event and avoid repeating a consequential action. |
| Revoked access | Stop using the connection and explain which work can no longer continue. |
| Cancelled subscription | Prevent future delivery from starting the cancelled task. |
| Malformed payload | Reject or quarantine it with a useful diagnostic record. |
A test should include both a normal event and an event that arrives during an interruption. Verify whether the worker can resume safely and whether it knows which steps already finished. Keep a record of the event identity, task identity and outcome. Those details are far more useful during an incident than a generic “automation failed” message.
Do not assume that a webhook’s successful receipt means the business task succeeded. Separate acknowledgment of delivery from acceptance of the resulting work. That lets you retry a failed analysis without accidentally repeating a write that already happened.
04 — PermissionsCarry the user boundary into background work
Review which identity supplies data and which identity performs actions. An event-triggered task may run when the initiating person is offline, so it needs a clear owner and a way to stop it. Test revocation before connecting sensitive material. Access should not survive merely because a queued task still holds an old instruction.
OpenAI also announced improved creation and discovery tools, plus Sites hosting for supported plugins on specified business and education plans. Those distribution paths do not eliminate the permission design of the underlying integration. A convenient installation flow and a correct authorization model are separate requirements.
Our dots guide covers persistent delegation, while the managed-runtime guide covers application-owned execution. The permission-default guide explains how to constrain both.
05 — The decisionChoose one event and one reviewable result
A useful first release supports a single event that prepares a draft or updates a reversible internal record. Check duplicate delivery, cancellation and account removal before adding external actions. Our AI transformation service helps define that end-to-end acceptance test.
06 — The failuresFour plugins that lost track of the user
A panel and an event each add a place where the user’s intent can be lost: the panel by holding state the chat does not know about, the event by starting work when the user is not there. The illustrative plugins below each lose it in one of those places. They are design examples, not deployed integrations.
The panel that disagreed with the chat
The agent says the draft has changed; the panel shows the previous version and no saved indicator. The user edits the panel, and the next agent action runs on the chat’s copy. Nobody decided which surface owned the current state.
The event as the authorisation
A subscription fires on a new support item and the plugin sends the reply. The event said something happened; it never authorised the response. Preparing a draft was within the subscription’s purpose, and sending it needed a separate rule.
The duplicate delivery
The same event arrives twice during a retry. The plugin treats each as new and performs a consequential action twice. Delivery acknowledgment and acceptance of the work were never separated, so the retry repeated a write.
The orphaned subscription
A user’s access is revoked. A queued task holding an older instruction still runs under the connection the next morning. Access survived because nothing checked it at the moment the work started.
Each failure is prevented by a line in the subscription record the next section describes, which exists so that the state, the owner and the stop are written down before the first event arrives.
Two of the four are visible to the user at once, because a panel that disagrees with the chat or a reply that was never authorised is noticed by the person it affects. The other two run in the background and are found later in the activity record, which is the harder case: a duplicate write or an orphaned task has done its work before anyone looks, and the only defence is the behaviour the record specifies in advance.
07 — The recordA subscription record in six fields
The delivery section asks the plugin to store enough information to identify a subscription, its owner and the action it can trigger, and six fields cover that and the rest of the guide. The subscription identity, with the list, subscribe and unsubscribe operations it was created through. The owner: which identity supplies the data and which performs the action, since an event-triggered task may run when the person is offline. The trigger: the defined change that starts work, written narrowly enough that a reviewer can tell whether a delivered event belongs to it. The permitted response and its boundary: what the task may prepare and what needs a separate rule, with the payload treated as task data rather than instructions. The cancellation and revocation behaviour: what stops when the user cancels, when access is revoked and when the account is removed, and how the work that cannot continue is explained. And the log: event identity, task identity and outcome, which the delivery section says is worth more in an incident than a generic failure message.
An illustrative record for a support-queue plugin reads: subscription created for one queue; owner, the support lead’s identity for data, a service identity for the draft action; trigger, a new item in that queue; permitted response, prepare a reply draft and save it to the item, with sending reserved to a human; cancellation, unsubscribe stops new drafts and revocation ends the connection, with an in-flight draft discarded and the item marked as not drafted; log, each event with its task and whether a draft was saved, skipped as a duplicate or abandoned.
The record is also the test plan the decision section asks for. Normal delivery, duplicate delivery, an invalid callback, cancellation, revoked access and interrupted work are each a case with an expected behaviour written in the record, and the first release should pass all six before a second event is added.
When a second event is added, the record is copied and the six fields are answered again for the new trigger, which keeps each subscription’s purpose narrow enough for a reviewer to check a delivered event against it.
A callback verified and associated with its subscription means an event arrived. The business task is accepted only when its result has been checked, and keeping the two apart is what lets a failed analysis be retried without repeating a write that already happened.
Prove the subscription lifecycle before expanding automation
Extensions can make work easier to inspect, and events can start it at the right moment. The reliable implementation keeps state, ownership and cancellation visible from the first event to the accepted result.