thinking sense · FAQ
Questions we hear most.
From customers evaluating thinking sense and investors sizing the category. If you have a question that isn’t here, we’re easy to reach.
Isn't this just RAG + NL2SQL + an ontology?
Those are components, not the product. thinking sense takes a business question, determines which enterprise systems and knowledge are relevant, understands relationships across them, executes against live data under governance, and returns an evidence-backed answer. More importantly, the system gets sharper with every use: each verified execution distills into task-specific SLMs through Governed Execution Distillation, and business user feedback feeds back through RLBUF — Reinforcement Learning from Business User Feedback. Not RLHF, which trains language models on crowdworker preferences. RLBUF closes the loop at the enterprise level: your analysts' corrections become the signal that improves inference accuracy on your business. The components exist. The compounding learning loop is what's new.
Why can't Claude, GPT, or Gemini just do this?
The LLM is the reasoning layer — it shouldn't become the enterprise system of record. Models don't inherently know that a Salesforce account corresponds to an SAP customer, which contract governs it, which policy applies, or what data the employee can access. thinking sense provides durable enterprise context and governed execution. Models can change without rebuilding that intelligence. We want every frontier model to be able to use thinking sense.
Won't OpenAI, Anthropic, or Google build this?
They'll keep improving reasoning and agents — and that's good for us. Our value sits below the model: enterprise semantics, relationships, policies, live execution, and learning from enterprise usage. Model providers want privileged access to your data for their inference. Hyperscalers want your workloads on their compute. None of them can hold this layer neutrally. The AI Control Plane has to be vendor-neutral by design — which is exactly why it can't be built by any of them.
Isn't this what Palantir does?
There's conceptual overlap around ontology, but a critical architectural difference: Palantir requires moving all enterprise data into its own platform before its ontology can operate. That's a multi-year ingestion project before you get any value — and your data now lives in Palantir's infrastructure. thinking sense takes the opposite approach. Data stays in place. A federated query engine reaches across SAP, Salesforce, Oracle, Snowflake, and your other systems directly, and the Semantic Evolution Harness is built on top — without copying or centralizing anything. The ontology learns from your existing systems as they are. Palantir rebuilds the enterprise around their platform. thinking sense works with the enterprise you already have.
Ontologies are notoriously expensive. Who builds yours?
That's one of our core technical bets. We don't require customers to model everything manually. We bootstrap from schemas, primary/foreign keys, data overlap, documents, and metadata — then learn additional relationships from real query history and business feedback. Humans govern high-impact or uncertain relationships rather than authoring everything from scratch. The ontology grows from usage, not from a consulting project. Business user feedback — whether a result was accepted, a metric definition corrected, or a relationship flagged — feeds directly back into the ontology through RLBUF. The system improves its inference accuracy the more it's used inside your business.
What is RLBUF, and how is it different from RLHF?
RLHF — Reinforcement Learning from Human Feedback — is how foundation models learn language. Crowdworkers rank model outputs, and the model adjusts to produce better text. It happens before enterprise deployment, at the model training level, optimized for general language quality. RLBUF — Reinforcement Learning from Business User Feedback — operates at the enterprise level, after deployment. When a finance analyst flags that thinking sense resolved 'revenue' to the wrong metric, or a field technician confirms a maintenance recommendation was correct, that signal feeds directly into the enterprise ontology and fine-tunes the task-specific SLMs serving that workflow. RLHF makes models better at language. RLBUF makes thinking sense better at your business. The two compound: frontier model quality improves over time through the labs, and thinking sense's enterprise intelligence deepens on top of it through your own usage.
How do you prevent AI from hallucinating SQL against production data?
The model proposes intent and plans; the execution layer enforces reality. Schema validation, ontology constraints, access control, query validation, cost limits, and read/write policy all happen deterministically — before any query reaches a backend. Unauthorized queries don't get filtered. They fail to compile. The LLM reasons. thinking sense executes.
Couldn't a large enterprise just build this internally?
A sophisticated team can build pieces — connectors, NL2SQL, a semantic layer. But they'd also need identity propagation, federation across source types, policy enforcement at compile time, model routing, continuous ontology learning, observability, Governed Execution Distillation that fine-tunes task-specific SLMs from verified traces, and RLBUF that routes business user corrections back into the ontology and model weights. That's infrastructure we can productize once and improve across every customer. The enterprise gets compounding intelligence without bearing the full build cost.
How do you fine-tune SLMs to make them more accurate for specific tasks — and what advantage does that provide?
thinking sense treats every verified execution as a training signal. Instead of feeding a model the entire database, we train a small language model (1B–7B parameters) to investigate it — using a controlled toolset to sample schemas, compare groups, trace join paths, and run SQL. Each successful investigation produces a trajectory: every observation, tool choice, and next step. Those trajectories are distilled into the SLM via LoRA/PEFT, producing a model that learns which evidence to seek and in what order for a given task, not just what the data says. The advantages are compounding: ontology retrieval becomes more accurate because the model has learned the real investigative patterns on your data rather than guessing from a general prior; token cost drops sharply because a fine-tuned SLM needs far fewer calls to reach the right answer than a large frontier model reasoning from scratch; and time to answer falls because the model skips exploratory dead-ends it has already learned to avoid. The loop reinforces itself — more investigations, sharper model, higher accuracy, lower cost.
Read: How to Train a Small Model for Databases →How does thinking sense relate to vertical AI companies and agents?
thinking sense is not a vertical AI company and is not competing with them. Vertical AI learns the profession — how to do legal review well, how to run a compliance workflow, how to draft a campaign. That learning is deep and specialized for one job. thinking sense learns the institution: how this enterprise's data relates across all its systems, what the organizational policies are, which entity relationships hold between SAP and Salesforce and Oracle, and how to govern execution across all of them. The distinction Seema Amble at a16z draws is useful: profession learning can be manufactured from expert examples; institution learning comes from real usage inside the enterprise. thinking sense builds the institution layer that compounds with every verified interaction — through RLBUF and task-specific SLM fine-tuning — and that learning belongs to the enterprise, not to a model provider or a vertical application. A vertical AI agent operating on top of thinking sense gets institution context it couldn't build independently. And if the vertical agent is replaced, the institution knowledge stays.
Read: The Incumbents Are Coming (Seema Amble, a16z) →Who buys this, and what's the entry point?
We land with a painful cross-system problem — order-to-cash investigation, third-party risk, field operations — connecting the few systems required and demonstrating measurable value. We don't sell 'model your entire enterprise.' The economic buyer depends on the wedge: CIO/CDO for enterprise AI infrastructure, CFO/COO for process improvement, CRO for risk. The value proposition is measurable outcomes — working capital, revenue leakage, cycle time — not simply better AI.
Still have questions?
We talk to enterprise teams and investors regularly. Reach out directly.
Talk to us →