- JWT token — Context embedded in the signed token (requires secured flow). Best for stable, identity-related values.
- Instance methods (
pre:sendevent) — Context added dynamically per message (works with or without token signing). Best for values that change during the session.
System and custom variables
Context variables are either system variables or custom variables. System variables use the reservedwxo_ prefix and are populated automatically by the platform on every run. Custom variables are defined and supplied by your application. For details, see Types of context variables.Naming convention for context variables
Follow the standard naming rules for custom context variables. For details, see Naming rules.Scope and persistence
Context is scoped to a single run and is not persisted across turns in a thread. For details and persistence strategies, see Persisting context across turns.Channel support
Channels might not support context-variable propagation. For details, see Channel support.Setup
To use context variables:- Enable
context_access_enabled: truein your agent definition. - Add variables to the
context_variableslist in your agent definition file. - Reference these variables in your agent
instructionsby using curly brace syntax:{variable_name}. - Reimport the agent.
- Pass context variables by using one of the two following methods.
Agent Definition Example
- List all context variables in the
context_variablesarray - Reference them in
instructionsby using{variable_name}syntax - Instruct the agent not to ask users for these values since they’re provided automatically
- The agent can use these values when it calls tools or responds to users
Important naming conventions:
- Do NOT use the
wxo_prefix in your custom context variable names. This prefix is reserved for system variables. - If the same context variable name exists in both the JWT and the instance method (pre:send), the JWT value takes precedence over the
/runsAPI value. - To avoid conflicts, use different variable names for JWT context and dynamic context that is passed through instance methods.
Method 1: Context Variables - JWT Token
This method embeds context variables directly in the JWT token. It is suitable for stable, identity-related context that doesn’t change frequently, such as user ID, role, or organization ID.When to use JWT context:
- Fixed user identity information (user ID, role, department)
- Organization or tenant identifiers
- Permissions or access levels
- Any context that remains constant throughout the session
createJWT
Using the JWT token
After the JWT token generates, pass it to the embedded chat. The following example shows how to do that: You can check the examples for watsonx Assistant web chat that are mostly compatible with the watsonx Orchestrate embedded chat.JavaScript
Method 2: Context Variables - Instance Methods (pre:send event)
This method dynamically injects context variables into each message by using thepre:send event handler. It’s ideal for dynamic context that changes frequently or varies per message, such as current page, selected profile, or user input.
When to use instance method context:
- Dynamic values that change during the session (current page, selected item)
- User-specific data that varies per interaction (form inputs, selections)
- Profile or when switching persona within the same session
- Any context that needs to be updated without page reload
Simple Example: Basic context injection
The following example shows the simplest way to inject context variables into messages:Event choice: Use
pre:send instead of send for context injection. The pre:send event fires before the message is sent, helping ensure that context is included in the request. The send event fires after the message is already sent.Comparison: JWT vs Instance Method
Implementation guidelines
- Use distinct variable names for JWT-based context and instance method context to prevent naming conflicts.
- Avoid the
wxo_prefix in custom context variable names, as it is reserved for system-defined variables. - Use JWT-based context for stable data such as user identity, role, and organization.
- Use instance methods for dynamic data such as the current page, selections, or form input.
- Keep context minimal by passing only the data required for correct processing.
- Document all context variables in the agent definition to support long-term maintainability.
JWT size and header limits
When you use SSO/OBO connections with remote MCP toolkits, the platform propagates the user’s access token in a request header during tool execution. watsonx Orchestrate enforces an 8 KB per-header size limit as part of RFC 6585-compliant header validation. If the JWT contains many context variables, the resulting access token can exceed this limit, causing MCP tool calls to fail silently with an HTTP 500 error (underlying cause: HTTP 431 Request Header Fields Too Large). To avoid this, keep your JWT payload small. Include only the context variables the agent actually needs and remove internal system values, verbose metadata, or redundant identity provider fields. For troubleshooting steps, see MCP tool execution fails with HTTP 431.Example: Combined approach
- JWT provides stable identity context (
user_id,user_role,organization_id) - Instance method provides dynamic session context (
current_page,selected_product,form_data) - All variable names are unique to avoid conflicts

