Roster for OpenAI
Use OpenAI models to resolve who should act.
Configure an OpenAI model as Roster's resolver to interpret workflow questions, identify the relevant participants, and produce structured, auditable answers.
Your deployment controls the OpenAI account, API credential, model, reasoning effort, and production approval process.
Last verified 07/13/2026
OpenAI interprets the question. Roster governs the answer.
Roster maintains the organizational context:
“Who should approve the Atlas vendor renewal for Europe?”
The OpenAI model helps Roster interpret natural-language requests. Roster remains responsible for assembling the authorized context, validating the model response, resolving the selected participants, and recording the request.
- Projects
- Participants
- Users and groups
- Directory membership
- Roles and labels
- Participant metadata
- Active delegations
- Access boundaries
The model does not replace Roster's participant model or authorization layer.
How the integration works
Roster prepares the authorized participant context, calls the OpenAI Responses API with a structured schema, and validates the returned selection before resolving active users, groups, roles, or delegates.
Agent, workflow, or application
↓
Roster Resolve
↓
Authorized project and participant context
↓
OpenAI Responses API
↓
Structured participant selection
↓
Active users, groups, roles, or delegatesWhy use OpenAI with Roster?
Configure OpenAI
OpenAI is Roster's default model-provider family.
OPENAI_API_KEY=<openai-api-key>
OPENAI_BASE_URL=https://api.openai.com/v1
ROSTER_MODEL_PROVIDER=openai
ROSTER_MODEL_NAME=gpt-5.6-sol
ROSTER_MODEL_EFFORT=lowOPENAI_BASE_URL is optional when using OpenAI's standard public endpoint. Set it only when your deployment uses an approved proxy, regional endpoint, or compatible model gateway.
Store the API key in your deployment secret manager or protected runtime environment. Do not commit it to source control.
Quality-first — recommended for complex, high-impact routing:
ROSTER_MODEL_NAME=gpt-5.6-solBalanced cost and quality — everyday production resolution:
ROSTER_MODEL_NAME=gpt-5.6-terraCost-sensitive and high-volume workloads — validate against representative data before high-impact routing:
ROSTER_MODEL_NAME=gpt-5.6-lunaDo not choose a model based only on general benchmark performance. Test it using the projects, participant structures, query patterns, ambiguity, and guardrails expected in your own deployment.
Reasoning effort — Roster accepts: none, minimal, low, medium, high, xhigh, max. Actual support is model-dependent. Use lower effort for straightforward, high-volume, latency-sensitive queries. Consider higher effort when multiple responsibilities may match, the query contains several constraints, or routing has financial, legal, security, or operational impact.
Example resolution
A procurement workflow asks:
“Who should approve the Atlas software renewal for Europe when the contract exceeds the regional threshold?”
- Roster identifies the authorized Atlas project context.
- Roster supplies relevant participants, labels, metadata, memberships, and delegations.
- Roster sends the structured resolution task to the configured OpenAI model.
- Roster validates the returned participant selection.
- Roster expands the selected participant into active users, groups, or delegates.
- Roster records the Resolve request and model run.
The workflow then uses its existing approval system to contact the selected participant. Roster resolves who should act — it does not send or enforce the approval itself.
Structured output and observability
Participant resolution is not ordinary conversational text generation. Roster needs responses that can be parsed reliably, validated against expected fields, connected to existing participant IDs, checked for unsupported selections, and audited after the request.
OpenAI Structured Outputs constrains responses to a defined JSON schema, reducing the risk of missing fields or invalid values. A successful API connection is not sufficient — the model must produce stable structured responses across Roster's expected Resolve workload.
Roster records provider, model name, run status, live or test mode, latency, input/output/total tokens, estimated cost, reasoning effort, Resolve request ID, provider request ID, trace identifiers, errors, and (subject to PII settings) input and output payloads. Administrators can use Model Runs to compare model choices and investigate latency, errors, cost, and resolution behavior.