> ## Documentation Index
> Fetch the complete documentation index at: https://agno-v2-codex-docs-audit-20260719-0149.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Materialization

> Turn validated recurring queries into reusable views in an agent-owned schema.

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.

```bash theme={null}
uv pip install "agno[openai,psycopg,sql]"
```

```python theme={null}
from agno.agent import Agent
from agno.models.openai import OpenAIResponses
from agno.tools.sql import SQLTools

engineer = Agent(
    name="Engineer",
    model=OpenAIResponses(id="gpt-5.5"),
    tools=[
        SQLTools(
            db_url="postgresql+psycopg://dash_writer@warehouse/analytics",
            requires_confirmation_tools=["run_sql_query"],
        ),
    ],
    instructions=(
        "When the user requests or approves a reusable view, introspect the "
        "schema and create it in dash. Never create objects outside dash."
    ),
)
```

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](/use-cases/data-agents/grounding-in-context) 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.

|                             | `public` (your data)           | `dash` (agent-owned)               |
| --------------------------- | ------------------------------ | ---------------------------------- |
| Who writes                  | Your application and pipelines | The Engineer agent only            |
| Holds                       | Source tables                  | Generated views and summary tables |
| Blast radius of a bad write | Catastrophic                   | Contained, droppable, rebuildable  |

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](/use-cases/data-agents/grounding-in-context). 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](/use-cases/data-agents/self-correcting-agents)).
* Validated query shapes sit in the knowledge stores ([grounding](/use-cases/data-agents/grounding-in-context)).
* 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

| Task                            | Guide                                                               |
| ------------------------------- | ------------------------------------------------------------------- |
| Keep writes inside the boundary | [Safe data access](/use-cases/data-agents/safe-data-access)         |
| Seed the validated queries      | [Grounding in context](/use-cases/data-agents/grounding-in-context) |

## Developer Resources

* [Dash: reusable views in the `dash` schema](/deploy/templates/dash/overview)
* [Serve and embed](/use-cases/data-agents/serve-and-embed)