Seroter's Daily Reading — #847 (August 17, 2026) · Seroter's Daily Reading

Listen: https://blossom.buildtall.systems/ab2dff5fd1918fb3d2831da1e4cd452767d1ecdd85db94891e8ed36b16f85911.mpga

Episode 847 — August 17, 2026

It's "strong opinions Monday" here at the Reading List. Eleven pieces today, and I'm going to let you guess which one has the most to say about the current state of the agentic engineering world. Spoiler: it's not from a hyperscaler. Let's get into it.

Starting with a piece from the Agentic AI Foundation about the A2A protocol joining AAIF as a hosted project. A2A is the open standard for inter-agent communication — the thing that lets agents built on different frameworks and from different vendors discover each other, delegate tasks, and exchange work without a bunch of custom integration glue. Google launched it in April of last year and donated it to the Linux Foundation. In August of 2025, IBM's Agent Communication Protocol merged into it, which was a good signal that the industry was consolidating around a single shared standard rather than fragmenting into competing proprietary approaches. A2A v1.0 shipped earlier this year with multi-protocol bindings, version negotiation, multi-tenancy, and signed agent cards for cryptographic identity. It's already running in production across mobile platforms, cloud AI infrastructure, financial services, supply chain, and enterprise IT. Huawei has standardized it as the protocol between Celia, its OS-level AI assistant, and in-app agents across HarmonyOS. Tencent's WeChat is integrating with Huawei and Android OEM assistants over A2A for messages, voice calls, and video calls initiated through an AI assistant. Google Cloud, Microsoft Azure, and AWS all support A2A natively in their respective AI platforms. Google Cloud and PayPal are extending it into agentic commerce through the Agent Payments Protocol. What's interesting here is the governance model. A2A has over 150 partner organizations including direct competitors. That breadth only holds together under neutral governance, and the Agentic AI Foundation, hosted by the Linux Foundation, provides that. For teams building multi-agent systems, this removes a specific category of risk — the protocol your agents depend on isn't subject to a single vendor's product decisions. Seroter mentions his team has been working on this for a while and is glad to see it move to this foundation. Fair enough.

Moving to a piece from Markus Eisele on O'Reilly's Radar about specifications and what happens to them when AI is writing the code. This one's titled "When AI Writes the Code, Specifications Need an Exit Strategy", and the core argument is sharp: specifications should be temporary by default. The problem Eisele describes is familiar. Open a repository after six months of spec-driven agent work and you may find a second system sitting next to the code — requirements, research notes, high-level designs, low-level designs, implementation plans, task lists, review reports, and a growing stack of Markdown files that explain what the code is supposed to mean. Even if the code changed significantly last Tuesday, the last documentation update was weeks ago. As agents produce code quickly, teams try to control the drift by moving more thought in front of implementation, making Markdown files with requirements, decision records, design approaches, and acceptance criteria the center of gravity. What effectively becomes a very large prompt fills a significant portion of the context window before any relevant source code gets added. Natural language specification is a weak system for agents to synchronize a codebase with. Without additional attention, most agents shift attention away from it and focus on the stronger signals in the codebase, forgetting to update the specification. The mistake is treating a specification as a permanent natural-language copy of the software. A useful spec describes the next change, documents the decisions that drive it, sets boundaries, and gives enough verification surface. But as soon as the change ships, most of it should be removed. What remains should move into the artifacts software teams already know how to maintain: code, schemas, configuration, policies, tests, and runtime telemetry. Eisele prefers calling this a "change brief" rather than a "specification" because specification sounds heavyweight and pretends to be complete, and that completeness is what makes it expensive. Heavyweight specification methods try to control quality by prescribing the path, but that creates a lot of attention on low-risk work while avoiding the deep technical judgment needed for harder changes. A copyedit and a payment-flow change should not follow the same process or testing strategy. The piece cites Simon Willison's simpler approach: give the coding agent the outcome and let it judge how much process the task requires. This matches how Eisele wants these systems to operate. Context is an engineering budget. Large specifications cost more than the time required to write and maintain them. They also compete with the code and evidence the agent needs for the current decision. Every requirement, design note, repository instruction, and tool definition consumes part of a limited working context. Important rules become harder to follow when surrounded by stale or duplicated material. Progressive disclosure is a better fit. This is a strong take and a useful reframe.

From Harvard Business Review, a piece called "Research: The Innovation Problems AI Can't Solve." The framing is that every innovation team now has the same tools — the same foundation models, similar prompt libraries — yet results are wildly uneven. Some teams report a creative renaissance while others report a flood of homogenized, forgettable ideas that all sound like they came from the same person. The reason isn't which model you're using. It's that generative AI acts on the human bottlenecks buried inside the innovation process, and these bottlenecks respond to AI in different, sometimes opposite, ways. Seroter notes one takeaway in particular: don't rush and avoid cognitive surrender. Use AI as a tool, not a substitute for thinking, seeing things for yourself, or taking ownership.

Now, from Google Cloud, a piece on Antigravity called "the busy PM's best friend." This one got blocked by a security service during research, which is unfortunate because the title and Seroter's commentary suggest it covers real problems that AI can actually solve, especially with human spot-checking. We'll have to go with what we know from context here.

Much more productive is a post from Wes McKinney on the Kenn Software blog about how his team does agentic engineering. This one's really good. McKinney opens by noting that his team of three people merges hundreds of pull requests per week, across millions of lines of production code, with an empirically low bug rate. And then he immediately pushes back on the "loop engineering" and "graph engineering" discourse that's everywhere on social media: fully autonomous, no-human-in-the-loop pipelines are, in his words, bullshit. Anyone telling you that you can engineer agents looping on each other's output, step away from the keyboard, and get good quality output on the other end is either clueless or selling you something. That being said, McKinney burns a lot of tokens — he's regularly at the top of a token leaderboard, and his last 30 days of consumption would have cost nearly fifty-seven thousand dollars at API rates. The rest of the post describes the Kenn team's stack and workflow. Jesse Vincent, creator of the Superpowers framework, described the difference between vibe coding and agentic engineering as "planning, architecture, and caring about the output." The Kenn team puts it bluntly: vibe coding is not caring at scale. Their workflow starts with the right tools — Superpowers and roborev, their continuous local review and verification system. The human stays involved in every important brainstorm decision and design section. Design and taste are not delegated to an agent. When a decision is unclear, they ask for a second opinion from a separate agent session, ideally from a different model family. Once the design is settled, Superpowers turns it into a precise specification. A separate agent reviews the specification adversarially, findings are fixed, and the review repeats until it converges. Superpowers then turns the reviewed spec into an implementation plan, which they implement either with subagent-driven development or inline execution. Superpowers commits frequently after validating spec conformance, and roborev asynchronously does adversarial verification. On large changesets, they sometimes spend hundreds of dollars in tokens bug-bashing with roborev, since the alternative is letting the codebase become a minefield of latent bugs. They do not retain Superpowers spec and plan documents in their repositories or refer to them in production code — all documents must be converted into living architecture documents. The human opens the pull request and owns the merge. McKinney also describes their "clanker constitution" — a set of operating principles for their coding agents that address how they communicate with humans, act with judgment, finish the job, protect existing work, verify reality, and communicate for humans rather than defaulting to walls of robospeak. They've also built custom tools for their workflow: Kenn Forge as a high-throughput review and landing workspace, Ghosthub as a multiplexer-native terminal for local and remote agent sessions, Kata as an agent-native issue tracker that serves as the system of record for intent, and AgentsView and roborev as accountability engines. McKinney's takeaway is worth quoting directly: they are biased toward a human-operator-centric workflow intended to minimize the amount of code slop that lands in their repos, which requires each of them to remain engaged with the design process, architecture, and details of what they are doing, never delegating critical work to an autonomous coding loop. Strong opinions, well-grounded.

From Google Cloud again, a piece by Darren on "Skills Sprawl: When Too Much of a Good Thing Confuses Your AI Agent." Seroter's commentary is brief and direct: you've gorged yourself on skills, step one was recognizing it, step two is to do something about it. This one also got blocked during research, so we're going light on specifics, but the takeaway is clear enough.

Now a piece from Ali on GitLab Pages titled "The SKILL.md Fallacy: Phase Transitions and Process Isolation in Coding Agents." This is the most technically dense piece in today's batch, and Seroter says Ali makes a strong case that we're misusing skills and should be looking at subagents instead. The TL;DR is that the developer ecosystem has turned SKILL.md into a cargo-culted silver bullet for agent modularity. While progressive disclosure provides legitimate token savings for small, orthogonal utilities, empirical research demonstrates that flat skill libraries suffer a catastrophic, non-linear phase transition failure as complexity grows. For non-trivial domain shifts, in-context prompt injection is an architectural anti-pattern, and the correct systems primitive is ephemeral subagent delegation with isolated process boundaries. Ali walks through five fundamental failure modes of the SKILL.md approach. First, semantic routing and discovery fragility: for progressive disclosure to work, the agent must correctly infer which skill to trigger based on a two-line description in its system prompt, and because natural language is ambiguous, this routing is stochastic. Developers suffer false negatives where the agent ignores the skill and hallucinates an ad-hoc implementation, or false positives where it reads completely irrelevant documentation. Second, prompt cache invalidation and KV-cache thrashing: hydrating a large markdown document in the middle of a long conversation blows away the downstream cache prefix, triggering expensive recomputation and inflating per-turn latency. Third, prose instead of determinism: a SKILL.md file written in natural language explaining how to invoke a CLI or format an API payload is vastly inferior to a typed compiler, a shell script, or an MCP tool. Prose invites interpretation; determinism guarantees execution. Fourth, silent rot and the lack of compilers: source code has compilers, linters, and unit tests that fail loudly when a contract breaks. SKILL.md files possess none of these defenses. Fifth, instruction conflict and precedence chaos: when a complex task triggers three separate skill files into a single context window, their behavioral directives collide, and because flat markdown prompts lack formal scoping or priority hierarchies, the model resolves these contradictions through arbitrary probabilistic weighting. The piece cites empirical research from Li et al. this year on the capacity limits of LLMs selecting from internal skill libraries, which found that skill selection accuracy does not degrade gracefully. Instead, it remains stable up to a critical threshold and then drops off a steep cliff. The primary catalyst is semantic confusability: as a skill library expands, the natural language descriptions of different skills inevitably begin to overlap, and the model's attention mechanism diffuses across overlapping semantic vectors, causing severe routing failures. The proposed antidote is process isolation and ephemeral subagents: instead of mutating a single monolithic context with runtime prompt injections, the orchestrator spawns a dedicated subagent with a pristine, specialized system prompt and a tailored toolset designed exclusively for that domain. The subagent performs its work, returns a clean diff or summary, and terminates. Its entire multi-thousand-token exploration context is discarded. The parent orchestrator's context remains lean, clean, and unpolluted. Ali's conclusion is quietly devastating: for years, developers celebrated the arrival of giant multi-hundred-thousand-token context windows and immediately treated this newfound memory as a massive digital trash can. Now, having watched their monolithic agents choke on semantic confusability and prompt pollution, organic engineers are slowly rediscovering what Unix developers established in 1970: small tools, clean address spaces, clear pipes, and strict process boundaries. That's worth sitting with for a moment.

From Atomic Object, a piece called "Fabled Too Hard? How I Stay Engaged in AI Development." This one complements the McKinney and Eisele pieces nicely. The author's premise is that at some point into AI adoption, you can allow the agent to solve all your problems, and that's when things start to go wrong. The single best way to stay connected as a developer is to engage with the minds of people around you. Their wealth of experience and context into your shared project is invaluable. Speaking to each other is also an incredible balm after reading endless plans filled with robot technobabble. The piece advocates for drawing before taking on work — not just to illustrate user flows or architectural insights, but as a way of testing your own understanding. Drawing gives clarity, reinforcing what you know to be true and what you have yet to learn. The agent isn't the one who will reap the consequences of bad design, so you can't afford to let your mental model atrophy. The piece also emphasizes verification: an agent can turn an underspecified request into a coherent implementation before the missing decisions become visible to anyone, and that coherent appearance is part of the risk. The author needs to be able to articulate exactly the best ways to test the changes, because that means understanding the scope of the work, the context, and the architecture. There's also a section on where the robot's limitations are: the agent gave some interesting database design ideas, but the most elegant solution came from a coworker. The agent couldn't describe the data flow from one end of the system to the other. It attempted to follow some bad patterns in older parts of the codebase. It dropped the ball on some feature sets because there was too much context. It often takes the easiest path forward, which is not always the best way. Knowing these limitations keeps the human engaged because they know where they're needed most. The piece closes with what sounds like personal experience: the author was so deeply into working with an agent that they completely forgot about a few completed stories from the day before and couldn't remember a key component of a workflow they'd had a huge hand in. Their hypothesis is that they fabled too hard, taking on more than they should have. The fix is simple and sounds obvious: keep PRs small and focused, plan work ahead of time, and balance the priority of what you take on. Use AI to fight cognitive surrender, not to replace the thinking.

Moving to a LinkedIn post from James O'Reilly on Google Cloud's Antigravity series, this one on subagent management as the final installment of a five-part guide. The core message is that by equipping orchestrator agents with process governance via manage_subagents, you transform multi-agent execution from unmonitored background spawning into a controlled, resilient team capable of active status auditing and hard circuit breaking. The manage_subagents tool operates across three action modes: list queries the runtime session registry and returns a summary of all active subagents including their conversation ID, role, mode, and start timestamp. Kill immediately halts execution for specified subagent conversation IDs and cleans up their branched workspaces. Kill_all is the emergency circuit breaker that terminates every running subagent and descendant process across the workspace tree. When a subagent is killed, its temporary branched workspace is automatically deleted while execution logs and artifacts remain preserved for post-mortem analysis. The piece contrasts soft messaging versus hard termination: send_message lets a subagent broadcast a soft kill signal, but relying on soft kills means assuming the other workers are actively checking their inbox and capable of self-terminating. By pairing send_message with manage_subagents, the parent orchestrator can execute a hard circuit breaker. This completes the five-tool toolkit for the Antigravity agent: ask_question for interactive UI workflows, generate_image for assets, define_subagent and invoke_subagent for parallel worker dispatch, send_message for real-time telemetry, and now manage_subagents for active governance.

Now a GeekWire piece on a GitHub outage that disrupted developers worldwide. GitHub was down for more than three hours on Monday morning, affecting the website, code review tools, CI/CD systems, and GitHub Copilot. GitHub has been struggling for many months with the surge of AI-driven coding. Their CTO wrote in April that the company set out last fall to expand capacity tenfold, then concluded by February that it needed to build for thirty times its current scale. A Microsoft spokesperson told Business Insider in June that the spike in AI agent development had tested GitHub's infrastructure limits, and said the company was accelerating GitHub's move onto Azure while pursuing a multi-cloud strategy, including renting capacity from Amazon Web Services. Seroter notes that the timing wasn't great, as a legitimate competitor apparently launched on the same day.

Wrapping up with a piece from Ping Lin on the shapes of agent memory. Seroter says he's not smart enough to extract all the learnings from this, but it sounds like databases are better than text files when AI needs to process many conversations. The piece is an empirical study comparing three shapes of agent memory: file-based, structured store, and experience-based. File-based memory keeps memory as files the model curates — a short index plus topic files written in plain markdown, read back by searching and reading like any other file. This is what Claude Code, Cline, Cursor, and Windsurf ship today. Structured memory keeps memory as a structured store where every turn is mined into small atomic facts, embedded into a vector index, threaded into a temporal graph, and read back by ranked retrieval. This is what the dedicated memory startups like mem0, Letta, and Zep sell. Experience-based memory keeps memory as experience the model is trained to use through reinforcement learning — episodes land in a bank but everything that makes them memory, what to retrieve, whether to trust it, and how to turn it into action is trained into the acting policy. The study found that the structured store beats files on accuracy and token cost at once, while files win where memory stays small or where the right answer is "I don't know." The hybrid structured approach was statistically indistinguishable from a plain vector index on one benchmark but showed a fifteen-point advantage on another, which is consistent with structure paying off as histories grow. Swapping the model stack that reads and judges the memory moves the score further than swapping between any two of the stores that work, which is why numbers don't travel between protocols. On agentic benchmarks, retrieved experience paid only where the actor was weak with headroom left. Where the task yields to reasoning, a frontier actor reaches the trained system's bar with no memory at all. Where the reward has a shape only practice teaches, the trained policy stands alone. The takeaway from Seroter stands: databases beat text files when AI needs to process many conversations, and if you're building agentic systems today, this is worth understanding.

Strong opinions Monday delivered. Eleven pieces, and if you had to pick a through-line, it's probably the one Ali articulated most bluntly: stop treating massive context windows as a trash can and start treating process boundaries like the discipline they actually are. Whether that's ephemeral subagents, change briefs instead of permanent specs, small PRs instead of goliath merges, or structured memory stores instead of markdown files, the advice points in the same direction. Stay tight, stay honest with yourself about what the robot can and can't do, and don't let the speed of generation trick you into thinking the work is done.

No Nostr signer detected