Connect an AI Agent to Google Sheets and Excel

Connecting AI to Excel and Google Sheets means giving an agent read and write access to your spreadsheets through the official API — the Google Sheets API with a service account, or Microsoft Graph for Excel in Microsoft 365 — so it can read rows, do the work on each one and write the result back into a column, a tab or a fresh report. Nothing gets migrated and nobody changes tools: the spreadsheet stays the interface your team already knows, and the agent works behind it.

It is by a wide margin the highest-return integration in the first weeks of a project. Most small and mid-sized companies have entire processes living in spreadsheets — lead lists, order tracking, incident logs, quotes, inventory — and those sheets are the perfect entry point for an agent: the data is already structured, the team already works there, and nobody needs training. We run several of our own processes this way. We are also going to tell you where this setup breaks, because it does break.

How does an agent technically connect to a spreadsheet?

Through the provider's API and with its own identity — never with a person's credentials. For Google Sheets you create a service account in Google Cloud, grant it access by sharing that specific spreadsheet with its email address, and the agent reads and writes ranges through the API. For Excel there are two different situations: if the file lives in SharePoint or OneDrive (Microsoft 365), you go through Microsoft Graph with an app registered in Entra ID; if it is an .xlsx sitting on somebody's disk, the agent processes it as a file — read, compute, produce a copy — and nothing is live.

That distinction is the project's first decision and it has consequences:

One detail that saves grief: grant access to the specific spreadsheet, not the whole drive. The agent should touch exactly the range it needs and nothing more, under its own registered identity so every write is traceable. It is the same least-privilege principle we apply to any agent with access to company systems.

Which usage patterns actually work?

Four of them, and it is worth recognising each because they are designed differently. The first three have been running in production for years; the fourth delivers the most value and almost nobody builds it.

1. The sheet as an input queue. Each row is a pending task: a lead to classify, an invoice to check, a product description to write. The agent reads unprocessed rows, does the work and writes the output columns plus a status flag and a timestamp. Simplest pattern, biggest hour savings.
2. The sheet as an output report. The agent works against the CRM, the ERP or the inbox and drops the result into a sheet that management already has open every Monday. It avoids building yet another dashboard nobody opens.
3. The sheet as the agent's control panel. A tab with parameters — thresholds, templates, rules, exclusion lists — that the process owner edits without touching code. It is the cheapest way to let the business tune the agent's behaviour without depending on the vendor.
4. The sheet as a human approval point. The agent proposes in one column, a person types "OK" or corrects in the next, and the agent executes only what was approved. This pattern solves supervision without building an interface: the interface already exists and everyone knows it.

That fourth pattern is what turns a spreadsheet into more than storage. When you want to raise the agent's autonomy gradually — start by reviewing everything, end by reviewing only exceptions — the approval column is the dial that lets you do it without rewriting anything.

Where does using spreadsheets as the agent's database break?

In five specific places, and all of them show up as the process grows. Worth knowing before you build anything important on top:

• Concurrency. A spreadsheet has no transactions and no row locking. If the agent writes while a person sorts the table or inserts rows, writes land in the wrong place. The defensive fix is to always locate rows by a unique identifier, never by row number.
• API quotas. Google and Microsoft both throttle requests per minute and per user. An agent that writes cell by cell burns through the quota immediately; reads and writes have to be batched into ranges. This is the number one cause of "the agent is painfully slow".
• Size. Google Sheets caps at 10 million cells per document, shared across all tabs; Excel goes to 1,048,576 rows per sheet. Long before those limits the sheet becomes unbearable: with tens of thousands of rows and live formulas, every open takes forever and every recalculation freezes it.
• Integrity. There are no real types and no validation. A "1,200" someone pasted as text, a date in the wrong locale, or a column somebody reordered will break the agent's logic silently, with no visible error.
• Traceability. Version history helps, but it is not an audit log: it answers "who changed this amount, when and why" badly, which matters for processes involving money or personal data.

None of these five is a reason not to start with spreadsheets. They are reasons to know when to stop using them.

When should you migrate to a database?

When any of these four signals appears, the spreadsheet has stopped being the right tool:

1. More than two processes or two people write to the same table at once. That is where conflicts stop being anecdotes.
2. The sheet passes a few tens of thousands of live rows and the team starts complaining about speed, or somebody creates "the 2027 sheet" to relieve it.
3. The data is the source of truth for money, stock or customers. If a cell error has accounting or legal consequences, you need constraints and history, not a spreadsheet.
4. You need to query across entities — customers with orders with incidents — and you have already chained three VLOOKUPs. That is a database asking to exist.

Migration is neither a drama nor a multi-month project: in most cases, moving a process from a spreadsheet to a managed database and leaving the sheet as a read-only view for the team takes 1-3 weeks and sits inside the €15,000-40,000 range of a custom agent for a small company, depending on how many integrations it drags along. What is a drama is doing it after a concurrency bug has invoiced a customer incorrectly. If you are weighing that step, we break the numbers down in what it costs to automate a process.

What should you NOT do with spreadsheets and an agent?

Three things, learned the hard way. First: do not let the agent rewrite formulas. If the agent writes into cells containing formulas, or changes the sheet's structure, you will spend entire afternoons rebuilding broken calculations. Always separate the zones — input, agent output and human calculations — into different tabs or column blocks.

Second: do not put sensitive personal data into link-shared sheets. "Anyone with the link" access is the most common data leak in small companies, and adding an agent on top multiplies the volume of what sits inside. If the process touches customer, employee or health data, a shared spreadsheet is the wrong home.

Third: do not use the sheet as the agent's memory. The sheet is for business data; the agent's internal state — what it attempted, what failed, what it retried — belongs in its own log. Mixing them produces unreadable sheets and makes debugging impossible when something goes wrong.

How do you build a first case in two weeks?

With a narrow process and one golden rule: the agent does not write to the original until its output has been reviewed a fair number of times. This is the script we follow:

1. Pick the process: repetitive, with stable judgement, and with the spreadsheet already in use. Lead classification, description writing, master data cleanup, quote calculation from a template.
2. Duplicate the sheet and work on the copy for the first weeks. The cost of a production error is far higher than one extra week of testing.
3. Define system columns: unique identifier, status, processing timestamp, agent result and reason. Without a unique identifier there is no reliable integration.
4. Connect with a service account scoped to that one spreadsheet.
5. Run it in parallel with the human process for a week or two, compare results and tune.
6. Move to the real sheet with the human approval pattern switched on, then reduce the review rate as accuracy is demonstrated.

A case like this deploys in 1-2 weeks and is the starting point we most often recommend: it delivers value fast, touches no critical systems and teaches the team how working with an agent actually feels. Once that first one works, the natural next step is connecting the agent to the real systems — CRM, ERP, email — which is where most of the savings in back-office automation live. If you want us to build it with you, that is how we work at our AI agency in Madrid.

Frequently asked questions

Are the built-in AI formulas in spreadsheets good enough?

They are fine for isolated tasks — classify a column, summarise a text — and they are a good first contact, but they are not an agent: they do not connect to your other systems, they do not handle errors or retries, they leave no audit trail and they recalculate at the spreadsheet's whim. For a process that must run daily without anyone watching, you need an agent outside the sheet that uses the sheet as its interface.

Can the agent create charts and formatting in the sheet?

Yes — both the Google Sheets API and Microsoft Graph allow formatting, creating tabs and generating charts. Our practical advice is to limit it: the more the agent touches presentation, the more fragile the integration. Let the agent write data, and keep formatting in templates or pivot tables that never change.

How much does this integration cost?

Connecting an agent to a spreadsheet is one of the cheap parts of a project: the cost sits in the business logic, not the connection. A first narrow spreadsheet case usually lands at the low end of the €15,000-40,000 range for a custom SMB agent, with the usual 10-20% annual maintenance on what was built.

Is it safe to give an agent write access?

It is, when it is done with its own service account, access scoped to the one spreadsheet, system columns logging every write and an automatic backup before each batch. What is not safe is the opposite: sharing a person's password or granting access to the whole drive.

What if my team uses desktop Excel and refuses to switch?

They do not need to switch. You can run the process in batches: the agent picks the file up from a shared folder, processes it and leaves the output in another folder with a name and a date. You lose real time, you gain simplicity, and in many administrative processes real time adds nothing.