There's a V2EX thread that names a problem I keep running into. A developer wants to pull server-side data, hand it to an AI along with the column names, and let the model write its own script to filter and aggregate whatever the user asked for. The plan was an MCP that fetches the data, dumps it into a temp file like JSONL or XLSX, returns a resource link plus metadata (columns, types, row count), and lets the AI take it from there.
Then the plan stalls on one honest question: where do I write the file?
Dump it into userdata and the junk just piles up, and it never gets cleaned when the conversation is deleted. The thread's replies drift toward "use DuckDB" and "don't make the LLM chew on millions of rows, have it write SQL against a database instead." Both are reasonable. But neither answers the thing that's actually blocking him, which is the lifecycle of the intermediate files, not the query engine.
That's the signal worth pulling out. When you let an AI generate and run code over a dataset, the hard part isn't getting a result once. It's what happens to the twelve half-baked CSVs, the aggregated parquet, the debug dump, and the failed attempt that errored halfway through writing. Every one of those is an orphan the moment the chat ends. So I rebuilt his idea on VicroCode with the file lifecycle as the first-class concern, not an afterthought.
The shape of the flow
Keep the MCP-style split he already had. One side fetches data and describes it. The other side is where the AI writes and runs code. On VicroCode that second side is the ability to run Python online, so the model's generated script executes in the platform's Python environment instead of on somebody's laptop or in a folder nobody owns.
The agent loop itself is a good fit for AI agent development: the model gets the metadata, decides on a filter-and-aggregate strategy, emits Python, runs it, reads the output or the traceback, and iterates. Nothing exotic. The interesting engineering is underneath.
A manifest that owns the mess
Before any generated script runs, I open a session and give it a session id tied to the conversation. Every file the AI produces has to be created through a small helper that does two things: writes the file into a session-scoped directory, and records a row in a SQLite manifest. The row holds the session id, the path, what produced it (which step, which script), a byte size, and a created-at timestamp.
The rule the agent can't route around: no writing files outside that helper. If the model's script wants a scratch file, it asks for a path and gets one that's already registered. So there is never a file on disk the manifest doesn't know about. That single constraint is what turns "junk piles up forever" into "every artifact has a parent and an expiry."
Cleanup then becomes boring, which is the goal. When the conversation is deleted, you look up the session id in the manifest, delete every path it lists, and drop the rows. When a conversation just goes cold, a sweep deletes sessions past a TTL the same way. Because the manifest is the source of truth, you're never guessing which of a hundred files in a shared folder belonged to which chat. On VicroCode the manifest is an ordinary table you can open in the SQLite editor, so when something looks wrong you can eyeball exactly what a session left behind and confirm the sweep actually removed it. That inspectability is worth a lot when you're debugging why disk usage isn't dropping.
A couple of details that saved me grief:
- Store the session id as a real column and index it. You will query by session far more than anything else.
- Record the producing step, not just the file. When a run goes sideways you want to know whether the orphan came from step 3 or a retry of step 3.
- Write the manifest row before the file, mark it complete after. A crash mid-write then leaves a row flagged incomplete, which your sweep can clean even though the file is garbage.
Where the platform boundary sits
Now the honest part, because the thread's answers point at tools VicroCode doesn't provide, and pretending otherwise would waste your time.
The "use DuckDB" advice is sound in general, but DuckDB is not one of the confirmed VicroCode capabilities. The database primitive here is SQLite. For the manifest, SQLite is exactly right. For the analytical workload itself, whether SQLite comfortably handles the original poster's "millions of rows" is unverified. That depends on schema, query shape, and how much the AI-written Python does in memory versus in SQL, and I'm not going to claim a number I haven't measured. If your volume is genuinely large, the load-into-a-table-then-query-with-SQL pattern the thread suggests still applies, just against SQLite rather than a columnar engine, and you should benchmark before promising anyone speed.
The other boundary is the word "local." The original request says local analysis. VicroCode's Python execution is hosted, not something running on the user's own machine or your own on-prem box. For a lot of "AI writes a script and returns aggregated numbers" work that's actually better, because the manifest and the sweep live next to the execution instead of scattered across whoever's userdata folder. But if the requirement is strictly that raw data never leaves a specific local host, that's outside what this stack does, and you'd want to say so up front rather than discover it later.
Anything the AI is meant to trigger from a chat, like kicking off a run or fetching a result, fits the platform's API endpoint hosting and in-platform tool calls. File handling goes through file management. None of that requires reaching for an outside cloud service.
What you actually ship
Strip it down and the deliverable is small: a Python execution path the AI writes into, a SQLite manifest that registers every generated file against a session, and a sweep keyed on conversation lifecycle. The AI gets to be as messy as models are, and the mess is contained because it can't create anything the manifest doesn't record.
The original poster asked whether the only option is to analyze server-side and hand results back to the AI. Not quite. You can let the AI drive the analysis and still keep a clean workspace, as long as the workspace, not the model, owns the bookkeeping. Build the manifest first, and the junk-files problem stops being a problem.