The usual way to get feedback on something an agent wrote is to put it in a Google Doc. That works well for prose that will live in Workspace. It works badly for what agents increasingly produce: HTML with charts, tables that sort, mockups and slides.
Checked against Google's documentation in October 2026; links below.
Side by side
| Onlay | Google Docs | |
|---|---|---|
| Keeps your agent's HTML as it is | Yes, scripts, charts and layout included | No: an import becomes Docs formatting; scripts and custom layout are lost |
| Markdown | Rendered as a clean page | Import and export since 2024 |
| Readers need an account to comment | No, unless you restrict the document | A Google account |
| Editing | Readers edit text in place when you allow it | Full editing, with suggestion mode and accept/reject |
| What comes back to the agent | Edits as before and after with source lines, comment threads with quotes, page state, from the CLI or MCP server | Comment threads with quoted text through the Docs API and Google's Docs MCP server, which is in developer preview and needs a Google Cloud project |
| Where the source lives | Your agent's file stays the source; feedback flows back into it | The Doc becomes the source |
Choose Google Docs when
- Reviewers already live in Google Workspace, and the result should end up as a Doc, a .docx or a PDF.
- You need tracked changes with accept and reject, or your organisation's admin and data controls.
- The document will be co-written by many people for a long time.
Choose Onlay when
- The agent's output is HTML: charts, interactive tables, mockups, slides. Converting it throws that away.
- Reviewers are outside your organisation and shouldn't need an account.
- You want the agent to keep its own file as the source and apply feedback to it, then publish the next version to the same link.