Ask a spreadsheet question, get an answer that was actually computed

Build me an analysis workbench that my ops and analyst team opens whenever they have a question about a spreadsheet. Today they paste data into a chatbot and get a plausible sounding number back. I want them to get an answer that was actually computed, in our own infrastructure, with the chart and the code to back it up. This is an on-demand surface a person opens with an unplanned question, so do not turn any part of it into a scheduled report or a recurring digest.

The main screen is where you choose data and ask. Give me two ways to load a dataset. First, a Google Sheet picker: a handler calls the Google Sheets Get Spreadsheet operation to read the spreadsheet metadata and list its tab names, then calls Get Values on the chosen tab to pull the range. Second, a direct CSV upload for data that is not in Sheets. Either way, once the data is loaded show a preview of the first twenty or so rows in a table, along with the detected column names, the column types, and the total row count, so the analyst can confirm they grabbed the right thing before spending a question on it.

Under the preview is a plain English question box with a Run button. Real examples of what people will type: which regions grew month over month, show me revenue by plan as a bar chart, what are the top ten accounts by spend, which products have declining units but rising revenue. Show a couple of these as clickable example prompts when the box is empty.

When the user hits Run, the handler works inside a Daytona sandbox. Reuse one sandbox across a whole working session rather than spinning up a new one per question. On the first question of a session, call the Daytona Create Sandbox operation. Sandbox creation is asynchronous, so poll the Get Sandbox operation until the state is started before making any call that runs inside the sandbox. As soon as it is up, call Set Auto-Stop / Auto-Archive / Auto-Delete Intervals to set a short auto-stop, around fifteen minutes of inactivity, so a forgotten session cannot sit there running. Every later question in the same session skips creation and reuses the existing sandbox id.

With the sandbox running, the handler uses the Daytona Upload File operation to drop the dataset in as a CSV, generates Python that answers the question using pandas for the analysis and matplotlib for any chart, and executes it with Run Code in Sandbox. Use Execute Command in Sandbox for shell steps such as installing a missing package or listing output files, keeping in mind that command execution is synchronous by default and returns the exit code together with the combined output. Have the generated code write its chart to a known path as a PNG and its result table to a known path as CSV or JSON, then use the Download File operation to pull both back out. Render the chart image and the result table directly in the app.

Each question produces an answer card. The card shows a short written summary of the finding, the chart, and the result table, with the generated Python sitting right next to the result in a code panel so an analyst can check the math. Make that code editable: an analyst who spots a wrong assumption, a bad filter or a missing currency conversion should be able to edit the code and re-run it, producing a new version of the card rather than silently overwriting the old one. When code fails, show the error output on the card so they can fix it and try again instead of hitting a dead end.

Every answer card has a Share button. It posts the written summary, the question that produced it and the headline numbers into a chosen Slack channel using the Slack Bot Send a Message operation, and attaches the chart image with the Slack Bot Upload a File operation so the picture lands in the channel rather than just a description of it. Let the user pick the channel and edit the message text before it goes.

Keep a per-user history of past questions. Each entry stores the question text, which spreadsheet and tab or which uploaded file it ran against, the generated code, the result table and the chart, plus who asked it and when. Show it as a list, most recent first, that a person can search. Opening a past entry brings back the full answer card, and there is a Re-run against fresh data action that pulls the current values from the same Google Sheet tab again with Get Values and runs the saved code over the new rows, so a question asked last month becomes this month's answer without retyping it. History is scoped to the person who asked, with their own questions front and centre.

Finally, clean up after the session. When the user ends their session or leaves the workbench, call the Daytona Stop Sandbox operation so the workspace is not left running, with the short auto-stop interval acting as the backstop if the app never gets a clean exit. Show the current session state somewhere unobtrusive, something like a small indicator saying the workspace is ready, starting or stopped, so people understand why the very first question of a session takes a little longer than the ones after it.