Scan what people are actually asking agents to do right now and a pattern falls out. One person is vibe-coding a crypto futures bot that force-fires a fixed 4-ATR stop because they can't trust themselves to cut a loss. Another is arguing with a retail support agent that silently blocks their message. Someone else has been feeding Excel to a model for months and keeps getting answers they can't check. Different domains, same wound: the moment you hand real work to an agent, you need the work itself to be stable, inspectable, and repeatable — and most setups give you none of that.
The clearest articulation of the fix I've seen lately comes from a local data-pipeline CLI called dtool. It's a single binary, MIT-licensed, aimed squarely at agents processing Excel and JSON. The author walked the same dead ends most of us have, and the write-up is worth reading as a design argument, not a product pitch.
The one durable idea
dtool's author tried the obvious things first. Dump the xlsx at the model — works until the table outgrows the context window, at which point the model only sees a sample and guesses column names and types. Then let the model write pandas on the fly — runs fine once, but the next file is a new script, the numbers don't reconcile with last time, environments break, and a failed run can't resume. Every path led to the same place: a model can generate code, but it can't guarantee the calculation is stable, accurate, or reusable.
So dtool splits the job. Schema-ize the table once into a dataset with explicit column types, nullability, enums, and samples. Push computation down to SQLite and make SQL the compute layer — declarative, deterministic, the same query giving the same result every time, easy to audit and reuse. The agent only writes SQL; a real engine executes it. Each command lands as an Action with inputs, outputs, preview, errors, and lineage, so a run is traceable and resumable. stdout is always structured JSON with fixed exit codes; human-readable noise goes to stderr. There's a read-only SQL sandbox that permits a single `SELECT`/`WITH`. The author reports streaming xlsx conversion holding to roughly 47MB peak on a 7.4MB / 150k-row file (their measurement, not mine). And they're honest about the ceiling: it's not a BI tool, no dashboards, no permissions, no scheduling.
That split — schema once, SQL as the contract, deterministic server-side execution — is the part worth stealing. It generalizes well beyond one CLI.
Why this matters to a builder
If you're shipping anything agent-driven, the lesson is that improvised code is a liability wherever the output has to be correct and comparable over time. The fragile layer is always the one where the model freehands logic that changes between runs. Freeze that layer behind a declarative contract and the agent's job shrinks to something it's genuinely good at: expressing intent, not guaranteeing arithmetic.
The interesting question is whether you can reproduce that discipline as a hosted service instead of a local binary — so an agent anywhere can call it as a tool. On VicroCode you can rebuild the same three-layer split, with a couple of honest boundaries.
The rebuild, layer by layer
**Ingest.** Stand up a Python backend that accepts an uploaded Excel or JSON file, infers a schema (column types, nullability, distinct-value hints, a few sample rows), and loads the rows into a table. VicroCode lets you run Python online as a hosted backend, which is enough to do the parse-and-load step and emit the schema as its own JSON artifact. One caveat I won't paper over: whether a specific parsing library is present in that runtime is something you'd confirm in the environment itself — I can't verify particular package availability here, so treat the exact ingest library as an implementation detail to check, not a given.
**Compute.** Keep the dataset in a SQLite database and treat SQL as the only way to compute against it. VicroCode's SQLite support, including a SQLite editor, gives you a schema-locked store you can seed from the ingest step and inspect by hand when a query looks wrong. This is the layer that buys you determinism: the same query over the same table returns the same result, and you can audit it directly instead of trusting a model's description of what it did.
**Contract.** Wrap the compute layer in a hosted endpoint the agent calls as a tool. VicroCode's API Endpoint Hosting plus in-platform tool calls let you expose a single operation — take a SQL string, validate it, run it read-only, return a fixed-shape JSON response. Mirror dtool's discipline here: cap the agent to a single `SELECT`/`WITH`, reject anything that writes, and always answer with the same JSON envelope — columns, a bounded preview, a summary, and on failure an error object with the available column names rather than a stack trace. The agent should never parse prose; it should get a predictable object every time.
**The agent.** Finally, the piece that writes the SQL. With VicroCode's AI agent development you give the agent the schema (not the raw rows), a short skills note on how to call the tool, and the rule that it reads a preview first and only pulls full results when it actually needs them. That keeps hundreds of thousands of rows out of the context window and keeps the model's job narrow: translate a request into one query, read the structured result, move on.
Store the schema file, the query text, and the returned preview through VicroCode's file management so a run leaves a trail you can reopen later. That's a lightweight stand-in for dtool's Action lineage — not identical, but enough to answer "what did we actually compute" after the fact.
Where the boundary is
I'd rather name the edges than imply this is a drop-in clone. dtool ships as a dependency-free local binary; this rebuild is a hosted stack, which is a different deployment model with different trade-offs, and the resume-from-failure and lineage semantics would be yours to reimplement rather than something you inherit. dtool's streaming memory guarantees and its reported throughput are its own; nothing about my VicroCode version is performance-verified, so treat any throughput expectation as unverified until you measure it on real files.
The delivery layer is where I'd be most careful. dtool exports CSV/Excel and renders charts; within the confirmed VicroCode capabilities I'd only commit to returning structured JSON and whatever a Python backend writes to a file. Generating native Excel workbooks or chart images sits outside what I can confirm here, so I'd leave those out of scope rather than promise them. And the things dtool explicitly disclaims — dashboards, access control, scheduled jobs — stay out of scope here too; they fall outside this capability set, not just outside this build.
Strip all that away and the valuable part survives the port intact. Schema the data once, make the agent emit SQL, execute it server-side against a locked SQLite store, and hand back a fixed JSON shape. The agent gets to be clever about intent while the numbers stay boring and reproducible — which, for anyone putting agent output in front of a decision, is exactly the right place for the cleverness to live.