Illustrative scenario. A small company keeps its order book in a shared Excel file maintained by three people. They add an agent that reads new orders and updates delivery status. It works for a month. One Monday someone inserts a column to log incidents, the agent keeps writing “delivered” into the column next to it, and for nine days the status of a hundred and twenty orders is wrong while no system raises a single error.
The thesis in one line: an Excel file can be a bridge for an AI agent, but not a system of record. The agent doesn’t make more mistakes than a person; it makes them faster, more often and without warning, and the spreadsheet has nothing to slow it down.
AI agent with Excel as a database: does it work?
It works as long as the sheet is a bridge: the agent reads from it, or writes to a tab that is only its own, and one person still owns the file. It stops working when the sheet is the system of record, the place where the official version of the data lives, and several people and the agent write to the same cells at once. There the agent inherits every flaw of the spreadsheet, multiplied by its speed.
What can’t Excel take from an agent?
- Concurrent edits. With a shared file, two people and an agent can save over the same thing: the last save wins, or a conflict copy appears that nobody reconciles. The agent can’t see what someone else is editing right now.
- Columns that move. Someone inserts a column, renames a header or moves a tab. An agent that finds its way by position writes to the wrong column and raises no error: it produces a plausible, wrong value. It’s the costliest way to fail because nobody finds out.
- Unvalidated data. A date typed as text, an amount with a comma or a dot, a merged cell, a totals row in the middle of the data. A person interprets it; an agent interprets it differently each time, or accepts it as is.
- No transactions. If the agent dies halfway through a batch, the sheet is left half-written and there is no reliable “undo” for the whole set. When it failed and what got written, you work out by hand.
- No stable identifier. If someone sorts the sheet, a row number no longer points to the same order. Without a key that doesn’t change, the agent updates the wrong customer.
- All-or-nothing permissions. Whoever can open the file can touch all of it. What that means for an agent is covered in permissions for an AI agent: access is granted per task, not for convenience.
When is Excel a bridge and when is it a bomb?
The useful question isn’t “Excel or a database?” but what role the sheet plays and who else depends on it.
| Situation | As a bridge | As a bomb |
|---|---|---|
| Who writes | The agent, on its own tab | Three people and the agent, on the same cells |
| What the agent reads | An export or an input tab with fixed headers | A live sheet everyone organizes their own way |
| Who depends on the data | Only the process the sheet feeds | Invoices, prices or orders that others treat as official |
| Who owns it | One named person | “The team” |
| If the agent is wrong | You see it on the tab and fix it | It spreads to other processes before anyone notices |
| Horizon | Temporary, with an exit date | Open-ended: “we’ll migrate it someday” |
A bridge holds for months if it meets the three conditions in the left column: the agent writes to its own area, there is one owner, and the data feeds nothing critical. The sheet becomes a bomb when the agent writes over cells that others take as official. Wiring systems together in general is covered in integrating AI with your systems, and what happens when an automation corrupts data in recovering data lost in an automation.
There is an in-between case that works better than it sounds: Excel as a review inbox. The agent leaves there whatever it isn’t sure how to decide, with the reason in a column, and a person resolves it in the sheet itself. Here the sheet isn’t the system of record, it’s the exception queue, and a person editing it by hand is exactly the point.
What is the minimum to migrate without a data project?
You don’t need a months-long project. You need the agent to stop depending on how the sheet happens to be organized today. Six steps, in order:
- An input tab with fixed headers and validation. What the agent reads lives there, with dropdowns and enforced date formats, and nobody inserts columns in that tab.
- A stable identifier per row. A code that doesn’t change when the sheet is sorted or filtered. The agent references by code, never by position.
- The agent writes only to its own area. Its own columns or tabs; never over cells a person fills in. If it needs to suggest a change, it leaves a note and a person applies it.
- A log of every change. Who wrote what, when and with what previous value. Without it, a silent error stays silent.
- A named owner. One person answers for the structure of the sheet and warns before moving anything.
- A written exit criterion. A date or a signal (more than two people editing, a second process reading the sheet, a column error) that triggers the move to a database or to the tool you already have. Without one, the bridge becomes permanent infrastructure.
If what you have is a file that arrives the same way every week and someone classifies by hand, that doesn’t call for a database: it calls for a process that reads it, handles it and leaves a trail, like automating Excel with AI as a process.
The line to take away: don’t ask whether the agent can read the sheet; ask what happens the day someone moves a column. If the answer is “nobody will notice”, you already have a system of record, even if it’s called Excel.
Note: this article uses no third-party figures. Limits on concurrent editing and file size depend on the version and on the service hosting the file; check your provider’s documentation. The opening scenario is illustrative.