The Weekly Query: How do you build and maintain the context your AI analyst needs to scale to the rest of the company?

Hey folks, and welcome to another edition of The Weekly Query.

And the people have spoken!

Last week I asked whether you'd be interested in an in-depth tutorial on context engineering and management for AI analytics.

And it looks like that was a “Yes”.

So this week we're doing something a little different. Rather than reading me blabber on about my opinions on data and AI, we're going to get into how to actually build some stuff. This will be a three part series, broken up into:

• Context Authoring & Governance
• Context Sources & Retrieval
• Context Improvement & Evals

Today, we’ll discuss authoring and governance, specifically, how to:

• Give an AI analyst the company knowledge an analyst would need to succeed.
• Structure company context, domain deep dives, and semantic models (and when to use each).
• And establish trusted sources, ownership, and processes for reviewing context changes.

Oh and for the 4% of you who said you're not interested: cover your eyes :D

Alright, let's get into it.

This week's query

How do you build and maintain the context your AI analyst needs to scale to the rest of the company?

By Shane Butler

For today's tutorial, I'll be using Hex, an agentic analytics platform where we can do the analysis and build and manage the context around it. This follows the workshop we're teaching with Hex this Saturday. (If you’d like to join us, it’s only $25 and we still have some seats available. More details here.)

We'll be analyzing Porchlight, a fictional neighborhood social network. Residents use it to share local updates, recommend businesses, discuss neighborhood issues, and buy, sell, or give away stuff. Local businesses pay to advertise to those residents. Hai, Sravya and I all used to work at a company much like this one :D

The problem we’re going to explore: weekly active users are declining, and we want to understand what's driving it.

You're welcome to follow along in Hex as we go through the guide. It’s free to try at hex.tech. You can use your own company data or they have a B2B SaaS demo dataset already available in the product. You can also read through the example and apply it later. The basic decisions here carry over to any other tools: what the AI needs to know, where that knowledge lives, how it gets used, and who keeps it current. A shared repo with some Markdown, YAML, and SQL can go a long way. Our open-source AI Analyst is another place to start if you're building your own system.

Why does an AI analyst need context?

If you connect say ChatGPT's data agent to your data, as I have with Porchlight's Snowflake warehouse below, and start asking it questions of the data, you will eventually start running into scenarios where it doesn’t necessarily hallucinate or miscalculate response, but it begins to make assumptions that don’t align to how your company actually works.

For instance I asked ChatGPT: “Using the Porchlight data, what was WAU for October 26 to November 1, 2026?”

It responded: 453

I know the correct number for this time period is actually 907, so then I asked: What definition of an active user did you use? Show me the source, filters, and SQL behind that number. Here’s what it said:

Maybe that’s a reasonable interpretation.

But a reasonable interpretation can still be misaligned with the company’s actual interpretation.

For instance, at Porchlight, the company includes users who open certain emails as part of their WAU as well even if they don’t visit the product. So if AI only counts users who visit the product, they're answering a different question.

Maybe that’s a bad metric by Porchlight. Maybe AI’s definition is better. (Maybe it’s based on a true story ;) ). But if you’re dealing with any sort of question where there could be multiple “correct” answers, you open yourself up to the risk of AI misaligning from how you define correct.

This isn't specific to a single model or platform. An agent in Hex needs that information too. So would a human. We have all been in meetings where people disagreed on how a metric should be defined or brought up, or someone flagged that the same metric didn’t match across two decks or dashboards. But that problem scales as the ability to access and ask questions of that data is scaled to the rest of the company through AI.

I like to think about an AI analyst as an experienced analyst joining your company. Someone who's been in the field for five or ten years. They know SQL, Python, statistics, how to communicate, and how to get shit done. But on day one, they don't know your company, your team, your metrics, your goals, or your data.

Just like with that new joiner, we need to onboard the AI to our company and our data.

Which brings us to the two jobs we’ll work through today:

• Context engineering: designing how the right information and tools reach the agent when it's working on a task.
• Context management: deciding what knowledge it should rely on, where that knowledge lives, who owns it, and how it stays current.

Three places to start

For this tutorial, I'll focus on three ways to give the agent company knowledge. There are more forms to store context than this, but I think these are pretty good places to start and go a long way:

Type	What goes in it	Example
Company-wide context	What goes in itThe background and conventions relevant to most analytical questions at the company.	ExampleHow Porchlight works, which data serves which purposes, and common mistakes.
Domain context	What goes in itDetailed guidance for a particular subject or type of analysis.	ExampleHow the growth team defines WAU, why it includes email activity, and how to interpret it.
Semantic model	What goes in itStructured definitions of data, calculations, dimensions, and relationships.	ExampleMeasures for user activity like retention and churn, and the dimensions we can use to aggregate or segment it.

All of these pieces work together. A semantic model is useful when we've established a calculation we want reused. A guide can explain its purpose, assumptions, and limits, and help with questions we haven't yet anticipated. And company-wide context is always on.

Let's actually start there: company-wide context.

Give it the company background

Some things are relevant across almost everything your AI analyst does. What does the business do? Where should routine analysis start? What conventions does the data follow? What mistakes do new analysts keep making?

In Hex, this broad workspace context lives in a file called hex.md, which is included in every conversation. If you're building in Claude Code, a CLAUDE.md file can play a similar role for project instructions.

I would start by interviewing yourself about four things:

• The business. What does the company do, how does it make money, and what decisions are we using data to make?
• The data. How is it organized? Which sources should routine analysis start with? What conventions would an outsider miss?
• Recurring mistakes. Where do people usually get tripped up? What looks obvious but means something different here?
• Analysis preferences. What should be included in an answer? When should the analyst stop and ask a question?

You can have AI interview you on these one at a time, draft the document, and then review it.

For Porchlight, an excerpt of our company-wide context stored in Hex’s Context Studio looks like this:

But what about the very specific knowledge required to calculate something like WAU? This context doesn't need to go into every conversation someone has about advertising, hiring, or company finances. In fact too much irrelevant context might make answering those other questions harder for the agent (not to mention the additional token cost).

That's where Domain Context comes in.

Write down what WAU actually means here

Domain context gives the agent detailed knowledge for a particular area of work. In Hex this information is stored in Domain Guides. You can store these in a directory of markdown files if you are using your own repo or AI analytics tool.

For Porchlight, that could be engagement, notifications, advertising, or experiments.

Take WAU. The broad definition sounds simple: people who were active in the product or opened a qualifying email during a seven-day window.

But once you try to calculate it, you’ll start finding you have a lot of questions:

• What counts as product activity?
• Which emails qualify?
• What if someone visits the product and opens an email? We should count that person once.
• What if an email open was machine generated or opened by a bot rather than someone reading it?
• Which seven days are we counting, and in which timezone?
• If someone moved neighborhoods during the week, where do they belong in the breakdown?

That's all company-specific knowledge. It’s not baked into any AI model you access out of the box. Some of it comes from product decisions. Some comes from how the data was built. Some comes from measurement problems people had to work around at some point in time. A lot of it is the opinions of groups of people. And it’s often full of nuance.

In Porchlight, our domain context needs to distinguish on platform WAU from off platform WAU, and measured WAU from estimated WAU. As I mentioned earlier, Porchlight considers some email opens as qualifying events to count a user as WAU (off platform). But not all email opens can be counted reliably due to privacy features on iOS. So to make things even more convoluted, they do some hacky calculations to estimate email opens for those iOS users.

An AI (just like a human analyst) at Porchlight needs to know all this. And a domain guide is a good place to explain that nuance and why the rules exist.

Help the agent know when to read it

Step 1 is to give your guide a useful name and description to help the agent identify the relevant guide for the question it’s trying to answer. We don’t want the agent to read the entire guide to figure out if the context is worth consuming. In fact, we want it to consume as little as possible. Hex calls the small header at the top of the file frontmatter.

The frontmatter of our WAU guide at Porchlight looks like this:

Think about how real people actually ask real questions. They may say “weekly actives,” “active residents,” or “people using the product.” You want to give the agent enough information to recognize when the guide applies, and where those phrases need clarification.

Then once the agent knows this is the best guide to consume, the body should cover the things it needs to carry out the analysis:

• The questions and business decisions the guide supports.
• Approved definitions, including time periods, filters, and exceptions.
• Data sources, grain, keys, and relationships.
• The calculation or a reference to it elsewhere (like a measure in a semantic model).
• Known data problems and limitations.
• How to interpret and test answers.
• Who owns the definition and when it was last reviewed.

Have AI interview you

That’s a lot of information to organize. On the data team we are used to collecting this sort of information. We have built this muscle long before AI, working across the company, eliciting information from our stakeholders and partners to help us tease out all this nuance. Some of it we documented, much of it we stored in our minds.

Just as we interviewed those stakeholders to get that information out of their minds here, I find a similar process helps here to help AI get it out of ours. I like to have the agent ask me questions like:

• Which domain are we documenting, and what questions do people ask about it?
• What are the important entities, and how do they relate?
• What are the agreed metrics and calculations?
• Which sources should the analyst use, and what does one row represent?
• Which joins, filters, exceptions, and historical changes matter?
• What needs clarification, and what checks would tell us the analysis is right?
• Who can confirm these rules and keep them updated?

I ask AI to go through that with me one question at a time. I give it existing documentation and reviewed analyses where you have them (we’ll get more into how to do this in an automated/structured manner in Part 2 of this series: Context Sources & Retrieval). And then I review the draft before rolling it out as the company's instructions.

Here’s a snippet of what that might look like for Porchlight:

Test the change before everyone starts using it

One habit I highly recommend getting into early: understand how a context change affects the answers.

Don't write a bunch of documents, change several definitions, remove some old guidance, and roll the whole thing out at once. It'll be much harder to work out what helped or what broke.

And more importantly, I also think it runs the risk of you offloading the thinking too much. When we do big jobs with AI, I find it becomes really easy for us to take the back seat real quick. The purpose here is for us to be extremely engaged, directing AI on how to incorporate our company context. Doing tighter iteration cycles of ideation, structuring, reviewing, testing, and publishing removes a lot of that temptation to YOLO and let AI decide things for us.

Ideally, you'll have an eval suite: a set of questions and checks you can run against your AI analyst to see whether its work meets your standards. That includes questions you're trying to improve and questions that already work. We are going to cover this in length in Part 3 of this series: Context Improvement & Evals.

But to get started, at least just try a few relevant questions and inspect the work behind the answers. Compare the answers with and without your change. For Porchlight’s WAU guide, a few test questions I might run are:

• What was WAU for October 26 to November 1?
• How much of that activity came from the product versus email activity?
• Can you show estimated WAU by country?

The first question constrains metrics to a single window of time that I already know the answer to, so I can flag if it’s right or wrong.

The second lets me evaluate if the agent knows what I mean by “email activity”?

And the third is useful because the right behavior may be to explain that the company-level estimate doesn't support that specific segment breakdown. A test doesn't always need to end with a number. Sometimes the test might be to see if the agent asks us for more information rather than making things up on their own.

You’ll want a way to compare these changes easily, similar to how you would test code before and after a commit, or a product rollout via an a/b test, you’ll just want to build out some process to do that reliably.

In Hex below, I’m using their Context Workbench's Test and Publish flow to ask questions against the proposed context before making it live. Then I can compare that with the current published version via live Notebook agent.

Check whether it used the right definition and source, not just whether the final number looks good. A few successful questions give you evidence about those questions; you'll still need to test more of the work people will ask it to do.

A GitHub repo is another good way to organize reviewed changes and version history. Either way, someone should be able to see what changed, review it, and return to an earlier version if needed.

The best part is now that this context is published, it’s automatically accessible across the company. A colleague asking about WAU has access to the same maintained definition, instead of relying on whatever happens to be in my local conversation or memory.

Make the established calculations reusable

Now let’s go a little further. I had my analytics agent look at how WAU has changed over time. Total company WAU has been declining lately, but breaking it down reveals something else: activity in the actual product had been dropping even while total WAU was still growing. Email activity was making up a larger share of the total.

So what’s driving that decline in platform activity? Maybe fewer people are joining. Maybe existing users are churning. Maybe people who used to visit regularly are showing up less often. Or perhaps fewer occasional users are becoming frequent users.

We can investigate that through growth accounting: tracking how users move between defined activity states and how those movements contribute to growth or decline.

But each of those things needs a definition. What counts as a frequent user at Porchlight? How long does someone need to be gone before we call them churned? What counts as coming back?

The team has been doing this work for years. They already have agreed definitions, SQL, and automated reporting. We want our AI analyst to use that same knowledge when we ask follow-up questions or explore something our existing dashboards don’t cover.

This is a good place to use a semantic model. We already know the calculations we want. Rather than having the agent recreate them from written instructions every time, we can define them in the model and reuse them. Then, whether we’re looking at retention over time or breaking it down by country or neighborhood, we’re working from the same definitions.

What's in a semantic model?

A semantic model describes the data and the calculations people should use. The main pieces are:

Piece	What it means	Example for this investigation
Source	What it meansThe table or query the model is built on.	Example for this investigationThe approved activity dataset.
Grain	What it meansWhat one row represents.	Example for this investigationOne user on one reporting date in a selected snapshot.
Dimension	What it meansSomething we can filter or group by.	Example for this investigationReporting date, country, neighborhood, or activity segment.
Measure	What it meansA calculation over the data.	Example for this investigationDistinct users meeting an approved activity rule.
Relationship	What it meansHow the model connects to other data.	Example for this investigationThe valid connection to neighborhood details without duplicating users.

Semantic models have been around for a long time. dbt, Snowflake, Hex, and other platforms have their own implementations. There's also work on exchanging definitions between tools.

In Hex, these definitions can be written in YAML, a text format for structured configuration. The syntax organizes names, fields, calculations, and relationships so the platform can interpret them. Note: a YAML file needs a system that actually reads and uses it; so just saving a definition somewhere doesn't by itself enforce a calculation. It’s not as open ended as guides. Below is an example of a semantic model I store in Hex’s data models for our Porchlight semantic project.

Pair the semantic model with the domain context guide

As I mentioned in the beginning of the issue, that semantic model is only one piece of the context puzzle. I'd still have a growth-accounting domain context guide explaining what the analysis is for, what the states mean, and which questions the model can answer. But instead of explaining all of the metric calculations in the guide itself, I’d have it direct the agent to the semantic model for the established calculations.

We did some of this in reverse to introduce the pieces. In practice, you would start with the business guidance and add modeled calculations as the definitions become established, then update the guide to reference the model. Just make sure you’re not maintaining the calculation in both places. If you’ve got one calculation of the metric in the model and another in prose in domain context, they are likely to drift apart at some point and feed AI conflicting definitions.

Here’s my agent’s response in Hex on what’s driving the WAU decline after we added our semantic model.

A bonus of building shared models like these is it encourages some healthier analytical behavior organizationally, it gives the team a concrete artifact to discuss when definitions at the company need to change, making those discussions less abstract. Instead of everyone creating their own versions of a metric in their heads, we can review the existing definition in a centralized repository and decide what should happen to it.

By the way, as an aside, if you're interested in the toy growth-analysis we’re doing as an example, I'm teaching a free session next month: Master Growth Analytics with AI, Wednesday, December 9 at 10 a.m. Pacific. We'll use Runable to work through choosing a growth question, investigating the evidence, and deciding what to do next. You're welcome to join.

Okay back to the show.

Give the definitions an owner

I highly recommend having a specific owner for each consequential definition or guide. And it doesn't always need to be the data team.

If we're documenting email engagement, the product manager responsible for email may be the person who needs to confirm what the metric means and tell us when the product changes. Someone on the data team can make the technical update, but the business owner is still responsible for the meaning staying current.

For an analytics procedure, a data person may be the right owner. For finance definitions, get the appropriate finance owner involved. “The data team owns all context” is going to get difficult pretty quickly.

You basically want to build a culture of proactive data stewardship, where owners of domains across the business are actively delivering any updates or changes to the system’s context (or the technical owners of the context, such as the data team). Rather than a reactive culture where the data team is trying to pull it out of everyone from time to time.

Agree on who can propose a change, who approves it, and who updates the actual asset. Record what changed and when it takes effect. Then test the affected questions and tell the people who rely on it.

You need that process when someone changes a definition in a meeting, as well as when someone spots a wrong answer from AI in the system itself.

Tell the agent which sources to trust

Your warehouse probably has several tables that look like they could answer the same question. Some are maintained. Some are experiments. Some belong to a dashboard nobody has opened in years and years.

We need a way to communicate which sources have been reviewed, what they're suitable for, and how AI should prioritize them when answering a question.

There are many ways to do this. Trust and usage status might live in your data catalog, metadata, or a reviewed source inventory that the agent consults. The key is to include what each source is for, its limitations, its owner, and whether it's draft, approved, or superseded.

In Hex, I'm using endorsements. These prioritize trusted assets when the agent answers questions. You can endorse sources such as tables, schemas, projects, and semantic models. An endorsement is a review signal; it doesn't prove the asset fits every possible question. Below is how I set up an endorsement in Hex as well as a couple screenshots that tell me if the data they used has been endorsed or not.

Bring it back to your team

So how do we take this from something that works for us to something the rest of the company can use?

I'd roll it out in stages.

• Start with yourself. Pick work you know well enough to check. Build the context around that, inspect what the agent does, and figure out where it still gets things wrong. Your own experience gives you a much better chance of catching those mistakes.
• Bring in other people on the data team. Have them ask their own questions and review the work. Can they use the context you build into the system without you sitting next to them explaining everything? They might interpret a metric differently, know about an exception you missed, or ask something you hadn't thought to test.
• Work with stakeholders in one area of the business. Bring in the product, marketing, finance, or other team that owns the decisions you're trying to support. Agree on the definitions, which questions the system is ready to answer, what data people can access, and when an answer still needs review. Give those people a way to flag problems, and make sure someone is responsible for acting on them.
• Expand from there. As you bring in another team or business area, reuse the definitions and sources that apply, add the knowledge specific to that domain, and test the new questions before opening it up further. Don't assume that because it works for your team, it's ready for every question the company might ask.

A lot of this becomes an organizational challenge. People need to agree on what things mean, who owns them, and how changes happen. The data team can build the system, but it can't make all those business decisions on everyone else's behalf.

And honestly, this is work we should have been doing anyway.

If two teams show up to the same meeting with different numbers for the same metric, AI didn't create that problem. We already needed to understand what each team was measuring, why the definitions differed, and which one applied to the decision. Sometimes both definitions are useful. We still need to be clear about what each means.

Doing this well helps the company beyond AI. It gives people shared definitions, clearer ownership, and a way to resolve disagreements. That helps with dashboards, experiment readouts, planning, and all the other places we use data to make decisions. I'd want those things even if we weren't building an AI analyst.

And this work keeps going. As more people get access, they'll ask questions you never thought to ask. The product will change. Tracking will change. You'll find gaps in the data foundation, missing context, and new things to evaluate. The system needs a process for learning from that and improving over time.

We'll leave it here for this tutorial. In the future issues, we’ll get into context Sources & Retrieval and Context Improvement & Evals. These will help you pull in context that already exists in documents and code across your business, determine if it’s being used as expected, set a review cadence, and expand to many more teams without letting the context get out of date. If you'd find that useful or have any questions, hit reply and let me know.

New in data this week

A few things worth a look this week, especially if you're building the kind of system we just walked through:

• Hex says it cut the cost of an agent conversation by nearly 75%. In its November 9 write-up, Hex reports a drop from $6.44 to $1.64 per Thread since January, through model choices and changes to its agent harness. Those are Hex's reported costs, not a promise for your workload. I like that it points people back to evaluating models on their own company's data.
• Databricks updated Genie permissions, tracing, and benchmarks. The November 5 release lets Genie Agents answer using the attached sources a user can access, adds parallel benchmark runs, and introduces beta trace export for Genie Code and Genie One. Useful progress on the access, observability, and testing work we talked about above.
• dbt published a way to assess your company's AI readiness. Its November 5 article looks at data quality, governance, ownership, cost, context, and interoperability. Worth going through with the people responsible for those things before treating “we gave everyone an AI tool” as the end of the rollout.

The 30-second lesson

Regression testing

Say you update your AI analyst’s context to fix a wrong answer. You test the question again, and it gets it right. Heck yeah! But wait…what happened to all the questions it was already answering correctly?

Regression testing means rerunning those checks to make sure a change hasn’t broken something that worked before, even if it fixed what you’re currently working on.

For example, an update to your WAU guide might fix the company total but cause a country breakdown to use an estimate that doesn’t apply there.

Keep those working questions in your eval suite alongside the one you’re trying to fix. After a change, check both: did we fix the problem, and did anything else get worse?

Jobs this week

The context work above is showing up in job descriptions too. Cohere wants someone to connect its semantic layer to an internal analytics agent and evaluate the answers. ElevenLabs wants data served through AI agents. Discord is asking for a discoverable semantic layer and guidance that helps other teams answer their own questions.

Here are eight open roles covering that work, from company definitions and reusable models through to agentic analytics.

Senior Staff Data Engineer at Cohere

US and Canada locations. Listed US base salary for California, New York and Washington: US$300,000–$350,000 a year; other locations have separate ranges.

Cohere wants this person to lead its data foundation work, connect the semantic layer to an internal analytics agent, and build the eval harness that determines where it is ready for production.

Staff Data Engineer at Discord

San Francisco Bay Area. Listed base salary: US$248,000–$310,000 a year, plus equity and benefits.

Discord wants a discoverable semantic layer, reusable data models and clear guidance for self-service, alongside contributions to AI-assisted analytics workflows.

Lead Product Data Scientist, Agents at Klaviyo

Boston. Listed US base salary: US$172,000–$258,000 a year; the offer depends on location and experience.

Klaviyo wants this person to define how its AI agents are measured, investigate traces and failure patterns, and establish governed metrics and shared measurement standards.

Senior Analytics Engineer at Prefect

Remote, US pay bands. Listed base salary for the SF Bay Area and NYC metro: US$173,000–$222,000 a year; other US locations have separate ranges.

Prefect wants one maintained definition of its core GTM entities and metrics, with a semantic layer, documented assumptions, tests and version control so teammates can answer their own questions.

Analytics Engineer at ElevenLabs

Remote-first in Europe, operating in GMT/GMT+1 hours. Salary not listed.

ElevenLabs wants trusted, reusable data products served through AI agents, and experience building semantic or metrics layers consumed by AI tools.

Senior Analyst, Advanced Analytics at Airbnb

Gurugram, India. Salary not listed.

Airbnb wants its customer-support analytics practitioner to build agentic pipelines, reusable skills and governed prompts, and certify the metric definitions those systems use.

Analytics Engineer at Modal

New York, San Francisco or Stockholm. Listed salary: US$150,000–$250,000 a year; confirm location applicability with the recruiter.

Modal wants foundational datasets that people and AI tools can use for product, finance and marketing questions, as part of its self-serve AI analytics stack.

Analytics Engineer at Linear

Remote, North America. Listed US base salary: US$180,000–$220,000 a year; equity is additional.

Linear wants trusted models and reusable workflows across its business, with LLMs and coding agents used in analysis, development, testing and documentation.

What's happening at AI Analyst Lab

This week

This Saturday: build with us in Hex

If you liked this tutorial and want to get hands-on, join Enterprise Context Management for Analytics this Saturday, November 14, from 7 to 11 a.m. Pacific.

You'll connect to Porchlight in our Snowflake warehouse and work through this yourself with three instructors: me and Hai from AI Analyst Lab, and Rachel Herrera from Hex.

We'll build company and domain context, work with semantic definitions and trusted sources, inspect whether the agent uses them, and test improvements before publishing them.

You'll get:

• The context you build during the hands-on exercises.
• Live help from the three of us.
• The recording and course materials to return to afterward, including if you can't make the live session.
• An extended Hex trial so you can keep building.
• A practical 30-day implementation plan for applying the work at your company.

I'm not sure when we'll run this one again. If this is something you've been meaning to learn, I'd recommend setting aside the half day and joining us.

Reserve your seat for $25 with CONTEXT25.

Reserve your seat for $25

We've also got three free lightning lessons this week:

The New Data Job: What AI Does, What You Own

Today we're working through what AI can take on, what needs review, and what data people still need to lead. Join us if your team's job is starting to feel like checking everyone else's AI output.

Register for free

Decide which data questions AI answers

Before opening AI analytics to the company, decide which questions it should answer. We'll work through the cost of getting an answer wrong and whether the person asking can recognize the problem.

Register for free

Build a Promotion Case That Gets Approved

If you're working toward a promotion, we'll look at how decisions get made, how to map your work to the next level, and how to explain your impact when you're not in the room.

Register for free

Next week

Check if your data is ready for AI

Take a recurring question, check the data it depends on, and identify what needs fixing before you expect an AI analyst to answer it reliably.

Register for free

Think on the Spot in Analytics Case Interviews with AI

Practice structuring a case, thinking out loud, and checking the details that matter before making a recommendation, with AI helping you rehearse.

Register for free

Coming up

Master Growth Analytics with AI

If the growth questions in today's Porchlight example caught your attention, join me for a session using Runable. We'll choose a growth question, investigate opportunities with business data and market research, and turn the evidence into a measurable next step.

Register for free

Enterprise AI Analytics for Data Leaders

We'll work through the organizational side of this: where to start, who owns the definitions and context, how changes get approved, and how to build a plan the rest of the company understands.

View the workshop

That's it for this week. If you try this at work, hit reply and tell me what you built or where you got stuck.

See you next Tuesday,

Shane