Add run configuration inheritance for agent-as-tool workflows

[DanielHashmi]

Problem:
When using the "agents as tools" pattern, tool-agents create their own execution context but don't inherit the parent's run_config.

This creates two problems:
Tool-agents can't access the parent's global model configuration
If tool-agents don't have their own model field set and the parent's run_config.model is unavailable, model resolution fails entirely, causing the orchestrator to fail when calling the tool

Solution:
Modified the agent-as-tool execution to properly handle run_config inheritance while ensuring robust model resolution. This prevents execution failures when tool-agents lack explicit model configuration.

Changes

1. traces.py

• Added _run_config attribute to both NoOpTrace and TraceImpl classes
• Added TYPE_CHECKING import for RunConfig type annotation
• Enables storing run configuration in trace context for cross-agent access

2. run.py

• Enhanced trace context management to store run configuration
• Implements two-tier storage: metadata dictionary (preferred) or _run_config attribute (fallback)
• Ensures sub-agents can access original run configuration during execution

3. agent.py

• Added get_current_trace import from tracing module
• Enhanced as_tool() method to retrieve and inherit run configuration from trace context
• Passes inherited configuration to Runner.run() for consistent behavior

[seratch]

I am not sure what @rh-openai thinks but here are my initial thoughts on this:

• I see the need for some use cases but in general, setting the most suitable model for each agent would be recommended rather than sharing the parent's one (again, I hear the need though)
• I don' think passing via current trace is the best approach for this; enhancing in a more straight-forward way without breaking changes would be ideal

[rm-openai]

Yeah using the trace to store this data isn't right. What you could do instead, is use a ContextVar. So:

1. Add a pass_run_config_to_sub_agents: bool param to the RunConfig, just in case people want to enable/disable this behavior
2. Set the run_config context var from run.py
3. Read the run_config in the agent as tool
4. Also ensure that you add tests to make sure the contextvar is unset in all cases (errors, success, cancel etc)

I'm also not entirely sure if it makes sense to have this as part of the SDK, or just something you do. The approach I've taken to as_tool is that if you want customization, you can just create your own tool via:

@function_tool
def run_my_agent(input):
  my_agent = Agent(...)
  result = Runner.run(my_agent)
  return result.foo

[DanielHashmi]

Why This Feature is Needed

The RunConfig is designed to serve as a global configuration for the entire agent workflow. However, the current implementation breaks this contract when agents are used as tools, creating an inconsistent experience where:

1. Configuration Fragmentation: Global settings like model configuration, tracing preferences, and guardrails don't apply to sub-agents
2. Debugging Difficulties: Tracing and observability settings don't propagate, making it hard to debug complex agent hierarchies
3. Inconsistent Behavior: The same agent behaves differently when run directly vs. when used as a tool

This implementation addresses the OpenAI Agents SDK team's feedback to use ContextVar instead of storing configuration in traces, providing a clean, opt-in solution that maintains backward compatibility while enabling consistent global configuration across agent hierarchies.

Testing

Comprehensive test coverage includes:

• RunConfig inheritance when enabled/disabled
• Proper cleanup on errors and exceptions
• Direct API testing of Scope methods
• Integration testing with agent-as-tool workflows

This feature addresses a fundamental consistency issue in the SDK where RunConfig wasn't truly "global" due to the gap in agent-as-tool scenarios. The ContextVar approach recommended by you guys is actually great, But previously i didn't know how to do this,

I have tried my best and changes the code according to the recommended way.

If it still needs modification, tell me! I will try my best :)

[seratch]

It might be easy to add here since ContextVar is already imported in the source file. However, I don't think this is the best place to add it because the run config isn't specifically used for tracing. It's okay to add a new file, but personally, I think adding it to run.py should be fine in this case. Simply having get|set_current_run_config methods without Scope class should work.

[DanielHashmi]

I have updated the files :)