An AI notebook for power users: one kernel, two sets of hands

There is a false choice built into most AI analysis tools. Chat products treat every user as a business user: questions in, answers out, and if you want to touch the actual data you are invited to export a CSV and leave. Notebook products make the opposite mistake: everyone is presumed to be an engineer, and the people who just wanted an answer bounce off the empty cell. Both designs share an assumption worth rejecting — that the AI's work and the expert's work happen in different places.

Your best analysts are power users. They can read a Brinson decomposition faster than any summary of one, they have opinions about join keys, and they will not — should not — accept a number they cannot get their hands into. The question a serious platform has to answer is not "how do we keep them from needing to?" It is: where do they plug in?

One workbench, two kinds of hands

In DataQube, the answer is: the same place the agent works. A thread is not a chat window with an API behind it — it is a workbench with a live kernel, and the conversation is how work gets done at that bench. The composer that takes plain questions also takes /py and /sh. Ask in English, and the agent queries, shapes, and computes; drop into code, and you are in the same session — the same kernel, the agent's variables intact, its dataframes live in memory.

Here is what that looks like — the agent's tool steps and a notebook cell, landing in one stream:

Replay run

Based on real customer conversations — all data fictional.

Pick up exactly where the agent left off

The handoff is the point. The agent has pulled the quarter's holdings, joined the benchmark with the right lag, and run the attribution — the boring, error-prone eighty percent. A quant who wants to go deeper does not export anything, reload anything, or reconstruct anything. They open a cell and continue:

1# /py — att is the agent's attribution frame, still live2top = drilldown(att[att.sector == "Industrials"], level="issuer")3top[["issuer", "selection_bp", "active_weight_bp"]].head(2)4 5#            issuer              selection_bp   active_weight_bp6# Kessler Industrietechnik AG          -41               1307# Nordbahn Systems SE                  -30               110

att is the agent's dataframe. The drill-down extends the agent's work — down to issuer level, in this case, finding the two names behind the sector's selection loss. From here the quant can cut the data another way, bring in a factor the agent didn't consider, or prototype the next step of the analysis entirely in code — and the agent picks it back up in conversation, because it is all one session. This is co-working, in the plainest sense: two kinds of expertise operating the same tools on the same bench, each doing what it is best at.

Both sets of work, one record

Everything at the bench lands in the same append-only record: the agent's queries with their audit references, the analyst's cells with theirs, interleaved in the order it actually happened and attributed to whoever did it. Nothing is ever silently mutated — edit a cell and you create a revision; downstream results are flagged stale until re-run; the old version stays. When a number from this thread reaches a committee, "where did this come from" has a mechanical answer that includes the human contributions: walk the log, and the quant's issuer drill-down is right there beside the agent's attribution run, each carrying its own trail.

That interleaving is what makes co-working governable rather than chaotic. The expert's code is not a side channel or a private scratchpad — it is on the record, with the same standing as the agent's work, visible to the same reviewers under the same audit guarantees.

When the kernel is gone

A live session has a kernel: variables in memory, dataframes you can drill into. Sessions end; records don't. Reopen a thread from March and DataQube is honest about the difference — the cells show exactly what ran and what it produced, as records, and nothing pretends the March kernel is still warm. There is no silent re-execution against today's data wearing March's timestamps. When you want the work live again, that is explicit: rerun it in a fresh session, with new results appended as new events — or extract the workflow if it should keep running on its own.

The bet

Don't build a chat product for the many and exile the experts to another tool. Build one workbench: the agent does the heavy lifting, your sharpest people work the same data with real code, and everything either of them did stays on one record. The thread-and-notebook module on the product page shows where this lives in the platform — and if you have a quant who doesn't believe the kernel is really shared, bring them to a demo and let them type.