docs: clarify agent tool state options

[william-xue]

What

Clarify that agent.as_tool() state options such as session, previous_response_id, and conversation_id apply to the nested agent run started by the tool call.

Why

This avoids confusion about whether nested tool-agent state is shared with the parent run, and points readers back to the same state-management choices used with Runner.run.

Test

• git diff --check
• Checked docs/tools.md contains the new note and keeps the structured-input sentence.

[seratch]

Thanks for adding this clarification. The state options do configure the nested Runner invocation and are not inherited automatically from the parent run.
However, the current statement that they "are not shared" is too absolute. Passing the same Session to the parent run and agent.as_tool(...) is an intentional supported workflow; #1550 added per-turn persistence specifically for this agent-as-tool use case.
Please revise the paragraph to say that parent conversation state is not inherited automatically, while noting that callers can explicitly pass the same session when shared client-managed history is desired. The guidance to avoid mixing client-managed sessions with server-managed continuation should remain.

[seratch]

Suggested change

The state options apply only to the nested agent run started by the tool call; they are not shared with the parent run's conversation state. Choose the same kind of state you would use with `Runner.run`: either client-managed `session` history, or server-managed `previous_response_id` / `conversation_id`, not both for the same nested run. For advanced orchestration (for example, conditional retries, fallback behavior, or chaining multiple agent calls), use `Runner.run` directly in your tool implementation:

The state options configure the nested agent run started by the tool call; the parent run's conversation state is not inherited automatically. To share client-managed history between the parent and nested runs, explicitly pass the same `session` to both. As with `Runner.run`, choose one state strategy for the nested run: a client-managed `session`, or server-managed continuation through `previous_response_id` or `conversation_id`.