Infrastructure Software Watch: Google Open-Sources AX as Oracle Scales Infra for 1,000 AI Agents
Watch Tech Series · Infrastructure Software Watch | September 24, 2026
The latest infrastructure software developments across cloud, Kubernetes, observability, AI infrastructure, and autonomous infrastructure operations.
Infrastructure software is increasingly being redesigned around AI-scale workloads and autonomous operations.
The important shift is from infrastructure that merely runs applications to infrastructure software that can understand, optimize, and increasingly operate those environments. Today’s edition covers six developments: Google’s open-source AX orchestrator for autonomous agents, Oracle’s demonstration of 1,000-agent infrastructure, an observability integration for cross-layer root-cause analysis, Alibaba Cloud’s 20GW datacenter expansion, Microsoft’s AI-assisted Copilot runtime migration to Rust, and Empirik’s $21M round for autonomous infrastructure engineering.
1. Google Open-Sources AX for Autonomous AI Agents
Source: InfoQ
Google has open-sourced AX, a Kubernetes-style orchestrator designed specifically for autonomous AI agents. InfoQ reported the development on September 22.
The core problem AX addresses is that AI agents are not like conventional applications. They have different orchestration requirements across four dimensions:
| Dimension | Why Agents Differ |
|---|---|
| Identity | Agents act on behalf of users and systems, requiring delegated permissions and traceable ownership. |
| State | Agents maintain memory across steps, sessions, and tasks — not just ephemeral request state. |
| Scheduling | Agent workloads are bursty, long-running, tool-dependent, and often waiting on external calls. |
| Resource management | Agents need access to models, tools, APIs and data within controlled boundaries. |
By extending Kubernetes concepts toward agent workloads, AX treats agent infrastructure as a first-class orchestration problem rather than a workload that runs inside a container. That framing matters: Kubernetes was designed for stateless and stateful applications, not for entities that reason, act, and persist identity across time.
What It Means: The infrastructure stack may need to evolve from container orchestration → workload orchestration → agent orchestration. If that evolution is real, cloud providers and Kubernetes vendors will need to add agent-native primitives to their platforms — or risk having agent workloads managed by a competing layer.
The CODEW Lens: Kubernetes was not built for agents. The question is whether it will be extended to run them — or whether agent infrastructure becomes its own category.
2. Oracle Demonstrates Infrastructure for 1,000 AI Agents
Source: Oracle Cloud Infrastructure
Oracle published a technical demonstration showing how 1,000 AI agents can be deployed using Oracle Cloud Infrastructure Kubernetes Engine and File Storage. The architecture emphasizes preserving agent identity, state, and access boundaries as agent populations scale.
The demonstration is a useful counterpoint to the AX announcement. Where AX asks what an agent-native orchestrator should look like, Oracle’s work shows what it takes to scale agents on today’s Kubernetes-based infrastructure — and where the limits appear.
Three infrastructure requirements become non-optional at scale:
| Persistent state | Each agent needs memory that survives restarts, migrations, and tool calls. Stateless execution does not work. |
| Identity and access control | Each agent needs a distinct identity, scoped permissions, and audit trails — the same requirements that apply to human users. |
| Storage | Shared file storage becomes a coordination layer when agents need to read and write against common data. |
What It Means: The infrastructure challenge is not simply compute. Coordination, state, and permissions become infrastructure primitives. Running one agent is a demo. Running a thousand is an infrastructure problem that requires treating identity, storage, and scheduling as first-class concerns rather than application-level workarounds.
The CODEW Lens: At 1,000 agents, the hard problems are not compute. They are state, identity and coordination — the same problems distributed systems have always had, now applied to entities that reason.
3. Observability Moves Toward Cross-Layer Root-Cause Analysis
Source: ChannelLife UK
Percona and Coroot announced an observability integration connecting database monitoring with application, network, and infrastructure telemetry. The combined approach is designed for distributed and cloud-native environments, including Kubernetes.
The integration addresses a fragmentation problem that has persisted through the container era. Application monitoring, infrastructure monitoring, and database monitoring evolved as separate disciplines with separate tools. When something breaks, engineers are left correlating signals across systems that were never designed to talk to each other.
OpenTelemetry provided a partial answer by standardizing telemetry collection across services. But database-level observability — query performance, connection saturation, lock contention, replication lag — remained largely outside the cross-layer correlation loop. Percona and Coroot’s integration brings database telemetry into that loop.
AI workloads increase observability complexity for a structural reason: the boundary between what is compute, what is storage, and what is a model call is less clear. An agent waiting on a tool call, a model waiting on a vector lookup, and a database waiting on a lock can all present the same symptom — elevated latency — while requiring entirely different remediation.
What It Means: The observability market is moving beyond dashboards toward correlation and automated diagnosis across the entire stack. As AI workloads spread, vendors that can correlate signals across application, infrastructure, and data layers — and increasingly act on that correlation — will compete on a different axis than traditional monitoring tools.
The CODEW Lens: Observability is becoming less about seeing each layer and more about seeing the whole system. AI workloads make that transition urgent rather than optional.
4. Cloud Infrastructure Is Being Built Around AI Scale
Source: The Register
Alibaba Cloud has announced plans to expand its global datacenter capacity to 20GW, alongside its new Zhenwu V900 AI processor. The Register reported that Alibaba subsequently announced additional cloud-region expansion plans in Türkiye, Finland and the Netherlands, alongside expansion in several existing markets.
The dual announcement — custom silicon plus datacenter capacity — reflects how cloud providers are responding to AI’s effect on infrastructure economics. Datacenter capacity has become a strategic asset rather than a cost line. Power, land, cooling and interconnection now determine how fast a cloud provider can grow AI capacity, independent of software capability.
The Zhenwu V900 continues a pattern that has become common across hyperscalers: designing silicon for specific AI workloads to reduce dependence on external chip suppliers and to optimise cost per token at scale. The geographic expansion — into new regions and deeper into existing ones — is aimed at data residency, latency, and sovereign infrastructure requirements that have become purchasing criteria for enterprise and government customers.
What It Means: Infrastructure software increasingly exists inside a much larger system: chips → data centers → cloud platforms → orchestration → applications. The providers that will control the AI era are not just the ones with the best software. They are the ones that can align silicon, capacity, platform, and orchestration into a coherent system.
The CODEW Lens: Datacenter capacity is now a strategic asset. The cloud infrastructure race is being decided as much by power and land as by software.
5. AI Is Starting to Rewrite Infrastructure Software Itself
Source: The Register
Microsoft’s migration of its Copilot runtime from TypeScript to Rust provides a useful case study in AI-assisted infrastructure engineering. The Register reported that AI agents handled much of the conversion, covering roughly 430,000 lines of TypeScript and producing about 800,000 lines of Rust over the project. The effort also encountered regressions that required engineering oversight.
The migration reflects several infrastructure-engineering realities:
| Language choice | Rust offers predictable performance, lower memory overhead, and better startup characteristics than TypeScript runtimes. |
| Resource density | At hyperscale, per-instance memory and CPU costs compound. Lower-overhead runtimes change the economics of serving models to many users. |
| AI-assisted engineering | Agents performed substantial code generation and translation work, reducing the mechanical cost of a large migration. |
| Validation | Regressions appeared during the migration, confirming that AI-assisted engineering still requires human review, testing, and architectural judgment. |
What It Means: AI isn’t only changing what infrastructure runs. It is beginning to change how infrastructure software is built. Migrations that were once economically impractical because of sheer code volume become feasible when agents handle the mechanical translation. That lowers the cost of infrastructure modernization — and raises the importance of engineering teams that can review, test, and make architectural decisions.
The CODEW Lens: The scarce resource in AI-assisted engineering is not code generation. It is verification and judgment.
6. The Emerging Autonomous Infrastructure Layer
Source: TechCrunch
Empirik raised $21 million after being incubated by Sequoia, with a product designed to track infrastructure changes, understand dependencies, and identify potentially dangerous changes before they cause outages. TechCrunch describes the company as targeting infrastructure engineering with an autonomous approach.
Empirik is a supporting example rather than the main story, but it illustrates a category that is forming: infrastructure software that does not simply display the current state of systems, but reasons about what changes are likely to cause problems and intervenes before those problems occur.
Traditional monitoring answers the question: what is happening right now? The emerging category answers a different set of questions, in sequence:
| Observe | See the state of the system and its changes over time. |
| Understand | Model dependencies between services, infrastructure, and data. |
| Predict | Identify changes that are likely to cause outages or degradation. |
| Recommend | Suggest actions to prevent problems or mitigate risk. |
| Act | Execute remediation within defined controls. |
What It Means: This points toward a new infrastructure software category. Observe → Understand → Predict → Recommend → Act is materially different from traditional monitoring. The vendors that own this layer will sit closer to operational outcomes than to dashboards — and will increasingly compete on judgment, not visibility.
The CODEW Lens: Monitoring tells you what broke. The next category tells you what is about to break — and increasingly, prevents it.
The Infrastructure Software Shift
Infrastructure software is entering an AI-native phase. Kubernetes is being extended toward autonomous agents, observability is moving toward cross-layer correlation, cloud providers are designing infrastructure around massive AI workloads, and AI itself is beginning to participate in infrastructure engineering.
The strategic question is therefore shifting from who provides the infrastructure to who controls the software layer that coordinates increasingly autonomous workloads across that infrastructure.
Today’s six developments each touch a different part of that shift:
| Development | Layer of the Stack |
|---|---|
| Google AX | Agent orchestration as a new infrastructure category |
| Oracle 1,000 agents | State, identity and coordination as infrastructure primitives |
| Percona + Coroot | Cross-layer observability and correlation |
| Alibaba Cloud | Chips, data centers and cloud platform as one system |
| Microsoft Rust migration | AI-assisted engineering of infrastructure software itself |
| Empirik | Autonomous infrastructure operations layer |
The CODEW Lens: The infrastructure market is not simply growing. It is being reorganized around a new set of primitives — agent identity, persistent state, cross-layer correlation, autonomous remediation — that did not exist as first-class concerns five years ago.
Sources
→ InfoQ — Google open-sources AX, a Kubernetes-style orchestrator for autonomous AI agents
→ Oracle Cloud Infrastructure — Scaling 1,000 AI agents on OKE and File Storage
→ ChannelLife UK — Percona + Coroot expand observability across databases, applications, networks and infrastructure
→ The Register — Alibaba Cloud’s 20GW datacenter expansion and Zhenwu V900
→ The Register — Microsoft’s AI-assisted Copilot runtime migration to Rust
→ TechCrunch — Empirik’s autonomous infrastructure engineering platform and $21M funding
Next in Infrastructure Software Watch
→ Agent Orchestration: Will Kubernetes Extend or Be Replaced?
→ Cross-Layer Observability in AI-Native Environments
→ Autonomous Infrastructure Operations: The Emerging Category
The CODEW Stat
6 developments · 1,000 agents · 20GW planned capacity · 5 layers of the infrastructure stack Today’s infrastructure software developments touched every layer of the AI-native stack: agent orchestration (Google AX), agent-scale primitives (Oracle’s 1,000-agent demonstration), cross-layer observability (Percona + Coroot), cloud and silicon infrastructure (Alibaba Cloud’s 20GW and Zhenwu V900), AI-assisted infrastructure engineering (Microsoft’s Rust migration), and autonomous operations (Empirik, $21M). Together they point to a single structural shift: infrastructure software is being reorganized around new primitives — agent identity, persistent state, cross-layer correlation, autonomous remediation — and the competitive question is shifting from who provides the infrastructure to who controls the software layer that coordinates increasingly autonomous workloads across it.
Editorial Note
The CODEW Infrastructure Software Watch examines the developments reshaping the software layer that controls, orchestrates, observes, and increasingly autonomously operates modern computing infrastructure—including Kubernetes, orchestration, observability, infrastructure-as-code, automation, and AI-powered operations.
Educational content only. Not investment or business advice. Analysis is based on company announcements, official product disclosures, technical documentation, and reporting from InfoQ, Oracle Cloud Infrastructure, ChannelLife UK, The Register, and TechCrunch. Metrics referenced are labeled as reported, calculated, or CODEW-derived. Some products referenced may be affiliate partners — see our Affiliate Disclosure for full details. Platform coverage, data sources, and methodologies can change as the intelligence platform evolves.
Reviewed by Erwin Castro
on
Thursday, September 24, 2026
Rating:
.jpg)