I/O 2026 dropped 100 announcements, but I'm still hardcoding WorkBuddy templates

After going through all hundred announcements from Google I/O 2026, my hands are itching a bit. Gemini 3.5, Antigravity 2.0, Chrome DevTools for agents — they all point in the same direction: let the agent see for itself, debug for itself, plan for itself. Sounds pretty fierce.

There's something at I/O called Modern Web Guidance, officially described as expert-vetted skills. In plain terms: don't let the model improvise on the spot.

I've used WorkBuddy for about a month, and the more I use it, the more certain I am that in office scenarios, autonomous planning by the agent isn't step one — the material intake is. If the input isn't cleaned up, the stronger the model, the more it'll confidently read the wrong files.

Let me start with the problem. We're backend, and requirement changes are scattered across comments in Feishu docs, emails, and screenshots in group chats. Previously, manually compiling a change log took about forty minutes each time, and it was easy to miss things.

I tried letting WorkBuddy figure it out on its own — threw the entire project directory in and just wrote "compile this week's requirement changes." It went around and ended up reading clauses from client contracts too, mixing a few rows into the output table that shouldn't have been there. The problem was I didn't set boundaries.

Later I changed the order: collect materials first, then run the task.

First, create a dedicated directory locally, like D:wb-inboxchangelog, and only put files you allow it to see in there — nothing else. This directory is a material pool. Open WorkBuddy, create a new task, and select Craft mode. Let me explain: Craft is its execution mode, which actually reads and writes files; there's also Ask mode that only answers without touching files, and Plan that only outputs steps without writing to disk. Beginners most easily mix these up — I stepped in it my first week: selected Plan, wrote the description, waited forever, and only got a step list with no files touched.

I write the task description as a fixed paragraph, without any adjectives. Read all files under D:wb-inboxchangelog, extract requirement ID, requester, change content, affected module, and date proposed, output xlsx to D:wb-out, with headers fixed to these five columns, leave missing fields blank, do not infer.

The key is those last four words. If you don't write them, it'll fill in on its own, and what it fills in looks reasonable but is all hallucination. That sentence came from one off-track run. But it only guarantees stable output format and that the log can be compared — what makes that work is the clean-files-only directory from before.

The output xlsx goes in a fixed directory on the shared drive. For permissions, I only opened two writable: me and the interface person on the testing side; everyone else is read-only. The template file is stored separately, and only I can modify it. This division is important — once the template has been touched by a second person, the headers from the next run won't be consistent, and historical data can't be compared. I used to think this set of restrictions was a bit excessive, but now I've changed my mind: the tighter the permissions, the less hassle.

For operations, I run it once every Friday afternoon. Before running, clear the inbox; after running, rename the output file to something like changelog-20260919.xlsx with the date, and put the template version number at the end of the filename. If the template needs changing, create a new version instead of overwriting directly — first run it against historical data for comparison, and only switch once it matches.

Another pitfall. WorkBuddy isn't very friendly with merged cells when processing xlsx. My initial output template had merged headers, and reading it back gave all empty values. Later I changed it to a single row of pure headers, and the problem disappeared. This is an old xlsx issue, not much to do with the tool itself, but the first time you hit it you'll be very confused.

My environment is Windows local files plus a shared drive, and Feishu is just a material source — it may not apply to everyone. If you have a fully cloud-based collaboration workflow, the permissions setup needs to be redesigned.

The trend I see is simple: among those hundred items at I/O, very few can actually land in daily office work, but agents will only become more numerous, they'll get better at planning, and they'll get bolder at guessing. Rather than chasing every announcement, it's better to first narrow the material intake into a small set of enumerable, reproducible files. Models will change; directories won't.