Hi team — a design question from real use, not a bug report.
What I'm seeing
Every analysis starts from natural-language discovery: the agent searches the catalog, resolves entities, lists tables, reads schema, then queries. There's no way to say "analyze this dataset" — I can't hand the agent a dataset URN (or pick a table in the UI) and have it skip straight to schema + query against that one surface.
Why I think it's deliberate (and I largely agree)
The system prompt is explicit that this is by design — e.g. "Documentation is authoritative about intent; the catalog is authoritative about existence," and a whole section on reading table metadata as signal before recommending a table. The agent is meant to reason its way to the intended surface rather than trust a name. For exploratory questions ("what's our churn?") that's clearly the right default, and it's a big part of what makes the agent feel governed rather than a raw SQL box.
Where the tension shows up
There's a recurring class of cases where the human already supplies the intent:
- I own the mart and I'm validating one specific table's numbers
- A runbook already pins the canonical table for this task
- I'm iterating on the same dataset across many turns
In those cases the discovery pass is pure latency, and — more importantly — it's a chance for the agent to drift to a different table than the one I meant. A way to anchor a turn to a known entity wouldn't weaken the "documentation is authoritative about intent" principle; it'd be the human asserting intent directly, which seems like the strongest possible signal.
What I'd love to understand
Is per-entity scoping intentionally left out on philosophical grounds (the agent should always reason about which table is authoritative, even when the user thinks they know)? Or is it simply not built yet — something that'd be welcome on the roadmap? And is there a public design doc / RFC where this discovery-vs-pinning boundary is discussed?
Happy to share concrete traces from my own usage if that's useful.
Hi team — a design question from real use, not a bug report.
What I'm seeing
Every analysis starts from natural-language discovery: the agent searches the catalog, resolves entities, lists tables, reads schema, then queries. There's no way to say "analyze this dataset" — I can't hand the agent a dataset URN (or pick a table in the UI) and have it skip straight to schema + query against that one surface.
Why I think it's deliberate (and I largely agree)
The system prompt is explicit that this is by design — e.g. "Documentation is authoritative about intent; the catalog is authoritative about existence," and a whole section on reading table metadata as signal before recommending a table. The agent is meant to reason its way to the intended surface rather than trust a name. For exploratory questions ("what's our churn?") that's clearly the right default, and it's a big part of what makes the agent feel governed rather than a raw SQL box.
Where the tension shows up
There's a recurring class of cases where the human already supplies the intent:
In those cases the discovery pass is pure latency, and — more importantly — it's a chance for the agent to drift to a different table than the one I meant. A way to anchor a turn to a known entity wouldn't weaken the "documentation is authoritative about intent" principle; it'd be the human asserting intent directly, which seems like the strongest possible signal.
What I'd love to understand
Is per-entity scoping intentionally left out on philosophical grounds (the agent should always reason about which table is authoritative, even when the user thinks they know)? Or is it simply not built yet — something that'd be welcome on the roadmap? And is there a public design doc / RFC where this discovery-vs-pinning boundary is discussed?
Happy to share concrete traces from my own usage if that's useful.