Feature request: Add a dedicated event role to Chat Completions

API Feedback
1

Feature Request: Add a dedicated event role to Chat Completions

I would like to request a new first-class message role for externally generated application events, such as event or system_event, in the Chat Completions API.

Problem

Today, an application may have more sources of context than just a human user, the assistant, or a tool call.

For example, consider an inventory-management application:

  1. A user is chatting with an inventory-management agent.
  2. A background service continuously monitors inventory.
  3. The service detects that a product has fallen below its minimum stock level.
  4. The application wants to wake up the agent and have the agent proactively notify the user.

The event is not actually a user message, and it is not a developer instruction.

For example:

{
  "type": "inventory_low",
  "product": "iPhone 15",
  "current_stock": 2,
  "minimum_stock": 10
}

Currently, an application might represent this as:

{
  "role": "user",
  "content": "Inventory alert: iPhone 15 has only 2 units remaining. Minimum stock is 10."
}

But semantically, this is misleading. The user never said this. It came from an autonomous background service.

Proposed solution

Add a dedicated role such as:

{
  "role": "event",
  "content": {
    "type": "inventory_low",
    "product": "iPhone 15",
    "current_stock": 2,
    "minimum_stock": 10
  }
}

The model could then understand the distinction between:

  • user → something explicitly provided by the human
  • assistant → something previously generated by the model
  • developer / system → application-level instructions and behavior
  • tool → results from a tool invocation
  • event → an externally generated application event that may require the agent to react

Why this would be useful

This pattern is not limited to inventory systems. Many agentic applications have asynchronous events such as:

  • inventory.low_stock
  • order.shipped
  • payment.failed
  • delivery.delayed
  • subscription.expiring
  • security.alert
  • calendar.event_starting
  • monitoring.threshold_exceeded
  • customer.status_changed

These events are fundamentally different from user messages.

A dedicated role would allow developers to maintain a much more semantically accurate conversation history and would make event-driven agents easier to build.

Desired behavior

For example:

User:
How much stock do we have for iPhone 15?

Assistant:
You currently have 15 units.

Event:
iPhone 15 stock has dropped to 2 units.
Minimum stock is 10 units.

Assistant:
The iPhone 15 inventory is now low. There are only 2 units remaining, while the minimum required stock is 10 units.

The key point is that the Event should be understood as external application state, not as something the user said.

Alternative

If introducing a new top-level role is undesirable, another possibility would be a first-class message type/source field, for example:

{
  "role": "user",
  "source": "application_event",
  "event_type": "inventory_low",
  "content": "..."
}

However, I believe a dedicated event role would provide the clearest semantic model for event-driven and proactive agents.

This would be especially valuable for applications where background services need to trigger an agent without pretending that the human user initiated the interaction.

2

Welcome to the dev forum @AkhilmsAchu

Chat Completions is a legacy API. The Responses API, its current successor is the one that is recommended for implementing agentic workflows.

The event role type seems like a nice feature request.

3

On Chat Completions, you can use the "name" field alongside role, something lacking on Responses (which along with other missing support, makes it not a successor), text which is passed to the AI model.

name will likely fulfill your further need to have the speaker or author of a turn of input.

“Would require the agent to react”? When you make an API call, generating output language is the “react”.

4

Thanks for explaining the distinction. We'll share the request for a dedicated application-event role with the API team. The existing name field can label participants, but it isn't the event type you're asking for. No timeline to share.