DEV Community: saaro

Platform Engineering 2026: Internal Developer Platforms – Between Open Source and SaaS

saaro — Sun, 15 Nov 2026 12:00:25 +0000

Platform engineering has evolved over the past two years from a conference buzzword into a strategic discipline. At its core, it’s about a simple question: How do development teams get a self-service infrastructure platform without every team having to become a Kubernetes expert? The answer is an Internal Developer Platform (IDP) – and in 2026 the market is more dynamic than ever.

CNCF Technology Radar: The Data

The CNCF Q1 2026 Technology Radar, published in March 2026 based on a survey of over 400 professional developers, paints a sobering picture: only 28 percent of organizations have a dedicated platform engineering team. The majority – 41 percent – rely on loose multi-team collaboration, which in practice means the platform remains a shared side project without a fixed owner. 35 percent report a hybrid platform that combines existing developer portals with specialized AI tools.

On the tooling side, the picture is clearer. Backstage, Helm and k9s are in the Adopt status for application delivery. Helm achieves the highest maturity rating: 94 percent of developers gave four or five stars for reliability. GitHub Actions scores 91 percent recommendation, and cert-manager 87 percent for stability.

Backstage: The Market Leader

Backstage, open-sourced by Spotify in 2020 and donated to the CNCF, remains the gold standard. With over 34,000 GitHub stars and more than 200 community plugins, it forms the backbone of most IDP strategies. The catch: Backstage is a framework, not a finished product. Every team that uses it operates its own React/Node application, writes its own plugins, and keeps up with the release pace of versions like v1.55.3 (September 2026).

The total cost consideration puts the supposedly free license into perspective. Third-party analyses estimate the actual annual cost for a medium-sized Backstage installation at around $150,000 – driven by engineering time for integration, plugin development, and operations. So if you’re comparing Backstage against a SaaS alternative, you shouldn’t compare with $0, but with that figure.

The Commercial Competition: Port, Cortex, and OpsLevel

Against the open-source option, three commercial providers have positioned themselves, gaining massive maturity in 2025 and 2026.

Port has evolved from managed Backstage hosting into an “Agentic SDLC” company. The launch of Port AI Builder in July 2026, a natural-language interface for agentic workflows, marks the most significant AI push in this segment so far. Pricing is transparent: Basic from $30 per seat per month (up to 50 seats), Standard from $40 (up to 200 seats).

Cortex focuses on scorecards and engineering leadership. Instead of starting with a catalog interface, Cortex builds around evaluating services against maturity criteria – security patching, test coverage, on-call readiness. The entry price is around $65 per user per month (Amazon Marketplace reference for 50 users: $39,000 annually).

OpsLevel competes directly with Cortex but differentiates through deep CI/CD and deployment integration. Instead of initiative tracking, it focuses on supply chain metrics: build times, deployment frequency, and change failure rate.

The Build vs. Buy Dilemma

Platform engineering is not a pure technology decision. If you build, you save the license but pay in engineering time. A rough three-year calculation for a 150-person team shows: Backstage (self-hosted) costs cumulatively about $390,000, Port (Standard tier) $216,000, Cortex (Marketplace reference) $351,000. Port’s published prices give the cheapest three-year outlook in the model – though without considering migration costs if you switch later.

However, the truly critical factor is not the price, but the internal organization. If you don’t have a dedicated platform team, Backstage is often not an option – operating your own React/Node application plus plugin maintenance overtaxes multi-team structures. Commercial offerings provide faster time-to-value here, bought at the cost of vendor lock-in and less flexibility.

Conclusion

Platform engineering has come of age in 2026. Backstage remains the reference for organizations with a strong platform team and high customization needs. The commercial alternatives Port, Cortex, and OpsLevel have closed the gap for teams without dedicated platform engineers – at prices ranging from $30 to $65 per user per month. The most important insight from the CNCF data, however, is not a tooling question: as long as there is no clear ownership for the platform, even the best tool won’t help.

Sources

KubeCon NA 2026 Live: The Identity Crisis of AI Agents and the First Announcements from Salt Lake City

saaro — Sat, 14 Nov 2026 12:00:13 +0000

KubeCon + CloudNativeCon North America 2026 opened on November 9 in Salt Lake City — and the first half of the conference has already made it clear that this year is not just about GPU scheduling and inference frameworks. The organizing question running through keynotes, side events, and announcements is more fundamental: How can we even trace which AI agent performed which action in a Kubernetes cluster?

The Identity Crisis of AI Agents

The SPIFFE standard and its reference implementation SPIRE assign cryptographic identities to workloads in Kubernetes via service accounts. This works excellently for classic workloads like database pods or API gateways, where each instance is functionally identical. However, this model breaks down with AI agents. An agent that has accumulated tool calls, retrieval results, and intermediate conclusions over six hours in a conversation context is not identical to a freshly started agent — even if both use the same container image and the same service account.

An analysis by Solo.io from August 2026 described the gap as a "fundamental contradiction between the non-deterministic, context-dependent behavior of agents and the rigid identity assignment via infrastructure topologies." The numbers underscore the urgency: According to the NHI Management Group, 72 percent of organizations now have more non-human than human identities in their environments. Teleport found that 70 percent of companies grant AI systems more access than humans in comparable roles.

Various solution approaches are being discussed on the exhibition floor: per-instance SPIFFE identities that are issued when an agent starts and rotated during context changes; supplementary token formats that carry a session-bound identity alongside the workload credential; and tighter integration between agent orchestration frameworks and SPIFFE-capable service meshes. A consensus has not yet been reached — discussions in the working groups are ongoing.

Red Hat OpenShift 5.0: Built-in MCP Server

Red Hat used KubeCon to introduce OpenShift 5.0 — a platform designed for the era of agentic AI. The core of the announcement: OpenShift receives an integrated Model Context Protocol (MCP) server, allowing AI agents to directly access cluster resources without separate middleware. In parallel, Lightspeed has been extended with an AI agent through which IT teams can orchestrate multiple models to automate workflows.

Additionally, there is OpenShell, a sandbox environment for OpenClaw agents developed by NVIDIA and integrated by Red Hat. The architecture isolates agents in shielded runtime environments — an architectural pattern that other vendors are also adopting.

Cloudsmith: Agent Skills as Versioned Packages

Cloudsmith presented an AI Agent Skills Registry at KubeCon. Behind it lies a simple but powerful idea: The capabilities of AI agents (skills), consisting of a SKILL.md file plus scripts, references, and templates, are versioned, reviewed, and distributed like software artifacts.

"Community skill registries were built for sharing, not for control," said Alison Sickelka, VP of Product at Cloudsmith. "With Cloudsmith, platform teams decide which skills and versions are allowed, block the unwanted ones, and see every pull in the same audit trail as the rest of their software supply chain." This closes a gap that is becoming increasingly urgent with the growing prevalence of AI coding agents: An unchecked skill can change what an agent does — and skills from public catalogs carry the same unknowns as any open-source dependency.

AI Gateway Governance Becomes Platform-Agnostic

Traefik Labs announced that Traefik Hub — its AI Gateway — now runs on four additional platforms: SUSE AI Factory with NVIDIA, Spectro Cloud PaletteAI, VMware Cloud Foundation (VCF), and Nutanix Cloud Platform. Wherever workloads run, the same governance rules apply for model, agent, API, and application traffic.

"Customers rarely buy a gateway for its own sake," said Sudeep Goswami, CEO of Traefik Labs. "They choose a platform for their infrastructure — and expect the controls to work there."

Conclusion

The first half of KubeCon NA 2026 shows a clear trend: The cloud-native community has built the infrastructure for AI workloads — now it's about control, traceability, and security. The identity crisis of agents, the integration of MCP into platforms like OpenShift, and the packaged management of agent skills are not fringe topics but the central construction sites for 2027.

Anyone operating Kubernetes for AI agents should closely follow the discussions from Salt Lake City. The coming months will show whether the outlined solution approaches — per-instance identities, versioned skills, and platform-agnostic AI gateways — prove themselves in practice. KubeCon NA 2026 runs until November 12; session recordings will be published subsequently on the CNCF YouTube channel.

Sources

Backstage Scaffolder 2026: From Template to Self-Service Platform

saaro — Fri, 13 Nov 2026 12:00:36 +0000

The Backstage Scaffolder is the heart of any Developer Portal: It enables developer teams to create new projects, services, and components via self-service – without having to wait for a platform team. With the release of Backstage 1.55 in October 2026 and the increasing maturity of the v1beta3 format, the Scaffolder has made a leap forward, transforming it from a practical tool into a strategic platform component.

From Template to Golden Path

The idea behind the Scaffolder is simple: Instead of each team manually setting up its CI/CD pipeline, repository structure, and Kubernetes manifests, the platform team defines unique Software Templates – coded templates that are run through a standardized workflow. Developers select a template in the Backstage frontend, fill out a form, and the Scaffolder does the rest: create repository, generate code skeleton, configure CI/CD, register in the catalog.

With the v1beta3 format, Backstage has fundamentally revised the template definition. Unlike earlier versions, templates are now more clearly structured: parameters define the input form, steps the actions to be executed, and output the return values for the frontend. The steps are processed sequentially and can build on each other – for example, when a publish:github step passes the repository URL to the subsequent catalog:register step.

A template can include any number of steps: clone code from a Git template, replace variables, inject secrets, run Terraform, provision a database, and make the finished product visible in the Backstage catalog. What used to mean hours of manual work becomes a self-service process lasting just a few seconds.

Custom Actions: The Power of Extensibility

In addition to the built-in actions (such as fetch:template, publish:github, debug:log), platform teams can write their own Custom Actions. These are implemented as a Node.js package and integrated into the Scaffolder. This allows practically any internal process to be automated: creating a Jira ticket, provisioning a cloud resource, or generating a certificate.

The Roadie community now lists over 50 available Scaffolder actions – from interacting with cloud providers to integrating with monitoring tools. Backstage itself has provided the scaffolder.requireScmUserCredentials option since version 1.54, which mandates user credentials for certain actions – an important step toward governance.

Task Recovery: Finally Robust Automation

A long-standing criticism of the Scaffolder was its lack of fault tolerance: if the process crashed during execution, the entire template had to be run from the beginning. A GitHub issue from April 2025 put it succinctly: "It is not only inconvenient but technically problematic to have to restart the entire Scaffolder process."

Backstage 1.55, released on October 13, 2026, fixes this problem with the new Task Recovery feature. When enabled, an interrupted task can be resumed from the last successfully completed step. The step results remain persistent, and task secrets are only deleted once the task has reached a final state. Configuration is done via the new scaffolder.taskRecovery section in the Backstage configuration.

However, the documentation points out an important limitation: actions in resumed tasks should be idempotent or use checkpoints, since a step could potentially be executed a second time. For production environments, the Backstage team also recommends an external storage backend – such as the GCP module – instead of the built-in database, which is limited to 50 MB.

Performance Leap Through Smart Optimizations

In addition to Task Recovery, Backstage 1.55 shows that even seemingly small changes can have a big impact. Michael Todorovic, Senior SRE at Veepee, optimized the GitLab merge request and push actions: Instead of making a separate API request to GitLab for each file, the code now compares files locally. The number of API requests dropped from around 300 to under ten, and execution time from 5–15 seconds to about three seconds.

Such optimizations may sound unspectacular, but in the daily operation of a Developer Portal with hundreds of template executions, they are a decisive factor for acceptance among the developer team.

Conclusion

The Backstage Scaffolder has evolved from a simple template engine into a full-fledged automation platform. With the v1beta3 format, Task Recovery in 1.55, and the growing number of Custom Actions, it now meets the needs of platform teams that take Developer Experience and Governance equally seriously. Anyone running an Internal Developer Portal should view the Scaffolder not just as a "nice-to-have" but as a strategic tool that scales the productivity of an entire engineering team.

Sources

Small Language Models 2026: Why Small AI Models Are Taking Over Production

saaro — Fri, 13 Nov 2026 12:00:00 +0000

In 2026, a quiet paradigm shift has taken place in the AI landscape. While headlines continue to be dominated by ever-larger frontier models with trillions of parameters, more and more production teams are opting for the opposite: Small Language Models (SLMs). These compact models with a few billion parameters run locally on end devices, avoid cloud roundtrips, and drastically reduce operating costs – often with equivalent quality for specific tasks.

What defines SLMs in 2026

The term "Small Language Model" describes AI models with typically 100 million to 15 billion parameters – a fraction of the trillion-parameter models like GPT-4. However, size alone is not the decisive factor. SLMs are trained on narrowly defined, curated datasets or distilled from larger models. The result is specialized helpers that excel at one task rather than being mediocre at everything.

The current model families show the breadth of the spectrum: Microsoft's Phi-4-mini-instruct comes with 3.8 billion parameters and a 128,000-token context window. Google's Gemma 4 offers effective 2B and 4B variants specifically for mobile and edge deployments. Meta's Llama 3.2 (1B and 3B) and Alibaba's Qwen3.5 series (0.8B to 9B) round out the offering. What they all have in common: they run on consumer hardware, often fully quantized on devices with 4 GB of RAM.

Three hard truths driving SLMs

The shift to small models is not ideological – it is pragmatic. Three factors are forcing teams to rethink.

Latency. A cloud API call to GPT-4 or Claude takes 200–800 ms to the first token, plus network latency. An SLM on the device delivers the first token in 5–15 ms – without a network hop, without an API queue, without a cold start. For real-time applications like autocomplete, voice assistants, or code completion in IDEs, this is the difference between usable and unusable.

Data privacy. Medical records, financial transactions, legal documents – in regulated industries, sending data to external APIs is not an option. On-device inference means the data never leaves the device. No API logs, no third-party agreements, no risk of training data leaks.

Costs. At 100 requests per day, cloud LLM APIs are affordable. At one million requests per day, they become a CFO nightmare: around $90,000 monthly just in API fees. An edge SLM, on the other hand, costs only the amortized hardware – the inference itself is effectively free.

Where SLMs are already winning in 2026

The areas of application are diverse and practical. In customer service, SLMs handle the most common, repetitive inquiries – order status, billing questions, policy queries – without routing every ticket through a cloud API. This reduces response times and relieves human employees.

On the device, voice assistants, offline translations, and smart home interfaces run completely locally. For IoT environments in factories or field installations, where network connectivity is often intermittent, local inference is not an option but a requirement.

SLMs are also on the rise in code assistance. Models like Phi-3.5 Mini are actively used for code generation and completion. For teams working within a specific codebase, a fine-tuned SLM often outperforms a general coding assistant – it knows the context that matters in daily work.

The approach of model routing is particularly interesting: Instead of using a large model for everything, systems route simple, verifiable steps to an SLM and escalate only the difficult cases to a frontier model. This saves costs without sacrificing quality.

The limitations – and why they matter

SLMs are not a panacea. They hit limits with open-ended, ambiguous tasks, with synthesis over long contexts, and with factual retrieval beyond their training data. Microsoft explicitly warns that Phi-4-mini "cannot store extensive factual knowledge and may produce incorrect facts." The reliability of an SLM stands or falls with the quality of the provided context information – and with the clarity of the task delineation.

Conclusion

In 2026, Small Language Models are no longer a niche but a fixed component of AI production architecture. They do not replace frontier models but complement them where efficiency, data privacy, and latency matter. The market for SLMs is estimated to reach over $20 billion by 2030 – driven by a simple realization: Most real-world applications do not need a supercomputer, but a reliable specialist that completes its task quickly and cost-effectively.

Sources

Argo CD 3.6: Less Memory, Better Rollout Visibility – The GitOps Update of the Year

saaro — Thu, 12 Nov 2026 12:00:48 +0000

On November 3, 2026, the Argo CD project released version 3.6.0, followed by a stabilization patch 3.6.1 on November 4. The release coincides with KubeCon NA 2026 in Salt Lake City and is the most extensive update of the year. At its core are three developments: a drastic reduction in controller memory usage by around 70 percent, new rollout metrics for the ApplicationSet module, and the expansion of the health check library to over ten new resource families – including, for the first time, AI infrastructure with KServe. At the same time, the 3.3 release line reaches its planned end of support. More than 170 bug fixes round out the overall picture. The release is the result of months of work by contributors from Intuit, Akuity, Red Hat, BlackRock, and Octopus Deploy, among others.

Progressive Sync Metrics: Transparency in Multi-Stage Rollouts

The ApplicationSet controller module, central to deployments across multiple clusters and environments, receives a long-requested capability in 3.6: meaningful metrics for progressive syncs. Previously, for operators in canary or wave-based rollouts, it was often not clearly distinguishable whether a wave had completed successfully or never started. Newly provided Prometheus metrics and the error states ApplicationSetRolloutError and InvalidRolloutConfig now provide clarity. This is supplemented by annotations that can trigger a forced reconciliation before the next sync step. For teams operating hundreds of applications across multiple clusters with staggered rollouts, this transparency is the foundation for automated alerting chains and reliable deployment dashboards. The release candidate phase began in mid-September 2026 and allowed thorough testing of these changes in real production environments.

70 Percent Less Memory – The Architecture Overhaul

The most impressive metric of the release concerns memory usage: on a production system, the consumption of the Argo CD controller dropped from 3.27 GB to under 1 GB – a saving of around 70 percent, achieved with only 2.5 percent more CPU load. This is made possible by a fundamentally redesigned caching architecture with server-side label filtering: Kubernetes objects that are not relevant for any deployment never even enter the cache. Combined with optimized manifest serialization and partial JSON unmarshalling, the memory footprint drops drastically even in large installations. Additionally, a new virtual scrolling relieves the UI – with 5,000 applications, the tab no longer freezes because only the visible rows are rendered. Filter and search operations in the application list also require an estimated 20 to 30 percent less rendering work. A redesigned resource explorer aggregates all managed resources across application and cluster boundaries, searchable and filterable, with summary pie charts for sync status and health. The explorer respects RBAC boundaries, so team members only see the resources shared with them.

Health Checks for AI Infrastructure and Cloud-Native Platforms

The built-in health check library receives the largest single expansion in its history. Newly covered are: Kyverno policies, TLSRoute resources, AWS ACK resources, CloudNativePG databases and backups, Medusa jobs, Prometheus Operator components, cert-manager objects, Tekton pipelines, Velero backup schedules, and – particularly noteworthy – KServe for LLM inference services. With this, Argo CD responds to the increasing diversity of modern Kubernetes platforms, which are no longer composed solely of Deployments and Services but orchestrate policy engines, database operators, and ML serving stacks. Platform teams that previously maintained their own health checks in Lua scripts can now replace them with the native library.

OpenTelemetry and Platform Maturation

Another strategic feature is configurable OpenTelemetry trace sampling, which now extends across the controller, repo server, and GitOps engine. Combined with the new Prometheus metrics for ApplicationSet, this creates a comprehensive observability picture that allows operations teams to integrate Argo CD into their existing monitoring and tracing infrastructures – an important step for use in regulated environments or large platform teams. This is accompanied by an OCI generator for ApplicationSets, new RBAC rollback actions, and over 170 bug fixes, including a fix for SSH repository fetch through a SOCKS5 proxy (backported from the 3.3 branch). The release was significantly supported by contributions from Intuit Open Source, Akuity, Red Hat, BlackRock, Octopus Deploy, and a long list of individual community contributors – a prime example of distributed open-source development.

End of Support for Argo CD 3.3

With the GA of 3.6, support for the 3.3 release line ends as planned. The last version, 3.3.17, was released on November 3. Teams still running 3.3 should plan the upgrade path via 3.4, 3.5 to 3.6. Operating a 3.3 installation without security updates is not recommended for production environments. The project's upgrade documentation describes the required migration steps between minor versions in detail.

Conclusion

Argo CD 3.6 is the most significant release of 2026 so far. The drastic memory reduction, the meaningful rollout metrics, and the expansion of the health check system into the AI domain make the update relevant for every platform team. The combination of operational robustness (performance, observability, lifecycle management) and new capabilities (OCI generator, extended health checks) shows: Argo CD is evolving from a deployment controller to an overarching control plane for cloud-native platforms. Anyone using Argo CD in production should prepare the upgrade to 3.6 promptly.

Sources

EU AI Act 2026: What Now Applies to Developer Teams and DevOps

saaro — Tue, 10 Nov 2026 12:01:00 +0000

Since August 2, 2026, the EU AI Act has been fully enforceable in its core transparency obligations. While headlines focused on the postponement of high-risk deadlines, the rules that now apply are more relevant for most development teams than those coming later. An overview of the current status and practical consequences.

What the AI Omnibus postponed – and what it did not

The EU AI Act (Regulation 2024/1689) entered into force on August 1, 2024, and is being phased in gradually. In July 2026, the EU adopted the Digital Omnibus on AI (Regulation 2026/1744), which postponed four key dates:

High-risk systems under Annex III (standalone: recruitment, credit scoring, education, critical infrastructure): from August 2, 2026 to December 2, 2027
High-risk systems under Annex I (embedded in regulated products such as medical devices): to August 2, 2028
National AI regulatory sandboxes: to August 2, 2027
Labeling of systems already on the market: to December 2, 2026

This postponement is often misunderstood as a general relaxation. The opposite is true: the Omnibus did not remove any obligations, create any exemptions, or reduce any fines. It only changed the when, not the what.

What was not postponed – and has been enforceable since August 2, 2026:

Article 50 transparency obligations for chatbots, AI-generated content, and deepfakes
Enforcement powers of the European Commission against GPAI providers (General-Purpose AI)
Fines of up to €15 million or 3% of global annual turnover for violations

The four transparency obligations that development teams must implement now

1. Chatbots and AI interaction (Art. 50(1))

Any AI system that directly interacts with humans must clearly and accessibly communicate this at the start of the first interaction. The "obvious" exception is to be interpreted narrowly – anyone running a chatbot behind a standard chat UI should not rely on it.

For development teams, this means: the disclosure must be implemented in the production-level frontend, not just in the prototype. Machine-to-machine APIs and systems without direct human contact are exempt.

2. Labeling of generative content (Art. 50(2))

AI-generated audio, image, video, and text content must be marked with effective, reliable, robust, and interoperable machine-readable markings. Systems that were on the market before August 2, 2026, have a grace period until December 2, 2026.

In practice, this means: CI/CD pipelines must now support metadata standards such as C2PA (Coalition for Content Provenance and Authenticity). A model output without provenance marking is a compliance risk after the deadline.

3. Emotion recognition and biometric categorization (Art. 50(3))

Operators of systems for emotion recognition or biometric categorization must inform affected individuals – either in real time or subsequently.

4. Deepfakes and public-interest AI content (Art. 50(4) and (5))

Deepfakes must be labeled as such. AI-generated texts of public interest (e.g., news, election information) must be disclosed unless they have undergone human editorial review. "Human review" means substantive engagement – a mere spell check is not sufficient.

What this means for DevOps and platform teams

The EU AI Act is not purely a legal matter. The transparency obligations fall directly under the responsibility of development teams:

Labeling in the CI/CD pipeline: Content provenance must become part of the deployment process. Anyone delivering AI-generated text, images, or code via a CI pipeline must ensure that the metadata is correctly set. This requires new middleware components or gateway rules.

Model documentation as an artifact: Since August 2026, GPAI providers must supply standardized Model Documentation Forms. Anyone integrating third-party models into their applications should request and version this documentation – it is the basis for their own compliance.

Monitoring and audit trail: Article 50 does not require a full high-risk conformity assessment, but the burden of proof remains. Teams should document which AI components are used where, what labeling they receive, and whether the disclosure is correctly implemented.

Grace period for existing systems: Systems that were on the market before August 2, 2026, have until December 2, 2026, for content labeling. This is the next real deadline – and the one most often overlooked in the postponement headlines.

Conclusion

As of August 2026, the EU AI Act is no longer an abstract future regulation but enforceable law with enforcement authority. The postponement of high-risk deadlines has lulled many into a false sense of security – in fact, the transparency obligations under Article 50 are in effect and affect the majority of AI applications currently developed and operated in Europe. Development teams should use the remaining time until December 2026 to integrate content provenance, chatbot disclosure, and model documentation into their existing DevOps processes. The foundation for high-risk compliance in 2027 is being laid now.

Sources

Regulation AI: EU AI Act in 2026 – Complete Compliance Guide — Comprehensive guide to the AI Act with updated deadlines after the Digital Omnibus
Regulation AI: EU AI Act Digital Omnibus 2026 – What It Changes — Detailed analysis of the four postponed deadlines and the unchanged obligations
cybersins/sec: The EU AI Act Delay That Isn't – What Actually Goes Live on August 2 — Classification of enforceable obligations from August 2026, extraterritorial scope, GPAI enforcement
SIG: A Comprehensive EU AI Act Summary (August 2026 Update) — Practical summary of risk levels, deadlines, and the Omnibus procedure
Abhishek Gautam: EU AI Act Article 50 Transparency Deadline – What Developers Must Ship — Concrete checklist for developer teams on the four transparency obligations under Article 50

LLM Wiki in Teams 2026: Why Karpathy's Pattern Fails in Companies – and What Comes Next

saaro — Tue, 10 Nov 2026 12:00:24 +0000

Karpathy’s LLM Wiki has been the most discussed pattern for personal AI knowledge databases since April 2026. The idea is convincing: An LLM agent compiles a structured Markdown wiki from raw sources, maintains cross-references, uncovers contradictions, and keeps everything up to date – the human only curates the sources. Karpathy himself describes the workflow as “Obsidian is the IDE, the LLM is the programmer, the wiki is the codebase.” But since fall 2026 at the latest, it has become clear: What works brilliantly for one person collapses in a team due to fundamental governance problems. This article shows where the limits are and what architecture a real team LLM wiki needs.

What makes Karpathy’s pattern so successful

Karpathy’s architecture separates three layers: /raw (immutable original sources), /wiki (LLM-generated and maintained Markdown pages), and a schema like CLAUDE.md that defines structure and workflows. Three operations – Ingest, Query, Lint – keep the system alive. The crucial break with RAG: knowledge is not reassembled from chunks with every question, but compiled once and then continuously improved. A preregistered comparison study (arXiv:2605.18490, as of October 2026) showed that an LLM-compiled wiki performed significantly better at connecting insights across 24 papers than vector RAG – though with roughly 21 times higher token consumption per query.

The pattern’s clever trick lies in shifting the maintenance work: while Zettelkasten systems fail because manual upkeep grows over time, the LLM takes over that part entirely. The human only decides which sources are allowed in and which questions to ask.

What fails in a team

Several teams have tested the pattern in practice since summer 2026. The results are sobering. The Harbor blog (October 2026) sums up the problems precisely: “Git records who changed a line. It does not say whether the line is true.”

Lack of intake control: Karpathy’s pattern relies on one person manually curating the raw sources. In a company, however, the sources are scattered across Slack, GitHub, Linear, Google Docs, and Confluence – dozens of teams write simultaneously without knowing that a wiki depends on their contributions. Taktile Engineering, which runs the pattern via Notion and Google Drive, reports that errors in an LLM‑written index propagate uncontrollably when sources are edited by people unaware of the wiki workflow.

No access control (RBAC): The file-system model of Karpathy’s pattern knows no role‑based permissions. Who is allowed to read which page? Which source may not be seen? Which synthesis may be generated? For companies with compliance requirements – e.g., in finance, pharma, or energy – this is a deal‑breaker, as Innobu states in its enterprise reality check (May 2026).

Error compounding: A user comment in the Show‑HN thread puts it succinctly: after six months, entries are “confidently wrong,” and the lint cannot tell which ones. Even more fatal: agents that read the wiki cite erroneous entries further – a self‑reinforcing cycle that, without a countermeasure, can devalue the entire wiki.

Write conflicts with parallel work: Multiple agents or team members ingesting simultaneously create conflicts. Git versioning mitigates the problem but does not fundamentally solve it. Added to this is the lack of ACID transaction safety – irrelevant for a personal knowledge database, but leading to inconsistent states in a team.

Is the “Company Brain” platform coming?

The industry has reacted to these gaps. Y Combinator explicitly named the missing “company brain” primitive as a construction site in its Spring 2026 Requests for Startups. Several approaches address the gap between Karpathy’s personal pattern and true team capability:

Synthadoc (1,500+ GitHub stars) introduces a life cycle for wiki pages: Draft → Active → Stale/Contradicted → Archived. Pages go through a review process before they become “Active” – a simple gate mechanism that Karpathy’s pattern lacks. Codealmanac (997 stars) targets engineering teams with a codebase wiki maintained by coding agents and released via Git review.

Sentra and Falconer take a radically different approach: instead of a curated raw/ folder, they ingest automatically from the tools where work actually happens – Slack, GitHub, Linear, meeting notes. Every fact remains linked to its source, the latest version takes precedence, and the permissions of the source system are adopted. This spares the company the illusion of a central curator.

The challenge is architecturally demanding: a team LLM wiki must fulfill four properties simultaneously, as Falconer formulates them: Capture (ingesting from distributed sources, not just a raw/ folder), Link (bidirectional connections across tool boundaries), Compound (growth and synthesis through every new source), Stay Current (automatic updates and obsolescence detection). No existing tool meets all four – most cover only one or two.

Conclusion

Karpathy’s LLM Wiki pattern is a milestone for personal knowledge work – it frees the human from the maintenance work that causes classic Zettelkasten systems to fail. For teams, however, it is not plug‑and‑play. Anyone who wants to use the pattern in a company needs at least three extensions: a gate for incoming sources (review queue, approval workflow), a validity and obsolescence model for statements (dates + retirement), and usage monitoring (which pages are agents actually reading, where are errors circulating). The first platforms that close these gaps are emerging – 2027 will show whether the “Company Brain” becomes the next big cloud‑native primitive, or whether Karpathy’s pattern remains a single‑player phenomenon.

Sources

RAG 2026: Why Massive Context Windows Haven’t Ended the Retrieval Era

saaro — Mon, 09 Nov 2026 12:00:47 +0000

When the first models with a million token context window hit the market in 2024/2025, the prognosis was clear: Retrieval-Augmented Generation (RAG) was done. If the LLM can simply read the entire knowledge package at once, why bother with complex searching and chunking? Two years later, in November 2026, the verdict is different. RAG hasn’t disappeared – it has become more important.

The Pivot: From Workaround to Precision Filter

The intuitive assumption was deceptive: more context means better answers. A study by the Chroma team from July 2025, known as “Context Rot,” impressively refuted this. They tested 18 then-current models from GPT, Claude, and Gemini and found that model quality measurably degrades before the advertised context limit. Even more surprising: even a single irrelevant paragraph worsens accuracy, and logically sorted content sometimes performed worse than shuffled content.

The insight fundamentally changed the role of RAG. While retrieval used to be the workaround to get data into the model that otherwise wouldn’t fit, today it’s the opposite: ensuring a small, clean, and precise context so that a powerful long-context model can fully realize its potential. In 2026, RAG is no longer a workaround for too-small windows, but a precision filter for overloaded contexts.

Two-Stage Retrieval: The New Standard

The simplest RAG implementation – chunking, embedding, similarity search, generation – is considered a baseline in 2026, not a solution. Production-ready systems rely on a two-stage retrieval process:

Retrieve Wide: In the first step, a broad set of candidate passages is quickly retrieved, typically using a combination of vector similarity search (cosine similarity) and keyword-based full-text search (hybrid search).
Rerank Precise: A second, slower but more accurate model – a cross-encoder reranker – re-evaluates the candidates and keeps only the most relevant three to ten passages.

This pattern has proven so reliable that it is now considered standard practice rather than an optimization. Tools like Cohere Rerank or Voyage-Rerank, as well as the open-source library Rerankers, are found in almost every RAG stack in 2026.

GraphRAG: Structure Instead of Prose

One of the most significant developments is GraphRAG, largely driven by Microsoft Research. While classic vector RAG represents documents as text chunks and searches by similarity, GraphRAG extracts entities and their relationships and stores them as nodes and edges in a knowledge graph (e.g., Neo4j). When a query comes in, the graph is traversed instead of just computing vector similarity.

The advantage shows with so-called multi-hop questions: “Which medications prescribed in cardiology interact with active ingredient X?” – a question that classic RAG cannot answer from scattered individual chunks because the relationship between entities was never captured. GraphRAG solves this problem by mapping the structure of the information.

However, practice in 2026 also shows the limits: a comparison of GraphRAG with vector RAG on general question-answering datasets yielded only a marginal advantage of 0.47 points, but at 44 times higher token costs (around 40,000 tokens per query compared to 900). For multi-hop questions in highly relational domains, the effort pays off – for simple fact queries, classic RAG remains superior.

Agentic RAG and Evaluation: Two Trends That Are Here to Stay

The second major trend in 2026 is Agentic RAG. Instead of treating retrieval as a rigid step before every generation, an AI agent decides for itself whether and what to search for, whether a search needs to be refined, or whether the question doesn't require retrieval at all (“Adaptive Retrieval”). Multi-step retrieval loops with self-correction are in production, usually limited to two or three iterations to control cost and latency.

In parallel, the evaluation landscape has professionalized. The open-source framework RAGAS is the de facto standard in 2026 for measuring retrieval and generation quality separately. Four core metrics have become established: Faithfulness (does the answer stay within the context?), Answer Relevancy (does it answer the question?), Context Precision (are the chunks relevant?), and Context Recall (was everything necessary found?). Faithfulness is considered the most important metric because hallucination, despite good retrieval, causes the greatest trust damage.

When RAG, When Long Context?

The rule of thumb for 2026: If the entire knowledge base fits into roughly 200,000 tokens (about 500 pages), you can do without retrieval, put everything into the context, and operate cost-efficiently via prompt caching. Beyond that, RAG wins on all dimensions: cost (approx. $0.001–$0.01 per query vs. $0.05–$2.00 for full context stuffing), latency (500 ms–2 s vs. 5–30 s), and accuracy (85–95% vs. 70–90% on needle-in-a-haystack tasks). Rather than being competitors, long context and RAG are two ends of the same dial.

Conclusion

In 2026, RAG has not died – it has grown up. Its role has shifted from a workaround for small context windows to a precision filter for large ones. Two-stage retrieval with reranking, graph-based approaches for relational questions, agentic retrieval loops, and measurable evaluation with RAGAS have turned the technology from a tinkering exercise into an engineering-manageable discipline. Anyone running an AI-powered knowledge base in 2026 cannot avoid a well-thought-out RAG stack – but this time for different reasons than in 2023.

Sources

TokenMix: RAG Tutorial 2026 — Cut Costs 80%, Hallucinations 40-60% — Cost comparison, architecture, implementation guide
ArStudioz: What Is RAG? Retrieval-Augmented Generation in 2026 — Context Rot study, RAG as precision filter, Agentic RAG
Markaicode: GraphRAG Knowledge Graph Enhanced Retrieval Guide 2026 — GraphRAG architecture and implementation with Neo4j
WhySoGeek: RAG Evaluation Metrics — Measuring Faithfulness 2026 — RAGAS metrics, faithfulness as primary metric
LinkedIn (Muhammad Atif Lodhi): GraphRAG vs Vector RAG — 2026 Research — Cost and performance comparison GraphRAG vs. Vector RAG

Backstage TechDocs 2026: Zensical as a Fallback Path Before the End of Material for MkDocs

saaro — Mon, 09 Nov 2026 12:00:12 +0000

On November 2, 2026, the Backstage project released version 1.56.3 – a four-day patch that seems unremarkable at first glance, but addresses one of the most pressing infrastructure questions for platform teams: What happens to TechDocs when Material for MkDocs disappears? The answer is Zensical, and it arrives as an experimental engine for Backstage's documentation pipeline.

Why the timing is critical

TechDocs is Backstage's documentation engine and, for many companies, the central place where developers find service documentation, ADRs, and runbooks. Under the hood, TechDocs relies on Material for MkDocs – a widely used theme and static site generator developed by Martin Donath (squidfunk). In November 2025, the team announced that active development would be discontinued and the focus would shift to its successor, Zensical.

Originally, November 5, 2026, was set as the end-of-life date. In September 2026, the deadline was extended to May 2027, but the implicit pressure on platform teams remained: Anyone running TechDocs in production must migrate in the medium term. Backstage has now made this migration concrete with version 1.56.3.

The TechDocs engine abstraction as a foundation

Backstage 1.56.0 (October 2026) already laid the foundation with a TechDocs engine abstraction: Instead of tightly integrating MkDocs, various generators can now be used. The abstraction allows swapping out the TechDocs build process without rewriting the surrounding pipeline (preparing, publishing, serving). This is the prerequisite for Zensical support, which was actually built into 1.56.3.

What Backstage 1.56.3 specifically delivers

The release brings three components:

@backstage/plugin-techdocs-backend-module-zensical: A new backend module that integrates Zensical as a TechDocs engine. It is marked as experimental – productive adoption is possible, but caution is recommended.
CLI support: @techdocs/cli can now build TechDocs projects with Zensical as well. This allows testing against the new generator locally or in CI pipelines.
Alpha building blocks in @backstage/plugin-techdocs-node: For teams with custom TechDocs pipelines, new APIs are available that integrate with the Zensical engine.

The maturity levels are deliberately chosen: experimental (backend module) and alpha (Node APIs) signal that this path has been tested but is not yet secured for every production case. The Backstage project has thus chosen a pragmatic middle ground: deliver quickly, but make no false promises of a zero-effort migration.

What Zensical is – and what it is not

Zensical is developed by the same team as Material for MkDocs. It is not a fork, but a new development that – as of November 2026 – covers the most important MkDocs features: mkdocs.yml as configuration, Python Markdown, most theme settings, and a growing number of plugin replacements. It aims to be compatible, but not identical. Anyone using custom MkDocs plugins, template overrides, or special theme customizations should test thoroughly before migrating.

The official compatibility page lists the supported settings and plugins. It shows that for standard documentation, the migration is usually smooth, while for heavily customized projects, each plugin needs to be checked.

What platform teams should do now

Three steps make sense from today's perspective:

Set up a test environment: Upgrade a non-production Backstage to 1.56.3 and build representative TechDocs projects – including those with custom plugins and themes – against the Zensical engine. Document the differences in build logs and generated output.
Inventory dependencies: Which TechDocs projects use MkDocs plugins that do not yet have a Zensical equivalent? Is there a dependency on MkDocs-only features? This list is the basis for the migration plan.
Offer a golden path: Instead of letting each team organize the migration themselves, the platform should provide a tested builder image with the Zensical module enabled, CI snippets, and a rollout checklist. This reduces the cognitive load for teams and prevents ad-hoc patchwork.

The deadline until May 2027 sounds generous – but anyone who only tests then will have wasted the window for an orderly migration. The experimental status does not mean the engine does not work, but that it can still change. Those who test today will be prepared when stabilization occurs in one of the next versions.

Conclusion

Backstage 1.56.3 is an important milestone for the future of TechDocs. The experimental Zensical integration gives platform teams a concretely testable way out of the Material for MkDocs dependency. The effort for migration is manageable – provided you start evaluating now and build a reproducible test setup. The next Backstage versions (1.57.x) will further stabilize the alpha APIs; until then: test, document, prepare.

Sources

Ten Projects, One Stack: Why the AAIF Consolidation Reframes the Security Question

saaro — Fri, 06 Nov 2026 12:01:11 +0000

On October 22, 2026, the Agentic AI Foundation (AAIF) added four more projects: Agent Skills (Anthropic), Open Responses (OpenAI), OpenEnv (Hugging Face), and OpenSandbox (Alibaba). The foundation, launched in December 2025 with three projects, now hosts ten after eleven months. Good for adopting teams – and a reason for a question that often gets overlooked: What does it mean when a large part of the trust assumptions of the agent stack is under one roof?

From three to ten projects

The AAIF is a project of the Linux Foundation, founded on December 9, 2025, with MCP, goose, and AGENTS.md as founding projects. By August 2026, it had grown to more than 250 members. The ten projects cover almost every layer of an agent operation: MCP for tool and data access, A2A for agent communication, Open Responses as a model interface, AGENTS.md and Agent Skills as instruction-carrying formats, agentgateway and Agent Router as a traffic control plane, goose as a runtime, and OpenEnv and OpenSandbox for evaluation and isolation. This is a map of dependencies.

Two axes: A2A and MCP

MCP connects an agent with things that are not agents: databases, file systems, internal APIs. A2A connects an agent with another agent – potentially from another company, on another model, in another organization. A2A defines discovery via Agent Cards, task delegation, and result exchange.

A2A reached the stable v1.0 specification in March 2026 and has been a Growth Stage project of the AAIF since August 17, 2026 – in the same house as MCP, but with a separate specification. The foundation names more than 150 supporting organizations and production deployments in supply chains, financial services, and mobile platforms. Shared governance does not mean shared specification: the protocols remain independent.

Since October 1, 2026, there is the official A2A CLI – an interface for scripts, CI pipelines, and coding agents:

# Read the Agent Card of a remote agent
a2a card get https://agent.example.com

# Send a task and wait for the result
a2a send -a https://agent.example.com "Summarize this document"

JSON outputs and defined exit codes make it automatable; a2a server --exec turns any stdin/stdout program into an A2A server – for testing, not for production.

Neutral governance is not a security promise

This is where the analysis by the Cloud Security Alliance (CSA) from October 29, 2026, begins: The AAIF solves the governance problem, not the security problem. The public project list lists ten projects without maturity or security labels. Unlike the CNCF, whose graduation requires an external security review, the CSA found no published foundation-wide baseline – no mandatory threat model, no uniform disclosure process, no third-party audit for all projects.

Added to this is a silent migration risk: The MCP revision from July 28, 2026, removed sessions at the protocol level, including Mcp-Session-Id. Tooling that correlates activity via session IDs or makes policy decisions during the initialization handshake can lose visibility without reporting an error. New attachment points are the headers Mcp-Method and Mcp-Name as well as OpenTelemetry trace propagation.

Instructions as a supply chain

Most uncomfortable: the instruction-carrying formats. A2A v1.0 introduced signed Agent Cards, with which identity and advertised capabilities can be cryptographically verified. The Agent Skills specification defines mandatory fields for name and description, optional metadata, and an experimental allowed-tools field – but nothing for signature, hashing, publisher identity, or provenance. AGENTS.md is deliberately kept even lighter. Both carry instructions that an agent with significant rights executes – without built-in verification of who wrote them.

A Snyk study from February 2026 examined 3,984 skills from public marketplaces: 534 (13.4 percent) had at least one critical problem, 1,467 (36.8 percent) at least one security problem, 76 malicious payloads were manually confirmed. For MCP registries, an OX Security analysis across 15,465 servers found no consistent authorization model and no uniform lifecycle responsibility. Those who treat skills and servers as configuration rather than software dependencies have an open supply chain.

The gateway as a single point of failure

Two of the ten projects are gateways – a position with unusual leverage. agentgateway routes LLM traffic via an OpenAI-compatible API, supports MCP tool servers and A2A, and enforces JWT, API key, and MCP authentication as well as role-based authorization in CEL. Agent Router, originating from the Envoy AI Gateway and moved to the AAIF on September 10, 2026, connects applications with models and MCP tools and manages backend credentials via its own policy resources.

A gateway in front of agent traffic is a common recommendation. However, one that terminates MCP, A2A, and model traffic simultaneously becomes the point where a parsing error or a credential leak affects all protocols. Since OpenEnv provides MCP interfaces and OpenSandbox provides execution APIs, a vulnerability in shared components can affect the gateway, evaluation environment, and runtime at the same time. Coordinated cross-project vulnerability handling at the foundation level is not publicly documented.

What teams should do now

First, an inventory: Which of the ten projects are present in your own environment, even indirectly via vendor products, and which revision does each component implement? AGENTS.md files and skills deserve the same attention as code – review on changes, installation only from an allowlist, scanning for embedded scripts and instruction injection. Then: route MCP and A2A traffic through a policy-enforcing gateway and patch the gateway itself; prefer signed Agent Cards for A2A and reject unsigned cards from external parties; rebuild monitoring from session IDs to headers and trace context; place agent code within an isolation boundary with minimal privileges.

Conclusion

The consolidation is strategically correct: It takes away manufacturers' ability to create lock-in via a proprietary connector and gives architecture committees a neutral contracting party. Only no security promise follows from this. The foundation manages ten artifacts with their own maintainers, release cycles, and security histories; the maturity is visibly uneven.

The next few months are crucial in two areas: whether Agent Skills gets a signature and provenance extension, comparable to A2A Agent Cards, and whether a foundation-wide baseline of threat model, disclosure process, and conformance tests emerges. As long as both are missing, the AAIF stack remains a map of dependencies – and an invitation to check each one yourself.

Sources

Agent Memory 2026: Why the Memory Layer Is Not a Benchmark Victory

saaro — Fri, 06 Nov 2026 12:00:35 +0000

An agent that doesn't remember the first conversation during the second one isn't an assistant, but a form. 2026 will decide whether agents become production-ready – not based on the model, but on what is stored between sessions. The makeshift solution of "putting the entire history into the prompt" has become its own product category: Mem0, Zep, and Letta are vying for the same role. The decisive question is not which memory wins, but which one fits the workload.

Three Architectures, Three Bets

The providers aren't solving the same problem, even if they promise the same thing. Mem0 is a layer you call: add() extracts facts from a conversation, search() retrieves the relevant ones for the next turn. This requires the least integration effort and is often sufficient for preferences and profiles. The price is the flat structure: as soon as relationships between facts matter, the model hits a ceiling.

Zep relies on a temporal knowledge graph. The underlying engine Graphiti stores each edge with a validity window, i.e., the information about when a fact was valid and when it was superseded by a newer one. This allows answering which tariff a customer has today and which they had last quarter – without the model having to guess. Self-hosting means Graphiti plus a graph database; the old Zep Community Edition was discontinued in April 2025.

Letta, originating from MemGPT, shifts the memory into the runtime environment itself. The agent manages its own memory blocks and decides what becomes permanent – with core, recall, and archive storage, similar to an operating system's memory management. To do this, you adopt a runtime, not just an API.

What LoCoMo and LongMemEval Really Measure

The benchmark canon has consolidated in 2026 – each test answers a different question. LoCoMo poses 1,540 questions across multiple conversation sessions, distributed across Single-Hop, Multi-Hop, Temporal, and Open-Domain tasks. LongMemEval tests knowledge updates and cross-session retrieval with 500 questions – exactly what happens constantly in operation. BEAM scales to one and ten million tokens and is thus the only one of the three that cannot be tricked by a larger context window. DolphinBench and STATE-Bench no longer measure memory, but task success.

Mem0 reports 92.5 points on LoCoMo and 94.4 on LongMemEval for its algorithm published in April 2026 – with an average of around 6,900 tokens per query. On BEAM, 64.1 points remain at one million tokens and 48.6 at ten million tokens. The last number is the most honest: with real scaling, the field is open.

The Contradiction in the Numbers

Because the ranking is disputed. Zep has publicly dismantled Mem0's evaluation from 2025: The LoCoMo conversations, with a few tens of thousands of tokens, are too short for a real long-term memory test, the category for knowledge updates is missing, and the dataset has errors in speaker assignment and ground truth. Above all, Zep was implemented incorrectly: swapped roles, appended instead of native timestamps, sequential instead of parallel searches. With a correct implementation, Zep achieves 75.14 percent, Mem0's best graph configuration achieves 68.44 percent.

More remarkable than the exchange of blows is a detail from Mem0's own 2025 table: a simple full-context baseline beats the reported memory variants with around 73 percent. If retelling the entire history performs better than the memory layer, then the benchmark is not measuring the capability it is supposed to measure.

Accuracy vs. Cost

A study from March 2026 compares a Mem0-based fact layer with long-context inference over GPT-5-mini on LongMemEval, LoCoMo, and PersonaMem v2. The result is uncomfortable for both camps: On two of the three benchmarks, the full context was about 33 to 35 percentage points more accurate. On PersonaMem v2, where consistent persona traits matter, the memory was equivalent, and in one comparison slightly better.

The difference lies in the cost profile: Full context pays per turn, and the bill grows with the history – even with prompt caching, which only discounts input tokens by 90 percent. The memory layer has a one-time write phase and then nearly constant read costs. At 100,000 tokens of history, it becomes cheaper after about ten interactions; after 20 questions, it's around 26 percent savings, and the longer the history, the sooner the break-even point is reached.

However, full context is not a safe bet either. In 2025, Chroma tested eighteen models and found that all become less reliable with increasing input length – not at a documented limit, but gradually and unevenly, even for simple retrieval tasks.

When a Memory Layer Pays Off

Four questions decide most cases. First: How many turns run against the same context? With 100,000 tokens of history, the layer usually doesn't pay off under ten turns. Second: Do facts change whose history matters later? Then there's hardly any way around temporal graphs. Third: Are the questions detail- and multi-hop-heavy? Then compression loses exactly the evidence that is needed. Fourth: How are entries deleted? Memory stores personal data – retention is part of the design, not the operation.

You can't avoid your own evaluation. A set of 100 to 200 real user questions with expected answers beats any vendor table. The starting point:

from mem0 import MemoryClient

client = MemoryClient(api_key="...")

client.add("I prefer Python over JavaScript", user_id="martin")
hits = client.search("programming language preferences", user_id="martin")

A hybrid is usually sensible: stable profile facts in memory, the current session in the context window.

Conclusion

Agent Memory has evolved from a tinkering project to infrastructure in 2026 – with benchmarks, prices, and architecture debates. But the numbers that serve as purchase arguments almost all come from the providers themselves, and they contradict each other. The reliable common ground from independent analyses is sobering: A memory layer is primarily a cost and latency technology, not an accuracy technology. Whoever chooses based on a leaderboard buys the wrong kind of certainty. Whoever chooses based on turns, fact structure, and their own measurements gets a building block that makes agents usable across sessions.

Sources

Kubernetes 1.38: Preview of the December 2026 Release

saaro — Thu, 05 Nov 2026 12:00:58 +0000

The Kubernetes release train runs on a three-month cycle — and right on time for the end of the year, the next version is due on December 16, 2026: Kubernetes 1.38. While 1.37 “Garhwal” introduced the AI and security turnaround with Gang Scheduling beta, HPA scale-to-zero, and pod certificates, 1.38 is shaping up to be a release that moves these developments to stable status and further consolidates the platform for modern workloads. Those who are planning their cluster platform strategically should know the roadmap now.

Current status: Beta.0 is out, code freeze approaching

The development cycle for Kubernetes 1.38 began on August 31, 2026. On September 29, the enhancement freeze passed — after that, no new KEPs could be submitted for the release. Since November 4, 2026, v1.38.0-beta.0 is available, and on November 16, 2026 (AoE), the code freeze follows: after that, only critical bug fixes will be accepted. The SIG Release roadmap includes the following milestones:

Milestone	Date
Beta.0	November 4, 2026
Code Freeze	November 16, 2026 (AoE)
KubeCon NA	November 9–12, 2026
Deprecations/Removals Blog	November 23, 2026
rc.0	December 3, 2026
GA (Release)	December 16, 2026

With the code freeze and the planned deprecations blog at the end of November, the feature list will be cemented by GA. As of the end of October, 87 KEPs were tracked for the milestone (15 stable, 27 beta, 42 alpha, 3 without stage labels) — a scope that makes 1.38 the strongest release of the year.

Gang scheduling and workload-aware preemption become GA

The most important feature from a production perspective: Gang scheduling (KEP-4671) and workload-aware preemption (KEP-5710) are targeting stable status. Gang scheduling was introduced in 1.37 as beta (disabled by default, feature gate GenericWorkload). It solves a classic problem of distributed AI/ML/HPC workloads: if a scheduler distributes the pods of a training unit across multiple nodes, the slowest pod blocks the entire job — GPU cycles are wasted. Gang scheduling ensures that a pod group is only scheduled together (“all-or-nothing”).

The combination with workload-aware preemption in 1.38 makes it possible to enforce prioritized AI jobs at the expense of lower-priority batch runs. Both features communicate via the workload API and the PodGroup concept that Kubernetes has provided since 1.37. For operators of GPU clusters and CI farms, this is the production-relevant improvement — eliminating deadlocks in distributed training directly saves infrastructure costs.

DRA grows up: device binding, partitioning, and capacity management

Dynamic Resource Allocation (DRA) went GA in 1.34. In 1.38, three follow-up KEPs are being moved toward stable:

Device Binding Conditions (KEP-5007): Pods can be bound to concrete device instances (GPU UUID, NPU serial number) — a prerequisite for license-bound AI hardware and deterministic device assignment.
Partitionable Devices (KEP-4815): A physical device (e.g., an NVIDIA H200) can be divided into partitions, allowing multiple pods to share a device without interfering with each other.
Consumable Capacity (KEP-5075): Resources such as VRAM are modeled as consumable quotas rather than binary “present/not present” flags.

These three KEPs make DRA truly practical — they close the gap between “GPU as a number” and “GPU as a manageable device with divisibility and binding.”

Platform improvements and convenience

In addition to the big AI topics, 1.38 brings several improvements for daily operations:

kuberc (KEP-3104) becomes stable: After seven years of alpha/beta status, kubectl users finally get a stable configuration file (~/.kube/kuberc) for aliases, default flags, and credential plugin policy. This replaces workarounds with shell aliases.
Pod-level resources become stable (KEP-2837/5419): CPU and memory specifications at the pod level become stable — including in-place resize without pod recreation (previously only stable at the container level). This enables vertical autoscaling without pod churn.
SPDY → WebSockets (KEP-4006): kubectl exec, attach, and port-forward switch from SPDY to WebSockets — an infrastructure change that mainly affects clusters with modern load balancers and firewalls.
Hermetic network-isolated pods and in-place container probe updates are candidates on the tracking board; their status will be decided by the code freeze.

What remains: cgroup v1, IPVS, and the long-term cleanup work

The deprecations blog for 1.38 is scheduled for November 23, 2026, so the final list of removals will only be determined then. What is clear: the long-term migrations already initiated in 1.35–1.37 are continuing:

cgroup v1: failCgroupV1 has already defaulted to true since 1.35 (kubelet does not start on cgroup-v1 hosts). The code removal in a future release (KEP-5573) has been decided; 1.38 does not set a new date here, but the pressure on operators of old node images is increasing.
IPVS → nftables: The IPVS mode of the kubelet proxy layer is on its way out. If you still have IPVS hardcoded in your platform templates, you should include the switch to nftables in your upgrade planning.
End of support for 1.35: When 1.38 is released, Kubernetes 1.35 leaves the three-branch support cycle and will only receive critical security patches.

Conclusion

Kubernetes 1.38 will not be a “big release” with a single new feature, but rather the stabilization run for the AI and platform turnaround that began with 1.35. Gang scheduling, workload-aware preemption, and DRA follow-ups make Kubernetes fit for GPU workloads and deterministic device management — exactly what platform teams need for production AI operations. At the same time, long-standing pain points such as kuberc and pod-level resources are finally being cleared away.

For cluster operators: don’t wait for GA, but start migrating the node base to cgroup v2 and containerd 2.x now. If you are on 1.35, you should plan the upgrade path via 1.36 → 1.37 → 1.38 — and mark December 16, 2026 on your calendar.

Sources

Kubernetes v1.38 Release Information (official, SIG Release) — release cycle, milestones, team
Kubernetes 1.38: Release Date, Schedule and Features (kubernetesinterviewquestions.com, as of October 29, 2026) — 87 KEPs in tracking, feature details: gang scheduling GA, kuberc stable, DRA follow-ons
Kubernetes 1.35 to 1.38: What Actually Changes in Production (Aleksei Aleinikov, September 22, 2026) — candidate analysis for 1.38, hermetic pods, in-place probe updates
Kubernetes Releases (official) — release history, EOL dates, patch releases