Solutions·Data Science
Session — это реальная Linux-машина. Агент ставит то, что нужно, гоняет query, пишет script, который можно прочитать, и коммитит. На выходе — анализ и код, который его произвёл: reproducible по определению, потому что это файл в repo.
The handoff
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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 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.
Reached as a connector you define: OpenAPI, Postman, GraphQL, raw HTTP, or a remote MCP server. Neuro OS turns each operation into a tool with its own Allow, Ask or Block.
Cloned at session start on a fresh branch. Your transformation code, metric definitions and previous analyses are already there — so the agent can check a new definition against the existing one.
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.
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 the SaaS sources around the edges. 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
The same session machinery started three ways. The isolation and the review path do not change with the trigger.
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.
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.
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
An analysis agent is mostly a read problem — right up until the moment it is not. Be exact about both halves.
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.
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.
The notebook, the query and the fix land through a change request against main. An agent cannot merge unless an admin has granted it in a versioned config file — and widening that grant is itself a reviewed change.
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 — worth knowing before you grant a warehouse password rather than a connector.
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
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.
“An analysis you can re-run, not a number in a chat window.”
Любая модель, ваши ключи. Neuro OS в вашем cloud, VPC или on-prem.
