Use a DRAFT_ tab for agent spreadsheet writes

Why this matters

No spreadsheet MCP exposes a “draft cell” mode. Once the agent calls a write tool, the cell is live. Google Sheets, Excel via Microsoft Graph, Composio Google Sheets, the community connectors: none of them have a staging layer between the agent’s tool call and what your team sees when they open the sheet.

The pattern that gives you a structural review gate without waiting for the MCP layer to grow one is the DRAFT_ tab pattern: the agent writes to a separate tab named DRAFT_summary (or DRAFT_inventory, or DRAFT_<work>: your call). The live tab stays canonical. The human reviews the DRAFT_ tab, decides which rows to accept, and copies the accepted rows into the live tab. The live tab is the record; the DRAFT_ tab is the review gate.

This is not a sophisticated pattern. It is a tab named DRAFT_ and a tool policy that prevents the agent from writing anywhere else. The discipline is human: the team agrees the DRAFT_ tab is where the agent works, and the live tab is where decisions live.

Nothing migrates from DRAFT_ to live on its own: you read the DRAFT_ rows, you decide which to accept, you copy the accepted rows into the live tab.

Quick start

1. Add a DRAFT_ tab to your live sheet: open the spreadsheet, create a new tab named DRAFT_summary (or whatever fits the work). Mirror the live tab’s column headers in row 1. The DRAFT_ tab has no formulas, no validation; it is a scratch surface.
2. Wire Composio Google Sheets (Add an MCP server): the managed-OAuth path is the cleanest for new users. The community connectors work too; the trade-off is more setup. Pin the connection to a specific Google account, not a personal one.
3. Restrict the tool policy to the DRAFT_ tab (Define a tool policy): the agent’s tool policy must scope writes to the DRAFT_ tab range only. The exact mechanism depends on the connector; some accept a range filter, some accept a tab-name filter. Verify the policy by trying to write to the live tab in a test run: the write should fail.
4. Write the one-page operating note: Admin Agent power move 3: a one-page note explaining the DRAFT_-to-live review step. Lives beside the sheet (a context file, a wiki page, or row 1 of the DRAFT_ tab itself). Names who reviews, when, and what triggers a copy to the live tab.
5. Run a five-row smoke test: paste five real rows of input, let the agent populate the DRAFT_ tab, walk through the review-and-merge step manually. Adjust the column shape before scaling.

Done? A sheet with a DRAFT_ tab the agent writes to, a tool policy that prevents the agent from touching the live tab, and a written note your team reads before the first merge.

The agent can do that?

1. Bootstrap the DRAFT_ tab from your live sheet

Chat → Admin Agent:

Live sheet tab: [paste tab name + headers]. Build the matching DRAFT_<work> tab structure: same column headers, no formulas, no data validation, with row 1 highlighted yellow as a visual reminder that this is a DRAFT_ tab. Output the column list and the formatting rules I should apply by hand in the Sheets UI. Do not call any write tool; this is a structure prompt only.

Why it’s non-obvious: The DRAFT_ tab and the live tab need matching shapes so the manual copy-paste step works without remapping. Asking the agent to enumerate the structure before you create it (instead of asking it to create the tab) keeps the wiring step in your hands, which matters because the agent’s write tool policy is not configured yet at this point.

2. Lock the tool policy

I'm writing a tool policy for an agent that writes to a Google Sheet via Composio. The agent must only be able to write to range "DRAFT_summary!A:Z" on sheet ID [paste sheet ID]. List the tool policy rules needed: which tools to allow, which to block, what range parameters to enforce. Flag any tool the agent would need where the policy cannot enforce the range and a human verification step is required instead.

Why it’s non-obvious: Tool policies on MCP connectors vary in granularity. Some support range-level enforcement; some only support tool-name-level enforcement. If the policy cannot enforce the range, the human verification step (running a test write to a live-tab cell and confirming it fails) is the only proof. The agent helps you write the rules; you confirm them in the Auxot UI before any real run.

3. Operating note for the review-and-merge step

Sheet purpose: [one sentence: e.g., "Track quarterly subprocessor inventory for procurement"]. Owner of the live tab: [name]. Owner of the DRAFT_ tab review: [name, may be different]. Produce a one-page operating note: (1) what the DRAFT_ tab is for, (2) who reviews it and how often, (3) what triggers a copy to the live tab, (4) what to do when the DRAFT_ tab fills up faster than the reviewer can keep up. Tone: factual, no apology language. The note lives beside the sheet so the next person who joins the team can read it cold.

Why it’s non-obvious: The pattern fails on the human side, not the technical side. A written operating note is the cheapest insurance against the reviewer skipping the review or the owner falling behind. The note is also evidence: if an auditor or a customer asks how the spreadsheet’s accuracy is maintained, you can show them the note.

Go deeper

Why not “let the agent edit the live tab directly”

Two reasons. First, no spreadsheet MCP exposes a draft layer at the cell level. The agent’s first write is the live state; there is no rollback affordance for the reviewer beyond manual undo. Second, the value of the review step is that it actually happens. A reviewer who knows the agent wrote directly to the live tab will start skipping the read. The DRAFT_ tab is a forcing function.

When sensitive data is in scope

If the rows contain PII, internal contract figures, or buyer-specific names, the cloud-MCP path becomes a separate concern. Even on the DRAFT_ tab, the data has left your environment to land in the Sheets cloud. The offline-file alternative is an Excel MCP (for example haris-musa/excel-mcp-server) that writes a local .xlsx your team merges into the canonical sheet manually. No cloud, no OneDrive, no Graph API in the loop. The Worth-knowing operating note still applies: the file is the gate, the manual merge is the discipline.

Why Composio specifically

For Google Sheets, Composio is the cleanest managed-OAuth path for new users: the OAuth flow stays inside Composio’s UI, and the connection persists across Auxot agents that share the team’s connector. The community connectors (mkummer225/google-sheets-mcp, shionhonda/mcp-gsheet) work and are more flexible, but they require running your own Google Cloud project and managing the OAuth credentials yourself. Recommend Composio for the first wiring; revisit if Composio’s per-call cost becomes a budget concern at volume.

Naming convention for the DRAFT_ tab

DRAFT_ is the prefix. The suffix names the work: DRAFT_summary, DRAFT_inventory, DRAFT_followups. Multiple workflows can write to multiple DRAFT_ tabs on the same sheet; the prefix makes it obvious which tabs are agent-write surfaces and which are canonical record. Avoid one shared DRAFT_ tab for everything: the review-and-merge owner cannot context-switch between unrelated work safely.

Troubleshooting

• The agent wrote to the live tab anyway. The tool policy did not enforce the range, or the agent picked a different write tool than the one you scoped. Confirm in Audit Logs (View your audit logs) which tool actually fired. Tighten the policy or revoke the offending tool entirely.
• The DRAFT_ tab fills up faster than the reviewer can keep up. Slow the agent down before relaxing the gate. Cap the workflow’s intake (fewer rows per run), or rate-limit the trigger (daily instead of hourly). Unlocking the live tab is the wrong fix.
• The reviewer skims and copies everything. Restructure the review step. Add a “rows that changed since last review” column. Add a hash on key fields so the reviewer can see at a glance which rows are net-new and which are updates. The skim is a discipline problem, but the design can make discipline easier.
• Two reviewers disagree on which rows to merge. Document the tiebreaker in the operating note before the disagreement happens again. Common patterns: the agent’s output is treated as a proposal, and either reviewer can reject; the live tab gets a last_reviewed_by column.

Variations and edge cases

• The live sheet is read by external systems. A downstream report, a Looker dashboard, or a Slack pull from the live tab. The DRAFT_ tab pattern stays the same; just be aware that any rows the reviewer merges hit those systems immediately.
• The live sheet is the spec for a workflow that already runs. The DRAFT_ tab pattern is even more important here: an unreviewed change to the live tab could change behavior in a system the team relies on. The reviewer’s role escalates to “owner of the spec,” not just “reviewer of agent output.”
• The team uses Excel, not Sheets. The same pattern works with Excel via Microsoft Graph (Composio Excel, softeria/ms-365-mcp-server). The DRAFT_ tab lives in the same workbook as the live tab; the tool policy locks the agent to the DRAFT_ range. Same operating-note discipline applies.
• A workflow needs to write to multiple sheets. Each sheet gets its own DRAFT_ tab. The agent’s tool policy scopes the allowed range per sheet ID. The operating note enumerates each sheet, owner, and review cadence.

Walkthrough

Step 1: Add the DRAFT_ tab in the Sheets UI

Open the live sheet. Right-click the bottom tab bar, choose Add sheet, name it DRAFT_<work>. Copy row 1 from the live tab into row 1 of the new tab. Apply visual highlighting (cell background color) to row 1 of the DRAFT_ tab so anyone opening the sheet immediately knows which tab is the draft surface.

Step 2: Wire Composio Google Sheets

Open Settings → MCP servers in Auxot. Add the Composio Google Sheets connector (Add an MCP server). Walk through the OAuth flow using the team’s Google account. After the connection is live, run a single read tool call to verify the connector can see your sheet (the agent should list the tab names back to you).

Step 3: Write the tool policy

Open Settings → Tool Policies (Define a tool policy). Create a new policy. Allow the read tools (the agent needs to read the live tab to know what is already there). Allow the write tools, but scope the allowed range to DRAFT_<work>!A:Z on the specific sheet ID. Block any write tool that does not accept a range parameter: the agent should not have a path to write outside the DRAFT_ tab.

Step 4: Test the policy

Ask the agent to write a single test value (e.g. TEST-001) to cell A1 of the live tab. The write should fail with a policy error. If it succeeds, the policy is not enforcing the range; fix the policy before any real run.

Step 5: Write the operating note

Use power move 3 to draft. Edit until the note covers the four points (what, who, when, overflow) in a way a new team member could read cold. Store the note beside the sheet: a context file with the same name as the sheet, a wiki page, or row 1 of the DRAFT_ tab if your team prefers everything in one place.

Step 6: Run the five-row smoke test

Trigger the workflow with five real rows of input. Wait for the DRAFT_ tab to fill in. Walk through the review-and-merge step manually with the named owner. Note any friction (column shape, formatting, missing context). Adjust before scaling.

What’s next

• → Add an MCP server. The MCP wiring layer this pattern depends on.
• → Define a tool policy. The range-scoping mechanism that makes the DRAFT_ tab gate structural.
• → Batch spreadsheet rows through a workflow. The most common consumer of this pattern: batch writeback to a sheet.
• → Track which audit fields each questionnaire asks about. Spreadsheet variant of the questionnaire log uses this pattern as its safe-write path.
• → View your audit logs. When you need to verify which write tool fired and what range it touched.
• → Plan for retention and deletion requests. When the rows in the DRAFT_ tab contain customer data that itself needs retention rules.

Reference

• Naming convention: DRAFT_<work>: the prefix is the marker, the suffix names the work.
• Tool policy scope: range-level (DRAFT_<work>!A:Z) on the specific sheet ID. Test the policy by attempting a live-tab write and confirming it fails.
• Recommended connector: Composio Google Sheets for managed OAuth; community connectors (mkummer225/google-sheets-mcp, shionhonda/mcp-gsheet) when you want self-hosted OAuth.
• Excel variant: Composio Excel or softeria/ms-365-mcp-server for OneDrive-hosted workbooks; offline-file Excel MCP (haris-musa/excel-mcp-server) when sensitive data should not leave the local environment.
• Operating note fields: what the DRAFT_ tab is for, who reviews and how often, what triggers a copy to the live tab, what to do when the DRAFT_ tab fills up faster than the reviewer.
• Owner role: named person responsible for the review-and-merge step. Cadence documented in the operating note.
• Smoke-test discipline: five real rows before scaling. Adjust column shape based on friction.
• See also: Batch spreadsheet rows through a workflow, Track which audit fields each questionnaire asks about, Add an MCP server, Define a tool policy, View your audit logs