The problem that forced us to build this​

We had a pile of insights and nobody could find anything in it.

Here's what actually happened. I ran two discoveries back-to-back against a sample vacation rental dataset we use for testing — a thing called WanderBricks. Two runs, 132 insights between them, a handful of recommendations, seven analysis areas. Normal DecisionBox output. Nothing weird about the numbers.

A few days later I was on a call and someone asked me "didn't one of those runs find something about same-day bookings getting cancelled a lot?" And I genuinely could not remember which run, which analysis area it was under, or what the exact finding said. I opened the dashboard and started clicking through insight cards. It took me about four minutes of scrolling to find it.

Four minutes is the kind of friction where you just stop looking. And if I'm doing that — I wrote the thing — a customer staring at their own dashboard for the first time has no chance.

So we built Ask.

What Ask is (and what it isn't)​

Ask is a text box. You type a question in plain English, and it pulls up the insights and recommendations your discoveries already produced that are relevant to what you asked. Then it writes you a short answer that stitches those findings together, with numbered citations pointing back to the originals.

I want to be clear about one thing before going further: Ask does not make things up. It doesn't invent data. It doesn't run new SQL. It doesn't talk to your warehouse. It retrieves existing insights from the runs you've already completed and summarizes them. If you ask it about something the agent never analyzed, it will tell you it has nothing.

If that sounds boring, good. The whole point is that every number in the answer is traceable back to a SQL query the agent wrote and validated against your data. You can click any citation and read the raw insight — name, description, affected count, risk score, source steps, discovery run, timestamp. All of it.

What it actually feels like to use​

I'll just walk through the session I ran while writing this post. Same project, same two discoveries, no cherry-picking. All the quotes below are copied from actual answers.

Question 1: "What are the biggest threats to guest trust on the platform right now?"​

Six results came back. The top match was an insight about the five dominant negative review themes — cleanliness, maintenance, unresponsive hosts, misleading descriptions, and bad experiences — each appearing in over 6,500 reviews. The second was the platform-wide rating sitting at 3.01 against a 4.5 target. Then support tickets confirming listing-accuracy complaints, then a suspicious 99,793-reviews-against-72,244-bookings ratio that hints at data integrity issues.

The answer pulled those together into one paragraph I'd actually put in a deck:

"A guest who sees a misleading listing, arrives to a dirty property, can't reach the host, and then reads reviews that seem unreliable has experienced a complete trust chain failure. The data bears this out: guests with 1–2 star average experiences have only a 7.35% repeat booking rate versus 25.6% for those with 3–4 star averages."

The 7.35% number is from an insight I hadn't even opened before. Ask found it, cited it, and wove it into the narrative. That's the thing I wanted — a map across insights, not just a list.

Question 2: "Where are we losing the most money? I care about the biggest revenue leaks."​

Same session. This is the part where the multi-turn bit matters — Ask remembers what we've already talked about, so follow-ups land naturally.

Top result: cancellation leakage. $5.8M lost in the first seven months of 2025, about 22% of gross. Second result: 77% of guests who cancel never rebook, which is a separate $4.5M annual churn. Third: a refund rate accelerating to 9.3%. The answer arranged these in order of financial impact, which I did not ask for but is obviously what I wanted.

I didn't have to phrase the question a specific way. I didn't have to remember that cancellation findings were in the cancellation and revenue analysis areas. I just said "revenue leaks" and it pulled the right things.

Question 3: "Is our host onboarding healthy? How do we compare to where we want to be?"​

This is where I got a bit emotional because the answer was really good.

It opened with:

"Short answer: No. Host onboarding is in a state of catastrophic failure, and it represents one of the most severe underperformance gaps on the platform."

Then a table — 80% target, 19.7% actual, 60-point gap. Then the absolute counts: 19,384 registered hosts, 3,817 have ever created a listing, 15,567 signed up and did nothing. Then a country-by-country breakdown showing that India and China together account for 72.6% of registered hosts and only 2.96% of them have listed anything. Then a first-week retention window — hosts who list within a week average 6.8 properties and 17.3 bookings, hosts who take six months average 2.9 and 8.3.

Every one of those numbers came from a different insight in the discovery run. I could have found them manually. I would not have thought to line them up next to each other like that.

Question 4: "Out of everything above, what could we actually ship this quarter to move the needle?"​

This is the question I care about most, because "what do I do on Monday" is the real job. The answer came back with four concrete initiatives, ordered by impact and effort, with dollar ranges attached:

1. Same-day booking guardrails — non-refundable deposits for bookings made within 3 days of check-in. Estimated $800K–$2M saved in cancellation losses this quarter, based on the insight that 26.4% of July volume came from same-day bookings with a 40.8% cancel rate.
2. Mega-host relationship program — defensive, protects the $8.18M (31% of platform) concentrated in the top 169 hosts. Low-medium effort.
3. Off-season activation for 7,068 summer-only properties — the agent had already found that 39% of supply has literally zero bookings outside June-July. Ask stitched that to a recommendation the agent generated in the same run.
4. Urban destination acceleration — longer-term, but addresses the Q4/Q1 seasonal cliff.

It also added a "what I'd explicitly deprioritize" section that basically said: don't bother with pricing optimization this quarter, the structural problem is too big for a one-quarter fix. I didn't ask for that. It just did it.

The thing I want you to notice is that #3 cited both an insight ("Summer Seasonal Destinations Surge 135-217% Q1-to-Q2") and a separately-generated recommendation ("Launch Off-Season Activation Campaign"). Ask treats insights and recommendations as the same kind of thing for retrieval — they both get embedded, they both get searched, they both get cited. That matters when you're trying to answer "what should we do" because the agent already did that work in a previous run. You just need to be able to find it again.

The search is the thing​

I want to call out one specific query because it surprised me.

In a fresh session I asked: "What are the early signs a guest won't come back?"

None of the matched insights contain the phrase "early signs" or "won't come back" in their titles. What came back:

• 73.6% Single-Booking Guest Rate: 40,242 Guests Never Return
• 77% of Guests Who Cancel Never Rebook
• Two-Booking Guests Take 159 Days to Return
• Low-Rated Experiences Drive Churn: Guests With <2-Star Average Have Only 7.35% Repeat Rate

That's a semantic match, not a keyword match. The insight titles talk about "repeat booking," "rebook," "return," "retention." My question talks about "early signs" and "won't come back." Different words, same concept. The embedding model — text-embedding-3-large, in our case — handles that without anyone having to think about it.

The reason this matters: you don't have to remember how the agent phrased a finding to get back to it. You just have to remember roughly what it was about. Which is how humans actually remember things.

How it works under the hood​

Short version for the people who care.

When a discovery finishes, every insight and every recommendation gets embedded and stored in a vector database. We use Qdrant (which now ships as part of the default deployment). The embedding model is pluggable — OpenAI text-embedding-3-large is the default, but you can point it at whatever provider you prefer. The same provider abstraction we already have for LLMs and warehouses.

When you ask a question, here's what happens:

1. Your question gets embedded with the same model.
2. Qdrant returns the top-k nearest insights + recommendations by cosine similarity, filtered to your project so one customer can never see another customer's data.
3. The top results get passed to the LLM with a prompt that says: answer the user's question using only these sources, cite them like [1], [2], and if the sources don't cover the question, say so.
4. The answer and the list of raw sources come back together. The dashboard renders them side by side.

Multi-turn conversations work by replaying the last ten messages from the session as context, so the LLM knows what "that" and "above" and "those" refer to. Sessions belong to a specific project. They're stored in MongoDB alongside everything else. There's no separate infrastructure.

One thing worth saying: we use the same LLM provider you've already configured for discoveries. If you're running Claude Opus via Bedrock, that's what answers your questions. If you're running Ollama locally, that's what answers them. No new API keys, no new billing, no new secrets. That was a deliberate call — we didn't want Ask to require a "now also sign up for X" moment.

What it doesn't do​

Worth being explicit about the edges:

It doesn't write new SQL. If you ask it a question that isn't covered by your existing discoveries, you'll get a polite version of "I don't have data on that." The fix is to run another discovery, or add a new analysis area to your domain pack.

It doesn't cross projects. Each Ask session is scoped to one project. This is a privacy boundary — it's not something we'll loosen. If you need cross-project reporting, that's a different feature.

It doesn't replace the insights tab. If you're exploring, browse the insights directly. If you have a specific question, use Ask. They do different jobs.

It doesn't know about the future. It knows what your discoveries found, which is a snapshot of what your data looked like when the run happened. "What will happen next quarter" isn't a question it can answer, and it will tell you so.

How to try it​

If you're already running DecisionBox, pull the latest images and you'll get Ask automatically. The feature is part of the community release, AGPL v3, runs in your own infrastructure, no separate tier. You'll need Qdrant running, which the Helm chart provisions by default.

1. Navigate to a project with at least one completed discovery
2. Click the Ask tab in the sidebar
3. Type a question

That's it. There's nothing to configure. Your existing discoveries are already indexed on run completion — no backfill step, no migration, no "enable this feature" toggle.

If you don't have a project yet: pick a domain pack, connect a warehouse, hit run. Come back in ten minutes and start asking questions.

Where we're taking it​

A few things on the list. No promises on timing.

• Cited chart generation. When an answer references a trend over time, draw it. The data is already in the insight metrics, we just need to render it.
• Saved questions. Right now every session is free-form. Eventually you should be able to save "the five questions I check every Monday" and have them run against each new discovery automatically.
• Cross-discovery comparison. Right now a single question retrieves across all discoveries in a project, which is usually what you want. But being able to scope explicitly to "compare last week's run to this week's" is the obvious next step.
• Slack integration. Ask, but from the place where the question actually gets asked.

One last thing​

The reason I wrote this post the way I did is that I'm a bit allergic to the way AI features get talked about right now. "Revolutionary AI-powered conversational insights experience" — you can find that sentence on a dozen product landing pages this week and none of them mean anything.

Ask is a text box that helps you find stuff you already have. It's useful because the alternative is scrolling through 132 insight cards trying to remember which one had the 7.35% number. That's all it is. That's enough.

If you try it and it doesn't help, tell us what question it fell over on. That's the useful feedback. The email is can@decisionbox.io, or open an issue on the repo.

— Can

Links​

• GitHub Repository
• Documentation
• Ask API reference

TL;DR​

Domain packs are how DecisionBox knows what to look for in your data. From the dashboard, you can create a domain pack, edit it with a built-in markdown editor, export it as JSON to share with others, or import one someone else made. No restarts, no deploys — just save and run a discovery.

What Is a Domain Pack?​

A domain pack teaches DecisionBox's AI agent how to analyze a specific industry. Think of it as a recipe: it tells the agent what questions to ask, what patterns matter, and what context it needs about your business.

Every pack has four parts:

DecisionBox ships with built-in packs for E-Commerce, Gaming, Social Network, and Real Estate CRM. But you can create your own for any industry.

Browsing Your Packs​

Navigate to Domain Packs in the sidebar. Each pack appears as a card with its name, status (Published or Draft), number of categories and analysis areas, and version.

You can create a new pack, import one from a JSON file, export any pack, edit it, or delete it. Deleting a pack doesn't affect projects that already use it — they keep their own copy.

Inside a Domain Pack: E-Commerce​

Let's open the built-in E-Commerce pack to see how everything fits together.

General​

The basics: a slug (ecommerce), a name, a description, a version number, and a Published toggle that controls whether the pack shows up when creating new projects.

Categories​

Categories are sub-types within your domain. The E-Commerce pack ships with Multi-Category Store — for large retailers selling across electronics, appliances, fashion, and more.

You could add others like "Subscription Box" or "Marketplace", each with its own tailored prompts and analysis areas.

For comparison, the Gaming pack has three categories — Match-3, Idle, and Casual — because a puzzle game and an idle clicker need completely different analysis strategies.

Prompts​

This is where the magic happens. Prompts are markdown documents that tell the AI agent how to think about your industry.

There are three base prompts:

Base Context gives the agent background about the user's specific business. It includes {{PROFILE}} — the information the user filled in about their store (business model, KPI targets, product categories). If a user sets a 3% conversion rate target, the agent uses that to judge whether what it finds is a problem or not.

Exploration is the main prompt that drives autonomous SQL generation. It tells the agent what dataset to connect to, what tables are available, and lays out a phased strategy: start broad with baseline metrics, deep-dive into each analysis area, then look for cross-area correlations. It even includes example SQL queries tailored to e-commerce — conversion funnels, revenue by category, repeat customer behavior — so the agent hits the ground running.

Recommendations takes what the agent discovered and turns it into specific, actionable steps — with target segments, expected impact, and implementation details.

Each prompt is edited with a markdown editor that supports preview mode.

You can also write category-specific prompts. Select "Multi-Category Store" from the dropdown and you'll see an exploration context that tells the agent to focus on cross-category shopping behavior, brand dynamics, and price range diversity — things that only matter for large multi-category retailers.

The Gaming pack leans on this heavily: the Idle game context explains prestige cycles and offline earnings, while the Casual game context focuses on ad tolerance and onboarding funnels. Same domain, very different analysis.

Analysis Areas​

Analysis areas define what the agent should look for and how to interpret what it finds.

The E-Commerce pack has five areas — three at the base level (for all categories) and two specific to Multi-Category Store:

Each area includes its own detailed analysis prompt. For example, the Conversion Funnel prompt tells the agent to check cart abandonment by price range, compare category-level conversion, and estimate revenue at risk — and it defines what "critical" vs "medium" severity means for this type of insight.

The Gaming pack shows how category-specific areas work: Churn, Engagement, and Monetization apply to all game types, but ad_performance only activates for Casual games and economy only for Idle games.

Profile Schema​

The profile schema defines the form that users fill out when creating a project. It's a JSON Schema that gets rendered as a dynamic form in the project settings.

The E-Commerce pack asks about:

• Business: Industry, business model, target market, growth stage
• Product Catalog: Number of products, average price, categories, inventory model
• Shipping: Free shipping threshold, delivery time, return rate
• Payment: Accepted methods, supported currencies
• KPI Targets: Conversion rate, AOV, 30-day retention, CAC, LTV

The Multi-Category Store category adds extra fields for catalog depth, search and discovery features, and cross-sell/bundling capabilities.

All of this becomes the {{PROFILE}} that the agent receives in every prompt. The more context users provide, the more targeted the analysis — setting a conversion rate target of 3% means the agent flags anything below that as a problem.

Create Your Own​

Click New Pack and follow the same structure: general info, categories, prompts, analysis areas, and profile schema.

For example, a FinTech pack might have categories like "Neobank", "Lending", and "Payments", with analysis areas for transaction fraud, customer lifetime value, and churn prediction.

DecisionBox validates everything when you save — required template variables in prompts, analysis areas with prompts and keywords, valid slug format. Once saved, the pack is immediately available for new projects.

Sharing Packs​

Every pack can be exported as a single JSON file and imported elsewhere.

Export: Click Export on any pack card. The browser downloads a portable JSON file — no database IDs, no timestamps, just the pack definition.

Import: Click Import, upload a .json file or paste the JSON directly, and the pack is created.

This makes it easy to:

• Move packs between environments (staging to production)
• Share packs with your team or the community
• Keep pack definitions in version control alongside your code

What Happens When You Run a Discovery​

When a user creates a project, they pick a domain pack and category. DecisionBox copies the pack's prompts and analysis areas into the project — the project gets its own independent copy. The user fills in the profile form, clicks Run Discovery, and the agent takes it from there.

A few things worth noting:

• Changing a pack doesn't change existing projects. Projects snapshot the pack at creation time, so updates to a pack only affect new projects.
• Projects can be customized independently. You can tweak a project's prompts without touching the source pack.

What's Next​

• Community pack registry — browse and install packs with one click
• Pack versioning — track changes, diff, and rollback
• AI-assisted pack creation — describe your industry and let the AI draft prompts for you

Get Started​

DecisionBox ships with built-in packs seeded automatically on startup.

To create your own:

1. Navigate to Domain Packs in the sidebar
2. Click New Pack
3. Fill in your categories, prompts, analysis areas, and profile schema
4. Save — and start running discoveries

Or grab a JSON file from someone who already built a pack for your industry, and Import it.

• GitHub Repository
• Documentation
• Domain Packs Guide

PostgreSQL Support​

PostgreSQL is now a supported warehouse, making DecisionBox accessible to teams that don't use a cloud data warehouse. Connect with username/password or a connection string, with SSL mode configurable (default: require).

The PostgreSQL provider includes a comprehensive SQL fix prompt covering 13 error patterns that the AI agent commonly encounters — LATERAL joins, FILTER clauses, recursive CTEs, the NOT IN NULL trap, BETWEEN timestamp pitfalls, and more. Row count estimates use pg_class.reltuples for fast schema discovery without full-table scans.

Databricks Integration​

Databricks SQL warehouses are now supported via Unity Catalog. Two authentication methods are available:

• Personal Access Token (PAT) for quick setup.
• OAuth M2M (service principal) for production workloads.

The provider covers the full Databricks type system including complex types (STRUCT, ARRAY, MAP, VARIANT) and includes a dialect-specific SQL fix prompt for QUALIFY, PIVOT/UNPIVOT, Delta time travel, and the common yyyy vs YYYY date format pitfall.

Ecommerce Domain Pack​

The first domain pack outside of gaming brings AI-powered analysis to online stores. It covers five analysis areas:

• Conversion Funnel — Drop-off analysis from landing to purchase.
• Revenue & Pricing — Price sensitivity, discount effectiveness, AOV trends.
• Customer Retention — Cohort analysis, repeat purchase patterns, churn signals.
• Product & Category Performance — Top sellers, underperformers, cross-sell opportunities.
• Session & Browsing Behavior — Navigation paths, search patterns, device segmentation.

The pack includes a profile schema for capturing store context — business model, fulfillment method, marketing channels, and KPIs — so the agent tailors its analysis to your specific setup.

Plugin Middleware Hooks​

This release introduces a middleware system that lets enterprise plugins wrap core functionality without modifying community code:

• Warehouse Middleware (warehouse.RegisterMiddleware()) — Intercept warehouse calls for logging, access controls, or cost tracking.
• HTTP Middleware (apiserver.RegisterGlobalMiddleware()) — Wrap all API requests for audit logging or custom authentication.
• Agent Export (agentserver.Run()) — Build custom agent binaries that import your plugins and call the standard entry point.

These hooks power the enterprise auth plugin and are available for anyone building custom extensions.

Other Improvements​

• Per-model max output tokens — The agent now requests each model's full output capacity for recommendation generation instead of a fixed 8K limit.
• IP restriction — GKE, EKS, and AKS control plane access can be restricted to specific CIDR ranges via allowed_cidr_blocks in Terraform modules. The setup wizard auto-detects your public IP.
• Insight validation fix — Improved SQL fix prompt parsing and added missing schema context, increasing the success rate of automated insight validation.

Seamless Upgrade​

No breaking changes. Update your Docker images to v0.3.0 or pull the latest Helm charts:

helm repo update decisionbox
helm upgrade decisionbox-api decisionbox/decisionbox-api
helm upgrade decisionbox-dashboard decisionbox/decisionbox-dashboard

Get Started​

Check out the v0.3.0 release notes on GitHub. If you have suggestions or run into issues, join us on GitHub Discussions.

TL;DR​

We pointed DecisionBox at a Databricks SQL Warehouse connected to a vacation rental dataset (WanderBricks — 11 tables, 500K+ rows) and hit Run Discovery. Seventy-six minutes later, the AI agent had:

• Explored every table autonomously, writing and executing 92 SQL queries during exploration alone
• Identified 67 insights across 7 analysis areas — 17 critical, 18 high severity
• Validated each claim with independent SQL queries — 21 confirmed exactly, 12 adjusted with corrected numbers
• Discovered a $5.8M revenue leak from cancellations, a 28.8% cancellation spike driven by same-day bookings, and an 80% host onboarding failure rate

No one told it what to look for. No one wrote a single query. The agent figured it all out.

The Setup: Databricks + DecisionBox in 5 Minutes​

DecisionBox connects directly to your Databricks SQL Warehouse. The setup is three fields:

We pointed it at the samples.wanderbricks schema — a vacation rental marketplace dataset with 11 tables covering users, hosts, properties, destinations, bookings, payments, reviews, clickstream, page views, support logs, and booking updates.

Then we configured the AI model (Claude Opus via Vertex AI) and hit Run Discovery.

That's it. No metric definitions. No dashboard templates. No SQL.

What Happened Next: The AI Agent at Work​

DecisionBox's discovery agent is a Go binary that connects to your warehouse and runs an autonomous multi-phase analysis. Here's what it did with the WanderBricks dataset:

Phase 1: Exploration (92 queries)​

The agent started by sampling every table (SELECT * FROM ... LIMIT 5) to understand the schema. Then it got to work — progressively writing more complex queries to build a complete picture of the business:

-- Step 3: Baseline metrics
SELECT MIN(created_at) AS earliest_booking,
       MAX(created_at) AS latest_booking,
       COUNT(*) AS total_bookings,
       COUNT(DISTINCT user_id) AS total_guests,
       COUNT(DISTINCT property_id) AS total_properties,
       AVG(total_amount) AS avg_booking_value
FROM `wanderbricks.bookings`

-- Step 22: Spotting the July cancellation spike
SELECT DATE_TRUNC(created_at, MONTH) AS booking_month,
       COUNT(*) AS total_bookings,
       ROUND(SUM(CASE WHEN status = 'cancelled' THEN 1 ELSE 0 END)
             * 100.0 / COUNT(*), 1) AS cancel_rate
FROM `wanderbricks.bookings`
WHERE created_at >= '2025-04-01'
GROUP BY 1
ORDER BY 1

When it saw the July cancellation rate spike to 28.8% (up from ~20%), it didn't stop there. It immediately drilled into why — investigating lead times, same-day bookings, destination breakdowns, and property type correlations. All autonomously.

-- Step 25: Investigating cancellation timing
SELECT CASE
         WHEN TIMESTAMP_DIFF(b.check_in, b.updated_at, DAY) > 30
           THEN '30+ days before'
         WHEN TIMESTAMP_DIFF(b.check_in, b.updated_at, DAY) > 7
           THEN '7-30 days before'
         WHEN TIMESTAMP_DIFF(b.check_in, b.updated_at, DAY) > 0
           THEN '1-7 days before'
         ELSE 'Same day'
       END AS cancel_timing,
       COUNT(*) AS cancellations
FROM `wanderbricks.bookings` b
WHERE status = 'cancelled'
  AND created_at >= '2025-06-01'
GROUP BY 1

Finding: 71% of cancellations happen the same day or day before check-in. The agent flagged this as "devastating for hosts."

Phase 2: Analysis (74 steps)​

The agent took everything it learned during exploration and produced structured insights across 7 business areas:

Each insight includes severity, affected count, confidence score, risk score, specific metrics, and supporting indicators — all derived from the data, not predefined templates.

Phase 3: Validation (67 steps)​

This is where DecisionBox differentiates itself from "AI that generates reports." Every single insight gets validated. The agent writes a fresh, independent SQL query — different from the one that discovered the finding — and runs it against the warehouse to verify the numbers.

For example, the "July 2025 Cancellation Spike" insight was validated with this query:

SELECT
  COUNT(*) AS total_july_bookings,
  SUM(CASE WHEN status = 'cancelled' THEN 1 ELSE 0 END) AS cancelled_bookings,
  ROUND(SUM(CASE WHEN status = 'cancelled' THEN 1 ELSE 0 END)
        * 100.0 / COUNT(*), 1) AS cancellation_rate_pct,

  -- Same-day bookings
  SUM(CASE WHEN DATEDIFF(check_in_date, booking_date) = 0 THEN 1 ELSE 0 END)
    AS same_day_bookings,

  -- Same-day cancellation rate
  ROUND(SUM(CASE WHEN DATEDIFF(check_in_date, booking_date) = 0
                  AND status = 'cancelled' THEN 1 ELSE 0 END) * 100.0
        / NULLIF(SUM(CASE WHEN DATEDIFF(check_in_date, booking_date) = 0
                     THEN 1 ELSE 0 END), 0), 1) AS same_day_cancel_rate_pct

FROM `wanderbricks.bookings`
WHERE YEAR(booking_date) = 2025
  AND MONTH(booking_date) = 7

Result: Confirmed. 2,979 cancelled bookings. 28.8% cancellation rate. Numbers match exactly.

Of the 67 insights:

• 21 confirmed — numbers matched exactly
• 12 adjusted — the insight was directionally correct but the validation query found slightly different numbers (the agent updates the insight with the corrected count)
• 1 rejected — the claim didn't hold up under validation and was flagged

The 5 Most Impactful Discoveries​

1. $5.8M Revenue Leakage from Cancellations (22% of Gross)​

In 2025, 10,492 cancelled bookings represented $5.81M in lost revenue — 22% of the $26.4M total. But the real story was why: same-day bookings surged from 3% of volume in April to 26.4% in July, and these carry a 40.8% cancellation rate.

The agent traced the full causal chain:

• Average lead time collapsed from 52.6 days (April) → 5.9 days (July)
• 71% of cancellations happen same day or day before check-in
• Refund rate climbed from 7% to 9.27% in July ($624K refunded)
• Realized revenue (completed + confirmed) is only $9.1M of $26.4M gross — a 34.4% realization rate

Severity: Critical | Confidence: 95% | Validation: Confirmed

2. 80% of Hosts Never List a Property​

14,273 out of 17,764 registered hosts (80.3%) have zero properties on the platform. The host activation rate has been stuck between 17-21% across every quarterly cohort since Q1 2023 — no improvement over 2.5 years.

The agent dug deeper and found the geographic driver: India (6,564 hosts, 2.1% activation) and China (6,330 hosts, 3.8% activation) represent 72.6% of all hosts but only 2.96% of them have listings. Meanwhile, hosts from destination countries show dramatically higher activation — Thailand at 88.7%, France at 82.9%, Italy at 82.0%.

Severity: Critical | Confidence: 95% | Validation: Adjusted (verified 15,567)

3. 43.7% of Bookings Stuck in "Pending" — Never Confirmed​

Of 72,244 total bookings, 31,575 (43.7%) remain in pending status. Only 10.3% ever reach "completed." The agent calculated that realized revenue is only $9.1M out of $26.4M in gross booking value — 65.6% of booking value is unrealized.

Severity: Critical | Confidence: 92% | Validation: Confirmed (31,575 exactly)

4. Guest Satisfaction Crisis: 3.01 Average vs 4.5 Target​

The platform-wide average review rating is 3.01 — 33% below the 4.5 target. What makes this remarkable is how uniformly bad it is: the agent checked every dimension and found the same 3.0 rating across all destinations, all property types, all price tiers, and all time periods.

The agent also connected this to retention: guests with 1-2 star average reviews have a 7.35% repeat rate vs 25.6% for those with 3-4 star averages.

Severity: Critical | Confidence: 97% | Validation: Confirmed (99,185 reviews)

5. 1.84% Occupancy Rate vs 65% Target​

Across 10,758 properties over 12 months, only 72,200 nights were booked from 3.93M available — 1.84% occupancy. The average property gets 6.7 booked nights per year. The platform has approximately 35x more supply than demand.

Severity: Critical | Confidence: 90% | Validation: Adjusted (18,163 properties counted)

Why This Matters for Databricks Users​

If you're using Databricks, your data warehouse already has the answers to your most important business questions. The problem is that finding them requires:

1. Knowing what to ask — an analyst needs to hypothesize "maybe same-day bookings are driving cancellations" before writing the query
2. Writing the SQL — Databricks SQL is powerful but someone has to write it
3. Connecting the dots — the cancellation spike, the lead time collapse, the refund rate increase, and the host activation failure are all related, but different teams would typically investigate them in isolation
4. Validating the findings — dashboards show numbers but don't verify whether those numbers actually support the conclusion

DecisionBox does all four autonomously. It connects directly to your Databricks SQL Warehouse, explores your data without any guidance, and comes back with validated, actionable insights.

What the Agent Did That a Dashboard Can't​

The agent's reasoning chain during exploration is what sets this apart. When it saw a 28.8% cancellation rate in July, it didn't just flag the number — it:

1. Compared July to prior months to confirm it was anomalous
2. Checked if the spike was isolated to specific property types (it wasn't)
3. Investigated booking lead times and discovered the same-day surge
4. Calculated the cancellation rate by lead time bucket to prove causation
5. Cross-referenced with refund data to quantify the financial impact
6. Checked if host ratings correlated with cancellations (they didn't)
7. Looked at destination-level patterns to see if it was geographic (Byron Bay 37.2%, London 34.5%)

That's 7 layers of investigation, each informed by the previous one. A dashboard would show you the 28.8% number. The agent tells you why it happened.

The Numbers​

Try It Yourself​

DecisionBox is open source (AGPL v3) and available on GitHub.

To run the same analysis on your Databricks warehouse:

1. Deploy — docker compose up for local, or use our Helm charts for Kubernetes
2. Connect — Add your Databricks SQL Warehouse host, HTTP path, and PAT
3. Discover — Hit Run Discovery and let the agent work

The agent works with any Databricks catalog and schema. It adapts to your data — no domain-specific configuration required for the general discovery mode.

Supported Warehouses​

DecisionBox isn't limited to Databricks. It also connects to:

• Snowflake — Username/password or key pair auth
• BigQuery — ADC or service account key
• Redshift — IAM role, access keys, or assume role
• PostgreSQL — Standard connection

What's Next​

This was a general discovery run — no domain pack, no pre-defined analysis areas. DecisionBox also supports domain packs that bring industry-specific knowledge to the analysis. Our gaming and social domain packs, for example, know about retention cohorts, monetization funnels, and engagement metrics specific to those industries.

We're building domain packs for travel, e-commerce, SaaS, and fintech next. If you're interested in contributing or have a dataset you'd like to see analyzed, open a discussion on GitHub.

DecisionBox is an open-source AI-powered data discovery platform. It connects to your data warehouse, runs autonomous AI agents, and surfaces validated insights — no SQL, no dashboards, no manual analysis. Star us on GitHub

Before jumping into a hands-on tutorial, let's talk about what DecisionBox is and why we built it.

The Problem: Your Data Knows More Than You're Asking​

Every data team has the same bottleneck: insights only come from questions someone thought to ask. A PM has a hunch, an analyst writes queries, iterates, reports back. It's serial and slow. And the biggest problem? It only finds answers to questions someone thought to ask.

What DecisionBox Does​

DecisionBox flips this process. Instead of humans writing queries to answer specific questions, an AI agent autonomously explores your data and tells you what it found.

Here's how it works — three steps:

Connect your warehouse — BigQuery, Redshift, Snowflake, Databricks, PostgreSQL. No data transfer, no schema migration. Your data stays where it is.

Discover — The agent discovers your schema, writes SQL queries, executes them, and iterates based on results. Dozens of queries per run, each building on the last. Not a chatbot — an autonomous investigator.

Act on what it finds — Insights with severity, affected counts, and confidence scores. Recommendations with expected impact, target segments, and implementation steps.

Validate — This is where DecisionBox differs from other AI analytics tools. Any LLM can generate plausible-sounding findings. DecisionBox verifies them. Every insight goes through two independent validation passes against your actual data: one catches inflated numbers, the other generates entirely new SQL queries to confirm each finding from a different angle. Insights come back as confirmed, adjusted with corrected numbers, or rejected. Every query and reasoning step is fully auditable. No black box.

The platform is industry-agnostic, but domain packs give the agent specialized expertise per industry (E-commerce, Gaming, Social Networks today — open source means anyone can add more). It's licensed under AGPL v3, deploys on your infrastructure, and works with your choice of LLM provider — Claude, OpenAI, Azure AI Foundry, Vertex AI, Bedrock, or local models via Ollama.

Let's See It in Action​

The best way to understand DecisionBox is to use it. In the rest of this post, I'll walk you through a complete end-to-end tutorial:

1. Set up DecisionBox locally (3 commands, 5 minutes)
2. Import a real e-commerce dataset from Kaggle into Amazon Redshift Serverless
3. Create a project with the E-commerce domain pack
4. Run a discovery and explore the results

By the end, you'll have a completed AI discovery run with real insights from real data — and a clear picture of how DecisionBox works.

What You'll Need​

• Docker Desktop (Docker 24+ with Compose v2+)
• An AWS account with permissions to create Redshift Serverless resources and S3 buckets
• An Anthropic API key for Claude (console.anthropic.com)
• A Kaggle account to download the dataset

Step 1: Set Up DecisionBox Locally​

DecisionBox runs as three services — an API server, a dashboard, and MongoDB — all orchestrated with Docker Compose.

git clone https://github.com/decisionbox-io/decisionbox-platform.git
cd decisionbox-platform
docker compose up -d

That's it. After about 10 seconds, open http://localhost:3000 and you should see the DecisionBox dashboard.

You can verify everything is healthy:

curl http://localhost:8080/health/ready

You should get a 200 OK response.

Step 2: Get the Dataset​

We'll use the eCommerce Behavior Data from Multi Category Store dataset from Kaggle, provided by REES46 Marketing Platform via their Open CDP project. It contains real behavioral data from a large multi-category online store (similar to Amazon or eBay).

Download both CSV files:

• 2019-Oct.csv (~5.6GB, ~42M events)
• 2019-Nov.csv (~9.5GB, ~67M events)

Each row is a single event with these columns:

This is a rich dataset for e-commerce analysis — it has the full purchase funnel (view → cart → purchase), product categorization, pricing, and session-level behavior.

Step 3: Set Up Amazon Redshift Serverless​

We need somewhere to put this data so DecisionBox can query it. We'll use Amazon Redshift Serverless — it's pay-per-query, requires no cluster management, and takes a few minutes to set up.

3.1 Create a Redshift Serverless Endpoint​

1. Open the Amazon Redshift console and select Serverless dashboard from the left menu
2. Click Create workgroup
3. Give your workgroup a name (e.g., decisionbox-tutorial)
4. Under Namespace, create a new namespace (e.g., decisionbox-tutorial-ns)
5. Set an admin username and password — you'll need these later
6. Keep the default settings for everything else and click Create
7. Wait 2-3 minutes for the workgroup to become Available

3.2 Upload CSVs to S3​

Redshift loads data from S3, so we need to upload our CSVs first.

1. Open the S3 console and create a new bucket (e.g., decisionbox-tutorial-data) in the same region as your Redshift workgroup
2. Upload both CSV files to the bucket:
   • s3://decisionbox-tutorial-data/2019-Oct.csv
   • s3://decisionbox-tutorial-data/2019-Nov.csv

3.3 Set Up IAM Permissions​

Your Redshift namespace needs an IAM role that can read from S3:

1. Go to IAM → Roles → Create role
2. Select Redshift - Customizable as the trusted entity
3. Attach the AmazonS3ReadOnlyAccess policy
4. Name it (e.g., redshift-s3-read-role) and create it
5. Back in the Redshift Serverless console, go to your Namespace → Security and encryption → Manage IAM roles
6. Associate the role you just created

3.4 Create the Table and Load Data​

Open the Redshift Query Editor v2 from the Serverless console (or use any SQL client) and run:

CREATE TABLE ecommerce_events (
    event_time      TIMESTAMP,
    event_type      VARCHAR(20),
    product_id      BIGINT,
    category_id     BIGINT,
    category_code   VARCHAR(256),
    brand           VARCHAR(256),
    price           DECIMAL(10,2),
    user_id         BIGINT,
    user_session    VARCHAR(64)
);

Now load both CSV files:

COPY ecommerce_events
FROM 's3://decisionbox-tutorial-data/2019-Oct.csv'
IAM_ROLE 'arn:aws:iam::<YOUR_ACCOUNT_ID>:role/redshift-s3-read-role'
CSV
IGNOREHEADER 1
TIMEFORMAT 'auto'
REGION 'us-east-1';

COPY ecommerce_events
FROM 's3://decisionbox-tutorial-data/2019-Nov.csv'
IAM_ROLE 'arn:aws:iam::<YOUR_ACCOUNT_ID>:role/redshift-s3-read-role'
CSV
IGNOREHEADER 1
TIMEFORMAT 'auto'
REGION 'us-east-1';

Replace <YOUR_ACCOUNT_ID> with your AWS account ID and adjust the region if needed.

The load takes roughly 5-10 minutes per file. Once done, verify:

SELECT COUNT(*) FROM ecommerce_events;
-- Should return ~109M rows (42M Oct + 67M Nov)

SELECT event_type, COUNT(*) as cnt
FROM ecommerce_events
GROUP BY event_type
ORDER BY cnt DESC;

3.5 Configure Network Access​

For DecisionBox running locally to reach your Redshift endpoint, you need to make it publicly accessible:

1. In the Redshift Serverless console, go to your Workgroup → Data access → Network and security
2. Turn on Publicly accessible
3. Make sure the associated security group allows inbound traffic on port 5439 from your IP address

Note: For a production setup, you'd use VPC peering or a private endpoint. For this tutorial, public access is fine — just restrict the security group to your IP.

Step 4: Create a Project in DecisionBox​

Now for the fun part. Go back to the DecisionBox dashboard at http://localhost:3000 and click Create Project.

4.1 Basic Configuration​

• Name: Give it something descriptive, like "E-Commerce Kaggle — Multi-Category Store"
• Domain: Select Ecommerce
• Category: Select Multi-Category Store

As we covered earlier, the domain and category determine which domain pack the AI agent uses. The E-commerce / Multi-Category pack includes five analysis areas:

• Conversion Funnel — View-to-cart-to-purchase rates, cart abandonment patterns
• Revenue & Pricing — Revenue trends, average order value, pricing dynamics
• Customer Retention — Repeat purchase behavior, customer lifecycle stages
• Product & Category Performance — Category conversion gaps, cross-category affinity, brand performance
• Session & Browsing Behavior — Browse patterns, session depth, discovery-to-action paths

4.2 Data Warehouse Configuration​

• Provider: Select Amazon Redshift
• Workgroup Name: decisionbox-tutorial (or whatever you named it)
• Database Name: dev (the default Redshift database)
• Region: Your AWS region (e.g., us-east-1)
• Authentication: Select Access Keys and enter the admin credentials you set up in Step 3.1

4.3 AI Provider Configuration​

• LLM Provider: Select Claude
• Model: Enter claude-sonnet-4-6
• API Key: Paste your Anthropic API key

Claude Sonnet 4.6 is a strong balance of speed and quality for discovery runs. A typical 100-step run costs about $1-3 in API usage.

4.4 (Optional) Fill in the Project Profile​

Navigate to the Profile tab. The domain pack generates a profile form specific to your store type — business info, product catalog, shipping, KPIs, and more. Filling this in gives the AI agent richer context for better-targeted analysis.

For this tutorial dataset, you might enter:

• Business Model: B2C
• Industry: General Retail / Consumer Electronics
• Target Market: Global
• Total Products: ~200,000+
• Top Categories: Electronics, Appliances, Computers

The more context you provide, the more tailored the insights will be. But it's entirely optional — the agent will discover the data structure on its own.

Step 5: Run Your First Discovery​

Click "Run Discovery" from the top bar of your project page.

You'll see a configuration panel:

• Exploration Steps: Set to 10 for a quick first run. This controls how many exploration queries the AI agent will execute. You can increase it later for deeper analysis (the default is 100).
• Areas: Select "Run All Areas" to analyze all five e-commerce areas.

Click Start and watch the agent work.

What's Happening Behind the Scenes​

The discovery run follows a structured lifecycle:

1. Schema Discovery — The agent connects to your Redshift endpoint and discovers all tables, columns, and data types. It doesn't need you to describe your schema — it figures it out.

2. Autonomous Exploration — This is the core of the process. The agent writes SQL queries, executes them, reads the results, and decides what to explore next. It starts broad (total events, date ranges, customer counts) and drills into specific patterns (cart abandonment by price range, conversion rates by category, repeat purchase behavior).

3. Analysis — After exploration, the agent runs structured analysis for each of the five areas. It takes the exploration results relevant to each area and produces specific, validated insights.

4. Validation — Every insight goes through two independent validation passes. First, a user count validator ensures affected counts are realistic (not event counts mistaken for user counts). Second, a warehouse verifier generates fresh SQL queries to independently confirm each insight's numbers.

5. Recommendations — Finally, the agent synthesizes all validated insights into actionable recommendations — specific actions your team could implement, with expected impact and implementation steps.

The dashboard shows real-time progress: a progress bar, the current phase, live query counts, and a timeline of the agent's actions. You can see exactly what the agent is thinking and querying at each step.

Even with just 10 exploration steps, our run took about 30 minutes and produced 33 insights and 6 recommendations. Most of that time is the agent waiting for Redshift query results — the AI reasoning itself is fast. Increasing the step count lets the agent dig deeper, but even a short run surfaces meaningful patterns.

Step 6: Explore the Results​

Once the run completes, navigate to Insights and Recommendations in the sidebar to explore what the agent found.

Insights​

Insights are the discovered patterns — the agent's answer to "what's going on in this data?" Each insight belongs to one of the five analysis areas and includes:

• Severity (critical / high / medium / low) — how urgent this is
• Affected Count — how many unique customers are impacted
• Confidence — how statistically reliable the observation is (0-100%)
• Validation Status — whether the numbers were independently confirmed

Click on any insight to see the full detail. Each insight page includes a description with exact numbers, key indicators, a metrics table, an assessment section with risk score and confidence, validation results showing claimed vs. verified counts, and — at the bottom — a "How This Insight Was Found" section that shows the exact source queries the AI used, complete with the agent's reasoning and the SQL it wrote.

Recommendations​

While insights tell you what's happening, recommendations tell you what to do about it. The agent synthesizes insights across all areas and produces specific, actionable recommendations with:

• Priority (P1-P4) — what to address first
• Expected Impact — quantified improvement estimate with reasoning
• Implementation Steps — numbered steps specific enough for a product team to execute
• Related Insights — which discovered patterns this recommendation addresses

Full Audit Trail​

DecisionBox is designed to be fully transparent. There's no separate "transparency" tab because transparency is woven throughout the product:

• The Discovery runs page shows a live, step-by-step log of every action the agent took — what it was thinking, what SQL it wrote, what results it got, and whether queries were auto-fixed
• Each Insight includes a "How This Insight Was Found" section with the exact source queries and reasoning
• Validation results show claimed vs. verified counts for every insight, with the status clearly marked (confirmed, adjusted, or rejected)

Your data team can trace any finding from recommendation back to insight, back to the SQL queries that produced the data. Nothing is a black box.

Feedback​

Found an insight that's particularly valuable? Click the thumbs up. See something off? Thumbs down. This feedback trains the agent for subsequent runs — it will avoid repeating disliked patterns and continue monitoring liked ones. Each discovery run builds on the last.

Key Concepts at a Glance​

This tutorial introduced several DecisionBox concepts. Here's a quick reference:

What Just Happened​

Let's step back and look at what we did. We pointed DecisionBox at a dataset it had never seen before — 109 million raw e-commerce events with no documentation, no data dictionary, no context. The AI agent figured out the schema on its own, explored the data systematically across five analysis areas, discovered specific patterns with exact numbers, validated every finding against the actual data, and produced prioritized recommendations with implementation steps.

With just 10 exploration steps, the discovery took about 30 minutes and produced 33 insights and 6 recommendations — fully autonomous, no human input after clicking "Start." The equivalent manual process — an analyst writing queries, iterating, validating, synthesizing findings into a report — would take days to weeks.

And this was a first run. Subsequent runs build on previous context. The agent learns what it already found, avoids repeating itself, respects your feedback, and focuses on new patterns. Each discovery compounds.

Try It Yourself​

DecisionBox is open source under AGPL v3.

• GitHub: github.com/decisionbox-io/decisionbox-platform
• Documentation: decisionbox.io/docs
• Website: decisionbox.io

Clone it, docker compose up -d, and run your first discovery. Questions, feedback, or issues? Open a GitHub Discussion or file an issue — we'd love to hear what you discover.

Snowflake Integration​

Snowflake is now a first-class citizen in the DecisionBox ecosystem. We've added full support for:

• Username/Password authentication for quick setup.
• Key Pair (JWT) authentication for secure, production-grade connections.
• Type Mapping: Robust handling of all major Snowflake data types (NUMBER, VARIANT, DATE, TIMESTAMP, etc.).
• Efficient Discovery: Uses Snowflake metadata queries to explore schemas without impacting performance.

Azure Cloud Support​

Azure joins GCP and AWS as a supported cloud provider. This includes:

• Azure AI Foundry: Support for GPT-4o and other models via Azure's enterprise LLM platform.
• Azure Key Vault: Securely store and manage your credentials using Azure's native secret management service.
• Terraform Module: A dedicated Terraform module for provisioning AKS (Azure Kubernetes Service) and all related infrastructure.

Improved Authentication Experience​

We've introduced a structured approach to authentication. Warehouse providers now declare their supported auth methods via metadata. This allows the DecisionBox dashboard to:

• Render provider-specific forms for a better user experience.
• Validate configuration before it's submitted.
• Dynamically update the UI based on the selected auth method (e.g., showing fields for Key Pair vs. Password).

Helm Chart Improvements​

• Azure Workload Identity: Support for Azure Workload Identity webhooks, including new labels for service accounts and pods.
• Enhanced Configuration: More flexible Helm values for managing cloud-specific integrations.

Seamless Upgrade​

This release contains no breaking changes. Existing v0.1.0 deployments can upgrade to v0.2.0 without any modifications, and you can opt into the new Snowflake and Azure features as needed.

Get Started​

Check out the v0.2.0 release notes on GitHub to get started.

We're continuing to build towards our v0.3.0 milestone. If you have any suggestions or encounter any issues, please reach out to us on GitHub Discussions.

What is DecisionBox?​

DecisionBox bridges the gap between raw data and actionable insights. Unlike traditional BI tools that require manual dashboard building and SQL writing, DecisionBox uses autonomous agents to:

1. Explore: Automatically sample and understand your data schema.
2. Analyze: Identify patterns, anomalies, and opportunities across different business areas.
3. Validate: Verify every finding with independent SQL queries to ensure accuracy.

Key Features in v0.1.0​

Multi-LLM Support​

Connect to the models of your choice. v0.1.0 supports:

• Claude (Anthropic)
• OpenAI (GPT-4o/GPT-4-turbo)
• Ollama (Local models)
• Vertex AI (Claude & Gemini)
• Bedrock (Claude & Titan)

Warehouse Providers​

Start discovering insights from:

• BigQuery: Includes dry-run cost estimation to keep your analysis budget-friendly.
• Redshift: Full support for both Serverless and Provisioned clusters.

Enterprise-Grade Security​

• Secret Management: Integration with GCP Secret Manager, AWS Secrets Manager, and encrypted local storage via MongoDB (AES-256).
• Non-Root Containers: All services run as non-root (UID 1000) with read-only filesystems.

Domain Packs​

industry-specific analysis is powered by Domain Packs. Initial support includes:

• Gaming: Specialized analysis for Match-3, Idle, and Casual games.
• Social Networks: Insights focused on content sharing and user engagement.

Infrastructure & Deployment​

• Docker Compose: For quick local evaluation.
• Helm Charts: Production-ready deployment to Kubernetes.
• Terraform: Modules for GCP (GKE) and AWS (EKS).

Quality and Reliability​

We believe in software that works. v0.1.0 ships with:

• 500+ Tests: Comprehensive unit and integration testing.
• 85%+ Coverage: High confidence in core logic.
• CI/CD: Robust pipeline with vulnerability scanning and SBOM generation.

Get Started​

DecisionBox is open-source (AGPL v3). You can find the code and installation instructions on GitHub.

We'd love to hear your feedback! Join the conversation in our GitHub Discussions.