Processing 72,000 rows without hallucinating

A worked example: 12 CSV files, 30 megabytes, one prompt. Why this would crush a chat-based AI — and why AI in SharePoint just runs it.

Walk away with

72K rows beats every context window

Walk away with

Data stays in tool storage

Walk away with

Code writes the answer

The demo — 12 files, 35 columns, 72K rows

The demo uses a fake sales dataset for a fake store over one year. Twelve CSV files, 35 columns each, nearly 10,000 rows per file — about 72,000 rows in total. Roughly 30 megabytes of structured data.

The prompt does not ask the agent to look at one file or sample results. It asks the agent to read all 12 files, generate a full dataset across them, analyze it, and build a complex interactive report. About seven minutes later, a live HTML report drops into the library — revenue, transactions, units sold, loyalty-card insights, store-by-store margin analysis, hour-by-hour transaction density.

The agent does real math across every row. Numbers in the report match the source data exactly because they came out of actual computation, not an LLM's best guess.

"Seven minutes is slow for AI." Compare it to the alternative: a human doing the same analysis manually across 12 spreadsheets. Seven minutes for a polished, interactive, mathematically accurate report is fast — it is just not chat-fast.

Why context windows can't hold 72,000 rows

Current LLM context windows cannot fit 30 megabytes of CSV. Even if you forced it in, the model would get confused, the math would degrade, and you would see classic hallucination — numbers that look plausible but do not reconcile to the source.

You don't want the AI to remember 72,000 rows. You want it to process them with code and only remember the result.

This is the "too much information" trap. The bigger the dataset, the more tempting it is to dump it all into the prompt — and the more catastrophically the LLM degrades. RAG systems try to dodge this by retrieving a few relevant chunks, which then misses anything outside those chunks. AI in SharePoint dodges it differently: by never asking the model to remember the data in the first place.

"A bigger context window would fix this." Bigger windows help, but they do not solve the underlying problem — LLMs still get confused by long, repetitive numeric data and still confabulate sums. Code, not context, fixes that.

Tool storage — data stays server-side

When the agent reads files, the content does not travel into the context window. It lands in tool storage — a server-side dataset the agent can reference by handle. The model only sees metadata: "this file has 35 columns and 6,000 rows."

The key parameter in the read tool call is content_return: false. Translation: "store the bytes server-side, give me a pointer, don't burn my context." That single flag is what lets the agent operate on gigabyte-scale corpora without ever overflowing its window.

Tool storage is the trick. The model architects; the storage holds the data; the sandbox processes it. The model never tries to "see" all the bytes.

"The LLM still has to load all the data eventually." It really does not. The LLM only sees shapes and summaries. The actual rows are touched only by the code it writes.

The model writes the code — it does not write the answer

The strawberry example sums this up. Ask an LLM "how many Rs are in strawberry" and many models will get it wrong. Ask the same LLM to write code that counts the Rs and it will produce a correct, repeatable answer every time.

The model writes the code. The code computes the answer. That separation is what makes the math trustworthy.

In the 72K-row demo, the agent writes JavaScript that aggregates revenue, joins on store IDs, computes margins per category, and bins transactions by hour. None of those aggregates pass through the model — they are produced by the code and only the final summary structure (a 27 KB JSON file of analytics) gets used downstream.

"If the model writes the code, won't the code be wrong?" Code can be wrong, but it is deterministic and inspectable. A bad LLM guess looks confident and is unreadable. Bad code throws an error or produces visible nonsense — and you can fix it.

Flashcards — Applied

02 · Applied

72K Row Demo

tap to reveal →

A worked example: 12 CSV files, 35 columns, ~72,000 rows, 30 MB. AI in SharePoint reads, analyzes, and produces an interactive HTML report in about seven minutes.

← tap to flip back

02 · Applied

Tool Storage

tap to reveal →

Server-side storage that holds file content during an agent run. The model references the data by handle; the bytes never enter the context window.

← tap to flip back

02 · Applied

content_return: false

tap to reveal →

The read-tool flag that tells SharePoint to keep file content in tool storage instead of returning it to the model. The mechanism that prevents context overflow.

← tap to flip back

02 · Applied

Context Window

tap to reveal →

The token budget the LLM can see at once. Even modern windows cannot fit 30 MB of data — and even if they could, the model still gets confused.

← tap to flip back

02 · Applied

Strawberry Problem

tap to reveal →

The classic "how many Rs in strawberry" failure. Demonstrates why letting the LLM write code, not the answer, produces reliable results for any countable task.

← tap to flip back

Guide 02 · Applied · Processing 72K Rows All flashcards →