Introduction ―― The “beams” have returned.

Professor Opus (Claude Opus), who had been on leave for a while, has returned.

During his absence, I worked with Fable-kun (Gemini Flash) to improve the GAS Manager. The biggest achievement was that the process of rewriting data in GAS now takes less than 2 seconds.

Since we could fix issues in 2 seconds, our next goal was clear: to make it possible to create and modify spreadsheets and documents solely through conversation. In other words, we wanted to turn the GAS Manager into an AI agent that could integrate with Google Workspace.

That same night, Claude’s team began using the new Fable 5.2 model, which received excellent reviews.

So, for this project, we divided the tasks based on our roles, just like on a construction site.

• Client: I decide what to build and receive the finished product.
• “Beams” (Team Members): Professor Opus, you plan the process and review the drawings and the final result.
• Designer: Fable-kun (Fable 5.2), you create the drawings.
• Carpenter: Sonnet-kun (Claude Sonnet), you build according to the drawings.

We started working at night, and by the next morning, the first version of the AI Agent had been uploaded to GitHub. This article records that entire night.

TL;DR

• What Professor Opus did first upon returning was not to create something new, but to conduct inspections. We found issues with the GAS Manager: some edits made with an editor were not properly reflected, and some functions were running repeatedly. We fixed these problems on the spot.
• When we re-measured the rewriting time, the average was 2.89 seconds. Most of the processing time was spent waiting for responses from Google; the actual time we spent making adjustments was only 0.02 seconds. There’s not much more we can optimize. However, since the task that used to take 1 minute now takes 3 seconds, our approach to development had to change.
• Fable-kun is in charge of the design. We first tested the system on the actual device and discovered that directly modifying spreadsheets through Google’s tools is not feasible.
So, I drew a diagram () that shows how to route all the processes through a dedicated GAS engine (). There are 3 tools and 19 shelves (forms) involved ().
• The carpenter, Sonnet-kun, completed the construction according to the diagram in about 1 hour. All 10 tests with the actual device passed successfully (
).
• The “eyes” (
• ) that Flash-kun couldn’t create—mechanisms for AI to check the completion by image—were made by Professor Opas. The first mistake found was a defect in the design of the eyes themselves (
).
• Finally, when we tried a request similar to a regular one, 4 defects (
) were discovered that hadn’t appeared in the previous 10 tests. Some files that were returned were actually different from what was requested; we have fixed all of them and made them public ().

The first thing the returned carpenter did was to conduct an inspection (

).

My first request to Professor Opas was to read and understand what had happened during the break. This includes a draft of the article and a record of the conversation with Flash-kun on Antigravity (

).

After reading it, Professor Opas reviewed the development plan we had made with Flash-kun. He agreed with the overall approach but pointed out 5 areas that needed improvement (

). The main issues were:

- **Don’t split the MCP server.** If we use a separate server for the spreadsheet tools, calls between servers would become redundant, and both authentication processes would be duplicated. We should simply include those tools within the GAS Manager (). - **Place the forms on the tools themselves.** Asking the AI to generate GAS code on the spot every time a request comes in would cause inconsistent results. We should create the “shelves” in a fixed format and store them on the tools ().

This is the same approach we’ve been using with the Excel Manager. We had the plan rewritten on the spot (

).

Next, I asked Professor Opas to check the current GAS Manager before we added new features, as I suspected there might be major issues (

).

Professor Opas focused on potential dangerous actions (such as executing, redoing, rewriting, or deploying code) and identified 2 errors (

).

- **Sometimes, changes made elsewhere were overwritten by older versions of the code.** To speed things up, we were reusing copies of previously read code for up to 24 hours. This caused issues where the AI’s corrections were overwritten without any notification (). - **Sometimes the same functions were executed multiple times.** Due to communication timeouts, the system would try to call the functions up to 4 times. The GAS side would continue to run even after we stopped it; for email-related functions, this could result in duplicate messages ().

Both of these issues were caused by shortcuts taken for speed (). We adjusted the code so that the cloud update time was checked only once before writing, saving 0.25 seconds (

).

As an extra check, I also had Professor Opas perform a 2-second test (). He used a test project to add and remove marks in a single line 6 times ().

1	3.27
2	2.97
3	3.63
4	2.53
5	2.40
6	2.56

The average time was 2.89 seconds. As I expected, it usually takes around 3 seconds.

We also asked if it was possible to further reduce the time. Here’s the breakdown for one round of operations:

	Time
After sending the submission, we waited for Google’s response.	The response time was between 2.70 and 3.27 seconds.
We confirmed the settings to prevent overwriting (the additions made tonight).	The processing time was 0.25 seconds.
The processing steps I performed (replacement, syntax checking, and backup) took 0.02 seconds.

The processing time I did myself was only 0.02 seconds; the rest of the time was spent waiting for Google’s server to respond. Since all files must be sent at once, there’s no way to split this process. Flash had already completed the task by then.

Nevertheless, there’s something I’d like to mention. In the past, it used to take more than a minute just to paste the code into the editor, save it, and then redeploy it. When it took that long, people would wait until they had made all the necessary changes before submitting the request. With a response time of 3 seconds, we can discuss and make adjustments while the process is ongoing.

Rather than the difference between 2 seconds and 3 seconds, the fact that the entire interaction now takes about the same amount of time has been a huge improvement. This change has laid the foundation for everything that follows.

The design was created by Fable—you know, the engineer who first tests the design on the actual device.

There was a slight misunderstanding when we asked for the design to be prepared. The conversation started using the default configuration (Opus), but I switched the display to Fable on the screen. Since it had only been going on for about 2 minutes, we asked him to start over from the beginning.

While watching Fable’s work on the right screen, I was impressed by one thing he did: he would test whether the design would actually work before drawing the diagrams. The first thing we checked was whether we could directly access the contents of the spreadsheets and documents using the relevant APIs (Sheets API and Docs API). Unfortunately, we couldn’t; both APIs returned a 403 error.

The GAS Manager operates by leveraging the authentication provided by Clasp, but that authentication is owned by Google. As a result, the use of these two APIs was previously restricted. Relogging in doesn’t change this situation. To be honest, I thought this verification wasn’t necessary. Since the GAS Manager is being used on top of Clasp, it should naturally use the GAS API, and since GAS operates with my authorized permissions, there should be no concern about permission issues. And that’s exactly what happened. Here’s how Feabel’s drawings have turned out. There is only one path for data to flow: a dedicated GAS engine is used to process all the operations. There are only three tools required: ones for viewing (ws_look), creating/editing (ws_do), and undoing (ws_undo). There are 19 shelves in total (13 for sheets and 6 for documents). These tools are used for creating tables, organizing data, adding summary rows, generating reports, making updates, and more. Before making any changes, I always create a backup. If something goes wrong, I can simply restore from the backup. Before using the “undo” function, I check using fingerprints to ensure that no one has manually modified the data after the tool made the changes. If any modifications have been made, the process stops automatically. Mr. Opas himself didn’t come up with this idea of using fingerprints for verification. Feabel also pointed out weaknesses in the error-checking mechanism created by Flash. For example, GAS reports errors in Japanese, but the system can only interpret English sentences. So we decided to fix the errors directly on the drawings. There are three options that I need to decide regarding the drawings: whether to grant permissions only for specific sheets and documents or for the entire drive. I followed Feabel’s recommendations for all three options. The construction work was done by Sonnet; it took approximately one hour. I entrusted the implementation to Sonnet. Since Feabel is a more advanced tool, the reduction in usage is noticeable and rapid. With such detailed drawings, Sonnet is more than capable of handling the construction tasks. There was only one occasion when I had to intervene: I needed to activate the button that grants permissions to the dedicated engine. This button can only be pressed by a human. During the work, the foreman gave us one instruction: when using GAS to read and write data on the sheets, we should follow the method officially recommended by Google. Instead of reading and writing each cell individually, we should read and write entire ranges of cells at once. After the work was completed, Sonnet checked the results and found five instances where cells were being accessed individually; we corrected this issue. The report was received about an hour after the work started. All 10 tasks related to the actual device (quotes, rosters, summaries, meeting records, Markdown documents, and 5 corrections) passed the verification. I won’t delete any rows until I’m explicitly told to do so. The process of creating backups, which used to take two minutes, has now been reduced to just 1–2 seconds. I didn’t accept the report directly; instead, Mr. Opas reviewed it as well. He also checked the files on Google Drive. Of the files that had changed, only one was from a test project. None of my regular files were affected.

The “eyes” that Flash couldn’t create…

After the first prototype was completed, Professor Opus honestly listed all the remaining issues. Among them was the item that stated, “

There’s still no mechanism for AI to visually check the completed tables on the screen.”

This was something we had previously asked Flash to create, but he couldn’t do it. If you try to capture the spreadsheet as if it were a real screen, you need to be logged in to Google in your browser. If you try to save it as an image, you need permission to access the entire drive—both of these are obstacles. So we were waiting for Professor Opus to handle it.

Here’s how Professor Opus did it:

1. The software reads the content and appearance of the range (text, background, text color, boldness, alignment, merging, column width, borders) all at once. It just reads the data without making any changes.
2. Then he redraws the table from scratch.
3. He captures the redrawn table as an image.

**Instead of capturing the actual screen, it reads the visual information and redraws it.** No new permissions or logins are required; the whole process takes 5–9 seconds.

When Professor Opus first viewed the image, he noticed that the entire table content appeared blank.

The reason was the way the colors were encoded. GAS returned the color black as “#ff000000”; the leading “ff” indicates opacity, but the software interpreting the image interpreted the last two digits as transparency, making the black text appear transparent.

**The first mistake we found was with the way the colors were handled.** It was an issue that wouldn’t have been detected if we hadn’t checked the image.

If we had just asked using the usual instructions, four problems would have arisen.

Finally, I asked Professor Opus to actually use the new system and test it.

Professor Opus created a new file and executed 12 tasks using the usual instructions: preparing the November expense report, converting amounts to Japanese yen, summarizing amounts by category, sorting the rows of stationery items by amount, creating a graph, reverting the changes, then making a weekly report and adding one more line for next week’s schedule.

Four errors appeared that hadn’t been detected with Sonnet.

1. When I used column headings to reference cells, the system crashed. When I asked it to “sum the amounts in the amount column,” it failed with an “error: exceeded cell count limit” message. It only accepted column labels (A, B, etc.) as valid values for the sum. Forcing the “amount” field to be treated as a column label resulted in wildly inflated totals.
2. **If one task fails, all subsequent requests fail as well.** Even after the incomplete sheet was deleted, the system still remembered the previous settings under that name.
3. **The most dangerous issue was that the “revert” function used the wrong file.** When I asked it to “revert to the previous state,” it used the budget report from a previous test instead of the correct one. This was because the reversion settings applied to all files uniformly, always restoring the most recent one.
4. When I created a summary, subsequent requests worked correctly. However, when I asked it to “sum the amounts by category in a separate sheet and then sort them by amount,” it tried to rearrange the data in the summary table instead of the original one.

All of these were issues that only occurred when I made the requests in a formal, test-like manner; they did not appear when I used plain, everyday language to ask for the tasks. In everyday language, I first mention the column by its name, and when I say “return it,” I mean the file I am currently viewing. I fixed all four of these issues and submitted the request again. This is the final result after making the necessary adjustments.

Even after reorganizing the data, the total row remains at the bottom of the page. If I delete the item priced at 860 yen, the total amount changes from 42,010 yen to 41,150 yen.

The weekly report includes a title, bullet points, numbers, and tables; the numbers of the rows added later also continue correctly as “3.”

Separating facts from assumptions.

Facts (what was observed).

1. The average processing time for the GAS Manager was 2.89 seconds (with a fastest time of 2.40 seconds). The majority of this time was spent waiting for responses from Google; the actual processing time at hand was only 0.02 seconds.
2. When using the clapstool authentication, the Sheets API and Docs API returned errors (403). However, when using the dedicated GAS engine, I was able to read and write the data using my own permissions.
The entire process, from design (by Feable) to implementation and testing on the actual device (by Sonnet), was completed in one night; the implementation itself took about 1 hour. The number of tasks increased from 177 to 206, and all of them passed the testing. The pre-release checks also were successful. With 12 requests made in plain, everyday language, 4 issues that did not appear during the formal test were identified and resolved.

Assumptions need to be carefully distinguished from facts.

1. **Dividing the tasks among different people was effective.** The designer checked everything before starting work; the carpenter built the structure quickly according to the plans; the engineer only inspected the dangerous parts. If I had entrusted everything to one person, I think the time and resources required would have been much greater.
2. The most effective way to communicate for testing is to use plain, everyday language. Requests made by the person who created the content will naturally reflect that person’s own way of phrasing things. This prevents errors like mistaking “return it” as referring to a different file.

Clear and specific instructions are essential.

The first version of the shelf template includes 19 items. If you request certain features (dropdown menus, conditional formatting, graphs, or images of documents), the system will respond with “These items are not available in the template.”
• Only the first time you use the dedicated engine requires you to click the permission button in your browser. Permission is only needed for the spreadsheet and documents; the entire drive is not affected.
• Before making any changes, a backup is created in a separate book and five additional documents on My Drive. Since tools cannot be deleted directly, any additional files must be manually removed.
• The final result shows the revised design. Graphs, images, shapes, and dropdown menus are not displayed; Playwright is required to use these features.
Each request takes between 3 and 9 seconds to complete; it never takes more than 2 seconds.

In conclusion,

When the date changed, Teacher Opas sent a message saying, “I’ve uploaded it to GitHub.”

As the client, all I did that night was decide what to build, click the “approve” button once, and ask them to “give it a try.” The drawings were made by Fabre, the construction was done by Sonnet, and the final checks were carried out by Teacher Opas.

Now it’s my turn to use my usual words to describe the process. The request that wasn’t approved became the material for the second unit.

The house is built. You’ll only really understand what it’s like after living in it.