News · · 10 min
Period: September 7 — morning of September 8.
One line is clearly visible today: the agent stack is maturing from both sides at once. From the bottom — more compute and hardware independence. From the top — more isolation, policies, audit trails, and limited autonomous workflows.
Australian company Firmus has signed a multi-year contract with OpenAI for capacity in two data centers in Malaysia. After this deal, Firmus's total contracted capacity exceeded 900 MW. In its Asian data centers, the company plans to deploy the next generation of Nvidia chips — Vera Rubin — at scale. The contract value was not disclosed.
Why this matters. Frontier labs are increasingly buying compute not as a regular cloud resource, but are instead reserving physical infrastructure years in advance. This continues yesterday's trend: model competition is also turning into competition for electricity → datacenters → accelerators → networking.
What the data shows: >900 MW contracted capacity at Firmus after the deal; five of the company's new sites are under development across APAC. OpenAI's specific share within this 900 MW was not separately disclosed.
What you need to already understand: GPU cluster, Vera Rubin, inference capacity, MW, capacity reservation.
What this could change. For a regular engineering team — just observe for now. For businesses, the long-term takeaway is more important: the availability and economics of frontier inference increasingly depend on the infrastructure deals of a specific model provider, not just the model's own efficiency.
Date: September 8. Source: Reuters — OpenAI/Firmus Malaysia deal
Alibaba Cloud and Cambricon became Platinum members of the PyTorch Foundation; Ant Group became a Gold member. Simultaneously, Huawei, Cambricon, Alibaba, and Ant are presenting a common full-stack story at PyTorch Conference China: Qwen serving, hardware/software co-design, device-agnostic PyTorch, and secure runtimes for agents. More than 250 organizations from China are already participating in PyTorch Foundation projects, including PyTorch, vLLM, Ray, DeepSpeed, and Safetensors.
Cambricon's participation is especially interesting: the company will work on extending PyTorch so that alternative hardware backends receive more native support. Huawei is similarly promoting Ascend as a full-fledged PyTorch platform.
Why this matters. One of Nvidia's strongest lock-ins is not just CUDA, but the entire accumulated software experience around it. If PyTorch becomes truly device-agnostic, it becomes easier for alternative accelerators to compete without requiring the entire ML stack to be rewritten.
The causal chain here is quite obvious:
alternative AI chips → proper support in PyTorch → easier to port models → more competition in inference/training → potentially lower infrastructure lock-in.
What you need to already understand: CUDA, PyTorch backend, device abstraction, vLLM, hardware/software co-design.
What this could change. For now, don't choose Cambricon or Ascend just because of an announcement. But for businesses with very large inference bills, it's worth already treating hardware portability as a potential architectural advantage.
Date: September 8. Primary Source: Linux Foundation / PyTorch Foundation announcement
GitHub Agentic Workflows released v0.88.4. Most of the changes have nothing to do with agent "intelligence": the team is strengthening the isolation and policy layer around them.
The release introduced finer-grained sensitivity controls for trusted enclaves and automatic generation of data-flow integrity/confidentiality policies for workflows running via GitHub Apps. In parallel, GitHub is transitioning its agent workflow fleet to Cloud Hypervisor-based microVMs and adding dynamic repository-level enclave policies.
Why this matters. This is almost a textbook progression for production agents:
give the model tools
→ realize tool access is dangerous
→ network firewall
→ process isolation
→ microVM
→ data-flow policy
→ dynamic permissions.
The more autonomous the agent, the more its runtime starts to resemble infrastructure for executing untrusted code.
What the data shows. This is production/open-source engineering evidence from GitHub, not a benchmark. Changes are happening simultaneously across firewall, sandboxing, enclave delegation, and safe-output handling — meaning security is already a separate architectural layer of the project.
What you need to already understand: microVM, sandbox, trusted enclave, data-flow policy, least privilege.
What this could change. If a production agent runs shell/browser/code and has credentials, "we have a sandbox" is already too coarse an answer. Separate policies are needed for network, secrets, filesystem, tool calls, and data allowed to be extracted.
Date: September 7. Primary Source: GitHub Agentic Workflows — weekly update
GitHub published the story of the Dead Code Removal Agent — a scheduled agent that runs a Go static analyzer, removes unreachable code, and creates a small PR.
The last five runs look much more interesting than a typical demo: three ended in agent-logic failure, two succeeded. The last successful run took 19 minutes and 19,398 tokens, removed five functions and their corresponding tests, and created a diff for only four files. The PR was then merged by a human.
GitHub intentionally limited the workflow to a maximum of five functions per run. Previous successful PRs are roughly the same small size.
Why this matters. This is a good production counterpoint to the idea of "let the agent independently rework the entire repository."
Reliability can be increased not necessarily by a smarter model, but by changing the unit of work:
small task → deterministic discovery → limited diff → tests → reviewable artifact → human merge.
Three failures out of five here don't look catastrophic because failure means "PR not created," not "bad code silently went to production."
What you need to already understand: static analysis, bounded autonomy, CI, pull request, fail-safe.
What this could change. For initial production coding-agents, it's better to look for narrow, repeatable workflows with a cheap failure mode rather than starting with autonomous end-to-end feature development.
Date: September 7. Primary Source: GitHub — Dead Code Removal Agent
Today Mistral announced a round of €3 billion at a post-money valuation exceeding €21 billion (~$24 billion). Samsung Electronics became the lead investor; co-leads include the Scaleup Europe Fund and PSG Equity. The funds are intended for frontier research and development of Mistral's infrastructure.
Mistral's CFO also told Reuters that the company expects to reach approximately $1 billion ARR by year-end and already has over 125 customers.
The company's wording on sovereignty is especially interesting. Mistral sells not only models but the ability to download an open-weight model, customize it, and run it on your own infrastructure. Management directly links this to the risk of political or commercial restrictions on access to foreign models.
Why this matters. Open weights is turning from a developer preference into an enterprise procurement argument:
model
→ can it be downloaded
→ can we switch compute provider
→ can we fine-tune
→ can the vendor shut off our API
→ is AI part of supply-chain risk.
What the data shows: €3 billion funding, >€21 billion valuation, >125 customers, stated trajectory to $1 billion ARR. The funding is confirmed by the company; ARR is a CFO statement, not an audited financial result.
What you need to already understand: open-weight model, self-hosting, data sovereignty, vendor lock-in, ARR.
What this could change. For companies where AI becomes a critical part of the product, it makes sense to discuss an exit strategy from the model provider even before the need to actually leave arises.
Date: September 8. Sources: Reuters — Mistral funding
Nous Research released Hermes Agent v0.21.1. The patch release itself doesn't contain one big feature, but it does show the project's scale of development well: since v0.21.0, there have been 5,139 non-merge commits, 4,364 changed files, and 632 merged PRs.
Work is proceeding simultaneously on memory/state, MCP authorization, browser annotations, scheduling, model providers, desktop sessions, and delegation reliability.
The signal. Open source is increasingly answering not "how to call an LLM," but:
how an agent lives long → how it stores state → how it delegates → how it authorizes → how it schedules → how it survives model/runtime changes.
This confirms the trend of recent days: the persistent agent is gradually becoming its own software runtime.
What you need to already understand: persistent agent, MCP authorization, delegation, agent state, scheduler.
What this could change. For now, observe as an architectural reference. For production, the set of problems Hermes is forced to solve is more important than the specific choice of this framework.
Date: September 7. Source: Hermes Agent v0.21.1 release
The stack is increasingly diverging in two directions at once: models and compute are becoming more accessible on more hardware, but the agent runtime is becoming more complex and stricter.
That is, openness at the bottom — PyTorch backends, open-weight models, alternative compute — is accompanied by a growing number of control mechanisms at the top: microVM, firewall, enclaves, permissions, deterministic tooling, and small, reviewable actions.
And this is a quite logical causal connection: the easier it is to give a powerful model access to real infrastructure, the more important the engineering of constraints around it becomes.
If our primary model provider becomes too expensive or unavailable tomorrow, how difficult would it be for us to switch models or self-host open weights?
What exactly does our "sandbox" mean: a separate process, a container, or a full-fledged microVM — and what data/credentials are still accessible to the agent?
Can we limit initial autonomous coding workflows to small, reviewable PRs instead of large end-to-end tasks?
Should we consider hardware portability when designing large inference workloads already, even if everything runs on Nvidia today?
Do our persistent agents have explicit policies for inter-agent access, secrets, outbound network, and shared state?