Technology Radar Vol 35
Platforms
Adopt
-
46. VictoriaMetrics
We've moved VictoriaMetrics to Adopt because it has matured into a reliable choice for organizations operating large-scale, self-managed observability platforms. As a high-performance, open-source time-series database, it handles high-volume and high-cardinality metrics workloads that can challenge Prometheus. In one of our projects, a VictoriaMetrics cluster handles five million samples per second with 20 to 30 labels per metric, demonstrating its suitability for large-scale deployments.
The platform offers a straightforward single-node version for smaller workloads as well as a clustered architecture that separates ingestion, querying and storage into independently scalable components. It integrates with existing observability architectures by supporting native OpenTelemetry ingestion, Prometheus APIs and remote write support, allowing teams to adopt it without replacing their existing instrumentation and dashboards. Whether used as long-term storage behind Prometheus or as a complete metrics stack with components such as vmagent and vmalert, VictoriaMetrics is a compelling option for infrastructure where retention, cardinality or cost has become a challenge.
Trial
-
47. Kafka share groups
Kafka share groups (introduced in KIP-932, production-ready since Kafka v4.2) bring a new cooperative event consumption model to Kafka, enabling queue-like behavior. Historically, Kafka's traditional consumer groups have imposed a concurrency bottleneck because the number of active consumers can’t exceed the number of partitions. Share groups remove this constraint: individual records are handed to any available consumer in the pool under a per-record acquisition lock, which the consumer must explicitly acknowledge. On failure or timeout, the record is released and redelivered to any consumer in the group, up to a configurable maximum number of delivery attempts. This provides at-least-once delivery with the possibility of duplicate-processing. Records that exhaust their delivery attempts are archived; dead-letter queue support (KIP-1191) is not yet available.
The tradeoff is that share groups don’t guarantee per-partition ordering because records are dispatched and redelivered independently. However, for teams that previously had to run both Kafka and an external queue system, share groups can simplify the architecture by consolidating workloads onto Kafka.
-
48. KServe
KServe is an open-source Kubernetes operator that manages predictive and generative AI inference through custom resources. Rather than acting as an inference engine itself, it orchestrates serving runtimes such as vLLM, SGLang and NVIDIA Triton, separating the lifecycle of a model service from the engine that executes it.
As organizations build AI factories, operating inference across Kubernetes GPU infrastructure becomes a fleet-management problem rather than a matter of running individual model servers. KServe addresses this with two custom resources: InferenceService for conventional machine learning and simpler LLM workloads, with optional Knative-based scale-to-zero, and LLMInferenceService for advanced LLM serving. Built on llm-d and the Gateway API Inference Extension, LLMInferenceService supports multi-node inference, prefill/decode disaggregation and KV-cache-aware routing that directs requests to replicas already holding the relevant cached prefix.
KServe is a CNCF incubating project, and several of our clients use it in production. Our teams prefer it over other tools in this space when building in-house inference platforms on Kubernetes. LLMInferenceService is newer than InferenceService, and its ecosystem is still evolving.
-
49. LibreChat
LibreChat is an open-source, self-hosted AI chat platform that lets people across an organization access models from multiple providers through a single interface. Like Open WebUI, it offers single sign-on, role-based permissions and RAG over uploaded documents. Its agent features make it more than a chat frontend. Administrators decide which MCP servers are available. Users whose role allows it can then build agents on those servers without writing code and share them through a built-in marketplace.
One of our teams built a client's internal AI platform on LibreChat. The team wrote MCP servers for Jira, Confluence, Salesforce, Grafana and the client's own order, inventory and revenue systems. The client's staff then built the agents themselves: sales created one to check availability and book orders, while operations built one to manage contracts. That experience is why we're placing it in Trial. It gives people outside engineering a controlled way to access vetted AI tooling, which is what we've recommended as the answer to AI-accelerated shadow IT. ClickHouse acquired LibreChat in November 2025, and the project remains MIT licensed.
-
50. LiteLLM
LiteLLM has become a widely used open-source AI gateway. Several of our teams route their model calls through it, either as a standalone proxy or as a sidecar. It supports more than 100 LLM providers and offers routing, provider translation, authentication, budgets and guardrails. Its proxy core is being rewritten from Python to Rust to improve performance while retaining the same Python SDK and configuration.
We’re moving LiteLLM from Languages and Frameworks to Platforms in this edition because we now see it more as infrastructure than a library. We’re keeping it in Trial rather than Adopt largely because of security concerns: at the time of writing, more than 25 CVEs have been reported this year alone. Teams using it should apply security patches promptly. To also govern MCP and agent-to-agent traffic, consider combining it with agentgateway.
-
51. Microsoft Copilot Retrieval API
Microsoft Copilot Retrieval API is a streamlined solution for retrieving data from the Microsoft ecosystem for retrieval-augmented generation (RAG). The API retrieves relevant text extracts from SharePoint, OneDrive and content exposed through Copilot connectors. It applies security trimming based on the calling user and respects access controls defined within the tenant. Developers can build organization-aware AI agents without maintaining custom data stores and retrieval pipelines, leaving tasks such as chunking, indexing, data synchronization, reindexing and access control to Microsoft. The Microsoft Copilot Retrieval API is particularly useful for AI systems that need organizational knowledge already stored in Microsoft tools, and we’ve had a positive experience adopting it.
-
52. Restate
Restate is a durable execution platform for building stateful, fault-tolerant applications. Because it journals every step of execution, a service that fails resumes where it left off. Restate also guarantees exactly-once communication between services. An application combines Basic Services for stateless functions, Virtual Objects for concurrent stateful entities and Workflows for multi-step processes.
When we last wrote about Restate, we were assessing it on a large insurance system. It's now a core part of that system, automating an entire insurance business process. The team relies on its state recovery and concurrency control and hasn't had to write its own recovery code. That experience is why we're moving it to Trial. Restate suits long-running processes that wait on a human in the loop or retry many times against legacy systems. It fills the same role as Temporal, which also moves to Trial in this edition. The SDKs are MIT licensed, but the server uses the Business Source License, which rules out offering it to third parties as a managed service.
-
53. Talos Linux
Talos Linux is a minimal, immutable Linux distribution for running Kubernetes. It has no SSH, package manager or interactive shell. You configure nodes declaratively with talosctl through an mTLS-secured gRPC API, and upgrades replace the entire OS image. This design reduces the attack surface and configuration drift associated with general-purpose distributions such as Ubuntu and makes each node a replaceable appliance, in the spirit of immutable servers.
One of our teams runs self-managed Kubernetes on Talos across a large bare-metal fleet for an AI cloud platform and found the control plane easy to provision. Most organizations use a managed service such as Amazon EKS and never interact with the node OS, so Talos is primarily for teams that operate their own nodes. Bottlerocket takes a similar approach on AWS, and Flatcar Container Linux also has traction. In 2026, Yardi acquired Sidero Labs, the developer of Talos. Talos remains open source under MPL-2.0, but teams should watch where the new owner takes it.
-
54. Temporal
Temporal is a durable execution platform for complex business processes that require strong reliability guarantees. Temporal provides workflows with retries, intermediate state persistence, configurable timeouts, human-in-the-loop checkpoints, resumability and visibility into execution progress. It offers both an open-source self-hosted option and a managed cloud service.
We’ve found compelling use cases for Temporal when building internal developer platforms and control planes for AI cloud infrastructure. These systems typically involve multiple long-running infrastructure provisioning tasks whose state must be reconciled later. Temporal's built-in retries, flexible worker queue scheduling, resumability, visibility and durable execution help teams build these types of systems more resiliently.
-
55. vCluster
vCluster provides virtualized Kubernetes control planes for multi-tenant environments. It offers a middle ground between namespace-level multi-tenancy, where tenants share cluster-wide APIs and custom resource definitions (CRDs), and provisioning completely independent clusters, which increases operational overhead. With vCluster, each tenant gets its own Kubernetes API server, controller manager, data store, RBAC and CRDs. The control plane runs as a lightweight workload on the underlying infrastructure, allowing standard tools such as kubectl, Helm and GitOps controllers to interact with each tenant independently.
We've successfully used vCluster to build managed Kubernetes services and AI cloud environments where balancing tenant isolation against operational costs is critical. It’s particularly attractive for AI platforms where different customers may need their own GPU operators, schedulers, inference frameworks and CRDs. For trusted workloads, virtualized control planes can share underlying compute resources. For customer-facing GPU environments, dedicated worker nodes can provide stronger workload isolation while retaining consolidated control plane management. Given its success in production client environments, we're placing vCluster in Trial.
-
56. VictoriaLogs
Developed by the creators of VictoriaMetrics, VictoriaLogs is an open-source log management platform optimized for high-throughput ingestion, compact storage and fast querying of large log volumes. Rather than requiring predefined indexes, its storage engine organizes and compresses log fields into blocks. It uses Bloom filters and timestamp indexes to avoid unnecessary scans and parallelizes queries across CPU cores.
We've had positive experiences using VictoriaLogs while building observability for an AI cloud infrastructure system. At this scale, Kubernetes services generate large volumes of telemetry, making ingestion throughput, query performance and storage efficiency critical considerations. Compared with traditional search-based logging platforms like Elasticsearch, VictoriaLogs offers a capable logging backend with less operational complexity and lower resource overhead. We've also found it particularly attractive for high-cardinality structured logs and arbitrary field searches when compared with Grafana Loki, because it doesn't require the same degree of label design. VictoriaLogs also includes the LogsQL query language for full-text search, transformations and aggregation. It integrates with Grafana for interactive exploration and alerting, while compatibility with OpenTelemetry, Elasticsearch and Loki ingestion protocols allows teams to adopt it without tying applications to a proprietary logging pipeline.
Assess
-
57. Agent Client Protocol (ACP)
While CLI-based coding agents excel at repo-wide implementation and workflow execution, developers still need inline access to agents within their IDEs for rapid code exploration, interactive bug fixing and context-aware editing. Traditionally, this requires individual IDE plugins, creating integration overhead and locking developers into specific editor-agent pairings. Agent Client Protocol (ACP) addresses this by establishing an open, standard boundary between AI agents and host environments, whether that’s VS Code, JetBrains, a terminal window or a CI/CD pipeline.
Much like the Language Server Protocol standardized language support across editors, ACP relies on JSON-RPC to define agent lifecycle and interaction primitives, including session creation and resumption, streaming updates, permission requests and cancellation. ACP complements existing interoperability layers: while the Model Context Protocol (MCP) handles agent-to-tool integration, ACP handles client-to-agent control, making the complete agent harness a swappable component.
-
58. Agent Plugins
Agent Plugins is an open standard for packaging reusable agent components into portable plugins. The first version, launched by a cross-vendor collaboration including Amazon, Microsoft and OpenAI, defines a shared format for agent skills and Model Context Protocol (MCP) servers. Although the specification is deliberately minimal, an open standard is an important step forward for an ecosystem that has so far been fragmented. We've found that the "small interoperability floor" makes it easy to extend an existing skills repository so that it doubles as an Agent Plugin.
-
59. agentgateway
agentgateway is a high-performance gateway for LLM-related traffic, hosted by the Linux Foundation. It supports LLM inference, MCP and A2A communication through a common protocol in both standalone and Kubernetes versions. Core features include cost- and latency-based routing, fallbacks, spending limits, guardrails, MCP tool control and OpenTelemetry observability.
We’re particularly interested in the Kubernetes version because of its deep integration with self-hosted LLM infrastructure. It can use Kubernetes metrics to route requests to a GPU-backed replica that already has the relevant context cached in memory or to a less utilized server based on actual GPU usage. These capabilities make agentgateway worth evaluating for organizations running self-hosted inference stacks.
-
60. AWS DevOps Agent
AWS DevOps Agent is a managed AWS agent platform for AI-driven incident investigation. When an alarm, ticket or chat message triggers an investigation, the platform maps application resources and their relationships, correlates telemetry with recent deployments and code changes, tests hypotheses and presents likely root causes and mitigations for an engineer to act on. Built-in integrations with Datadog, Dynatrace, New Relic, Splunk and Grafana let alerts from those tools trigger investigations and allow the platform to query their telemetry through MCP-based integrations. Connections to GitHub, GitLab, ServiceNow, PagerDuty and Slack, along with custom MCP servers, extend its reach to on-premises and proprietary systems.
Our teams are experimenting with it in production to investigate live alarms. It's early, but the results look promising, suggesting the potential for faster root-cause analysis and less operational toil. Our main reservation is cost transparency. The platform charges per agent-second spent investigating an incident, making costs difficult to predict. Spending can add up quickly without close monitoring. The service has only been generally available since March 2026, so we recommend assessing it with human validation of every finding, tight control over which events trigger investigations and active cost tracking.
-
61. Claude Managed Agents
Claude Managed Agents is Anthropic's hosted service for running general-purpose agents. Teams define each agent's model, prompt, tools, MCP servers and skills. Anthropic provides the rest of a managed agents runtime: the agent loop, sandbox, scheduling and observability. Agents run on a schedule or when an application starts a session through the API. Scheduled runs are suited to recurring background work, such as triaging alerts and proposing fixes as pull requests for human review.
Teams can get started without writing code through the console or use code-based integrations for greater flexibility and control. Agent, environment and schedule definitions can be stored in files applied through a CI pipeline. A credential vault injects credentials into outbound requests without exposing them to the agent. One of our internal teams chose Claude Managed Agents over other agent platforms, including Gemini Enterprise Agent Platform, because it was easier to understand and faster to deliver with.
We're placing it in Assess because our experience is limited to that team and the service is in beta. Unlike Amazon Bedrock AgentCore, it supports only Anthropic's agent harness and Claude models. Anthropic charges for session runtime as well as tokens. Because the service stores sessions, it isn't eligible for Zero Data Retention. Self-hosted sandboxes can keep tool execution within your network, but orchestration and tool results still pass through Anthropic.
-
62. Decision models
A new class of AI models called decision models has emerged since the last Radar. TypeSafe AI released Jev, which it calls a "system one" model, built to make fast, structured decisions. Many other models have followed, including Laya, Nimble and Kev. In contrast to deliberative reasoning models, decision models output predefined structured values instead of generated text. Rather than using reinforcement learning from human feedback (RLHF) to optimize for human preferences, Jev uses reinforcement learning from calibrated decisions (RLCD) to optimize for well-calibrated decisions, where predicted probabilities reflect how often an outcome actually occurs. Their smaller, structured outputs enable faster and cheaper processing. Decision models receive a state and a set of questions. Every question asked against the state must map to one of three types: Noul for yes/no questions that return the probability of a "yes" answer, Choice for categorized multiple-choice options or Score for evaluations on an ordered list of levels or a numerical scale. Decision model use cases include Jev-as-a-judge as an alternative to LLM-as-a-judge, model and tool routing, policy gates and bulk labeling. We recommend teams avoid overenthusiastic LLM use and define evaluation criteria to determine whether a decision model can replace an LLM for classification use cases.
-
63. KAITO
KAITO (Kubernetes AI Toolchain Operator) is a Kubernetes operator that automates the infrastructure needed to self-host open-weight models on your own clusters. Instead of manually configuring GPU nodes and model servers, teams declare a Workspace, KAITO's custom resource for a single model deployment, specifying the model and GPU instance type. The KAITO controller then provisions matching GPU nodes through Karpenter NodePools, estimates GPU memory requirements, tunes the runtime and serves the model through vLLM, exposing an OpenAI-compatible endpoint via a Kubernetes Service.
Our teams began exploring KAITO on AKS to host small language models at lower cost and latency. Previously, running Ollama and vLLM directly on GPU VMs had left them managing drivers, scaling and node configuration manually. Managing the model lifecycle through the same declarative manifests as other workloads promises to reduce much of that toil.
KAITO's scope is deliberately narrow, though. It handles node provisioning and model deployment rather than the broader inference stack, where KServe is more mature and offers capabilities such as KV-cache-aware routing. KAITO is still a CNCF Sandbox project. Its GPU node auto-provisioning is most mature on AKS, and it supports only Ampere-generation or newer NVIDIA GPUs. We think it's worth assessing, particularly for teams that want to self-host models using their existing Kubernetes tooling.
-
64. llm-d
llm-d is an open-source distributed inference serving stack designed to operate model servers such as vLLM and SGLang across multiple Kubernetes nodes. Traditional web applications often rely on stateless routing and horizontal scaling, but LLM inference is highly stateful due to key value (KV) caching. Rather than treating model-serving pods as interchangeable HTTP backends, llm-d uses inference-aware routing to coordinate requests across multiple accelerators, extending optimization beyond individual model servers.
Built around Kubernetes and the Gateway API Inference Extension, llm-d offers several capabilities tailored to stateful AI traffic. It supports model-aware and KV-cache-aware routing, using factors such as cache affinity, queue depth and predicted latency to guide scheduling decisions. A notable feature is prefill and decode disaggregation, which allows operators to place compute-intensive prefill workloads on one set of GPUs and memory-bandwidth-bound decoding tasks on another. This can improve hardware utilization and reduce inference costs. Teams building large-scale GPU inference platforms should assess llm-d as an emerging foundation for their inference layer, particularly when looking to scale while meeting strict latency objectives.
-
65. Netris
Netris is an out-of-band network automation and multi-tenancy platform for physical data centers and AI infrastructure. Using a declarative, infrastructure-as-code model accessible through a UI, an API, Kubernetes CRDs and Terraform, it simplifies network management by abstracting switch configurations into cloud-style virtual private clouds (VPCs), virtual networks, access control lists (ACLs) and Layer 4 load balancers. A central controller manages policies while lightweight agents execute changes on switches and data processing units (DPUs). The controller operates out-of-band as an automation control plane, so packet forwarding can continue uninterrupted even if the controller goes offline.
We’re highlighting Netris for its support of high-bandwidth AI workloads. It automates routed Ethernet VPN (EVPN) fabrics, manages flow control for RDMA over Converged Ethernet (RoCE) and orchestrates NVIDIA BlueField DPUs for hardware-enforced multi-tenancy. It also integrates with NVIDIA UFM for InfiniBand partition keys (PKeys) and NMX-C for NVLink domains, helping manage multi-tenant boundaries across different AI fabrics through a unified management layer. We’re placing Netris in Assess for teams building automated private clouds or AI data centers, although teams should evaluate compatibility with their switch operating systems, such as SONiC, Cumulus Linux and Arista EOS, as well as the boundaries of bare-metal orchestration support.
-
66. Omnigent
Netris is an open-source meta-harness, released by Databricks, that sits above coding agents such as Claude Code, OpenAI Codex and Pi, as well as agents defined in YAML. It provides a common layer for capabilities that each harness otherwise implements differently. Policies can cap spending or require approval before a risky action, while an OS sandbox restricts file system and network access and swaps credentials into outgoing requests, so the agent can use them without reading them. Sessions persist, allowing a run to resume where it stopped. Omnigent can also communicate with agents through the Agent Client Protocol (ACP) instead of wrapping each CLI.
On a laptop, Omnigent gives a developer an inbox of parallel sessions, much as Herdr does. As a shared server, it adds single sign-on, live session sharing and administrator-set policies, with sessions running locally or in cloud sandboxes such as E2B. This suits organizations that want consistent controls regardless of which coding agents their developers choose. We aren't yet sure what the right abstraction over coding agents is, and the project still describes itself as alpha. Teams that want consistent policies across several coding agents should evaluate Omnigent with both caveats in mind.
-
67. VAST DataStore
VAST DataStore is the storage layer of the VAST Data platform. It provides file (NFS and SMB), object (S3) and block (NVMe/TCP) access through a unified namespace. Its disaggregated shared-everything architecture separates stateless compute nodes from shared NVMe storage, allowing capacity and performance to scale independently. We're assessing it because storage throughput increasingly affects how efficiently expensive GPU clusters operate during training, checkpointing and model loading. DataStore lets workloads retain conventional NFS/POSIX or S3 access while using NVMe and RDMA for faster data transfer, offering an alternative to specialized parallel file systems. VAST is also working with NVIDIA on S3 over RDMA and shared KV-cache storage for disaggregated inference.
Compared with Ceph, which offers open-source block, file and object storage on commodity hardware, DataStore is a proprietary platform designed for NVMe, RDMA and AI workloads. However, it’s expensive and ties you to VAST's broader data platform, so it may be more than teams need unless they're training models or running large-scale inference. We think VAST DataStore is worth assessing for teams designing large GPU clusters for AI and high-performance computing (HPC) workloads, where data loading, checkpointing and metadata-heavy access to billions of files can leave expensive GPUs waiting on storage.
Caution
The information in our interactive Radar is not available in your preferred language.
Unable to find something you expected to see?
Each edition of the Radar features blips reflecting what we came across during the previous six months. We might have covered what you are looking for on a previous Radar already. We sometimes cull things just because there are too many to talk about. A blip might also be missing because the Radar reflects our experience, it is not based on a comprehensive market analysis.
