PROBLEM
Tens of thousands of runs a week, opened one trace at a time. The failures that matter get found by customers first.
The dashboard is green yet the product is broken
Every span returns OK, so quality failures never reach a screen. The customer finds them first.
No way to tell a big problem from a loud one
Every occurrence arrives as its own trace. The fix list gets ordered by who complained, not by what is costing the most.
Agent behavior and business data live apart
The warehouse holds the traces and the revenue tables. Every question that joins the two becomes a data-engineering ticket.
PLATFORM
Query the agent traces already in your warehouse. Nothing to install.
The traces are already in your warehouse. Kubit queries them there. No SDK, no pipeline.
Databricks Native
Reads MLflow traces and evals in Unity Catalog.
No SDK to import
No pipeline to build
Snowflake Native
Reads AI_OBSERVABILITY_EVENTS and GET_AI_EVALUATION_DATA.
Cortex Agents traces, read in place
Evaluation data lands beside the traces
BigQuery & ClickHouse Native
Kubit queries your BigQuery or ClickHouse trace tables directly.
Queries run in your own account
No second copy to secure
Trace File Upload
Same analysis, no warehouse needed.
Try it before connecting anything
Polaris labels and Flows work the same on an uploaded file
Outcome Joins
Joins agent actions to user activity, a/b tests and campaigns.
See which execution paths actually convert
Traces and revenue tables join in one SQL query
WHY KUBIT
Label each span, group by execution path, in your warehouse.
Every span is labeled, including OK ones.
Polaris, Kubit’s in-house small language model, labels what every span did and whether it worked. Flows then groups all runs that called the same tools in the same order.
Every failure comes with its triggers.
For each failing execution path, Triggers shows the change deployed before it and the attributes, like model version or user segment, most common in its failed runs.
All of it runs as queries in your own warehouse.
No SDK, no pipeline. Your warehouse already holds user activity, A/B tests and campaigns, so you can tie what the agent did to the outcomes that followed.
Your traces stay in your warehouse.
Kubit queries your agent traces in place, inside your own Databricks, Snowflake, BigQuery or ClickHouse account. There's nothing to copy and nothing new to secure.
Your Account, Your Permissions · Nothing Copied · OTel to Your Warehouse in Q4


QUERY TRACES IN DATABRICKS, SNOWFLAKE, BIGQUERY AND CLICKHOUSE
FAQ
Questions We Often Get
We already have an observability tool. What is Kubit for?
Kubit works on the traces already stored in your warehouse, and standard OTel collection can write them there directly. Try this on your current tool: ask for last week's ten most common execution paths, ranked by run count, with the change and attributes behind each one. Then see what comes back.
Why not just use what is built into Databricks or Snowflake?
Could we not build this ourselves?
What does labeling every span cost us?
Should we trust a cluster label enough to act on it?
It is a crowded space. What is actually different?
Do I have to install another SDK?
Coming Soon in the Roadmap
7 places in the first cohort. Applications close October 30.
THESE TEAMS ALREADY RUN KUBIT PRODUCT ANALYTICS IN THEIR WAREHOUSE










