Google Sheets as a Data Source for AI Agents: When to Migrate

Google Sheets as a Data Source for AI Agents: When to Migrate

Google Sheets works as a data source for an AI agent when volume is low, few people edit, and the agent only reads or writes in a simple, reversible flow. It stops working when simultaneous writes appear, when each user profile may see only part of the data, or when you need a trustworthy audit trail. At that point, moving to a database is a risk-control decision, not a technical fashion.

Key takeaways

• A spreadsheet is a good pilot data source: the team already knows it, setup is cheap, and data can be fixed by hand.
• The first real limit is concurrency: spreadsheets do not offer transactions, so two simultaneous writes can overlap or duplicate records.
• Spreadsheet permissions are designed for people, not for an agent with minimum access: whoever can read the file usually reads everything in it.
• Version history helps with investigation, but it does not replace a log of agent decisions with input, action and result.
• Migrate when the agent starts writing data that moves money, inventory, schedules or personal data, not simply when the spreadsheet gets big.

Why spreadsheets are so tempting, and what they do well

Almost every small and mid-sized company already runs on spreadsheets: customer lists, price tables, order tracking, team schedules. When someone proposes an AI agent, the shortest path is to point the agent at that file. That is understandable, and in many cases it is the right way to start.

A spreadsheet does a few things well in a pilot. The first is visibility: the process owner opens the file and sees exactly what the agent read and wrote. The second is fast correction: a wrong price is fixed in seconds, with no developer. The third is flexibility: changing a column does not require a schema migration.

For reading reference data, such as a catalog, opening hours, warranty rules or an approved price table, a spreadsheet usually works well. The agent looks things up, answers, and changes nothing. The risk is small, and what you learn from the real process is valuable.

The trouble starts when the spreadsheet stops being a reference and becomes an operational record, that is, when the agent creates orders, books time slots, deducts inventory or records consent. At that point the limitations are no longer minor details.

Concurrency: where a spreadsheet breaks first

A database is designed to accept many operations at once without losing consistency. It offers transactions (either everything happens or nothing does), uniqueness constraints and locks. A spreadsheet was not designed for that.

In practice, with an AI agent answering on WhatsApp, several customers write at the same time. If the agent reads the last free row, decides and writes, another run may have done the same in between. The result is two customers in the same appointment slot, the same order saved twice, or one update overwriting another.

There are mitigations, and they are worth knowing before you rule out the spreadsheet:

• Use append operations instead of reading and rewriting rows, so each record is new and never overwrites another.
• Generate a unique identifier per request and check whether it already exists before writing, which makes the flow idempotent.
• Serialize writes through a queue or a single service, so only one process writes to the spreadsheet.
• Keep people from manually editing the same rows the agent updates.

These measures reduce the problem, but all of them push into your own code a responsibility that a database already handles. The more mitigation you have to build, the closer you are to the time to migrate. Also check the current Google Sheets API documentation on quotas and request limits, because they change over time and an agent stuck in a loop can exhaust them. For more on that risk, read AI Agent Infinite Loop: Step Limits, Time and Budget Caps.

Permissions: the agent sees more than it should

Sharing a spreadsheet works around the file: who can view, comment or edit. Range protections exist, but they mainly prevent editing. They do not hide data from someone who can open the file. A person with read access tends to see every tab and column.

That conflicts with a basic principle for agents: minimum access. If a support agent only needs the status of an order, it should not have access to the national ID column, other customers' phone numbers or the profit margin. If the agent's credential opens the entire file, an instruction failure or a prompt injection can expose everything. OWASP describes this kind of risk in its list of threats to LLM applications, and it is worth reading.

The starting point is to separate the agent's identity from people's identities. Use a service account or an OAuth flow with restricted scopes, following Google's OAuth 2.0 documentation, instead of having the agent operate with a partner's personal account. And treat authorization as its own layer, not as a side effect of file sharing, following principles such as those in the OWASP authorization cheat sheet.

A practical alternative inside the spreadsheet is a separate file containing only the data the agent may see, fed by a controlled routine. The agent never touches the main spreadsheet. This improves permissions, but it creates another copy to keep in sync, and that is a sign the data is asking for better structure.

If the spreadsheet contains personal data, LGPD obligations apply: purpose, minimization, security and, when the model runs outside the country, the transfer rules. The article International Data Transfer Under LGPD When Using AI Providers covers that point in detail. For official guidance, follow the ANPD, Brazil's data protection authority.

Audit: can you reconstruct what the agent did?

When something goes wrong, the question is always the same: what did the agent read, what did it decide and what did it write? A spreadsheet's version history shows who changed a cell and when. It is useful, but it has limits for auditing an agent:

• It records the change, not the reason. You see that the status became approved, but not the customer message or the rule that was applied.
• It does not link the change to a conversation, a prompt version or a tool call.
• It can be grouped, is hard to navigate, and, depending on permissions, can be edited or deleted by anyone with edit access.
• It was not built for queries like: list every agent action that changed an order value in the last week.

For that reason, even with a spreadsheet as the data source, keep a separate decision log with date, conversation identifier, summarized input, tool called, parameters, result and whether a human approved it. The traceability concepts in the OpenTelemetry observability primer help you think about this without inventing your own format. And the design of the tools the agent calls, with a few well-bounded actions, is well explained in Anthropic's guide on writing effective tools for agents.

To validate inputs and outputs before any write, see Guardrails for AI Agents: Input, Output and Action Controls.

Illustrative scenario: a distributor taking orders on WhatsApp

Imagine a small distributor of cleaning supplies. It keeps a spreadsheet with catalog, prices and inventory, and wants a WhatsApp agent that answers product questions and records orders for the team to confirm. This is an illustrative scenario, not a real case.

In the first phase, the agent only reads the catalog and prices, from a separate file that is read-only for it. There is no writing and no personal data in the spreadsheet. The spreadsheet is enough, and learning which questions customers really ask is valuable.

In the second phase, the agent starts recording orders in a draft tab, always by appending a row, with a unique identifier per conversation. An employee confirms each order before any inventory deduction. Concurrency is controlled because the agent never rewrites an existing row, and human approval acts as a brake. The spreadsheet still works.

In the third phase, the company wants the agent to reserve inventory on the spot, tell the customer the delivery time and accept order changes during the day, while salespeople also edit the same rows. Now there are simultaneous writes to the same records, customer data (name, address, phone) and a need to prove later who changed what. This is the moment to move order and inventory records to a database, keeping the spreadsheet only as a lookup or import interface.

When to move to a database: practical signals

Use this list as a decision guide. If two or more statements are true, plan the migration. If the first or the second is true, treat it as a priority.

• The agent writes information that moves money, inventory, schedules or deadlines, and an error causes real loss or rework.
• The spreadsheet contains personal data, and not every user, or the agent itself, should see every column.
• Several people or processes edit the same rows at the same time as the agent.
• You need to answer audit questions, from customers or data subjects, about what was done and why.
• The team has built formulas, scripts and helper tabs just to avoid duplicates and conflicts.
• Someone has already fixed an error by hand that was caused by a simultaneous write.
• Other systems, such as an ERP, CRM or website, also need to read and write this data. In that case, review the integration paths and risks for each system before choosing.

Notice that size is not the main criterion. A small spreadsheet with sensitive data and concurrent writes is riskier than a large, read-only one.

How to migrate without stopping operations

Migration does not have to be a long project. The method we follow is map, limit, pilot and hand over, and it fits well here.

Map: list the tabs and columns the agent reads and the ones it writes. Separate reference data (catalog, rules) from operational data (orders, schedule, consent). Record the current state of the process, such as response time and rework, so you have a baseline for comparison.

Limit: define which actions the agent can take and which require human approval. Give it access only to what it needs. When you move to the database, create a user with minimum permissions, for example read access to some tables and insert access to one.

Pilot: migrate one real flow, the one most exposed to concurrency or risk, and keep the rest in the spreadsheet. Run it with decision logs and a success metric agreed with the team. The article How to Measure an AI Automation Pilot: Metrics and Decision Gates helps you define those criteria.

Hand over: document the schema, the permissions, the log and the correction procedure, and give them to the business owner. Only then decide whether to expand, adjust or stop.

A minimal step-by-step for the switch:

• Create the tables with unique keys to prevent duplicates, such as a conversation identifier or order number.
• Import the current data and check a sample by hand against the spreadsheet.
• Point the agent at the database in read mode and compare its answers with those of the spreadsheet version.
• Turn on writing with human approval and watch the logs for a defined period.
• Keep the spreadsheet as a lookup view generated from the database, not as the source of truth.
• Define who can correct data, how corrections are recorded and how to reverse an error.

Frequently asked questions

Can I use Google Sheets as a database for an AI agent in production?

You can, as long as the scope is narrow: reference data, low volume, few people editing and reversible actions. If the agent writes data that creates cost or obligation, such as orders, schedules or consent records, we recommend a database or, at minimum, append-only writes with human approval and a separate log.

Is Google Sheets version history enough for auditing?

It helps you see who changed a cell and when, but it does not record the conversation, the rule applied or the tool called. To audit an agent, keep your own decision log with input, action, result and human approval, stored somewhere the agent cannot edit.

How do I protect personal data in a spreadsheet used by an agent?

Separate the data the agent needs into its own file, use a credential with minimum scope, and avoid sharing the main file with the agent's account. If personal data is involved, apply minimization and the other LGPD obligations, and consult a lawyer or the company's data protection officer when in doubt.

What is the best time to leave the spreadsheet for a database?

When the agent starts writing critical data, when there are simultaneous writes to the same records, or when you need to prove what was done and why. If the team is already building formulas and scripts to avoid conflicts, the cost of keeping the spreadsheet has probably already passed the cost of migrating.

Sources

• Google: OAuth 2.0 authorization
• OWASP: Authorization Cheat Sheet
• OpenTelemetry: observability concepts
• Anthropic: Writing effective tools for agents