Solutions · Data Science

An analysis you can re-run, not a number in a chat window.

A session is a real Linux machine. The agent installs what it needs, runs the query, does the work in a script you can read, and commits it. What lands is the analysis and the code that produced it — reproducible by definition, because it is a file in your repo.

Real shell · real packages · the notebook lands in the repo

Runs on
A real machine with a shell
Installs
Whatever the analysis needs
Lands as
A change request against main
Re-runnable
Because the code came with it
The handoff

The requests that arrive faster than you can answer them.

Most of the queue is not modelling. It is the fourth variation of a question someone already asked, a pipeline that broke overnight, or a definition of "active" that three teams disagree about. That queue is the handoff.

  1. 01

    The ad-hoc question, answered with its query attached

    Somebody asks what happened to conversion in week 27. It writes the query, runs it, checks the result against a second cut, and answers with both the number and the SQL. The next person to ask does not need you either.

  2. 02

    The pipeline that failed at 03:00

    It reads the failure, reproduces the transformation on its own machine against a sample, finds the row shape that broke it, and opens a change request with the fix and a test that would have caught it.

  3. 03

    Data quality sweeps, on a schedule

    Nulls where there should not be, distributions that shifted, joins that started fanning out, a dimension that grew 40% overnight. It reports what moved and what it thinks moved it — and says when it does not know.

  4. 04

    The metric definition audit

    It finds every place a metric is computed, diffs the definitions against each other, and reports where they disagree. This is unglamorous, genuinely hard to schedule, and the reason two dashboards show different revenue.

  5. 05

    The exploratory pass before you take over

    Profile the dataset, plot the distributions, check for leakage and imbalance, and write the first honest paragraph about what is in the data. You start from a briefed position rather than from an empty cell.

  6. 06

    The recurring analysis nobody wants to own

    The weekly cohort cut, the monthly retention curve, the quarterly segment refresh. Same code, new period, run by a trigger, landing as a change request with the chart regenerated.

The output

The query, in a file, on a branch.

A chat answer is unfalsifiable and unrepeatable. So an analysis session commits its work: the query, the script, the notebook, the chart, and the note about what it checked. That is what arrives for review.

analysis/wk27-conversion/query.sqlSource
-- Week 27 conversion, split by first-touch surface.
-- Excludes internal domains: they run the smoke suite hourly and
-- accounted for 4.1% of week-27 signups before this filter.
with first_touch as (
select account_id,
min(occurred_at) as first_seen,
argmin(surface, occurred_at) as surface
from events
where occurred_at >= date "2026-06-29"
and email not like "%@acme-internal.example"
group by account_id
)
select surface,
count(*) as accounts,
countif(converted_at is not null) as converted,
round(countif(converted_at is not null)
/ count(*), 4) as rate
from first_touch join accounts using (account_id)
group by surface
order by accounts desc;
Illustration. The excluded domain is a placeholder — Kortix never names a real customer or tenant.

It is a real machine, not a tool sandbox

The agent has a shell and a filesystem. It can install a package, pull a sample down, run it, look at the output, and try again — the loop an analyst actually works in, rather than one shot at a fixed set of tools.

Reproducible because the code came with it

The answer and the thing that produced the answer arrive together in the same change request. Re-running it next month is a re-run, not a reconstruction.

It writes down what it excluded

The filters, the date boundaries, the rows it dropped and why. An analysis whose exclusions are undocumented is not an analysis, and a comment in the query is the cheapest possible place to keep them.

Where it reaches

Your warehouse, however it is actually reachable.

We are not going to list a row of warehouse logos we have not verified. Here is what is genuinely true about how an analysis session reaches data, including the part where it does the work locally.

The machine itself
The strongest data connector on this page is the sandbox. Pull an extract down, work on it locally with whatever you would normally use, and never move the analysis into a tool that cannot do arithmetic.
Your warehouse and BI stack
Reached as a connector you define: an OpenAPI or Postman description, a GraphQL endpoint, a raw HTTP base URL, or a remote MCP server. Kortix reads the source, works out the authentication, and turns each operation into a tool with its own Allow, Ask or Block.
The repo
Cloned at session start on a fresh branch. Your transformation code, your metric definitions and your previous analyses are already there — which is why the agent can check a new definition against the existing one instead of inventing a third.
Google Sheets and Drive
Because half of the real inputs to an analysis are a spreadsheet somebody maintains by hand. It reads them as source and writes the output back where the requester will look for it.
Slack
The one live channel. Ask the question in the thread where it came up; the answer, the chart and the query come back into the same thread.

Easy connect covers 3,000+ apps through their own OAuth screens, and it is the right route for the SaaS sources around the edges of a data stack. For the warehouse itself the direct connector types are usually the honest answer — most warehouses are reached through a driver or an API, not an OAuth catalogue entry.

How it runs

Answer it now, check the writes, refresh it on a schedule.

The same session machinery started three ways. The isolation and the review path do not change with the trigger.

  1. 01On demand

    The question, in the thread it was asked in

    Somebody asks in a channel. The mention starts a session, the session does the work on its own machine, and the answer lands back in the same thread with the query attached.

  2. 02Human-assisted

    Reads run, writes wait

    Set the read actions to Allow and anything that writes to a warehouse or overwrites a table to Ask. The run pauses at the call with the statement in front of you and resumes from that exact point when you approve.

  3. 03Automated

    The refresh, and the quality sweep

    A cron trigger re-runs the recurring analysis against the new period and opens a change request with the regenerated output. A second one runs the quality sweep and only says something when a check fails.

Control

What it can read, and what it can overwrite.

An analysis agent is mostly a read problem — right up until the moment it is not. Be exact about both halves.

Approval gates are off until you set them
The shipped default is permissive: an action runs unless you have said otherwise. Reads are usually fine that way. Writes to a warehouse are not, and setting them to Ask is a configuration change you make, not one that was made for you.
Reach is granted per agent, not inherited
An agent gets the connectors you list for it and nothing else, and it cannot discover that the others exist. The analysis agent reaching the warehouse and the support agent reaching the helpdesk are separate grants in kortix.yaml.
Merge is default-deny
The notebook, the query and the fix land through a change request against main. An agent cannot merge unless an admin has granted project.cr.merge in kortix.yaml, and widening that grant is itself a reviewed change.
Two kinds of credential, stated precisely
A connector credential is brokered server-side and never enters the machine. A runtime secret you deliberately grant a session IS a real environment value inside it, readable by any command the agent runs — that is what granting it means, and it is worth knowing before you grant a warehouse password rather than a connector.
One machine per session
Sessions do not share a working tree or a filesystem. An extract pulled into one session is not visible to another, and the machine is disposable.

The same platform, the other teams

One project, one set of connectors, one memory that compounds. Each team writes the skills for its own work; nobody stands up a second system.

All solutions →
Data Science

Clear the queue that is not modelling.

Open source and self-hostable. Any model, your keys. Kortix Cloud, your own VPC, or your own on-prem network.

Kortix for data science teams