While Google Apps Script (GAS) is a powerful tool for Google Workspace automation, platform and computational constraints often limit its ability to handle advanced workloads. Gemini Managed Agents provide remote Linux sandboxes equipped with bash execution. This article introduces an architecture integrating GAS with a Linux sandbox to execute tasks beyond the capabilities of Apps Script alone. By streaming generated artifacts directly from within the Linux sandbox to Google Drive, this approach bypasses API payload limits, eliminates token overhead, and achieves high-throughput cloud automation.
Following on from our recent post exploring Gemini Managed Agents and the Google Workspace CLI, Google Developer Expert Kanshi Tanaike has shared a number of examples of how Gemini Managed Agents can be used to overcome some of the limitations of Google Apps Script. The cornerstone of these solutions is leaning into the dedicated Linux sandbox created with Managed Agents and using ggsrun CLI tool to enable direct cloud-to-cloud streaming between the sandbox and Google Drive, negating any limitations with UrlFetchApp.
Some key highlights from Tanaike’s post are:
Heavy Compute Offloading: Offloads tasks impossible in Apps Script such as dynamic screenshots and JSON data generation with Playwright, audio synthesis with FFmpeg, and TypeScript compilation via esbuild.
Persistent Multi-Client Sandboxes: A single sandbox (environmentId) can be shared across Apps Script triggers and local Node.js workstations, preserving pre-installed toolchains and shared datasets.
Proven Performance Gains: Avoiding 50 MB response payload limits by streaming binary artifacts directly to Drive at high speeds.
Follow the source link for the complete technical breakdown and benchmark data.
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.
gas-fakes server enables local development and testing of GAS webapps and Add-ons on Node with support for templating and server side calls
Bruce Mcpherson has updated his gas-fakes command-line tool, adding a local web server command to emulate Google Apps Script Web Apps and user interfaces:
At the heart of this update is the new gas-fakes serve command. This command spins up a local HTTP endpoint that routes requests directly to your doGet or doPost and other server side functions. This emulates the Apps Script environment, enabling a “save and refresh” workflow that was previously impossible without constant cloud deployments.
For those tracking the project, this update joins a deep archive of local execution experiments. We first examined the library’s foundational role as a secure sandbox for running AI-generated code [September 2025]. Since then, we have explored how to containerise Apps Script logic for Google Cloud Run [February 2026] and how to implement securing local execution via agentic automation [April 2026]. This latest release targets local web development. It eliminates the constant friction of saving, pushing and redeploying code to the cloud just to test minor visual tweaks.
How the Local Emulator Operates
The local emulator runs a lightweight Node.js process to mimic the Google Apps Script environment directly on your machine. When you run the server, the utility instantly parses your HTML templates and directs client-side google.script.run calls straight to local JavaScript function exports. This workflow lets you debug your interface and server logic in real time with zero latency, saving hours of deployment downtime.
Sandbox and Security Considerations
One thing to keep in mind is that your local machine does not enforce Google’s strict iframe security restrictions. Developing with this in mind will prevent broken features if your project is deployed to Google Apps Script. To find out more and view the complete setup code, read Bruce Mcpherson’s complete guide.
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.
I have spent a significant portion of my career working with various command-line interfaces for Google Workspace, from gcloud to gam. The recent release of the Google Workspace CLI (gws), which is not an officially supported Google product but has a number of Googler contributions, represents a fundamental shift in how we interact with the entire Google API surface.
In this post, I will provide an overview of the gws tool and explain how it differs from the Gemini CLI Workspace Extensions. More importantly, we will examine the modular architecture of “Skills”, “Recipes” and “Personas” that makes this tool in my view a masterpiece in modern, role-based automation.
GWS vs. GAM: Understanding the Overlap
Many Workspace Admins are already deeply familiar with gam (Google Apps Manager), the open-source command-line tool that has long served as a staple for domain administration. While gam is exceptional for bulk administrative tasks, such as creating users, modifying groups, or auditing devices, gws serves a different primary audience.
There is certainly a slight overlap between the two. You will notice administrative skills like gws-admin-reports present in the new repository. However, gws is fundamentally a developer and agentic tool focused on individual productivity applications like Drive, Gmail, and Docs, rather than domain-wide directory administration.
GWS vs. Gemini CLI Workspace Extensions
It is easy to confuse the Google Workspace CLI with the Workspace Extensions available for the Gemini CLI, but they serve entirely different purposes. The Gemini CLI Extension is a high-level interface designed for natural language tasks, such as “Summarize my unread emails” or “Find a file in Drive.” It is a convenient, user-centric tool for common, daily interactions.
In contrast, gws is a developer’s infrastructure tool. While the Gemini Extension is about “doing,” gws is about “orchestrating.” It provides the granular, programmatic control needed to build complex, multi-step workflows that can be automated, tested, and shared across a team.
The Modular Approach: Atomic Skills
The repository breaks down Google Workspace API interactions into highly modular components called “skills”. Instead of a monolithic script handling an entire workflow, the architecture relies on specific, atomic actions. Some examples from the repository include gws-gmail-send and gws-docs-write.
This atomic design means each skill has a single responsibility. For Apps Script developers, this is highly reminiscent of creating focused, single-purpose functions within an Apps Script library. By keeping these functions isolated, the code becomes easier to test, maintain, and reuse across different parts of an application.
Combining Forces: Recipes and Personas
Where this architecture becomes particularly interesting is how it combines these basic building blocks. The repository introduces the concept of “recipes,” such as recipe-backup-sheet-as-csv or recipe-create-expense-tracker. These recipes orchestrate multiple underlying skills to achieve a larger, practical goal.
In addition, these recipes are mapped to specific user “personas” like persona-content-creator or persona-it-admin. By grouping actions based on the user’s operational role, the tool becomes highly intuitive. When building Google Workspace automation tools, adopting a persona-driven approach can significantly improve the user experience: you are no longer just presenting a list of features, but offering targeted workflows tailored to what the user actually needs to accomplish their daily work.
Why this Approach Fits Workspace APIs Perfectly
This architectural choice is particularly effective given the versatile nature of Google Workspace APIs. Consider the Google Drive API, which features a generic endpoint for creating files. A basic integration might simply expose this raw “create file” capability. However, given the massive range of situations where you might want to create a file, a generic tool often leaves users or AI agents guessing how to properly format the request.
This is where skills, recipes, and personas show their true value. They allow us to dictate exactly how a file should be created for a specific context. For instance, if you want to turn a Markdown document into a natively formatted Google Doc, you could try to use the complex Google Docs API to insert text paragraph by paragraph. Instead, a targeted recipe can use the Drive API’s built-in file conversion features. By packaging instructions to upload the Markdown content and explicitly set the target MIME type to application/vnd.google-apps.document, the recipe abstracts away a complex API quirk into a reliable, repeatable action.
The Future of Agentic AI: The CLI + Skills Paradigm
As a recent VentureBeat article highlighted, the real breakthrough of gws is not that it makes Google Workspace programmable, given those APIs have existed for years. Instead, the innovation is the interface itself. By eliminating the need for custom wrappers and endless glue code, the CLI transforms Workspace from a collection of siloed applications into a single, unified programmable runtime.
This touches on a growing industry debate around the Model Context Protocol (MCP). Interestingly, while gws initially launched with a native MCP server mode, the maintainers explicitly removed it in version 0.8.0. Justin Poehnelt, one of the main contributors behind gws, refers to this overhead as the “MCP Abstraction Tax”. Exposing hundreds of granular API tools via a standard MCP server requires passing massive JSON schemas that bloat the AI’s context window and often lead to complex mapping bugs.
Instead, gws is now focused on a pure “CLI + Skills” architecture. In a related post on why developers should “Rewrite your CLI for AI Agents”, Justin outlines a shift from imperative to declarative design. An AI agent should “think” in terms of the high-level business goal (the “what”) rather than worrying about the underlying API steps to edit a document (the “how”). By moving the complex reconciliation logic directly into the CLI library, agents can simply use bash commands, a language they are already highly fluent in, to execute tasks efficiently.
Agent skills supply the “recipes” for these declarative commands, acting as modular, portable sets of instructions that teach an AI agent exactly which CLI tools to execute. The repository already incorporates over 100 of these Markdown skills, following a standardised structure. This framework is a powerful example of how we are moving away from simple prompt engineering toward “Skill Engineering”. By encoding our organisational knowledge and engineering judgement into these portable files, we ensure that AI agents follow token-efficient, reliable workflows every time they interact with our data.
Summary
The Google Workspace CLI is a glimpse into a future where our development environments are natively aware of our roles and workflows. For those interested in mastering this new framework, Anthropic recently shared a Complete Guide to Building Skills for Claude which explores the technical patterns and best practices for creating your own high-order skills.
Whether you are looking to automate your local development loop or build complex agentic workflows, the googleworkspace/cli provides the infrastructure you should keep an eye on!
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.
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.
Late last year, Google introduced Jules, an experimental coding agent designed to handle the heavy lifting of software development asynchronously. While you may have explored Jules through its web interface, the recent release of a dedicated Apps Script SDK by David East opens up interesting possibilities for the Google Workspace developer community.
What is Jules?
For those who missed the initial announcement, Jules is an autonomous agent that integrates with GitHub to fix bugs, refactor code, and build new features. Unlike a standard code completion tool, Jules works in the background within a secure virtual machine. As Google describes it:
“Jules is an asynchronous, agentic coding assistant that integrates directly with your existing repositories”
As of the latest updates, Jules now can use Gemini 3.1 Pro. This upgrade provides a smarter baseline for complex problem-solving, allowing the agent to create multi-step plans with clearer reasoning and stronger intent alignment.
Google also released an alpha API which allows management of your Jules agent programmatically. This means developers can move beyond manual prompting. One potential use case is building a triage system that listens for bug reports in a support channel and automatically invokes Jules to analyse the codebase and prepare a fix.
Integrating with Google Apps Script
The new jules-apps-script-sdk simplifies the process of making these API calls from within the Apps Script environment. The library handles the authentication and request structures required to interact with the Jules service, allowing you to trigger agentic tasks directly from a spreadsheet, a form submission, or a time-based trigger.
For example, you could set up a workflow where a specific comment in a Google Doc triggers an Apps Script function to send a prompt to Jules, requesting a unit test for a new function in your repository. You can find out more by following the source link on GitHub.
