Multi-Agent Orchestration: Missing Tool Execution Details in Evaluation + SQL Tool Parameter Matching Issues

[sivakumar-d3v]

Hi team,

I’m working with a multi-agent orchestration setup using Google ADK:

• Root agent: CloudOpsCoordinator
• Agent as tool: BillingAgent
• BillingAgent itself uses an internal tool (SQL executor) to query billing tables.

🧩 Issue 1 — Evaluation Missing Tool Execution Inside Child Agent

In the Events → Request/Response panel, I can see:

• The root agent invoking the BillingAgent as a tool
• The BillingAgent’s own reasoning + LLM call

However, I cannot see the tool execution that is triggered inside the BillingAgent—specifically:

• The request payload sent from BillingAgent → SQL tool
• The SQL tool invocation details
• The intermediate outputs

When I run an Evaluation Set, only the Root Agent to BillingAgent tool call is captured.
But the tool call inside BillingAgent is completely missing, which means the evaluation cannot test the full agent execution cycle for a user query.

👉 Question:
Is this expected behavior?
How can we capture and evaluate nested tool calls (tool triggered by another agent) during evaluation?
Without this, we cannot test the complete agent workflow end-to-end.

Screenshot for reference

---

🧩 Issue 2 — Tool Parameter Exact Matching During Evaluation

My BillingAgent uses a tool that executes SQL queries.

But in evaluation docs I can see:

• The evaluator compares exact SQL text or exact parameter match.
• Agent-generated SQL may vary in ordering, whitespace, or alias naming.
• Even if the SQL is semantically correct, the evaluation marks it as Fail because the tool parameters are not an exact match.

👉 Question:
How can I configure evaluation to allow flexible SQL generation instead of requiring an exact string match?
Is there a way to:

• Provide a semantic SQL matcher
• Allow partial match / fuzzy match on tool parameters?

Right now, evaluation always fails for these scenarios because the SQL is not identical.

---

🙏 Looking for Guidance

Would really appreciate direction on:

1. How to enable visibility + evaluation of nested tool calls inside sub-agents.
2. How to relax SQL parameter matching in evaluations for more realistic testing.

Thanks!

[klateefa]

@sivakumar-d3v Thank you for reporting this. I understand the request is currently under review. Please keep me posted if anything else is needed. Thanks for your patience.

[ryanaiagent]

Hi @sivakumar-d3v,

Issue 1

Yes, to an extent. When an agent is invoked strictly as a tool by a Root Agent, the ADK default behavior often treats the child agent as a "black box" function. The Root Agent observes the input (the query sent to BillingAgent) and the output (the final text response), but the internal trajectory (SQL execution) is encapsulated within the child agent's execution scope.

Solution

1. Enable verbose debugging
Ensure you pass verbose=True when running your debug session:

await runner.run_debug("Query", verbose=True)

2. Inspect Intermediate Data in Evaluation
The evaluation system is designed to capture multi-agent progress. Specifically, the Invocation object contains an intermediate_data field.

This field holds IntermediateData, which includes:

• tool_uses: The chronological list of tool calls.
• tool_responses: The outputs from those tools.
• intermediate_responses: Responses generated by sub-agents.

Action: When analyzing your EvalCaseResult, do not look only at final_response. You must inspect invocation.intermediate_data to find the nested SQL tool usage trajectory.

---

Issue 2

1. Use Specialized SQL Testing Tools

you can integrate external tools designed for this specific purpose:

• GoogleSQL: Use this to generate SQL queries that support different ordering, whitespace, or alias names, allowing for more flexible generation comparisons.

2. Abstract SQL into Typed Tools (Recommended Pattern)

If exact SQL matching is failing due to syntax variations, the code samples suggest wrapping raw SQL logic into specific, parameterized Python functions.

• How it works: Instead of exposing a generic execute_sql tool where the agent writes the full query, create a specific tool like count_rows_in_table or search_hotels_by_name.
• Benefit: The evaluator then matches the structured arguments (e.g., table_name='products') rather than a complex SQL string. This eliminates failures caused by whitespace or alias differences.
• Example: Instead of letting the agent generate SELECT COUNT(*) FROM table1, define a tool that generates the template internally:

[adk-bot]

This issue has been automatically marked as stale because it has not had recent activity for 7 days after a maintainer requested clarification. It will be closed if no further activity occurs within 7 days.