Skip to main content
The third time someone asks “what’s MRR by plan,” the agent should be reading a view it built the first time. Materialization is the data agent turning recurring questions into durable, reusable structure in a schema it owns.

​
The pattern

A recurring question is a signal. The agent promotes it from an ad-hoc query to a view in an agent-managed schema, then answers from the view.
  1. A question repeats, or a query gets validated as correct.
  2. The agent proposes the view and a human approves the write.
  3. The Engineer builds the view in its own schema (for example dash), never in public.
  4. The new object’s schema and an example query go into knowledge, so later runs can discover it.
  5. The next ask reads the view directly, which is faster, cheaper, and consistent across users.
Configure dash_writer as a non-owner role with read access to source data and write access only to dash. requires_confirmation_tools pauses every run_sql_query call. After the client continues the run with approval, SQLTools executes the statement. The role’s grants must enforce the schema boundary because SQLTools does not restrict SQL by schema. After creation, add the object’s columns, purpose, and example queries to the agent’s knowledge, so later runs discover the view instead of rebuilding the query. Attach the knowledge store from grounding to the Engineer and set update_knowledge=True. That gives the agent an add_to_knowledge tool, which writes the description back into the same store it searches.

​
Why an agent-owned schema

The agent writes structure, so that structure needs a sandbox. A dedicated schema keeps generated views away from the tables your product depends on. Because the schema is disposable, a wrong view is a cheap mistake. Drop it and let the agent rebuild.

​
Materialize from validated queries

The best materialization candidates are the validated queries from grounding. A query analysts already trust, asked often, is exactly what should become a view. Review the generated DDL before approving the write. A regular view evaluates its query when read. Summary tables and materialized views need explicit refresh logic; this example does not schedule that work.

​
How it compounds

Each repeat question promoted to a view is one less query generated from scratch:
  • Captured corrections inform later runs (self-correction).
  • Validated query shapes sit in the knowledge stores (grounding).
  • The agent-owned schema accumulates the views your team relies on, with no hand-written migration.
Repeated work becomes structure instead of recomputation, so the agent gets faster and more consistent the more it is used.

​
Next steps

​
Developer Resources