[dotnet-port-api] agent-as-tool: session propagation and argument customization

[PratikDhanave]

Parity gap surfaced comparing tool/agenttool against .NET/Python.

Gap

agenttool hardcodes a single query string argument and runs the sub-agent with an independent context, returning only resp.String(). It cannot:

1. Propagate the parent session to the sub-agent (so a sub-agent-as-tool starts stateless every call).
2. Customize the argument name/description.

Note: the tool name/description defaults and the query arg name already match .NET (AgentExtensions.cs), so those are intentionally aligned — only session propagation and arg customization are missing.

Reference

• Python Agent.as_tool(arg_name="task", arg_description=..., propagate_session=..., ...) (_agents.py).
• .NET AsAIFunction(this AIAgent, options, session) accepts a session (AgentExtensions.cs).

Proposed shape (needs maintainer input)

Add optional config to the agenttool constructor, e.g.:

agenttool.New(a, agenttool.Config{
    ArgName:        "task",         // default "query" (matches .NET)
    ArgDescription: "...",
    PropagateSession: true,          // thread the caller's *agent.Session into the sub-run
})

Open questions:

1. How to obtain the caller session at Call time — thread it via context, or capture from the invoking run? (Go tool Call(ctx, argsJSON) has no session param today.)
2. Should session propagation be opt-in (default off, matching a stateless tool) or default on (matching Python's common usage)?
3. Whether to also surface sub-agent approval/user-input requests (Python raises UserInputRequiredException; .NET returns .Text — Go currently matches .NET).

Filing issue-first per CONTRIBUTING (new public API). Happy to implement once the direction is settled.

[PratikDhanave]

Investigated the session-propagation half. It needs new plumbing, not just an agenttool change:

• The agent is placed in the run context (agent.go ctx = context.WithValue(ctx, agentKey{}, a)), but the session is only passed via run options (agent.WithSession), and toolautocall reads it from those options.
• A tool.Tool.Call(ctx, args) receives only ctx and the JSON args — not the options, so there is no way for agenttool.Call to reach the caller's session today.

So propagating the session cleanly requires two coordinated changes: (1) expose the run session on the context (e.g. a public SessionFromContext + having toolautocall inject it into the ctx it passes to Call), and (2) have agenttool read it and forward WithSession to the sub-run. That's a cross-cutting change to the tool-calling contract, so it's worth settling the mechanism here before implementing. The argument-customization half is already done in #1157.