Clean up docs

Author: benbrandt

docs/docs.json

@@ -94,7 +94,6 @@
                   "protocol/v2/file-system",
                   "protocol/v2/terminals",
                   "protocol/v2/agent-plan",
-                  "protocol/v2/session-modes",
                   "protocol/v2/session-config-options",
                   "protocol/v2/slash-commands",
                   "protocol/v2/extensibility",
@@ -117,7 +116,6 @@
                       "protocol/v2/draft/cancellation",
                       "protocol/v2/draft/terminals",
                       "protocol/v2/draft/agent-plan",
-                      "protocol/v2/draft/session-modes",
                       "protocol/v2/draft/session-config-options",
                       "protocol/v2/draft/slash-commands",
                       "protocol/v2/draft/extensibility",

docs/protocol/v2/draft/overview.mdx

@@ -89,14 +89,6 @@ Agents are programs that use generative AI to autonomously modify code. They typ
   `agentCapabilities.auth.logout` capability).
 </ResponseField>
 
-<ResponseField
-  name="session/set_mode"
-  post={[<a href="./schema#session%2Fset-mode">Schema</a>]}
->
-  [Switch between agent operating
-  modes](./session-modes#setting-the-current-mode).
-</ResponseField>
-
 ### Notifications
 
 <ResponseField
@@ -181,11 +173,11 @@ Clients provide the interface between users and agents. They are typically code
   post={[<a href="./schema#session%2Fupdate">Schema</a>]}
 >
   [Send session updates](./prompt-turn#3-agent-reports-output) to inform the
-  Client of changes (no response expected). This includes: - [Message
-  chunks](./content) (agent, user, thought) - [Tool calls and
-  updates](./tool-calls) - [Plans](./agent-plan) - [Available commands
-  updates](./slash-commands#advertising-commands) - [Mode
-  changes](./session-modes#from-the-agent)
+  Client of changes (no response expected). This includes [message
+  chunks](./content), [tool calls and updates](./tool-calls),
+  [plans](./agent-plan), [available commands
+  updates](./slash-commands#advertising-commands), and [config option
+  updates](./session-config-options#from-the-agent).
 </ResponseField>
 
 ## Argument requirements

docs/protocol/v2/draft/session-config-options.mdx

@@ -3,14 +3,7 @@ title: "Session Config Options"
 description: "Flexible configuration selectors for agent sessions"
 ---
 
-Agents can provide an arbitrary list of configuration options for a session, allowing Clients to offer users customizable selectors for things like models, modes, reasoning levels, and more.
-
-<Info>
-  Session Config Options are the preferred way to expose session-level
-  configuration. If an Agent provides `configOptions`, Clients **SHOULD** use
-  them instead of the [`modes`](./session-modes) field. Modes will be removed in
-  a future version of the protocol.
-</Info>
+Agents can provide an arbitrary list of configuration options for a session, allowing Clients to offer users customizable selectors for things like modes, models, reasoning levels, and more.
 
 ## Initial State
 
@@ -263,20 +256,3 @@ This notification also contains the complete configuration state. Common reasons
 - Switching modes after completing a planning phase
 - Falling back to a different model due to rate limits or errors
 - Adjusting available options based on context discovered during execution
-
-## Relationship to Session Modes
-
-Session Config Options supersede the older [Session Modes](./session-modes) API. However, during the transition period, Agents that provide mode-like configuration **SHOULD** send both:
-
-- `configOptions` with a `category: "mode"` option for Clients that support config options
-- `modes` for Clients that only support the older API
-
-If an Agent provides both `configOptions` and `modes` in the session response:
-
-- Clients that support config options **SHOULD** use `configOptions` exclusively and ignore `modes`
-- Clients that don't support config options **SHOULD** fall back to `modes`
-- Agents **SHOULD** keep both in sync to ensure consistent behavior regardless of which field the Client uses
-
-<Card icon="gears" horizontal href="../session-modes">
-  Learn about the Session Modes API
-</Card>

docs/protocol/v2/draft/session-list.mdx

@@ -179,7 +179,7 @@ When no sessions match the criteria, the Agent **MUST** return an empty `session
 
 ## Updating Session Metadata
 
-Agents can update session metadata in real-time by sending a `session_info_update` notification via `session/update`. This follows the same pattern as other session notifications like [`available_commands_update`](/protocol/v2/draft/slash-commands) and [`current_mode_update`](/protocol/v2/draft/session-modes).
+Agents can update session metadata in real-time by sending a `session_info_update` notification via `session/update`. This follows the same pattern as other session notifications like [`available_commands_update`](/protocol/v2/draft/slash-commands) and [`config_option_update`](/protocol/v2/draft/session-config-options#from-the-agent).
 
 ```json
 {

docs/protocol/v2/draft/session-modes.mdx

@@ -184,8 +184,8 @@ Agent **MUST** respond to the original `session/load` request.
 }
 ```
 
-The response **MAY** also include initial mode, model, or session configuration
-state when those features are supported by the Agent.
+The response **MAY** also include initial session configuration state when that
+feature is supported by the Agent.
 
 The Client can then continue sending prompts as if the session was never
 interrupted.
@@ -261,8 +261,8 @@ session is ready to continue.
 }
 ```
 
-The response **MAY** also include initial mode, model, or session configuration
-state when those features are supported by the Agent.
+The response **MAY** also include initial session configuration state when that
+feature is supported by the Agent.
 
 ## Closing Active Sessions
 

docs/protocol/v2/draft/session-setup.mdx

@@ -89,14 +89,6 @@ Agents are programs that use generative AI to autonomously modify code. They typ
   `agentCapabilities.auth.logout` capability).
 </ResponseField>
 
-<ResponseField
-  name="session/set_mode"
-  post={[<a href="./schema#session%2Fset-mode">Schema</a>]}
->
-  [Switch between agent operating
-  modes](./session-modes#setting-the-current-mode).
-</ResponseField>
-
 ### Notifications
 
 <ResponseField
@@ -181,11 +173,11 @@ Clients provide the interface between users and agents. They are typically code
   post={[<a href="./schema#session%2Fupdate">Schema</a>]}
 >
   [Send session updates](./prompt-turn#3-agent-reports-output) to inform the
-  Client of changes (no response expected). This includes: - [Message
-  chunks](./content) (agent, user, thought) - [Tool calls and
-  updates](./tool-calls) - [Plans](./agent-plan) - [Available commands
-  updates](./slash-commands#advertising-commands) - [Mode
-  changes](./session-modes#from-the-agent)
+  Client of changes (no response expected). This includes [message
+  chunks](./content), [tool calls and updates](./tool-calls),
+  [plans](./agent-plan), [available commands
+  updates](./slash-commands#advertising-commands), and [config option
+  updates](./session-config-options#from-the-agent).
 </ResponseField>
 
 ## Argument requirements

docs/protocol/v2/overview.mdx

@@ -3,14 +3,7 @@ title: "Session Config Options"
 description: "Flexible configuration selectors for agent sessions"
 ---
 
-Agents can provide an arbitrary list of configuration options for a session, allowing Clients to offer users customizable selectors for things like models, modes, reasoning levels, and more.
-
-<Info>
-  Session Config Options are the preferred way to expose session-level
-  configuration. If an Agent provides `configOptions`, Clients **SHOULD** use
-  them instead of the [`modes`](./session-modes) field. Modes will be removed in
-  a future version of the protocol.
-</Info>
+Agents can provide an arbitrary list of configuration options for a session, allowing Clients to offer users customizable selectors for things like modes, models, reasoning levels, and more.
 
 ## Initial State
 
@@ -263,20 +256,3 @@ This notification also contains the complete configuration state. Common reasons
 - Switching modes after completing a planning phase
 - Falling back to a different model due to rate limits or errors
 - Adjusting available options based on context discovered during execution
-
-## Relationship to Session Modes
-
-Session Config Options supersede the older [Session Modes](./session-modes) API. However, during the transition period, Agents that provide mode-like configuration **SHOULD** send both:
-
-- `configOptions` with a `category: "mode"` option for Clients that support config options
-- `modes` for Clients that only support the older API
-
-If an Agent provides both `configOptions` and `modes` in the session response:
-
-- Clients that support config options **SHOULD** use `configOptions` exclusively and ignore `modes`
-- Clients that don't support config options **SHOULD** fall back to `modes`
-- Agents **SHOULD** keep both in sync to ensure consistent behavior regardless of which field the Client uses
-
-<Card icon="gears" horizontal href="../session-modes">
-  Learn about the Session Modes API
-</Card>

docs/protocol/v2/session-config-options.mdx

@@ -156,7 +156,7 @@ When no sessions match the criteria, the Agent **MUST** return an empty `session
 
 ## Updating Session Metadata
 
-Agents can update session metadata in real-time by sending a `session_info_update` notification via `session/update`. This follows the same pattern as other session notifications like [`available_commands_update`](./slash-commands) and [`current_mode_update`](./session-modes).
+Agents can update session metadata in real-time by sending a `session_info_update` notification via `session/update`. This follows the same pattern as other session notifications like [`available_commands_update`](./slash-commands) and [`config_option_update`](./session-config-options#from-the-agent).
 
 ```json
 {