How to Make the Most Out of Contextflo

Contextflo connects your LLM to your data warehouse along with the context it needs about your tables, metrics and business definitions. Like any tool, you get better results by using it well. This is what that looks like in practice.

How a question gets answered

When you ask something, Contextflo runs a consistent workflow:

1. Search for similar patterns. Semantic search finds saved queries, metrics and business concepts related to your question, giving the model proven patterns to work from rather than a blank page.
2. Explore tables. If nothing relevant turns up, the model explores your warehouse tables to work out which are involved.
3. Verify schemas. It fetches exact column names, types and descriptions for any table it plans to query. This is the step that prevents invented column names and wrong joins.
4. Execute and analyse. The query runs against your warehouse and the results come back for the model to interpret.
5. Save what worked. Saved queries become available for future questions, so the same problem is not solved twice.

Step 1 is why context work pays off. The more you have saved, the less often the model is guessing from scratch.

Give it access to the right data

The model can only answer about data it can reach, and more access is not automatically better.

• Sync the tables that matter. Do not sync everything. Focus on what your team actually queries, because irrelevant tables are noise that makes the wrong table easier to pick.
• Point at production. If you have production and staging copies of tables, make sure it is pointed at the one you mean.
• Watch for schema changes. When tables get restructured or renamed, resync so column names stay current.
• Add context to the important tables. For high-traffic tables, write down the gotchas: deleted_at IS NULL means active, a test_ prefix means test data.

Start a new thread for a new question

When you switch topics, start a fresh conversation. Carrying over context from an unrelated analysis makes the model more likely to reuse a query that does not apply, and a long thread can run out of context window entirely.

Don't	Do
Keep asking about marketing metrics in the thread where you were analysing churn. The model may mix the concepts or reuse an irrelevant query.	Start a new conversation when you move from customer analytics to marketing analytics, so it works from a clean slate.

Save the queries you ask repeatedly

When a query works well, save it with a descriptive name and it will be suggested for similar questions later. The easiest way is to just ask, once the analysis is done: "can you save this query?"

Good candidates look like:

• Show MRR growth by product line for the last 30 days
• List customers with declining usage in a given quarter
• Break down ARR by customer segment and region
• Calculate retention by signup month

Saved queries are institutional knowledge. They capture the analysis patterns that work against your specific data model, including the filters someone learned the hard way. Admins can review and edit them in the app.

One caveat worth building a habit around: a saved query that has drifted from your schema is worse than no saved query, because it gets reused with the same confidence as a correct one. When you change a model, check what referenced it.

Add organisation-specific instructions

Organisation settings let you add instructions that apply to every query, under Settings → Org Info → Data analysis guide. This is where conventions live that no schema can express:

Data quirks. "The created_at column in the orders table uses PST. Always convert to UTC for comparisons."

Reporting conventions. "When analysing revenue, always exclude test accounts (account_id starting with test_) and internal employees (email domain @company.com)."

Preferred metrics. "For growth analysis, prioritise net revenue retention over gross retention. Our board treats NRR as the primary health metric."

The second one is the highest-value category by far. Exclusions are invisible in a schema, nobody thinks to mention them, and leaving them out produces numbers that are wrong by a plausible-looking margin.

For admins: review what people are asking

Periodically read the activity log to see where users and the model are getting stuck. This is the cheapest way to find out what context is missing, because it tells you what people actually want rather than what you assumed.

• Repeated questions. If several people ask the same thing, that is a saved query or a metric definition waiting to be created.
• Failed queries. Look for patterns. Repeated failures usually point at a specific missing table description.
• Confusion around a metric. If the model keeps misinterpreting something, define it explicitly or add it to your org instructions.
• Common domains. The areas people query most are the ones worth investing context in first.

Putting it together

The teams that get the most out of this treat it as a knowledge base rather than a query tool. The value compounds: each saved query makes the next analysis faster, each refined description prevents a class of confusion, each org instruction removes a round of back-and-forth.

Concretely, the highest-return half hour you can spend is reading the activity log, finding the three questions people keep re-asking, and writing those down as definitions.