[Bug]: Generated demo agent mis-aggregates grounded query results and preserves incorrect prompt assumptions

### File Name

search/gemini-enterprise/ge-demo-generator/agent_template/adk_agent/app/

### What happened?

I reproduced a semantic aggregation / grounding issue in a retail operations agent generated by the Gemini Enterprise Demo Generator.

The underlying BigQuery query executed correctly and returned the authoritative inventory data, but the generated natural-language summary introduced incorrect counts and also preserved an incorrect assumption from the user prompt.

The demo dataset contained:

- 20 stores
- 80 inventory records
- 20 inventory records below the configured safety threshold
- 14 of those critical records associated with perishable products

The authoritative category/perishability breakdown for the 20 critical records was:

Beverage Concentrate / non-perishable: 3
Beverage Concentrate / perishable: 5
Dairy & Plant Based / perishable: 4
Fresh Food / perishable: 5
Whole Bean Coffee / non-perishable: 3

Total critical records: 20
Total perishable critical records: 14

I then asked the generated agent to run an inventory safety / stockout scan.

The prompt itself referenced "all 12 district locations", but the actual generated demo dataset contained 20 stores.

The agent successfully queried BigQuery and identified 20 critical inventory records.

However, the response then summarized the result incorrectly. It reported values including:

- 20 critical records
- only 3 stores affected
- 11 perishable items

It also presented a heading referring to 8 SKUs while rendering 9 rows.

The execution log showed that the query itself included the relevant product category and is_perishable fields, so the error occurred after the data retrieval step, in the interpretation / summarization layer.

Actual behavior:

The generated agent can retrieve the correct authoritative rows but then produce a natural-language aggregation that does not match the retrieved result set.

It can also continue using a user-provided numerical assumption such as "12 district locations" instead of correcting it from the authoritative dataset, even when the agent has already queried and discovered the actual store count.

Expected behavior:

When structured data is available from an authoritative tool result, the generated agent should derive counts and summaries directly from that result rather than estimating or re-counting them in free-form natural language.

If the user prompt contains a factual assumption that conflicts with authoritative retrieved data, the agent should explicitly correct it.

For example:

"The prompt mentions 12 locations, but the current dataset contains 20 stores. I used all 20 stores for this scan."

For aggregate outputs, the response should preserve deterministic relationships between:

- returned row count
- distinct store count
- perishable/non-perishable count
- category totals
- rendered table row count
- summary headline counts

A useful safeguard would be to calculate aggregates programmatically from the structured result and pass those values into the response rather than asking the language model to independently infer them from raw rows.

Why this matters:

The retrieval/tool layer can be functioning correctly while the customer-facing response still communicates incorrect operational metrics.

This is particularly problematic in demo scenarios because it can make a correctly grounded BigQuery integration appear unreliable.

It also means that manually correcting the current response does not solve the issue for future demos generated from the same reusable agent template.

I validated this by comparing the generated agent response with the actual BigQuery result set and the category/perishability breakdown from the authoritative demo dataset.

Reported and reproduced by:
Nilden Tutalar
Cloud Solution Architect - Cloud4Next
Contact: nilden.tutalar@cloud4next.com

### Relevant log output

```shell
Authoritative demo dataset:

stores:
20

inventory records:
80

critical / below safety threshold:
20

Critical records by category and perishability:

Beverage Concentrate | is_perishable = NO | 3
Beverage Concentrate | is_perishable = YES | 5
Dairy & Plant Based | is_perishable = YES | 4
Fresh Food | is_perishable = YES | 5
Whole Bean Coffee | is_perishable = NO | 3

Total critical:
20

Total perishable critical:
14

User prompt assumption:
"all 12 district locations"

Generated response included:
20 critical records
3 stores affected
11 perishable items

The response also contained a heading referring to 8 SKUs while displaying 9 rows.

The BigQuery execution itself returned the relevant structured fields, including product category and is_perishable.

Observed failure point:
post-query semantic aggregation / natural-language summarization
```

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Start in search/gemini-enterprise/ge-demo-generator/agent_template/adk_agent/app/ and reproduce the inventory safety scan, comparing the generated response with the authoritative BigQuery result and execution log. Trace the post-query aggregation and summarization path; done means counts, distinct stores, category/perishability totals, and rendered rows agree with the retrieved data, and conflicting location assumptions are explicitly corrected.

Written by the indexing model from the issue text.