Seroter's Daily Reading — #827 (July 17, 2026)
Follow into
Save into
Source: Seroter's Original Post
Seroter's Daily Reading, Episode 827. July 17, 2026.
This one's a good one. We've got agent orchestration, agent optimization, a language that might be perfectly built for this moment, a renaming, a new open model that's turning heads, and some solid perspective on model routing. Let's get into it.
First up, Google Cloud dropped a piece on What 10 autonomous film crews taught us about agent teamwork. This is genuinely wild. They assembled actual film crews out of AI agents, then sent a second AI documentary crew to film the whole thing. Each film combined multiple Google models. Gemini image generation produced character reference sheets and storyboard frames. They kept characters consistent by generating headshots first, then using those as input for body sheets, then using body sheets as input for scene frames. That's reference chaining. Veo 3.1 generated the video clips, four to eight seconds at 720p, with different generation modes depending on the shot type. One team built their whole film around the fact that Veo generates audio inside each clip too. They structured the script like a musical score with movement markings because the sync between generated speech and lip movement gave pauses real weight.
The agents ran on Scion, an open-source orchestration system. Scion defines agents from templates, runs them in containerized sandboxes, and lets agents spawn and message each other through a shared CLI. The shared filesystem was the key resilience mechanism. When an agent crashed, its files persisted. The coordinator restarted one documentary producer agent multiple times across the project, and each new instance read the previous one's files and continued.
What they learned: agents collaborate better through files than through messages. Teams that wrote decisions down recovered from crashes without losing direction. Teams that kept decisions in message history lost them. The effective pattern was passing messages containing file-paths. They also found that choosing styles that match AI generation strengths produced better films. Claymation's wobble made temporal drift invisible. Silhouette animation sidestepped facial consistency problems. One team couldn't generate a kiss because a safety filter blocked it. They showed two shadows merging on a wall, and the coach called it the strongest shot in the film.
A coach role at verification gates changed outcomes. The coach could observe the full production but could only intervene at step boundaries. One coach described it as "a room full of specialists who can each do one thing at superhuman speed, but none of them can taste the soup."
Next, a piece on How I Cut an AI Agent's Token Use by 94%. This is smart. He had a daily skill that looks through his back catalog of blog posts, finds something worth resurfacing, checks recent history, and drafts a LinkedIn post. The original version was written as natural-language instructions in an Agent Skill. On every run, his agent had to interpret those instructions, make a plan, call tools, and track workflow state. That was great for the first version. Natural language made it easy to articulate and change.
But after running every day for a while, most of the behavior had crystallized. The skill always looks in the same places. It builds the same content inventory. It applies the same recent-post filters. None of that needs to be reasoned through from scratch each morning. A lot of it doesn't even need an LLM. There were really only two steps where LLMs were needed: choosing a good candidate from the inventory, and writing the LinkedIn draft. Everything else could be deterministic code.
So he compiled the skill into a specialized harness. The new version is barely a skill at all. It's a thin bootloader that invokes a Python program. That program fetches the sources, constructs the inventory, checks recent posts, applies filters, and manages the workflow. It calls an LLM only for selection and generation. The result: 94 percent fewer tokens, 87 percent lower latency, essentially the same output quality.
He didn't get those gains by swapping to a smaller or cheaper model. The selection and generation steps still use the same model. The savings come from removing all the model calls that were doing work regular code could do more directly. His framing is sharp: a general-purpose coding agent is an extraordinarily capable reasoning and workflow engine, but it's an expensive way to execute a procedure whose shape becomes known after a few historical invocations. The natural-language skill serves as a high-level specification. The traces supply the operational detail. Then you compile what has crystallized into code.
He also notes there's little incentive for the big model vendors to push this idea hard, since their revenue rises with token usage. That's the opportunity for independent builders.
Moving on. A post on My thoughts on the future of Go in the AI era, and honestly this is one of the best-written arguments I've seen on the topic. The core idea is that AI systems are starting to compete on machine ergonomics, not just human ergonomics. Languages that are human-friendly but not machine-friendly will face more pressure. Ruby on Rails is incredibly human-friendly, but humans can navigate conventions and implicit magic that models struggle with. Explicit systems are easier for AI to reason about.
Go, the author argues, is an extremely good language for LLMs. Not just for humans. The standard library is massive and well-designed, you can build real production systems with few dependencies. The Go team takes security and stability seriously. The compiler is absurdly fast, and that matters more than people realize in the AI era. Humans can tolerate slower feedback loops. Agents really cannot. AI systems might compile and iterate hundreds of times while solving a task. Fast compilation directly improves that workflow.
Go also produces single static binaries, has built-in formatting, powerful cross-compilation, minimal dependency hell, and simple intentional syntax. Go removed many ways to write creative code. There are simply fewer ways to make a mess, which means AI-generated Go code often ends up looking surprisingly clean. The compatibility promise is a standout. The team guarantees that old programs continue working on newer Go versions. You can open a Go project from almost ten years ago and run it on a modern version without issues. That level of stability might become one of the most valuable engineering properties when AI starts generating massive amounts of code. Generated code doesn't need to be genius-level engineering. It needs to be understandable, stable, refactorable, and easy to verify. And Go is proudly boring in exactly the right ways.
Now, some news. NotebookLM is now Gemini Notebook. Thirty million people and over 600,000 organizations were using it. It remains a standalone product focused on research, but it will now do more across the Google ecosystem, including inside the Gemini app and Google Search. There's also an under-the-hood upgrade coming, giving every notebook a secure cloud computer that can write and execute code natively for complex data analysis grounded in your sources. Available now for Google AI Ultra users and Workspace business customers, rolling out to all Pro users soon.
Then there's Kimi K3: Open Frontier Intelligence from Moonshot AI. This is a big deal. Kimi K3 is the world's first open model to reach 2.8 trillion parameters. It's built on their Kimi Delta Attention and Attention Residuals, with native vision capabilities and a one-million-token context window. On coding benchmarks, Kimi K3 posted competitive results against frontier proprietary models. In one test, an early version of K3 handled the majority of the team's GPU kernel optimization work. It also developed MiniTriton, a compact Triton-like compiler with its own tile-level IR layer over MLIR, optimization passes, and a PTX code generation pipeline. Across supported roofline benchmarks, MiniTriton delivers performance on par with or better than Triton.
For game development, K3 combines strong 3D reasoning, coding, and vision to turn concepts, images, and videos into fully playable interactive experiences. It uses vision in the loop by iterating between code and live screenshots, instantly seeing and refining outputs. In one 48-hour autonomous run, K3 designed a chip to serve a nano model built on its own architecture, using open-source EDA tools on the Nangate 45nm library. A chip built by a model, for a model.
It's available today on Kimi.com, Kimi Work, Kimi Code, and the Kimi API at launch pricing. Full model weights release by July 27th.
Finally, a piece on Model Routing Is Simple. Until It Isn't from IBM Research on the Hugging Face blog. Building a router sounds simple. Send simple requests to cheaper models, reserve expensive ones for harder tasks. A classifier makes the call, costs go down, performance stays up. Except it's not.
Three dimensions made this surprisingly hard. First, cost is more than model pricing. Across 417 tasks on the AppWorld Test Challenge using a CodeAct agent, they found that Claude Sonnet cost 79 dollars total at 19 cents per task, while GPT-4.1 cost 155 dollars at 37 cents per task, nearly double. On paper that makes no sense. GPT-4.1's token pricing is lower on both input and output. The explanation was caching. Agent workloads reuse large chunks of context across steps. Sonnet's lower cache-read pricing meant it benefited disproportionately from that pattern, enough to overcome both its higher base pricing and its longer trajectories. Actual cost depends on the interaction between the model, the workload, and the serving infrastructure.
Second, complexity is more than task difficulty. A request like summarize this contract looks simple but might trigger retrieval, compliance checks, tool use, and multiple rounds of refinement. You often don't know how hard a task actually is until execution is underway. Third, latency is more than model speed. Infrastructure factors like which hardware a model is running on, whether the cache is warm, how busy the endpoint is, often dominate end-to-end response times.
The key shift they made was treating routing as an optimization problem rather than a classification problem. Rather than asking which model is best, their algorithm optimizes across cost, quality, and latency simultaneously, while staying lightweight enough to avoid becoming a bottleneck. Configuration one landed at 84 percent accuracy for 93 dollars and 83 seconds, a 21 percent cost reduction and 9 percent latency reduction compared to running Opus alone with only a 4 percent accuracy drop.
The takeaway is that routing isn't really about choosing models. It's about optimizing systems. Models are one variable among caching behavior, infrastructure state, compliance constraints, and workload patterns. When routing works well, it's rarely because it found the best model. It's because it found the best operating point for the entire system.
That's episode 827. A couple of threads worth noting.
Articles
- What 10 autonomous film crews taught us about agent teamwork — Google Cloud
- How I Cut an AI Agent's Token Use by 94% — Vivek Haldar
- My thoughts on the future of Go in the AI era — PackageMain
- NotebookLM is now Gemini Notebook — Google
- Kimi K3: Open Frontier Intelligence — Kimi / Moonshot AI
- Model Routing Is Simple. Until It Isn't — IBM Research / Hugging Face There's a real tension running through these pieces between flexibility and optimization. You want agents that can do anything, but once they settle into a pattern, there's huge value in compiling that into something leaner and faster. The Go post makes a similar point from the language design angle, that boring and explicit beats clever and implicit, especially when AI is generating the code. And the routing piece makes clear that the infrastructure layer isn't just plumbing, it's where the real tradeoffs live. Catch you next time.