Machine
Solutions · Data Science

Not a number in a chat.An analysis you can re-run.

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 plus the code that produced it, reproducible because it is a file in your repo.

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

Data Science sessionrunning
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
01The handoff

The questions that arrive faster than you can answer.

Most of the queue is not modelling. It is the fourth version of a question someone already asked, a pipeline that broke overnight, or a definition of "active" that three teams disagree on. That queue is what you hand off.
Job 01

The ad-hoc question, with its query attached

Someone 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.
Job 02

The pipeline that failed at 03:00

It reads the failure, replays 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.
Job 03

Data quality sweeps, on a schedule

Nulls where there should be none, 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 so when it does not know.
Job 04

The metric definition audit

It finds every place a metric is computed, compares the definitions, and reports where they disagree. Dull, hard to ever schedule, and the reason two dashboards show different revenue.
Job 05

The first 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 already briefed, not from an empty cell.
Job 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.
02What comes back

The query in a file, on a branch.

An answer in a chat cannot be checked or repeated. So an analysis session commits its work: the query, the script, the notebook, the chart, and a note on what it checked. That is what arrives for review.
analysis/wk27-conversion/query.sqlSource
1-- Week 27 conversion, split by first-touch surface.
2-- Excludes internal domains: they run the smoke suite hourly and
3-- accounted for 4.1% of week-27 signups before this filter.
4with first_touch as (
5 select account_id,
6 min(occurred_at) as first_seen,
7 argmin(surface, occurred_at) as surface
8 from events
9 where occurred_at >= date "2026-06-29"
10 and email not like "%@acme-internal.example"
11 group by account_id
12)
13select surface,
14 count(*) as accounts,
15 countif(converted_at is not null) as converted,
16 round(countif(converted_at is not null)
17 / count(*), 4) as rate
18 from first_touch join accounts using (account_id)
19 group by surface
20 order by accounts desc;
Illustration. The excluded domain is a placeholder. Machine never names a real customer or tenant.

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. That is the loop an analyst actually works in, not one shot at a fixed set of tools.

Reproducible, because the code came with it

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

It writes down what it left out

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

Your warehouse, however you really reach it.

We will not show a row of warehouse logos we have not verified. Here is how an analysis session actually 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 the tools you 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. Machine reads the source, works out the auth, and turns each operation into a tool with its own Allow, Ask or Block.

The repo

Cloned on a fresh branch when the session starts. Your transformation code, metric definitions and past analyses are already there, so the agent can check a new definition against the existing one instead of inventing a third.

Google Sheets and Drive

Because half the real inputs to an analysis are a spreadsheet someone keeps by hand. It reads them as a source and writes the output back where the person who asked 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 to the same thread.

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

04How it runs

Answer it now. Check the writes. Refresh it on a schedule.

The same session, started three ways. The isolation and the review path stay the same whatever starts it.
01 · On demand

The question, in the thread it came from

Someone 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.
02 · Human-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 that call with the statement in front of you, and picks up from that exact point when you approve.
03 · Automated

The refresh, and the quality sweep

A cron trigger re-runs the recurring analysis for the new period and opens a change request with the regenerated output. A second one runs the quality sweep and only speaks up when a check fails.
05Control

What it can read, and what it can overwrite.

An analysis agent is mostly about reading, right up until it is not. Be exact about both halves.
01

Approval gates are off until you set them

The shipped default is permissive: an action runs unless you said otherwise. That is usually fine for reads. It is not fine for writes to a warehouse, and setting those to Ask is a change you make yourself. Nobody made it for you.
02

Reach is granted per agent, never inherited

An agent gets the connectors you list for it and nothing else, and it cannot see that the others exist. The analysis agent reaching the warehouse and the support agent reaching the helpdesk are separate grants in your project config.
03

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 grants project.cr.merge in your project config, and widening that grant is itself a reviewed change.
04

Two kinds of credential, stated plainly

A connector credential is brokered server-side and never enters the machine. A runtime secret you choose to 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 hand over a warehouse password instead of a connector.
05

One machine per session

Sessions never share a working tree or a filesystem. An extract pulled into one session is invisible to every other, and the machine is thrown away afterwards.
Data Science

Clear the queuethat is not modelling.

One governed platform for data agents. Any model, your keys. Every action recorded.
  • One machine per session
  • Lands as a change request
  • Every action recorded