Add tool approval middleware for HITL parity

[George Adams (gdams)]

Summary

Adds a toolapproval middleware package for .NET ToolApprovalAgent parity, closing the primary Human-in-the-Loop gap identified in the feature comparison.

New: agent/middleware/toolapproval

• Implements the .NET ToolApprovalAgent pattern as idiomatic Go middleware
• One-at-a-time surfacing: When the inner agent returns multiple approval requests, only the first is surfaced to the caller; the rest are queued in session state
• Standing rules ("don't ask again"): Callers can respond with AlwaysApproveToolResponse() or AlwaysApproveToolWithArgsResponse() to create rules that auto-approve matching future tool calls for the session lifetime
• Auto-approve loop: When all approval requests match standing rules, the middleware automatically approves them and re-calls the inner agent without surfacing anything to the caller
• Session persistence: Rules, queued requests, and collected responses are persisted across turns via agent.Session

Changes to message package

• Added AlwaysApproveTool and AlwaysApproveToolWithArgs fields to FunctionApprovalResponseContent
• Added AlwaysApproveToolResponse() and AlwaysApproveToolWithArgsResponse() convenience methods on FunctionApprovalRequestContent

Tests

• Passthrough (no approval requests)
• First request surfacing with queuing
• Always-approve tool rule creation and auto-approval
• Queued requests surfaced one at a time
• AlwaysApproveToolWithArgs response creation

[Copilot]

Cross-repo Parity Review — toolapproval middleware

This PR successfully fills the primary HITL gap and the overall logic (one-at-a-time surfacing, standing rules, queued drain, auto-appr...

Addressed in 72df83e (with follow-up nits in 07b6d7f and 8dc0de1). I switched always-approve to a dedicated wrapper content type (AlwaysApproveToolApprovalResponseContent) that middleware unwraps before forwarding, added AlwaysApproveToolWithArgumentsResponse, and made tool+args rule matching order-independent by canonicalizing JSON arguments before comparison.

[github-actions]

Generated by Go API Consistency Review Agent for issue #138 · ● 704.8K

[Quim Muntal (qmuntal)]

Looks good! Some minor comments,

[George Adams (gdams)]

Copilot linter failures

[Copilot]

Copilot linter failures

Fixed in acd2ffe. I traced the failing workflow run (25461521092) and addressed the gofumpt error by grouping the toolapproval constants into a single const block.

[George Adams (gdams)]

Copilot resolve this merge conflict

[github-actions]

Cross-Repo Consistency Review

Summary

The core toolapproval middleware concept is consistent with upstream .NET — ToolApprovalRequestContent and ToolApprovalResponseContent are first-class types in the .NET AIAgentHostExecutor (see dotnet/src/Microsoft.Agents.AI.Workflows/Specialized/AIAgentHostExecutor.cs), and the Go middleware correctly wraps them. No Python equivalent was found.

Parity Gap: AlwaysApproveToolApprovalResponseContent and standing rules

The new AlwaysApproveToolApprovalResponseContent type (exported from message) and the standing-rules pattern (always-approve-tool / always-approve-with-args) introduced in this PR have no counterpart in the upstream .NET or Python implementations. The .NET AIAgentHostExecutor surfaces ToolApprovalRequestContent and ToolApprovalResponseContent to the workflow graph for routing, but does not expose any "don't ask again" / standing-rule mechanism on those types.

This is a new public Go type exported from the message package:

type AlwaysApproveToolApprovalResponseContent struct {
    AlwaysApproveTool              bool
    AlwaysApproveToolWithArguments bool
    InnerResponse                  *ToolApprovalResponseContent
}

And new public methods on ToolApprovalRequestContent:

• AlwaysApproveToolResponse() *AlwaysApproveToolApprovalResponseContent
• AlwaysApproveToolWithArgumentsResponse() *AlwaysApproveToolApprovalResponseContent
• AlwaysApproveToolWithArgsResponse() (deprecated alias)

Recommendation: Since this is a meaningful public API extension that isn't present in .NET or Python, the upstream team should be aware so they can decide whether to add an analogous standing-rule concept to the other SDKs. If this is intentionally a Go-first feature, that intent should be documented in the PR/commit.

Other observations

• The Config struct is exported but empty — this appears intentional for forward-compatibility and is reasonable.
• The session-based state persistence approach (agent.Session) is the correct Go idiom and is semantically equivalent to how .NET persists this state during workflow checkpointing.
• No example was added in examples/ for the new middleware, while .NET has samples in dotnet/samples/ for the HITL pattern. Consider adding a usage example for consistency.

Generated by Go API Consistency Review Agent for issue #138 · ● 2.1M · ◷