- Reads the navigation index to find which files are relevant
- Fetches only those files from the repository
- Uses their contents to inform the query, calculation, or analysis
Why this matters
The alternative — putting all your context into the product-native context library as a single document — has a practical ceiling. As your organization’s knowledge grows, a single context document becomes unwieldy. Ana has to read all of it on every question, most of which is irrelevant to what the user actually asked. Dynamic loading solves this by letting you build a large, well-organized knowledge base and having Ana navigate to the right part of it. You can have hundreds of files covering different data sources, metric definitions, API documentation, and business rules — and Ana will find the relevant ones without loading everything at once.“You get a dynamic context load that gets triggered based on what questions you ask and what knowledge the agent identifies that it needs to find in your context repo. You get more efficient token usage on your questions, and also more precise knowledge download for the agent.”
What to store in the repository
The repository can contain any files Ana can read. Common patterns: Data source documentation Markdown files describing your tables, columns, known data quality issues, and example queries. When a user asks about a specific dataset, Ana fetches the relevant documentation file rather than relying on schema inference alone. Metric definitions Markdown or SQL files defining how key metrics are calculated — what filters to apply, which tables to join, how to handle edge cases. Ana reads these when the question involves a defined metric. API documentation If your team uses external APIs (internal tools, third-party services, data providers), store their documentation in the repository. Ana fetches the relevant API docs when a question requires calling that service. Business rules and conventions Fiscal calendar definitions, currency conventions, exclusion rules, terminology that differs from common usage. These can live in a single org-level file or be split by domain. Reusable code Python helper functions, SQL query templates, visualization scripts. Ana can read and adapt these rather than writing from scratch each time. Navigation index A top-level file (likeNAVIGATION.md) that maps question types to the files that answer them. This is what Ana reads first to orient herself. A well-designed navigation index is the single highest-leverage thing you can do to improve answer quality.
Designing the repository structure
Think of the repository as a maze that Ana navigates. The goal is for Ana to find the right file quickly, even if the user’s question uses different terminology than the file names. Start with a navigation index. A top-level file that routes common question types to the right files. Ana reads this first and uses it to decide where to look next. Even a simple one dramatically improves how reliably Ana finds the right context. Use cross-references. Each file should link to related files. If a metric definition references a specific table, link to the table documentation. Ana follows these links to build complete context. Organize by domain, not by type. Group files by business area (sales, product, finance) rather than by file type (all SQL files together, all markdown together). Ana navigates by topic, not by format. Keep files focused. A file that covers one table or one metric is easier for Ana to use than a file that covers ten. Ana fetches whole files, so smaller focused files mean more precise loading.Previewing and iterating
After setup, ask Ana a question that should trigger a context lookup. Check whether she found the right file. If she did not, adjust the navigation index to route that question type more clearly.GitHub Integration Setup
Set up the GitHub connection, access token, and system prompt
Version-Controlled Context Writing
How Ana proposes context changes via pull requests