Episode 96: AgentStack Daily: Agent Stack Release Readout: Hermes Agent v2026.7.30

I'm Nova. I'm Alloy, and this is AgentStack Daily. Hermes Agent just compressed more than a thousand merged pull requests into stable release 7.30. That sounds tidy. The underlying work wasn't. Nearly 2,800 commits touched the gateway, voice system, desktop app, installer, telegram media delivery, a Nostra-based channel called Buzz, and Flux 3 video generation. Meanwhile, DeepMind's robots can learn from long demonstrations, choose tools, and divide work among multiple machines. A retail voice agent in Japan has already handled 30,000 shoppers. Developers are also downloading a local, vision-capable Kimi model for private screenshot and document work. Okay, that's actually a lot of physical world AI in one day. But there's a sharp platform reversal too, GitHub retired its models playground, catalog, inference service, and bring your own key layer all at once. Today, you'll hear what Hermes 7.30 contains, how Gemini Robotics 2 coordinates whole robot bodies, why GitHub models users must now connect directly to providers, and where local multimodal models, stateless tool connections, code review agents, edge hardware, and Europe's AI rules move next. Across those items, the evidence ranges from live deployment numbers and published specifications to marketing posts and early research claims. Hermes Agent 7.30 landed July 30 as a stable patch release. It gathers more than a thousand pull requests merged since version 0.19 into a tagged build that downstream users can consume through Docker images, hosted deployments, and fresh installations. The scale is unusual for something labeled a patch, roughly 2,789 commits, 4,748 changed files, 442,000 insertions, and 392,300 deletions across the main branch in 10 days. Those totals describe development activity, not thousands of individually documented user features, so don't mistake the size of the difference for a neat feature list. Now's research says the period was dominated by bug fix and salvage work across the gateway, voice subsystem, desktop application, and installer. Salvage waves isn't the phrase anyone wants attached to a production agent, but a stable roll-up is exactly how that work reaches people outside the main branch. The named areas also show how broad Hermes has become. Gateway behavior affects requests entering and leaving the agent. Voice regressions hit real-time conversations. Desktop and installer fixes determine whether people can run it at all. Telegram media reliability matters when the agent receives or delivers more than text. There was continued work on Buzz, a channel built on the decentralized Nostra network, plus Flux 3 video generation and delivery. That's a lot of surface area packed behind one tag. And I'm going to resist the giant number glow. The source doesn't map those commits to specific new defaults, compatibility guarantees, or measurable reliability gains. Full notes are reserved for version 0.20, which NOS research says will document everything from 0.19 onward, including feature areas, highlights, and contributor credits. So 7.30 gives downstream consumers a stable artifact now, but not yet a guided tour through every change. Claims about better latency, reconnect behavior, approvals, permissions, or security would outrun the published evidence. Fair pushback. What's concrete is the transition from a fast-moving development branch to a stable release spanning gateway, voice, desktop, installation, channels, media, and generated video. Hosted and containerized Hermes deployments can consume one defined build rather than reconstructing that 10-day development window themselves. The more revealing release may still be 0.20 because that's where the maintainers promise the curated account. But 7.30 matters independently, it freezes an enormous stretch of repair and platform work into something downstream systems can actually name and deploy. DeepMind calls Gemini Robotics 2 whole-body intelligence. What does that mean beyond a robot moving more joints at once? It means perception, planning, tool use, arm movement, grippers, and mobile-based motion are treated as one coordinated problem instead of isolated control systems. DeepMind published two named models July 30, Gemini Robotics 2 and Gemini Robotics ER 2. ER means embodied reasoning, the model reasons about a task situated in the physical world, and DeepMind positions that variant for collaboration and real-world problem solving. The system can watch long video demonstrations, identify important steps, and turn those observations into action. It can also decide its built-in limbs aren't enough, fetch another implement, or call a separate agent. That moves the robot from following a narrow motion recipe toward assembling a plan from available bodies, tools, and services. Okay, the multi-robot part is what gets me. Several machines can divide a job without a person scripting every handoff, turning coordination into a model capability instead of a bespoke control program. DeepMind also frames the demonstrations around real-world tasks, not only tabletop pick and place. That framing landed, the discussion reached 561 points on Hacker News within a day, unusually high attention for robotics work. Popularity isn't proof of performance, obviously, and DeepMind hasn't established that one system can enter any unfamiliar site and handle unconstrained work. Whole-body control also compounds error, a bad visual interpretation can become a bad plan, a bad tool choice, and then unsafe motion. Still, combining long video understanding, orchestration, and collaboration gives these robots a wider route into labs, warehouses, manufacturing, and service work than a system trained around one gripper routine. Kitting, inspection, and packaging are the clearest targets because each combines perception, sequencing, tool choice, and repeated physical handoffs. Those jobs expose whether coordination survives outside a staged demonstration. GitHub Models is retired, completely. As of July 30, its browser playground, model catalog, inference API, and bring your own key option are unavailable to customers. GitHub didn't preserve the catalog while removing inference or keep the playground as a browsing tool. Every major part disappeared together. Developers who used the playground for fast model comparisons lose that entry point. Applications calling GitHub's inference endpoint lose that endpoint. Teams that supplied outside provider keys to root open AI, Anthropic, or other models through one GIT hub-managed surface lose that handoff as well. That's a surprisingly hard stop for a service built around convenience. Does moving directly to model providers restore the same setup? It restores the underlying model access, not the single GitHub layer. Provider software kits and API credentials can replace inference calls, while provider consoles and independent directories can replace browsing and prototyping. But applications that depended on GitHub's request format, model names, authentication, authentication, usage records, or routing still face integration work. Instead of one account mediating multiple vendors, teams now maintain each provider relationship themselves or choose another aggregation service. The source's customer scope wording is truncated, so it doesn't clearly establish whether a paid or enterprise continuation path exists. The confirmed news is the broad retirement, not a special exception. And that connects back to Hermes in a slightly uncomfortable way. Stable layers are valuable only while someone commits to operating them. GitHub models offered a thin, attractive abstraction over providers, now it's gone, and direct provider connections become the durable path by default. There may be better control in that arrangement, clearer billing, access to native features, fewer intermediaries, but there's more fragmentation too. Any product that treated GitHub models as production infrastructure now has to replace a dependency, not merely find a different browser playground. The retirement also fragments usage records and credentials that previously sat behind one GitHub-managed account. Moonshotari's Kimi K3 is pulling local model attention because Unsloth released quantized GGUF weights July 27, and the package passed 36,000 downloads with 218 likes within days. GGUF is a model file format used by local runtimes such as Llama.cpp, Ollama, and LM Studio. Quantization stores model weights with lower numerical precision, reducing the memory needed to run them. Put those together and a large model becomes more practical on privately controlled hardware instead of only through a cloud service. Kimi K3 also accepts images and text together, then produces text, opening local screenshot analysis, scan document extraction, visual chat, and private image-assisted work. That's exciting because local-friendly open models have often been text-first. A quantized multimodal package from Moonshot widens what offline assistants can see. And data can remain on a laptop, workstation, or home GPU system rather than crossing a third-party service. But GGUF doesn't mean fits on every laptop. Memory needs depend on the particular quantization and runtime. The model also carries an other license rather than a familiar permissive label, plus custom code and compressed tensor tags. Local availability and unrestricted commercial use aren't the same thing. Demand is visible beyond the unsloth package. Moonshot's main Kimi K3 listing has more than 9,100 likes and roughly 493,000 downloads, with image-to-text conversation and evaluation result tags. Those hub figures measure attention and retrieval, not production adoption or model quality. Still, hundreds of thousands of downloads say developers want vision, conversation, and local control in one package. Cloud multimodal services remain easier for many teams. Kimi K3 gives privacy-sensitive users and people with suitable hardware a serious alternative, while the model card remains the authority on exact formats, hardware requirements, benchmark conditions, and commercial terms. The GGUF conversion matters because common local runtimes already know how to load that format, reducing packaging work before any model-specific tuning begins. Dharma AI has a brutally simple comparison, and idle GPU is a grounded aircraft. It depreciates whether it's doing useful work or sitting on the tarmac. Right, and the July 30th hugging face post argues that organizations often budget around accelerator capacity purchased rather than computation actually consumed. Once a company operates more than a handful of GPUs, unused hours can become a dominant cost because the hardware, financing, power envelope, and support commitment continue even when jobs aren't running. It's a fleet management framing, utilization matters as much as nominal capacity. Buying scarce accelerators can feel like progress while queues, long reservations, oversized allocations, and fragmented workloads leave expensive machines inactive. I buy the framing, but not yet the implied scale. The available material doesn't provide utilization benchmarks, customer case studies, scheduling software, or measured savings. So dominant cost remains Dharma AI's headline claim, not a broadly demonstrated result in the cited post. This isn't a product launch, and it doesn't show that Dharma AI has solved scheduling or capacity reclaim. Still, the aviation analogy exposes a real accounting trap, installed hardware isn't automatically productive hardware. The next useful evidence would put numbers behind the argument, before and after utilization, fewer idle hours, higher job throughput, or avoided purchases. Until then, the post's contribution is conceptual but sharp, and used accelerator time is an operating cost, not empty space on a dashboard. NVIDIA put investor Sarah Gua in a July 28 promotional video and pitched Jetson as a clutch, compact, stylish, held in one hand, and apparently ready for the runway of embedded computing. Dry aside, GPU marketing has now reached handbag vocabulary. I laughed, but the deployment idea underneath it is real. Jetson runs AI at the edge, meaning on the robot, camera, drone, or handheld device instead of sending every input to a remote service. Local inference can reduce network dependence, protect data that doesn't need to leave the device, and keep a machine responsive when connectivity is slow or unavailable. Gua runs the AI-focused venture firm Conviction and co-hosts no priors, so NVIDIA is using an investor operator, not a chip engineer, to tell founders that edge deployment is a credible company-building surface. Just don't mistake the messenger for a technical release. The post announces no new Jetson product, software kit, price, benchmark, or changelog. It doesn't establish that a particular model fits, meets a latency threshold, or wins economically against a cloud service. This is NVIDIA marketing its existing edge platform through Gua's endorsement. That may reflect where venture attention is moving, but it supplies no fresh performance evidence. And yet it fits two earlier items almost perfectly. Kimi K3 shows developers want more capable models under local control. The GPU fleet argument warns that centralized accelerators can sit idle and expensive. Edge boxes move suitable workloads to the place where data is generated, though they create their own limits around power, memory, updates, and device management. NVIDIA's fashion framing is fluff. The growing interest in robots and devices that can perceive and act without a permanent cloud round-trip isn't. OpenAI published Advancing Responsible AI Across Europe on July 31. Is there a new European commitment in it, or is this mostly positioning around the EU AI Act? Mostly positioning around existing practices. OpenAI groups its work into safety, security, transparency, and provenance, then says those programs will continue alongside the EU AI Act as its requirements phase in. Provenance means information that helps identify where content came from or whether AI generated or altered it. OpenAI presents content labeling, disclosures, and security work as foundations for compliance rather than announcing a Europe-only model, certification, or enforcement system. That's an important distinction. A corporate playbook can signal direction without changing an application overnight. The EU AI Act activates different obligations on different schedules, with more demanding requirements around higher-risk systems. OpenAI is telling European customers that documentation, generated content identification, and safety reporting will remain part of its response. It isn't saying the implementation work is finished. As those rules land, model documentation and content origin information stop looking like legal appendices and start behaving like product surfaces. Exactly, and the harder evidence will arrive in specific artifacts, model documents, security disclosures, provenance metadata, and explanations of which obligations apply to which deployments. OpenAI's post-supports continued alignment work. It doesn't support assuming every European compliance question has already been resolved. The difference matters because a broad statement of principles can cover many future actions, while customers need concrete information tied to the model and use case they actually deploy. Four teams serving European users, provenance, and disclosure therefore become implementation concerns alongside model quality. The relevant obligation still depends on the product category and deployment context. PHY0 proposes a different foundation for world models. Instead of predicting future video pixels directly, it learns a compact vocabulary of physical state changes from ordinary video. The researchers call that a physical language, discrete tokens representing how the world moves, rather than full rendered frames containing every visual detail. Those tokens can then be rolled forward to predict later states. Okay, that's genuinely interesting because pixels force a model to reproduce texture, lighting, and background even when the useful question is whether an object falls, rolls, collides, bends, or stays put. PHY0 tries to abstract those transitions and provide cleaner material for planning. The authors compare it with how people infer reusable rules from observation. It's a research preprint, not a deployed robot system, and the work doesn't yet prove that physical tokens beat pixel prediction across real-world settings. But it offers a plausible route toward world models that reason about change instead of merely rendering what the next frame might look like. FrontisMA1 asks a wonderfully recursive question, Can an AI improve the engineering process used to build AI? The 35 billion parameter model is post-trained as what the researchers call a meta-evolution agent for machine learning engineering. Their open system, OpenMLE, turns proposed engineering changes into executable tasks with feedback. One layer runs verifiable environments, another teaches the model how to steer edits and searches, and a third supports longer searches in which improvements can compound. The headline isn't autonomous self-improvement achieved. It's that the team published an open, measurable environment where a model proposes changes and sees which ones work. Other researchers can inspect or extend the task environments, learning loop, and search system rather than relying on a closed demonstration. The paper is trending on Hugging Face's daily research feed, but repeatable gains inside that environment will determine how important it becomes. Recursive improvement has acquired an observable workbench, it hasn't acquired magic. DoubleWord published a walkthrough of Deltanet's family of linear attention variants, and its provocative claim is that Kimi Delta attention looks like a natural next branch once you understand the preceding work. Linear attention refers to techniques designed to process long sequences with growth closer to the sequence length, rather than the more expensive pairwise comparisons used by standard attention. Implementations differ, but that efficiency goal ties the family together. Which is useful because model announcements often present a new attention name as if it arrived from another planet. DoubleWord lines up the predecessors so each modification becomes legible as an answer to what the prior design could and couldn't retain. The post isn't introducing a model or reporting a benchmark win. It's organizing existing ideas into a lineage that makes Kimi's design easier to understand. The July 28 post reached 297 points on Hacker News and also drew discussion on lobsters, showing real demand for explanations that connect papers instead of treating each one as an isolated invention. I still don't buy the posts you could have invented it flourish. A clear retrospective can make an invention feel inevitable after the hard work has been done. But tracing the family tree does help separate substantial changes from branding. With Kimi K3 drawing local interest, the architecture inside it is suddenly less academic. Readers can see which limitation each branch addresses, what information it carries forward, and what trade-off it introduces without pretending that a good explainer independently reproduces the original research insight. GitHub moved agent skills and model context protocol support in Copilot Code Review to general availability July 29. Model Context Protocol, or MCP, is an open standard that lets AI systems connect to outside tools and data. The capabilities are now available to Copilot Pro, ProPlus, Business, and Enterprise users after a public preview. That's a real status change, but the announcement is surprisingly thin. General availability says GitHub considers these features ready for supported use rather than preview experimentation. It doesn't define exactly what an agent's skill contains, list bundled skills, identify specific MCP integrations, or describe behavioral changes from the preview. Free Copilot users aren't included in the name tiers. So the concrete move is availability and support status, not a newly documented review superpower. Connecting code review to skills and MCP could let the reviewer draw on specialized instructions or external context, but the changelog alone doesn't establish which systems it can reach or how that context changes a review. More detailed GitHub documentation carries those answers. What shipped is paid-tier access to two extensibility surfaces under a general availability label. That's meaningful for organizations that avoid preview features in production, even though GitHub hasn't supplied enough detail here to claim improved review accuracy, broader repository understanding, or a particular integration. This may be the least glamorous change with the broadest impact. MCP's July 28th specification makes its transport stateless. What does that alter for the services behind all these agent tools? Stateless means a server doesn't have to remember a session between requests. Each request carries what's needed to handle it on its own. That simplifies scaling because any suitable server instance can receive the next request, and it reduces dependence on one remembered connection surviving perfectly. A dropped session no longer has to invalidate every later exchange in the same way. The July 30th publication also introduces a formal deprecation policy, so protocol features receive notice and a documented transition period before removal. That's a maturity marker. Once code review agents, personal assistants, and code-based memory services speak the same protocol, surprise removals become ecosystem-wide breakage. A deprecation promise gives client and server authors time to move together. It doesn't mean old features live forever, but it does mean maintainers won't make them vanish without warning. And the timing matters, GitHub is asking paying customers to rely on MCP and code review while the protocol itself becomes easier to operate and more predictable to evolve. The specification update reached 127 points on Hacker News, a decent response for transport semantics. No, statelessness doesn't make every integration reliable by itself. Tools may still have their own authentication, data, or workflow state. The transport simply stops requiring the server to preserve a protocol session between requests. That removes one source of connection complexity and establishes a clearer contract for change. As MCP spreads across agents and repositories, boring operational guarantees become more valuable than another flashy demo. That contract is especially important for services scaled across multiple instances, because no single process must retain the protocol session for the next request. Avatrin has deployed a round-the-clock multilingual shopping assistant at Yamada Denki, a Japanese electronics retailer, using OpenAI's GPT RealTime. In its first two weeks, 30,000 people used the agent, and 92% of survey responses were positive. Those numbers come from the deployment account, but they're unusually concrete for a retail voice agent launch. Customers can walk up, ask product questions in their own language, and receive spoken responses in real time. 30,000 interactions in 14 days isn't a quiet back-office pilot. GPT RealTime is speech-to-speech, audio enters and audio returns directly, without treating visible text transcription as the central conversational step. That direct path can reduce the lag that makes older voice assistants feel like turn-taking machines instead of conversations. More importantly, public retail traffic brings accents, background noise, incomplete questions, interruptions, and people with zero patience. Surviving that environment at meaningful volume tells us more than a controlled booth demonstration. The measured outcome is encouraging, though positive survey response doesn't reveal response accuracy, task completion, repeat usage, or how many people declined the survey. We also don't have a breakdown by language or product category. Still, this is evidence of live use rather than a promise. And it makes the robotics news feel less distant. Intelligence entering stores won't all arrive inside humanoid machines. Voice may be the first practical interface because it uses existing retail space and doesn't require moving hardware. Returns, complaints, recommendations, and upselling carry higher stakes than locating a product. Expansion into those jobs would make the deployment considerably more consequential. The multilingual format also matters in a store. One voice surface can answer shoppers who would otherwise need different language support paths. We covered Gemini Robotics 2 earlier, but DeepMind's full release separates the work into three models. How do they divide the job? Gemini Robotics 2 is the vision-language action model for whole-body humanoid control. Vision-language action means it turns visual and language input into physical actions. Gemini Robotics ER2 handles embodied reasoning and task orchestration. A third, on-device model is designed to adapt to new robot bodies within hours. The release describes one checkpoint controlling both Aptronic's Apollo 2 humanoid and a Franca duo setup, which is the concrete evidence for sharing learned capability across different embodiments. Only ER2 is publicly available. That last sentence keeps the announcement grounded. DeepMind has shown a three-model stack, but outside developers don't receive all three control layers. ER2 being public gives researchers access to the reasoning component, while the whole-body and on-device models remain described rather than broadly released. The setup also clarifies why one giant model isn't doing everything, orchestration, full-body action, and rapid adaptation to hardware remain separate jobs even when they cooperate. Cross-body reuse is the exciting claim because robot learning has historically been tightly coupled to one machine's joints, cameras, and control stack. And we shouldn't extend that claim beyond the named systems. The source supports Apollo 2, Franca duo, whole-body control, embodied reasoning, adaptation within hours, dexterity, and multi-robot collaboration. It doesn't promise compatibility with arbitrary robots, unrestricted deployment, or general performance superiority. Even so, one checkpoint spanning a humanoid and a dual-arm platform points toward physical intelligence that's less trapped in one body. Its bounded evidence, not universal robotics, but bounded evidence across two very different machines is still a meaningful step. Separating the reasoning, action, and adaptation models also makes the boundary visible. Public access to one component is not public access to the entire robotic stack. Three repositories show MCP turning into working infrastructure. HKUDS's Nanobot leads with 46,460 stars and version 0.3, released July 25th. It's a lightweight, self-hosted Python agent framework with a web interface, memory, tools, automation, chat integrations, multi-agent workflows, and MCP. Deistata's code-based memory MCP tackles a complementary problem. Persistent code understanding. It builds a knowledge graph across 158 languages, ships as one static binary, and claims milizacent indexing for an average repository, sub-milizacent queries, and 99% fewer tokens. Those performance figures come from the project and still need outside confirmation. Nanobot supplies the agent shell while code-based memory MCP supplies structured repository memory. Prefects Fast MCP, at 26,989 stars, provides the Python construction layer for MCP servers and clients. Fast MCP shipped version 3.4 on July 27th, while code-based memory reached version 0.9 earlier in July. Together, they cover a useful chain, build a tool service, expose persistent code knowledge, and connect it to a self-hosted agent. And that's why the stateless transport change matters more than it first sounded. Nanobot has the strongest traction at more than 46,000 stars, but none of these projects lives alone. Agent shells, knowledge services, and tool servers need a shared connection contract if developers want to combine them without writing a custom adapter for every pairing. Star counts show attention, not reliability. The releases and continued repository activity show an ecosystem assembling around interoperable parts rather than one monolithic assistant. DeepSeq v4 Flash 0731 is newly available through OpenRouter with a context window of 1,048,576 tokens. It's a sparse mixture of experts model, meaning each input activates only part of the network, 13 billion active parameters out of 284 billion total. DeepSeq positions this repost-trained revision for coding, reasoning, and agent work. The million-token context specification is concrete, quality, speed, and cost still depend on the workload and independent results. Its active-to-total parameter split is central to that sparse-serving proposition. Moonshot's Kimmy K3 is the local spotlight as well as a headline model. Its hugging-face listing identifies a model that accepts images and text and returns text, with transformers and compressed tensor support. More than 9,100 likes and roughly 493,000 downloads show exceptional interest, while Unsloth's GGUF conversion makes quantized local execution more accessible through common runtimes. The attraction is private multimodal work. Images, screenshots, scans, and text can stay on controlled hardware. But the listing's custom code tag and other license deserve equal billing with the download count. Hardware needs, usable context, exact weight formats, benchmark conditions, and commercial permissions come from the model card, not popularity. Kimmy K3 is a substantial local AI release, not a promise that every consumer machine can run it comfortably. That makes deployment a hardware and licensing decision, not a popularity contest. The GitHub co-pilot in Visual Studio July update adds a new agent built on the co-pilot software development kit, with .NET and Azure expertise and more customization. The EU launches AI gigafactories called to boost Europe's computing capacity and unlock more than 30 billion euros in investment. One specializes help inside an editor, the other expands the infrastructure beneath European AI. UNID builds an AI-ready workforce in OpenAI's third item. The insurer combined chat GPT enterprise, leadership support, responsible governance, and employee-led experimentation. It's a vendor-authored case study, not independent proof of broad productivity gains. Together, the three items connect specialized software, physical compute, and organizational adoption without pretending they are the same kind of evidence. For primary source details, model cards, project repositories, and the research covered here, look at the show notes at tobyonfitnesstech.com. Those links are gathered in one place so you can inspect the evidence behind every claim and follow the projects directly. Thanks for listening to Agent Stack Daily. We'll be back soon. We'll be back soon.