We will soon roll out Google Workspace Model Context Protocol (MCP) servers that expose new functionality to external AI agents across Gmail, Drive, Calendar, and other Workspace apps using the open MCP. Ahead of this launch, we are introducing an “agentic” setting (is_agentic) on Google OAuth clients, so that Google and Workspace administrators can differentiate AI agent traffic from traditional app traffic. Only OAuth clients marked as agentic will be able to call Workspace MCP servers. [emphasis mine]
In our recent review of the Q3 2026 Google Workspace Developer Release Notes, we looked at the expansion of remote Google Workspace MCP servers across Gmail, Drive, Docs, Sheets, Slides, Calendar, and Chat. At the time, I noted that while MCP is great for connecting local developer tools like Google Antigravity, giving external agents broad access across user documents raises real enterprise governance questions.
Google has now started sending developer notifications announcing a foundational change to address this, a mandatory agentic classification (is_agentic) for OAuth 2.0 clients. If you have configured OAuth clients in the Google Cloud console for AI agents or MCP servers, there is a tight one-month window to update your existing credentials.
A couple of key details and technical requirements from the announcement and the updated Manage OAuth Clients documentation are worth highlighting:
Hard Enforcement and Permanent Lock-In (November 11–12, 2026): Starting October 12, 2026, developers can edit existing OAuth clients in the Google Cloud console (Google Auth Platform > Clients) and select the Use this client for an AI-powered agent checkbox. On November 11, 2026, Workspace MCP servers will begin rejecting requests from any OAuth client not marked as agentic. Crucially, on November 12, 2026, the is_agentic setting becomes permanent on existing clients, if you miss the November 11 window, you cannot toggle the setting on an existing client and will have to create a new OAuth Client ID and update your client configurations (such as ~/.gemini/config/mcp_config.json in Google Antigravity).
Separate OAuth Clients for Human vs. Agent Traffic: According to Google’s updated best practices for agent client isolation, if your solution provides both human-interactive features (calling standard Google REST APIs) and AI agent workflows, you must maintain separate OAuth 2.0 Client IDs for each workflow. Tagging an OAuth client as agentic does not grant extra scopes or bypass user consent, but it isolates agent traffic so Workspace administrators can apply dedicated agent access controls and security policies without disrupting human users on your standard app.
Traditional Apps Script and REST Integrations Are Unaffected: If your application or Apps Script project is not an AI agent and only calls standard Google Workspace REST APIs, no action is required. However, Google recommends marking any OAuth client used by an AI agent, even if that agent currently only calls Workspace REST APIs, so it is properly classified ahead of the November 12 lock-in. Romain Vialard has however highlighted that the client ID for Apps Script is not editable in GCP so it’s not possible to mark it as agentic. The only workaround at this point is using a standard GCP, creating your own client ID and using the OAuth2 Apps Script library.
Seeing this land makes a lot of sense. Before enterprise admins can confidently allow MCP integrations or external AI agents in production domains, they need a reliable way in the Admin console and Security Investigation Tool to distinguish an autonomous agent acting on behalf of a user from a conventional web app. Separating those identities at the OAuth client level is the logical first step toward granular agent governance.
If you have existing Google Cloud projects using Workspace MCP servers, Agent Development Kit (ADK) workflows, or Gemini Enterprise connectors, head over to the Google Auth Platform Clients page before 11 November 2026 to review and update your OAuth client settings.
Email Notifications for Impacted Projects: To help, developers should check their inbox for service communications from Google with the subject ‘[Action Required] Mark AI agent OAuth clients as agentic for Google Workspace MCP by Nov 11, 2026‘, as these list the affected Google Cloud projects.
Gemini Spark, announced at Google I/O 2026, was launched as “your 24/7 personal AI agent that helps you work more efficiently by autonomously taking action on your behalf, under your direction… Spark operates in a fully managed, secure runtime on Google Cloud, meaning you get enterprise-grade security without ever having to manage the underlying infrastructure.”
If you have access to Gemini Spark, you will already know it has deep integrations to read and write your Google Workspace data. Like most of Google’s products, the infrastructure used by Gemini Spark is also accessible to developers. In the case of Gemini Spark, a key component is Managed Agents:
Managed agents on the Gemini API give you a configurable agent harness. A single API call provisions a Linux sandbox where the agent reasons, executes code, manages files, and browses the web autonomously.
The particular flavour of Managed Agents I was interested in was:
Antigravity agent: General-purpose managed agent powered by Gemini 3.7 Flash. Runs code, manages files, and searches the web inside a secure Linux sandbox hosted by Google. You can extend it with your own instructions, skills, and data to build a custom agent.
To replicate Gemini Spark’s integration with Google Workspace, this demo project installs the Google Workspace CLI (gws) into an agent orchestrated from a Google Apps Script web app.
Turning Raw Drive Docs into Executive Briefings
The setup is deliberately modest. Imagine a Google Drive folder containing raw Google Docs. in my case, copies of Google Workspace Updates and Gemini Enterprise announcements. I want to convert this growing folder into structured, evidence-backed briefings for Workspace developers and business stakeholders, a clean source register, and visual summaries.
An Apps Script web app runs as the accessing user.
The user supplies a source folder ID and an output folder ID.
Apps Script starts a Managed Agent interaction.
A virtual environment is prepared with:
the gws Google Workspace CLI;
a Python document and analysis toolchain including python-pptx, python-docx, matplotlib, and pandas;
an agent policy (AGENTS.md) and workflow skill (SKILL.md);
a per-run .env file containing the current user’s OAuth access token, approved folder IDs, and optional date timestamps.
The agent accesses Drive through gws to find and retrieve relevant source documents using server-side queries.
It generates multi-format deliverables (Word, PowerPoint, chart, CSV) locally in /workspace/output.
It uploads the final reports to the selected output folder.
One of the biggest advantages of a Managed Agent over a basic API call is the ability to provision a full Linux sandbox, preconfigured with Python 3.12 and Node.js 22. You can also install additional libraries and binaries dynamically. In this project, the agent creates the following outputs before uploading them:
Output Asset
Tooling / Libraries
Pre-installed vs. Runtime
Purpose
source-register.csv
pandas
Pre-installed
Aggregates metadata, sorts, and filters document sources.
updates-summary-chart.png
matplotlib
Installed via pip
Visualizes update frequencies and product area breakdowns.
executive-presentation.pptx
python-pptx
Installed via pip
Compiles an executive presentation deck formatted into structured slides.
executive-briefing.docx
python-docx
Installed via pip
Generates a styled Word document with headers, callouts, and structured tables.
executive-briefing.md
Plain Text / Markdown
Native Filesystem
Provides a lightweight narrative briefing summary.
run-manifest.json
JSON / jq
Pre-installed
Audit record of all actions taken during the run.
Screenshots
Creating a Managed Agent
To allow the agent to interact with Drive on the user’s behalf without an interactive login prompt, Apps Script fetches the user’s OAuth token:
const userToken = ScriptApp.getOAuthToken();
To limit the potential blast radius, the appsscript.json manifest strictly scopes requested permissions:
Using drive.file ensures that write access is scoped strictly to files created or explicitly opened by the application, preventing modification of other Google Drive files.
Seamless Credential Delegation to gws
A common challenge with a headless agent environments is authentication. How do you allow a CLI tool to act on the user’s behalf without interactive browser logins (gws auth login) or baking long-lived service account keys into the agent definition?
The gws CLI addresses this by supporting environment-based authentication. When invoked, gws checks for the GOOGLE_WORKSPACE_CLI_TOKEN environment variable. By mounting a transient /workspace/.env file directly into the sandbox environment during interaction creation, gws automatically authenticates all Drive API operations using the active user’s short-lived OAuth token.
Because this token exists solely in memory within the temporary container instance, it naturally expires and is never saved to persistent storage.
Example Interaction Creation Request
The entire custom Managed Agent is created with a single API call. An example payload used in this demo project is included below:
The payload allows developers to include both an AGENTS.md and SKILL.md into the sandbox
System Instructions (.agents/AGENTS.md): Establishes boundaries requiring the agent to only read from SOURCE_FOLDER_ID, only write to OUTPUT_FOLDER_ID, and never disclose /workspace/.env. It instructs the agent to treat all retrieved Workspace text as untrusted reference data, ignoring any embedded instructions or prompt injections.
Workflow Skill (.agents/skills/update-intelligence/SKILL.md): Provides structured workflow guidance for using gws drive with field masks, executing Python scripts for artifact generation, and mapping file extensions to Google Drive MIME types during upload.
Tooling and Sandbox Bootstrapping (tools & bootstrap.sh)
As well as the instructions and policies, the payload also configures the agent with execution capabilities and installs the required runtime toolchain:
tools: [{ type: "code_execution" }]: Activates the Linux terminal and Python interpreter, allowing the Antigravity agent to write, execute, and debug scripts inside its container.
bootstrap.sh & requirements.txt: The payload requires the agent to execute /workspace/bootstrap.sh on startup. This script downloads the static gws CLI binary and installs the specified Python libraries (pandas, matplotlib, python-docx, python-pptx) dynamically.
Asynchronous Execution and State Persistence (background & store)
A workflow that inventories dozens of Google Docs, generates slide decks and Word documents, and uploads deliverables to Drive can take several minutes to run. Two flags make this practical from Google Apps Script:
background: true: Launches the agent run asynchronously, immediately returning an interaction_id. The frontend UI simply polls the interaction endpoint periodically for status and live step progress.
store: true: Persists the interaction transcript and environment state on Google’s infrastructure. This not only allows the web app to retrieve the final summary and token usage metrics when finished, but also enables multi-turn follow-ups—allowing users to ask the agent to revise or refine documents within the same container without re-bootstrapping.
Summary and References
Combining Managed Agents with the Google Workspace CLI unlocks opportunities to automate complex, multi-step document workflows. Combining the latest Gemini models via the Antigravity agent with a full 4 vCPU / 16 GB Linux sandbox gives developers the ability to build capable autonomous agent workflows directly from Google Apps Script.
The flip side of this, particularly with recent news stories of agents escaping sandboxes, is the implication of providing managed agents with a user token. This is no different from the OAuth token flow already used when extending applications; the difference here is that it is being passed to an agent that can “think” and “reason”. In Google Workspace, it is positive to see that agentic security and governance is being surfaced to administrators for built-in services, but it feels to me that the protocols and standards are still catching up. For users, my advice is to pause and think before you click continue in authentication flows.
Google Chat’s cardsV2 widget set is fixed — no custom layout, no charts beyond what Google ships. The fix: render the atom to a real image server-side and hand Chat a plain URL. This piece covers the real, self-hostable Cloud Run bundle, the exact wire-level trace of one request, and the Chat-setup gotchas Google’s own docs don’t lead with.
The clever solution is to render the complex visual elements using headless Chromium generating a PNG or animated GIF that can be shown as an image in Google Chat. Of course this has its limitations for interactive form elements but makes it possible to render complex dashboards, custom charts and more.
The really clever bit is as a developer, you create an AI agent that uses a single consistent A2UI vocabulary. If the platform supports live web components, these can be drawn interactively and if not your backend automatically “prints” the exact same A2UI element as a PNG or GIF.
If, like me, you’ve often struggled with the pain of coding user interfaces with the CardService in Google Workspace, things are about to change. Using the new, open Agent2UI (A2UI) specification, agents can autonomously decide how to structure and render their own native interfaces in real time.
In a recent Pulse post, The Evolution of Google Chat: Exploring the New Wave of Developer Quickstarts, we highlighted a new Google tutorial that implements Agent2UI (A2UI) inside Google Chat. This guide shows you how to build a hybrid solution using Apps Script as a secure, lightweight gateway to Python-based agents running on the Vertex AI Agent Engine.
The Architecture: Apps Script as the Orchestrator
A common challenge when working with modern AI toolkits like the Agent Development Kit (ADK) is that they are not designed to run natively inside Apps Script. The quickstart bridges this divide by turning Apps Script into a lightweight, secure orchestration layer.
Instead of running heavy processing directly inside the script, Apps Script handles the Google Chat event, manages secure server-to-server authentication, and sends the payload out to an agent running on the Vertex AI Agent Engine.
Under the Hood
A look at the script provided in the quickstart shows how the Python backend passes UI layout instructions back to the Workspace front-end. When a user asks a question, the Python script processes the request, calls any backend tools and returns a single text stream structured like this:
When this response is returned to Google Apps Script, it triggers the extractA2UIParts() function which splits this raw payload on the ---a2ui_JSON--- separator. The text before the delimiter (e.g., “Hello! I found the profile…”) is taken and posted straight to the user and the raw JSON array after the delimiter is to make the card.
Something to keep in mind is that this framework is not yet a wholesale replacement for the entire CardService library, as you will see in the script it uses a basic render to convert the A2UI JSON into CardService elements:
switch (Object.keys(component)[0]) {
case 'Text':
const textParagraph = CardService.newTextParagraph();
textParagraph.setText(extractTextValue(component["Text"].text, dataModel));
widgetWithIds.push({ id: c.id, widget: textParagraph });
break;
case 'Image':
const image = CardService.newImage();
image.setImageUrl(extractTextValue(component["Image"].url, dataModel));
widgetWithIds.push({ id: c.id, widget: image});
break;
case 'Button':
// Maps inline labels or child text components to TextButtons
// and packages them into a trailing ButtonSet...
break;
default:
console.warn(`Could not render component: ${JSON.stringify(c)}`);
}
This means that for the time being, the script example is only able to handle basic UI elements rather than handling heavy, structured data-entry flows.
Future Directions
While the quickstart provides a foundational v0.8 entry point for developers, community members are already looking at how A2UI responses can be used in Google Workspace interfaces.
An excellent example of this is Curtis Krygier’s open-source a2ui-catalogue project. Curtis has started a component library designed to build agent-driven interfaces for Google Workspace starting with Google Meet and Google Chat.
Instead of trying to bundle complex, pre-composed UI elements on the backend, Curtis advocates for a substrate model:
Atomic Philosophy: Developers define a fixed visual vocabulary of atomic “primitives” once on the client side (such as TypeScript Lit web components).
Token Efficiency: The AI agent reasons entirely within this stable vocabulary. It passes raw state updates rather than inventing presentation layouts on every conversational turn. This reduces token overhead and eliminates slow backend container redeployment loops.
Interchangeability: By completely decoupling primitives from the transport layer, the exact same v0.9 component tree can reflow dynamically across completely different containers. A layout originally designed for a fullscreen stage in a Google Meet iframe can seamlessly stack and reflow to fit inside a compact Google Chat card or side panel.
Summary
For Google Workspace developers, the base A2UI Agent quickstart serves as an excellent hands-on starting point to experiment with agent integrations in Google Workspace. The underlying frameworks are evolving rapidly, as are the solution wrappers like a2ui-catalogue. Given a speed of change don’t expect a completely frictionless, single-click deployment out of the box, and you’ll likely need to lean into a little “Gemini-powered” fault finding should sort things out.
A Comparative Study of Agentic Frameworks and Multi-Agent Orchestration
Earlier this week, we explored how Bruce Mcpherson’s gas-fakes agent provides a secure, sandboxed alternative to my initial experiments with the Workspace CLI. While securing local execution is a necessary step, it surfaces an entirely new operational headache. As we build out these agentic behaviours, what happens when your AI has access to too many tools?
As Kanshi Tanaike identifies, these systems hit a cognitive wall known as ‘Tool Space Interference’, a concept recently detailed by Microsoft researchers, which is widely recognised across the industry as context bloat. As noted in Google’s recent engineering piece on architecting context-aware frameworks, “single-agent systems struggle with context bloat; multi-agent systems amplify it.” If you load an agent’s active memory with 160 different Workspace functions, its reasoning accuracy degrades significantly; your token costs also spiral out of control.
Tanaike tackles this phenomenon head-on in his latest comparative study. He contextualises my own CLI skill-based prototyping and Bruce’s local emulation, mapping them against the architecture of the newly announced Gemini Enterprise Agent Platform at Google Cloud Next ’26.
I must admit, while I was proudly figuring out how to chain a few CLI commands together without crashing my terminal, Tanaike was already designing complex orchestration networks using multiple autonomous agents to resolve this friction.
Delegating to Sub-Agents
To combat Tool Space Interference, Tanaike proposes dynamic tool creation. Rather than pre-loading an agent with functions, a primary orchestrator delegates tasks to sub-agents that write, test, and deploy custom Google Apps Script code on the fly. This entirely removes the need to store static skills in the agent’s memory.
Alternatively, he suggests using the Agent-to-Agent (A2A) protocol to shift large libraries of predefined skills onto remote Apps Script Web Apps. By bypassing complex cross-domain authentication using local agent cards, this method clears the main agent’s active memory while retaining frictionless access to legacy macros.
The Conscious Expert: Zero-Trust Routing and Caching
To safely manage these multi-agent delegations, Tanaike introduces two advanced frameworks: the Federated Context-Aware Routing Architecture (Federated CARA) and the Self-Optimising Tool Caching Network (SOTCN). From a data governance perspective, these concepts provide a fascinating blueprint for enterprise security when combined.
Federated CARA acts as a zero-trust architecture that evaluates the classification of the data involved in any given prompt. Based on this sensitivity, it dynamically routes the AI task to either a containerised emulation environment or a remote A2A subagent. This design maps perfectly to the Agent Gateway and Agent Identity features introduced within the Gemini Enterprise Agent Platform, ensuring that native IAM access control policies are strictly enforced to guard against data exfiltration.
Building on this secure routing pipeline, SOTCN functions as an additional security perimeter by treating skills as modular assets kept in “cold storage”. By using semantic search, the network programmatically retrieves and inserts only the necessary capabilities into the agent’s prompt during a given session. This approach has just been validated by the launch of Google’s official Agent Skills repository at Next ’26. By publishing compact, agent-first Markdown files to be loaded entirely on demand, Google is signalling a wider industry push towards “Context Engineering”.
Tanaike’s synthesis offers a highly scalable roadmap for multi-agent orchestration. I highly recommend reading his full paper and watching the accompanying explanatory video to see how these architectures align with Google’s new enterprise standards.
gf_agent is an interactive automation agent for Gemini CLI that enables users to access and manupulate workspace resources conversationally.
The automation of Google Workspace is advancing rapidly. We are moving away from static scripts and rigid cloud triggers towards environments where AI agents autonomously orchestrate complex tasks. Recently, I shared a recipe exploring how we could use the Workspace CLI to call the Apps Script Execution API. I was quite pleased with it, however, a recent email exchange with Bruce Mcpherson quickly highlighted a much more efficient path.
Bruce pointed out that his new gf_agent for the Gemini CLI bypasses the need to write these intermediary scripts entirely. By using his gas-fakes emulation environment, the agent accepts plain English requests, generates the required Apps Script logic dynamically, and executes it securely on your local machine. It is a brilliant piece of work. You simply ask the agent to summarise your latest emails or resize images in a document, and it handles the heavy lifting without using the Apps Script runtime.
To illustrate this capability, Bruce shared an excerpt from a recent run demonstrating a complete web to document flow, similar to the Workspace CLI / Apps Script Execution API example. The log captures the moment the system activates the local skill, maps the available resources, and then executes the required logic directly from the terminal:
✦ I will activate the gf_agent skill to access specialized guidance for Google Workspace automation.
╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ Activate Skill "gf_agent": Specialized agent for automating Google Workspace tasks locally using gas-fakes. Gener… │
│ │
│ Skill gf_agent activated. Resources loaded from /Users/brucemcpherson/.gemini/skills/gf_agent: │
│ │
│ Showing up to 200 items (files + folders). │
│ │
│ /Users/brucemcpherson/.gemini/skills/gf_agent/ │
│ ├───documentation.md │
│ ├───index.md │
│ ├───README.md │
│ ├───SKILL.md │
│ ├───scripts/ │
│ │ └───builder.js │
│ └───skills/ │
│ ├───base.md │
│ ├───cache.md │
│ ├───calendar.md │
│ ├───charts.md │
│ ├───document.md │
│ ├───drive.md │
│ ├───forms.md │
│ ├───gmail.md │
│ ├───jdbc.md │
│ ├───lock.md │
│ ├───properties.md │
│ ├───script.md │
│ ├───slides.md │
│ ├───spreadsheet.md │
│ ├───urlfetch.md │
│ ├───utilities.md │
│ └───xml.md │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ I will use the workspace_agent to fetch the content from the URL, create a Google Document from the HTML, copy it, and then
resize the images in the copy using the recommended Docs API workaround, as setWidth/setHeight are not supported in the
local environment.
╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ workspace_agent (gas-fakes-mcp MCP Server) {"script":"\nconst url = 'https://ramblings.mcpher.com/resurrecting-sc… │
│ │
│ 2026-04-24T11:49:08.017Z ...using env file in │
│ /Users/brucemcpherson/Documents/repos/empty/recipe-web-to-doc-gf/scripts/.env │
│ 2026-04-24T11:49:08.763Z ...gas-fakes version 2.3.9 │
│ 2026-04-24T11:49:08.763Z Fetching content from: │
│ https://ramblings.mcpher.com/resurrecting-scriptdb-nosql-database-for-apps-script/ │
│ 2026-04-24T11:49:09.451Z [Worker] ...authorized backends: google via DWD ([email protected]) │
│ 2026-04-24T11:49:09.451Z [Worker] ...using scriptId: ab9c5881-...-2bc29a0c8834 (source: env) │
│ 2026-04-24T11:49:14.788Z Created original document with ID: 1sQ7oGqKm9XOQzsYQF10fM6uiAoD2_OSJ6uAJgunPnbE │
│ 2026-04-24T11:49:17.980Z Created copy document with ID: 1Labz...ZSSo │
│ 2026-04-24T11:49:19.052Z Found 12 images in the document. │
│ 2026-04-24T11:49:19.053Z Applying 24 updates to resize images... │
│ 2026-04-24T11:49:21.557Z Image resizing complete. │
│ 2026-04-24T11:49:21.557Z Original Doc URL: │
│ https://docs.google.com/document/d/1sQ7...PnbE/edit │
│ 2026-04-24T11:49:21.558Z Resized Doc URL: │
│ https://docs.google.com/document/d/1Labz...ZSSo/edit │
│ 2026-04-24T11:49:21.563Z ...terminating worker thread │
│ │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ I have successfully fetched the content from the specified URL and created the requested documents.
Weighing the Approaches: Broad CLI vs Sandboxed Emulation
Let us consider the practical realities of these two approaches. The Workspace CLI generally operates under the broad OAuth scopes granted during its initial setup. If you authorise full Google Drive access, any AI agent driving that CLI inherently possesses the same unrestricted permissions. Handing an autonomous reasoning engine the keys to your entire file system is risky. A simple mis-prompt could lead to data loss or unintended modifications.
Conversely, Bruce’s gas-fakes approach offers a much tighter, sandboxed environment. Rather than relying on global credentials, gas-fakes can be explicitly configured to operate only on specific Drive files or within isolated boundaries. By functioning as a Model Context Protocol (MCP) server, it allows the LLM to write native Apps Script syntax and immediately test it against Workspace resources, but it forces the execution to happen within a securely fenced area. The primary benefit here is safe, dynamic adaptability. You do not need to pre-write a specific skill to resize an image; the agent simply authors the script on the fly and the emulator runs it safely.
It is worth mentioning that gas-fakes is still in development so not all Apps Script methods are implemented yet, but the approach provides a robust sandbox for interacting with Workspace APIs. Click through to Bruce’s post to read more.
The most striking demonstration at Google Cloud Next ‘26 was the “Chat Command Centre”. Julie Quan Kim showed how a user might invoke a “regional campaign skill” to orchestrate complex tasks across Docs, Slides, and external CRM data. While we have yet to see how “skills” will be created and managed, developers can already prototype these agentic behaviours using the Workspace CLI (gws) and the Gemini CLI.
These tools are the perfect laboratories for developing “skills” that could eventually be used in your own Workspace Intelligence platform. To test the boundaries of this, I have been building a “recipe” that fetches a webpage, converts the content into a natively formatted Google Doc, and then executes additional logic via Google Apps Script.
The Practical Bridge: The Web-to-Doc Recipe
This recipe, published in this repo, hopefully demonstrates how we can orchestrate a multi-step workflow using different tools. It is worth noting that the development of this very skill was facilitated by a specialised skill-creator subagent included in the latest Gemini CLI. This dedicated assistant handles the initialisation and packaging of new capabilities, which in itself makes the transition from a manual workflow to a reusable agentic skill remarkably easy.
The core logic of the Web-to-Doc recipe is defined in a simple SKILL.md file, which instructs the local agent to follow a strict pipeline:
Extraction via Node.js: The skill instructs the CLI to execute a local Node.js script (extract_article.js), which uses Mozilla’s readability and turndown libraries. This gives us a clean, “Reader View” markdown version of the article, stripping away the navigation menus and ads. With the announcement of the Gemini Enterprise Agent Platform I think it is very probable that Workspace customers would be able to use similar functions hosted in Cloud Run.
Native Conversion via CLI: Next, the agent passes this markdown file directly to the Workspace CLI. By explicitly setting the MIME type to application/vnd.google-apps.document, the CLI takes advantage of the Drive API’s ability to convert markdown into formatted Google Docs. With the announcement Workspace MCPs, including Drive, a similar conversion should be possible without the Workspace CLI
Refinement via Apps Script: This is my favourite part of the process. To ensure the embedded images do not overflow the document margins, the skill triggers a deployed Google Apps Script function (resizer.gs) using the gws script scripts run command. This is a level of precise document manipulation, specifically calculating page margins to ensure images do not overflow, is one that the high-level Drive API cannot perform during a simple import.
Governance and Security
Moving to this atomic, skill-based architecture is not without its friction. This homebrew approach of using different CLIs and managing authentication scopes across different local and cloud environments can be a severe headache and is very difficult to scale.
It also remains unclear if the Workspace Intelligence skills will include a script.run functionality found in the Workspace CLI. If it is included, it would be an exceptionally powerful way to extend skill capabilities. It would mean being able to build modular, portable sets of very repeatable code using the existing power, functionality and affordances of Apps Script.
This is where it will be very interesting to see how Workspace Intelligence manages this with the appropriate security and governance, especially considering the risks associated with Workspace MCP servers and the risk of indirect prompt injection attacks.
This is a rapidly evolving space. The ability to prototype these behaviours today using the Workspace CLI provides a direct path to understanding how the Agentic Enterprise could operate.
This article explores integrating remote subagents built with Google Apps Script into the Gemini CLI using the Agent-to-Agent (A2A) protocol.
Google recently announced that subagents have arrived in the Gemini CLI, allowing developers to extend the capabilities of the command-line interface by connecting it to external tools and services. This update provides a way to build more complex, multi-step workflows where Gemini can call upon specialized agents to perform specific tasks.
For the Google Apps Script community, this opens up interesting possibilities for connecting local terminal workflows with the Google Workspace ecosystem. Kanshi Tanaike has already explored this area, sharing a detailed guide on integrating remote subagents built with Google Apps Script with the Gemini CLI.
Extending the CLI with Apps Script
In his post, Tanaike-san demonstrates how to bridge the gap between a local environment and remote script functions. By deploying an Apps Script as a web app, it can act as a “remote subagent” that the Gemini CLI calls to perform actions within Google Workspace or process data using the Apps Script environment.
As Tanaike-san notes:
“By using Google Apps Script as a subagent, Gemini CLI can interact with Google Workspace services like Google Drive, Google Sheets, Google Docs.”
You can find the full technical breakdown, including the necessary code snippets and configuration steps, in Kanshi Tanaike’s blog post.
Understanding and spotting trends in organic YouTube traffic based on specific queries can often be a manual and time-consuming process. To solve this, the Google Marketing Solutions team has published an open-source repository for a tool called YouTube Topic Insights. Developed by Google Customer Solutions Engineer Francesco Landolina, the project transforms raw video data into actionable summaries by combining the data-gathering capabilities of the YouTube Data API with the video and language understanding of Gemini models.
For Google Apps Script developers interested in building scalable tools, this repository is a fantastic example of using Vertex AI at scale. It orchestrates complex, long-running processes directly from a Google Sheet and pairs them with Vertex AI batch prediction. In this post we will highlight some interesting infrastructure setup and the pattern used to bypass common Apps Script execution limits.
Project architecture and setup
The solution is divided into two main components that make it easier to setup and process the data:
GCP Infrastructure as Code: The necessary cloud environment is defined using Terraform infrastructure as code. This makes the deployment easier by enabling required APIs like Vertex AI and the YouTube Data API. While the Terraform script attempts to set up the OAuth Consent Screen using the google_iap_brand resource, you will need to configure the OAuth Consent Screen manually within the Google Cloud Console as the official Terraform documentation notes that the underlying IAP OAuth Admin APIs were permanently shut down on March 19, 2026.
Google Apps Script: The brain of the operation lives within a Google Sheet. It calls the YouTube API to find videos, prepares and submits analysis jobs to Vertex AI batch prediction, fetches the completed results, and writes the human-readable insights back into the spreadsheet interface.
For developers setting this up, the repository includes a Quick Start template. The script automatically handles the initialisation of the spreadsheet structure when first opened, creating the necessary configuration and logging sheets in a safe, non-destructive way.
Overcoming the execution limit with Vertex AI batch prediction
As you can imagine, analysing hundreds of videos using a LLM is going to be a compute-heavy task. If you attempt to process these synchronously in a simple loop, you will quickly hit the execution limit for Google Apps Script.
To get around this, the solution uses Vertex AI batch prediction (see Batch inference with Gemini). Instead of waiting for Gemini to process each video, the script initiates an asynchronous batch job and uses a chained-trigger system to poll for completion. Once the batch job completes, the script retrieves this context, parses the JSON response from Gemini, and writes the summarised data back to the Google Sheet.
Summary
The YouTube Topic Insights solution is an excellent example of how to build complex applications using Vertex AI Batch Prediction. It provides practical solutions for managing asynchronous tasks, interacting with advanced Vertex AI features.
If you are interested in exploring the code further or setting up the tool for your own research, you can find the complete source code and deployment instructions in the YouTube Topic Insights GitHub repository.
The growing landscape of AI agent development is overloaded with acronyms: MCP, A2A, UCP, AP2, A2UI, and AG-UI, just to name a few. If you’ve ever looked at this list of protocols and felt like you were staring at a wall of competing standards, you are not alone. To help you understand their value, we are going to demonstrate what each one does to save you from writing and maintaining custom integration code for every single tool, API, and frontend component your agent touches
In Pulse we have recently featured some excellent examples of agentic integration into Google Workspace, in particular, Pierrick Voulet’s insightful posts on extending Chat apps with Universal Actions provide a great template for building intelligent assistants. For those following Pierrick on LinkedIn you’ll know these are just the tip of the iceberg.
With users increasingly expecting these intelligent assistants to communicate seamlessly across their everyday tools, knowing the right standards to connect different systems becomes a significant challenge. Fortunately, the Google Developers Blog has published a comprehensive guide to help navigate this exact problem.
In a recent post there is an overview of the growing list of acronyms associated with AI agent development. The post breaks down six main protocols:
Model Context Protocol or MCP: This standardizes connection patterns for servers. Instead of writing custom API requests for every service, your agent discovers tools automatically.
Agent2Agent Protocol or A2A: This standardizes how remote agents discover and communicate with each other using well-known URLs.
Universal Commerce Protocol or UCP: This modularizes the shopping lifecycle into strongly typed schemas that remain consistent across any underlying transport.
Agent Payments Protocol or AP2: This adds cryptographic proof of authorization to checkout flows to enforce configurable guardrails on transactions.
Agent-to-User Interface Protocol or A2UI: This lets the agent dynamically compose novel layouts from a fixed catalog of safe component primitives.
Agent-User Interaction Protocol or AG-UI: This acts as middleware that translates raw framework events into a standardized stream for the frontend.
To illustrate these concepts, the guide walks through building a multi-step supply chain agent using the Agent Development Kit. The scenario starts with a bare large language model and progressively adds protocols until the agent can check inventory, get quotes, place orders, authorize payments, and render interactive dashboards.
Adopting standard protocols is only half the equation, and how effectively you apply them shouldn’t be overlooked. As an example, Richard Seroter recently highlighted this in his analysis of agent token consumption. He discovered that simply attaching an MCP to an agent often leads to excessive planning iterations and high token costs. By pairing an MCP with a highly focused “Skill”, a structured set of instructions that guides the tool’s application, developers can drastically cut down on wasted turns. In one test, combining an MCP with a specific skill resulted in an 87% reduction in token usage compared to letting the agent figure out the tool on its own.
For Google Workspace developers building complex integrations, it’s important not to just be aware of the emerging protocols, but also the best practices for implementing them. Giving your agent a connection is a great start; teaching it the specific skill to use that connection efficiently is essential.
