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.
Native Query
Flows
Triggers
Clusters every run by the shape of its path. Not only the failures.
See every path shape in one Sankey diagram. Loops and stalls show up as patterns, not one-off incidents, each with metrics like error rate, latency and token cost.
Path Shapes
Clusters runs by execution path, labels carried alongside.
>
A thousand occurrences become one shape
>
The fix list orders by size, not by who complained
Path Funnels
Shows where runs diverge, loop or stall.
>
Find the step that loses the run
>
The same funnel an analyst already knows how to read
Cohort Analysis
Cohorts on intent, sentiment, behavior, error, latency or cost.
>
Compare one cohort against overall traffic
>
Slice by what the run was trying to do, not just how it ended
Polaris Evaluator
In-house small language model. Labels every span.
>
A failure with a clean status still gets a label
>
Kubit’s own model, so no third-party LLM credit bill
>
Fine-tune it on your own account
Try it on the traces already in your warehouse.
Label the spans, group the shapes, name the signal, join the outcome.
Every span labeled, every shape drawn
Polaris labels every span, so a failure that returns a clean status still carries a label. Flows then groups the whole population by the shape of the execution path.
Every pattern comes with its signals
Once a pattern is detected, Triggers shows signals you can verify: what changed, what's overrepresented, which label cluster, and what came earlier.
All of it runs where the traces already sit
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 or Snowflake 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 AND SNOWFLAKE · BIGQUERY AND CLICKHOUSE IN Q4
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-path shapes, ranked, with the signals 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
>
Related commits: October. Traces a pattern to the commit, the diff and the error-rate jump after it shipped
>
Bring Your Own Warehouse for agent traces: Q4. Through OTel integration write-back, with BigQuery and ClickHouse arriving alongside
>
Monitoring: Q4. Regressions, fix checks and drift, after a trigger is addressed
Be first to see every agent run as one picture.
7 places in the first cohort. Applications close October 26.





THESE TEAMS ALREADY RUN KUBIT PRODUCT ANALYTICS IN THEIR WAREHOUSE








