[FEATURE] Allow tools to access main event loop resources

[charles-dyfis-net]

Problem Statement

Strands' current async->sync wrapper executes tools on a separate event loop, so they cannot access resources bound to the application's main loop -- cached tasks, preexisting httpx.AsyncClient instances, and other awaitables that were initialized there.

Proposed Solution

Either:

• Enable greenback as an explicitly-supported optional dependency, using it in favor of the current approach if-and-only-if (a) greenback is installed, and (b) greenback.ensure_portal() has been called to initialize it; or
• Provide a supported, non-monkeypatching extension point for application authors to supply their own async→sync wrapper.

Use Case

Integrating Strands into a larger async-native application where tools need access to resources (HTTP/database/other natively-async client connection pools, cached coroutines, etc.) that are bound to the main event loop and cannot be accessed from a secondary loop.

Alternatives Solutions

No response

Additional Context

No response

[zastrowm]

Would you have a code sample that helps demonstrates what you're seeing; we've been making incremental improvements in this area so I want to ensure that we understand the prolbme.

Strands' current async->sync wrapper executes tools on a separate event loop

I believe though I'm not 100% certain that this only occurs for tools that are defined synchronously; for tools that are defined asynchronously, it should inherit the event loop - Are you seeing this behavior for asynchronous tools or synchronous tools (or both)?

[charles-dyfis-net]

I have a proposed fix that's half-assembled (will be PRing it shortly).

For what it's worth, I actually ran into this implementing a session manager, not a tool -- the database I was trying to connect is attached through a purely async library, and the session-manager interface being natively synchronous meant a bridge was needed. Looking at how strands already does that bridging led me to look at _async.py, and thus to the concerns about being able to use the preexisting connection bound to the main event loop.

Anyhow -- does the attached (admittedly artificial) test help?

demo_event_loop_issue.py

[zastrowm]

I have a proposed fix that's half-assembled (will be PRing it shortly).

For what it's worth, I actually ran into this implementing a session manager, not a tool -- the database I was trying to connect is attached through a purely async library, and the session-manager interface being natively synchronous meant a bridge was needed. Looking at how strands already does that bridging led me to look at _async.py, and thus to the concerns about being able to use the preexisting connection bound to the main event loop.

Anyhow -- does the attached (admittedly artificial) test help?

demo_event_loop_issue.py

Not exactly - I'm trying to tease out when using an Agent & executing tools, where this statement is true:

Strands' current async->sync wrapper executes tools on a separate event loop, so they cannot access resources bound to the application's main loop -- cached tasks, preexisting httpx.AsyncClient instances, and other awaitables that were initialized there.

For example this works as I expect:

from strands import tool, Agent
from strands._async import run_async
import asyncio

class LoopBoundHttpClient:
    """Simulates an httpx.AsyncClient or similar async resource.

    Real async clients often store a reference to their creation loop and validate
    that they're being used from the same loop, or have internal state (connection
    pools, pending requests) that's tied to a specific event loop.
    """

    def __init__(self):
        self._loop = asyncio.get_running_loop()
        self._request_count = 0

    async def get(self, url: str) -> dict:
        current_loop = asyncio.get_running_loop()
        if current_loop is not self._loop:
            raise RuntimeError(
                f"Client created on loop {id(self._loop)}, "
                f"but called from loop {id(current_loop)}. "
                "Cannot use async client from a different event loop."
            )
        self._request_count += 1
        await asyncio.sleep(0)  # Simulate I/O
        return {"url": url, "status": 200, "request_num": self._request_count}


client = LoopBoundHttpClient()

@tool
async def example_tool(url: str):
    return await client.get(url)

@tool
def example_tool_sync(url: str):
    return run_async(lambda: client.get(url))

agent = Agent(tools=[example_tool])
await agent.invoke_async("Invoke example_tool with google homepage")

This does fail for:

agent = Agent(tools=[example_tool_sync])
await agent.invoke_async("Invoke example_tool with google homepage")

But that's because synchronous functions are invoked on a background thread - the solution here is to use an async function as the tool though.

[charles-dyfis-net]

Thank you for spending the time to dig in -- that makes sense! I was overextrapolating from the session-manager interface (which is synchronous-only) to the tool-calling interface.