Event-triggered AI workflows need a recovery plan

Many business workflows begin with somebody noticing that something happened.

A new enquiry arrives. A support ticket changes status. A project task is assigned. A customer comments on a document. Until a person or scheduled process checks the system, the next step waits.

OpenAI's support for MCP Events gives connected apps a way to notify ChatGPT when a relevant event happens. That can remove monitoring and polling from a useful workflow. It does not make the workflow reliable by itself.

An event is only the starting signal. The business still needs to decide how the system verifies that signal, handles duplicates and delays, recovers missed work, protects customer information and keeps a person responsible for consequential actions.

What changed on 29 September 2026

On 29 September, OpenAI announced support for MCP Events in its DevDay recap. The company says a plugin can start an automation when something happens in a connected app, such as a new task appearing in a project tool. The announcement describes the capability as available across plans.

The current OpenAI MCP Events documentation places the experience inside Work chats on ChatGPT web, the desktop app with Cloud selected, and dots. Workspace controls still apply. A business therefore needs to confirm that the relevant plugin, chat surface and workspace settings are available before treating the announcement as an implementation commitment.

The technical change is more substantial than a new notification setting.

A plugin server using the MCP 2.0 protocol can expose event types, accept authenticated subscriptions and deliver signed webhooks to a verified HTTPS callback. It must store subscription state, preserve the event identifier across retries and recheck that the connected account still has access to the event.

OpenAI is implementing part of a draft MCP Events proposal. The current ChatGPT integration does not support the proposal's polling, streaming, gap notification or terminated notification methods. The announcement makes the capability usable, but it does not make the wider protocol final or every delivery mode portable between vendors.

That distinction matters for a business deciding how much of an operational process to place on top of it.

Why this matters to a smaller business

Polling is a common hidden cost in automation.

A scheduled process may ask a system for changes every few minutes even when nothing happened. A person may keep checking an inbox, project board or CRM. Both approaches create delay. Frequent polling can also increase API usage and produce awkward logic for deciding which records are genuinely new.

An event can start the next step closer to the moment the work arrives.

That can be useful when a team repeatedly needs to:

• prepare an initial summary when a qualified website enquiry arrives;
• collect the right context when a support request changes priority;
• draft an internal update when a project task reaches a defined state;
• notify an owner when a customer document receives a new comment;
• prepare a review pack when an approved record changes.

The strongest candidates are stable, repetitive processes with a clear owner and a measurable delay. A process that changes every week, has no agreed next step or depends on undocumented judgement is not ready simply because it now has an event source.

This is where AI Workflow Development should begin: clarify the work first, then decide whether an event, conventional automation or AI assistance belongs in it.

An event solves the wait, not the workflow

The event should usually say that something relevant changed. It should not be treated as the complete, authoritative business record.

A maintainable workflow can use the event to identify the source record, retrieve the minimum current information from the connected system, check whether the record still qualifies, then prepare a bounded output for review.

For example, a new enquiry event might start this sequence:

1. Verify the event source and connected account.
2. Retrieve the enquiry and its current status from the customer system.
3. Check that it has not already been processed.
4. Ask AI to classify the request and prepare a draft summary.
5. Show the source, classification and draft to the responsible person.
6. Record the person's decision and the final outcome.

The AI role is narrow. It interprets language and prepares context. Authentication, state, routing, approval and recovery remain normal system responsibilities.

A useful AI Integration keeps those responsibilities visible instead of hiding the whole process inside one prompt.

Start with one event and one draft output

Do not begin by subscribing to every event a connected system can produce.

Choose one event with a clear business meaning. Define the filter as narrowly as the source allows. Decide what output would save time without making an irreversible decision.

A sensible first pilot might prepare a draft triage note for a new enquiry that meets defined conditions. It should not send a customer response, change an opportunity stage and assign paid work at the same time.

Before implementation, record the current baseline:

• how often the event occurs;
• how long the team waits before noticing it;
• how much time the first review takes;
• which errors or missed handoffs occur;
• what information a reviewer needs;
• what the current process costs to operate.

This gives the business something more useful than a successful demonstration. It provides evidence about whether the event driven workflow improves response time, consistency or effort after review and exception handling are included.

Design for duplicate and out-of-order events

OpenAI's documentation requires each event to have a unique event identifier that remains the same when delivery is retried. It also warns that events may arrive out of order.

Both conditions are normal in distributed systems.

If the receiving workflow creates a task, sends a message or updates a customer record every time it sees a delivery, one retry can create duplicate business actions. If an older status event arrives after a newer one, the workflow can move a record backwards.

The receiver should store the event identifier and make each write idempotent. In practical terms, processing the same event twice should have the same business effect as processing it once.

The workflow should also retrieve current source state before acting where order matters. It can compare a source version, timestamp or status transition, then ignore stale events or send ambiguous cases to review.

This logic belongs outside the model. A prompt should not be responsible for remembering every event that the system has already processed.

Decide how missed events are found

Reliable delivery and complete recovery are different promises.

The current ChatGPT integration does not support polling or explicit gap notifications. The draft protocol allows a source to provide a cursor for replay, but a source can return a null cursor when missed events cannot be recovered.

A business should know which case applies before the workflow becomes operationally important.

Ask:

• Is the subscription stored across server restarts?
• How does it expire and renew?
• Can the source replay events from a saved cursor?
• What happens when history is no longer available?
• How will the business detect that an expected event never arrived?
• Who owns the queue when automatic recovery is not possible?

For an important process, add a reconciliation path outside the AI step. That may be a scheduled comparison with the source system, a daily exception report or a visible queue that a person can review.

The fallback does not need to be elaborate. It needs to make silent loss less likely.

Verify the source, identity and permissions

OpenAI's implementation requires HTTPS callback verification and signed webhook delivery. The setup challenge must be fresh and single use, and callback verification should not follow redirects or connect to private network addresses. Each subscription also needs to remain tied to the authenticated account and authorised event filter.

These controls help prove where a delivery came from. They do not prove that the content inside it is safe or correct.

An event may refer to a customer message, document comment or ticket containing hostile instructions aimed at the AI. The MCP proposal treats event data as untrusted. The plugin's tool calls should enforce permissions and validate inputs even when the text tries to change the workflow.

Use a dedicated identity where the connected system supports it. Grant only the read and write permissions needed for the pilot. Recheck access when events are delivered, revoke subscriptions when an account disconnects and log the event, tool calls and approval outcome without copying unnecessary personal information.

The existing guide to technical boundaries for AI agent pilots explains the wider permission, tool and network controls that become important once a workflow can touch live systems.

Keep consequential actions approval gated

An event can make work begin sooner without making the final decision automatic.

Keep a person responsible before the workflow sends an external reply, publishes content, changes a customer or financial record, commits spend, deletes information or makes another action that is difficult to reverse.

The approval should show:

• what event started the workflow;
• the authoritative source record;
• the AI output and any uncertainty;
• the proposed action and affected system;
• what will happen after approval;
• how to reject, correct or defer the action.

This is more useful than a generic confirm button. It lets the reviewer judge the proposed outcome rather than approve a hidden chain of automation.

Lower risk steps may earn more autonomy after the business has measured reliable performance. The first pilot should create that evidence, not assume it.

Privacy, cost and maintenance still need owners

Events can encourage systems to send more context than the next step needs.

Prefer a small event payload with identifiers and essential routing fields, then retrieve the current record only when authorised and necessary. Avoid placing full customer messages, documents or sensitive fields into every notification simply because the format allows it.

The OAIC's guidance on commercially available AI products recommends due diligence, privacy by design, human oversight and ongoing review. A business handling personal information should assess purpose, access, processing location, retention and disclosure, then obtain appropriate privacy or legal advice where its obligations are unclear.

Cost also extends beyond model usage. Include plugin hosting, callback infrastructure, source API charges, logs, monitoring, retries, human review and maintenance when comparing the pilot with the current process.

Give the subscription lifecycle an owner. Someone needs to respond when credentials expire, permissions change, the source alters an event schema or the platform changes its supported protocol. Test after upgrades and keep the event contract, workflow states and recovery rules documented outside one vendor's interface.

That documentation also reduces lock in. The protocol is still a draft, and OpenAI currently supports a subset. The business should be able to replace the event transport or model without rediscovering the operational decision behind the workflow.

A practical pilot path

For most businesses, the next step is a bounded operational test:

1. Choose one stable, repetitive process with a clear owner.
2. Record its current time, cost, error rate or response delay.
3. Subscribe to one narrowly filtered event and retrieve only the necessary source information.
4. Give AI a bounded role, beginning with classification, a summary or a draft.
5. Keep human approval for consequential actions and exceptions.
6. Test duplicate, delayed, out-of-order and invalidly signed events.
7. Test restarts, expired subscriptions, revoked access and a period of missed delivery.
8. Measure the complete result, including corrections, review time, recovery effort and operating cost.

Also test for feedback loops. If the workflow updates the same system that produced the event, make sure its own change cannot trigger an endless cycle.

Expand only after the process remains understandable under these conditions.

The next decision

MCP Events can remove waiting from a useful workflow. The important question is not whether AI can start when something happens.

It is whether one business event can become one verified, reviewable and recoverable outcome.

If the answer is not yet clear, start with the process and its failure modes. AI Business Automation can help identify the repeated work and the smallest useful implementation. When the decision spans several systems, vendors or operational risks, a Fractional Technical Partner can help define what to connect, what to keep human and what needs a recovery path before launch.