This week at a glance
This was a good week for evidence, which is not the usual verdict in this section. Three engineering organisations published numbers from production systems, and all three are about the same thing: what it costs to run agents, and what you do about it. Uber operates more than 1,000 MCP servers behind a single gateway, and found that pre-loading roughly 100 tool schemas into the agent context burned 50,000–70,000 tokens before any work began. Removing schema pre-loading entirely — replacing it with CLI resolution, on-demand tool search and code-mode batching — took that to “near-zero per session”, and between February and August 2026 weekly agent requests rose 9.4x while total spend stayed roughly flat from April onward; cost per 1,000 agent requests fell about 34% and cost per session about 52% from its peak. DoorDash published the first hard accuracy-and-cost figure for agentic code maintenance we have seen: across a 50-flag evaluation, 45 of 50 (90%) produced usable pull requests, 31 merged first-pass, zero bugs or regressions were recorded, and the average cleanup cost 13.8 minutes and $4.79 against a manual baseline of one to two engineer-hours. And Lyft moved hundreds of production Flink jobs onto the community Kubernetes operator and credits the autoscaler with right-sizing a fleet that had been overprovisioned by “a few million dollars per year”. Note what all three have in common: the win came from removing something — schemas, dead flags, spare capacity — not from a better model.
The counterweight is AWS, and it is the most consequential operational story of the week. On 15 September AWS confirmed it cannot restore resources and data hosted exclusively in its Bahrain region after Iranian drone attacks in March 2026 and a secondary disruption in April; in the UAE region one availability zone is back and two are not. AWS’s own wording is the part to read twice — the damage “spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand”. Multi-AZ was not the answer, and customers who did not move after March are the ones who lost data in April. Elsewhere, label the sourcing before you quote it. The Splunk .conf26 bundle is one announcement told three times across this issue and Agentic NetOps, and all its capability claims are Cisco’s; the Azure SRE Agent piece is a Microsoft-sponsored post whose 1.8 million incidents and 3,000 service teams are Microsoft’s own internal figures, with customer percentages that carry no stated baseline; the three-tier incident-response MTTR ranges are the author’s illustrative numbers, and the article says so itself; and the governance podcast write-up rests on theCUBE Research’s own survey plus an unnamed anecdote about 8,000 discovered agents. Meanwhile Vercel’s gateway telemetry shows open-weight models crossing 56% of tokens in August while Anthropic still takes about 64 cents of every dollar — a volume-versus-spend split worth understanding before anyone tells you open weights have won.
On our watch list
- Whether Uber’s three anti-schema mechanisms show up in anyone else’s numbers. CLI tool resolution, on-demand tool search and code-mode batching are transferable to any MCP gateway, and the claimed result — near-zero schema tokens per session with 9.4x more agent requests on flat spend — is large enough to be worth reproducing. Watch for a second organisation publishing its own before-and-after cost per 1,000 agent requests rather than a vendor repeating Uber’s.
- Whether the vendors whose MCP servers ship 30–50 tools start trimming them. Uber found third-party servers were the worst offenders: a workspace suite exposing 49 tools for about 22K tokens of schema, a messaging vendor 34, a project tracker 46. Watch whether vendors begin shipping scoped or lazily loaded tool catalogues, because until they do, the fix stays on the customer’s side of the gateway.
- Whether DoorDash’s 90% pass rate survives contact with someone else’s codebase. The work was accepted to the ICSME 2026 industry track, so the method will be public and checkable. The hard case is already named — dependency-injected wrappers spreading a flag across 5 to 20 files, the reason Uber’s AST-based Piranha did not work. Watch for a replication that reports its own merge rate by complexity, not just a headline percentage.
- Whether Anthropic’s spend share on Vercel’s gateway finally breaks below 61%. It has not done so in any month since December 2025, even as open-weight token volume went from 7% to 56%. These are Vercel’s own gateway numbers and skew toward web developers and coding agents, so watch the September and October reports for the spend line specifically — token share moving is not the same event as spend share moving.
- The Splunk GA dates that have not landed yet. Agent Observability with Tokenomics, the Network Intelligence App and Cisco AI POD for Splunk were dated 15 September 2026; Observability and Enterprise Security integration is promised for end-2026, FedRAMP coverage for January 2027, Splunk Enterprise on-prem for later in 2027, and Agent Launchpad later this year. No pricing has been disclosed for any of it. Watch the dates slip or hold before you build a 2027 plan on them.
- Whether MCP’s governance actually stays plural. The protocol has 40+ maintainers with fewer than 25% at Anthropic, tier-1 SDKs pulling roughly 500 million downloads a month, and a home at the Linux Foundation’s Agentic AI Foundation since December 2025. That maintainer ratio is the number to re-check in six months if you are betting infrastructure on the protocol.
- Whether anyone publishes agent-identity numbers with a named source behind them. This week’s most-quoted governance figure — 8,000 agents discovered inside one engineering organisation — is an anecdote with no organisation attached, sitting next to survey findings from theCUBE Research’s own panel. Watch for a discovery count published by the organisation that ran the discovery.
- Whether BlueGreen deployment closes Lyft’s redeploy window. Stop-then-start redeploys cost 3–6 minutes on a typical job and about 20 minutes on the largest. BlueGreen mode arrived in Flink Kubernetes Operator 1.14.0 on 15 February 2026, and Lyft has already found and reported one bug in it. Watch for published before-and-after downtime from a fleet running it in anger.
- Whether Karmada’s graduation produces adopter numbers. The CNCF announcement lists Bloomberg, Trip.com, Alibaba Cloud, Huawei, Bilibili, iFLYTEK and others by name and gives no cluster, node or pod counts for any of them. Watch for the first adopter to publish multi-cluster scale figures, because 1,214 contributors tells you about the project and nothing about the deployments.
- Whether the sponsored SRE-agent figures ever get a baseline. Microsoft’s own internal numbers — 1.8 million+ incidents handled, 3,000+ service teams, more than 50% of incidents autonomous for some teams — are the largest deployed dataset in this category. The customer percentages beside them (80% less investigation time, 84% lower cost) state no baseline at all. Watch for a customer publishing the before number.
- Whether monitoring overhead on agent inference gets measured independently. The claim in circulation is roughly 20% added inference compute for persistent agent monitoring, sourced this week to an Nvidia product executive rather than a benchmark. If agent observability costs a fifth of your inference bill, that belongs in the business case — watch for a figure from someone not selling the runtime.
This week’s topic map — token economics anchors the upper centre, wiring Uber and context hygiene to the Model Context Protocol and Vercel’s gateway to open-weight models, Anthropic and Claude Opus 5. Splunk and Cisco sit to the right through Agent Observability, Tokenomics, Token Meter and the AI POD; agent governance runs through the centre via agent identity, runtime guardrails, WSO2 Agent Manager and StackGen Aiden OS. The Kubernetes platform cluster fills the lower right with Karmada, CNCF, TauGrid, GPU scheduling and Lyft’s Flink operator and autoscaler; AWS, Bahrain and the UAE anchor multi-region resilience on the left beside long-running incidents; and a vendor-sourced-numbers node ties the sponsored and contributed rows together, because that is where most of this week’s percentages come from.
View interactive topic map →
Article index
25 articles, grouped by sub-theme. Nineteen are from this week’s coverage window (September 14–20); six are longer-form foundational reads on the beat. Sponsorships, contributed posts and author affiliations are named in each group.
Token economics as an operations discipline
The through-line of the week: token spend is now a line item with an owner, and the levers are context hygiene, model routing and per-session attribution. Uber’s and Vercel’s figures come from their own production systems — Vercel’s are gateway telemetry, not a market-wide measurement. The three Splunk rows are vendor announcements: the Network World piece is a press-release rewrite and every capability claim in it is Cisco’s, and the SiliconANGLE roundup is five separately-sourced keynote sections rather than one argument.
Agents doing real operations work, with a measured pass rate
Three items on agents performing maintenance and incident work, and only one of them has an independently reported cost-and-accuracy figure. The Azure SRE Agent post is sponsored by Microsoft Azure and every number in it is Microsoft’s own; its customer percentages carry no stated baseline. The three-tier piece is a contributed post whose MTTR ranges are the author’s illustrative figures — the article itself calls them directional.
Governing agent sprawl: identity, policy and the control plane
The category that produced the most announcements and the fewest numbers. The MCP status report is the substantive item; the WSO2 and StackGen rows are press-release rewrites with no adoption figures; the governance piece is a write-up of a podcast whose two guests both sell into this space; and the harness explainer is a single-source Q&A, not a market survey.
Observability that diagnoses rather than displays
The common mechanism across this group: normalise metrics, logs and traces into one anomaly representation and correlate over the topology graph. Atlassian’s is the most mechanically detailed write-up of the week and carries no time-to-diagnosis baseline; the Splunk model announcement names no parameter count, licence or release date; the O’Reilly essay is argument rather than data and says so.
Platform plumbing for AI workloads
Where the AI workload actually runs: a streaming fleet moved onto a community operator, a multi-cluster scheduler graduating, a GPU workload manager open-sourced, and a storage platform making room for AI by spending less power on what it already runs. Note that the InfoWorld headline oversells its subject — the story is an open-source, self-hosted application, not an AWS product bet.
When the redundancy design is the thing that failed
Two failures that healthy components and correct multi-AZ design did not prevent, and one of them is permanent. The AWS reporting is built on the status page rather than a post-incident review, so no service list or customer count exists yet. The InfoQ item is a recorded QCon San Francisco presentation with a transcript, not a written article.
Ops culture and the AI-native transition
What changes in an engineering organisation when agents do the work, and why an agent failure is usually not a model failure. Both pieces rest on single interested sources — an Nvidia product executive in one, a keynote anecdote in the other — so take the framing and leave the percentages.
Detailed write-ups
1. Uber deleted the tool schemas and the agent bill stopped growing
The Stack · September 16, 2026
The most useful engineering story of the week is about removing something. Uber runs more than 1,000 MCP servers behind a single unified gateway, and at the outset roughly 100 tools were installed into the agent context by default. Those schemas alone cost 50,000–70,000 tokens of context before the agent did any work — paid on every session, for tools most sessions never called. Uber’s answer was not a smaller model or a bigger context window. It stopped pre-loading schemas at all, and reports the cost of doing so as “near-zero per session”.
Three mechanisms replaced pre-loading, and all three are portable. CLI tool resolution lets the agent invoke a shell command at the moment of need rather than carrying a definition in case it is needed. Tool search is an on-demand catalogue lookup that loads only the relevant definition. Code-mode batching has the model write a script, a subprocess execute it, and only a summary return to the context window — which is the one that changes the shape of the cost curve, because the intermediate output never enters the context at all. The workloads in scope are ordinary operations work: code review, self-healing CI failures, end-to-end PR completion with visual validation, on-call alert triage and bug debugging.
The part worth taking to a budget conversation is the trend line. Between February and August 2026, weekly active users of Uber’s AI coding tools rose 7x and weekly agent requests rose 9.4x, while total spend stayed roughly flat from April onward. Cost per 1,000 agent requests fell about 34% and cost per session about 52% from its peak. Uber is explicit about where the problem originated, and it is a warning for anyone assembling an agent platform from vendor connectors: third-party MCP servers were the worst offenders, because vendors expose their full product surface — a workspace suite shipping 49 tools for about 22K tokens of schema, a messaging vendor 34 tools, a project tracker 46. Uday Medisetty, a distinguished engineer at Uber, puts it plainly: “Managing third-party software proved significantly more challenging than our internal servers. Vendors design MCP servers to expose full product capabilities.”
Sources: The Stack (1,000 MCP servers, zero schema bloat?) — https://www.thestack.technology/1-000-mcp-servers-zero-schema-bloat-ubers-assault-on-ai-costs/
2. DoorDash put a number on agentic code maintenance: 45 of 50, $4.79 each
InfoQ · September 18, 2026
DoorDash carries more than 60,000 feature flags across 623 repositories and creates roughly 2,300 new flags every month; over 1,000 were classified stale, meaning unmodified for 90 days, still referenced in code, and neither archived nor explicitly excluded. This is the kind of debt that never wins a sprint planning argument, which is exactly why it is a good test of whether agents can do maintenance work at a quality you would accept from a person.
The architecture is the interesting half. Phase one runs Claude Sonnet on Google’s Agent Development Kit: it pulls the stale-flag Jira ticket, searches the repositories and queries the experimentation platform over MCP. A human engineer then reviews the report and confirms the flag’s target value — and only then does phase two run Claude Opus agents in isolated Git worktrees, capped at four concurrent agents per repository, with a one-hour timeout per agent and Gradle run without the daemon so agents cannot share build state. A pull request opens only after build, tests, JaCoCo patch coverage and Detekt static analysis all pass. The confirmation step and the isolation are doing as much work here as the model choice.
The results are the first properly reported accuracy-and-cost figures for this kind of work. Across a 50-flag evaluation, 45 of 50 (90%) produced usable pull requests: 31 merged first-pass, 14 needed revision and 5 required engineer intervention. Zero bugs or regressions were recorded across the 50 changes. Single-pass merge rate degraded predictably with difficulty — 100% simple, 94% medium, 85% complex — and the average cleanup took 13.8 minutes and $4.79 against DoorDash’s own baseline of one to two hours of manual engineer time per flag. The failure mode is named too: dependency-injected wrappers that spread a flag’s definition, client calls and business logic across 5 to 20 files, which is why Uber’s AST-based Piranha tool did not work for this codebase. The work has been accepted to the ICSME 2026 industry track, so the method will be checkable rather than merely quotable.
Sources: InfoQ (DoorDash uses multi agent LLMs to clean up 60,000 feature flags) — https://www.infoq.com/news/2026/09/doordash-feature-flag-cleanup/
3. Open weights took the tokens; Anthropic kept the money
The New Stack · September 18, 2026
The single most useful chart in this issue is a volume-versus-spend split. On Vercel’s AI Gateway, open-weight models’ share of token volume went 7% in December 2025, 13% in April 2026, 36% in July, 56% in August — the first month they crossed a majority, with a single-day record of 62% on 22 August. And yet in that same August, open-weight models took about 14 cents of every dollar spent while Anthropic took about 64 cents. Anthropic’s spend share has not dropped below 61% in any month since December 2025. If your AI cost reporting tracks only token share, it is telling you a story your invoice does not support.
Underneath the headline the mix is moving fast. Within Anthropic’s August spend share, Claude Opus 5 accounted for 22.5% and rose month-over-month, while Claude Fable 5 fell to 4.9% from 13.2% in July — 90% of teams using Fable cut their usage, and Opus picked up nearly twice the volume Fable lost. Average price per token on the gateway fell 23.2% in August, a third consecutive monthly decline, and for teams that processed 10M+ tokens in both months the median cost per token fell 7.6%. On the challenger side, Z.ai’s GLM-5.3-Flash reached 3x the daily volume of GLM-5.2 within five days of launch, and Google’s Gemini 3 Flash lost 22 of 25 percentage points of Google’s overall share, with more than 75% of that volume going to competitors rather than to other Google models.
Two cautions before this goes into a slide. First, every figure here is Vercel’s own gateway telemetry, not a market-wide measurement; the gateway skews toward web and JavaScript developers and toward coding agents, so the right phrasing is always “on Vercel’s AI Gateway”. Second, Vercel’s chief executive Guillermo Rauch is describing a transition he expects to continue: “This is very likely just the start, because enterprise adoption is still early, and harnesses, CLIs, IDEs, SDKs, etc need to be adapted to be model agnostic.” That is the operational point for platform teams — the constraint on routing cheaper models is tooling that assumes one provider, and it is yours to fix.
Sources: The New Stack (open-weight models now handle a majority of tokens on Vercel’s AI Gateway) — https://thenewstack.io/open-weight-anthropic-spend/
4. Cisco puts Splunk AI on-premises and starts metering the tokens
Network World · September 15, 2026
Five named pieces arrived or were pre-announced at .conf26, and the framing is consistent: instrument the AI stack the way you instrument an application, then charge for it. Cisco AI POD for Splunk is an on-premises and air-gapped AI runtime on Nvidia accelerated compute with a Kubernetes architecture, available now as part of Cisco Secure AI Factory. Splunk Agent Observability with Tokenomics instruments GPUs, vector databases, agent memory and orchestration frameworks rather than only the application, and applies runtime guardrails intended to block hallucinated output and prompt injection before it reaches a user. Observability Studio embeds OpenTelemetry instrumentation into the development workflow. The Network Intelligence App pulls Cisco network topology, device health and events into Splunk so network state sits beside application telemetry. Agent Launchpad, a custom agent builder, is expected later in 2026.
Tokenomics is the piece with the clearest operational job: track and attribute token consumption in real time, route workloads to cheaper models, and forecast consumption before the billing period closes, delivered through Splunk Observability Cloud and Cisco Cloud Control. Read the rest with the sourcing in mind — this announcement is a press-release rewrite, every capability claim is Cisco’s, no pricing or licence terms were disclosed for any of the five items, and Cisco’s claim that instrumentation time drops “from hours to seconds or minutes” is published with no measured baseline for the “hours”. Jeetu Patel, Cisco’s president and chief product officer, gives the strategic line: “One of the biggest roadblocks to enterprise AI today is that it’s too hard to deploy.”
The keynote roundup is where the numbers live, and they are worth lifting with attribution because no other row carries them: agent token consumption overtook human consumption in February 2026 and is now 5x human volume seven months later; 60% of global AI compute is going to inference rather than training; a guardrail evaluator cut evaluation cost from about $1,000 a day to “a few dollars”; and Constellation Energy took mean time to detect and respond on a cloud-native identity incident from about 20 minutes to 39 seconds. Splunk data chief Kamal Hathi’s summary of the economics is the quotable one: “Capacity up 10x, bill flat.” Note that the roundup is five separately-sourced sections, not a single thesis. Splunk also open-sourced two things this week, both thin on specifics: a Token Meter CLI that reads local AI coding-agent trace files and prices them against public model rates — surfacing tokens per second, model wait time, input-versus-output split and budget alerts, with a read-only MCP server and support for Claude Code, Codex, Cursor, OpenCode, Kiro and Pi — announced with no licence, repository or availability date; and a second open-source LLM, a log-reasoning model to follow Cisco Time Series Model 1.0 for metrics, to be published on Hugging Face with no parameter count, benchmark, named licence or release date disclosed.
Sources: Network World (Cisco brings Splunk AI on premises) — https://www.networkworld.com/article/4222333/cisco-brings-splunk-ai-on-premises-expands-agent-observability-monitors-token-costs.html · SiliconANGLE (trust becomes the product: five takeaways from the Splunk .conf26 keynotes) — https://siliconangle.com/2026/09/16/trust-becomes-the-product-five-takeaways-from-the-splunk-conf26-keynotes/ · DevOps.com (Splunk open sources Token Meter tool) — https://devops.com/splunk-open-sources-token-meter-tool-for-application-developers/ · DevOps.com (Splunk preps second open source LLM for telemetry data) — https://devops.com/splunk-preps-second-open-source-llm-for-telemetry-data/
5. AWS says the Bahrain data is not coming back
The Stack · September 15, 2026
This is the disaster-recovery story of the year so far, and it is short. Iranian drone attacks in March 2026 damaged AWS infrastructure in both the Bahrain and UAE regions, and a secondary disruption in April 2026 took the Bahrain region out entirely. On 15 September 2026 AWS posted a status update confirming that it cannot restore resources and data hosted exclusively in Bahrain. That is permanent loss, not an extended outage. In the UAE region, availability zone mec1-az2 has been restored; az1 and az3 remain inaccessible.
The sentence that should end a lot of internal arguments is AWS’s own framing: the damage “spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand”. Multi-AZ redundancy is a design for component and facility failure inside a region. It is not a design for losing the region, and AWS has now said so in writing. The second lesson is about the window: customers who did not migrate out after the March attacks are the ones who lost data in April. There was time, and using it was a decision.
Two limits on what can responsibly be said about this. The reporting is built on the AWS Service Health status page rather than an interview or a published post-incident review, and no AWS spokesperson is quoted by name — the statement reads “After a thorough assessment, we have determined that we are unable to restore access to the resources and data hosted exclusively in [Bahrain]”, with the region name bracketed by the reporter. And the article does not name which services were affected and gives no customer or instance counts. For planning purposes that does not matter much: the actionable item is to find every workload whose only copy lives in one region, and that is an inventory question you can answer yourself this week.
Sources: The Stack (AWS: cloud instances in Bahrain, UAE might be lost for good) — https://www.thestack.technology/aws-cloud-instances-in-bahrain-uae-might-be-lost-for-good/
6. MCP grows up, and the agent-governance market rushes the gap
The Stack · September 18, 2026
The protocol underneath most of this issue now has scale numbers worth knowing. MCP’s tier-1 SDKs are pulling roughly 500 million downloads a month, more than 1 billion tool calls have been recorded through the Claude platform alone, and the protocol has 40+ maintainers with fewer than 25% of them at Anthropic. That last figure is the one that matters if you are betting infrastructure on it: MCP originated at Anthropic in late 2024 and was donated to the Linux Foundation’s Agentic AI Foundation in December 2025, and the maintainer spread is the evidence that the donation was more than a press release. The open engineering questions the report covers are multi-agent topologies, agent identity, and the overlap between MCP and adjacent protocols. Mazin Gilbert, executive director of the Agentic AI Foundation, makes the maximal claim — “You cannot deploy agentic applications at scale without MCP, that needs to become a central part of every deployment” — and it is worth remembering he leads the foundation that hosts it.
Around that protocol layer, three vendors shipped control planes this week and none of them published an adoption figure. WSO2 Agent Manager reached general availability on 18 September after a June beta: open source, a sandboxed Kubernetes-native runtime, 40+ built-in controls including PII masking and rate limiting, OpenTelemetry tracing, MCP and OAuth 2.0 extensions, and support for LangChain, CrewAI, Amazon Bedrock, Azure and Ballerina. StackGen’s Autonomous Operations Factory pairs Aiden OS — a shared environment record with policy enforcement and action logging — with an Aiden World Model knowledge layer over deployments, changes, failures and fixes, shipping four built-in agents for infrastructure ops, DevOps, SRE and observability, with custom agents inheriting the same governance. It is in preview on AWS, Azure, Google Cloud and Oracle Cloud, with a free community edition of the reliability agent and no disclosed pricing. Two ecosystem statistics circulating with that launch — AI attributed to roughly 10% of disclosed outages in 2026, and at least nine documented cases of agents taking destructive production actions independently — are published with no named source at all, so do not carry them into a risk register.
The conceptual vocabulary is settling at the same time, which helps. A harness is, in the useful definition offered this week, “what sits between the agentic code and the models themselves” — handling routing, access control, context management, evaluation and audit — with an accounts-payable workflow in which 10 to 15 different agents are presented to the user as a single agent. That comes from a one-source Q&A with a consultancy chief executive, not a survey of the category, so treat it as a definition rather than a market map. The same caution applies harder to the week’s “provable control” governance discussion: it is a write-up of a podcast whose two guests are both vendor executives with products in this space, and its figures — 47% of respondents operating across mixed connected and disconnected environments, 11% deploying generative AI in on-premises and air-gapped infrastructure, and 8,000 agents discovered inside one engineering organisation — come from theCUBE Research’s own survey and, for the 8,000, an anecdote with no organisation named.
Sources: The Stack (state of MCP) — https://www.thestack.technology/state-of-mcp-multi-agent-identities-and-overlapping-protocols/ · InfoQ (WSO2 releases Agent Manager) — https://www.infoq.com/news/2026/09/ws02-agent-manager/ · SiliconANGLE (StackGen launches Autonomous Operations Factory) — https://siliconangle.com/2026/09/15/stackgen-launches-autonomous-operations-factory-to-govern-production-agents/ · TechTarget (harnesses bring coordination and guardrails to enterprise AI agents) — https://www.techtarget.com/ai/news/366650281/AI-harnesses-bring-coordination-and-guardrails-to-enterprise-AI-agents · SiliconANGLE (AI governance shifts toward provable control) — https://siliconangle.com/2026/09/19/ai-governance-provable-control-agentic-ai-thecube-appdevangle/
7. Lyft gave up its own Flink operator and found the money in the autoscaler
InfoQ · September 16, 2026
Lyft migrated hundreds of production Apache Flink jobs off an in-house operator it had run since 2020 and onto the community Flink Kubernetes Operator, upgrading Flink 1.17 to 1.19 in the process. The version floor was not a preference: the Kinesis connector forced it, because flink-connector-aws 5.0.0+, from November 2024, requires Flink 1.19 or later. This is the ordinary shape of platform work — a dependency sets the deadline, and the migration you had been deferring becomes this quarter’s project.
The return came from a component most teams treat as a nice-to-have. Lyft attributes “a few million dollars per year” of savings to the operator’s autoscaler right-sizing a fleet that had been overprovisioned by roughly that amount — in the words of streaming engineers Maheep Myneni, Arda Kuyumcu and Prem Santosh Udaya Shankar, “The autoscaler is doing what we had hoped, which is right-sizing a fleet that had been overprovisioned by a few million dollars per year.” The catalogue of what the legacy operator lacked is the more transferable artefact: no savepoint retry logic, no idempotency, a single systemMemoryFraction knob covering all non-JVM memory overhead, and dual deployments with manual traffic switching required to upgrade a job. If your home-grown operator has any three of those, you already know what the migration would buy.
What has not been solved is downtime on redeploy. Stop-then-start takes 3–6 minutes for a typical job and about 20 minutes for the largest, which is the gap BlueGreen deployment mode — added in operator release 1.14.0 on 15 February 2026 — is meant to close. Lyft found and reported a BlueGreen bug upstream and the fix landed in the Apache project within days, which is the argument for community operators stated better than any vendor could put it: the bug you find is fixed for everyone, and you did not have to fix it yourself.
Sources: InfoQ (Lyft moves streaming fleet to Apache Flink Kubernetes Operator) — https://www.infoq.com/news/2026/09/lyft-flink-k8s-operator/
8. Karmada graduates, TauGrid opens, Dropbox makes room without buying racks
InfoQ · September 17, 2026
Karmada graduated from the CNCF in September 2026, five years after entering the Sandbox in September 2021 and moving to Incubating in December 2023. At graduation the project counts 1,214+ contributors from 292 organisations and 5,600+ GitHub stars, with release v1.19 landing alongside the announcement. The architecture is worth knowing even if you never adopt it: a control plane of three components — API server, controller manager and scheduler — plus its own dedicated etcd, running four internal controllers for Cluster, Policy, Binding and Execution. Scheduling is driven by two custom APIs, PropagationPolicy for which clusters a workload lands on and OverridePolicy for per-cluster mutation, so existing Kubernetes manifests propagate across clusters without being rewritten. That is the design choice that makes multi-cluster tractable for teams with an existing manifest estate. Named production adopters include Bloomberg, Trip.com, Alibaba Cloud, Huawei, Bilibili, iFLYTEK, JDCloud, Kuaishou, SenseTime, Vivo and ZTO — a list of names only, with no cluster, node or pod counts published for any of them. Honghui Yue, a senior development expert at Trip.com, offers the adopter framing: “At Trip.com, Karmada has become critical infrastructure, enabling unified resource pools without changing existing Kubernetes definitions.”
Microsoft open-sourced TauGrid for AI workload management on Kubernetes, and the verifiable surface is: a Go codebase at github.com/Azure/taugrid, a requirement for Kubernetes 1.30+ with GPU nodes, kubectl and Helm 3.0+, a tau CLI, integration with Kueue for queuing and KubeRay for orchestration, topology-aware GPU scheduling, workload checkpoint and resume, and GPU-node health monitoring. What is absent is any measurement: no utilisation, throughput or queue-time figures, no cluster sizes, no comparison against Kueue, Volcano or KAI, and no stated licence. The only concrete configuration published is a sample PyTorch job, which is an example manifest and not a benchmark result. Evaluate it on the feature list and your own cluster, not on the announcement.
Dropbox’s contribution is the least fashionable and possibly the most reusable: create headroom for AI by spending less on what you already run. The one figure with a stated baseline is storage power efficiency improving more than 50% since 2020, measured in watts per petabyte. The rest is qualitative and still instructive — seventh-generation servers drawing more power handled by doubling PDUs per rack while keeping existing busways; a “Deep Sleep” system that powers idle servers and disks into standby and returns them to service within minutes; shingled magnetic recording for density; and hardware lifecycle extension driven by observed reliability rather than a fixed age, all inside the Magic Pocket storage system. There are no dollar savings, no server or rack counts and no figure for capacity actually freed for AI, so treat it as a set of levers to check in your own estate rather than a result to cite. The same week’s reminder that headlines oversell: an InfoWorld piece framed as an AWS strategic bet on agent inboxes is in fact about Pizza Bot, an open-source, self-hosted application built on LangChain’s Deep Agents with LangGraph as the stateful runtime, supporting Anthropic, OpenAI, Google Gemini, Amazon Bedrock and local models via Ollama. There is no availability date, no pricing, and — as analyst Manoj Chandra Jha notes — no support or SLA, which leaves the operational burden with whoever deploys it.
Sources: InfoQ (Kubernetes multi-cluster project Karmada reaches CNCF graduation) — https://www.infoq.com/news/2026/09/karmada-kubernetes-cncf/ · InfoQ (Microsoft open-sources TauGrid) — https://www.infoq.com/news/2026/09/microsoft-taugrid-open-source/ · InfoQ (Dropbox outlines how infrastructure efficiency can create headroom for AI) — https://www.infoq.com/news/2026/09/dropbox-datacenter/ · InfoWorld (AWS bets that AI agents need an inbox) — https://www.infoworld.com/article/4222882/aws-bets-that-ai-agents-need-an-inbox-not-another-chat-window.html
9. Diagnosis, autonomy tiers, and the incidents that refuse to end
InfoQ · September 15–17, 2026
The most mechanically detailed observability write-up of the week comes from Atlassian, and it describes a correlation engine rather than a dashboard. Metrics are checked for rate, error and duration changes; traces for exceptions, latency and structural changes; logs are grouped into new or unusual error patterns; and all three are normalised into a common anomaly format and correlated across signal type, time and topology. The topology comes from an OpenTelemetry-derived service map whose dependency graph is built from real production traffic via parent-child span relationships, with sequence fingerprinting to collapse recurring failure patterns. Most teams already emit what that map needs. What the piece carries no trace of is measurement: no time-to-diagnosis baseline, no incident volume, no adoption figure, no named engineer, and no product name for the platform. Read it as a mechanism to copy, not a result to cite.
On the response side, the useful contribution is a taxonomy and the useful caution is about its numbers. The three-tier framing — fully autonomous for well-understood reversible actions, approval-gated for changes with blast radius, human-led for novel or ambiguous failures — is a sound way to decide what an agent may do unsupervised. The MTTR percentages attached to each tier are the author’s own illustrative ranges in a contributed post, and the article itself tells readers to treat broad industry figures as directional rather than guarantees. Its one sourced datapoint is Microsoft’s roughly 8-minute MTTR baseline reduced to about 4 minutes for autonomous AKS recovery in one documented scenario. The larger deployed dataset sits in a Microsoft Azure-sponsored post about Azure SRE Agent: 1.8 million+ incidents handled inside Microsoft, 3,000+ Microsoft service teams using it, and more than 50% of incidents handled autonomously for some internal teams. Those are Microsoft’s own numbers about Microsoft, which is still the biggest sample anyone has published; the customer figures quoted beside them — 80% less incident investigation time, 84% lower cost and similar — state no baseline and should not be repeated as measured results.
The counterweight to all of it is a QCon San Francisco presentation on long-running incidents by Vanessa Huerta Granda, who leads the resilience engineering team at Enova. She deliberately refuses to define “long-running” by hours or SLA — the definition is whatever feels too long to the people responding — and works through three case studies: database performance degradation, a data-centre infrastructure failure, and recurring seasonal capacity. The four pressures that accumulate are time, coordination, cognitive load and visibility, and none of them is a monitoring problem. Her framing is the line to take into your next long incident: “Long-running incidents don’t just reveal system fragility, they expose that organizational fragility.” Which connects to the week’s other argument about agent failure — that when an agent fails, the model is usually not the problem. That case is made by Adel el Hallak, a vice president of product at Nvidia, alongside Nvidia’s own OpenShell runtime and Nemotron models, and its three circulating numbers each need a source before use: coding agents failing more than 60% of the time on real codebase tasks with no benchmark named; SAFE, the Secure Agent Findings Exchange, backed by approximately 140 companies; and monitoring adding roughly 20% to inference compute cost for persistent agents. The methodological point stands on its own, though: “It’s not enough to just look at the logs or the inputs and the outputs. It is important to figure out how it got to the answer.”
Sources: InfoQ (Atlassian automates root cause analysis) — https://www.infoq.com/news/2026/09/atlassian-automated-rca/ · DevOps.com (the three tiers of agentic incident response) — https://devops.com/the-three-tiers-of-agentic-incident-response-when-to-trust-ai-autonomy/ · The New Stack (agents operate, humans govern: Azure SRE Agent) — https://thenewstack.io/azure-sre-agent-operations/ · InfoQ (when incidents refuse to end) — https://www.infoq.com/presentations/stream-incidents/ · The New Stack (your AI agent failed; the model might not be the problem) — https://thenewstack.io/nvidia-agent-debugging-safe/
Calls to action
- Audit what your agent loads before it does anything. Count the tool schemas in your agent’s default context and multiply by your per-token rate. Uber found about 100 tools costing 50,000–70,000 tokens per session before work started. Move to on-demand tool lookup or CLI invocation, and check your third-party MCP servers first — they ship the largest surfaces.
- Put a human confirmation step between agent analysis and agent code change. DoorDash’s zero-regression result across 50 changes is not only a model story: phase one produces a report and an engineer confirms the flag’s target value, and only phase two writes code. Isolated worktrees, a concurrency cap, a per-agent timeout and a PR gated on build, tests, coverage and static analysis are the rest of the reason it held.
- Re-check every workload whose disaster-recovery plan stops at multi-AZ. AWS has now stated that the Bahrain damage exceeded what regional and multi-AZ services are designed to withstand, and that data held exclusively there cannot be restored. Identify anything with no copy outside a single region, and treat “we are multi-AZ” as a statement about component failure, not about losing a region.
- Separate token volume from token spend in your own reporting. On Vercel’s gateway open-weight models carried 56% of tokens for about 14 cents of every dollar in August. If your AI cost dashboard reports only one of those two numbers, it will tell you a story the invoice does not support. Report both, per model, per team.
- Give your incident tooling a way to correlate signals, not just display them. Atlassian’s approach is copyable without buying anything: normalise metric, log and trace anomalies into one representation, then correlate across signal type, time and topology using a service map built from real traffic. Start with the service map — most teams already emit the spans needed to derive it.
- Price your agents before you scale them. Splunk’s Token Meter reads local coding-agent trace files and prices them against public model rates, surfacing tokens per second, input-versus-output split and tool-call performance. No licence, repository or availability date was named in the announcement, so evaluate it as a pattern you can build in a day if it is not yet downloadable.
- Decide your autonomy tier per incident class, in writing, before an incident. The useful part of this week’s three-tier framing is the taxonomy, not the percentages: fully autonomous for well-understood, reversible actions; approval-gated for changes with blast radius; human-led for novel or ambiguous failures. Write down which of your runbooks sit in which tier and what the rollback is.
- Ask who measured it, every time, before a number enters a plan. Four items in this issue are sponsored or contributed, and their headline figures are the vendor’s own or explicitly illustrative. The three numbers worth carrying out of this week — Uber’s 34%, DoorDash’s 90% and Lyft’s autoscaler savings — came from engineering teams describing their own production systems.
|