Query Generation Pattern
Object definitions and relationships are loaded into the knowledge base; the LLM generates the required query at runtime from user intent, rather than using a pre-defined query.
Why This Pattern
This is the highest-risk, highest-flexibility pattern in the set — you're trading the safety of a pre-written query for the ability to answer questions you can't enumerate in advance. That trade only holds up if you've also invested in giving the LLM concrete query templates as knowledge, so it adapts known patterns instead of inventing syntax, plus explicit guardrails on functions the target system doesn't support. Skip that investment and this pattern produces confidently wrong aggregations — the failure mode is silent, not loud.
Contrast with Information Summarization: that pattern synthesizes data you've already retrieved. This one decides what to retrieve in the first place — a different, riskier kind of judgment.
When to Use It
- Ad hoc aggregation or lookup requests that can't be enumerated in advance (e.g., "total ARR from contracts signed in FY2026").
- You can ingest object metadata and common query templates as knowledge, giving the LLM concrete patterns to adapt.
When NOT to Use It
- The set of possible queries is small and known upfront — a fixed skill is more reliable and auditable.
- The target system doesn't support the aggregation functions the LLM might generate, and you haven't documented that explicitly — this pattern will fail silently instead.
How It Works in Workato
- Ingest object metadata (object name, description, field list with types) as knowledge.
- Ingest commonly used or complex query templates as knowledge, so the LLM adapts known patterns instead of inventing syntax.
- Build a skill that takes the LLM-generated query plus a target table, executes it, and returns results — with explicit do's and don'ts, pagination, and any aggregation limits the target system requires.
Source: Agentic Design Cookbook V2.0, pp. 17–19