Use case

A data analyst on Slack, on your warehouse

Connect your warehouse via MCP, encode the schema and conventions as rules, ask plain-English questions in Slack. The agent writes the SQL, runs it, posts the answer with the table and the query. Postgres, Snowflake, BigQuery, anything with an MCP server.

Try Nairi free See Slack integration

What this looks like

Most ad-hoc data requests are the same shape. Someone in marketing or product asks a question that's a 30-second SQL query for anyone fluent and a one-day turnaround for everyone else. Half the data team's week disappears into answering them.

Nairi sits in the analyst channel and answers from your actual warehouse. Postgres, Snowflake, BigQuery, all wired up as MCP configs with the DB credentials sealed inside. A schema cheat-sheet rule tells the agent which table holds what; metric-definition rules tell it which canonical version to use. The agent writes the SQL, runs it, replies with the one-sentence answer, a small table, and the collapsed query.

Safe by construction. The DB user has SELECT only, no write grants. The MCP runs in restricted access mode. Query-safety rules cap unbounded selects and require date filters on time-series tables. The data team writes the schema rules and keeps owning the warehouse; the agent handles the questions that would otherwise interrupt them.

What the agent does

Ad-hoc questions, scheduled digests, real anomaly diagnosis.

Ask in plain English, get SQL + answer back

Mention @Nairi in the analyst channel: "how were sign-ups last week vs the week before?". The agent writes the SQL, runs it against the warehouse, replies with a one-sentence answer, a small table, and the SQL collapsed in a code block. Anyone on the team can ask, not just the SQL fluent.

Schema-aware, not table-guessing

A schema-cheat-sheet rule tells the agent which table holds what and which canonical metric definition is the right one. First SQL is usually correct instead of three rounds of "actually the column is called user_id not userid".

Safe by construction

Read-only DB credentials, MCP access-mode restricted, query-safety rules ("default date filter on time-series tables, LIMIT 1000 on unbounded selects, never cross-joins, ask before scanning >100 GB"). The two layers stack: even if the agent tries something dumb, the DB user can't do damage.

Anomaly diagnosis, not just numbers

When the question is about a change ("why are conversion rates down this week?"), the agent reports the number and the likely cause from what's in the data: a deploy correlation, a segment shift, a date-range mismatch.

Multiple warehouses, one agent

Attach Postgres + Snowflake + BigQuery to the same agent. A rule tells the agent which warehouse holds what (clickstream in BQ, transactions in Postgres, marketing data in Snowflake) so it picks the right one without asking.

Recurring digests on a schedule

Turn an ad-hoc question into a scheduled job that posts the same answer every Monday morning. Same agent, same SQL, no new wiring. Useful for KPI dashboards in chat instead of in BI tools.

Three scenarios teams use it for

Ad-hoc questions, recurring digests, anomaly diagnosis.

Ad-hoc question from a non-SQL teammate

Marketing lead asks in the analyst channel: "how many new signups from the Slack ad last week vs the LinkedIn ad?". The agent writes the SQL (joining the ad_campaigns table to the signups table on attribution_id), runs it, replies with the two-number answer, the table, and the collapsed SQL. The marketing lead got the answer in 30 seconds without anyone in data having to context-switch.

Weekly KPI digest, automated

The data lead writes the prompt once: "every Monday at 9am, post sign-ups, conversion rate, revenue, and the WoW delta for each. Add a one-paragraph diagnosis if any metric moved more than 15%". Wire it as a scheduled job. Every Monday the message lands in #weekly-kpis with the same shape, automatically. No new wiring; same agent, same SQL.

Real anomaly investigation

Engineering pings the analyst agent: "wait times spiked yesterday on payments, why?". The agent pulls the wait_time data, checks for a deploy correlation, looks at segment breakdowns by region and payment method, finds the issue isolated to a specific provider, posts the diagnosis with the SQL that found it. Saves the data team an hour of dashboard hunting.

How it works

Warehouse via MCP, schema as rules, safety in three layers.

1
Wire the warehouse as a custom MCP
Postgres, Snowflake, BigQuery, or anything else with an MCP server. Configure as a sensitive MCP config with the DB connection string in the env block. Pass --access-mode=restricted (or equivalent) to lock to read-only. The credentials sit inside the MCP config; the agent only sees the MCP's tool surface.
2
Encode the schema and conventions as rules
Schema cheat-sheet (which table holds what, which columns matter), metric definitions ("revenue means sum(fare) on completed rows, not all rows"), output format ("lead with one-sentence answer, then table, then collapsed SQL"). Without these the agent guesses table names and burns tool calls. With them, first SQL is usually right.
3
Bind the agent to the analyst channel
#data, #analyst, #metrics, your call. The agent listens for mentions, reads the conversation context, and posts results back in the thread. Multi-person by default. Anyone in the channel can ask.
4
Add safety nets, ship it
Query-safety rules ("default 7-day filter on time-series tables, LIMIT 1000 on unbounded selects, never cross-joins, ask before scanning >100 GB"). The DB user has SELECT only, no write grants. The MCP is restricted-mode. Three layers of safety so a wrong query is annoying, not catastrophic.

Put a data analyst in your analyst channel

Wire the warehouse, encode the schema, ask in plain English. Read-only by construction, three layers of safety, self-host the runtime if the data can't leave your infra.

Try Nairi free View pricing

Questions about data-analyst use

What data teams ask before they connect the warehouse.

No. The data team writes the schema rules, defines the canonical metrics, and owns the warehouse. The agent handles the ad-hoc requests that would otherwise interrupt them. A marketing lead asking "how were sign-ups last week vs the week before?" gets a 30-second answer instead of a one-day turnaround. The data team gets pulled in for the questions that actually need their judgment (new pipeline, new metric definition, model debugging), not for things that should have been a one-line SQL query.

Anything with an MCP server. Postgres (and Postgres-compatible warehouses like Redshift, Aurora) via Postgres MCP Pro, Snowflake via mcp-snowflake-server or Snowflake's official remote MCP, BigQuery via mcp-server-bigquery. Configuration is a sensitive MCP config with the DB connection string in the env block. If your warehouse doesn't have a public MCP server yet, the pattern works with any tool you can wrap as MCP, including internal ones.

Two structural layers, plus the rules as a third. First: the DB user the agent uses has SELECT only, no write grants anywhere. The database itself refuses the write, regardless of what the agent tries. Second: the MCP runs in restricted access mode, which limits what kinds of statements it can issue. Third: the rules tell the agent never to issue mutations and to default to safe query patterns (date filters, LIMITs, no cross-joins). The first layer alone is usually enough; the other two stack on top.

The schema cheat-sheet rule is the single highest-leverage thing. It tells the agent which tables matter, which canonical version to prefer when more than one exists, and what conventions you use ("this week means Monday 00:00 local through now", "all timestamps in the warehouse are UTC", "active driver means at least one completed trip that day"). Without it, the agent guesses. With it, the first SQL is usually right. When it gets something wrong, you almost always fix it by adding to that one rule.

Those are dedicated BI products and their dashboard tooling is real (charts, scheduled reports, embedded analytics, governance). If dashboards-and-charts is the primary surface your team works in, evaluate them. Where Nairi fits differently: it's a general team agent that also does data analyst work. The same agent that answers a SQL question in Slack can also field a wiki question, file a Linear ticket, run a scheduled job, draft an on-call summary. One platform, one set of credentials, one vault, harness choice per agent. For teams whose data questions happen in Slack rather than in a BI tool, the agent reduces the round-trip from minutes to seconds.

The structural difference is the rules and the Slack-native multiplayer surface. A naive text-to-SQL tool gets the schema right sometimes; one with a schema-cheat-sheet rule, your metric definitions, and your local conventions encoded gets it right almost always. Plus the agent lives where your team works (Slack or Discord), answers cite the SQL, multi-person context is shared across the conversation, and the same agent can pivot to filing a ticket or posting a digest in another channel. Text-to-SQL is the substrate; the team-agent product is the layer on top.

Yes. Attach a charts skill and the agent posts a PNG alongside the table when "is it up or down?" is the actual question. Same workflow, the agent decides per query whether a chart adds anything over the raw numbers.

Per agent, your choice: Claude (Sonnet 4.6 or Opus 4.7) via Claude Code, GPT-5 via Codex, open-weights via OpenCode, or the Cursor harness. For reasoning-heavy SQL over multi-table joins and anomaly diagnosis, Claude Sonnet is what we recommend by default. Switch if your team has a different preference.

Yes. The nairid daemon is open-source Go and runs the full agent loop, including the warehouse MCP and any returned query results, on your hardware. Slack messages route through the Nairi backend for delivery, but the warehouse connection, the query execution, and the result rows stay inside the daemon. Useful when the warehouse holds regulated data (PII, payment data, health records) that can't legally leave the corporate network.

Company brain on Slack On-call incident response Automated PR review Slack integration Discord integration Pricing Documentation