Patrik Devlin, co-founder and CTO of Hazel, talks with MotherDuck's Alex Monahan about how Hazel built an AI coworker for consumer brands and the data stack underneath it. Patrik shows Hazel in a demo account using prompt_jev() and embedded Dives, then walks through the architecture: Fivetran and dlt into S3, dbt models in MotherDuck, and one isolated MotherDuck database per customer.
What Hazel does and why it works from raw data
Hazel is a vertical AI product for consumer brands, which Patrik describes as an AI coworker or operator. Brands connect their ad platforms, support tools (email and SMS), and Shopify, and once the data syncs the agent is ready to use. Patrik says co-founder Clint Dunn brings deep experience with consumer brand data, and some of that knowledge went into a prepackaged context layer, including things like lifetime value analysis.
Hazel deliberately sits on data that is closer to raw than most BI products, with dimension and fact tables but little pre-aggregation. The agent is good enough at pulling insights across data sets that Patrik would rather give it an open canvas than make assumptions about how it will be used. A single answer can take around twenty queries as Hazel checks itself. He also describes memory as a goal: letting Hazel get smarter as a whole brand uses it, without leaking one person's conversation to another.
Demo: prompt_jev() and embedded Dives
Hazel added prompt_jev() within a week or two of its launch. Patrik's demo account is a barbecue brand with no long-form text, so he classified email subject lines with Jev and merged the labels back onto about 10 million emails to compare open and click rates by category. He then asked Hazel to classify cancellation reasons from a subscription platform as controllable or not, tag every cancel session, and trend the controllable share by quarter. He also sees Jev driving marketing segments that can be exported to external systems.
Hazel's dashboards are embedded Dives: the AI writes the JSX, MotherDuck is the back end, and DuckDB WASM loads a local copy of the data so filters run in the browser. Alex adds that you can ask a Dive to cache a temp table locally, and that he has pushed this to roughly 100 million rows, with 10 to 50 million more comfortable for snappy responses.
The architecture, step by step
Ingestion started on a homegrown dlt system. Hazel now runs Fivetran for connectors that already exist and keeps dlt for custom sources and for high-volume connectors, since Fivetran bills by monthly active rows. Everything lands in an S3 data lake partitioned by organization. About 700 dbt models run in MotherDuck, stopping at a layer closer to raw than most, so the agent works out how things connect.
To expose that single warehouse safely, each organization gets its own MotherDuck catalog and a service account named after the org ID, so no account can reach another brand's data. It also lets Hazel size compute per brand, such as more read scaling for a heavy customer, which Patrik calls hypertenancy. In the app, a request through the API gateway carries the user ID and org ID, and the org ID is used to look up the read-write or read-only credentials for that service account.
Scale, cost, and guardrails
The largest table is email event data at roughly 500 million to 1 billion rows, and org databases run up to about a terabyte. Hazel sent 5.75 million queries through MotherDuck in the last 30 days, around 190,000 a day, and Patrik says he has not noticed latency differences and is probably not pushing the limits yet.
He says Hazel's MotherDuck query cost is very small next to its dbt transformation spend, and token cost is the real concern. Query tools cap how much data comes back in several bands and change the output format by size (JSON, TSV, or key-value), prompts push the agent to aggregate, and spreadsheet exports work by having Hazel write the query and the system run and stream it, so large results never pass through the agent. Observability is Langfuse, and users are not shown the SQL, since Hazel's customers are not technical.
Hazel is also experimenting with DuckLake. Its older data lake is an append-only partitioned layout that accrues too many small files, and Patrik is interested in compaction, the catalog, and data inlining. Looking ahead, he is most excited about ambient agents that find problems in your business and propose fixes without being asked.
