The spreadsheet that joins your warehouse

Hand the same file to an AI agent and its first instinct is to read it. Reading means the whole file passes through the context window, so a three-hundred-row spreadsheet costs thousands of tokens before the first question is asked, and a fifty-thousand-row vendor file does not fit at all. Whatever the agent concludes, the spend repeats next session, because nothing durable came of it.

The workarounds are worse. An agent can fetch both sides and match rows in prose, which performs the join inside the model itself, token by token, with an error rate that grows with the row count. Or it can dribble the file into a database as batches of INSERT statements, which is slow, needs write access to somewhere, and leaves a half-loaded table when the session ends early.

A short list of keys needs no table at all: a handful of pasted ids joins inline as a VALUES clause through an ordinary read-only query, and Plexara tells the agent so. Registration is for files with hundreds or hundreds of thousands of rows, where the join belongs in a query engine.

Files reach Plexara two ways. A person uploads reference material into the portal, where it becomes a managed resource with versions, scoping, and usage tracking. Or an agent saves something it built as a portal asset: an export from a warehouse query, a dataset assembled from gateway API calls, a working file another tool produced. Either kind of CSV can be registered as a table.

Registration is deliberately not ingestion. The platform reads the file, takes column names from its header row, and creates an external table over the object where it already sits, in a scratch schema set aside for working tables. Nothing is copied, no pipeline is scheduled, and no storage is doubled. Under the surface this is Trino reading CSV through its Hive support, directly against the same object store that holds the platform’s files; to the person or agent doing the registering, it is one action with a table name as the answer.

From that moment the file and the table are linked. A search that finds the file returns the registered table’s name and a sample join on the same hit, so an agent that finds the file later starts from SQL rather than from the loading problem. And because the table reads the object in place, a vendor drop that overwrites its file changes the next query’s answer with no further action from anyone.

Everything in this section ran on a live Plexara deployment, the demo environment seeded with a 303-store retail chain, while the article was being written. The file is the classic case: a FY2026 lease schedule, one row per store, carrying annual base rent, common-area maintenance charges, and the lease end date. It is exactly the spreadsheet a real-estate team keeps and a warehouse never sees.

The agent saved the schedule as a portal asset and registered it with a single call. The response below is complete: the table name, the columns read from the header, and the one fact worth knowing before writing SQL, which is that a CSV’s columns arrive as VARCHAR and join to typed warehouse columns through a cast.

The file exists to answer one question: which stores pay rent out of proportion to what they sell. That is a three-way join, lease costs against the store dimension against a year of transactions, and with the registration in place it is one statement.

The chain’s median store spends 12.8 percent of revenue on occupancy. Twenty stores sit above 25 percent, five above 30, and the worst, a Springfield, California store, pays $143,800 in occupancy against $340,536 in revenue, 42.2 percent, with the lease up for renewal in June 2026.

Two things did not happen: the file never entered the context window, and the agent never read the source rows. It read eight result rows, because the query engine did the work and only the answer traveled. The statement is recorded, the result was saved as an asset with its provenance attached, and when next quarter’s schedule arrives, the same join runs against it.

A registered table serves the content that was current when it was registered. Every edit to a portal asset and every revision of a managed resource writes a new version, and a table that silently followed the newest version would change the results of any report built on it. So the table stays put, and everywhere the registration appears, the portal panel, the file’s search hit, the agent’s own listing, it is flagged as stale until someone registers again, which takes the table forward in one step. A file overwritten in place, the shape of a recurring vendor drop, needs no re-registration at all.

Registration also refuses files a line-based query engine would misread. A spreadsheet export with line breaks inside quoted cells is legal CSV under RFC 4180 and parses cleanly in every ordinary reader, but a line-based reader would tear each such row into fragments and return them as rows without any error. Plexara reads the whole file before creating anything, names the specific problem, and offers a correction: one control that writes a repaired version through the file’s own version trail, with the original preserved beneath it, and registers the result.

The governance is the same as everywhere else on the platform. Every registration writes an audit event, including the failed attempts. Registering requires the authority to change the file, not merely read it, because a registered table is readable by everyone granted the connection; the table name carries the registering persona so a shared schema stays legible; and dropping a table belongs to the person who registered it, or an administrator. Deleting the file takes every table registered over it along.

The gap sits between the warehouse and the agent, where ad-hoc data lives: the attachments, the exports, the schedules, the lists. Those files used to face a choice between an engineering project and a silo. Now the path is upload, register, join, and it works in both directions, for the spreadsheet a person brings to the platform and for the dataset an agent assembles out of API calls and saves as an asset.

This does not replace pipelines, and is not trying to. Data that arrives on schedule at volume belongs in the warehouse proper, modeled and owned. The scratch schema is a working space, not a modeling layer: it is where a quarter’s analysis meets a quarter’s file. What it replaces is the ticket that was never worth filing, the one-off loader nobody wanted to own, and the analyst afternoon lost to a lookup formula.

A registered table is a pointer and a name. It puts the most common file in business on the same governed, queryable surface as everything else, the day the file arrives.