Structured Data Query Agent Family

One pattern, four engagements: natural-language agents over the spreadsheets that government programme offices actually run on - where the engineering value was recognising a repeatable asset and hardening it, rather than rebuilding four times.

1. The recurring problem

Across four separate engagements - a city-development commission’s programme office, a government entity’s use-case repository, a capital-markets authority’s programme office, and a portfolio-monitoring engagement - the same situation appeared:

The organisation’s real operating data lived in a large multi-sheet Excel workbook, maintained by hand, cross-linked, and undocumented. Leadership questions were straightforward in English and painful in practice: who are the top owners by project count? what are the upcoming priorities for this function? how does status break down by entity? which initiatives are behind?

Answering meant a human opening the workbook and building a pivot table. Every time.

2. The pattern I converged on

Tools-only grounding - the non-negotiable

The agent answers exclusively through tools and never from model memory. Schema and unique values are fetched before any filter is constructed. This is the single most important design decision, because it eliminates the characteristic failure mode of LLMs over structured data: confidently filtering on a category value that does not exist, and returning an authoritative-looking empty or wrong result.

If the agent cannot ground an answer in a tool result, it doesn’t answer.

Aggregation as a first-class tool

Beyond filtering and lookup, the agents expose explicit group-by aggregation - entity scorecards, rankings, distribution summaries. This matters because the questions leadership actually asks are aggregate questions, and expecting a model to synthesise a correct count from a list of returned rows is asking it to do arithmetic it will occasionally get wrong. Aggregation happens in code; the model orchestrates and narrates.

Multi-sheet awareness with a primary focus

Workbooks contain a few sheets that matter and many that are scaffolding. The agents focus on the designated primary sheets while keeping others discoverable through tools, rather than flattening everything into one undifferentiated table.

Supplementary external context

Where useful, a web-search tool lets the agent combine internal programme data with external context (for example, sector trends relevant to a transport programme) - clearly separated from grounded internal data so the two are never conflated in an answer.

Consistent delivery surface

Each deployment pairs the agent with a dashboard - summary statistics, status distribution, clickable owner rankings, and hierarchical project/initiative views with list-versus-tree toggles - plus an admin path for data ingestion. Containerised for deployment, with reasoning transparency exposed in the UI on later builds so a user can see how an answer was reached.

3. Evolution across the four builds

The pattern hardened with each iteration: the first established tools-only grounding and aggregation; later builds moved to newer model APIs and response formats, added reasoning-panel transparency, richer group-by scorecards, and markdown table rendering; and the final application in the family carried the pattern into a privacy-constrained portfolio context where the schema itself had to be formally inferred first.

The reusable asset was never the code - it was the interaction contract: tools-only grounding, schema-before-filter, aggregation in code, transparent reasoning. Each engagement had a genuinely different domain model, and I rebuilt that layer every time. Recognising which layer generalises is what made four engagements cheaper than four builds.

4. What I’d highlight

• Tools-only grounding with schema-before-filter - a structural fix to LLM hallucination over structured data, not a prompt-level mitigation.
• Aggregation in code, narration by model - because leadership questions are aggregate questions and arithmetic belongs in code.
• Recognising and productising a repeated pattern across four engagements, while deliberately rebuilding the domain layer each time.
• Reasoning transparency so users can audit how an answer was produced.
• Meeting organisations where their data actually lives - the spreadsheet - rather than requiring a data-platform migration first.

5. Skills demonstrated

LLM tool-calling agent design · hallucination prevention through tool grounding · structured aggregation over tabular data · multi-sheet Excel intelligence · FastAPI · React dashboards · Docker containerisation · pattern extraction and reuse across engagements · reasoning transparency in AI UX