ThinkingSense resolves business meaning across your systems, enforces identity and policy before anything executes, and speaks every backend's native protocol underneath — reaching 50+ data sources, without moving your data.
Three shapes of question that need more than one system to answer honestly — the kind that today means a data-engineering ticket, a one-off ETL pipeline, and weeks or months of work before anyone sees a number, just to answer one cross-system question a business user could have typed in a sentence.
The instinct is to wire an MCP server directly to every database, SaaS app, and document store an AI agent needs. That works for one source. It stops working past a handful: every system needs its own server built, patched, and kept running; every one is a new set of credentials an AI agent holds directly, with no shared access-control layer in between; and nothing stops a model that can reach ten different MCP servers from crossing into data no single team ever reviewed it to see.
That's integration and security debt that compounds with every new source — not a governance model. The fix isn't an MCP server per system; it's one governed layer in front of every system, enforcing identity and policy before anything executes, regardless of how many sources sit behind it.
ThinkingSense is the enterprise AI intelligence layer — it understands, governs, plans, and learns, then hands off to a dedicated execution layer underneath that connects, federates, routes, and actually runs the query (see the diagram below). Neither replaces the other; ThinkingSense decides what should happen, the layer beneath it makes it happen.
This is the part that compounds. Every answer feeds evidence back into the ontology — a question asked repeatedly promotes a candidate join into a reviewed rollup; a 👎 demotes a bad one. The semantic layer improves with usage, not just with engineering time spent on it directly — the longer it runs, the further ahead it gets.
Four frontends, one canonical Statement record, one ordered pipeline. A Postgres
client that speaks Postgres wire v3 doesn't care whether the row behind it actually lives in
Oracle — that one seam is what lets the firewall, router, stats collector, access-control layer,
and NL2SQL translator each serve every protocol without quadrupling the logic.
Every statement — every wire frontend, gRPC, the HTTP API — passes through StatsCollectorStage exactly once. That single point feeds three export surfaces, so a Prometheus scrape, the admin console, and an OTLP-speaking vendor are never looking at three different sets of numbers.
No manual data-dictionary work. Registering a backend triggers auto-onboarding immediately — four independent signal sources build the ontology from what's actually there, not from a schema a human had to describe by hand.
Mechanical, not probabilistic — no LLM call. Every foreign key becomes a relationship; a detected junction table becomes a many-to-many edge. Runs the instant the backend is registered.
Samples actual column values across tables to catch joins no foreign key declares — two columns that share overlapping values are a join candidate, PII-typed columns get flagged for access policy.
Mines the audit log of executed NL2SQL statements — a join pattern analysts actually use repeatedly is stronger evidence than a schema guess, and gets weighted accordingly.
Extracts computed business terms a schema alone can't express — "revenue" means quantity × price, a credit policy's threshold clause becomes a queryable term.
None of these four sources write to the live ontology directly. Structural, mechanically-certain candidates (a declared foreign key) can auto-accept; everything inferred — value-overlap joins, mined query patterns, document-derived terms — lands in Ontology review for a human decision. A bad join degrades one answer; a bad access-policy grant is a security decision — this project never lets an inference make that second kind of call on its own.
A deployment that only wants the gateway never has to configure the rest.
Four frontends sharing one pipeline — Oracle, Postgres, MySQL wire, and a native gRPC JDBC driver — plus an MCP frontend so AI agents get the identical firewall/routing/rate-limit path a human session does.
Join keys and entity relationships inferred from real query logs and value overlap — every candidate lands in a reviewable queue, never silently applied to production.
NL2SQL with a judge/self-correction pass, federated query planning with real measured per-backend timing, and an automatic Rollup Advisor that suggests pre-aggregations from repeated questions.
Groups (data-source access boundaries), row/column access control tied to real end-user identity, ontology review, rollups, federation plan history, and a question-activity log spanning every entry point.
Named JDBC presets for every major database including SAP HANA, real lakehouse table-format
readers for Iceberg, Delta Lake, Apache Hudi, and Delta Sharing (the open protocol behind SAP
Business Data Cloud and Databricks Marketplace — schema evolution, partition pruning, and
snapshot metadata, not just flat files), NoSQL connectors for MongoDB/Cassandra/DynamoDB, a
real bounded-snapshot Kafka connector, a generic REST connector that reaches any authenticated
JSON API, object-storage connectors for S3/Azure Blob, and a dynamic
ConnectorProvider SPI — drop a connector JAR in a directory, no restart, no
rebuild, to register a new source.
Beyond flat Parquet/CSV objects: real table metadata, snapshots, and schema evolution, read directly — no separate query engine required.
A real bounded-snapshot scan per query — each partition's watermark captured once, same semantics Trino's own Kafka connector uses.
One connector reaches any authenticated JSON API — these are real, working examples, not a fixed list.
Every connector above ships with the product. When one genuinely doesn't exist yet, a
ConnectorProvider implementation dropped
into a directory (OMNIGATE_CONNECTORS_DIR)
is picked up at startup with no OmniGate rebuild and no core product change — the same
mechanism the built-in connectors themselves are written against, not a separate, lesser
extension API.
Honestly scoped: this is a real engineering task — implement a small interface, package it as a jar — for your own team or a partner, not a no-code upload button in the admin console. For most new sources, the generic REST connector already reaches them with zero code at all; this path exists for the genuine exceptions.
Every capability below is a working part of demo.html: context checks before an answer, live charts instead of static numbers, and admin surfaces for the parts of the product that make answers trustworthy in the first place.
A question in plain language, across every connected system — one governed, sourced answer back.
Go deeper on that answer — a real query console, PDF extraction, evaluation runs, domain health.
Turn an answer into an ongoing view — live dashboards, shared links, dashboard-to-chat and back.
Automate the response — scheduled agents that run on a trigger, deliver, and get reviewed.
Type any question instead of only clicking a preset chip — matched against the demo's own scenarios by keyword overlap, with an honest "not covered by this demo" fallback rather than a fabricated answer.
Every answer runs through five visible checks — entity/metric resolution, access, routing, conflict detection, validation — before a Validated badge appears, mirroring how governed-analytics tools show their work instead of just a number.
Gradient bar charts, a smooth cubic-bezier trend/area view, and a table view — with grid lines, animated draw-in, value labels, and hover tooltips. Heterogeneous KPIs are chart-scaled honestly, never silently misleading.
"View workstream" opens the generated SQL, checks, and backends touched for any answer. ⌘K / Ctrl K jumps to any admin view, team, or question from anywhere.
Admins define a name, trigger description, and instructions once; business users invoke it with /skill-name or it loads automatically when a question matches its trigger — full CRUD in the admin console.
Reusable question phrasings, lighter than a Skill — no matching logic, just a starting shape with {placeholder}s the user fills in themselves, never auto-filled.
"Extract knowledge from this conversation" surfaces a candidate fact grounded in what an answer already states — reviewed and accepted in admin, then visible per-answer via a new "Knowledge" button.
Link a channel to a group's data area, then anyone in it can ask by mentioning ThinkingSense — the answer posts as a thread so the channel stays clean, with the same access control as Ask.
A toggle in Ask switches from the fast path to a proposed investigation plan you approve before it runs — producing a full report with an executive summary, key findings, visualizations, and a suggested next step.
Typing a prefix of a known question shows the rest greyed out inline — Tab to accept.
A toggle that searches across every team's questions instead of just the current one, and switches your active group automatically when a question matches a different team's.
When nothing internal matches, an honest toggle explains this demo has no live web connector — never a fabricated external-results answer blended in as if it were internal data.
A paperclip button attaches a CSV/TXT/XLSX file, shown as a chip in the composer and carried into the sent message.
A "🆘 Ask an admin for help" button opens a message form landing in a dedicated admin view — distinct from 👎 feedback: "I'm stuck," not "this answer was wrong."
A manual query console against any registered backend, plus prompt sets with expected SQL and scored run history — the admin-facing counterpart to this project's own internal NL2SQL eval suite.
Upload a document once and it becomes part of a group's permanent knowledge base — different from a chat attachment, which only applies to that one message.
Every question shown as an NL ↔ SQL pair, mark/unmark reviewed, plus a CSV import — the admin surface for this project's own QuestionBankGenerator.
A 👎 plus a tag in Ask now records a real, resolvable entry — question, group, tag, timestamp — in one aggregated admin view, not just a toast that vanishes.
A composite 0-100 score per group from live counts — ontology backlog, open negative feedback, rollup coverage, skills defined — not a fabricated number.
An isolated draft → refine → run workspace for turning a question into a trusted query — "Mark as reviewed" writes into the same store Reviewed queries reads from, not a disconnected mock.
Reconciles POs stored as PDF/OCR in S3 against SAP via a working PDF_EXTRACT() table function — every value is independently checked against the document's own text before a join is allowed to trust it.
"+ Add to dashboard" on any chat answer creates a live widget using the same chart engine — an actual chat-answer-to-dashboard round trip, not a mockup screenshot.
Share to specific people, your org, or just yourself, with two distinct link types: an authenticated link that honors each viewer's own row/column-level security, and a pre-auth link safe to hand outside the org — both served from a pre-computed Rollup snapshot, not a live re-query.
Organize widgets into named tabs (move any widget between them), and filter what's visible by group with no re-query — the same "no live re-query" posture as sharing.
"Save version" snapshots the full dashboard and its tabs with a label and timestamp; "Version history" lists and restores any saved version.
A new chart mode — left axis is each KPI's raw, unscaled value (bars); right axis is a 0-100 relative index (line) — two axes because the units genuinely differ, not for decoration.
An "Ask this dashboard" box scoped by the instant filter, producing an inline result with a one-click "Pin to tab" — the dashboard-to-chat direction, not just chat-to-dashboard.
Question activity rows that came from Claude via MCP get a "+ Pin" action too — the resulting widget carries a visible "via MCP" badge, not just internal Ask answers.
A running-agents table plus a read-only node-graph preview (Schedule → Data → Summary → Email) — the same trigger/data/reasoning/delivery node shape as production workflow builders.
"Run with parameters" on an agent produces a one-off preview using the same chart engine — labeled honestly when this demo has no backend to actually segment by the chosen parameters.
Add/edit/delete agent definitions — name, trigger, delivery, group — the same admin pattern already established for Skills and Prompt templates.
Approve or flag an agent's individual past runs to vouch for that exact output — distinct from a one-off parameterized preview, this is trust in a specific, already-delivered result.
Per-table policies using USER_ATTRIBUTE()-style conditions, enforced by rewriting SQL before it reaches the backend — configured per group in Users & access, not bolted on after the fact.
Every source is classified L0 (Public) through L4 (Highly Restricted); sharing a dashboard that touches a sensitive one is blocked behind an approval DAG — Data owner, Manager, and Security & Privacy as the classification escalates — with a timestamped audit trail, not just a label.
A "Viewing as" selector that actually gates the UI — Observer hides Skills/Templates entirely, Explorer keeps them but can't reach Admin console.
A safety knob separate from RLS — Full context / Schema only / Metadata only — restricting what the AI can even see for a group, not which rows come back.
The key/value pairs an RLS policy's USER_ATTRIBUTE('desk') reads from — previously only implied in policy text, now an editable table per user.
An org switcher in the topbar plus an Organizations admin view — plan, seats, created date, and a "Current" badge that follows whichever org is active.
Generate/revoke API keys, and embed snippets for both an <iframe> and the @thinkingsense/react SDK — the two ways this would actually get embedded in another product.
Require-SSO toggle, an SSO-group-to-ThinkingSense-group mapping table, and a SCIM base URL — new members provisioned into their mapped group automatically on next login.
A scripted, self-contained mockup — no server behind it — covering the full admin console (data-source groups, LLM settings, Skills, Slack, RLS/CLS policies, ontology review, rollups, federation plans, SQL Playground, Evaluation, Agents, and Developers/embedding) plus a live Ask experience with live charts, Deep Analysis, and Dashboards — see What's new for the full list.
ThinkingSense's source is proprietary — the free edition ships as a ready-to-run Docker image, no source access required. Contact us for a commercial license and full source/docs access.
git clone https://github.com/thinkingsense-ai/Docker.git cd Docker docker compose up --build
# admin console open http://localhost:8080/admin # business-user Ask app open http://localhost:8080/
Want them on separate ports instead — e.g. to expose the Ask app publicly while keeping
the admin console internal-only? Set OMNIGATE_ASK_PORT (e.g. 8081)
alongside OMNIGATE_HTTP_PORT. It's a hard split: once set, the admin port
stops serving Ask-app routes and the Ask port stops serving admin routes. Leave it unset
to keep the single-port default above.
psql -h localhost -p 5433 -U myuser -d mydb
export OMNIGATE_BACKENDS="primary=jdbc:postgresql://host:5432/mydb|user|pass"
Set this as an environment variable on the omnigate service in
docker-compose.yml before docker compose up --build.
| Variable | What it does |
|---|---|
| OMNIGATE_BACKENDS | Named backend connections, name=jdbcUrl|user|pass, semicolon-separated. |
| OMNIGATE_ROUTER_SCHEMA_RULES | Schema-prefix → backend routing, and what triggers federation across 2+ backends. |
| OMNIGATE_LLM_API_KEY | Enables NL2SQL generation via an external provider (or run fully local via a bundled llama-server). |
| OMNIGATE_STATS_REFRESH_INTERVAL_MINUTES | Turns on statistics collection that feeds cost-based federated planning. |
| OMNIGATE_SQL_PLAN_HISTORY_SIZE | Turns on Federation Plans — measured per-backend leaf-scan timing. |
| OMNIGATE_CONNECTORS_DIR | Drop-in directory for dynamically-loaded connector JARs — new sources with zero core rebuild. |
| OMNIGATE_ASK_PORT | Serves the Ask app on its own port, hard-split from the admin console (see step 2). |
| OMNIGATE_APP_USERS | Business-user accounts for the Ask app (distinct from admin login). |
| OMNIGATE_INSIGHTS_INTERVAL_MINUTES | Turns on Proactive Insights — scheduled re-checks of approved questions, flags material changes. |
| OMNIGATE_SLACK_WEBHOOK_URL | Sends Proactive Insights findings to a Slack channel. |