Selecting Google Docs & Sheets with the Native Google Picker

Macha removed that step. As of the April 9, 2026 release, you connect Google Docs and Sheets to an agent through the native Google Picker — the same "Open from Drive" dialog you already use everywhere else in Google — instead of manually entering document IDs. You click, you search, you select, you're done. This post is a walkthrough of how that works, what's actually happening underneath, and the watch-outs worth knowing before you wire your knowledge base to Drive.

The old way: document IDs by hand

To be clear about what changed, here's the thing it replaced. A Google Doc's URL looks like docs.google.com/document/d/1aBcD…XyZ/edit. The long string in the middle is the document ID, and the previous flow asked you to copy just that string (not the whole URL, not the trailing /edit) into a field. It worked, but it was exactly the kind of fiddly, copy-paste-the-wrong-thing task that produces silent failures — you don't find out the ID was malformed until the agent can't read the doc on a live ticket.

Manual IDs also don't scale. Connecting one runbook is fine. Connecting the twenty docs that make up your real help center is twenty round-trips to twenty browser tabs. The Picker turns that into a multi-select.

The new way: pick it like you'd open it

The Google Picker is Google's own file-open dialog — the polished "choose a file from Drive" interface that handles browsing, search, and the authentication handshake for you, and hands the application back the file's metadata (its ID and URL) when you're done. Macha embeds it directly in the data-source flow. Because it's the native component, it behaves exactly the way your team expects: recent files up top, full-text search across your Drive, the "Shared with me" and "Shared drives" tabs, thumbnails, the lot.

Here's the connector side first. Google Workspace is an OAuth connector, so before any of this you authorize it once from the connectors page.

Once Google Workspace is connected, you add a data source to an agent. This is the Data Sources panel where each knowledge source — uploaded files, web pages, Notion pages, and Google documents — lives.

Choose Google as the source type and Macha opens the Picker. No ID box, no instructions about where to find the string in the URL — just Drive.

Search for the documents you want, filter to Docs and Sheets, and select them — one, or several at once. The Picker returns the file IDs to Macha behind the scenes; you never see or touch them.

That's the whole interaction. The documents become data sources on the agent, and from there Macha can do three things with them.

What the agent can actually do with a picked document

Connecting a file isn't the goal — the agent using it is. The Google Workspace integration gives an agent three capabilities once a Doc or Sheet is in scope:

• Read Google Doc — read the full content of a Doc by its ID or URL, on demand, mid-conversation. Good for "what does our policy say about X" lookups where the agent pulls the live document at answer time.
• Read Google Sheet — read data from a Sheet, either every tab or a specific range. This is the one people underrate: a price list, an SLA matrix, or a store-locator tab becomes structured data the agent can quote exactly.
• Sync Docs to Knowledge — index a Doc as a live knowledge source. Macha re-syncs the indexed copy on a recurring schedule, so when someone edits the doc in Drive, the agent's answers follow — no re-uploading, no stale PDF.

The distinction between reading on demand and syncing to knowledge matters, and it's also the answer to the obvious next question — how fresh is "live"? The two paths refresh differently:

• A Read Google Doc / Read Google Sheet is truly real-time. The agent fetches the document straight from Drive at answer time, so it always reflects the version that exists the moment the ticket is being worked. There's no index in between to go stale.
• A knowledge sync is periodic, not instant. Macha embeds the Doc into the agent's searchable knowledge base and re-indexes it on a recurring background sync rather than re-embedding the second you hit save — so expect a short lag (a re-sync interval, not seconds) between editing in Google and the change appearing in retrieval. For a returns policy that's edited a few times a quarter, that lag is invisible; for a price you change hourly and need exact, point an on-demand Sheet read at it instead.

A read is a tool call the agent makes when it decides it needs that specific document. A knowledge sync embeds the doc into the agent's searchable knowledge base so it surfaces automatically through retrieval, ranked against everything else the agent knows. Most teams want their core help content synced (so it's always in the retrieval pool) and reserve on-demand reads for long, rarely-needed, or fast-changing references the agent should only open when a ticket clearly calls for it. If you're standing up Google Docs as an agent's knowledge base for the first time, the Google Docs AI knowledge base walkthrough covers the end-to-end setup beyond just the Picker.

Live sync is the part that earns its keep

The reason to pipe Drive into an agent rather than uploading a static export is that Docs move. Your returns window changes for the holidays; a SKU gets discontinued; legal rewrites a clause. With a live-synced Doc, you edit it once in Google and the agent's knowledge updates on the next sync pass — the same model competitors describe with a manual "Resync" button, except Macha runs the re-sync for you on a schedule and you're editing the source of truth your team already maintains, not a copy you have to remember to refresh. That's the whole pitch for connecting Docs instead of dumping files: one place to update, and the agent never drifts from it. (This applies to any connected wiki, not just Drive — see how to connect knowledge sources to an AI agent for the cross-source view, including Notion and Confluence.)

What's happening underneath (and why it's safer)

The Picker isn't just a nicer front end — the pattern it's built on changes the permission model, for the better.

The Google Picker is the front end for a least-privilege flow: Google recommends pairing it with the drive.file scope, which is non-sensitive because an app granted it can only ever see the specific files the user explicitly selects through the Picker, not their whole Drive. In other words, the Picker pattern is designed so the application sees what you pick and nothing more — you're not handing an AI agent a master key to every document in your Google account; the four runbooks and the one price sheet you chose are the files in play. That's a meaningfully smaller blast radius than a broad "read all your Drive" grant, and it's the kind of thing your security reviewer will (rightly) ask about — so confirm the exact scopes Macha requests on the Google Workspace integration page when you authorize it.

The Picker also handles the OAuth token exchange itself — for web apps it's handed an access token and manages the browsing session — which is why the experience feels like the rest of Google rather than like a third-party form bolted onto Drive.

Where this fits in a real support setup

A concrete shape that works well: a Zendesk-triggered agent whose synced knowledge is your three or four canonical policy Docs (returns, shipping, warranty), with on-demand Sheet reads wired to a live pricing or inventory tab. A ticket comes in asking "can I still return this and what'll the refund be" — the agent retrieves the returns policy from synced knowledge for the rules, reads the pricing Sheet for the exact figure, and drafts a reply that's correct today, not correct as of whenever someone last exported a PDF.

Macha is the agent layer on top of your helpdesk — Zendesk, Freshdesk, Gorgias, Front — so the Google content feeds agents that act inside the helpdesk you already run; it isn't a replacement for any of them. The Picker is simply the on-ramp that gets your Drive knowledge into those agents without the busywork. If you want the broader picture of how knowledge sources work, the Data Sources docs and Connectors docs cover the rest of the flow.

Watch-outs / when this isn't the right tool

No feature is free of trade-offs. A few honest ones:

• It needs Google Workspace OAuth. If your docs live in Notion, Confluence, or a public help center, this specific flow isn't your path — connect those sources instead. The Picker is for Drive.
• Picked ≠ permanently shared with the org. Selection is per data source. If you delete the source or revoke the Google connection, the agent loses access — by design, but worth knowing if answers suddenly go vague.
• Sheets are read as data, not magic. A Sheet read returns the cells; it doesn't interpret a tangle of merged headers and pivot tables for you. Clean, tabular ranges read far better than a dashboard tab. Point reads at a specific range when the layout is messy.
• Reads and syncs consume credits. Every Read Google Doc or Read Google Sheet is a tool call, billed per AI action like any other — default GPT-5.4 Mini = 1 credit (0.5–9 by model). Syncing to knowledge is the more economical pattern for content the agent needs constantly, because retrieval pulls the relevant chunk rather than re-reading a whole document every time. See the pricing page for how credits work.
• Huge documents are still big. A 60-page Doc read on-demand is a lot of tokens to pour into one turn. For sprawling references, sync to knowledge (so retrieval grabs only the relevant section) rather than reading the whole thing.

FAQ

Do I still need to copy document IDs? No. That's the entire point of the April 9, 2026 change — you select Docs and Sheets through the native Google Picker, and Macha captures the IDs for you. Manual entry is gone.

Can I select multiple documents at once? Yes. The Picker is multi-select, so you can add several Docs and Sheets in one pass instead of connecting them one at a time.

Does the agent see my whole Google Drive? No. The Picker pattern is built around Google's least-privilege drive.file scope, where the application can only access the specific files you select through the Picker — files you don't pick stay invisible. Confirm the exact scopes Macha requests when you authorize Google Workspace.

What's the difference between reading a Doc and syncing it to knowledge? A read pulls a specific document live, on demand during a conversation. A sync indexes the Doc as a knowledge source so it's always available through retrieval — and re-syncs on a recurring schedule when you edit it in Drive. Most teams sync core policies and reserve on-demand reads for long, rare, or fast-changing references.

How often does a synced Doc update — is it instant? It's periodic, not instant. A synced Doc is re-indexed on a recurring background sync, so there's a short lag between editing in Google and the change appearing in the agent's retrieval — fine for policies that change a few times a quarter. If you need a value to be exact the instant it changes (like an hourly price), use an on-demand Read Google Sheet/Doc instead, which always fetches the current version with no index in between.

Can it read Google Sheets too, not just Docs? Yes. The Read Google Sheet action reads all tabs or a specific range — useful for pricing tables, SLA matrices, and inventory.

Try it

If your support truth lives in Google Docs and Sheets, this is the fastest way to put it in front of an agent. Start a 7-day free trial, no credit card required, connect Google Workspace, and pick the documents you want your agent to read — no IDs, no exports, no stale copies. For the full setup, the Google Workspace integration page and the Data Sources docs walk through it end to end.

Written by Abbas (Customer Support & AI, Macha) · Reviewed by Ankeet Guha (Co-founder & CTO) · Published 2026-06-24 · Last updated 2026-06-24.