FOR ENGINEERING & DATA TEAMS

So you want to build a data tool for your team.

You could build the semantic layer, the permissions model, the audit trail, and the query infrastructure yourself. Or you could use the one we already built.

Someone in your org has asked for a Slack bot that answers data questions, an internal dashboard with live numbers, an ops tool that surfaces the right metrics for each team, or an AI-powered feature that gives customers visibility into their own data. These requests are reasonable. The infrastructure underneath them is not a weekend project.

The demo works quickly. The semantic layer, permission model, audit trail, and connector maintenance are what take the rest of the year — if you build them yourself.

The honest build estimate

The MVP takes a sprint. The infrastructure takes a year.

Connecting an AI to your database takes an afternoon. Getting a confident answer back to a simple question feels like a win. Then you try it in production — real questions, real users, multiple data sources — and you start finding out what you actually have to build.

The list below isn't specific to AI. Every internal data tool hits these problems. AI just surfaces them faster, because users trust a natural-language answer more than they trust a dashboard, which means the stakes of a wrong answer are higher.

Not edge cases — structural problems

These aren't bugs in your implementation. They're the problems every team hits.

Whether you're building a Slack bot, an internal dashboard, or an AI-powered feature, the problems below are the ones that turn a three-week project into a six-month one. They're not unique to your stack.

• ✗
  No shared definition of anything. Revenue is calculated differently in Salesforce, in your warehouse, and in your finance team's spreadsheets. Your tool will encounter all three. Without a semantic layer that encodes the canonical definition, users will get different answers depending on which source was queried. They won't know why. They'll stop trusting the tool.
• ✗
  Permissions that don't generalize. Every data source has its own access model. Enforcing "this user can see this data, but not that data" across Salesforce, your warehouse, and your product database requires a unified permission layer — one that applies at query time, not just at the UI level. Without it, you either over-restrict (everyone sees the same thing) or under-restrict (someone sees something they shouldn't).
• ✗
  Results that don't scale. Returning query results directly into an LLM's context window works for a handful of rows. A real business question — pipeline by region and segment, cohort retention, year-over-year comparison — returns thousands. The context fills, accuracy degrades, and sessions break. With 7 connected sources, over 67,000 tokens are consumed by tool definitions before any query runs. LLM accuracy on raw schemas without a semantic layer sits around 40%.
• ✗
  Schema rediscovery on every request. Without persistent schema context, your tool has to re-learn the structure of your data on every query — table names, column meanings, relationships between sources. There is no accumulated institutional knowledge. The tenth time someone asks about churn, the tool knows as little about your churn definition as the first.
• ✗
  No audit trail. When a business decision gets made based on a number your tool returned, someone will eventually ask where that number came from. If you haven't built logging from day one — what was queried, against which sources, with what result — you can't answer that question. Compliance, debugging, and user trust all depend on it.
• ✗
  Connector maintenance is a full-time job. Salesforce changes its API. HubSpot adds a new object. Stripe renames a field. Each change breaks your connector until you fix it. Multiply this by every data source you've integrated, and you have a permanent maintenance surface your team owns forever.

The infrastructure, already built

Supper is the data layer your tool queries. You build the experience on top.

Supper sits between your data sources and whatever you're building — a Slack bot, an internal tool, an AI-powered feature, an agent, a dashboard. It pre-compiles your semantic context, enforces your metric definitions, applies unified permissions across every source, and returns verified answers through a standard interface.

Your tool doesn't connect to your Postgres database, your Salesforce instance, and your warehouse separately, with bespoke logic for each. It calls Supper. You own the product experience. We own the plumbing.

The API

Four tools. Call them from anything — a Slack bot, an internal app, an agent, or a script.

Supper exposes four MCP tools: ask a question and get a verified answer, check the status of a query in flight, retrieve structured row data out of band, and pull semantic model metadata without running a query. OAuth authentication. Every call scoped to the requesting user or service account's permissions automatically. No custom SDK. No vendor lock-in.

Full parameter reference in the API docs →

• ✓
  Semantic layer. Your data team works with our Forward Deployed Analysts to define your metrics and business logic in Supper. It stays current as your business changes. Your engineers don't maintain it. "Revenue" means the same thing everywhere, for every user, every time.
• ✓
  Schema caching. Supper pre-compiles your semantic context into a compressed, cacheable form. Your tool doesn't rediscover the schema on every request. The context window goes to the query, not to setup.
• ✓
  Result pagination and delivery. Large results don't flood the LLM context. get_answer_rows retrieves structured data separately, paginated, on demand — suitable for rendering in a UI, processing in a script, or passing downstream.
• ✓
  Unified permission model. Supper enforces your access controls at query time across all connected sources. One permission model for every caller — Slack bot, internal tool, scheduled job, AI agent. Row-level, column-level, and data residency rules applied in one place, not bespoke per connector.
• ✓
  Integration connectors. We build and maintain connectors to every data source. API changes, schema updates, new fields — caught and resolved before they reach your tool. You don't own that maintenance surface.
• ✓
  Audit logging. Every query logged — who called it, which sources it touched, what logic was applied, what it returned. One audit trail across every caller and source, queryable, exportable, compliant out of the box.