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.
Have you ever used Google Workspace Studio? If so, you might have seen its “Google Drive Folder” trigger that instantly reacts to new files. It is an excellent feature for no-code automation, however, it has its limitations in what you can do in subsequent Studio steps.
If you are interested in this capability but would like to do more, I’ve just published an example repo which explores Google Drive events which is currently in the Developer Preview as part of the new Workspace Events API. With this you can subscribe to real-time changes including file uploads to specific folders, which opens opportunities for programmatically interacting with Google Drive and other services.
A Practical Application: Enterprise Data Pipelines
For me one of the most valuable applications for this capability lies within enterprise data pipelines. In many corporate environments, business users lack direct access to Google Cloud Storage buckets which are often used in data pipelines and instead they rely entirely on Google Drive for file sharing and collaboration.
By subscribing to folder events, developers can automatically trigger the movement or digestion of data the exact moment a user drops a new file into a designated Drive folder. This creates a seamless, automated bridge between user-facing storage interfaces and backend processing systems.
Architectural Highlights from the Demo
To demonstrate this I’ve published a complete proof of concept in the Google Drive to Google Sheets Notification Add-on Tutorial. This is a basic Google Workspace Add-on which lets users ‘subscribe’ to a Google Drive folder and get realtime updates to a Google Sheet. The example replicates what is possible already with Workspace Studio, but the idea is once you know how to set up a subscription you can do anything you want with that file. The example, unusually for me, has zero Apps Script meaning for chunkier data problems you can easily scale on Google infrastructure. If you look at the codebase, hopefully there are several design patterns that are useful for Workspace developers:
Infrastructure as Code (IaC): Rather than configuring the Google Cloud project services manually via the console, the repository includes Terraform configuration files to automatically provision the necessary Pub/Sub topics, service accounts, and IAM bindings required for secure message delivery. Using a ‘Infrastructure as Code’ makes it easy to ‘apply’ updates to your project.
Built-in Resilience: The Terraform configuration explicitly sets up a dead-letter topic. If your Event Processor fails to handle a file notification, the message routes to this secondary queue, ensuring no data events are lost during temporary outages or bugs.
Decoupled Execution: The example also separates user interaction from backend processing. An Add-on Handler manages user authorisation and API subscription creation meanwhile, a dedicated Node Cloud Function acts as a secure Event Processor, picking up messages asynchronously via Pub/Sub to prevent timeout issues.
The 3 Gotchas We Are Solving
The Drive API already has a watch endpoint but there three common obstacles that the new Workspace Events API gracefully solves:
The “Blind Ping”: When watching a folder with the legacy files.watch, the notification only tells you that the folder’s contents changed; it does not explicitly tell you which file was added. You are therefore forced to perform a secondary query to find the new file. The new Workspace Events API solves this by handing you the exact ID of the newly added file directly in the payload.
The Public URL Requirement: Standard webhooks require a public HTTPS URL and domain verification. By routing our events through Google Cloud Pub/Sub, this approach allows you to receive notifications privately and securely.
The Empty Payload: Google typically sends legacy notification data hidden within HTTP headers, which can be difficult to parse in certain environments, such as Apps Script. This is less of a concern in the shared example as we are using only Cloud Run Functions.
Summary
Hopefully, the demo is helpful showcasing what is possible using the Google Workspace Events API and Infrastructure as Code architectures. If there are any hints or tips I have missed, feel free to drop them in the comments below.
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.
Q1 2026 Developer Roundup: Vertex AI, Agentic Add-ons, and the Growth of Workspace Studio
The first quarter of 2026 has been a significant period for the Google Workspace ecosystem, primarily focused on providing the tools needed to scale the “agentic” workflows we saw emerging late last year. From the arrival of the Vertex AI Advanced Service in Apps Script to the full rollout of Google Workspace Studio, the platform is becoming increasingly integrated and capable of supporting sophisticated, AI-driven automations.
Apps Script: AI is Now an Advanced Service
For many Apps Script developers, the standout update this quarter is the arrival of the Vertex AI Advanced Service. Launched in January, this service allows you to call the Vertex AI API and prompt Gemini models directly within your projects, removing the previous reliance on UrlFetchApp.
While the service represents a step forward by handling authentication natively, it currently has some limitations. As noted in our January deep dive, while the connection is simplified, it lacks support for key features like Grounding with Google Search or the specialised Image Generation and Editing models available in the broader Vertex AI API. For developers requiring these advanced capabilities or alternative authentication methods, such as service accounts, the manual UrlFetchApp approach remains a necessity for now, though we hope to see these gaps closed in future iterations.
Google Workspace Studio
As of March 19, 2026, Google Workspace Studio (formerly Workspace Flows) has launched to all Rapid and Scheduled Release domains. It provides a centralised hub for creating and managing AI agents without needing extensive code.
Looking ahead, we’re expecting even more extensibility. It hopefully won’t be long until the initially announced features, including the ability for agents to call external APIs via webhooks and the integration of custom Apps Script steps, are released. These additions will allow developers to bridge the gap between low-code convenience and the complex logic required for internal proprietary tools.
Google Chat: The Add-on Evolution & Interactive Cards
We’ve seen a continued effort from Google to unify the developer experience in Google Chat. A major milestone is the ability to convert interactive Chat apps into Google Workspace Add-ons. This allows for a single distribution through the Marketplace that can extend Chat alongside Gmail, Calendar, and Docs.
This shift is supported by the general availability of the AddOnsResponseService, along with Cloud Pub/Sub and Dialogflow integrations for Chat-based add-ons. Additionally, a new Developer Preview launched in March allows Chat apps to create and asynchronously update card-based messages on behalf of users.
Gmail & Postmaster Tools v2
For those managing high-volume email workflows, the Gmail Postmaster Tools API v2 reached general availability in February. This version provides deeper access to the full Postmaster Tools dataset, including compliance status and the queryDomainStats method for more flexible reporting on sender reputation.
Security, Permissions, and API Graduations
Governance and security remain a priority, with several key updates affecting how we manage data and access:
Drive API Access: The enforceExpansiveAccess parameter is now deprecated. To restrict access, developers are encouraged to use the “folders with limited access” configuration.
Secondary Calendar Management: Following community feedback, Google has postponed the deletion of orphan secondary calendars for paid accounts until October 5, 2026. To assist with this transition, a new Calendar API endpoint will launch by June 2026, allowing administrators to programmatically transfer ownership of individual secondary calendars.
Google Meet Security:Updated guidance advises against reusing Meet codes across different Calendar events to prevent unintended access. Developers should generate a unique conference using the createRequest field for every new event.
Granular OAuth: A gradual rollout of the granular OAuth consent screen has begun for Chat apps built with Apps Script, offering users more control over specific scope grants.
Classroom API:Student Groups endpoints have graduated to General Availability, enabling programmatic management of group memberships.
Marketplace API Deprecation: The licenseNotification resource has been deprecated. While there is no direct replacement, developers can monitor install events via Google Analytics.
Relational Power: JDBC Supports PostgreSQL
While not in the official release notes, a significant update for the community is the addition of PostgreSQL support to the Apps Script JDBC service. By supporting the jdbc:postgresql:// protocol, developers can now connect their automations directly to relational databases, moving beyond the traditional limits of Google Sheets for data storage.
The Road Ahead
The pace at which features are moving from Developer Preview to General Availability indicates a platform that is maturing rapidly. The roadmap for Google Workspace Studio also hints at extensibility including the anticipated release of custom triggers and actions built with Apps Script, a dedicated connectors platform for third-party tools like Jira and Salesforce, and the ability to integrate custom Vertex AI models directly into workflows will represent a fundamental change in how we handle complex data processing within Workspace automations.
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.
How to pass Google’s OAuth verification process for your Workspace add-on—branding requirements, privacy policy, terms of service, scopes justification, and the demo video.
Over the years on Pulse, we have featured a number of guides and resources aimed at helping developers navigate the complexities of Google’s authorisation requirements. However, given it has been a while since we last touched on this topic, and considering how frequently the process can be a stumbling block for the community, I thought it was a subject worth revisiting.
If you have ever attempted to publish a Google Workspace add-on, you likely know the specific mix of excitement and trepidation that comes with the submission process. While building the functionality is one hurdle, ensuring your application meets Google’s rigorous security and branding standards is quite another. One area that frequently trips up even seasoned developers is OAuth verification.
In a recent post on the ShipAddons blog, Manuel Napoli shares a step-by-step guide to getting through Google’s OAuth verification. Having navigated this process multiple times to launch his own tools, Manuel provides a comprehensive look at what Google reviewers actually expect, offering a practical checklist to help you get verified on your first attempt.
The guide breaks down the requirements into four primary areas: branding, privacy policy, terms of service, and scope justification. Rather than rehashing the technical minutiae here, Manuel’s post serves as a comprehensive “pre-flight” checklist for anyone ready to hit the submit button.
It is also interesting to see this content coming from ShipAddons. For those unfamiliar, ShipAddons is a production-ready service designed for building premium Google Workspace add-ons with React and Supabase user management integrations. It aims to solve many of the recurring “pain points” we often discuss in the community, specifically handling the “plumbing” of a commercial application.
For developers looking to transition from a single-purpose script to a monetised solution, having these systems pre-configured can significantly reduce the time spent on infrastructure.
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.
