The self-improving source of truth for business data.
SignalPilot keeps your business context, dbt models, and evals current, and reruns the graded questions on every data-model change. Your team and your agents get answers with the evidence graph behind them.
SignalPilot
One source of truth
Post-agent data stack
Asking got cheap. Trusting the answer did not.
Two patterns we see in every mid-market and enterprise data team since Claude Code. Both explain why adoption stalls.
- Agent writes the SQLagent
- Analyst explains the contextanalyst
- Analyst checks the resultanalyst
- Answer, two days lateryou
- Agent writes the SQLagent
- Agent guesses the definitionagent
- Wrong answer in 5 minutesagent
- No evidence. Nobody acts on it.you
- Agent loads the approved contextagent
- Governed query in the sandboxsystem
- Rubric checks passsystem
- Answer with its evidence graphyou
"I told my team that if the number is not from one of the trusted dashboards we maintain, don't assume the number from your agent is right."
The third pattern
The most AI-forward data teams converged on the same architecture.
Semantic context, continuous evals, lineage, and sandboxed agents. Not a faster version of the old workflow, and not agents left to guess. That is the stack SignalPilot builds and maintains for you.
Inside our in-house data agent
How OpenAI's data team built an agent on shared context and continuous checks.
Read the post ↗Self-service data analytics with Claude
Semantic context and evals took the data team from 21% to 95%+ accuracy.
Read the post ↗RampThe shape and feel of the post-AI data stack
Ramp's head of data on semantic layers, lineage, and agents that run in sandboxes.
Read the post ↗Not a text-to-SQL problem
A context, business taste, and trust problem.
Data practitioners are moving from answering every question themselves to encoding business context and standards for correctness, then orchestrating agents that query, reason, and act.
It is in your schemas, dbt models, trusted dashboards, and the queries behind them. Scattered, sometimes in conflict, and it does not carry over when someone asks their agent a question.
Authoring semantic knowledge, writing evals, running sandboxed agents, and catching regressions as the data changes. Most teams cannot staff all of it, and keeping it current is ongoing work.
Our agents and engineers author the source of truth from what you already have, prove it with evals, and run the loop. Your data team reviews and approves instead of writing from scratch.
The four parts
Four parts, one system.
No capacity to run the loop yourself? A SignalPilot engineer runs it, with a 90% precision guarantee. Managed →
Context, maintained
Definitions authored from your dbt models, dashboards, and queries. You approve; the agent keeps them current.
Learn more →Evals on every change
Graded questions, anchored in a gold value and the approved definition, rerun on every pull request. Nothing merges until they pass.
Learn more →Cloud Agent Harness
One shared, sandboxed agent with all your context and governed access, from Claude Cowork, Codex, Slack, or the web. An evidence graph on every answer.
Learn more →Self-improving loop
Thumbs-downs and new questions become proposed context and regression tests, reviewed before they join the system.
Learn more →How a deployment runs
We start from what you already have.
We do not ask your data team to document everything they know or build another agent. This is the pattern behind our most successful pilots.
- 01
Start with your stack and one real workflow
Under NDA, our agents trace how your important numbers are calculated across schema, dbt models, and dashboards. We scope the first deployment around a review your leadership already runs.
- 02
Author the knowledge layer, review the gaps
Our agents and engineers write the definitions from what you already have and open the pull requests. We come back only where the evidence conflicts, like two dashboards with different definitions of revenue. You approve.
- 03
Generate the evals and gate the rollout
Graded questions with agreed checks, including the ways answers go wrong. Anchored in your approved definitions and reconciled against the warehouse, never in the agent's own answer. Nothing rolls out until the workflow passes.
- 04
Deliver through the cloud agent harness
Your teams and their agents query, investigate, and fork analyses on the same definitions, from Claude Cowork, Codex, Slack, or the web. Every answer carries its evidence graph.
Keeping it correct
On every data-model change, the affected evals rerun. Failures point to the exact questions and definitions that need attention.
- Corrections and new questions become proposed updates and regression tests, reviewed before they join the system.
- A fix becomes part of the system, not another answer someone has to remember.
feat: refund reason on int_orders_with_refunds #212
signalpilotproposed · feat/refund-reason → main
- add refund_reason to int_orders_with_refunds
- fix: keep 1:1 grain on order_id · signalpilot
- ✓Dana R. approved these changes
Open standards
Your semantics are yours. No lock-in.
Every definition SignalPilot authors is written in Apache Ossie, the open interchange format for semantic data, and lives in your repo as Markdown and dbt. Anything that reads Ossie reads your context.
metric: net_revenuemeasure: sum(gross_amount) - sum(refunded_amount)dimensions: [segment, fiscal_quarter]joins: fct_orders -> dim_refunds on order_id
Also as Markdown beside the model, and as dbt. In your repo, versioned with your models.
Ossieopen YAML spec · Apache 2.0
- dbt Labs
- Snowflake
- Databricks
Salesforce
Cube
ThoughtSpot- + 58 more in the Ossie ecosystem
Metrics, dimensions, and joins in one YAML file. dbt, Snowflake, Databricks, Salesforce, ThoughtSpot, Cube, Hex, Sigma, and 60+ other platforms in the Ossie ecosystem read the same definition.
Definitions, business context, and evals are files next to your models, versioned with them, reviewed as pull requests. Nothing lives only inside SignalPilot.
SignalPilot sits under your warehouse, BI tool, and agent harness rather than replacing them. Change any of them, or leave us, and the semantics you built keep working.