A shorter list as I jet back home after a short trip to the mothership. While a good day of work, this date always hits different for me. Probably always will.
[site] Cyber Model Arena. Fight! How do various agents and harnesses stack up on cybersecurity tasks? The results may (or may not) surprise you.
[article] Is Your Strategic Plan Too Ambitious? Or Not Ambitious Enough? Some very useful advice here. Have you defined the problem before setting the target? Are you getting the necessary investment? Reflecting the right time horizon? We need to answer those questions before setting a plan.
[blog] What comes after git. This company is keeping the git protocol (to make it less disruptive to switch) but evolving the storage engine.
[blog] What 1,000 small business owners taught us about AI. Anthropic shares what they’ve been learning. Now’s the time to be out there listening to a new set of users, as well as existing users facing new work styles.
[article] The five important tools for controlling AI costs. Seems fair to me. I wonder if models are now training on data like this, and if the recommendations will be different by the time a model actually reaches the market.
[article] AI accelerates output, not innovation. Makes sense. I can do more, which may (MAY) translate into faster learning. But AI also doesn’t replace the human brain’s ability to do recombination and identify real innovation.
[article] Suddenly I’m a Go developer. It’s weird that any of us can be any type of developer. Even if temporarily, and with virtually no depth. I think it’s a good thing overall, and maybe encourages professional developers to expand their horizons.
[blog] Debugging Serverless Apache Spark using Gemini with MCP. Yes, you can just paste errors into an AI chat tool and hope for the best. But context matters, and we should give your tools access to the information that encourages more than guessing.
It was a good day, and tomorrow I’m jetting up to Sunnyvale for some fun meetings at Cloud HQ. It’s easy to get caught up in everything changing all around us, but I remind myself to enjoy the present moment, learn new things, and not worry about tomorrow.
[blog] .gitignore everything by default. I think I love this. I’m always scrambling to remove unnecessary files from my git commits. What if you start by denying everything and only selectively allowing what you want?
I’m back after the holiday weekend and some shenanigans at the San Diego Padres baseball game yesterday. Today, in between real work and building a Chrome plugin to test out an idea, I also read a number of fascinating items.
[article] Inside a Software Factory. I’m not sure if the whole “software factory” as currently described will survive. We’ll see. This post does a fine job outlining where humans play a role in these factories, along with design considerations.
[blog] What happens when AI burns down the backlog? Will the backlog run out? That was a silly question to ask even 6 months ago. But now? Are you identifying useful things to work on at a fast enough rate? Maybe not.
[article] The quality paradox of AI-generated code. Why are code maintainability and change confidence moving in opposite directions all of a sudden? Interesting analysis here.
[blog] How to write a definition of done for an AI feature. Good point that we shouldn’t mistake evals for a requirements spec. PMs need to keep understanding user need AND definition of what “done” looks like.
That’s a wrap on this week. I’m ready for a long weekend here in the States, and will be back with a reading list next Tuesday.
[blog] The Incumbents Are Coming. I’m probably in the minority, but I like when staggering leaders roar back into a primary position against the feisty challenger.
[blog] Your Agent Doesn’t Know How to Wait. Huh. I don’t think I’ve come across this idea before. If your agent needs to wait for an operation to finish, make sure you design it correctly. Otherwise, your costs can quickly balloon.
[blog] How to Handle Errors in Go. Whether you’re writing it yourself or asking an AI agent to do it, make sure your code has robust error handling.
[blog] How to Think About Open Weight Models. Excellent analysis from Steve here. If you’ve only kept a casual eye on the open model space, or even if you’ve paid close attention, you can learn something here.
[blog] Software Is Fast Fashion. Too cynical? Maybe not. There’s a lot more that we should be treating as disposable versus durable.
[blog] Defying Gravity: The System of Record in the Age of AI. People don’t swap big systems of records (CRMs, ERP, etc) often, so the TAM looks small. But with AI, people are revisiting their systems of record. It’s a new ballgame.
[blog] Goroutine Leak Profiles. This is for a very specific audience—Go devs who build concurrent systems—but I like the technical detail and explanation.
[article] Middle Managers Will Make or Break AI Adoption. Is your AI transformation work focused on the wrong internal population? Possibly. Either get your middle managers to champion your new way of working, or watch your dreams go up in smoke.
Want to get this update sent to you every day? Subscribe to my RSS feed or subscribe via email below:
What a week (already) for new LLMs. Claude Fable 5.1, Meta’s Muse Spark 1.3, and Gemini 3.8 Flash. And it’s only Wednesday.
[blog] Introducing Gemini 3.8 Flash and 3.8 Flash Cyber. Can’t stop, won’t stop. This is the third new Flash model in six weeks, and it’s another leap forward. Not only is it up there with frontier models on coding and agentic tasks, it’s a fraction of the price. And on most every Google surface, like Antigravity.
[blog] From trajectories to lineage: building better agent telemetry. One session log is interesting, but fades in usefulness if you’ve got multi-agent systems or teams of people working towards a goal with AI. Now you need agent linage to figure out how you arrived at a destination.
[blog] Audit your Agent files. Your configurations rot over time. Skills endlessly compound in your AI coding tool. Addy encourages us to audit regularly and test what happens when we prune.
[blog] A2A Is the Task. This is one of the better deep-dives I’ve seen into A2A use cases. And how it compares to MCP for those use cases.
[blog] Agent memory as a file format. Are we over-processing agent memory? This writer proposes agent memory as portable data consisting of Markdown files and optional SQLite vector index.
I learned a lot today. How about you? My education usually comes from a mix of reading, talking to people, and trying things myself. It’s a good day when all three of those happen.
[article] The Job Doesn’t Change. The Agent Does. Consumers still want the right product at the right price with the least friction. Who is the consumer? That’s changing.
[blog] Teamwork: When AI Becomes a Research Partner. If you have a problem worthy of the token spend, the “teamwork” feature is worth it. Check out what real problems it solved.
[blog] Agency and Agents. Instead of dark factories where operate on their own (see /teamwork above), do we need “twilight factories” where humans are brought in at the right moments?
[article] Your agent context needs a development lifecycle. We need to see more exploration in areas like this. What about short term context (skills or rules)? Is there different rigor for shared versus local context? Is it the same cycle for all types of context?
It’s unusually hot and humid in San Diego, but that didn’t deter us from being outside this weekend. But, during some air-conditioned indoor time, I wrote up a blog post. You can count on it being outdated in like three weeks as the next new thing comes along.
[blog] Beyond Vibe-Coding. Your prototype might actually turn into something. Here are some lessons from one such case.
[blog] Top AI Trends Every Developer Should Know in 2026. None of these are earth-shattering (if you’ve been paying close attention to the industry), but I liked this roundup and it’s a good look at what matters right now.
[blog] Understanding the Linux Kernel: Network Subsystem. I joke in customer meetings that this is exactly the sort of knowledge I’m now happy to forget. Higher abstractions have let me ignore it. But, it’s pretty cool to dip back down again and re-engage with it.
[blog] You have to beat the models at something. Right now, you’re better at LLMs in your familiarity of the tech details in the system in which you work, and at clear communication regarding that system.
I’m not proud of it, but I’ve been drunk on agent skills. It’s time to reset. It’s easy to fall into skills bloat as you accrue different ones for every possible scenario. Doing software engineering? Coding in Go? Performing security analysis? Add a skill! Nowadays, any of us can do basically anything. Maybe not well, but with agent skills, we get just enough confidence to try it. But we’re blowing tokens and confusing our agents with all this extra context. Plus, you only really need skills when there’s a specific (temporary?) gap in the LLM’s knowledge. Let’s be smarter. Can we do just-in-time discovery and lazy-loading of skills for our coding sessions?
Case 1: Preload skills globally or in your project
As a baseline, many of us default to installing skills ahead of time. It’s easy to grab skill files manually, or use something like the skills CLI to install into global or project directories.
For instance, before starting my coding session, I could find and install a skill for working with Google Cloud Storage.
If I choose to install into my local project directory (instead of globally), I end up with these new files on disk.
I’m using Google Antigravity here, but you’d expect to see this skill show up in whatever agentic tool you have. Both my Antigravity desktop app and CLI show this pre-existing skill.
To be sure, this is a perfectly valid way to work. But the front matter of EVERY skill comes into play in all your agentic coding turns. That gets hefty over time. You could choose to just pre-load or copy the “right” skills into your project before each session. But that assumes you know where you’re heading before every session. I sure don’t! Let’s look at more dynamic scenarios.
Case 2: Find known skills during a session and use them
Let’s consider a case where I know where the desired skills live on the internet, but I only want to grab them if I really need them.
For example, maybe I use all sorts of clouds and pick the right one for the problem at hand. In my current coding session, I’m thinking through web app ideas, and landed on a fun concept for a fast-turnaround marketplace. Its bursty use and global footprint are great for Google Cloud. I need good guidance for picking the right architecture, so I asked Google Antigravity to find the right Google Skill to help out, and store it locally.
When this finished a few moments later, I had another skill in my local project directory.
Most importantly, this skill is automatically active in this coding session. I can see that in Antigravity’s list of active skills.
My current session got better as I discovered and loaded agents on-the-fly. And these skills stay with this project and aren’t just part of the LLM (or coding session’s) temporary memory.
Case 3: Search for skills during a session and use them
The above case assumed that I knew the location of the skill I wanted. You need to be careful about loading random skills, but what if you wanted to search without knowing ahead of time where the most suitable skill was at?
I continued my coding session by asking for the best skills for Go developers.
I know Steve (the creator of the 2nd of the 3 provided options) so I told Antigravity to load Steve’s skills. Sure enough, I got a handful of terrific Go skills installed into my project.
You don’t have to know skills or sources you want ahead of time. You can search for them during a session and keep going without ever breaking flow.
Case 4: Use a seed skill that grabs the “right” skill for the scenario
I’ve seen more of this pattern lately. You know you will need a set of related skills, but don’t know which ones, or when. A seed skill is your entry point that pulls the right skill at the right time. Addy’s Osmani’s agent skills do something like this. The “meta skill” routes you to the right skill for your situation. But it does require you to install all the skills (I believe).
Could you create a seed skill that acts as a lightweight entrypoint, and then just-in-time downloads the “right” skill from a pre-defined list? Sure you can.
Specifically, I want a skill that knows about all of the Google Cloud databases, but only retrieves the corresponding skill if our session demands it.
I used Antigravity to build it (in a different session) and here’s the gist (minus the scripts and references it also created).
---
name: gcp-database-seed-skill
description: >-
Dynamic seed skill for Google Cloud database solutions. Use this skill when the user is designing,
choosing, provisioning, migrating, or optimizing databases on Google Cloud (Cloud SQL for MySQL/PostgreSQL/SQL Server,
AlloyDB for PostgreSQL, Cloud Spanner, Firestore, or Bigtable), or when well-architected cloud database guidance is needed.
Automatically routes, downloads, and installs specialized skills from google/skills on demand.
---
# Google Cloud Database & Architecture Advisor (Seed Skill)
This seed skill provides a lightweight, progressive entrypoint for all database workloads on Google Cloud. Instead of loading bulky documentation upfront, it assesses workload requirements, recommends the optimal database solution, and dynamically downloads and installs specialized skills from the official [google/skills](https://github.com/google/skills) repository into your local workspace.
---
## Workflow & Step-by-Step Procedure
When invoked on a database-related prompt, follow this 4-step workflow:
```mermaid
flowchart LR
Step1[1. Assess Workload] --> Step2[2. Determine Database & WAF Needs]
Step2 --> Step3[3. Download & Install Skill]
Step3 --> Step4[4. Execute Guided Solution]
```
### Step 1: Assess Workload Requirements
Evaluate the user's requirements against key architectural dimensions:
1. **Engine Compatibility**: Does the workload require MySQL, PostgreSQL, SQL Server, or open-standard ANSI SQL?
2. **Scalability & Scale**: Single-instance vertical scaling vs. distributed multi-node horizontal sharding?
3. **Availability & DR**: Regional HA (99.95% - 99.99%) vs. Global Multi-Region zero downtime (99.999%)?
4. **Workload Characteristics**: Standard OLTP vs. High-throughput HTAP with columnar queries vs. Vector/AI search vs. NoSQL?
5. **Migration vs. New Build**: Existing application lift-and-shift vs. greenfield cloud-native design?
> 📖 Consult the detailed [Database Decision Matrix](./references/database_decision_matrix.md) for complete comparison tables.
---
### Step 2: Select the Target Skills
Map the workload to the primary database skill and check for relevant **Well-Architected Framework** pillars:
#### A. Database Engine Selection
* **Cloud SQL (`cloud-sql-basics` / `cloud-sql-mysql` / `cloud-sql-postgresql` / `cloud-sql-sqlserver`)**:
* *Select when:* Straightforward relational databases (MySQL, PostgreSQL, SQL Server), standard web apps, migration-friendly lift-and-shift via Database Migration Service (DMS).
* **AlloyDB for PostgreSQL (`alloydb-basics` / `alloydb`)**:
* *Select when:* Demanding enterprise PostgreSQL workloads, up to 4x transactional performance, up to 100x faster analytical/HTAP queries with columnar engine, or in-database vector search (Vertex AI / ScaNN integration).
* **Cloud Spanner (`spanner`)**:
* *Select when:* Mission-critical global databases, massive scale exceeding single-instance limits, synchronous multi-region replication, horizontal scaling, and 99.999% availability with zero downtime.
* **Discovery / Undecided (`cloud-databases-onboarding`)**:
* *Select when:* User is unsure or needs interactive discovery across relational, NoSQL (Firestore, Bigtable), and analytical stores.
#### B. Well-Architected Framework Triggers
Check if cross-cutting architectural pillars should be retrieved:
* **Reliability & HA:** Mentions of 99.999% SLA, DR, RTO/RPO, regional failover → Fetch `well-architected-reliability`.
* **Security & IAM:** Questions about Private IP, PSA, CMEK encryption, or IAM DB auth → Fetch `google-cloud-recipe-auth`.
* **Performance & Tuning:** Connection pooling, read replicas, latency optimization → Fetch `google-cloud-solution-architecture`.
* **Cost Optimization:** Committed Use Discounts (CUDs), rightsizing, auto-pause → Fetch `google-cloud-solution-architecture`.
> 📖 Consult [Well-Architected Triggers](./references/well_architected_triggers.md) for full trigger criteria.
---
### Step 3: Download and Install the Specialized Skill
Execute the bundled installer helper to fetch the required skill(s) directly from `google/skills` into the workspace's `.agents/skills/` directory:
```bash
# Example: Install Cloud SQL basics
python3 scripts/install_gcp_skill.py --skill cloud-sql-basics
# Example: Install AlloyDB basics
python3 scripts/install_gcp_skill.py --skill alloydb-basics
# Example: Install Cloud Spanner
python3 scripts/install_gcp_skill.py --skill spanner
# Example: Install Well-Architected Reliability
python3 scripts/install_gcp_skill.py --skill well-architected-reliability
# Example: Install all core database skills
python3 scripts/install_gcp_skill.py --all-databases
```
*Alternative using npm/npx:*
```bash
npx skills add google/skills
```
---
### Step 4: Proceed with Implementation
Once the skill is installed into `.agents/skills/`, it is immediately available for subsequent operations.
1. Reference the newly installed `SKILL.md` in `.agents/skills/<skill-name>/`.
2. Provide concrete `gcloud` commands, Terraform/IaC snippets, or client library examples tailored to the user's selected database.
3. Verify connectivity (e.g. Cloud SQL Auth Proxy, IAM authentication, VPC Private Service Access).
---
## Reference Guides
* [Database Decision Matrix](./references/database_decision_matrix.md): Deep-dive comparison between Cloud SQL, AlloyDB, Spanner, Firestore, and Bigtable.
* [Well-Architected Framework Triggers](./references/well_architected_triggers.md): Detailed rules for triggering security, reliability, performance, cost, and operational pillars.
* [Known Skills Catalog](./references/known_skills_catalog.md): Complete list of remote paths and metadata in `google/skills`.
* [Prompt Routing Scenarios & Examples](./examples/prompt_routing_scenarios.md): Real-world examples of user requests and the exact skills retrieved.
After adding this seed skill to my current coding session, I started up a database conversation regarding my app idea. We landed on Firestore as the best choice, so I asked the seed skill to retrieve only the Firestore skill.
Here, I didn’t need to download or pre-load all the possible Google Cloud database skills. There’s a lot of them. I only got the one I needed for this particular coding session. Seems cleaner?
A word about MCPs
If your skills make use of remote or local MCP servers, circumstances are different. While MCP now supports a stateless interaction pattern, most existing MCP servers don’t. When your coding session starts, there’s a handshake that happens. This means that if you introduce a new MCP during a session (in your mcp_config.json), you likely have to fork your current session, or start a new one. My tests showed this to be the case most of the time, but your mileage may vary.
I mention this because you could see skills that make heavy use of managed MCPs. That’s cool, but downloading those skills on the fly might mean they only partially work because your coding harness can’t “see” the referenced MCP server. Just be cautious!
We’re seeing an emerging “open knowledge layer” consisting of MCPs, skills, and plugins. I’d imagine we will see patterns evolve for how and when to use each component. What do you think of this lazy loading pattern I demonstrated here?
Richard Seroter's Architecture Musings 