Team IT Security - 📰 Alle Kategorien

Prioritizing Memory Efficiency: Essential Steps for Android 17

Sat, 25 Jul 2026 10:15:41 +0200

Posted by Alice Yuan, Developer Relations Engineer, Ajesh Pai, Developer Relations Engineer, and Fung Lam, Developer Relations Engineer

While app performance is often equated with a smooth UI and fast start times, memory serves as the silent foundation upon which these visible metrics are built. It's no secret that we're seeing a shift where device memory is more important than ever. Not only have we made strides in Android memory optimizations with Android 17, we're providing the tooling and API support to help you stay ahead of stricter memory requirements later this year.

To ensure device stability, starting in Android 17, the system will begin enforcing app memory limits based on the device's total RAM. If an app exceeds those limits, Android will kill the process with no associated stack trace.

Beyond these forced terminations, unoptimized memory usage inevitably degrades the user experience. When the app approaches heap memory limits, it triggers frequent garbage collection—leading to noticeable UI stutters. Furthermore, when a device runs out of available memory, the system scrambles to reclaim pages, causing CPU strain, UI latency, and battery drain. If the memory shortage is too severe, it can cause Low Memory Killer (LMK) events that abruptly terminate background processes and force apps to have slow cold starts and lose user state.

To build highly performant apps and avoid these forced terminations, we recommend that you adopt the following memory optimization strategies:

A condensed version of this blog post is also available in video format, go check it out!

Understanding Android 17 app memory limits

App memory limits are being introduced in Android 17 to prevent "one bad actor" from destroying the multitasking experience and stability of the user’s entire device.

Here is a breakdown of the reasons driving this architectural change:

Preventing cascading kills: When an app becomes bloated or leaks memory while holding a privileged state (e.g. it’s running a Foreground Service), it is initially shielded from the system's Low Memory Killer (LMK). As this single app grows unchecked and hoards RAM, the LMK is forced to compensate by killing off dozens of smaller, well-behaved cached apps and background jobs to reclaim space for the memory hog.
Preserving multitasking and user state: When the system is forced to purge cached apps to accommodate a single leaking process, the multitasking experience is severely degraded. Users returning to prior cached applications encounter sluggish cold starts instead of near-instant warm resumes. This inefficiency generates more CPU strain and accelerates battery depletion. It can also destroy the user’s context in recently used apps, such as scroll positions, navigation stacks, and in-game progress.

To determine if your app session was impacted by these constraints in the field, you can call getDescription() within ApplicationExitInfo. If the system applied a limit, the exit reason is reported as REASON_OTHER and the description string will contain "MemoryLimiter:AnonSwap". You can also leverage trigger-based profiling using TRIGGER_TYPE_ANOMALY to automatically capture heap dumps when the memory limit is reached. Furthermore, Android is actively working to surface more in-field memory metrics to developers within the Google Play Console.

We have also expanded our memory limits documentation to include local debugging commands, allowing you to simulate memory constraints in your local environment and validate your application's behavior under any memory limit enforcement.

Maximize bytecode optimization with R8

A highly effective way to reduce your app's memory footprint is to enable the R8 optimizer. By shrinking classes, methods, and fields into shorter names and stripping out unused code and resources, R8 significantly reduces your app's memory footprint by minimizing the amount of resident code required during execution.

R8 minimizes resident code, shrinking the memory footprint and lowering LMK termination risk. This results in more frequent warm starts over slow cold starts. Additionally, streamlined bytecode reduces main-thread CPU overhead, directly cutting ANR rates for a more fluid user experience. For example, the digital bank Monzo enabled full R8 optimization and saw a 35% reduction in their ANR rate, a 30% improvement in cold start rate, and a 9% reduction in overall app size.

The digital bank Monzo enabled full R8 optimization and boosted performance metrics by up to 35%.

To properly configure R8 in your build.gradle file:

Set isShrinkResources = true and isMinifyEnabled = true.
Use proguard-android-optimize.txt instead of the legacy proguard-android.txt, which actually prevents optimizations and is no longer supported in Android Gradle Plugin 9.
Remove android.enableR8.fullMode = false from your gradle.properties.

If you are using reflection in your code base, then add Keep rules to prevent R8 from optimizing those parts of the code. Make sure to scope the keep rules narrowly to get the maximum optimization.

To get the maximum optimization, make sure to follow these best practices in your keep rule file.

Remove global options like -dontoptimize, -dontshrink, and -dontobfuscate that prevent R8 from optimizing the entire codebase
Remove keep rules that prevent optimizing Android components like Activity, Services, Views or Broadcast receivers.
Refine the broad package wide keep rules to target only specific classes or methods.

To see more best practices, view our keep rules documentation.

Library Developer R8 Best Practices

If you are a library developer, strictly place the rules your consumers need into your consumer-rules file, and keep your library's internal protection rules in your proguard-rules.pro file. For more information on how to optimize libraries, see Optimization for library authors.

R8 Configuration Analyzer

To audit your R8 optimization, use the Configuration Analyzer. Configuration analyzer shows the current state of optimization with Obfuscation, Optimization, and Shrinking scores. With configuration analyzer, you can also understand how many classes, methods or fields are prevented from optimization by each keep rule. Refine these broad package wide keep rules to unlock the maximum optimization.

Using configuration analyzer, you can also identify keep rules that are subsuming other keep rules, redundant keep rules and unused keep rules.

The Configuration Analyzer shows the current state of optimization with Obfuscation, Optimization, and Shrinking scores.

R8 Agent Skill

You can also leverage the R8 Agent Skill with Android Studio agent or other AI tools to resolve misconfigurations and refine your rules resulting in improved app performance. (Insights from AI-driven skills will require technical verification)

Optimize image loading

Bitmaps are usually the largest common objects residing in your app's memory. They represent the final stage of the image loading process where compressed files, like JPEGs or PNGs, are decoded into raw pixel data for display. This means a tiny 100KB compressed image can balloon into several megabytes of RAM because memory consumption is determined by the image's pixel dimensions and color depth. Since bitmap operations are frequently on the critical path to drawing frames, unoptimized images cause severe memory bloat and UI jank.

Google recommends leveraging image loading libraries Coil for Kotlin-first projects, particularly when developing with Jetpack Compose and Glide for Java-based applications.

Adopt these five best practices

Downsample images: If you’re loading bitmaps manually, avoid loading a massive image into a tiny thumbnail view; use inSampleSize to load a smaller version. Glide and Coil downsamples images by default and you can configure this downsample strategy using DownsampleStrategy and ImageLoader respectively.
Cropping: Avoid embedding padding directly into an image file for letterboxing purposes (e.g., creating a transparent border to expand an image dimensions). Rather than baking in these borders, utilize InsetDrawable or apply padding directly within the View or Composable containing the bitmap.
Config: Balance memory and quality by choosing the right pixel format. Use RGB_565 when transparency isn't needed, which uses half the memory of the default ARGB_8888 format. In Glide you can configure this by using DecodeFormat and in Coil you can use bitmapConfig property.
Prioritize vector drawables: For basic geometric assets, leverage ShapeDrawable as a lightweight alternative to decoding rasterized bitmaps. By defining these assets once via XML, you ensure they scale seamlessly across all display densities while effectively eliminating resource-driven memory bloat.
Reuse: If your application manages Bitmaps manually then to minimize memory churn, when a bitmap is no longer required, the app should call bitmap.recycle() and immediately discard the Bitmap reference. If you use an image loading library like Glide or Coil, return the bitmap to the library’s managed pool. By providing an existing buffer for future memory needs, the pool effectively avoids the overhead of new allocations.

Check out our documentation on Optimizing performance for images to learn more.

Android Studio tooling

You can also eliminate redundant bitmaps using Android Studio Narwhal 4. Here is how to hunt them down in five simple steps:

Open the Profiler tab in Android Studio
Click Heap Dump (or "Analyze Memory Usage") and hit record to take a snapshot of your app’s current memory state.
Scan the analysis results for the yellow warning triangle ⚠️, which Android Studio uses to flag duplicate bitmaps being stored multiple times. Alternatively, navigate to the profiler header, choose "Filter by:" and pick the "Duplicate Bitmaps" setting.
Click on any flagged entry to open the Bitmap Preview pane, allowing you to see exactly which image is the repeat offender.
Use that visual confirmation to track down the redundant loading logic in your code and implement a better caching strategy.

Look for the yellow warning triangle ⚠️ in heap dumps when using the Android Studio Profiler.

Detect and fix memory leaks with Android Studio

Memory leaks in Android occur when your code holds onto an object's reference long after its lifecycle has ended. This prevents the Garbage Collector (GC) from reclaiming that memory, eventually leading to sluggish performance or OutOfMemoryError (OOM).

Android Studio Panda 3 features a dedicated LeakCanary profiler task, allowing developers to analyze real-time memory leaks and map traces within the IDE.

The LeakCanary profiler task in Android Studio actively moves the memory leak analysis from your device to your development machine, resulting in a significant performance boost during the leak analysis phase as compared to on-device leak analysis.

LeakCanary memory leak analysis contextualized with Go to declaration for debugging

Additionally, the leak analysis is now contextualized within the IDE and fully integrated with your source code, providing features like go to declaration and other helpful code connections that drastically reduce the friction and time required to investigate and fix memory leaks.

Examples of common memory leaks

Memory leaks occur when an object persists in memory beyond its intended lifespan. This typically happens due to:

Retaining references to Fragments, Activities, or Views that are no longer in use.
Mismanaging Context references.
Failing to properly unregister observers, listeners, and receivers.
Creating static references to objects that are bound to components with shorter lifecycles.

Here are a few example scenarios:

Scenario	Compose-based example	View-based example
Leaking Context	Example: Passing LocalContext.current to a ViewModel Fix: Keep `Context` dependent logic within the UI layer. For non-UI layers, refactor to use dependency injection or observe UI state using Kotlin flow.	Example: Storing an `Activity` in a companion object or static variable. Fix: Don’t hold static references to UI components. Refactor to use dependency injection or observe UI state using Kotlin flow.
Leaking Listeners	Example: Using `DisposableEffect` to start a listener but leaving `onDispose` empty. Fix: Perform the unregistration and cleanup logic inside the `onDispose` block.	Example: Registering for SensorManager updates and forgetting to unregister. Fix: Manually call `unregisterListener()` in `onStop()` or `onDestroy()` lifecycle.
Leaking Views	Example: Holding a reference to a legacy `View` inside an `AndroidView` without a release strategy. Fix: Use the `release` block of the `AndroidView` composable to clean up the legacy `View`.	Example: Keeping a reference to a view binding object after the `Fragment` is destroyed. Fix: Set the binding variable to `null` inside the `onDestroyView`() lifecycle method.

Trim memory when app leaves visible state

Android can reclaim memory from your app or stop your app entirely if necessary to free up memory for critical tasks, as explained in Overview of memory management. Android will usually reclaim memory from your app when it’s not visible to the user, such as by discarding some of your app’s code and data pages in memory or compressing your heap allocations. When the user resumes your app and your app tries to access some memory that’s been reclaimed, the OS will swap that memory back in on demand. This swapping behavior can be slow, and cause unexpected jank or stutters in your app.

If you leave it to the OS to decide what memory to reclaim from your app, you may find that the OS reclaimed memory that you’ll need shortly after resuming your app. Instead, your app can voluntarily discard memory allocations that it can regenerate later, on demand and at a low cost. To do so, you can implement the ComponentCallbacks2 interface. You can implement onTrimMemory in your Activity, Fragment, Service, or even your custom Application class. Using it in the Application class is highly effective for global cache management.

The provided onTrimMemory() callback method notifies your app of lifecycle or memory-related events that present a good opportunity for your app to voluntarily reduce its memory usage.

In terms of memory lifecycle management, your implementation should focus exclusively on TRIM_MEMORY_UI_HIDDEN and TRIM_MEMORY_BACKGROUND. Since Android 14, the system has ceased delivering notifications for other legacy constants, which were formally deprecated in Android 15.

TRIM_MEMORY_UI_HIDDEN: This signal indicates that your application's UI has transitioned out of the user's view. This provides an opportunity to release substantial memory allocations tied strictly to the interface—such as Bitmaps, video playback buffers, or complex animation resources.

TRIM_MEMORY_BACKGROUND: At this level, your process is residing in the background and is now a candidate for termination to satisfy the system's global memory needs. To extend the duration your process remains in the cached state, and reduce the number of app cold starts, you should aggressively release any resources that can be easily reconstructed once the user resumes their session.

import android.content.ComponentCallbacks2
// Other import statements.

class MainActivity : AppCompatActivity(), ComponentCallbacks2 {

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that is raised.
     */
    override fun onTrimMemory(level: Int) {

        if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
            // Release memory related to UI elements, such as bitmap caches.
        }

        if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
            // Release memory related to background processing, such as by
            // closing a database connection.
        }
    }
}

Note: The onTrimMemory integration may depend on SDK support. For instance, certain games rely on their game engine to enable this capability. Please check out the game memory optimization documents.

Advanced memory observability with ProfilingManager

To catch and diagnose memory issues in the field that cannot be reproduced locally, you should leverage the ProfilingManager API. Introduced in Android 15, this advanced observability API allows you to programmatically collect real-user Perfetto profiles.

For teams that lack a dedicated infrastructure to manage and host performance artifacts, Crashlytics is exploring a specialized solution to streamline this workflow. They are inviting developers to provide feedback.

Android 17 introduces new event-driven triggers, most notably TRIGGER_TYPE_OOM and TRIGGER_TYPE_ANOMALY:

The OOM trigger automatically collects a Java heap dump at the exact moment an OutOfMemoryError crash occurs, providing precise allocation states. A collected OOM profile is provided the next time the app starts and registers the registerForAllProfilingResults callback.
The Anomaly trigger detects severe performance issues, such as excessive binder spam or breached memory thresholds. The memory anomaly delivers a heap dump just prior to the system terminating the app.

  val profilingManager = 
applicationContext.getSystemService(ProfilingManager::class.java)
    val triggers = ArrayList()  


    triggers.add(ProfilingTrigger.Builder(
                 ProfilingTrigger.TRIGGER_TYPE_ANOMALY))
    val mainExecutor: Executor = Executors.newSingleThreadExecutor()
    val resultCallback = Consumer { profilingResult ->
        if (profilingResult.errorCode != ProfilingResult.ERROR_NONE) {
            // upload profile result to server for further analysis          
            setupProfileUploadWorker(profilingResult.resultFilePath)
        } 

    profilingManager.registerForAllProfilingResults(mainExecutor, resultCallback)
    profilingManager.addProfilingTriggers(triggers)

Once you’ve collected the heap dump, you can download the profile from the server, or locally via adb pull and drag and drop the file into the Perfetto UI. To streamline your memory debugging workflow, use the Heap Dump Explorer, this is the new default view for heap dumps in Perfetto UI. This tool provides an intuitive interface for inspecting Java heap dumps, allowing you to visualize object allocation hierarchies, compute retained memory sizes, and identify the shortest path from garbage collection root. By leveraging the Heap Dump Explorer, you can rapidly pinpoint memory leaks, bloated retained objects such as excessive bitmap allocations, and analyze heap object allocations all in one place.

Use the Heap Dump Explorer’s embedded flamegraph to visually inspect and navigate through objects with the highest heap allocations.

Conclusion

Optimizing bytecode with R8, adopting image loading best practices, and resolving memory leaks are critical steps toward delivering a high-quality user experience while managing resources effectively under pressure. Adopting these proactive measures helps maintain app stability and performance, preventing unexpected terminations while safeguarding user context. To further your performance expertise, explore our revised memory guidance.

Datadog delivers millions of in-depth performance insights with ProfilingManager

Sat, 25 Jul 2026 10:15:39 +0200

Posted by Alice Yuan, Developer Relations Engineer at Google, Arti Arutiunov, Product Manager at Datadog and Nikita Ogorodnikov, Staff Software Engineer at Datadog

Performance regressions are notoriously hard to reproduce, making regressions a massive bottleneck for mobile developers. Although signals like ANR rates indicate what issues occur in production, pinpointing the specific line of code that resulted in the performance issue has historically necessitated exhaustive manual reproduction or speculative trial-and-error experimentation.

Datadog collaborated with Google to mitigate this frustration by integrating the ProfilingManager API (available on Android 15+ devices) into its Real User Monitoring (RUM) and Continuous Profiling platforms. This integration transforms the debugging workflow, allowing developers to move beyond surface-level symptoms to being able to detect the why behind a performance bottleneck.

By leveraging this system-level API, Datadog now processes millions of production profiles weekly across the globe according to Datadog internal data of June 2026. It provides engineering teams with a new level of visibility into real-world performance, all while maintaining a low runtime overhead for production-scale performance monitoring.

The impact of ProfilingManager

ProfilingManager is a system service introduced in Android 15 that enables apps to programmatically collect performance data such as call stack samples, field traces and memory heap dumps directly from production environments. This capability shifts the engineering paradigm from reactive manual reproduction to proactive field analysis.

For example, a Google communications app used field traces to investigate why its cold start times were slower on newer, more powerful hardware. By diving into the field-collected traces and comparing traces across different device types, the engineer discovered a hidden scheduling issue: a background text-to-speech service was unnecessarily being prewarmed during app startup. The traces revealed that this background process was monopolizing the device's highest-performing big CPU core, forcing the app's main thread to sleep while the prewarm occurred.

Solving the Android code-level visibility challenge

Prior to the implementation of ProfilingManager, Datadog’s Real User Monitoring (RUM) focused on high-level application health and session-level telemetry to assess the user journey. Engineering teams could monitor Android performance signals like time to initial display, ANR rates, CPU load, and frozen frames. These insights extended to granular interactions, such as network latency, touch events, and main thread hangs. However, while this data effectively highlighted which performance bottlenecks were surfacing in the field, it provided no clear path to identifying the root cause of these failures.

To address this, Datadog needed a profiling engine capable of capturing Android traces directly from devices in production with minimal performance impact. After evaluating alternative approaches, such as writing their own trace processor using Android Debug APIs, the team selected ProfilingManager because it is the most performant solution of the profiling options they evaluated and offloads the sampling decisions overhead to the OS.

ProfilingManager supports a wide range of collection methods, including CPU traces, call stack sampling, memory analysis through Java heap dumps and native heap profiles. It enables developers to profile production builds, upload trace files to external storage, and review them in the Perfetto trace analyzer UI. As a SaaS provider, Datadog uploads, visualizes, and analyzes these profiles collected via its SDK, providing a unified view of application health.

By centralizing high-fidelity telemetry within a unified observability API, ProfilingManager empowers Datadog and its clients to proactively monitor, investigate, and remediate complex Android performance regressions through key technical advantages:

Granular session diagnostics: ProfilingManager enhances debuggability by delivering direct OS-level trace data, overcoming the visibility and alignment challenges typical of custom logging with system services. To dive deeper, developers can download these traces from Datadog to investigate further in visualization tools like the Perfetto UI.
Automated telemetry triggers: By leveraging native system events to initiate trace recordings at key optimization points, Datadog reduces the need to build custom collection logic. While the initial rollout focuses on the APP_FULLY_DRAWN signal, there are already plans to expand this observability to include ANR, OOM, and COLD_START triggers.
Proactive trace snapshots: By interfacing directly with the system-level Perfetto service (traced), ProfilingManager utilizes a proactive background recording model designed to capture unpredictable issues. This ensures that developers receive a precise visualization of the events leading up to a performance anomaly, offering a level of insight that exceeds what is possible through manual instrumentation.
Bottleneck detection at scale: Datadog is able to synthesize telemetry from across Datadog’s global customer base to uncover regressions that only emerge under unique hardware configurations and variable network environments.
System-enforced resource stability: The API leverages sampling trace collection to ensure performance and user experience impacts remain unnoticeable.
On-device data controls: ProfilingManager filters out irrelevant information from other processes on-device before the profile is delivered to the app. This minimizes file sizes and ensures that only data relevant to the app's processes is provided.

Processing millions of weekly profiles to optimize real-world apps

An example of Datadog's time to initial display measurement with
stack sampling powered by ProfilingManager

Integrating a system-level profiling API into a global monitoring SDK required solving infrastructure challenges. Because ProfilingManager generates highly detailed performance traces, the Datadog engineering team had to build a pipeline capable of parsing and analyzing these profiles on the server side at scale. Beyond profile collection, Datadog also emphasizes the importance of balancing sampling frequency with collecting enough data to generate meaningful insights about your application. Datadog relies on ProfilingManager’s built-in rate limiting as a critical stability safeguard, preventing excessive telemetry requests from overburdening user devices.

The team has been profiling Datadog's own native Android application and a number of early adopters’ applications for months, gathering millions of profiles to ensure a fast, error-free launch experience and to refine their performance-detection algorithms. Today, the production integration seamlessly scales across a variety of Android devices.

Conclusion

By integrating Android’s ProfilingManager API, Datadog successfully closed the visibility gap between backend systems and mobile client applications for their customers. By processing millions of profiles weekly with negligible device overhead, Datadog equips Android developers with the code-level insights necessary to diagnose complex performance bugs instantly, helping developers build smoother applications and improve their app’s performance signals in the Play Store. To adopt the ProfilingManager API directly into your performance observability framework, check out our documentation.

In the future, Datadog aims to make Android profiling data a first-class input for coding agents to autonomously resolve performance bottlenecks, closing the feedback loop between detection and remediation. Datadog is working toward making Android profiling broadly accessible to developers.

To get started using the Datadog real user monitoring feature powered by ProfilingManager, visit Datadog Mobile Real User Monitoring.

Cisco, AMD partner to bring enterprise-level security, visibility to Ryzen AI Halo systems

Fri, 24 Jul 2026 19:18:26 +0200

Cisco and AMD have expanded their partnership with a new package of hardware and security software that’s designed to help enterprise customers protect, deploy, and manage distributed AI resources.

During AMD’s Advancing AI event this week, Cisco’s president and chief product officer Jeetu Patel took to the stage during AMD CEO Lisa Su’s keynote to talk about how AI inference will be widely distributed and will require an architectural stack of software and tools that Cisco and AMD are partnering to develop.

The joint architecture combines AMD’s compact, high-performance Ryzen AI Halo hardware and a variety of Cisco networking, observability, governance, and security technologies. “AMD provides the deskside/local AI platform. At the foundation is AMD Ryzen AI Halo hardware, an isolated agent sandbox and the services needed for local-first inferencing, including model routing and token limits via AMD’s Semantic Router and local inference on Lemonade,” wrote Cisco’s Yash Sheth, senior director, engineering and research, in a blog post about the new package.

Ryzen AI Halo (pictured below) is designed to support local AI inference on an AI PC using its CPU, GPU, and XDNA neural processing unit (NPU), according to AMD. A resilient AI platform should continue delivering useful AI services even when connectivity is limited, models need to change, or workloads shift, AMD stated.

width="1024" height="576" sizes="auto, (max-width: 1024px) 100vw, 1024px">

AMD

Cisco then wraps that platform in a secure harness that includes its Splunk Agent Observability plus Splunk Infrastructure Monitoring to provide full-stack observability, tracking agent behavior, tokenomics and compute operation, according to Sheth.

Cisco also brings its AI Defense for model and agent security; DefenseClaw for security policy enforcement, so guardrails are enforced directly on-device, within the agent harness; and Cisco Cloud Control offering a single pane of glass for unified policy and control, Sheth stated.

“To make deskside and local AI computing work at enterprise scale, every AI node must be treated as a secure, managed node in the enterprise network,” Sheth wrote.

“The need for token efficiency and data sovereignty is driving a new class of computing, deskside computing, with users and teams putting AI agents right by their sides,” Sheth wrote. “Inference is moving to a hybrid architecture with thousands of ambient deskside agents in an enterprise helping employees have 24×7 productivity. That’s an extraordinary opportunity. It’s also a brand-new operating challenge.”

As agentic AI moves from experimentation to real enterprise workflows, organizations need more than powerful endpoints. AI agents can run continuously and act on enterprise data, but create new requirements for network infrastructure, tokenomics, agent behavior, and security, according to a statement from AMD.

“Running more AI locally can help improve responsiveness, keep sensitive data closer to users, and reduce dependence on cloud-only approaches, but enterprises also need a way to monitor and manage these systems at scale. AMD and Cisco are addressing that gap by collaborating to pair high-performance local AI compute with the observability, governance, and control infrastructure needed for enterprises to deploy it responsibly,” AMD stated.

“By combining AMD Ryzen AI Halo systems and our broader local AI software capabilities with Cisco’s enterprise networking, observability and security technologies, we are helping customers deploy AI in a way that is performant, secure, observable and manageable at scale,” said Jack Huynh, senior vice president and general manager, computing and graphics group with AMD, in a statement.

A few other interesting statistics and trends cited in AMD CEO Su’s keynote include:

AI adoption is accelerating across all industries, with agentic AI driving a surge in compute demand and shifting workloads from training to inference, which accounts for 60% of global AI compute capacity in 2026.
AI is moving beyond the cloud, with edge and personal devices becoming critical for real-time, distributed intelligence.
The AI accelerator market is projected to reach $1.4 trillion by 2030, nearly tripling previous forecasts, with GPUs expected to dominate but CPUs gaining new growth vectors due to agentic AI.
Server CPU market is forecasted to grow over 50% to $200 billion by 2030, fueled by rapid agentic AI adoption and the need for massive CPU infrastructure.

Warum LLM-Observability zum Sicherheitsfaktor für KI-Systeme wird

Fri, 24 Jul 2026 12:28:11 +0200

Agentische KI verändert, wie Software agiert und welche Risiken entstehen. Warum Observability neu gedacht werden muss, um autonome Systeme sicher, transparent und handhabbar zu machen.

Agentic orchestration: Enterprise AI organizations have a deployment problem, not a platform problem — and most are calling chatbots agents

Thu, 23 Jul 2026 19:19:45 +0200

Across 101 enterprises, agent orchestration is consolidating onto model-provider platforms — Anthropic’s Claude leads by a wide margin — chosen for the gravity of the underlying model and judged on reliable multi-step execution. But the ambition runs well ahead of the reality: most deployed “agents” are still chatbot wrappers, the control plane enterprises expect is deliberately hybrid to avoid lock-in, and real-time fiscal control over token burn remains the exception.

This wave of VentureBeat Pulse Research examines enterprise agent orchestration: which platforms enterprises run on, what drives the choice, what they optimize for, how they expect agent control to be structured, and — most revealingly — how orchestrated their deployed “agents” actually are and how tightly they control the cost of running them.

The central finding is a gap between orchestration ambition and orchestration reality. Enterprises are consolidating fast onto the major model platforms: Anthropic’s Claude is the primary platform for 40%, more than double any rival, followed by Microsoft (18%) and OpenAI (13%). The choice is driven by “model gravity” — native alignment with a state-of-the-art base model (21%) — and success is judged by reliable, multi-step execution (task completion reliability 32%, multi-step workflow management 28%). Yet asked to assess their portfolios honestly, 71% say a quarter or fewer of their deployed “agents” are true multi-step orchestrated workflows rather than single-prompt chatbot wrappers, and only 10% have crossed the halfway mark. The orchestration layer is being built well ahead of the orchestrated portfolio it is meant to run.

That gap shapes the architecture enterprises are putting in place. By the end of 2026 a clear majority (51%) expect a hybrid control plane — provider-native plus external orchestration — and only 6% expect to hand control to a provider-managed service, because vendor lock-in (35%) is the risk they fear most if control lives inside a model provider. Investment follows the build-out: agent workflow tooling leads the spend (34%), with security and permissions enforcement (25%) behind. And fiscal control lags throughout — more than a quarter (27%) have no real-time way to stop a runaway agent before the bill arrives.

Methodology

VentureBeat fielded this survey as part of its ongoing Pulse Research series, this instrument focused on enterprise agent orchestration. Responses are filtered to organizations with 100 or more employees (n=101), drawn from a single June 2026 wave; because this is one wave rather than a pooled multi-month sample, the report reads cross-sectionally and does not infer month-over-month trends.

By organization size the sample is spread evenly across the enterprise bands: 100–499 employees, 2,500–9,999, and 50,000+ (21% each), with 10,000–49,999 and 500–2,499 (19% each). By role it is senior and buyer-credible: product and program managers (15%), CIO/CTO/CISO (13%), consultants and advisors (13%), and a spread of data, AI, and engineering directors and VPs, with an “Other” function at 18%. On purchasing, 81% are recommenders, influencers, or final decision-makers for AI solutions (66% recommender/influencer, 15% final decision-maker). Technology/Software is the largest industry at 44%, followed by Financial Services (17%) and Healthcare/Life Sciences (8%).

At 101 respondents the sample is robust enough to read directionally with reasonable confidence, though it remains self-selected and is not a probability sample.

Finding 1: Orchestration runs on model-provider platforms

Anthropic’s Claude leads; open frameworks are marginal

We asked which agent orchestration platform enterprises primarily use today. The answer concentrates on the major model providers — and on one in particular.

A note on reading these shares. As described in the methodology section, the respondents are self-selected, and this question asked them for a single primary platform — so the figures measure which platform leads each enterprise's deployment, within a self-selected audience of AI-active technical decision-makers. A sample built this way can diverge substantially from spend-weighted market measures, and each VB Pulse survey draws its own sample with its own company-size mix, so vendor figures should not be compared across our surveys either. Read these shares as a portrait of where this cohort has placed its primary orchestration bet today, rather than as market share.

The model platforms dominate. Anthropic, Microsoft, OpenAI, Google, and Amazon together account for roughly 80% of deployments (81 of 101), while the open frameworks (LangChain/LangGraph) and custom in-house builds that anchor engineering discussion sit in single digits. Anthropic’s lead — 40%, more than double the next platform — mirrors the “model gravity” selection logic in Finding 2: enterprises are choosing the orchestration layer that comes with the model they want to build on. As with the security vendors in the prior agent-security wave, the tools that define the category in technical circles are not yet where enterprise deployment concentrates. A small 3% are not orchestrating at all.

Respondents rate the platforms they run at 3.94 out of 5 overall (109 answered), with “value for money” specifically at 3.94 and “ease of implementation” the weakest score, at 3.85 — placing orchestration near the bottom of our five-tracker satisfaction range, ahead of only evaluation tooling. A rating just under 4 out of 5, from users of whom 96% plan to change their orchestration approach within the year, reads as provisional acceptance: the platforms work well enough to run today, and not well enough to stop the search for something better. The ratings sit alongside near-universal intent to change; this is a layer enterprises tolerate more than they love.

Finding 2: Model gravity drives platform selection

The base model, not the tooling, decides the platform

We asked what most influenced the orchestration platform choice. The single largest factor is the pull of the underlying model — though flexibility and ease of development follow close behind.

Model gravity leading is the selection-side explanation for Anthropic’s platform lead: enterprises pick the orchestration environment closest to the frontier model they have standardized on. But the next tier complicates the picture — flexibility across models and tools (17%) and ease of development (17%) say enterprises also want to avoid being trapped by that choice, foreshadowing the lock-in fear in Finding 6. Security and permissions (14%) and total cost of ownership (11%) round out a pragmatic buying logic. Performance (latency/memory) sits last at 4%, a reminder that at this stage of adoption the binding constraints are model fit and optionality, not raw speed.

Finding 3: The job is reliable multi-step execution

Enterprises just orchestration by whether it completes the work

We asked what enterprises optimize for — their primary success metric for orchestration. Reliability and multi-step workflow management dominate; developer- and user-facing metrics trail.

Task completion reliability (32%) and multi-step workflow management (28%) together account for 59% of responses (60 of 101): orchestration succeeds, in the enterprise view, when it reliably carries a task through multiple steps to completion. Developer productivity (17%) matters but is secondary — the inverse of its prominence in framework discussion — and end-user experience (9%) is a minor concern, consistent with orchestration being an internal execution problem rather than a UX one. This reliability-first standard is exactly what makes the Chatbot Trap finding so pointed: enterprises define success as dependable multi-step execution, yet most of their deployed “agents” do not yet do multi-step work at all.

The trap is not evenly distributed. Splitting the sample by organization size, 77% of smaller enterprises say a quarter or fewer of their agents do true multi-step work, against 62% of larger ones. Larger enterprises are meaningfully further into genuine multi-step deployment; the chatbot trap is, directionally, a mid-market condition.

Finding 4: Consolidate, productionize, and build in-house

Three strategic moves are nearly tied for the year ahead

We asked what major change enterprises anticipate in their orchestration strategy over the next 12 months. Three moves cluster at the top, almost evenly split.

The top three — building in-house control (25%), standardizing on one framework (24%), and moving agents from sandbox to production (23%) — are statistically indistinguishable and tell a single story: enterprises are moving from experimentation to operational consolidation. They want fewer frameworks, more production exposure, and more ownership of the control layer; only 4% expect no change. The appetite for custom in-house control planes is notable alongside the platform concentration in Finding 1 — enterprises are standardizing on model-provider platforms while simultaneously planning to wrap them in control logic they own, the hybrid posture that Finding 6 makes explicit.

Finding 5: Nearly seven in 10 plan to switch — and the biggest group of movers has no shortlist

The strategic change enterprises anticipate (previous finding) comes with vendor motion attached. Asked whether they plan to adopt a new, additional, or replacement agent orchestration platform in the next twelve months, more respondents are moving here than in any other layer we track.

Asked which platforms they are considering, the most common answer among those in motion is none yet: 29% of all respondents are evaluating without a shortlist, the largest single response after "not considering a change." Among named candidates, OpenAI leads at 16%, followed by LangChain/LangGraph at 12% and Anthropic at 7% — and notably, the independent frameworks draw roughly double their current usage footprint in forward consideration, the same pattern our security tracker found for specialist vendors. Read with this report's concentration and lock-in findings, the picture completes itself: the major model-platform providers hold roughly four-fifths of today's primary usage, vendor lock-in has become the leading fear, 96% anticipate a strategic change — and now the purchase intent to act on all of it, with the largest bloc of buyers still undecided. The most concentrated layer of the agentic stack is also, as of June, the least settled.

Finding 6: Investment flows to workflow tooling

Tooling and permissions lead the spend; monitoring trails

We asked which orchestration-related investment will grow most next year. Agent workflow tooling leads, with security and permissions enforcement behind.

Workflow tooling leading (34%) is the budget-side expression of the reliability-and-multi-step priority in Finding 3: the money is going to the machinery that strings steps together dependably. Security and permissions enforcement (25%) and scaling infrastructure (20%) follow — the investments required to take agents from sandbox into production, the strategic move in Finding 4. Monitoring and debugging draws a smaller 11%, with another 11% reporting flat budgets. The weight on tooling, permissions, and scaling over pure observability signals that enterprises are spending to build and harden orchestration, not merely to watch it run.

Finding 7: The control plane will be hybrid — and lock-in is why

Enterprises expect to split control between providers and their own layer

We asked where enterprises expect the primary control plane for agents to live by the end of 2026, and what worries them most if that control sits inside a model-provider platform. A clear majority expect a hybrid model — and vendor lock-in is the reason.

Hybrid control is the dominant expectation by a wide margin (51%), and only 6% expect to hand control to a provider-managed service outright. Read together, the hybrid, custom, and externally-abstracted options — every architecture that keeps control at least partly outside the provider — sum to 88% (89 of 101). The reason surfaces directly when we asked about the risk of provider-resident control: vendor lock-in leads at 35% (35 of 101), ahead of security and permissioning limitations (28%) and inflexibility across models and tools (21%). The pattern echoes the prior wave’s “don’t trust the model to police itself” posture — here, enterprises will build on a provider’s platform but decline to be governed entirely by it. The hybrid control plane is the architectural hedge against the lock-in they most fear.

The June figure asserting a preference for a hybrid control plane marks movement from earlier. In the April–May survey (n=145), only 34% expected a hybrid control plane, and a greater number (12%) expected to hand control fully to a provider-managed service. These two snapshots don’t yet measure a confirmed longitudinal trend — but the direction of the conversation is unambiguous: toward keeping control.

Lock-in is also a new arrival as a top concern. In the April–May wave, the leading concern was security and permissioning limitations (32%), with lock-in second at 24%; by June the two had traded places. The worry about provider platforms appears to be maturing from whether they can be secured to whether they can be replaced.

Finding 8: The chatbot trap — most “agents” aren’t agents yet

Enterprises admit most deployments are still chatbot wrappers

We asked enterprises to assess their portfolios honestly: what share of their deployed “agents” are true multi-step orchestrated workflows versus simple single-prompt chatbot wrappers. The answer is the defining finding of this wave.

This is the gap at the center of the report. Combining the bottom two bands, 71% of enterprises (72 of 101) say a quarter or fewer of their deployed “agents” are genuinely orchestrated — and just 10% (10 of 101) have crossed the halfway mark. The ambition documented in the earlier findings — model-provider platforms, reliability-first success metrics, production rollouts, a deliberate control architecture — runs well ahead of the deployed reality, which remains overwhelmingly single-prompt assistants dressed as agents. This is less a contradiction than a roadmap: the platforms, budgets, and strategies are being put in place precisely because the orchestrated portfolio is still so thin. The open question for later waves is how fast the reality closes on the ambition.

Finding 9: Fiscal control is still reactive

Only a minority can stop a runaway agent before the bill arrives

Finally, we asked how enterprises enforce fiscal control over agent token consumption — the risk that an autonomous loop exhausts a budget before anyone intervenes. Most rely on native caps or after-the-fact monitoring; real-time programmatic control is the exception.

More than a quarter of enterprises (27%) admit they have no real-time, programmatic way to stop an agent before a budget-breaking bill arrives — they learn of it from the logs afterward. Another 32% lean entirely on the native caps and throttles built into their primary platform, a control only as good as the provider’s tooling and one that ties back to the lock-in concern of Finding 6. The enterprises building custom gateways (23%) or exploiting cross-model routing to arbitrage cost (19%) are the ones treating token burn as an engineering problem to be controlled deterministically. As with orchestration maturity, fiscal control is an area where the operational reality lags the ambition: agents are moving toward production faster than the cost-control plane around them is being built.

It’s worth noting, a split appears according to company size: roughly one in three enterprises under 2,500 employees (34%) exercises only reactive control of agent spend, against 20% of larger enterprises — directional figures, but consistent with the chatbot-trap split. The mid-market is running the least mature agents on the least instrumented budgets.

The bottom line: The layer is real; most of the agents aren't yet

Organizations with 100 or more employees describe an orchestration strategy that is consolidating quickly and maturing slowly. They are standardizing — for now — on model-provider platforms, which collectively hold roughly four-fifths of primary usage, chosen for the gravity of the underlying model, and they judge success by reliable multi-step execution. Investment is flowing to workflow tooling and permissions, the strategy is to consolidate frameworks and push agents into production, and the control plane they expect is deliberately hybrid, because vendor lock-in is the risk they fear most. But the standardization is provisional: 68% plan to adopt a new, additional, or replacement orchestration platform within twelve months — the highest switching intent of any layer we track — and the largest group of those movers has not yet shortlisted a candidate. Today's concentration describes where enterprises are, and visibly does not describe where they intend to stay.

But the honest self-assessment punctures the ambition. Seventy-one percent say a quarter or fewer of their deployed "agents" are truly orchestrated, only 10% are past the halfway mark, and more than a quarter cannot stop a runaway agent in real time. The orchestration layer — the platforms, the budgets, the control architecture — is being built ahead of the orchestrated portfolio it is meant to run. At 101 respondents in a single June wave this reads as a clear directional signal rather than a precise measurement: enterprises have decided how they want to orchestrate agents well before most of their agents are doing anything an orchestration layer is for. The questions for subsequent waves are whether the deployed reality closes the gap on the ambition — and, with nearly seven in ten buyers in motion and most of them undecided, which platforms the settled stack finally lands on.

Based on survey responses from 101 qualified enterprise respondents (100+ employees), drawn from a single June 2026 wave. Because this is one wave rather than a pooled multi-month sample, results read directionally rather than as a confirmed trend. Respondents include product and program managers, CIOs, CTOs and CISOs, consultants and advisors, and directors and VPs of data, AI, and engineering, across Technology/Software, Financial Services, Healthcare, and other sectors.

The agent evaluation gap: Enterprise AI organizations have a reality-alignment problem, not a coverage problem — and most are shipping to production anyway

Thu, 23 Jul 2026 19:19:44 +0200

Across 157 enterprises, organizations are granting AI agents more autonomy while trusting the evaluations meant to gate that autonomy less. Half have already shipped an agent that passed their internal evaluations and then failed a customer in production; only one in twenty fully trusts automated evaluation today; and the most-cited weakness is that evaluations do not align with real-world outcomes. Yet two-thirds already allow, or are actively engineering toward, deploying agent changes to production on automated evaluation alone — with no human in the loop. The result is an evaluation gap — the distance between how much autonomy enterprises are handing their agents and how far they trust the tests that are supposed to catch the failures.

This wave of VentureBeat Pulse Research examines how technical leaders measure agent performance: which reliability and evaluation platforms they use, how they select and trust them, what breaks in production, and how far they are willing to let agents run without a human in the loop.

The central finding is an evaluation gap — the distance between the autonomy enterprises are granting their agents and the trust they place in the evaluations meant to govern it. Half of organizations (50%) have, in the past year, deployed an agent or LLM feature that passed their internal evaluations and then caused a customer-facing failure, and a quarter have seen it happen more than once. Trust in the tests themselves is thin: only 5% say they fully trust automated evaluation today, and the single most-cited limitation is that evaluations align poorly with real-world outcomes (29%). Enterprises are discovering that a passing eval is not the same as a working agent.

What makes the gap consequential is the direction of travel. Two-thirds of organizations (66%) already permit fully automated, zero-human-in-the-loop deployment for low-risk agents (34%) or are actively engineering their pipelines to allow it within twelve months (33%). At the same time, the evaluation stack that would have to earn that trust is fragmented and immature: the most common primary tools are the model providers’ native evals, tied with having no dedicated tooling at all (17% each); and only about a quarter of enterprises run real-time quality checks on live production traffic. The autonomy is arriving faster than the assurance.

Methodology

VentureBeat fielded this survey as part of its ongoing Pulse Research series, this survey — the Agentic Reliability & Evals tracker — focused on how technical leaders evaluate agent performance and reliability. Responses are filtered to organizations with 100 or more employees (n=157), drawn from a single survey in June 2026; because this is one wave rather than a pooled multi-month sample, the report reads cross-sectionally and does not infer month-over-month trends. Where questions were multiple-select, those shares can sum to more than 100%.

By role the sample is senior and buyer-credible: 38% are final decision-makers for AI purchases and another 34% recommenders or influencers. Product and program managers (15%), consultants and advisors (10%), directors of engineering/IT (8%), and CIOs/CTOs/CISOs (8%) lead the named titles, alongside a large “Other” function (37%). By organization size the sample is mid-market-weighted: 100–499 (37%) and 500–2,499 (27%) employees lead, with 2,500–9,999 (20%), 10,000–49,999 (10%), and 50,000+ (6%) above them. Technology/Software is the largest industry at 23%, followed by Retail/Consumer (15%), Healthcare/Life Sciences (12%), and Manufacturing (10%).

At 157 respondents the sample is large enough to read directionally but should be treated as a directional signal rather than a precise measurement; it is self-selected and is not a probability sample. It skews toward the mid-market, so it is best read as the view from organizations actively standing up agent evaluation practices rather than from the largest operators.

Note: This survey was rebuilt for the June wave from the earlier “LLM observability and evaluations” survey; because the questions and sample differ, no comparisons are made to the April–May data.

Finding 1: A passing eval is not a working agent

Half have shipped an agent that passed evals, then failed a customer

We asked whether, in the past 12 months, organizations had deployed an agent or LLM feature that passed their internal evaluations but then caused a customer-facing failure. Half of those that run evaluations had.

This is the report’s defining number. Half of organizations (50%) have shipped an AI feature that cleared their internal evaluations and then failed in front of a customer — an incorrect output, a broken workflow, or a quality incident — and a quarter have seen it happen more than once. Only 36% report no such failure, and the remainder either run no pre-deployment evaluations (8%) or don’t track the root cause closely enough to know (6%). The failure is precise and expensive: the evaluation said the agent was ready, and it was not. Everything that follows — how enterprises trust their evals, what they monitor, and how much autonomy they grant — is shaped by this experience.

Finding 2: Almost no one fully trusts automated evaluation

The top complaint: Evals don't match real-world outcomes

We asked which limitation most reduces trust in automated agent evaluations today. Only a sliver of enterprises had no complaint at all.

Trust in automated evaluation is scarce, and specific. Only 5% of organizations say they fully trust automated evaluation as it stands — meaning 95% name a limitation that holds them back. The most common, at 29%, is the one that most directly explains Finding 1: evaluations align poorly with real-world outcomes, passing agents that later fail. Bias or inconsistency (21%) and a lack of explainability (18%) follow — enterprises cannot always tell why an evaluation reached its verdict — and 17% cite data-leakage or privacy concerns in the evaluation process itself. The tests meant to certify agents are not yet trusted to certify them, which is precisely why the autonomy trajectory in Finding 3 is so striking.

Finding 3: The autonomy ceiling is rising anyway

Two-thirds already allow, or are building toward, zero-human deployment

We asked whether organizations would let an autonomous agent deploy a code or system change to production on automated evaluation results alone, with no human-in-the-loop validation. The trajectory runs straight through the trust gap.

Here is the paradox at the heart of the report. Even though almost no one fully trusts automated evaluation (Finding 2), two-thirds of organizations (66%) either already allow zero-human-in-the-loop deployment for low-risk agents (34%) or are actively engineering their pipelines to permit it within a year (33%). Only 22% rule it out for the foreseeable future. The direction is unambiguous: enterprises are moving to let evaluations gate production autonomously — removing the human check — at the same moment they say those evaluations don’t reliably match reality. The autonomy ceiling is rising faster than the assurance beneath it, which is the mechanism by which the false-confidence failures of Finding 1 will scale rather than shrink.

Notably, the autonomy bet is not just a small company phenomenon. Splitting the sample by company size, larger enterprises are slightly further down the path toward zero human review than smaller companies (70% versus 64%) and slightly more likely to have shipped an evaluation-passing agent that then failed a customer (54% versus 48%). The assumption that large, regulated organizations are holding the human in the loop longest is, in this sample, backwards. To be sure, these are directional figures, since the survey was not a huge sample — 57 respondents from companies with 2,500+ employees and 100 from companies smaller than that.

Finding 4: The evaluation stack is fragmented and provider-led

Provider-native evals lead — tied with no dedicated tool at all

We asked which agent reliability or evaluation platform enterprises primarily use today. The market has no clear leader — and a large share has nothing dedicated.

The evaluation layer is early and unconsolidated. Provider-native tooling leads — OpenAI’s native evals and traces (17%) and Anthropic’s Claude Console evals (13%) together outweigh any independent platform — but it is tied at the top by a striking answer: 17% of enterprises use no dedicated agent-evaluation tooling at all, a notable gap for organizations shipping agents to customers. The specialist evaluation vendors — DeepEval (12%), Braintrust (8%), LangSmith, Weave, Promptfoo, Langfuse, Arize — are scattered across single to low double digits, and 11% have built their own. No independent platform has yet become the category standard, which leaves most enterprises evaluating agents with provider-native tools, home-grown scripts, or nothing.

Finding 5: Production monitoring rarely watches output quality

Only a quarter run real-time quality checks on live traffic

Production monitoring for an AI agent can watch two very different things. It can watch whether the system is functioning — is the agent up and responding, did each request complete, how fast, at what cost, with any errors. Or it can watch whether the agent's output is correct — automated checks that evaluate the content of each answer as it goes out: did the agent give the right answer, take the right action, stay within policy. The distinction matters because a confidently wrong answer is invisible to the first kind of monitoring: the request completes, the response is fast, no error is thrown, and every functioning-metric reads healthy. We asked organizations which kind their live production monitoring is built for today.

Grouped by what is actually being watched, the split is stark: 51% of organizations monitor only whether the agent is functioning, while 23% monitor whether its answers are right. Counting the ad-hoc reviewers and the don't-knows, roughly three-quarters of organizations run no automated, real-time evaluation of output correctness in production — they can see that the system is up and what it costs, and they are taking the correctness of its answers on faith. That blind spot is the runtime counterpart to the pre-deployment gap in Finding 1: the same organizations engineering the human out of the deployment decision mostly cannot see, in real time, when the deployed agent starts getting things wrong.

Finding 6: Bought on cost, measured on consistency

Price and integration drive selection; evaluation consistency is the goal

We asked what most influenced enterprises’ choice of an evaluation vendor, and what they treat as their primary measure of success. Both answers are pragmatic.

Enterprises buy evaluation tooling on economics and trust it on repeatability. Cost of evaluations (28%) narrowly leads selection, just ahead of ease of integration (27%) and evaluation accuracy (24%) — breadth of observability (13%) and vendor roadmap (4%) matter far less. On what success looks like, more than a third (36%) name evaluation consistency — getting the same verdict on the same behavior every time — well ahead of speed of experimentation (19%), reduction in failures (18%), production visibility (13%), and compliance (11%). The emphasis on consistency is telling: before enterprises can trust an evaluation’s verdict, they need it to be stable — the very property whose absence (bias and inconsistency) ranked among the top trust limitations in Finding 2. Satisfaction with current tooling is only moderate, averaging 3.8 on a five-point scale across overall satisfaction, ease of implementation, and value for money.

Finding 7: The next dollar goes to humans and observability

Investment is flowing to oversight, not just automation

We asked which reliability and evaluation investment will grow most over the next year. The money is going toward watching agents more closely — including with people.

The second-largest planned investment — behind only production observability — is human review workflows, at 26%. Read against Finding 1, that is the report's quietest contradiction: at the same moment two-thirds of enterprises are engineering the human out of the deployment decision, more of them plan to grow spending on human reviewers (26%) than on the automated evaluation pipelines (16%) that would replace them. The zero-human trajectory and the human-review budget are rising in the same companies at the same time. Indeed, only 8% report that their budget is not increasing.

Taken together, enterprises are hedging: building toward autonomy while spending to watch agents more closely and keep humans available for the calls that automated evaluation cannot yet be trusted to make.

Finding 8: A tooling reshuffle is coming

Nearly two-thirds plan to adopt or switch platforms within a year

We asked whether enterprises plan to adopt a new, additional, or replacement evaluation platform, and which they are considering. Few intend to stand pat.

The evaluation market is wide open. While 36% have no plans to change, a clear majority (64%) intend to adopt a new, additional, or replacement platform within twelve months, and 31% within the next quarter. The consideration set points where current usage is thinnest: Confident AI’s DeepEval leads what enterprises are evaluating (20%), ahead of OpenAI’s native evals (13%) and Braintrust (9%) — the open-source specialists drawing more interest than their present footprint.

Given that so many enterprises today rely on provider-native tools or nothing at all (Finding 4), this is less a defection than a first real wave of tooling adoption — the moment the evaluation layer starts to consolidate. Which platforms earn that trust, in a market where almost no one trusts automated evaluation yet, is the open question this series will keep tracking.

The bottom line: An evaluation gap that autonomy will widen, not close

Organizations with 100 or more employees are granting AI agents more independence than they trust their evaluations to support. Half have already shipped an agent that passed its evals and then failed a customer; almost none fully trust automated evaluation, chiefly because it doesn’t match real-world outcomes; and most watch production for uptime and cost rather than for whether the agent’s answers are right. Yet two-thirds already allow, or are actively building toward, deploying to production on automated evaluation alone.

The vendor market is early and unsettled: the most common primary evaluation tools are provider-native evals, tied with no dedicated tooling at all, and a clear majority plan to adopt or switch platforms within the year. Encouragingly, the next dollar is going to observability and — pointedly — human review, suggesting enterprises sense the gap even as they engineer past it. At 157 respondents in a single wave this is a directional read, skewed toward the mid-market — but the direction is clear: autonomy is being granted on the strength of evaluations that the people granting it do not yet trust. The evaluation gap is not a coverage problem that more tests alone will close; it is a problem of evaluations that reflect reality and can be trusted to gate it. The open question for later waves is whether assurance catches up to autonomy — or whether the false-confidence failures move from customer incidents into changes that deploy themselves.

Based on survey responses from 157 qualified enterprise respondents (100+ employees), drawn from a single June 2026 wave. This is a directional read rather than a precise measurement — the sample is self-selected, not a probability sample, and skews toward the mid-market. Respondents include product and program managers, consultants and advisors, directors of engineering/IT, and CIOs/CTOs/CISOs, among other functions, across technology/software, retail/consumer, healthcare/life sciences, manufacturing, and other industries.

Wie Observability komplexe IT-Systeme verständlich macht - it-business

Thu, 23 Jul 2026 19:00:38 +0200

Multicloud und KI-Workloads treiben die IT-Komplexität in Unternehmen in die Höhe. Tamara Altendorf von Dynatrace erklärt, warum klassisches ...

Palo Alto Networks targets application observability gains with latest acquisition

Thu, 23 Jul 2026 10:56:32 +0200

The company will integrate Embrace features with its Cortex AgentiX service

Palo Alto Networks übernimmt Observability-Spezialisten Embrace

Thu, 23 Jul 2026 10:56:30 +0200

Palo Alto Networks kündigt die Übernahme des Observability-Anbieters Embrace an. Damit erweitert das Unternehmen seine Plattform um Real User Monitoring.

Tags: #Cyber Security | #Übernahme

AI agents aren't confidently wrong because of bad context — they're wrong because of bad data engineering

Wed, 22 Jul 2026 22:58:18 +0200

You spend weeks tuning an AI chatbot. Answers are accurate. Stakeholders sign off, and you ship it. Three months later, the system is confidently wrong about a third of what users ask. Nobody changed the model, and nobody touched the prompts. The world moved, pricing changed, a policy updated, a product spec shipped a new version, and the underlying knowledge store didn't move with it.

This is not a hypothetical. It's one of the most common production failure modes in enterprise AI right now, and most data engineering teams don't have the right tooling to catch it, regardless of how the AI system retrieves the data.

The failure that doesn't look like a failure

An AI application doesn't care whether it's retrieving from a vector store, a document index, or an API call. Whatever the mechanism, nothing in a standard retrieval pipeline checks whether what it's serving is still correct. A stale pricing document retrieves just as confidently as a current one, because the system is scoring relevance or availability, not correctness. A record with a silently missing field passes through just as cleanly as a complete one, for the same reason.

So the failure is invisible by design. Outdated or incomplete data still scores high on relevance, or passes every check a data pipeline was built to run. The model answers with full confidence because the retrieved context looks authoritative. Every dashboard you're watching stays green. The system looks like it's working. It's just wrong.

I’ve watched a similar version of this happen outside the AI context, in a fintech pipeline. An upstream system changed a field without notifying downstream users. The pipeline did not fail; it simply propagated bad values into dashboards because the system only checked whether the job completed, not whether the data was still correct. The issue surfaced only when a customer noticed something inconsistent. By then, the bad data had already moved downstream.

Whether it's a document that's gone stale or a field that's gone silently missing, the failure shape is the same: the absence of an error is not the presence of correctness, and without building proper validation layers, nothing in the pipeline could identify the problem.

Why this is a data engineering problem

Teams that hit this failure tend to misdiagnose it, and they tend to do it twice.

Blaming the model: The first instinct is to blame the model, try a different LLM, adjust the prompt. The real problem lies further upstream, at the data engineering layer, the same instinct behind the fintech failure above: monitoring built for the pipeline, not the data.

Blaming the retrieval layer: Once the model's ruled out, the next instinct is to blame the retrieval or context layer instead and buy a better one. The timing isn't a coincidence: as enterprises push these systems into the real production world, this gap is exactly what's starting to surface, and the vendor response has been everywhere.

AWS just entered the "context layer" race with a knowledge graph that learns from agent usage.
Snowflake's new Horizon Context and Cortex Sense target the exact symptom this piece opened with: agents giving confident wrong answers because nothing governs the business logic underneath them.

Both are real responses to a real problem, but they sit one layer above it; a knowledge graph still depends on whatever feeds it.

The real problem lies further upstream, at the data engineering layer. Teams check whether a job ran, not whether the data it moved is still true, an instinct that predates AI by years. Monitoring is built for the pipeline, not for the data.

What's actually missing: Data observability

Data observability is a well-known concept that doesn't get enough attention in how it's actually implemented. The relevant metric isn't a percentage — it's coverage: what fraction of critical datasets have lineage that's actually queryable, versus only living in someone's head.

Uber built a dedicated data quality and observability platform long before retrieval-augmented generation existed. Their Unified Data Quality platform supports more than 2,000 critical datasets and detects around 90% of data quality incidents before they reach downstream consumers.

Netflix solved a different piece of the same problem, building a company-wide data lineage system so anyone could answer where a dataset came from and what touched it along the way. It maps dependencies across Kafka topics, ML models, and experimentation, not just warehouse tables. Similar to Uber, the platform was built for humans and now it has become more important with the rise in AI/LLM applications.

Between them, Uber and Netflix cover two of the four things worth building for. In practice, I think about it as four dimensions, each measurable on its own terms.

Correctness: Does each record conform to the shape and rules it's supposed to, right field types, no unexpected nulls, values in range. Tools like Great Expectations and Soda handle this well: automated row and column-level validation instead of manual checks after something breaks. Track percentage of records passing validation per run.

Freshness: Is the data still current relative to its source, not just current as of its last check. Track time since last successful update per source, with an SLA per dataset rather than one blanket threshold, since some sources need hourly refresh and others don't.

Consistency: Does the same fact read the same way everywhere it's stored or indexed. This fails silently, it only shows up when two systems fed by the same source start disagreeing. A periodic cross-check between downstream destinations, flagging mismatch rate above a threshold, is enough to catch it early.

Lineage: Can you trace any output back to its source and every transform it passed through, the same question Netflix built its system to answer.

None of this requires infrastructure most data teams don't already have. I know because I've built it, not just argued for it.

At Socure, client data arrived in whatever shape the client felt like sending it, and occasionally, quietly wrong. The challenge was building a system where incorrect data could be identified before it propagated downstream. The same principles applied: Validate what arrived, understand where it came from, and prevent bad data from becoming someone else's problem.

Great Expectations became part of that foundation: schema and range validation at ingestion, per-source SLAs for freshness, cross-system checks for consistency, and file-level lineage. All of it sat behind a write-audit-publish pattern, where data landed in staging, was validated, and only moved downstream if it passed the required checks.

The result showed up downstream: better accuracy across the board, in reporting, in the ML models, and in AI retrieval built on top of that same data.

What to do Monday morning

If you're running retrieval-based AI systems in production, the diagnostic question isn't which model to try next or which retrieval architecture to migrate to. It's four narrower questions:

Is the underlying data validated against the standards required by its consumers?
What's the oldest piece of content currently being served with high confidence?
Would two chunks of the same source ever disagree with each other in the same retrieval result?
Could you trace where it came from if it turned out to be wrong?

If you can't answer those questions, then the gap lies in the pipeline between your source systems and whatever your agent reads from. That’s a data engineering fix, not a model swap or a vendor migration.

Whether you're building reporting pipelines, ML systems, or AI agents, correctness, freshness, consistency, and lineage are what make data trustworthy. AI simply exposes weaknesses that have existed in data engineering all along.

Endpoint security firm Glow emerges from stealth with $180 million.

Wed, 22 Jul 2026 22:12:26 +0200

Neo has emerged from stealth with $100 million. Palo Alto Networks has agreed to acquire user-focused observability provider Embrace.

Palo Alto Networks to Acquire Observability Platform Provider Embrace

Wed, 22 Jul 2026 17:18:11 +0200

Acquisition follows January’s Chronosphere deal, deepening Palo Alto Networks’ push beyond core security into observability. The post Palo Alto Networks to Acquire Observability Platform Provider Embrace appeared first on SecurityWeek. This article has been indexed from SecurityWeek Read the original…

The post Palo Alto Networks to Acquire Observability Platform Provider Embrace appeared first on IT Security News.

Palo Alto Networks to Acquire Observability Platform Provider Embrace

Wed, 22 Jul 2026 17:05:02 +0200

Acquisition follows January's Chronosphere deal, deepening Palo Alto Networks' push beyond core security into observability.

The post Palo Alto Networks to Acquire Observability Platform Provider Embrace appeared first on SecurityWeek.

Tools, um MCP-Server abzusichern

Wed, 22 Jul 2026 06:10:24 +0200

width="1024" height="576" sizes="auto, (max-width: 1024px) 100vw, 1024px">

Unabhängig davon, welche MCP-Server Unternehmen wofür einsetzen – “Unsicherheiten” sollten dabei außenvorbleiben.

Gorodenkoff | shutterstock.com

Model Context Protocol (MCP) verbindet KI-Agenten mit Datenquellen und erfreut sich im Unternehmensumfeld wachsender Beliebtheit. Allerdings ist auch MCP nicht frei von Sicherheitslücken, wie entsprechende Entdeckungen, etwa beim SaaS-Anbieter Asana oder dem IT-Riesen Atlassian gezeigt haben. Inzwischen hat sich jedoch einiges in Sachen MCP-Sicherheit getan. Einerseits wurden mit Blick auf das Kernprotokoll etliche Fortschritte erzielt. Beispielsweise in Form von Support für OAuth sowie für Authentifizierungs-Server von Drittanbietern und Identity-Management-Systeme. Darüber hinaus wurde inzwischen auch eine offizielle MCP Registry geschaffen, die einen Überblick über sichere, öffentlich verfügbare MCP-Server bietet.

Dennoch bestehen weiterhin Sicherheitslücken, die sich für diverse Cyberschandtaten ausnutzen lassen – Prompt Injection, Tool Poisoning, Token-Diebstahl, Server-übergreifende Attacken oder manipulierte Messages sind nur einige von vielen Beispielen. Mit anderen Worten: Unternehmen, die sich beim Aufbau von Agentic-AI-Systemen einen Wettbewerbsvorteil verschaffen wollen, müssen erhebliche Anstrengungen unternehmen, um zu gewährleisten, dass sensible Daten nicht nach außen dringen. Glücklicherweise gibt es diverse Tools, die dabei Unterstützung versprechen.

In diesem Artikel lesen Sie:

was Security-Tools für MCP leisten sollten, und
welche Angebote in diesem Bereich interessant sind.

Das sollten MCP-Sicherheitslösungen können

Die Gefahr von Datenlecks, Prompt Injections und weiteren Sicherheitsbedrohungen besteht unabhängig davon, ob Unternehmen:

ihre eigenen KI-Agenten mit MCP-Servern von Drittanbietern,
ihre eigenen MCP-Server mit Drittanbieter-Agenten, oder
ihre eigenen Server mit den eigenen Agenten verbinden.

Soll heißen: Unternehmen müssen in jedem Fall Autorisierungen und Berechtigungen überprüfen, detaillierte Zugriffskontrollen implementieren und alles protokollieren. Daraus ergeben sich auch die Anforderungen für MCP-Sicherheitslösungen. Diese sollten bieten:

MCP-Servererkennung. Für Mitarbeiter eines Unternehmens ist es einfach, MCP-Server herunterzuladen und zu nutzen. Mit Scan-Services für MCP-Server können Unternehmen sämtliche Instanzen von Schatten-MCP-Servern in ihrer Umgebung finden.
Laufzeitschutz. KI-Agenten kommunizieren mit MCP-Servern in natürlicher Sprache. MCP-Sicherheits-Tools sollten deshalb in der Lage sein, diese Kommunikation auf Sicherheitsprobleme wie Prompt Injections hin zu überwachen.
Authentifizierungs- und Zugriffskontrollen. Das MCP-Protokoll unterstützt inzwischen OAuth, aber das ist nur ein erster Schritt. Für zusätzliche Sicherheit empfehlen sich Tools mit integrierten Kontroll-Frameworks für Zero Trust und Least Privilege.
Logging und Observability. Tools und Plattformen sollten zudem die Möglichkeit bieten, MCP-Protokolle zu sammeln, Sicherheitsteams über Richtlinienverstöße zu informieren, Compliance-Daten zu erfassen oder Protokolle in die bestehende Sicherheitsinfrastruktur einzuspeisen.

MCP-Security-Angebote

Im Folgenden haben wir die Anbieter von MCP-Security-Tools in drei Kategorien aufgeteilt. Diese Aufstellung erhebt keinen Anspruch auf Vollständigkeit.

Hyperscaler

Für Unternehmen, die sich vollständig auf eine bestimmte Cloud-Plattform verlassen, bieten die MCP-Tools des jeweiligen Hyperscalers einen einfachen Einstieg.

Amazon Web Services (AWS) hat Mitte 2025 seine eigene agentenbasierte KI-Plattform eingeführt. Amazon Bedrock AgentCore umfasst ein Gateway, das mehrere Protokolle unterstützt (darunter auch MCP), ein Identity-Management-System sowie Observability.
Microsoft bietet einen grundlegenden Azure-MCP-Server an, inklusive Support für Azure Key Vault. Darüber hinaus unterstützen auch Azure AI Foundry Agent Service und Azure API Management das Model Context Protocol. Zudem bietet Microsoft mit dem Agent Framework auch ein Open-Source-Entwicklungskit, das sowohl MCP als auch Agent2Agent unterstützt und beispielsweise Schutz vor Prompt Injections verspricht.
Google Cloud kündigte Anfang 2025 seine MCP Toolbox für Datenbanken an – inklusive integrierter Authentifizierung und Observability. Außerdem hat der Hyperscaler auch eine Referenzarchitektur veröffentlicht, um MCP-Server auf seiner Cloud-Plattform abzusichern.

Große Plattformanbieter

Der IT-Dienstleister Cloudflare hat mit MCP Server Portals ein Tool veröffentlicht, mit dem Unternehmen MCP-Verbindungen zentralisiert absichern und überwachen können. Die Funktion ist Bestandteil der Cloudflare-One-Plattform.
Palo Alto Networks hat mit Blick auf MCP-Sicherheit mehrere Eisen im Feuer. Mit Prisma AIRS hat das Unternehmen einen eigenen, intermediären MCP-Server veröffentlicht. Dieser sitzt zwischen den KI-Agenten und dem eigentlichen MCP-Server und erkennt schadhafte Inhalte und Daten. Das Tool MCP Security ist hingegen Bestandteil von Cortex Cloud WAAS und überprüft die MCP-Kommunikation an der Netzwerkgrenze auf bösartige Aktivitäten.
SentinelOne gewährt mit seiner Singularity Platform ebenfalls Einblick in die MCP-Interaktionskette und bietet zum Beispiel Warnmeldungen und automatisierte Incident Response für MCP-Server auf lokaler oder Remote-Ebene.
Die Plattform von Acuvity (seit Februar 2026 Teil von Proofpoint) verspricht, MCP-Server umfassend abzusichern. Dafür sorgt laut dem Anbieter eine Kombination aus Least-Privilege-Execution, unveränderlichen Laufzeiten, kontinuierlichen Schwachstellenscans, Authentifizierung und Bedrohungserkennung.
Daneben hat auch Broadcom MCP-Sicherheitsfunktionen für VMware Cloud Foundation angekündigt, die künftig mehr Sicherheit für agentenbasierte Workflows gewährleisten sollen.

Startups

Das API-Security-Startup Akto hat eine MCP-Security-Plattform im Angebot. Sie umfasst ein Discovery Tool, um MCP-Server in Unternehmensumgebungen zu identifizieren, Security-Testing-Werkzeuge sowie Monitoring- und Threat-Detection-Funktionen.
Invariant Labs bietet mit MCP-Scan ein quelloffenes Tool, das die statische Analyse und Echtzeitüberwachung von MCP-Servern ermöglicht. Mit Guardrails hat das Startup auch ein kommerzielles Produkt im Angebot. Dabei handelt es sich um einen Proxy. Der zwischen KI-Agenten und MCP-Servern sitzt und vor Security-Risiken schützen soll. Das Tool befähigt Anwender außerdem dazu, Richtlinien aufzusetzen.
Highflame (vormals Javelin) addressiert ebenfalls das Thema MCP-Sicherheit. Etwa mit Funktionen wie MCP-Server auf Risiken zu scannen oder Datenanfragen zu überprüfen.
Lasso Security stellt ein Open-Source-MCP-Gateway zur Verfügung, das die Konfiguration und das Lebenszyklusmanagement von MCP-Servern ermöglicht und Messages um sensible Informationen bereinigt.

(fm)

Dieser Artikel ist im Original bei unser Schwesterpublikation CSOonline.com erschienen.

IT leaders confident but cooked when it comes to rogue AI agents

Tue, 21 Jul 2026 12:09:38 +0200

A large majority of IT and security leaders are confident in their teams’ ability to detect when an AI agent has gone rogue, but few are able to take quick action to mitigate the fallout when an agent exceeds its intended scope.

Nine in 10 IT and security leaders surveyed by IT observability vendor WanAware believe in their capabilities to find malfunctioning agents, but only 26% acknowledge that they can trace the downstream impact within minutes. Over 45% say it would take hours to understand the full impact of an agent incident.

That delay between detection and mitigation can be a huge problem, says Jeffrey Collins, WanAware’s CEO. The survey suggests IT leaders are overconfident about their ability to control agents, he adds.

And here, timing is critical, Collins says, given that malfunctioning agents can lead to major outages and data breaches — damage that can start within seconds, he notes.

“That’s truly the gap here. It’s not if you understand it; it’s when you understand it,” Collins says. “If your average time to just knowing about an event is measured in days, weeks, or months, you have a serious problem right now.”

While it’s not always easy to tell whether an agent has gone beyond its scope, it’s even harder to tell the downstream impacts, he adds.

“What’s been affected if one machine was compromised, either from our own AI usage as a customer or from someone else’s, what else could happen, and how can we understand that quickly?” Collins asks.

Machine speed

Kevin Paige, field CISO at IT solutions provider C1, agrees that time is of the essence when an AI agent malfunctions.

“The problem is that agents move at machine speed, so the gap between an agent malfunctioning and you catching it isn’t measured in minutes, it’s measured in actions,” he says. “Every minute it’s wrong it’s still working, and because it’s usually running on borrowed standing credentials, the damage spreads across everything those credentials can reach before anyone can pin it on the agent.”

In many cases, organizations with rogue agents don’t find out from their own detection tools, but from customers, auditors, or broken downstream systems, he says.

“That’s the worst way to learn,” Paige adds. “The longer-term cost is trust, because one incident like that and the business pulls back on agents entirely, so failing to contain a malfunction fast is also what stalls adoption.”

The problem with detecting rogue agents is that many organizations have built in visibility but not control, he says.

“When an agent goes out of scope it’s rarely dramatic,” Paige adds. “Usually, it’s using access it legitimately has, for a purpose nobody signed off on, which means your access model doesn’t even flag it. So you find out after the fact, and you fix it by hand.”

IT teams can stop agents that exceed their scope, but only if controls were built in before the agent was deployed, adds Chris Camacho, COO of Abstract Security.

“Every agent should have its own identity, narrowly scoped permissions, and a complete audit trail,” he says. “Just as important, organizations need the ability to immediately revoke that identity or suspend the agent without manually hunting through multiple consoles during an incident.”

Part of the challenge is that an agent’s activity is spread across identities, cloud platforms, SaaS applications, APIs, and security tools that were not designed to tell a complete story, Camacho says. Security teams often have to piece together events from multiple basic questions such as, what did the agent access, and what changed?

“Most organizations know where they’ve deployed AI agents,” he adds. “That’s very different from knowing exactly what an agent did after something unexpected happens.”

The organizations that most successfully manage agents won’t be the ones that deploy the most, he says. “They’ll be the ones that can explain every action an agent took, prove it operated within policy, and stop it immediately when it doesn’t,” he adds.

Confidence isn’t reality

The survey’s results make sense to Joe Brinkley, director of offensive security research and community at pentest firm Cobalt. The high confidence in detecting malfunctions is compliance paperwork, whereas the minority of respondents who can detect problems quickly is the reality on the ground, he says.

“Tracing agent impact fast is brutal,” Brinkley says. “These systems do not run on fixed code paths. They use nondeterministic reasoning across a web of different APIs. Traditional logs only catch isolated events. They completely miss the full execution chain.”

By the time an anomaly alert hits, an agent has already executed multiple downstream actions, he adds.

In some cases, agent malfunctions are related to data flow vulnerabilities, such as when a prompt injection from an untrusted input such as a malicious email overwrites the system instructions, he says.

“We need to be clear about the actual technology; the AI is not waking up angry,” Brinkley says. “The agent suddenly thinks its official job is to dump your database. It spends tokens as fast as possible to do that.”

Agents are also vulnerable to loop failures, when they hit API errors and try to self-correct, he adds.

“It hits that same broken endpoint 10,000 times in two minutes,” he says. “It drains your budget and causes a self-inflicted denial of service. It is an automated wrecking ball moving faster than your monitoring can log it.”

Brinkley recommends that IT leaders put “hard kill” switches at the API layer to stop agents going out of scope.

“You can stop it, but soft guardrails are useless,” he says. “Do not try to patch the prompt or filter the text. You have to treat the agent like a compromised user account. Pull the OAuth tokens and kill the access immediately.”

SaaS will survive, but lazy SaaS is dead

Tue, 21 Jul 2026 11:05:13 +0200

Something interesting happened during an internal evaluation of AI meeting transcription tools at Tungsten Automation. The products worked. They weren’t bad. But sitting across from the pricing, we kept asking the same question: what exactly are we paying for?

We already had a secure enterprise AI environment. Building a meeting summary workflow took days, not months. We customized the outputs, injected our own internal context, and controlled security our way instead of working around someone else’s roadmap. We built it. It works better. We own it.

That’s not a knock on those vendors. It’s a signal of something more fundamental happening across enterprise software.

The moat was never the product

For two decades, SaaS rode a favorable asymmetry: building internal tools was hard, integrations were messy, and even modest automation required developers and long timelines. Buying was faster and cheaper than building. That asymmetry fueled the explosion of SaaS into every corner of the enterprise stack.

AI is collapsing that asymmetry. Large language models and agentic workflows can orchestrate APIs, move data between systems, generate interfaces, and automate business logic with a fraction of the engineering effort required even two years ago. The integration friction that once protected entire product categories is evaporating.

The vendors most exposed are not the deeply embedded enterprise platforms. They’re the lightweight workflow layers, the products that essentially put a polished interface on top of accessible data and relatively straightforward processes. Reporting dashboards. Meeting tools. Narrow productivity applications. These products created value by simplifying implementation. That rationale is getting harder to sustain when implementation is no longer the real barrier.

Here’s the part most analyses miss: it’s not just that AI makes development faster. It’s that agents change the integration model entirely. For 30 years, enterprise software was built for humans navigating UIs. Agentic systems don’t use UIs. They call APIs, read from multiple sources simultaneously, and move data freely across systems. The switching costs that once made incumbent software sticky are collapsing, because an agent doesn’t care which UI it used last quarter.

The SaaS that survives

The question isn’t whether SaaS survives. It’s which SaaS survives.

The companies with durable positions are not the ones with the cleanest interface. They’re the ones that transfer operational risk customers genuinely cannot absorb themselves. Compliance. Regulatory certification. Accumulated domain expertise. Liability.

Think about compliant invoicing across 140 countries. That’s not a workflow someone builds in a sprint. The certifications alone take years. A single regulatory change in one jurisdiction can break an AP process for a global enterprise overnight. Customers don’t pay for that capability because it’s technically complex. They pay because they cannot afford to own the risk of getting it wrong.

That’s the distinction that matters: AI lowers the cost of building software. It does not lower the cost of absorbing risk. The vendors who understand this are building durable businesses. The ones who don’t are quietly subsidizing their customers’ internal build programs.

Software sells features. Platforms sell accountability.

The prototype trap

The danger for enterprise buyers right now is overcorrection. Every successful prototype looks like a cost-saving opportunity. Very few survive the jump to production.

Building a workflow with generative AI is becoming straightforward. Maintaining it is not. Models evolve. Outputs drift. Governance requirements tighten. What worked cleanly in a controlled environment behaves differently at scale, and the failure mode is worse than traditional software. Rule-based automation, when it fails, fails obviously. Agents fail silently, confidently, at scale, often with a completely reasonable-sounding explanation.

Engineering teams that take on AI-powered systems need to solve for observability, model drift, access controls, audit trails, and long-term maintenance ownership. In regulated industries, they need to demonstrate exactly how the system reached every decision. That’s not a weekend project. That’s an ongoing operational commitment that compounds over time as models change and regulatory requirements evolve.

Before a team decides to replace an external platform with internal AI tooling, the honest question isn’t, “Can we build this?” The real question is, “Are we prepared to own this in production, for years, as the underlying models change beneath us?” Sometimes the answer is yes. Often the answer is no, and the true cost only becomes visible after the vendor contract is canceled.

Build vs. partner: a sharper frame

The build vs. buy framing has always been too binary. The right question is build vs. partner.

Partner for the capabilities where risk transfer, regulatory complexity, and domain expertise create genuine value your team cannot replicate. Build for the capabilities that actually differentiate your business from your competitors. Don’t burn your best engineers rebuilding compliant invoice processing or production-grade document extraction. Those aren’t competitive advantages. They’re table stakes, and someone else has already paid the cost, across decades, to make them reliable.

The organizations getting this right are honest about where they create unique value. They focus development there, and partner for everything else. The ones getting it wrong are vibe-coding solutions to non-differentiating problems while their actual competitive moat goes unattended.

The true value of software

We’re not watching the death of SaaS. We’re watching the end of the friction-based value proposition: the idea that software is worth renewing because integration used to be painful. That rationale is largely gone.

What survives is software that does something customers cannot reasonably replicate internally: absorb risk, maintain regulatory compliance, deliver operational reliability at scale, and bring genuine domain expertise into a production-grade system that someone else already stress-tested for years.

The vendors who recognize this are already repositioning around accountability, governance, and outcomes. The ones who haven’t will find the next renewal conversation noticeably harder.

Software sells features. Platforms sell accountability. That distinction is about to separate a lot of winners from a lot of cautionary tales.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

How AI impacts site reliability engineering

Tue, 21 Jul 2026 11:05:12 +0200

Site reliability engineers (SREs) have the tough assignment of resolving thorny performance and reliability issues. But their primary mission is to provide devops teams with operational insights and to suggest implementation improvements on business system performance, security, and overall robustness.

Google introduced its SRE playbook in 2003, but it took some time for the role’s definition, tools, and techniques to become mainstream. Startups were the first to adopt observability for cloud-native applications and create dedicated SRE positions. As tools matured and SRE responsibilities became more clearly defined, larger enterprises assigned SREs to work as a bridge between devops and IT ops teams to improve resilience across a wider range of applications, APIs, and data pipelines.

SRE is a career path for multidisciplinary engineers with strong investigative instincts, sharp data analytics skills, and the temperament to perform under pressure. It has become a critical responsibility as tech became mission-critical for enterprises, and it is a growing role in the genAI era as more businesses deploy AI agents.

But the critical need for resiliency and greater technological complexity brings new challenges for SREs. According to the 2026 State of Production Reliability and AI Adoption report, 44% of respondents experienced an outage linked to ignored or suppressed alerts in the past year, and 35% report their engineers occasionally ignore or dismiss alerts due to alert fatigue. More than 70% of alerts received are not actionable, according to 57% of organizations.

So, is AI making the SRE’s role easier and helping businesses run more reliable technology operations? On the other hand, AI is also driving complexity, as companies deploy genAI tools and AI agents across more business functions and seek to automate more decision-making across operations.

AIops and agentic ops aid SREs

Over the past decade, SRE responsibilities have become somewhat easier through improvements in monitoring platforms, observability practices, tools for centralizing operational data, and AI applied in IT operations (AIops). But during the heat of resolving an outage or performance issue, it’s not easy to correctly identify what system triggered the issue versus other downstream systems impacted by it.

According to the Komodore 2025 Enterprise Kubernetes Report, 79% of production incidents originate from recent system changes, including deployments and changes to compute environments. But the other 21% of incidents stem from issues outside of the business’s control, including network failures, third-party changes, and cloud provider failures.

“SREs using AI capabilities succeed or fail in the moment an incident unfolds, when engineers are deciding what to investigate next,” says Itiel Shwartz, CTO at Komodor. “If the system streamlines root cause detection, connects signals to recent changes, and explains its reasoning in a way engineers recognize, it earns trust. If it adds uncertainty or demands extra validation, it gets sidelined, regardless of how bespoke the model behind it may be. What’s less obvious is what it takes to make AI for SREs work in production, and how different that reality is from prototypes, demos, or early internal builds.”

AIops is not a new capability, especially in using machine learning to correlate logs, metrics, and traces across monitoring and alerting systems. IT service management and SREs have been using AIops to reduce the mean time to resolve incidents and to perform accurate root cause analysis (RCA) efficiently. Agentic ops is the next wave of genAI operational capabilities, including tools for monitoring AI agents, managing their access rights, and detecting AI model accuracy drift.

“AI is useful during major incidents because it can pull together a lot of context into a few clear sentences, which is exactly what an SRE needs in the moment,” suggests Shani Shoham, chief revenue officer at OpenObserve. “The complexity of architecture and the different tooling make it easier for AI than for a human, but autonomous resolution is still a way off.”

AI’s impact on people and burnout

The business pressure to keep systems up, secure, and performing well is a 24/7 stressful responsibility. According to The SRE Report 2025 from Catchpoint, 36% of SREs often or always experience elevated stress during an incident, and 28% said the stress persists even after the incident is resolved. AI capabilities may prove to be a game-changer in helping SREs avoid burnout and reduce stress.

“AI can improve RCA by taking in a much larger incident context than any engineer can hold at 3am, reasoning across traces, logs, metrics, deploys, config changes, alerts, ownership, and recent production behavior,” says Noam Levy, founding engineer and field CTO at Groundcover. “Beyond attempting a full RCA, its immediate value is distilling the signals that actually matter, reconstructing a clear timeline of cause and effect, and helping engineers separate correlation from likely causality. Once a fix is deployed, agents can also verify remediation by comparing pre- and post-fix behavior, but this depends on broad access to rich, correlated production signals and a cost model that does not discourage adoption or experimentation.”

Not only are incidents resolved faster and with less stress, but AI can also free up SRE time to focus on proactive work and create a career path for junior developers into SRE roles. Quais Taraki, CTO at EDB Postgres AI, adds, “AI reduces toil by automating repetitive tasks while accelerating incident resolution through copilots that correlate signals across distributed systems, allowing SREs to focus more on resilience strategies like chaos engineering and failure analysis.”

AI can have long-lasting operational impacts, especially for organizations looking to deploy more mission-critical technology and AI capabilities. Two longer-term benefits of AI for SREs are reducing the number of bridge calls needed for incident response and the number of engineers required in “war rooms” to coordinate root cause analyses.

“When something goes wrong, AI that guides SREs can do the full analysis, get to the root cause, and perform the remediation,” says Spiros Xanthos, founder and CEO of Resolve AI. “AI also helps avoid many escalations, and when escalations are needed, it targets the right people from the network, infrastructure, and the application teams. AI for SREs centralizes operational intelligence, exposes tribal knowledge, and can guide more junior developers.”

AI agent reliability

While AI capabilities have been a net positive in helping SREs improve system reliability, the growth of AI code generators, vibe coding, and spec-driven development is adding to their workloads. According to one study, 41% of all global code is now AI-generated, and Gartner predicts that 40% of new enterprise production software will be created using vibe coding techniques by 2028.

But coding velocity is creating new issues for SREs as AI pull requests have 1.4 times more critical issues and 1.7 times more major issues, according to CodeRabbit. “AI-assisted development has created an unprecedented velocity of code reaching production, expanding surface area, edge cases, and failure rates faster than traditional SRE practices can absorb,” says Vinod Jayaraman, cofounder and CTO at NeuBird AI. “The speed of shipping has far outpaced the speed of understanding what breaks in production. To close this loop, SREs need enterprise agents that can capture precise diagnostic context, including correlated traces, service dependencies, and anomaly timelines, and structure it as actionable input for the engineers and AI coding tools responsible for the fix.”

The growing number of AI agents deployed to production creates new challenges. AI agents are not just code; they have multiple failure points. They are built using language models, connect to proprietary sources for context, and integrate with Model Context Protocol servers to support more complex workflows. Changes are ongoing and not deployment events, so the SRE’s job of identifying the source of performance and accuracy drifts isn’t trivial.

“Traditional SRE was built for systems that fail in reproducible ways, but agents fail differently and drift when a model provider pushes an update, and behavior shifts silently with no baseline for comparison,” says Mohammed Aboul-Magd, vice president of product at SandboxAQ. “Most organizations can’t even answer the basics: how many agents are running, what they have access to, and whether they’re still doing what they were built to do.”

“Every time a senior engineer leaves, they take years of learned failure patterns with them, and the next outage starts from square one,” adds Ronak Desai, cofounder and CEO at Ciroos. “Using AI for compounding operational memory changes that, and every incident your system resolves, the AI learns it.”

SREs should take a leadership role in emerging best practices, including defining their standards for AI agent non-functional acceptance criteria, observability practices, and release-readiness criteria. SREs should update their service-level objectives (SLOs) and define error budgets for AI agents in production.

Ryan Downing, vice president and CIO of enterprise business solutions at Principal Financial Group, says, “Standard SLOs and error budgets give teams the guardrails, and AI helps interpret the telemetry against those targets, reducing noise so engineers can get to the real issue faster and automate parts of remediation before customers are impacted.”

AI raises the SRE’s business impact

The more dramatic shift in site reliability engineering is an evolution of its business scope. IT leaders focus on uptime, performance, and issue resolution, as well as understanding their impacts. Business leaders will look to IT and SREs to identify, determine root cause, and remediate a broader class of issues, including rogue AI agents and the impacts of rapidly deploying new agentic capabilities.

“AI agents are handing SREs categories of problems they’ve never had to solve before, specifically failures defined in business terms, not technical ones,” says Blake Sherwood, distinguished technologist for AI and platform strategy at Smarsh. “Traditional reliability engineering is built around latency, errors, and crashes, but agents now fail due to skipped compliance steps or outcomes that looked fine technically but were wrong contextually. Most SRE teams aren’t wired for that yet.”

The question is whether SREs with AI-augmented tools can keep up with the velocity, complexity, and business urgency of deploying new AI business capabilities.

The next AI bottleneck is not the model. It’s the infrastructure behind it

Tue, 21 Jul 2026 11:03:50 +0200

Every enterprise AI conversation seems to begin with the same question: Which model should we use?

I understand why. Models are visible. They have names, benchmarks, release notes, pricing pages and impressive demos. They are easy to compare in a leadership meeting. One model promises better reasoning. Another offers a larger context window. Another appears faster, cheaper or more specialized.

But after years of working around enterprise platforms, integration layers, cloud migration, middleware, production operations and mission-critical systems, I see the AI conversation differently.

The model matters. But it is not where most enterprises will struggle next.

The next AI bottleneck is the infrastructure behind the model.

I do not mean only GPUs, cloud capacity or data storage. I mean the full enterprise operating layer that allows AI to work safely in the real world: data pipelines, identity, APIs, messaging, observability, security controls, deployment automation, cost governance, auditability, support ownership and recovery design.

That layer is what determines whether AI remains an exciting experiment or becomes a trusted business capability.

Pilots hide the hard part

Most organizations can build an impressive AI pilot. A small team can connect a model to a dataset, create a workflow and show a use case that works well in a controlled setting.

The harder part starts when that pilot moves into a real production process.

That is when practical questions show up. Who owns the data quality? What systems can the AI access? How do we trace which prompt, policy or retrieval flow produced a specific answer? What happens when an API slows down, a queue backs up or a downstream system is unavailable?

To me, these are not model problems. They are infrastructure problems.

This is where many enterprises are now headed. The first phase of AI was experimentation. The next phase is operationalization, and that is where the real gap becomes clear.

McKinsey has made a similar point in its work on agentic AI, noting that the next phase of value depends less on isolated tools and more on redesigning workflows, operating models and enterprise execution around agents.

AI pilots can survive on enthusiasm. Production AI requires architecture.

AI is becoming an integration problem

The more I look at enterprise AI, the more it feels like an integration challenge.

In large organizations, I have seen how messaging platforms, integration gateways, deployment pipelines, monitoring tools and cloud infrastructure can decide whether a digital capability succeeds or fails. AI will be no different. Even the strongest model will struggle if the data, middleware, identity layer and operational controls around it are weak.

AI does not work in isolation. It needs context from systems of record, clean data from different business areas, secure access to APIs, event streams, workflows, knowledge repositories, monitoring tools and legacy systems.

That is why the CIO question is changing.

It is no longer just, “Which AI tool should we buy?”

It is becoming, “Can we safely operationalize intelligence across the business?”

This is where agentic AI matters. Autonomous AI only creates real value when the architecture around it can make its actions safe, traceable and useful.

A model can generate an answer. Infrastructure determines whether that answer is secure, timely, explainable, governed and connected to the right workflow.

For example, an AI assistant that summarizes customer or order information may look like a model use case. But underneath, it depends on access control, fresh data, reliable APIs, logging, encryption, monitoring and policy enforcement.

If the answer is wrong, people may blame the model. But the real failure may have started with stale data, weak integration, poor access design, missing observability or an unreliable downstream system.

That is why CIOs should not judge AI only by model capability. The enterprise system around the model matters just as much.

Latency will become a trust issue

In traditional technology operations, latency is often treated as a performance metric. In AI-enabled workflows, latency becomes a trust issue.

When an employee asks an AI assistant for help and the response takes too long, the employee stops using it. When a customer-facing workflow becomes slow, the customer abandons it. When an AI agent waits on multiple backend calls, the entire business process feels unreliable.

This becomes even more important as organizations move from simple chat interfaces to agentic workflows. A single AI-driven action may include identity checks, context retrieval, policy validation, model reasoning, API calls, business-rule execution, logging and human approval.

Each step adds latency. Each dependency adds a possible failure point.

A model may be fast in a benchmark but slow inside an enterprise process. That difference matters.

This is where platform engineering becomes essential. Enterprises need reusable patterns for AI workloads: approved connectors, secure retrieval methods, queue-based decoupling, caching strategies, deployment pipelines, monitoring dashboards and standard rollback procedures.

Without those patterns, every AI initiative becomes a custom build. Custom builds may work for pilots, but they do not scale across a large enterprise.

Observability has to expand

Traditional monitoring tells us whether infrastructure is healthy. Is the server up? Is CPU high? Is memory exhausted? Is the application returning errors?

AI needs that, but it also needs more.

We need to know what data was retrieved, which model was used, which prompt version was active, which user initiated the request, which policy was applied, how long each step took and whether the output passed validation.

We also need to detect new forms of risk: unusual usage patterns, repeated failed tool calls, unexpected cost spikes, sensitive data exposure, weak retrieval results or an AI workflow attempting actions outside its intended boundary.

In production AI, observability is not only about uptime. It is about confidence.

If a business leader, auditor, regulator or security team asks why an AI system made a recommendation, the answer cannot be, “The model said so.” The enterprise needs traceability. It needs evidence. It needs operational context that engineers, risk teams and business owners can understand.

This is one of the biggest gaps I see in AI strategy. Many organizations are investing in models and use cases, but not enough in the control plane required to manage them.

Data readiness is still underestimated

AI has exposed an uncomfortable truth: many enterprises are not as data ready as they think.

Data is often duplicated across platforms, described differently by each team, governed inconsistently and refreshed on different schedules. Access rules may be clear in one system but unclear in another. Even basic business definitions can change from department to department.

AI does not fix that automatically. In many cases, it makes the problem more visible.

A bad report may be questioned. A bad AI answer may sound confident enough to be trusted.

That is a real risk.

Being data-ready for AI is not just about connecting a vector database or indexing documents. It requires clear ownership, lineage, classification, quality checks, retention rules, access boundaries and a shared understanding of which data should be used for which purpose.

The same principle applies to resilient cloud-native design. In my IEEE TechRxiv paper, “Enabling Fault-Tolerant Multicast in Cloud-Native Architectures” I explored how reliability, observability and fault tolerance become foundational requirements when critical workloads stretch across hybrid and multi-cloud environments.

CIOs already understand this because they have lived through enterprise resource planning programs, cloud migration, integration modernization, cybersecurity transformation and analytics initiatives. The lesson is familiar: technology cannot outrun data discipline forever.

Security cannot be added later

As AI moves from answering questions to acting, security becomes much more important.

An assistant that summarizes information carries one level of risk. An agent that can open a ticket, update a record, trigger a workflow, approve a request or contact a customer carries a very different one.

The more AI can do, the more identity, authorization, least privilege, separation of duties and human approval matter.

Enterprises should be careful not to grant AI broad access just to speed up a pilot. That may seem harmless in development, but it can become dangerous at scale.

AI access should be treated like any other privileged enterprise capability: limited, logged, reviewed and easy to revoke.

The NIST AI Risk Management Framework is a useful reference point here because it frames AI risk as something organizations must govern, map, measure and manage continuously rather than something handled only at the end of deployment.

Security teams should be involved early, not at the end. The goal is not to slow innovation. The goal is to build a platform where safe innovation becomes repeatable.

The CIO has to define the operating model

AI is creating pressure from every direction. Boards want productivity. Business teams want automation. Employees want better tools. Vendors are pushing new features. Security teams are watching risk. Finance teams are watching cost. Customers expect faster, smarter experiences.

The CIO sits in the middle of all of it.

That is why the CIO’s role cannot stop at choosing tools or approving pilots. The CIO has to define how AI will actually operate across the enterprise.

That means answering practical questions. Which architecture is approved? Which data sources can be trusted? How are AI workflows deployed, monitored, supported and governed? How are costs controlled? How do teams reuse common patterns instead of rebuilding the same foundation each time?

This work may not be as exciting as a model demo, but it is what separates sustainable AI from short-term experimentation.

The winning organizations will not be the ones with the most pilots. They will be the ones with the strongest AI operating layer.

They will build reusable platform patterns, strengthen data governance, design access properly, monitor AI behavior end to end and measure success by business improvement, not only model performance.

The model still matters. But the enterprise behind the model matters more.

A powerful model on weak infrastructure will eventually disappoint the business. A capable model on strong infrastructure can deliver real value because it can be trusted, secured, scaled and improved.

That is the shift CIOs need to lead.

The next AI bottleneck is not the model. It is whether the enterprise behind the model is ready.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

CIO 100 Leadership Live New York: CIOs push past AI pilots for measurable returns

Tue, 21 Jul 2026 01:07:24 +0200

Technology executives from across the New York metropolitan area gathered July 16 at Convene, One Liberty Plaza, for CIO 100 Leadership Live New York, a full day of roundtables and panel discussions on enterprise AI investment, governance, and organizational change.

Several key areas of consensus emerged throughout this highly interactive event. Infrastructure fragmentation continues to block the path to securing returns on AI investments prompting leaders to understand rising cloud spend attributed to large language model utilization. This has caused a growing number of organizations to refocus on on-premises and hybrid options in C-suite and board-level capital planning conversations. Speakers, along with comments from the audience, described a shift from project thinking to product thinking, with smaller multidisciplinary teams moving faster than legacy structures.

Several participants repeatedly warned that automating broken processes just amplifies dysfunction. Governance and measurement remain unresolved, with usage metrics still getting mistaken for business value. One of the panels explored how CIOs may benefit from applying venture capital-style scrutiny to enterprise bets, weighing team execution as heavily as the technology itself. The throughline was a redefinition of the CIO role, from technology executor to business strategist fluent in revenue, board engagement, and transformation ownership.

Morning roundtable tackles AI infrastructure

The day opened with an invitation-only executive breakfast roundtable, “Beyond the Pilot, Building the Infrastructure for Real AI Returns,” co-hosted by Unisys and Dell Technologies. Over a dozen executives representing major public and private sector organizations across the New York metropolitan area joined Steve Hollander, senior director of Americas global alliances at Dell Technologies, and Matt Marshall, CIO at Unisys for a workshop-style discussion.

The session explored the strategic, operational, financial, and technological issues that must be mastered to optimize infrastructure decisions and separate organizations that are experimenting with AI from those competing on it. Discussion questions probed how CIOs measure whether AI investment is translating into business results, how they can break the cycle of fragmented and siloed AI deployments, how boards are beginning to scrutinize seven-figure token spend and whether on-premises or hybrid infrastructure can rein in costs.

The take-home point: the organizations pulling ahead are the ones that stopped treating AI as four separate problems, strategic, operational, financial, technological, owned by four separate functions, and started running it as one coordinated decision. Fragmentation is the actual cost center here, not the token spend itself. A CIO who solves the infrastructure question in isolation from the governance question, or the cost question in isolation from the talent question, ends up optimizing one silo while the other three keep bleeding value. Competing on AI, instead of just experimenting with it, means the finance, operations, technology and business sides are reasoning from the same picture of what’s being built and why, so the tradeoffs get made once, together, instead of getting re-litigated at every handoff.

Forum sessions open with a mandate for growth

Following breakfast, the main forum program began with “The New CIO Mandate, Delivering Growth, Not Just Technology.” In a moderated conversation, Laksh Nathan, chief information officer at Paramount Skydance, drew on his experience with mergers, enterprise transformation and AI-enabled development to describe a shift from project and application management toward a product-centric operating model. Nathan addressed how smaller, multidisciplinary teams are changing expectations on both the business and technology sides of the enterprise, and what mindset changes CIOs must lead to turn AI into an engine of growth rather than a cost center.

PwC followed with a session on “Designing the Intelligent Enterprise, From AI Investment to Evolving Operations.” Darren O’Meara, principal and chief technology officer for managed services, and Meghna Shah, principal for engineering and AI, examined why fragmented outcomes persist even after heavy investment in technology and transformation.

The intelligent enterprise, they posited, is less about working toward achieving specific technology outcomes and more about creating operating models that integrate strategy, technology, operations, and governance into one system. This, they explained, requires linking AI, data, and decisions across the business and will leave an indelible mark on how decision rights are redesigned, funding models are developed, and accountability is enforced to accommodate the speed of the agentic economy.

Talent, tradeoffs, and the cost of getting it wrong

The session “Return on Transformation: Time, Talent, and Tradeoffs” — with Prashant Hinge, chief information and transformation officer at MSIG USA; Joseph Gimigliano, chief technology officer at Northwell Health; and Eduard de Vries Sands, AI executive advisor at PatientPoint — examined why transformation initiatives so often lose their way.

The main culprit, even today in 2026, continues to revolve around a persistent instinct for technology implementations to become the objective rather than the means to a measurable business outcome. The panelists made the case for doing the incredibly difficult work of re-engineering (if not entirely re-imagining) existing processes before automating them and then placing smaller bets inside that bigger vision.

Ricky Thakrar, head of sales and account management at Zoho, took the stage to present “Smaller, Smarter, Safer, The Enterprise AI Architecture Most Leaders Get Backwards,” arguing that constrained, context-rich architectures consistently outperform expensive models bolted onto fragmented systems.

A round of Hot Topic Discussion Groups and a networking lunch followed, including the Next CIO Luncheon featuring Robert Half Regional Director Jason Deneu.

Afternoon sessions turn to security, scale, and investment signals

CSO and CIO Contributor Joan Goodchild moderated “Securing Trust in the Agentic Economy,” a discussion with Marlowe Cochran, CISO at the New York State Education Department, and Gee Rittenhouse, vice president of security services at AWS, on how organizations are balancing speed, innovation and security as AI agents move from experimentation into productization at scale.

Rittenhouse framed agentic risk as closer to human risk than traditional software risk, describing how an independent agent acting in a non-deterministic way really does look like a potential insider threat, pushing CISOs toward behavioral monitoring over static workload protection. He tied this to a structural shift in defense, noting it’s hard to do agentic security if you’re not observing it, putting observability at the center of agentic risk management.

Cochran concurred, adding that many of the key tools that are needed to move into the agentic economy already exist, but must be implemented more aggressively, comprehensively and even more creatively. CISOs don’t need to invent an entirely new security discipline for the agentic era so much as extend identity management, access control and monitoring frameworks they already run to cover a new class of non-human actor — agents.

A session on “AI, From Experimentation to Enterprise Impact” brought together Meagan Gentry, national AI practice manager and distinguished technologist at Insight and Yuri Gubin, chief technology officer at DataArt, for a candid look at why pilots stall before reaching scaled production and what operating capabilities, governance, cost visibility, continuous education, must be in place to sustain AI once a proof of concept works.

During the session’s Q&A segment, a discussion emerged around how proof-of-concept success can result in a false signal, raising questions about whether pilots should be considered successful before the intended outcomes have had time to materialize, and drawing a distinction between measuring usage and adoption versus measuring business value.

The panelists explored how CIOs can identify the small number of transformational AI opportunities worth pursuing rather than managing hundreds of incremental use cases, and even challenged whether prioritization is the CIO’s job at all. The discussion closed on a sequencing question with real strategic weight, whether AI-first strategies are putting the technology ahead of the business problem CIOs are trying to solve, and what role CIOs should play with boards in defining the outcomes AI is expected to support.

A shift in perspectives

The “Think Like a VC, Investment Shifts Towards Focused AI Applications” session featured three venture investors, Aaron Darr, partner at Lead Edge; Isabelle Phelps, partner at Lerer Hippeau; and Marshall Porter, general partner at AlleyCorp. The panel explored how investors evaluate risk and talent in a market where products and competitive positions can shift within months, and what separates a focused AI application with durable enterprise value from an AI wrapper built to chase a trend.

The panel challenged the enterprise instinct to seek certainty in a market moving this fast, questioning whether CIOs should stop looking for technologies that will future-proof the enterprise and instead grow more comfortable continuously reassessing their bets. Investors framed this as a deliberate departure from the traditional low-tolerance-for-failure posture that has long governed enterprise technology purchasing, arguing that the search for certainty has itself become a risk in a market where products and business models can shift within months. The discussion pressed CIOs to weigh how they can adopt a more dynamic investment mindset without compromising the enterprise security, governance and accountability their organizations still depend on.

A Lightning Insights followed, featuring five-minute briefings from Insight, Platform9 and Console, followed by Keystone Senior Principal Ellora Sarkar’s talk on why most enterprise AI investment fails to produce measurable value and what separates the small share of firms capturing real return on investment from the majority still stuck in pilots.

Closing the day

The forum closed with “What’s Next for the CIO, Preparing for the Next 12 to 24 Months,” a fireside conversation with Leif Maiorini, CIO for corporate services at Omnicom. Maiorini discussed why business processes need to be redesigned for agentic speed rather than automated around existing human workflows, how organizational structures may shift as autonomous agents reshape visibility and decision support, and where sustainable differentiation will come from once AI capability itself becomes widely accessible.

Maiorini encouraged the industry to clearly distinguish between nondifferentiated services that should be made as efficient as possible and the differentiated capabilities that actually influence why customers choose to do business with an organization, once the major efficiency gains from optimization and AI have been captured.

He was candid about the governance gap agentic systems open up, noting that agents lack the professional reputation, personal accountability and inherent constraints that shape human behavior, which creates new risk when autonomous decisions occur at machine speed. That combination, reinvesting efficiency gains into genuine differentiation while building governance models suited to non-human decision-makers, framed his closing case for why human creativity and judgment remain the enterprise’s most durable asset even as the underlying technology becomes commoditized.

Join the CIO 100 Awards & Conference Aug 17–19, 2026 at Omni PGA Frisco Resort & Spa, Frisco, TX — where top IT leaders celebrate innovation and connect. Learn more to attend or partner.

Automated Observability with Puppet in a Zero-Trust Environment (voxconf2026)

Tue, 21 Jul 2026 00:34:08 +0200

Building comprehensive infrastructure observability traditionally requires manual configuration of monitoring targets, brittle configuration management and endless YAML files. Every new server means updating Prometheus configs, managing certificates and hoping nothing breaks. What if your infrastructure could monitor itself automatically from the moment a server boots? This talk demonstrates a production-ready architecture that combines modern Puppet patterns with automated service discovery to create truly self-configuring observability. Using Puppet's exported resources, nodes automatically register themselves for monitoring without any manual intervention. New web servers are discovered and scraped within minutes of provisioning—no configuration updates required. You'll learn how to implement: * Modern Puppet classification using CSR attributes instead of site.pp node definitions. Nodes self-classify by embedding their role directly in their TLS certificate, eliminating centralized configuration bottlenecks. * Hiera-based roles defined as pure YAML data instead of Puppet manifests, making roles accessible to non-Puppet experts and enabling templated role generation. * Automated service discovery through Puppet's exported resources. Each node exports its monitoring endpoints to PuppetDB, which a lightweight Python script queries to generate Prometheus file-based service discovery targets. Zero manual configuration required. * Zero-trust security using Caddy as an mTLS reverse proxy. All metrics traffic is secured with mutual TLS using Puppet's existing CA infrastructure—no additional certificate management needed. * Universal observability with node_exporter on every server and application-specific exporters (apache_exporter, etc.) automatically configured based on the node's role. The architecture scales from a handful of servers to thousands, works seamlessly with cloud auto-scaling and provides complete visibility into both system and application metrics. Attendees will observe a demo with working code, container configurations and a deep understanding of how to build self-managing infrastructure that doesn't require operator intervention to stay observable. https://corporate-gadfly.github.io/zero-trust-observability/#/title-slide about this event: https://c3voc.de

Automated Observability with Puppet in a Zero-Trust Environment (voxconf2026)

Tue, 21 Jul 2026 00:18:38 +0200

Building the network for agentic AI: The foundation for autonomous enterprise operations

Mon, 20 Jul 2026 12:03:46 +0200

Enterprise AI is entering a new phase. While the first wave of generative AI focused on human productivity and content creation, the next wave — agentic AI — will fundamentally change how organizations operate. Agentic AI systems are capable of reasoning, planning, making decisions and executing actions across applications, workflows and business processes with minimal human intervention.

As organizations move toward agentic frameworks that can independently resolve customer issues, optimize supply chains, manage infrastructure, coordinate workflows and even operate IT environments, one reality becomes clear: The network becomes the nervous system of the autonomous enterprise.

The infrastructure requirements of agentic AI differ dramatically from those of traditional applications. These systems are highly distributed, continuously exchanging information, interacting with APIs, accessing multiple data sources and making decisions in real time. The performance, security, visibility and adaptability of the network will directly determine the effectiveness of AI agents. Organizations that view AI readiness solely as a compute or data challenge risk overlooking one of the most critical enablers of future success — the network itself.

From AI-ready networks to autonomous networks

The long-term destination is the autonomous network: A network capable of self-monitoring, self-optimizing, self-healing and self-securing through the use of AI and automation. However, autonomous networking will not emerge overnight. The investments enterprises make today to support agentic AI are the same foundational building blocks required for tomorrow’s autonomous operations.

In many ways, agentic AI serves as both the driver and beneficiary of network transformation. AI agents require networks that can dynamically adapt to changing demands, while autonomous networks will increasingly rely on AI agents to manage and optimize themselves. The result is a reinforcing cycle where AI and networking evolve together.

The core characteristics of the network of the future

One of the most critical requirements for AI-ready networks is real-time observability and telemetry. Agentic AI thrives on context, and AI agents must continuously gather information from users, applications, devices, clouds, security systems and operational platforms. Future-ready networks must provide end-to-end visibility across campus, branch, cloud and data center environments. High-fidelity telemetry streams, real-time performance monitoring, application-aware analytics, AI-aware analytics and unified operational visibility are essential. Without comprehensive visibility, AI agents operate with incomplete information, limiting their effectiveness and increasing operational risk.

Another cornerstone is intent-based automation. Traditional networks are configured manually, often requiring administrators to define thousands of individual settings. In contrast, autonomous networks operate according to business intent. Enterprises increasingly need to define desired outcomes — such as maintaining application performance, optimizing user experience or automatically isolating compromised devices — rather than micromanaging configurations. The network continuously adjusts itself to achieve those objectives, providing the foundation upon which AI agents can make decisions safely and consistently.

Agentic AI also introduces entirely new traffic patterns that require AI-optimized connectivity. Large language models, retrieval systems, vector databases, cloud AI services, edge inference platforms and multi-agent orchestration frameworks create significant east-west and cloud-bound traffic. Future networks must provide low-latency connectivity, high-capacity fabrics, dynamic traffic engineering, edge-to-cloud optimization and policies that identify and prioritize AI workloads. The organizations that can move data efficiently will gain a competitive advantage in AI execution speed and responsiveness.

Security is another non-negotiable element. Agentic AI expands the enterprise attack surface because AI agents increasingly access sensitive systems, interact with APIs, consume proprietary data and execute actions across business environments. Future-ready networks must embed zero trust security into their architecture, with continuous identity verification, fine-grained access controls, microsegmentation, policy-driven authorization and continuous risk assessment. Security can no longer be bolted onto the network; it must be integral to its design and AI agents need to adhere to their own identity rules.

Finally, distributed intelligence across edge and cloud environments is essential. Many AI use cases require decisions to occur close to the source of data. Manufacturing systems, healthcare environments, retail operations, transportation networks and smart facilities often cannot tolerate the latency associated with centralized processing. Future networks must support edge AI deployment, distributed processing architectures, local inference, hybrid cloud operations and intelligent workload placement. The ability to move intelligence closer to users, devices and operational environments will become increasingly important as agentic AI expands across the enterprise.

Human expertise remains essential

Despite rapid advances in AI, the future will not eliminate the need for human expertise. In fact, it may increase its importance. One of the most significant misconceptions surrounding AI is that automation eliminates the need for skilled professionals. The reality is that autonomous systems require expert oversight, governance, validation and continuous optimization.

As AI systems become more capable, enterprises will need professionals who understand network architecture, security policy, AI governance, operational risk management, data quality, regulatory compliance and human-in-the-loop decision frameworks. The challenge is compounded by the unprecedented pace of AI innovation. New models, architectures, orchestration frameworks, security concerns and governance requirements emerge almost monthly. Most enterprise IT teams cannot be expected to independently evaluate every development while simultaneously modernizing infrastructure and maintaining day-to-day operations.

Organizations need access to experts who continuously track technology evolution, understand emerging best practices and can help translate innovation into practical deployment strategies. These experts provide not only implementation support but also ongoing operational guidance, helping enterprises maintain appropriate human oversight as AI capabilities expand. The future is not fully autonomous decision-making without people; it is intelligent automation operating under expert human governance.

5 actions enterprises should take now

Organizations should be preparing for the autonomous future right now. The following investments deliver immediate value while laying the groundwork for long-term AI transformation:

Modernize network observability. Establish comprehensive visibility across users, applications, devices, clouds and infrastructure. Rich telemetry and operational data will become the fuel that powers both Agentic AI and autonomous network operations.
Build an automation-first operating model. Identify repetitive operational processes and begin automating them. Automation maturity is a prerequisite for autonomous networking and creates the operational foundation AI agents will eventually leverage.
Adopt zero-trust principles across the enterprise. Implement identity-centric security controls, segmentation and continuous policy enforcement. As AI agents gain access to enterprise systems, security architectures must evolve to leverage the same identity controls.
Design for edge-to-cloud AI workloads. Evaluate network architectures for latency, bandwidth and resiliency requirements associated with distributed AI. Future AI deployments will span data centers, public clouds, branch locations and edge environments.
Invest in skills and strategic partnerships. Develop internal expertise while leveraging partners that possess deep networking, automation, security and AI knowledge. Human expertise remains one of the most important success factors in building AI-ready and autonomous infrastructures.

The road ahead

Agentic AI is poised to transform enterprise operations in much the same way cloud computing transformed infrastructure and the internet transformed business itself. But AI agents cannot operate effectively without a modern network foundation. The enterprises that succeed will recognize that AI readiness extends beyond models and data. It requires networks that are observable, automated, secure, intelligent and increasingly autonomous. The investments made today in AI-ready networking are not merely infrastructure upgrades — they are strategic building blocks toward the autonomous enterprise of the future, where AI agents and autonomous networks work together under human guidance to deliver unprecedented levels of agility, efficiency, and innovation.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Vibe Coding erklärt

Mon, 20 Jul 2026 07:54:16 +0200

Vibe Coding verspricht viele KI-getriebene Vorteile, macht Softwareentwickler jedoch nicht überflüssig – eher im Gegenteil.

Fit Ztudio | shutterstock.com

Im Dev-Umfeld verschwimmt die Grenze zwischen Programmieren und Prompten schon seit einigen Jahren. Auf die Spitze getrieben wird diese Entwicklung vom Vibe-Coding-Trend: Frühe KI-Entwickler-Tools wie GitHub Copilot waren vornehmlich darauf ausgelegt, Devs zu unterstützen. Etwa, indem sie Funktionen und Syntax ergänzten oder Boilerplate-Code aus Kommentaren generierten. Kommt ein Vibe-Coding-Ansatz zum Zug, beginnen menschliche Entwickler hingegen gar nicht erst damit, Code zu schreiben.

Dieses Konzept führt nicht nur zu veränderten Workflows, sondern erfordert auch, ein neues Mindset. Schließlich wird die Programmierarbeit mit Vibe Coding eher zu einer Art Live-Prototyping. In diesem Artikel lesen Sie:

warum Vibe Coding Vibe Coding heißt,
inwieweit sich dieser Ansatz für Unternehmen eignet,
wie Vibe-Coding-Workflows konkret aussehen (können),
welche Tools in diesem Bereich zu empfehlen sind,
welche Risiken Sie dabei auf dem Schirm haben sollten, sowie
Tipps dazu, wie Sie Vibe Coding effektiv in der Praxis umsetzen.

Vibe Coding – Begriffsdefinition

Der Begriff Vibe Coding wurde Anfang 2025 vom OpenAI-Mitbegründer Andrej Karpathy geprägt. Der KI-Experte trat den Trend mit einem Post auf dem Kurznachrichtendienst X los.

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper…
— Andrej Karpathy (@karpathy) February 2, 2025

In diesem beschreibt Karpathy die Vibe-Coding-Methodik als eine neue Coding-Form, bei der man sich ganz den “Vibes” hingibt und vergisst, dass der Code überhaupt existiert. Amy Mortlock, Vice President of Marketing beim OSINT-Spezialisten ShadowDragon, erklärt das Konzept etwas weniger kryptisch: “Beim Vibe Coding beschreibt man in natürlicher Sprache, was man möchte, und die KI generiert dann die gesamte Anwendung und kümmert sich um alle technischen Details.”

Vibe Coding setzt also darauf, die traditionelle Programmierarbeit durch dialogorientierte Anweisungen und Kooperation mit einem KI-Assistenten zu ersetzen. Statt detaillierte Spezifikationen zu entwerfen und diese an die Engineers weiterzugeben, können Produktmanager, Fachexperten – oder jeder andere, der eine Idee hat – in einfacher Sprache beschreiben, wie das Ergebnis aussehen soll. Die KI-Software erledigt dem Rest in Echtzeit. Allerdings geht es dabei weniger darum, die Softwareentwicklung durchgängig zu automatisieren.

Vielmehr stehen Mindset-Veränderungen im Fokus: Warum sollte man nicht der KI die Mechanik überlassen und sich stattdessen auf die Ausrichtung, das Feedback, den Flow und die “Vibes” konzentrieren? Schließlich werden die Modelle, die Tools wie Cursor oder GitHub Copilot zugrunde liegen, immer performanter. Deswegen sehen auch viele Developer ihre Arbeit inzwischen vorwiegend als einen Dialog mit der KI – statt sich zeilenweise selbst durch Syntax zu wühlen.

Und obwohl auch bei einem Vibe-Coding-Ansatz diverse Probleme und Herausforderungen auf den Plan treten können (dazu später mehr): Die Technik gewinnt zunehmend an Popularität – auch im Unternehmensumfeld.

Vibe Coding im Unternehmen

Wie das in der Praxis konkret aussieht, beschreibt Charles Ma, Softwareentwickler beim Observability-Spezialisten Chronosphere: “Viele unserer Entwickler nutzen Tools wie Cursor und Claude Code. Wir fördern deren Einsatz sogar über ein Nutzungs-Leaderboard. Dabei betrachten wir die Tools jedoch als Assistenten, nicht als Dev-Ersatz. Unser Code-Review-Prozess ist weiterhin Pflicht für jeden Produktionscode – und wir sehen eher davon ab, viele unserer oder gar externe Tools mit KI zu verbinden.”

In der Perspektive von Achint Agarwal, Vice President of Product beim KI-Anbieter Pramata, hat Vibe Coding vor allem die Art und Weise verändert, wie Teams vom Konzept zum Prototyp gelangen: “Früher mussten UI/UX-Designer und Entwickler zusammenarbeiten, um eine Idee in etwas zu verwandeln, mit dem Kunden interagieren konnten. Dieser Prozess konnte leicht mehrere Wochen dauern und diverse Überarbeitungsrunden umfassen.”

Heute, so Agarwal, könne ein Produktmanager oder Fachexperte einfach in natürlicher Sprache formulieren, was er sich vorstellt, und die KI generiere funktionierenden Code in Prototyp-Qualität. “Bei dieser Veränderung geht es um mehr als nur Geschwindigkeit: Auch die Qualität der Ergebnisse ist besser, weil die Person, die den Anforderungen am nächsten steht, während des gesamten Prozesses die Kontrolle behält und es keine Reibungsverluste durch Übergaben gibt”, fügt der Manager hinzu.

Auch Agarwal sieht in Vibe Coding kein Substitut für die traditionelle Softwareentwicklung, sondern vor allem ein Explorations- und Validierungs-Tool: “Dev-Teams ist es damit möglich, in kurzer Zeit funktionierende Prototypen zu erstellen, diese mit Kunden zu testen und zu überprüfen, ob die Idee sinnvoll ist. Fällt diese Prüfung positiv aus, kann der Prototyp an die Engineers gehen, die ihn mit Blick auf Skalierbarkeit, Sicherheit und langfristige Integrationen weiter ausbauen.”

Wie sieht ein Vibe-Coding-Workflow aus?

Es gibt keine allgemeingültige Blaupause für Vibe Coding. Entsprechend gehen auch die Ansichten darüber auseinander, wie ein typischer Vibe-Coding-Workflow aussieht. Kostas Pardalis, Data Infrastructure Engineer beim KI-Lösungsanbieter Typedef, beschreibt diesen als agilen, vierstufigen Prozess:

die Erkundungsphase, in der der “Vibe”, der Zweck und die Einschränkungen definiert werden.
die Gestaltungsphase, in der ein funktionierender Prototyp erstellt und verfeinert wird.
die Grounding-Phase, die genutzt wird, um Struktur und Datenintegrität hinzuzufügen.
die Operationalisierungsphase, in der Versionierung, Evaluierung und Governance hinzukommen.

Steve Croce, Field CTO beim Open-Source-Unternehmen Anaconda, steht hingegen auf dem Standpunkt, dass der Vibe-Coding-Workflow davon abhängig ist, ob ein Prototyp, eine Zwischenlösung oder eine vollständige Produktionsapplikation entwickelt werden soll. Basierend darauf, orientiert sich der Vibe-Coding-Workflow in der Vision des Technologieentscheiders eher am traditionellen Software Development Lifecycle – fußt jedoch ebenfalls auf vier Stufen:

In der Phase der Planungs- und Anforderungsanalyse könnten Produktmanager und UX-Teams demnach voll und ganz auf Vibe Coding setzen und so vor der formellen Entwicklung klickbare Prototypen und Machbarkeitstests erstellen.
Im Rahmen der Design-Phase kann KI laut Croce dabei unterstützen, Architekturen und Dokumentationen zu erstellen. Der Manager weist allerdings darauf hin, dass es in dieser Phase auch hilfreich sein könne, erfahrene Engineers oder Architekten hinzuziehen, um die Einhaltung von Standards und die Reusability interner Systeme zu gewährleisten.
Als Kernbereich der Vibe-Coding-Experience sieht Croce die Implementierungs- und Testphase: Ein KI-Agent könne an dieser Stelle die gesamte Anwendung erstellen und darüber hinaus auch Repositories strukturieren und Tests durchführen. Der Experte rät Unternehmens-Teams jedoch mit Blick auf die Testabdeckung und Konformitätsprüfungen auch in dieser Phase dazu, menschliche Profis hinzuzuziehen.
In der Bereitstellungs- und Wartungsphase könne KI laut dem CTO dazu genutzt werden, Apps bereitzustellen und zu warten. Dieser Part könne jedoch auch vollständig außerhalb der Vibe-Coding-Erfahrung abgewickelt werden, um den Unternehmensanforderungen zu entsprechen, so Croce.

Empfehlenswerte Vibe-Coding-Tools

Vibe-Coding-Tools decken ein breites Spektrum ab: Vom leicht zugänglichen, dialogorientierten Builder für nicht-technische Teams, bis hin zu integrierten Entwicklungsumgebungen (IDEs), die Engineers umfassende Kontrollmöglichkeiten bieten und zuverlässige Anwendungen gewährleisten. Die Wahl des richtigen Tools hängt von den Fähigkeiten des Teams, dem Projektziel und dem benötigten Maß an Governance ab.

Eine kleine Auswahl empfehlenswerter Tools für Vibe-Coding-Zwecke:

Cursor ist eine KI-integrierte IDE, mit der sich mehrere Dateien bearbeiten lassen.
Replit ist eine gute Wahl für Browser-basierte Entwicklungsarbeit.
Bolt und Lovable sind Builder, eignen sich vor allem für schnelles Brainstorming und zeichnen sich durch überschaubaren technischen Aufwand aus. Diese Tools sind daher auch für Einsteiger geeignet.
Windsurf und Zed sind vollständige IDEs, die darauf ausgelegt sind, Vibe-Coding-Funktionen in traditionelle Dev-Umgebungen zu integrieren.

Diese Risiken birgt Vibe Coding

Trotz der genannten Vorteile birgt der Vibe-Coding-Ansatz auch diverse Risiken mit Blick auf die Wartbarkeit und Anfälligkeit der generierten Logik. So warnt etwa ShadowDragon-Managerin Mortlock: “Sicherheitslücken und technische Schulden sind die Hauptprobleme in Zusammenhang mit Vibe Coding. KI kann manchmal unsichere Pattern oder auch veraltete Bibliotheken einbinden.”

Zudem sei KI-generierter Code in den meisten Fällen auch länger, was das Debugging langwierig und mühsam gestalten könne, erklärt Mortlock. Sie fügt hinzu: “KI verweist unter Umständen auch auf nicht existierende Packages, was auch böswillige Akteure ausnutzen könnten. Was wie funktionierender Code aussieht, kann versteckte Fallen bergen.”

Charles Ma, Software Engineer beim Observability-Spezialisten Chronosphere, sieht ein weiteres Problem, das die Angriffsfläche potenziell vergrößert: “Selbst erfahrene Engineers können selbstzufrieden werden und dann Probleme übersehen, die ihnen sonst nicht entgangen wären. Sobald KI-Tools mit externen Systemen verbunden sind oder Websuchen durchführen, besteht außerdem das Risiko von Prompt Injections und Toolchain-Exploits.”

Infrastruktur-Profi Pardalis fokussiert mit Blick auf die Risiken von Vibe Coding vor allem die Bereiche Volatilität und Sichtbarkeit: Weil dieser Ansatz für schnelle Iterationen und Modellautonomie förderlich sei, bestünden die Hauptrisiken in unkontrollierter Variabilität und undurchsichtigen Quellen. Um diese Probleme zu bekämpfen, appelliert Pardalis für:

Lineage Tracking: Jede Version wird committet und verwendet Frameworks mit integrierter Traceability.
Evaluierungsschleifen: Qualitäts- und Regressionsprüfungen werden automatisiert durchgeführt.
Governance-Layer: Prompt-Historien werden auditiert und sensible Daten gefiltert.

Der Engineering-Profi ist der Ansicht, dass eine expressive, modellgesteuerte Softwareentwicklung und eine deterministische Infrastruktur unter disziplinierten Rahmenbedingungen koexistieren können: “Letztendlich verspricht Vibe Coding kein Chaos, sondern strukturierte Kreativität. Sie entwickeln Ideen schnell, setzen sie aber sicher um. Mit anderen Worten: Freiheit am Anfang, Disziplin im weiteren Verlauf – so kann Vibe Coding tatsächlich in Produktionsumgebungen skaliert werden.”

6 Tipps für effektives Vibe Coding

Da Sie nun umfassend über alle Aspekte des Vibe-Coding-Ansatzes informiert sind, geben wir Ihnen abschließend noch ein paar Tipps an die Hand, um Ihre eigene Initiative erfolgreich umzusetzen. Diese haben wir aus unseren Gesprächen mit den im Artikel zitierten Spezialisten zum Thema extrahiert

Beginnen Sie mit Zielen, nicht mit Funktionen: Beschreiben Sie zunächst die gewünschte User Experience und die wesentlichen Geschäftsprobleme, die mit der Initiative gelöst werden sollen. Dabei müssen Sie es nicht übertreiben und jeden Button oder Screen definieren – für relevante Lösungen ist es entscheidend, der KI so genau wie möglich zu beschreiben, was erreicht werden soll.
Planen Sie voraus: Vibe Coding ist nicht in der Lage, eine gute Architektur zu ersetzen. Bevor Sie KI hinzuziehen, sollten Sie deshalb sicherstellen, dass Design und Spezifikationen stimmen. Das erleichtert es der KI, “Intent” in kohärente Systeme zu übersetzen.
Verstehen Sie KI als Partner: Es gilt, mit Vibe-Coding-Tools zu kollaborieren. Diese Werkzeuge brauchen Anleitung und ihre Ergebnisse müssen überprüft werden. Blindes Vertrauen kann an dieser Stelle kontraproduktiv sein. Sie sollten deshalb nicht zögern, die KI-generierte Logik in Frage zu stellen.
Nutzen Sie Frameworks, Kontext und Beispiele: Etablierte Frameworks zu nutzen, erspart es Ihnen alles von Grund auf neu zu entwickeln. Die KI mit Beispielanwendungen zu füttern oder (vertrauenswürdige) MCP-Server hinzuzuziehen, um Kontext in größeren Projekten zu managen, kann ihre Fähigkeiten erweitern.
Halten Sie Menschen – und Security – im Loop: Setzen Sie auch bei Vibe- respektive KI-Coding-Tools auf das Least-Privilege-Prinzip – und Review-Prozesse. Engineering Best Practices anzuwenden, empfiehlt sich ebenfalls: Generieren Sie Tests, verifizieren Sie Funktionalitäten. Und betrachten Sie die Tools als Kreativitäts- und Produktivitäts-Support. Nicht als Substitut für Skills und Knowhow.
Iterieren und verfeinern Sie: Nehmen Sie mit Blick auf Vibe Coding Abstand vom Streben nach Perfektion (auch wenn es Ihnen widerstrebt) und finden Sie sich möglichst frühzeitig mit unvollkommenen Ergebnissen ab. Tracken Sie Prompts, cachen Sie Checkpoints und verfeinern Sie die Ergebnisse – solange, bis der “Flow” zu einer zuverlässigen Funktionalität wird.

(fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.

An SRE's Guide to Camping in Extreme Conditions (emf2026)

Sun, 19 Jul 2026 13:47:51 +0200

Winter camping in the Alps sounds beautiful… doesn't it? That is, until the pipes freeze or the heating goes out when it’s -21°C outside. By day, I'm an SRE responsible for incident management, triaging alerts, and calling in subject matter experts when required. It turns out that those skills are transferable to handling real-life situations, too! In this talk, I’ll share a fun (slightly traumatic) guide to applying SRE thinking to camping. I'll talk about hacky fixes to resolve the immediate impact, the process of narrowing down the root cause, and the beauty of pattern matching in observability. You’ll see that monitoring, escalation, and redundancy aren’t just for data centres. They’re survival tools. If you’ve ever been on-call or just like a good disaster story, join me for this slightly chaotic, entirely true adventure in off-grid reliability. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://www.emfcamp.org/schedule/2026/230-an-sres-guide-to-camping-in-extreme-conditions

Observability als Engineering-Problem: Weniger sammeln, mehr verstehen

Sat, 18 Jul 2026 09:18:27 +0200

Zwei OpenTelemetry-Experten erklären, warum zu viele Daten schaden – und wie ein Top-down-Ansatz die Zuverlässigkeit der Observability rettet.

AI workloads shake up observability market

Fri, 17 Jul 2026 18:28:45 +0200

Observability platforms are evolving beyond traditional monitoring as vendors add AI capabilities and cost-management features aimed at helping enterprise organizations better manage increasingly complex IT environments.

Vendors are investing heavily in AI observability, autonomous investigations, cost optimization, and operational intelligence as they try to evolve their platforms into systems that help IT teams understand problems, identify root causes, and determine the best course of action, according to Gartner, which just published its latest Magic Quadrant for Observability Platforms.

Gartner defines the observability category as technologies that help organizations understand and optimize the health, performance, and behavior of applications, infrastructure, services, AI agents, and user experiences by collecting and analyzing telemetry data, such as logs, metrics, events, and traces.

There are 19 vendors that made the cut for Gartner’s new report. Its Leaders quadrant includes (alphabetically) Chronosphere, Coralogix, Datadog, Dynatrace, Elastic, Grafana Labs, IBM, and New Relic. The Challengers are Alibaba Cloud, Amazon Web Services, LogicMonitor, Microsoft, and Splunk. The two Visionaries are BMC Helix and Honeycomb. Those dubbed Niche Players are Apica, HPE, ScienceLogic, and SolarWinds. (For specific vendor strengths and cautions, check out the full Gartner report. Some vendors offer free versions of the report with registration.)

Looking beyond quadrant placement, Gartner advises organizations to evaluate vendors based on their ability to deliver full-stack observability and their “roadmap credibility” in key areas such as AI observability, OpenTelemetry interoperability, and the ability to observe and govern AI agents.

AI observability emerges as a key differentiator

Organizations are increasingly looking for visibility into AI workloads, including token consumption, model latency, response quality, hallucination rates, and other AI-specific performance metrics, according to the report. Gartner identifies AI observability as an emerging requirement, driven by growing enterprise interest in large language models (LLMs), genAI applications, and agentic AI systems.

The report recognizes a growing number of vendors introducing AI-focused monitoring, autonomous investigations, AI agents, and specialized observability capabilities designed to help organizations monitor and govern AI-powered applications and workflows. At the same time, Gartner clarifies that many claims surrounding autonomous operations remain ahead of reality.

“The transition from generative AI assistants to autonomous agents is more complex than vendor marketing suggests,” the report states.

Cost management becomes a top priority

While AI may dominate vendor messaging, Gartner states that telemetry cost management remains one of the top concerns for enterprise buyers.

As organizations collect larger amounts of logs, traces, metrics, and events, observability spending is increasingly attracting attention from finance and procurement teams. Gartner notes that 5% of its clients now spend more than $10 million annually with a single observability provider.

Gartner describes pipeline management as a strategic layer that is becoming central to observability deployments. Vendors that fail to address these cost concerns risk losing customers to vendor-agnostic alternatives focused on telemetry optimization. Organizations increasingly want platforms that can provide cost attribution, utilization insights, and financial metrics that help justify observability investments, according to Gartner.

Gartner projects the observability market will reach $14.3 billion by 2028, driven increasingly by organizations’ need to manage growing telemetry volumes.

OpenTelemetry is table stakes as consolidation continues

The growing impact of open standards is a major shift for observability, Gartner notes.

The widespread adoption of OpenTelemetry and eBPF-based instrumentation has lowered barriers to switching observability providers and made telemetry collection increasingly commoditized, the research firm explains. Gartner says many enterprise buyers now consider OpenTelemetry support a baseline requirement rather than a differentiator.

As a result, vendors are now trying to differentiate themselves through analytics, automation, AI capabilities, and user experience rather than proprietary data collection approaches. That shift is forcing vendors to demonstrate value beyond monitoring and visibility, as buyers seek platforms capable of accelerating troubleshooting, automating investigations, and improving operational outcomes, according to Gartner.

Gartner says market consolidation continues to favor platform-oriented vendors that combine full-stack observability with integrated AI capabilities. Organizations are increasingly looking for unified platforms that can monitor applications, infrastructure, digital experiences, and AI workloads from a single environment.

The rise of operational intelligence

As enterprises modernize applications and expand AI initiatives, organizations want platforms that can not only identify problems but also explain causes, prioritize actions, and potentially automate remediation. Vendors are expanding observability platforms with AI-driven analytics, automation, and governance capabilities that span applications, infrastructure, cloud services, and AI workloads.

For enterprise buyers, the next phase of observability may be defined less by telemetry collection and more by how effectively vendors can transform data into intelligence, automation, and measurable business outcomes.

The build vs. buy dilemma at the heart of enterprise AI

Fri, 17 Jul 2026 12:17:08 +0200

For three decades, enterprise software has been a buy-it decision. Packaged software from SAP, Oracle and Salesforce covered roughly 80% of requirements at a fraction of the cost of building. The economics were obvious, and for traditional applications, they still are.

AI is introducing a wrinkle that is forcing even the most committed enterprise software customers to rethink their options. AI is a layer that sits across your data, your processes, and your decisions. Where that layer runs and who controls it is an architecture question, and most of the enterprise community is still treating it as a procurement one.

The appeal of vendor-embedded AI is clear: automated operational decisions, smarter supplier and merchandising choices, and friction-free workflows built into the systems enterprises already rely on. The catch is that these capabilities almost universally depend on your data living in the vendor’s cloud environment. For most large enterprises, it sits on-premises, in hyperscale cloud infrastructure they manage themselves, or in private data centers. That gap between where your data is and where your vendor’s AI assumes it should be creates a fundamental strategic fork in the road.

Build vs. buy is a category error

The framing I keep hearing is “build vs. buy your AI strategy.” It implies that some organizations are out there training foundation models from scratch. Nobody serious is doing that. The real choice sits across three distinct approaches, and conflating them leads to poor decisions:

Buy embedded. Use the AI capabilities your vendor ships natively inside their platform: the assistant baked into your ERP, your CRM, your HCM suite. Lowest integration cost, fastest time to value, tightest fit with the application data.
Buy platform. Adopt the vendor’s AI infrastructure layer and build your own assistants and agents on top of it. More flexible, but you remain inside the vendor’s architectural boundary and subject to their governance model.
Compose. Connect a third-party model (Claude, GPT, Gemini, an open-weight model running in your own environment) directly to your existing landscape. Maximum control, maximum integration burden, and full responsibility for what comes out the other end.

These are not equivalent options at different price points. They make different assumptions about where your data lives, who governs the AI, and how much architectural change you’ll absorb to get there. Vendor pitches sometimes blur the distinction on purpose. Enterprise leaders can’t afford to.

The vendor AI stack has an assumption baked in

Every embedded AI capability ships with an unstated architectural prerequisite: your data must be where the AI can see it, in the shape it expects, under the governance the vendor enforces.

For organizations with clean, modern cloud estates, that is often a reasonable trade. For the long tail of large enterprises running heavily customized environments on private or hybrid infrastructure, that trade becomes a precondition, one you must meet before the AI conversation can even begin. Whether meeting it makes sense depends on your starting point, your sector’s regulatory posture, and your appetite for migration risk. None of those are uniform across organizations.

That’s the part that gets glossed over in vendor keynotes. The AI demo on stage assumes a destination architecture the audience hasn’t necessarily reached yet. Large enterprise customers are carrying an unusually heavy technology burden right now. Many are simultaneously managing platform modernization programs that have been building for over a decade, alongside pressure to migrate to vendor-managed cloud infrastructure. Sitting above both is a boardroom-level directive to demonstrate meaningful AI progress fast. The vendor path to AI and the boardroom path to AI can diverge sharply, and enterprises need to make selective, strategic decisions about where to adopt AI first to maximize value and minimize risk.

Sovereignty isn’t a slogan, it’s an architecture constraint

The conversation about sovereignty has been hijacked by both sides. One camp treats every SaaS adoption as a sovereignty violation. The other dismisses every sovereignty concern as Luddite resistance. Neither is useful.

What’s happening in real customer conversations – particularly in DACH, public sector, and financial services – is more specific. Organizations are drawing a distinction between running their applications in a vendor’s cloud (which is broadly fine, well understood, decades of precedent) and enriching their data and processes inside a vendor’s AI model (which has less precedent, is harder to reverse, and carries material implications for competitive position).

Enriching your data inside a vendor’s AI model is the genuinely new question, and organizations that conflate it with their existing cloud posture tend to defend the wrong perimeter.

Despite spending around $100 million annually with Amazon, Disney built its own internal AI system to house its corporate intelligence rather than rely on a hyperscaler’s AI offering. The decision came down to control. When your data represents decades of creative and commercial IP, you think carefully about where it lives and who can learn from it. Disney has become more open to SaaS over time. The AI sovereignty question is a separate debate from the SaaS debate and conflating the two leads organizations to the wrong conclusions.

At the other end of the spectrum, enterprises in heavily regulated environments treat data sovereignty as an absolute non-negotiable. Any AI model must run within their controlled environment, especially where sensitive data cannot touch the public internet. GDPR obligations reinforce this instinct across the European market, requiring organizations to maintain clear accountability for how personal data is processed inside AI systems, including vendor-managed ones.

AI-enriched data, meaning models that have learned the shape of your business processes, your supplier negotiations, your customer behavior, carries a different half-life and a different strategic value than the operational data underneath it. That deserves its own architectural decision, separate from your broader cloud strategy.

What this means in practice

Most large enterprise estates will end up with a mix of all three approaches, and where you draw the lines matters more than your overall posture.

Embedded AI capabilities are the right answer for in-application productivity: the assistant inside your ERP workflows, the agent inside your procurement or HR suite. That is where vendor embedding genuinely shines, and attempting to compose your own equivalent is typically a poor use of engineering resources.

Compose belongs elsewhere: in cross-application orchestration, in custom assistants over operational and observability data, and in agents that need to reach across multiple vendor systems and infrastructure layers in ways no single vendor stack will never natively support. Research from McKinsey suggests the most significant near-term productivity gains from enterprise AI will come precisely from these cross-system workflows, rather than from within individual applications. The most interesting enterprise AI work over the next eighteen months lives here, and it doesn’t require waiting for a migration to complete first.

That compose path isn’t free, and it’s important to be honest about the costs. Governance, audit trails, and accountability for hallucinated outputs become your problem, not the vendor’s. Prompt drift and evaluation discipline are real engineering costs that never appear in the proof-of-concept. Those costs scale with the complexity of your landscape and the number of systems your agents touch. Budget for them before deployment, not after your first production incident. None of that is a reason to avoid the path. It’s a reason to staff for it, honestly.

The real question

The build-vs-buy frame survives because it gives executives a binary choice along a familiar axis. AI sits somewhere else entirely.

The question worth putting on the table at your next architecture review is simpler:

Which decisions do we want our vendors’ AI to make, and which do we want to keep on our side of the boundary?

Answer that, and the right build/buy/compose mix flows from it. Skip it, and you will end up with the architecture your vendors prefer – which may or may not be the one your business needs.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Can Meta really compete in the cloud business?

Fri, 17 Jul 2026 11:04:14 +0200

Meta is reportedly planning a cloud business that would sell access to AI computing power and models, extending its internal infrastructure into a commercial service for outside developers and enterprises. Reuters, citing Bloomberg’s reporting, noted that the planned offering would allow customers to access AI models hosted on Meta’s infrastructure and pay based on usage, effectively positioning the company in the infrastructure-as-a-service and AI platform markets. On the surface, this seems like a logical next step. If you are already spending enormous amounts of money to build AI infrastructure, there is a natural temptation to ask whether some of that investment can be monetized beyond your own internal use.

I have seen this pattern before. A company builds sophisticated internal systems, recognizes their value, and then begins to imagine that becoming a cloud provider is simply a matter of exposing those capabilities to external customers. It sounds straightforward, especially given the excitement around AI and the demand for high-performance infrastructure. But cloud computing is not just another distribution model. It is not simply a matter of offering on-demand multitenant services and charging a fee. It is a deeply operational, trust-based business in a market that punishes companies that do not fully understand what enterprise customers require.

A crowded neocloud market

The first problem Meta faces is that this is not an open opportunity. The neocloud space, meaning purpose-built AI infrastructure delivered as a service, is already crowded and increasingly difficult to enter. Amazon, Microsoft, and Google dominate the conversation for obvious reasons. They have years of cloud operating experience, broad service portfolios, global reach, mature ecosystems, and deeply established enterprise relationships. Oracle remains a serious player as well, especially in enterprise applications, data platforms, and performance-sensitive workloads. IBM still matters in hybrid cloud, operations, and industries where governance and regulatory rigor remain central.

That list alone should give Meta pause. These companies are not just infrastructure vendors. They are experienced cloud operators. They have spent years building not only the underlying platforms, but also the native capabilities enterprises now expect by default. Those capabilities include security, governance, identity management, observability, support, compliance, billing controls, resilience planning, and integration with the broader enterprise technology estate. These are not secondary features. They are part of the core value proposition.

This is why late entry into the cloud market is so hard. A new provider is not just competing on price or capacity. It is competing against accumulated trust. Enterprises are not casual buyers. They are selecting long-term operating environments for applications, data, AI models, and business-critical processes. They want confidence that the provider understands how these services will be consumed, governed, and supported over time. Meta is entering a market where the incumbents already have a major head start on all of those fronts.

Harder than it looks

Over the years, I have had many technology companies come to me and say they wanted to reposition their technology in the cloud space, either as software as a service or infrastructure as a service. In the beginning, enthusiasm is always high. The technology is impressive. The market size looks attractive. The revenue models appear compelling. Investors love the story. Then we begin to walk through what it really means to operate as a cloud provider, and the optimism usually fades fast.

The questions become very practical and very uncomfortable. How will tenants be isolated? How will identity and access controls work across different kinds of customers? What governance models will be built in natively? How will workloads be monitored, optimized, and secured? What does support look like 24 hours a day, across regions, across industries, across compliance boundaries? How will outages be handled, communicated, and remediated? How will the platform integrate with existing customer tools for operations, policy management, and security response? How much investment will it take just to become credible before you even begin to differentiate?

Once companies fully understand the complexities, market dynamics, and the capital and execution required to compete even with secondary players, many of them back off. They realize that cloud technology is not a packaging exercise. It is a transformation in how a company designs, operates, supports, sells, and evolves technology. That is why I remain skeptical when any company assumes it can translate internal infrastructure excellence into external cloud success without a very long, disciplined commitment.

Meta’s market readiness

Of course, Meta is not lacking in financial resources. If any company can afford to spend aggressively in this space, it is Meta. The company has the capital to build infrastructure, absorb losses, hire experienced talent, and stay in the market long enough to make a serious attempt. I would never argue that Meta is too small or too poor to try. Quite the opposite. If there is any non-traditional entrant with the financial scale to force itself into the conversation, Meta would be high on the list.

But money does not erase complexity. It only gives you the chance to confront it. The real question is not whether Meta can afford to become a cloud provider. The question is whether Meta has what it takes to become an excellent cloud provider. Those are two very different things. Enterprises are not going to move meaningful workloads to a new platform simply because the company behind it is wealthy or technically famous. They are going to ask whether the provider understands enterprise consumption patterns, enterprise risk, enterprise governance, and enterprise operations.

That is where the challenge becomes much more serious. Meta has extensive experience running infrastructure for itself. That is valuable, but internal operating excellence is not the same thing as external service maturity. Running systems for your own workloads allows a high degree of control over architecture, standards, priorities, and operating assumptions. Running systems for paying customers requires flexibility, consistency, transparency, and support across a wide range of use cases that you do not control. Those are very different disciplines, and companies often underestimate the gap between them.

What exactly is Meta?

Another concern here is strategic clarity. Meta already has a complicated market identity. It is a social media company, an advertising platform company, a hardware company, an AI company, and still, in the minds of many, the company that spent billions pursuing the metaverse. If it now wants to be viewed as a serious cloud infrastructure provider, it will need to explain not only what it is offering, but why customers should believe this is a durable long-term commitment and not just another adjacent experiment.

That uncertainty can be damaging. Customers want stable providers with clear strategic intent. They do not want to architect important systems around a platform if they suspect the provider may lose interest, shift direction, or reframe the business after a few years of uneven results. Cloud computing requires patience, consistency, and deep customer orientation. It is not a market where strategic ambiguity helps.

This could become confusing for Meta internally as well. Building a true cloud business demands focus. It demands years of investment in areas that may not be glamorous but are absolutely necessary, such as governance, operations, controls, support frameworks, partner programs, and enterprise sales alignment. If the company is not willing to make those sacrifices fully and for the long term, the initiative will struggle.

Observability statt Multi-Tool-Chaos - IT-Matchmaker News

Fri, 17 Jul 2026 10:54:52 +0200

Genau hier setzt USU an: Mit einer IT-Observability-Plattform können IT ... Security IT-Sicherheit KI Künstliche Intelligenz Machine Learning MES ...

The agent evaluation gap: Enterprise AI organizations have a reality-alignment problem, not a coverage problem — and most are shipping to production anyway

Thu, 16 Jul 2026 19:03:24 +0200

Methodology

Finding 1: A passing eval is not a working agent

Half have shipped an agent that passed evals, then failed a customer

Finding 2: Almost no one fully trusts automated evaluation

The top complaint: Evals don't match real-world outcomes

We asked which limitation most reduces trust in automated agent evaluations today. Only a sliver of enterprises had no complaint at all.

Finding 3: The autonomy ceiling is rising anyway

Two-thirds already allow, or are building toward, zero-human deployment

Finding 4: The evaluation stack is fragmented and provider-led

Provider-native evals lead — tied with no dedicated tool at all

We asked which agent reliability or evaluation platform enterprises primarily use today. The market has no clear leader — and a large share has nothing dedicated.

Finding 5: Production monitoring rarely watches output quality

Only a quarter run real-time quality checks on live traffic

Finding 6: Bought on cost, measured on consistency

Price and integration drive selection; evaluation consistency is the goal

We asked what most influenced enterprises’ choice of an evaluation vendor, and what they treat as their primary measure of success. Both answers are pragmatic.

Finding 7: The next dollar goes to humans and observability

Investment is flowing to oversight, not just automation

We asked which reliability and evaluation investment will grow most over the next year. The money is going toward watching agents more closely — including with people.

Finding 8: A tooling reshuffle is coming

Nearly two-thirds plan to adopt or switch platforms within a year

We asked whether enterprises plan to adopt a new, additional, or replacement evaluation platform, and which they are considering. Few intend to stand pat.

The bottom line: An evaluation gap that autonomy will widen, not close

Demystifying AI Exploits: A Blueprint for AI-Assisted Vulnerability Management

Thu, 16 Jul 2026 16:23:24 +0200

Written by: Jules Czarniak

Introduction

As highlighted in the Mandiant M-Trends 2026 report, the mean time-to-exploit (TTE) has dropped to -7 days, meaning vulnerabilities are often exploited a week before a patch even exists.

To keep pace, many security teams are exploring how to integrate large language model (LLM) agents into their codebases, development environments and continuous integration and continuous delivery (CI/CD) pipelines for automated vulnerability discovery and remediation. However, deploying privileged artificial intelligence (AI) agents without mature integration processes introduces new architectural risks.

In response to customer inquiries about how to safely integrate AI capabilities into vulnerability management workflows, this blog provides actionable guidance from Mandiant Consulting about how to establish operational guardrails for AI assisted vulnerability management, including several detailed scenarios. What each of these examples show is that security teams can accelerate workflows with AI while also upholding the structural integrity of their environments. We suggest that combining AI capabilities with deterministic controls and human intelligence in strategic ways maximizes benefits and reduces risk.

Establish Operational Guardrails to Safely Deploy AI Agents

To safely adopt advanced AI capabilities without introducing unpredictable failures into deployment pipelines, organizations should ground their approach in established industry standards. While guidelines like the NIST AI Risk Management Framework (RMF) and the OWASP Top 10 for LLMs provide comprehensive baselines for identifying risks, operationalizing these controls requires a structural blueprint.

Frameworks like Google’s Secure AI Framework (SAIF) and Google’s approach to secure AI Agents provide a practical path forward, demanding that organizations extend existing deterministic controls directly into the AI execution environment. When deploying AI agents, security teams should navigate specific operational and structural risks:

Pre-agent data security and Defense-in-Depth: Agents should not be able to access personally identifiable information (PII), protected health information (PHI), or other sensitive data. Organizations should enforce data security before the prompt reaches the model. This includes strictly using non-production environments populated with synthetic data for testing. For production, security teams should deploy a hybrid defense-in-depth model. This includes Layer 1 deterministic policy engines acting as chokepoints, alongside Layer 2 reasoning-based defenses like specialized guard models (such as Model Armor or similar provider-agnostic guardrails) to filter out sensitive data and block malicious prompt injections before they reach the agent layer. Crucially for vulnerability discovery, security teams should treat the codebase itself as an untrusted input. Threat actors can embed indirect prompt injections within source code comments or third-party dependencies (e.g., hidden instructions telling the agent to ignore vulnerabilities or exfiltrate environment variables), making input sanitation a requirement even for internal scanning.
Cloud provider limitations and zero data retention (ZDR): Many cloud and LLM providers block or throttle automated offensive security probing by default to prevent abuse. Organizations should establish clear rules of engagement and authorized testing agreements to navigate acceptable use policies. Furthermore, organizations should enforce strict zero data retention (ZDR) agreements with their LLM providers to guarantee that proprietary code and discovered vulnerabilities are never used to train external models.
Workload isolation: Agent workloads should execute in strictly isolated, unprivileged containers with dynamically limited privileges. By relying on robust sandboxing to prevent privilege escalation, if an agent hallucinates a destructive command or is hijacked via prompt injection, the blast radius remains contained.
Red Teaming: Before deploying autonomous vulnerability scanners that can dynamically spin up sandboxes and execute code, organizations should subject the AI agents themselves to human-led red teaming as part of comprehensive assurance efforts. This validates the agent's resilience against jailbreaks, recursive logic loops, and complex prompt injections, ensuring the security tooling does not become the attack vector.
Least-Privileged Machine Identities and Human Controllers: While workloads should be isolated, agents inherently require privileges to generate pull requests and commit code. Security teams should ensure these agents operate under distinct, strictly scoped machine identities that tie back to human controllers to ensure accountability and user consent. Organizations should use short-lived, just-in-time (JIT) tokens bound exclusively to the specific repository and branch under review. This enforces the principle of limited agent powers and ensures that even if an agent’s container is compromised via prompt injection, the threat actor cannot pivot to modify adjacent enterprise codebases.
Supply chain resilience for skills: As developers augment AI with third-party skills and model context protocol (MCP) servers, security teams should treat these integrations as untrusted supply chain components. MCP plugins introduce the risk of supply chain poisoning, where a previously benign integration is silently updated with malicious dependencies. Additionally, security teams should evaluate the underlying agent orchestration frameworks themselves (e.g., LangChain, AutoGen) for inherent vulnerabilities, such as session memory poisoning or recursive loop hijacking.
Toxic flow analysis (TFA) and Observable Actions: The objective of TFA is to monitor data paths at runtime, ensuring agents do not exfiltrate sensitive internal context to unvetted external endpoints. Agent actions, inputs, reasoning, and outputs must be fully observable and transparently logged. While implementing dynamic taint tracking for LLMs remains a complex architectural challenge, organizations should clearly separate this runtime observability from static supply chain controls. Integrating threat intelligence to hash and vet incoming agent tools provides a necessary baseline for verifying integrity before deployment. However, because static controls cannot address behavior post-deployment, mitigating data exfiltration ultimately requires active runtime monitoring and secure, centralized logging to trace and restrict the actual flow of data.

Figure 1: Visual representation of an isolated AI agent environment using SAIF mechanisms

By operationalizing these tools within frameworks that demand verifiable integrity and structural resilience, organizations can safely bridge the gap between AI velocity and enterprise defense.

The need for human-led threat modeling

While LLMs excel at identifying syntax patterns, source code itself rarely contains the full picture of unwritten business intent. Some organizations attempt to solve this by connecting LLM agents to internal wikis, design documents, and issue trackers using retrieval-augmented generation (RAG).

While RAG gives the model access to external business context, it is not a perfect fix. Corporate documentation is frequently stale, contradictory, or incomplete. An AI agent might retrieve an outdated architecture diagram and confidently hallucinate a secure path that no longer exists in production. Because LLM agents struggle to resolve conflicting, undocumented human assumptions, human-led threat modeling remains a critical security control across both legacy applications and modern agent workflows.

Security teams should apply threat modeling during both the pre-build system design phase to establish a secure foundation, and during post-build architecture reviews. While an AI agent might successfully identify a poorly configured internal endpoint locally, a human threat modeler asks the structural question: why does that microservice possess broad database read permissions in the first place?

Identifying architectural vulnerabilities requires reasoning about business risk, data sensitivity, and operational constraints. To structure this process, organizations can use industry frameworks like PASTA (Process for Attack Simulation and Threat Analysis) or service offerings like the Mandiant Threat Modeling Security Service to map trust boundaries, uncover structural design flaws, and prioritize compensating controls. Securing fundamental architecture through human oversight is a necessary component when relying on automated agents to find bugs in a poorly designed system.

Once these AI agents are safely sandboxed, as guided by SAIF, and the architecture is verified through threat modeling, organizations can typically apply them to two different problem spaces: Enterprise Vulnerability Management (to assist in managing the volume of known CVEs in commercial off-the-shelf (COTS) software and infrastructure) and Product Security (to identify vulnerabilities in 1st-party (1P) code).

Track 1: Enterprise Vulnerability Management

Foundational security and discovery

While the second track of this post explores how AI agents can uncover complex zero-days in custom code, organizations should manage the scale of enterprise infrastructure in tandem with these AI deployments. Even as new AI capabilities dominate headlines, organizations should still address foundational security challenges, such as secrets sprawl, unmanaged service accounts, missing FIDO2 MFA, and legacy VPN concentrators. Although vulnerability exploitation was the primary initial infection vector in intrusions Mandiant investigated last year, threat actors consistently rely on missing foundational controls and unpatched edge devices to secure and escalate their foothold after exploiting a vulnerability.

Furthermore, AI cannot replace foundational visibility. As security teams deploy AI agents, they should simultaneously close these tactical entry points by maximizing dynamic discovery capabilities like External Attack Surface Management (EASM), Cloud Security Posture Management (CSPM), and Continuous Threat Exposure Management (CTEM). In hybrid and cloud environments, tools like Wiz can be used to map this initial footprint.

Risk-based vulnerability management

Vulnerability management teams are already overwhelmed by the current volume of findings generated by traditional scanners. As organizations scale dynamic discovery tools, such as EASM, CSPM and CTEM, alongside automated AI agents, this influx of findings will compound the problem. To manage this influx, telemetry from these diverse discovery methods must first be normalized and deduplicated. This normalized data serves two purposes: it feeds directly into the risk engine, and it acts as a live overlay to correct stale records in the configuration management database (CMDB). By evaluating the deduplicated vulnerabilities alongside this newly updated asset context and frontline threat intelligence, the RBVM engine calculates a custom risk score that allows security teams to dynamically prioritize remediation.

A mature RBVM methodology calculates a customized risk score on a 0 to 100 scale using a weighted average. A sample formula for calculating this risk-based score is:

Final Score = (W_1 * S_vuln) + (W_2 * S_asset) + (W_3 * S_threat)

The variables and weights (W) are customized to the organization's risk appetite (for example, 0.20 for vulnerability, 0.40 for asset, and 0.40 for threat, summing to 1.0), while the underlying variables (S) are scored on a 0 to 100 scale and defined as follows:

Vulnerability severity (S_vuln): The inherent technical severity of the flaw. This is calculated by taking the CVSS Base Score (which natively accounts for confidentiality, integrity, and availability impact) and multiplying it by 10.
Asset context (S_asset): A combined metric of exposure and data sensitivity. Scores range from 100 for internet-facing assets holding customer data, down to 25 for internal-only assets with no sensitive data. To translate this impact into monetary terms for non-technical stakeholders, organizations can incorporate Factor Analysis of Information Risk (FAIR) principles into this metric. However, this approach requires highly accurate, continuously updated financial data that many enterprises struggle to maintain at scale.
Threat context (S_threat): The real-world urgency of the vulnerability. Scores range from 100 if actively exploited by threat actors relevant to the organization's profile, 75 if a proof-of-concept exists or if it is a vulnerability class easily exploited by autonomous AI agents, down to 25 if the exploit is theoretical and highly complex. Organizations should also map the Exploit Prediction Scoring System (EPSS) probability percentage directly into this variable. This allows the threat score to automatically scale up or down as real-world exploitation telemetry shifts, aligning static vulnerability data with active threat intelligence.

An asset's customized risk score should directly influence internal remediation service-level agreements (SLAs), unless external compliance-driven mandates, such as CISA Binding Operational Directives (BODs), or relevant equivalents, override internal prioritization. A risk-driven and threat-intelligence-driven vulnerability prioritization methodology will help organizations focus resources on managing and mitigating the most critical security vulnerabilities first. This is an area where LLMs can support the vulnerability management process, particularly by helping teams synthesize unstructured threat intelligence to surface relevant risk contexts more efficiently. Enforcing strict SLOs for patching, while requiring formal risk acceptance documentation for any patching exceptions, will help reduce the number of vulnerabilities available to threat actors and increase the visibility of outstanding risks across the organization. Furthermore, organizations should integrate RBVM data directly into their security orchestration, automation, and response (SOAR) platforms for automated alert enrichment.

Figure 2: Integration points of a risk-based vulnerability management (RBVM) program.

Containment and Observability

Modern architecture blueprints must prioritize attack surface reduction under the assumption that vulnerabilities will inevitably be exploited. Moving away from traditional perimeter defenses, organizations should align with zero trust principles, ensuring that security boundaries are established around every asset, workload, and identity.

A component of this alignment is the implementation of strong authentication principles. Organizations should eliminate implicit trust by enforcing continuous, context-aware authentication and authorization. Utilizing Zero Trust Network Access (ZTNA) solutions, such as Identity-Aware Proxies (IAP), shields critical management interfaces (e.g., SSH, RDP) and internal systems from direct internet exposure, granting access only to verified identities and compliant devices.

For public-facing applications and APIs, attack surface reduction involves deploying Layer 7 inspection at the load balancer or API gateway level. This hardening layer enforces strict schema validation, intercepting and neutralizing malformed inbound traffic and potential exploits before they can interact with internal application logic.

Securing the software supply chain is equally vital in modern blueprints, and organizations should align with frameworks like Supply-chain Levels for Software Artifacts (SLSA) across both dependency and build tracks. Security policies should mandate that third-party dependencies are routed through a centralized artifact repository equipped with automated curation services, such as Google Assured Open Source Software (OSS) or an equivalent solution, preventing untrusted code from entering the development lifecycle. Furthermore, maturing toward advanced SLSA build levels (e.g., SLSA level 3) through the implementation of isolation, ephemerality and reproducibility requirements via ephemeral compute infrastructure for CI/CD runners reduces the likelihood of attacker persistence by ensuring environments are short-lived and automatically cycled.

To complement these pre-build controls, runtime observability should be established across all production workloads. This requires monitoring both infrastructure-level behavior and the specific runtime libraries actively executing in production, which surfaces true exploitable risk far beyond a static Software Bill of Materials. In tandem with monitoring workloads, organizations should secure how they authenticate by implementing workload identity federation. By removing static credentials and instead using short-lived tokens backed by strong cryptographic identity verification, organizations can reduce the risk of credential theft and unauthorized lateral movement.

Within the internal environment, microsegmentation should be enforced to break down flat networks into granular security zones. Routing application traffic through a Secure Access Service Edge (SASE) architecture integrates network routing directly with robust identity controls, rendering internal services completely invisible to unauthenticated users and containing threats to their initial point of entry.

Finally, automated containment and incident response within a zero trust framework must rely on deterministic, auditable tooling. Endpoint detection and response (EDR) platforms and SOAR playbooks should handle high-fidelity containment tasks through hardcoded execution logic. While AI tools accelerate triage and policy recommendation, actual execution capabilities must remain restricted to well-defined, pre-tested workflows to maintain total architectural predictability.

Figure 3: Structural containment and observability architecture

Track 2: Product Security & Development (1P Code)

Deterministic and probabilistic tooling

Integrating LLM agents into vulnerability management and security workflows requires recognizing the differences between deterministic and probabilistic tooling. Traditional SAST and DAST tools utilize fixed methodologies to evaluate vulnerabilities through structural code parsing or definitive runtime observations. LLMs, however, evaluate source code by processing tokens simultaneously to calculate statistical and semantic relationships, rather than tracing deterministic execution tracks.

While techniques like Chain of Thought (CoT) prompting allow models to bridge this gap by decomposing complex code paths into intermediate reasoning steps, this process remains bounded by architectural limitations. Even when a model possesses a context window large enough to ingest entire repositories, it may experience attention degradation across long inputs, often failing to correctly weight intervening validation or sanitization logic within the prompt. For example, if a variable is tainted on line 10 but sanitized on line 500, attention degradation can cause the model to lose track of the sanitization logic. Furthermore, when enterprise codebases require chunking to fit within context limits, the resulting fragmentation may cause the model to lose track of end-to-end data flows.

Consequently, probabilistic engines are effective at uncovering localized, static anomalies, such as hardcoded credentials or outdated dependencies, but frequently misjudge complex vulnerabilities split across fragmented chunks or extended context windows. Notable exceptions occur when these probabilistic models are coupled with deterministic feedback loops. For instance, when analyzing C++ memory corruption, an LLM can be equipped with a test harness to iteratively execute code and definitively prove a crash. While these dynamic validation applications are detailed in subsequent sections, the baseline limitation for static analysis across standard enterprise codebases remains: models struggle to consistently evaluate dispersed logic.

Figure 4: Deterministic SAST scanners vs. probabilistic LLMs

Binary and architectural oracles

Many security programs are moving toward agent workflows where an agent autonomously spins up a test environment and uses tools to execute payloads and verify its findings. This is a promising approach, but it is important to understand where it is most effective.

Agent workflows perform well against bug classes with binary and observable oracles, meaning the system provides an objective, 'crash or no crash' feedback loop. For example, if a model is hunting for memory corruption in a C++ kernel, a successful exploit is undeniable: the payload executes, and a resulting crash definitively proves the vulnerability. This explains why the industry is currently seeing a surge in AI-discovered vulnerabilities across memory-unsafe targets like web browsers and operating systems.

However, enterprise software is heavily dominated by vulnerabilities that require architectural oracles for validation. Vulnerabilities like authorization bypasses, complex business logic flaws, and indirect server-side request forgeries require an understanding of business context and cross-service trust boundaries. If an agent's payload fails to produce a clear outcome, it can't reliably distinguish whether the vulnerability is a hallucination or if it simply constructed the payload incorrectly. An agent's malformed payload might even crash an unrelated background process and cause the model to hallucinate a success and report a false confirmation. Complex enterprise architecture contains unwritten business intent that a probabilistic engine can't inherently know.

Figure 5: Evaluating vulnerabilities against binary vs. architectural oracles

Targeted deployment and human impact

Organizations adopting LLMs for vulnerability discovery face a massive staffing challenge. LLMs can generate findings significantly faster than human engineers can triage them. If every LLM-generated alert requires manual review, security teams will quickly face burnout and/or suffer alarm fatigue.

Rather than indiscriminately pointing agents at all available codebases and risking an influx of unverified output, security teams need a selective deployment strategy. Mature programs should maintain SAST and DAST for baseline hygiene and deterministic rule enforcement, and reserve intensive agent audits for high-impact components with clear binary oracles.

Organizations can prioritize agent audits on systems where the technology's strengths align with the broader risk profile:

Memory-unsafe codebases: Legacy or high-performance components written in memory-unsafe languages such as C, C++, or Assembly are strong candidates for LLM audits. These languages are susceptible to memory corruption flaws, such as buffer overflows and use-after-free conditions. Because these vulnerabilities trigger definitive failure states like segmentation faults, they work well with automated sandboxes where agents can compile the code with memory sanitizers and write proof-of-concept inputs. This approach is also effective for auditing the native extensions where safe languages call unsafe internal libraries, such as Python C extensions or the Java Native Interface (JNI).
Systems highly exposed to outside content: First-party data ingestion pipelines, custom API gateways, or proprietary edge proxies. A prerequisite here is direct access to the source code, this strategy is strictly for internally developed or fully open-source codebases where the organization can inspect the logic. Because these systems directly parse untrusted internet traffic, targeting their source code for LLM-driven audits yields the highest risk-reduction ROI.
Shared internal libraries and utilities: Core serialization/deserialization packages, common utility functions, and custom middleware wrappers (such as internal message-queue parsers) maintained in-house. Because the enterprise owns the source code for these shared building blocks, agent tools can easily hook into them within automated test harnesses to fuzz inputs and catch low-level logic or parsing bugs with high fidelity.
Foundational security boundaries: Internally developed centralized authentication services, custom OAuth providers, and internal credential brokers. While testing complex identity boundaries generates higher logic-based noise, having full access to the source code allows teams to pair agents with deterministic checks to safely triage findings, given that the blast radius of an authentication failure justifies the human effort.

To filter the noise generated by LLMs, organizations should establish routing rules. Require the agent to generate a fully reproducible, deterministic test harness (such as a compiled binary or a Python test script) that attempts to prove the exploit. This harness must execute automatically in an isolated, monitored sandbox. If the sandbox execution fails (due to a syntax error or a failed exploit), the ticket is discarded, sparing human resources. However, organizations should enforce execution timeouts and iteration limits on these test harnesses. Without hard limits, an autonomous agent attempting to prove a vulnerability can fall into an infinite loop: writing a script, failing, rewriting, and failing again, exhausting API token budgets and compute resources against a single dead-end vulnerability, creating significant cost overruns without advancing the security review. To manage these expenses, organizations should incorporate FinOps principles to balance the compute and API costs of LLM audits against the traditional expenses of manual triage.

However, a successful execution in the sandbox does not guarantee an actionable, high-priority risk. In practice, autonomous agents frequently produce working PoCs for genuine technical flaws that are ultimately irrelevant; or warrant a lower remediation priority within the context of the system's threat model. For example, the agent might successfully exploit an unreachable dead-code path, or trigger a bug that requires administrative access to execute and yields no further escalation of privilege. Therefore, a human engineer should be assigned to review and prioritize the ticket only if the sandbox registers a successful execution, validating environmental context, reachability, and true business impact as part of the review.

This workflow reduces the volume of alerts, but it is important to understand that the security team's workload does not disappear. The engineer's primary job shifts from manually hunting for the initial vulnerability to auditing the LLM-generated proof to ensure it represents a meaningful risk rather than an unexploitable or contextually irrelevant finding. Leadership should properly staff and train teams for this new reality. Deploying LLM agents does not remove the need for skilled practitioners; it redirects their workload toward complex validation. Equally important is training teams to recognize the risk of false negatives. A hyper-focus on filtering AI-generated noise can create a false sense of security. If an exploit relies on a novel technique or a zero-day vulnerability that was not heavily weighted in the model's training data, the agent will likely scan right past it in silence. LLMs augment discovery, but they do not guarantee exhaustive coverage.

When integrating LLMs into SAST triage pipelines, human engineers should also verify the broader architectural integrity. Prompting an LLM with specific SAST warnings can induce contextual narrowing, where the agent becomes hyper-fixated on resolving a localized syntax error and misses broader architectural flaws existing in the same file. Furthermore, if the agent's mandate extends beyond discovery to automated remediation (such as writing and proposing code fixes), this human-in-the-loop validation becomes critical to ensure the LLM does not inadvertently introduce new regressions or bypass intended business logic.

Figure 6: Flowchart outlining the targeted LLM deployment and triage workflow.

Remediation and hardening

LLM-assisted code remediation

A primary goal of integrating large language models (LLMs) into the software development lifecycle is automated remediation. To achieve this, organizations are deploying these capabilities through two primary execution methods: directly within the integrated development environment (IDE) or as a centralized pipeline runner. Examples include CodeMender, although as of time of writing, it is not publicly available.

IDE-integrated method

This method shifts remediation as far left as possible by operating as an active pair-programmer. Tools running continuous static analysis in the background of the IDE surface vulnerabilities directly to the developer via editor diagnostics like inline indicators or hover tooltips.

Localized scope: The developer can trigger the LLM agent to analyze the localized data flow and generate a targeted patch (such as implementing parameterized SQL queries). By constraining the LLM to localized, syntax-level fixes, the scope of the change remains contained. This prevents the agent from attempting sprawling, multi-file refactors that frequently break complex architectural logic.
Human-in-the-loop: The developer reviews the AI-generated patch before the code is committed.
Managing false positives: Local IDE agents allow developers to manage false positives dynamically. Suppressing alerts anchored to specific line text reduces alert fatigue and preserves developer trust.

CI/CD runner method

The runner method executes asynchronously within the CI/CD pipeline to use an LLM to review committed code and automatically propose remediation.

Restricted execution and deterministic validation: Asking a centralized runner to automatically rewrite a complex, multi-file authorization flaw directly in the main branch introduces a high risk of breaking logic errors. To mitigate this, agents must be restricted to generating pull requests (PRs). Once a PR is generated, it must automatically execute standard regression suites alongside the deterministic test harness. By rerunning the initial PoC against the patched code, the workflow repurposes the exploit script as a validation oracle to prove the vulnerability has been remediated. A human engineer then reviews the PR to validate the architectural logic before merging.

In all cases security teams should define a clear boundary between the two methods rather than rely on a single approach. IDE agents provide immediate, syntax-level support. They catch and resolve low-complexity errors locally before developers commit code. Centralized CI/CD runners handle broader organizational baselines. They propose complex, repository-wide fixes for vulnerabilities that bypass local environments.

Post-deployment controls

Even with human review and deterministic test harnesses, AI-generated patches can still introduce logic regressions in production. Organizations should implement strict post-deployment controls:

Automated rollbacks: Treating LLM-generated code with the same post-deployment scrutiny as any major architectural change ensures that if an unforeseen regression traverses the CI/CD pipeline, the environment can revert to a known good state.
Mitigating model drift: Relying on managed AI services introduces the ongoing risk of model drift. To prevent silent weight updates from breaking test harnesses, organizations need to pin specific model API versions to frozen releases. When a pinned version reaches its end-of-life, organizations will face a forced migration. Mitigating this pipeline fragility requires combining model pinning with deterministic regression suites.
Compliance and auditability: If an AI agent automatically closes a security ticket or generates a patch in the CI/CD pipeline, organizations should maintain immutable audit logs to satisfy frameworks like SOC 2 ,PCI-DSS, FedRAMP, and CMMC. National security deployments must also account for data sovereignty requirements. This logging should record the specific model version that proposed the fix, the deterministic test results that validated it, and the human engineer who approved the merge. Furthermore, because emerging legislation like the EU AI Act emphasizes human oversight for high-risk applications, security teams should carefully evaluate how autonomous remediation workflows align with these evolving global regulatory standards.

Figure 7: Flowchart demonstrating the difference between local IDE AI remediation and centralized CI/CD pipeline remediation.

Conclusion

Leveraging LLMs in vulnerability management is a multi-layer solution: Integrating it requires separating workflows by layer. At the enterprise infrastructure level, Risk-Based Vulnerability Management (RBVM) and exposure management are necessary to process the volume of findings and configuration drift. At the product and code security level, LLM-enabled vulnerability assessment and remediation must operate alongside foundational deterministic controls, such as SAST and DAST, to audit custom, open-source, or third-party code.

Although LLMs can help manage technical debt and accelerate vulnerability discovery, they do not replace secure-by-design principles. The fact that LLM agents are proving exceptionally capable at identifying and exploiting localized memory corruption in memory-unsafe codebases, alongside other primary vectors, should serve as a wake-up call.

As a long-term strategy aligned with NSA guidance on Software Memory Safety, organizations need to phase memory-safe languages into new internal development. LLMs are beginning to expand what is possible here by reducing the manual labor required for code migration. Converting existing C or C++ codebases to Rust has historically been unrealistic due to the large volume of engineering hours needed. While fully automated translation is not a turn-key solution, using LLMs to assist engineers with the bulk of the conversion can make these long-term migrations operationally viable. Beyond internal efforts, organizations should use procurement requirements to incentivize vendors to reduce their reliance on memory-unsafe languages and establish secure configuration defaults over time. Bridging the gap between AI velocity and enterprise defense means building an automated pipeline to manage the current backlog, while architecting systems where entire classes of vulnerabilities and misconfigurations are eliminated by design.

Acknowledgements

This analysis would not have been possible without the assistance of Google Threat Intelligence Group (GTIG) and other broader Google teams.

19 AgentOps tools for monitoring AI activity, issues, and costs

Thu, 16 Jul 2026 12:09:36 +0200

With AI increasingly tucked into every cranny of the enterprise, someone has had to step up and provide the tools necessary to discover, track, and monitor all the agents and LLMs and keep them humming along in their various workflows. Thankfully, the DevOps world answered the call, building the tools to support our new overlords in an emerging subdiscipline interchangeably called “AIOps,” “AgentOps,” and sometimes “agent observability.”

Many of the challenges involved in AgentOps are similar to those tackled by traditional DevOps tools and processes. After all, at their foundation, LLMs are just software running on hardware somewhere. Typical issues involving RAM and disk space are just as important in the agent world, maybe more so because AI operations are even more greedy about consuming storage than regular software is.

Many of the companies supporting agent observability are big names in DevOps circles, having adapted their stacks to address the idiosyncrasies of modern LLMs. IT teams maintaining enterprise agents can treat the LLMs as just one node in a big graph filled with services that are constantly swapping packets and triggering software jobs. Latency and resource constraints must be managed because end-users don’t care whether it’s an LLM, a database, or a plain-old Python script that’s failing, bringing their work to a grinding halt.

But new AI-specific challenges are opening the door to newcomers that are building tools with the peculiarities of LLMs in mind — for example, keeping deeper logs filled with records of prompts. LLMs are also often very non-deterministic by design, making it trickier to pinpoint failure modes. And then there’s the fact that an agent will give a perfectly intelligent answer one minute and hallucinate the next.

Relying on many of the same approaches that DevOps tools do, AgentOps tools watch for misbehavior and flag anything out of the ordinary for deeper analysis. This may be as simple as fixing slow responses, but it can also include AI hallucinations and other issues born of LLMs’ non-determanism.

Teams trying to choose which agent observability tools is best for their use case should look at the size and nature of their agentic systems and projects. Are they adding AI agent features to an existing product or application, or are they building agentic systems from scratch? Are they more focused on maintaining a stable LLM operation or iterating on new approaches? Is AI the center of attention or just an add-on that’s meant to improve an existing stack?

The AgentOps and agent observability options listed below share many of the same features but differ in their focus and their attention to the challenges organizations will encounter when incorporating agents into their stacks. Each tool offers a worthwhile place to start understanding how to care for the growing presence of AI in the production world.

AgentOps.ai

When teams of agents work together, tracking the conversations are essential for understanding and debugging what’s happening. The SDK from AgentOps.ai records events so that the creators can replay past behavior to track details such as token counts, spending, latency, and more. Available as a service and on-premises.

Pricing: Starts at $40 per month plus usage costs at $0.20 per 1M tokens

Standout feature: Replay analytics with “time-travel debugging”

Best suited for: Complex agent debugging

Arize Phoenix

Debugging prompts and LLM responses requires a nuanced understanding of just what’s happening, in part because of the non-determinism that often enters the process. Phoenix from Arize supports this process with robust tracing and the ability to score the results for more precise iteration. Their system can track the results and tool calls from a variety of major platforms (Anthropic, AWS, OpenAI, etc.) that are initiated by the major frameworks (LangChain, LlamaIndex, DSPy, etc.). The result is insight into what data is triggering what chain of responses.

Pricing: Small free tier; Pro plan starts at $50 per month plus costs tied to events

Standout feature: LLM-as-a-Judge metrics for tracking quality

Best suited for: Teams focusing on iterating for accuracy and quality

BigPanda

BigPanda has always offered solutions for tracking performance of complex systems. Now the company is drilling deeper into the challenge of detecting and ending the problems that come from models that go awry. BigPanda’s main system relies on historical data and machine learning algorithms to flag issues. Its own agent layer connects the problematic nodes and errant models while dispatching alerts to the right team members.

Pricing: “Value-based” table on request

Standout feature: Automated triage for faster response

Best suited for: Large teams seeking to reduce alert fatigue from large customer base

Braintrust

Setting up an effective improvement cycle for an AI agent requires a strong feedback loop from production data to the agent’s next generation. Braintrust watches the production workload and creates test vectors that expose how an agent may be drifting, regressing, or departing from its path. The tool automates much of the testing and scoring feedback loop so problematic patterns can be discovered and addressed. A core part of the offering is a specialized data store that can track large and sometimes deeply nested collections of tests and their results. Their approach may be summarized by one of their tag lines: “trace everything.”

Pricing: Free starter tier; Pro plan starts at $249 with some usage-based costs covered

Standout feature: Highly scalable trace ingestion

Best for: Teams developing strong guardrails through continuous testing

Chronicle Labs

When it’s time to release a new version of an agent into the wild, the platform from Chronicle Labs specializes in staging it and testing it with a collection of use tests and regression cases. The tools are also helpful during development cycles. “Backtest your agent against reality,” their sales material promises, with a set of tools that mines the production telemetry for solid test vectors that stress every part of the agent with prompts and challenges that the agent will encounter after leaving the safety of the lab.

Pricing: On request

Standout feature: Back-testing options for complex testing regimes

Best for: Teams chasing strong models with good fidelity to reality

Comet Opik

Building a dashboard for tracking every in-flow and out-flow to agents is one way to be ready to watch for and solve problems. Opik from Comet is just such a tool. The DevOps teams can track each call and add its own automated routines to examine the results, score them based on 30-plus metrics, and if desired, send it off to another LLM to evaluate the results. Agents that are constantly failing stand out. DevOps teams can also ask questions like, “Who is using this model and racking up all of the bills?” The same goes for MCP skills and other cogs in the machine.

Pricing: Free tiers for open source and small projects; Pro plan starts at $19 per month with usage limits

Standout feature: Auto-scoring with 30-plus metrics for evaluating traces

Best for: Teams focusing on RAG and agentic workflows

Datadog

DevOps teams that rely on Datadog to track logs across collections of services can also use it to track LLM operations, which are, of course, just another source and sink for data. It will track performance such as time to first token and offer insight into what might be causing an issue, such as lack of memory. Results then get plugged into the same cost-tracking mechanism so the bean counters can predict when the budget will run out. After all, the CFO likely doesn’t care whether the bill comes from an LLM or an old-school S3 storage bucket. Datadog integrates AI into their tools by treating these models as just another source of data.

Pricing: Small free tier with multiple paid tiers for various levels of enterprise monitoring

Standout feature: Large installed base with broad focus on more than LLMs

Best for: Large enterprise teams working with established infrastructure

Dynatrace

For more than 20 years, Dynatrace has been delivering tools that track dataflows across the full stack. Now that AIs are finding roles in many of the nodes in this complex graph, they’re expanding to track how various AI agents can interact. They want to build one platform that helps track the root cause and, often now, deploy solutions autonomously. They want to focus on being ready to support complex networks of agents that detect problems in either performance or security and then work within defined guardrails to fix them. Determining the right role for their own AI-powered agents is a key part of the product.

Pricing: Plans start at $7 per month with larger plans designed for full enterprise monitoring

Standout feature: High level of autonomous monitoring designed for large installations

Best for: Complex, hybrid environments mixing LLMs with traditional services

Galileo

Placing some AI systems into production is often a harrowing experience because the actual performance is impossible to predict, even with the most rigorous tests. Galileo offers guardrails that track performance and watch for any behavior that deviates from the ground truth. Their “LLM-as-judge” systems are distilled into compact models that can be run locally for lower costs and faster performance.

Pricing: Small free tier; Pro plans start at $50 per month with usage-based limits and costs

Standout feature: Real-time guardrails for deployed agents

Best for: Security-conscious installations that need to defend against hallucination and data leakage

Grafana Labs

Long the go-to source for open source telemetry, Grafana Labs now tracks performance of AI models in constellations of services. Grafana tracks the evolution of answers across the agentic network to recognize how small changes or hallucinations can spin out of control. It bills its system as “actually useful AI” and has even trademarked it. Its cloud assistant can configure and reconfigure the Grafana dash to offer the right level of observability. Its system includes AI-level analysis that can flag models that are responding quickly but offering bad answers because of problems such as model drift or context degradation.

Pricing: Basic free tier; Pro plan begins at $19 per month, includes better retention and some usage-based fees

Standout feature: Full-stack tool with fully integrated LLM tools

Best for: Large, enterprise-scale system adding AI

Helicone

Sometimes shoehorning in another tool into the chain can be tricky. Helicone is designed as a smart network proxy that will route all model requests while keeping solid debugging records from the data as it goes by. The data it captures can be turned into nice charts that make it easy to spot latency issues or model failures. Naturally, tracking AI spend is also a feature in much demand as bills continue to climb.

Pricing: Small free tier; Pro plan starts at $79 per month, includes features such as team collaboration and improved querying

Standout feature: Proxy-based integration

Best for: Development teams who want to add better monitoring features quickly

Laminar

Tracking agents in development and production means building strong storehouses of data enumerating what happened. Laminar works closely with OpenTelemetry to follow agents operating in production so that flaws and failure modes can be understood from log files stored efficiently with their own compression scheme. Developers can search through traces with an SQL-ish language and Laminar’s transcript view illuminates what happened. When necessary, the traces can enable developers to scroll back in time and replay the same inputs for debugging. The goal is to offer deep insights with high-level visibility of how well the agents are meeting business objectives.

Pricing: Small free tier; “Hobby” tier that adds more features at $30; Pro level starts at $150 per month

Standout feature: Open-source license makes self-hosting a viable option

Best for: Teams fully able to leverage open-source responsibilities

LangChain LangSmith

Real-time data from agents is essential for managing any mutli-agent system in production. LangSmith from LangChain traces costs, tools, and progress toward solutions for a wide collection of agents using SDKs for Python, TypeScript, Go, and Java. The OpenTelemetry-based solution watches for anomalies, issuing warnings and alerts through dashboards and communication channels such as PagerDuty. Deeper analysis can reveal issues such as topic clustering or odd patterns of failure. Coordination with agent deployment platforms such as LangGraph and deepagents ensures greater focus on successful resolution of assignments.

Pricing: Free for solo developers; Pro teams start at $39 per person per month

Standout feature: Systematic approach to regression testing of prompts

Best for: Teams relying on LangChain and LangGraph frameworks for supporting complex agentic behavior

Lunary

Watching the user experience is essential for building AI applications such as chatbots and assistants. Lunary offers a proxy that traces all interactions and then builds analytical dashboards for measuring metrics such as user satisfaction or model costs. One common usage is finding frequent topics and looking at the responses to ensure they deliver. When prompts aren’t perfect, Lunary lets teams iterate on the prompt text until the right answers are coming out. Its proxy structure and common API format enables Lunary to promise to work with “any LLM, any framework.”

Pricing: Free tier; Pro plan starts at $20 per month

Standout feature: Deep integration with humans for reviewing and optimizing results

Best for: Startups focused on rapid prompt innovation

NewRelic

The platform that began tracking performance of some web applications is now powerful enough to track the flows of data through complex agentic ecologies. NewRelic’s AI-driven monitoring watches for golden signals that can indicate misbehavior or worse throughout the entire lifecycle. It tracks every detail of the interactions through protocols such as MCP and then makes this available to the AI engineers responsible for performance. The dashboard provides the insights necessary to watch for toxic behavior, overt bias, drift, and overblown hallucinations. Predicting and maybe even controlling the cost is also a growing role as tokenomics becomes as important as response time.

Pricing: Free tier; Pro plan fees available through website

Standout feature: Full-stack support with hundreds of integrations with other tools

Best for: Established enterprise teams mixing in AI

Nova AI Ops

The goal of Nova AI Ops is to deliver a team of agents that watch over a cloud and make it, at least partially, self-healing. Each agent uses a mixture of predictive AI and machine learning to watch cloud telemetry reports for anomalies. Then they calculate the “blast radius” and decide whether this is a problem that can be fixed automatically “while you sleep” or saved for the human supervisors. These tools are aimed not just on LLM operations but on the stack as a whole.

Pricing: Small free tier; Standard pricing begins at $40 per user per month with usage billing

Standout feature: Focus on software reliability engineering helps teams deliver stable stacks

Best for: Teams that want to integrate LLMs into incident response and stability management

Splunk

The platform that began delivering smart logging is now fully AI capable, offering solutions that can watch over agents with much the same way that it continues to track microservices. Splunk now includes a fairly large amount of predictive AI for learning from the information in the logs and then turning this learning into fast solutions. This AI assistant can track deployed AI models connected by protocols such as MCP and watch over behavior while delivering the ability for users to drill down and explore what’s working and what’s failing. Their AI Canvas is meant to offer a central hub where the AI scientists can track both the local behavior of the models as well as their role in a larger data ecosystem.

Pricing: Activity-based pricing tracks usage of LLM backends and storage

Standout feature: Ready to scale to large enterprise stacks

Best for: Teams with legacy systems that are folding in agentic options

SuperPenguin

One of the most important parts of an AI service is the bill. SuperPenguin is a product designed to track consumption and make predictions so that the CFO won’t be surprised. The goal is to provide solid estimates about the total cost of each product by allocating costs to customers, features, and teams. If there’s a sudden shift, a “spike detector” will raise an alarm so that dev teams can ensure that the AI spend is worth it.

Pricing: Small free tier for experimentation; Growth tier for teams, starting at $30 per month; Pro tier offers deeper options starting at $200 per month

Standout feature: Strong accounting with invoice reconciliation and PR-level usage tracking

Best for: Teams that need precise cost accounting

Vellum

Prompt engineers spend time fussing over the details of tweaking, improving, and enhancing the words that guide the LLM. Vellum started as a company that would provide the pipeline so that you could manage and improve the prompts that ran again and again. Now the system is growing more powerful, offering a higher level of automation that lets you meta-manage the prompt chain. They’ve also begun marketing it as a form of personal assistant with pre-built connections to many of the major services such as Gmail. Its llm-cost-optimizer can juggle multiple options while finding a cheaper way to execute a prompt, a process the company suggests can save 60% or more.

Pricing: Open-source free tier; Pro plan starts at $35 per month

Standout feature: Focus on multi-model pipelines for true agentic solutions

Best for: Product teams with complex prompt engineering workflows

New agentic compute patterns

Thu, 16 Jul 2026 11:19:03 +0200

For a decade, Kubernetes was the right answer. It organized containers, scaled services horizontally and gave platform teams a shared vocabulary for running software in production. It abstracted away enough of the underlying complexity that engineers could stop thinking about servers and start thinking about services. Most cloud-native infrastructure today is built on top of it, directly or in spirit, and EKS made that model the default for the majority of enterprise teams running workloads on AWS.

The workload that defined that era was the stateless HTTP request, fast in, fast out, disposable. A user action triggers a request, the request hits a service, the service returns a response and the container is done. Kubernetes was optimized for that pattern down to the scheduler internals: Bin-pack containers onto nodes, autoscale on CPU and memory, evict and reschedule when something goes wrong. The whole system is tuned around the assumption that individual units of work are short, stateless and interchangeable.

That assumption no longer holds for the workloads that matter most right now.

The agent workload is structurally different

Agents are long-running, stateful processes. They reason across time, call external tools, spawn subprocesses, write and execute code, and make decisions that depend on what happened five steps earlier in the same task. A single-agent workflow might run for minutes or hours, touching a dozen external systems and generating intermediate outputs that subsequent steps depend on. The compute layer for that kind of work needs to do things the old model was never asked to do. That is the new pattern: Execution infrastructure designed around agent semantics rather than request semantics.

The Kubernetes community itself has acknowledged this mismatch. In March 2026, Kubernetes SIG Apps published an introduction to Agent Sandbox, a new CRD-based abstraction designed specifically for singleton, stateful agent workloads. The framing is direct: The ecosystem is moving from short-lived, isolated tasks to deploying multiple, coordinated AI agents that run continuously, and mapping those workloads to traditional Kubernetes primitives requires an entirely new abstraction. The fact that the Kubernetes maintainers built a dedicated primitive for this, rather than recommending teams compose one from existing resources, is itself the clearest signal that agent execution does not fit the old model.

What agent execution actually requires

Concretely, it requires four things. First, isolated execution environments that provision in milliseconds, not minutes, so each agent task gets its own sandbox for code execution and tool calls without blocking the reasoning loop. The difference between a two-second environment and a two-minute environment is not a performance optimization; it determines whether the architecture is viable at all. Second, durable state management across the full task lifecycle, so an agent can pause, hand off or resume without re-initializing from scratch and burning tokens to reconstruct context it already built. Third, coordination primitives for multi-agent work: The ability to spawn subagents, pass structured outputs between them and track task dependencies across a graph of concurrent processes. Production agent systems are rarely single agents; they are pipelines of specialized agents with handoffs that need to be reliable and inspectable. Fourth, credentials and secrets management that travel with the execution context, so agents can authenticate to external services securely without exposing credentials in the task definition, logs or the environment variables of a shared container.

The mismatch shows up fast in production

Kubernetes and EKS expose the mismatch quickly in practice. Pod eviction terminates an agent mid-task with no clean recovery path. Autoscaling reads CPU utilization as the load signal, but an agent holding a long inference connection looks idle to the scheduler even when it is doing the most consequential work in the pipeline. Provisioning a new environment takes 45 seconds to two minutes on a well-tuned cluster; agent workloads need that in under two seconds or the reasoning loop stalls and the user experience degrades visibly. These are not edge cases or misconfigurations. They are the normal operating conditions for production agent workloads running on infrastructure that was not designed for them.

The utilization data makes the broader cost picture even starker. The 2026 State of Kubernetes Optimization Report from CAST AI, drawn from analysis of over 23,000 production clusters across AWS, Azure and GCP, found average CPU utilization at 8 percent, down from 10 percent the year prior. Memory utilization fell from 23 to 20 percent. CPU overprovisioning jumped from 40 to 69 percent year over year. These numbers reflect clusters running traditional workloads, and the pattern is worsening, not improving, as environments scale. Agent workloads compound this problem further. An agent holding an open inference connection or waiting on a tool call registers as idle to a scheduler that reads CPU and memory as the only meaningful load signals. The infrastructure responds to the wrong metric, overprovisioning capacity for demand it cannot measure, while the actual bottleneck, environment provisioning latency and state continuity, goes unaddressed.

Security is not the same problem it was before

Agent workloads change the threat model at the infrastructure level. A compromised stateless service exposes a narrow surface defined by its API contracts. A compromised agent exposes every system it can reach, every credential it holds and every action it is authorized to take on behalf of the user. Agents generate and execute their own code, make non-deterministic tool-call decisions and accumulate context across long-running sessions. Standard container namespacing does not contain that kind of risk. Kernel-level isolation, default-deny network egress, scoped credentials per session and agent-aware observability are not optional hardening steps. They are baseline requirements for running agents in production.

What teams that ship agents have already figured out

Some of the clearest evidence for this shift comes not from infrastructure vendors but from product engineering teams running agents at scale on their own code. In late 2025, Ramp’s engineering team published a detailed account of building Inspect, their internal background coding agent. Each Inspect session runs in a sandboxed VM with a full-stack development environment and deep integrations across their observability, CI, and deployment tooling. The architecture requirements map almost exactly to the four primitives above. Filesystem snapshots keep sessions starting in seconds rather than minutes. Sessions are isolated and stateful. The agent can run tests, review telemetry, query feature flags and visually verify frontend changes in a real browser. And the whole system supports unlimited concurrency, so engineers can spin up ten parallel sessions exploring different approaches to the same problem without contention.

The results speak for themselves. Within months of launch, roughly 30 percent of all pull requests merged to Ramp’s frontend and backend repositories were written by Inspect. That level of adoption was not mandated. It happened because the execution environment was fast enough, capable enough and well-integrated enough that the agent was strictly better than a local workflow for a meaningful share of tasks. The key insight from the Ramp case is not about the model. It is about the execution layer. As their team put it, session speed should only be limited by model-provider time-to-first-token; everything else, like cloning and installing, needs to be done before the session starts. That is a statement about infrastructure, not intelligence.

The ecosystem is catching up, but defaults are sticky

None of that is a criticism of the tools. Kubernetes solved exactly the problem it was designed for, and it solved it well. The issue is that infrastructure defaults are sticky. Teams inherit them, build on top of them and optimize within their constraints long after the underlying workload has changed. The Kubernetes community’s own response, the Agent Sandbox project under SIG Apps, validates the thesis that a new abstraction is necessary. The new primitives the community is building include warm pools for near-zero cold starts, lifecycle management for suspending and resuming idle agents without losing state, and pluggable kernel isolation for secure execution of untrusted code. These are not incremental improvements to existing resources. They are net-new abstractions that acknowledge the old model does not stretch to fit.

But adoption of purpose-built agent infrastructure remains early. Enterprises building agent pipelines today are largely running a request-oriented orchestration model against an execution-oriented workload, and the mismatch shows up in task failure rates, runaway costs and debugging cycles that have no good tooling because the observability layer was also designed for stateless services.

The structural advantage is available now

The infrastructure to close that gap exists now. The prerequisite is recognizing that agent execution is a first-class compute pattern with its own primitives and its own requirements, not a variant of the stateless service model that defined the last decade. Teams that make that shift early will have a meaningful structural advantage. The ones that do not will spend the next two years wondering why their agent systems are unreliable at a scale that should be tractable.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Getting from black-box AI to glass-box AI

Thu, 16 Jul 2026 11:04:17 +0200

A year ago, most enterprise AI systems generated recommendations. Today, AI systems are approving transactions, routing shipments, updating records, interacting with customers, and triggering downstream software actions with little or no human involvement.

For CIOs, that shift changes the central governance question. The challenge is no longer simply whether an AI model is accurate. It is whether the organization can explain, audit, and defend the decisions the system makes.

When an AI assistant suggests a meeting time or summarizes a document, mistakes are inconvenient. When an autonomous AI system issues a refund, reprices a product, modifies a customer record, or initiates a financial transaction, mistakes carry operational, legal, and reputational consequences.

When those consequences arrive, “the model decided” is not an acceptable explanation.

This is the accountability gap emerging at the center of enterprise AI adoption. Organizations are deploying increasingly autonomous systems while relying on technology that often provides little visibility into how decisions are made. The result is a growing mismatch between the level of authority organizations grant AI and their ability to understand or justify its actions.

Black-box AI may have been acceptable when AI primarily generated predictions. It becomes far more problematic when AI begins taking actions on behalf of the business.

The lesson software already learned

Fortunately, the technology industry has faced a similar challenge before.

As enterprise software systems became more distributed and complex, troubleshooting failures became increasingly difficult. Engineers could no longer rely on intuition to understand what happened when something broke. The solution was observability: the practice of instrumenting systems so their internal state could be understood through logs, metrics, traces, and monitoring.

The goal was not to predict every possible failure in advance. It was to create enough visibility that teams could reconstruct what happened after the fact and identify the root cause.

Enterprise AI now requires a similar discipline.

But AI observability must go beyond traditional software observability. It is not enough to know what action occurred. Organizations also need visibility into why the system believed that action was appropriate.

An auditable AI system should be able to answer questions such as:

What information did the system rely on?
Which tools or data sources did it access?
What alternatives did it consider?
What verification steps were performed?
How confident was it in its conclusion?
What events led to the final action?

These questions are rapidly becoming essential operational requirements rather than technical nice-to-haves.

Why visibility matters more as AI gains autonomy

As AI systems become more autonomous, failures become harder to detect and diagnose.

A human reviewing a single AI-generated recommendation can often spot obvious mistakes. A network of AI agents coordinating multiple tasks across business processes presents a different challenge. Decisions can build upon one another. A flawed assumption early in a workflow can propagate through subsequent actions, creating confident but incorrect outcomes.

The challenge is rarely identifying that something went wrong. Eventually, an error surfaces through a customer complaint, a failed transaction, an audit finding, or an operational disruption.

The challenge is determining why it happened.

Which information influenced the decision? Which tools were consulted? Which safeguards worked as intended? Which ones failed?

Without visibility into the reasoning process, troubleshooting autonomous AI workflows can become significantly more difficult than debugging traditional software systems.

For CIOs responsible for enterprise reliability, compliance, and governance, that lack of visibility creates unacceptable operational risk.

Moving toward glass-box AI

The answer is not to slow AI adoption. The answer is to make AI systems observable.

Increasingly, organizations are seeking AI systems that behave more like a glass box than a black box. The objective is not to expose every parameter inside a neural network. Rather, it is to provide a clear, auditable record of how decisions were reached and why actions were taken.

The most promising approaches share two common characteristics.

The first is verification. Instead of treating a single model’s output as ground truth, systems incorporate independent validation steps before actions are executed. Multiple agents, external checks, business rules, or verification workflows help identify errors before they become operational incidents.

The second is explainability. Effective systems maintain a decision trail that captures inputs, intermediate reasoning steps, tool usage, verification activities, and outputs in a form that human reviewers can understand.

Together, these capabilities create something that has long been expected of human decision-makers but is often missing from AI systems: the ability to show your work.

The regulatory and business reality

The push toward AI observability is not being driven solely by technologists.

Regulators increasingly expect organizations to demonstrate oversight of automated decision-making systems. Emerging AI governance frameworks place growing emphasis on transparency, traceability, accountability, and human oversight.

Customers are moving in the same direction. Whether the decision involves pricing, service, eligibility, or support, people increasingly want the ability to understand and challenge outcomes that affect them.

The result is a convergence of operational, regulatory, and market pressures around a single requirement: organizations must be able to explain what their AI systems are doing.

Three questions every CIO should ask

Before deploying autonomous AI systems, technology leaders should be able to answer three basic questions:

Can we reconstruct the complete decision path that led to an action?
Can we verify critical outputs before actions are executed?
Can a human auditor understand why the decision occurred?

If the answer to any of those questions is no, the organization may be granting more authority to AI than it can responsibly govern.

Accountability will become a competitive advantage

The organizations that succeed with autonomous AI will not necessarily be those that automate the most processes or deploy the largest models. They will be the organizations that combine automation with accountability.

Black-box systems made sense when AI primarily generated predictions. As AI increasingly acts on behalf of businesses, customers, and employees, visibility becomes essential.

The future of enterprise AI will belong not to systems that merely act, but to systems whose actions can be examined, understood, and trusted.

—

Agentic orchestration: Enterprise AI organizations have a deployment problem, not a platform problem — and most are calling chatbots agents

Thu, 16 Jul 2026 00:46:36 +0200

Methodology

At 101 respondents the sample is robust enough to read directionally with reasonable confidence, though it remains self-selected and is not a probability sample.

Finding 1: Orchestration runs on model-provider platforms

Anthropic’s Claude leads; open frameworks are marginal

We asked which agent orchestration platform enterprises primarily use today. The answer concentrates on the major model providers — and on one in particular.

Finding 2: Model gravity drives platform selection

The base model, not the tooling, decides the platform

We asked what most influenced the orchestration platform choice. The single largest factor is the pull of the underlying model — though flexibility and ease of development follow close behind.

Finding 3: The job is reliable multi-step execution

Enterprises just orchestration by whether it completes the work

We asked what enterprises optimize for — their primary success metric for orchestration. Reliability and multi-step workflow management dominate; developer- and user-facing metrics trail.

Finding 4: Consolidate, productionize, and build in-house

Three strategic moves are nearly tied for the year ahead

We asked what major change enterprises anticipate in their orchestration strategy over the next 12 months. Three moves cluster at the top, almost evenly split.

Finding 5: Investment flows to workflow tooling

Tooling and permissions lead the spend; monitoring trails

We asked which orchestration-related investment will grow most next year. Agent workflow tooling leads, with security and permissions enforcement behind.

Finding 6: The control plane will be hybrid — and lock-in is why

Enterprises expect to split control between providers and their own layer

Finding 7: The chatbot trap — most “agents” aren’t agents yet

Enterprises admit most deployments are still chatbot wrappers

Finding 8: Fiscal control is still reactive

Only a minority can stop a runaway agent before the bill arrives

The bottom line: The layer is real; most of the agents aren't yet

Organizations with 100 or more employees describe an orchestration strategy that is consolidating quickly and maturing slowly. They are standardizing on model-provider platforms — Anthropic’s Claude leads at 40% — chosen for the gravity of the underlying model, and they judge success by reliable multi-step execution. Investment is flowing to workflow tooling and permissions, the strategy is to consolidate frameworks and push agents into production, and the control plane they expect is deliberately hybrid, because vendor lock-in is the risk they fear most.

But the honest self-assessment punctures the ambition. Seventy-one percent say a quarter or fewer of their deployed “agents” are truly orchestrated, only 10% are past the halfway mark, and more than a quarter cannot stop a runaway agent in real time. The orchestration layer — the platforms, the budgets, the control architecture — is being built ahead of the orchestrated portfolio it is meant to run. At 101 respondents in a single June wave this reads as a clear directional signal rather than a precise measurement: enterprises have decided how they want to orchestrate agents well before most of their agents are doing anything an orchestration layer is for. The question for subsequent waves is whether the deployed reality closes the gap on the ambition — or whether the chatbot trap proves stickier than the roadmap assumes.

IBM targets AI edge with Power server, software upgrades

Wed, 15 Jul 2026 20:37:53 +0200

IBM has bolstered its Power server portfolio with a new edge S1112 server and announced IBM Power Autonomous Operations, an AI agent that helps customers monitor Power systems and autonomously resolve issues to keep operations running smoothly. Additional software upgrades are aimed at helping customers deploy and manage AI infrastructure components.

“Each announcement addresses a different layer of the enterprise technology stack, from how infrastructure is deployed and managed to how applications are developed, modernized, and optimized,” wrote Brandon Pederson, senior IBM i product manager, in a blog post about the new products. “Together, they reinforce a broader direction for IBM Power of helping clients move from manually operated infrastructure toward intelligent, resilient, and AI-assisted systems that are easier to manage, easier to modernize, and ready for new workloads.”

The new IBM Power S1112 is a one‑socket Power11 server engineered for IBM i, AIX, and Linux. Aimed at distributed and edge locations, it is Big Blue’s new entry-level i server and is AI‑ready by design, integrating on‑chip Matrix Math Acceleration (MMA) for fast inferencing and other AI‑driven use cases, such as support for AI-assisted decisions, automation, and analytics close to where data is generated and consumed, Pederson stated.

The server supports two configurations: a 10-core 3.05 to 4.0 Ghz Power11 Processor in a rack version only, and a 4-core 3.60 to 4.0 Ghz Power11 in rack and tower form factors, IBM stated.

“For IBM i clients, Power S1112 is especially important because it expands what entry IBM i environments can do. IBM i P05 clients can run IBM i partitions within the P05 software tier while also using additional system resources for AIX, Linux, VIOS, AI, or open-source workloads on the same server,” Pederson wrote. “This creates a flexible path to consolidate workloads, improve utilization, and support modernization without forcing clients into a larger platform than they need.”

width="1024" height="683" sizes="auto, (max-width: 1024px) 100vw, 1024px">

Thomas Prior for IBM

Announced: IBM Power Autonomous Operations

On the software side, IBM Power Autonomous Operations offers automation capabilities via an embedded AI agent that offers natural language interactions designed to help customers manage, tune, and streamline their environments without relying on deep domain expertise for every task, Pederson stated.

“IBM Power Autonomous Operations is designed to continuously monitor, optimize, protect, and manage Power environments. It combines Power telemetry, AI-powered analytics, automation, and operational workflows into a unified experience that helps IT teams reduce complexity, improve resiliency, and increase productivity,” Pederson wrote.

“Rather than simply showing operators what is happening, Power Autonomous Operations is designed to help teams decide what to do next. The platform analyzes system telemetry, identifies risks and optimization opportunities, and provides intelligent recommendations or automated actions to improve performance, resiliency, and operational efficiency,” Pederson wrote.

Agentic Engine for IBM i

IBM also issued a preview of the Agentic Engine for IBM i, which is aimed at providing greater AI support for Power systems.

IBM described the Agentic Engine as a new enablement layer designed to make it easier to adopt native and integrated AI agents into IBM i workloads and business processes. The engine provides the runtime, IBM i Knowledge Pack, observability, extensibility, MCP server, and foundational agents that help teams build trusted agents for IBM i without starting from scratch. Developers can build agents using their preferred coding tools, run them close to Db2 for i data under native IBM i object-level authority, and extend them into broader enterprise workflows through APIs and agent-to-agent integration.

With security, governance, and instrumentation built in, the Agentic Engine for IBM i helps organizations manage agent behavior, monitor activity, and support responsible adoption across mission-critical environments, Pederson stated.

IBM Bob Premium Package for i

Also in the AI agent vein, IBM announced support for its Bob AI application development environment for the i system. The idea here is to help customers quickly modernize applications built on RPG and COBOL.

“These capabilities help developers explain complex RPG and COBOL programs, convert Fixed-Format RPG to modern Free-Format RPG, refactor monolithic applications into modular structures, generate RPG, CL, COBOL and DDS code, create technical documentation, and produce unit tests to support validation,” Pederson wrote. “Rather than relying on generic prompts and inconsistent results, IBM i teams can use expert-built skills that deliver more predictable, repeatable and higher-quality outcomes. Agentic workflows help guide multi-step development tasks from understanding and planning through implementation and validation, allowing developers to modernize incrementally without losing control.”

IBM also added new development features to the core operating system for i with IBM i 7.6 Technology Refresh 2 and i 7.5 Technology Refresh 8 that include a variety of features designed to enhance RPG and COBOL development, security, and hybrid cloud integration.

IBM Power S1112 is expected to be generally available on July 24, IBM Power Autonomous Operations is expected to be generally available on September 23, 2026, and IBM Bob Premium Package for i was made generally available on June 24, 2026.

AI is paying off, but governance is lagging behind

Wed, 15 Jul 2026 18:33:43 +0200

Enterprises are facing two simultaneous challenges with AI: The risks associated with it are evolving faster than governance frameworks, while the business benefits are often difficult to measure.

This is one of the key findings of The Value of AI, a study commissioned by SAP from Oxford Economics. Now in its second year, the study surveyed 2,600 executives from 13 countries worldwide.

High expectations, limited preparation

On average, the enterprises surveyed plan to spend around $28 million on AI (up from $26.7 million last year), and expect a 21% ROI (from 16% last year). Expectations for AI agents are particularly high, with ROI expected to reach 17% this year, up from 10% last year. Furthermore, 83% of respondents worldwide said agentic AI has the potential to fundamentally transform their organization. On the other hand, only 3% of respondents said their enterprises were fully prepared for the deployment of AI agents.

There are gaps, particularly when it comes to governance:

Only 12% of respondents said their skills or processes were able to govern AI effectively,
38% do not have human-in-the-loop processes in place for oversight of AI agents, and
only 63% have established permissions and access controls for agents.

Other concerns include weaknesses in the organization of AI deployment, poor data quality, insufficient employee training, and the widespread use of shadow AI.

Governance is the bigger challenge

width="1024" height="576" sizes="auto, (max-width: 1024px) 100vw, 1024px">

Sean Kask, Chief AI Strategy Officer at SAP

SAP

In an interview, Sean Kask, Chief AI Strategy Officer at SAP, commented on the study’s key findings.

Mr. Kask, in the study’s foreword, you write that companies are currently facing two challenges simultaneously: The risks associated with AI are evolving faster than governance, while the business benefits are often difficult to measure. Which of these poses the greater problem for companies?

Sean Kask: Measuring the business value of IT investments has never been easy. The same applies to AI. That’s why I currently consider the governance issue to be the greater challenge. While traditional governance principles and best practices for secure software development remain important even in the age of large language models and agent-based AI, entirely new risks are emerging at the same time.

For example, as soon as companies roll out AI on a broad scale, they suddenly discover hundreds or even thousands of so-called shadow agents that employees are using without central oversight. Or they find that a significant portion of the workforce is copying content into private ChatGPT accounts. Such risks often only become apparent once AI is already being used productively.

According to your study, German companies invest an average of nearly $40 million in AI, more than companies in all other countries surveyed. Why is that?

Kask: I was less surprised by the amount of investment than by the fact that, overall, the level of investment and the return on investment achieved have developed very similarly across the various countries. There’s no clear answer as to why Germany invests more. In part, it’s likely simply because costs here are higher than in India, for example.

However, we’re also seeing a high level of AI adoption among German companies. SAP has a dashboard that allows us to track how our customers are using AI features. Germany is among the countries with particularly high usage. Added to this are the strong industrial base and the political impetus from Europe, which are driving the use of AI. Accordingly, companies there are making targeted investments in building the necessary expertise.

According to the study, 47% of German companies are satisfied with the return on investment from their AI investments. At the same time, 77% say they are still far from realizing AI’s full potential. Isn’t that a contradiction?

Kask: No, we see this pattern worldwide. Companies initially invest in a few AI use cases and realize: This works; we’re creating added value. Accordingly, they’re satisfied with their investment.

But this is precisely what leads them to identify further use cases. They explore AI agents and want to utilize them as well. However, it is exactly at this point that many encounter new challenges in implementation and scaling.

The study therefore primarily highlights a learning curve: The more experience companies gain with AI, the greater their awareness of its previously untapped potential becomes.

According to the study, only 33% of companies surveyed have KPIs at the executive board level that are directly linked to the implementation of AI. In your view, which metrics should supervisory boards and CEOs definitely be tracking?

Kask: For us, a key indicator is employee enablement. How many employees have already successfully completed training or upskilling programs related to AI? Without the appropriate skills, AI adoption will fall short of its potential.

Transparency is equally important. Companies should know which AI agents are actually in use within their landscape. SAP offers the SAP AI Agent Hub for this purpose, which automatically discovers and inventories agents from SAP and third-party environments. Customers have already been able to identify thousands of agents this way, which highlights the need for centralized governance and transparency.

In addition, companies should have a complete overview of all AI use cases. A robust business case should be in place for each use case. We often see two extremes: Either the executive board is under pressure to implement AI as quickly as possible and allocates a lump-sum budget for this purpose. Or management initially takes a wait-and-see approach. This leads to independent pilot projects springing up throughout the company, with individual departments procuring their own tools and entering into their own contracts.

At SAP, we therefore follow a clearly structured selection process. Each idea first undergoes an assessment of its expected business value. We then examine technical feasibility, data availability, and ethical and governance aspects. From management’s perspective, it is crucial to maintain transparency regarding all ongoing AI projects at all times and to consistently prioritize them based on their business value.

Agents, too, need a ‘hire-to-retire’ lifecycle

Even with the introduction of dozens or even hundreds of AI agents, governance becomes increasingly complex. What capabilities do enterprise platforms need to manage AI agents securely and in a controlled manner at scale?

Kask: We make a conscious effort not to anthropomorphize AI too much. Nevertheless, the analogy is helpful: Agents require a complete hire-to-retire lifecycle. This begins with the detection and registration of an agent. It is then integrated into the enterprise environment, granted the necessary permissions, and given access to the data sources it needs to perform its tasks.

Observability is just as important. Companies must be able to track what an agent is actually doing in the system at all times. In addition, they should track key performance indicators: Is the agent achieving the desired results? How efficiently is it working? How many tokens does it consume? How many processing steps does it require for a task?

Ultimately, this involves several key components: a complete inventory of all agents, appropriate governance, risk, and compliance (GRC) mechanisms, transparency regarding agent behavior, and continuous monitoring. This is the only way to ensure that AI agents consistently operate within defined parameters and deliver the desired business value.

In your estimation, which business processes will companies actually delegate entirely to AI agents over the next two to three years?

Kask: Currently, such agents work particularly well in clearly defined use cases. SAP will release more than 50 (currently 34) specialized AI agents.

One example is periodic financial reporting. In this context, journal entries must be made based on numerous rules stored in documents, emails, or previous transactions. The agent analyzes these various sources of information, derives a recommendation from them, and suggests the appropriate journal entry to the user.

Based on what we’ve heard from customer projects, employees at medium-sized companies currently spend about twelve hours per month on these tasks. With the help of an AI agent, this effort can be reduced to two to three hours.

Another area of application is production planning. If delivery dates change or new orders come in at short notice, the entire production plan must be adjusted. It is precisely these kinds of complex optimization tasks that are ideally suited for AI agents.

In principle, there are virtually no limits to the narrowly defined business processes in which agents can be deployed. However, they will not operate completely autonomously at first.

Trust in AI begins with a stable foundation

Many companies still struggle to trust AI agents. After all, large language models operate probabilistically and can produce false information. This is particularly problematic in financial processes. How do you build trust?

Kask: Trust begins with a stable foundation. ERP systems remain the reliable system of record. They operate deterministically, contain the business logic, and hold the relevant company data. AI agents build upon this foundation. They do not replace it.

Equally important is the human-in-the-loop principle. Employees must be able to understand what the agent is doing, verify its results, and intervene if necessary. That’s why employee training also plays a crucial role. They must understand how generative AI works and where its limitations lie.

Of course, language models can hallucinate. At the same time, we must not forget that humans are not infallible either. The key lies in the collaboration between humans and AI. This allows us to improve both the efficiency and the quality of many business processes.

Another important component is transparency. Our global AI ethics policy, for example, stipulates that users must always be able to recognize when AI is involved. In Joule, it’s possible to trace which data sources the agent used and which steps it went through in reaching its decision. This traceability is an essential prerequisite for trust.

What distinguishes an SAP agent from a general AI agent that merely accesses an ERP system?

Kask: The key difference is that Joule and the SAP agents are directly embedded in the ERP system. There, for example, we’ve built a knowledge graph that describes the semantic relationships between all tables, business objects, and data fields.

To put this into perspective: The SAP S/4HANA Knowledge Graph is based on approximately 452,000 ABAP tables, 7.3 million data fields, and thousands of analytical views. The semantic relationships between these artifacts are modeled in the Knowledge Graph and made available for AI applications.

For example, if a user wants to view all open purchase orders, the agent does not first have to laboriously search for the relevant information. It immediately knows which tables and objects are relevant and also understands the relationships between a purchase order, a purchase requisition, the responsible approvers, and other business objects. As a result, the agent not only works much more precisely but also requires significantly fewer tokens because it can greatly narrow down the search space.

If, instead, one attempts to simply overlay AI onto an existing system or extract data from a relational ERP system, many of these relationships are lost. In a sense, this destroys the semantic context that is crucial for precise answers.

That is why we view the ERP system as an enormous strategic advantage. It has been the system of record for decades and contains roughly 50 years of codified business and process knowledge. This knowledge forms the foundation for what we call the autonomous enterprise. The agents build upon this knowledge and continue to develop it.

In the future, SAP agents will also communicate bidirectionally with agents from other providers via standards such as Agent-to-Agent (A2A).

According to your study, AI currently creates the greatest added value in decision-making, customer interaction, and gaining new insights, rather than in traditional productivity gains. Will this change the way companies justify AI investments in the future?

Kask: In our study, productivity was simply rated slightly lower than, for example, gaining new insights. In the long term, however, productivity remains the ultimate goal. Europe, in particular, has been suffering from comparatively weak productivity growth for years.

At SAP, we therefore first evaluate every new AI feature based on its specific business value. For all agents and AI features that we include in our AI Feature Catalog, we first conduct a value analysis. We ask: What benefit does the feature offer the user? Does it contribute to higher revenue? Does it increase productivity? Only then is it developed further.

At the moment, the greatest added value often still lies in consolidating information from structured and unstructured data sources and making it accessible via natural language. The next step, however, is to translate these insights directly into more efficient business processes. That is precisely where the greatest productivity gains will be realized in the future.

If you could give CIOs just one or two pieces of advice for the transition from generative AI to AI agents, what would they be?

Kask: In my view, the biggest mistake would be to try to transform the entire company all at once or to attempt to perfectly prepare all the data right from the start.

Instead, you should consider what kind of agent can create significant added value, and then implement it. Of course, this agent needs access to consistent and context-rich enterprise data. That’s exactly what we’re working on at SAP with technologies like the knowledge graph, which maps the semantic relationships within enterprise data.

In addition, with data products and the SAP Business Data Cloud, we provide tools that make data from various sources usable for AI agents. Thanks to zero-copy and data fabric approaches, information from legacy systems, Snowflake, or ERP systems can be consolidated without first having to extensively replicate the data. For a procurement agent, this makes it possible to provide exactly the relevant data for the specific use case.

The key point is this: Companies do not have to wait until they have fully migrated to the cloud or consolidated their entire data landscape. With the technologies available today, data can already be made usable for specific AI agents, managed in a controlled manner, and used to quickly generate initial business value. On the other hand, those who wait for the perfect starting point run the risk of falling behind.

This article is adapted from one first published by Computerwoche.

Which AI model should you bet your company on? None of them

Wed, 15 Jul 2026 17:19:39 +0200

Every day this past week I did something I suspect millions of other people also did: I stared at an LLM model picker and wondered which one I was supposed to want.

OpenAI just released ⁠GPT-5.6 Sol, Terra, and Luna. Sol is the flagship. Terra offers much of its intelligence for less money. Luna is cheaper still. Anthropic released ⁠Claude Sonnet 5 at the end of June and Opus 4.8 the month prior, with a little Fable 5 emerging in between. Meanwhile, Google, which seemed to be winning the model wars a few months ago, is now getting shade from Gergely Orosz, who ⁠argues that Gemini has slipped outside the top tier for software development and has been out of the major model release game for eons (May 19).

Perhaps Orosz is right. Perhaps he’ll be wrong again in six weeks. Honestly, it’s exhausting.

I use ChatGPT and Claude constantly and still have no principled idea which model to choose most of the time. I tend to click whatever looks like the biggest, most expensive option because I don’t know what I’m giving up by choosing something smaller. “Instant” sounds dangerously unserious. “Thinking” sounds expensive but powerful.

A quick survey of my LinkedIn crowd suggests others also feel my “WHICH MODEL???” pain. More importantly, I suspect most enterprises do, too.

A model doesn’t rot

Before getting carried away, however, it’s worth considering whether any of this model churn actually matters. After all, a model doesn’t rot. The model an enterprise put into production in March performs just as well in July as it did when the company selected it. “Obsolete” generally means that something better now exists, not that the deployed model suddenly stopped summarizing insurance claims or classifying support tickets. (In other words, once you have something working, the idea that “but maybe Opus 200.2 is better!” is really a FOMO problem, not a performance issue.)

Most enterprise workloads don’t live at the frontier anyway. Extraction, summarization, classification, document comparison, and customer-service assistance often work perfectly well with smaller, cheaper models. OpenAI’s own pitch for the trio of GPT-5.6 models isn’t simply that Sol is better. It’s that ⁠Terra and Luna deliver different combinations of intelligence, latency, and cost. Luna, the cheapest tier, nearly matches the previous generation’s peak performance at less than half the estimated cost, according to OpenAI.

The practical question, of course, is where to start. An enterprise can’t test every model, every reasoning setting, and every price tier before doing any work. So here’s my advice (which I don’t follow in my own work, but I’m not defining enterprise strategy and can be a little price-insensitive). Start with the cheapest credible model that appears capable of the task. Give it a representative set of real examples and, before you start testing, define what counts as good enough. If it passes, stop. If it fails, move up a tier or try a model with strengths better suited to the work.

That sounds almost offensively simple, but it reverses the way many people, including me, use these products. We start with the biggest model because we’re afraid of what we might lose. Enterprises should start lower and require evidence before paying for more intelligence.

There are exceptions, of course. For genuinely difficult work, such as autonomous coding, complex research, or high-stakes reasoning, beginning with a frontier model may save time. But even then, the goal should be to establish a quality ceiling, then test whether a cheaper model can meet it. It’s changing the question from “which model is best?” to “what is the least expensive model that reliably clears the bar for this job?”

For many workloads, that price improvement matters more than a few extra benchmark points. ⁠As I argued back in 2023, following AI hype doesn’t help anyone. If your model strategy depends on whichever benchmark screenshot is circulating on X this week, you don’t have a strategy. Not a viable one, anyway. Pick a model and ignore the noise.

Except, of course, when that noise suggests a serious signal.

Sometimes better really is better

Frontier improvements aren’t always incremental, making it advantageous to consider an upgrade. Coding is the obvious example. There’s a significant difference between a model that suggests the next few lines of code and one that can inspect a repository, plan a change, use tools, run tests, discover its own mistakes, and keep working for an extended period. That isn’t merely a nicer autocomplete experience. It can reorganize a development workflow.

This is why enterprises can’t simply standardize on an 18-month-old model and declare victory. In some areas, particularly software development and other agentic work, better models can unlock compounding productivity. A model that reliably completes 80% of a bounded task rather than 50% may justify an entirely different division of labor between humans and machines.

Still, that upgrade isn’t free.

Models differ in how they interpret instructions, call tools, manage context, refuse requests, and fail. Prompts and scaffolding tuned for one model can regress when moved to another. Or costs can explode. As one of my Oracle colleagues discovered just this week, running the same tasks in GPT 5.6 was orders of magnitude more expensive than 5.5. The API change may be trivial, but the revalidation and implications are not.

This leaves enterprises caught between two bad options. They can freeze and potentially miss out on meaningful improvements or chase every release and repeatedly test production systems on faith. What to do?

Stop making model bets

The answer is to stop making LLM bets and start making job-to-be-done bets. Stop asking which model is fastest. Instead, figure out what work you are trying to improve. What does a good result look like? How much latency and cost can the workflow tolerate? How wrong can it be before a human must intervene? Once those questions have answers, model selection becomes less opaque.

A difficult code migration may justify GPT-5.6 Sol or Claude Sonnet 5. A repetitive classification task may work just as well with Luna or another smaller model. A regulated workflow may require a model or deployment option that offers particular data controls. Sometimes the correct model is no LLM at all, like when I’m writing this post. Sorry, AI vendors! (At least you won’t get blamed for my mistakes.)

This is where evaluations become the center of enterprise AI strategy. ⁠As I’ve said before, most companies don’t have an AI quality problem so much as an AI measurement problem. Hence, a private evaluation suite built from real company work is the only leaderboard that matters. Does the new model materially improve quality? If so, use it! Does it reduce cost or latency? Again, that’s your free pass to adoption. Does the improvement justify the expense and effort of revalidation? If yes, continue.

Make model releases boring

As important as the model is, keep in mind that AI success always comes back to your company’s data, your company’s workflows, your company’s integrations, etc. That’s the ⁠dull reality behind sexy AI. Retrieval, memory, governance, data quality, observability, and feedback loops aren’t as exciting as a new model launch, but they’re what ultimately make AI truly work.

Again, when it’s time to consider something new, the principle should be to default to the least expensive model that reliably passes your evaluations. Only escalate harder tasks to more capable models when measurement shows that the premium pays. Tip: Make this invisible to employees so that the system routes to the best model for a particular prompt. As dbt Labs’ Jon Lewis expresses it, “The best model is ‘Auto’ and I won’t hear anyone say otherwise.” OpenAI’s own ⁠migration guidance recommends testing models on representative tasks, including trying a lower reasoning level rather than automatically cranking everything to the maximum.

As for me, I’ll probably keep clicking the shiniest option. I don’t have a formal evaluation suite for InfoWorld columns, and the marginal cost is a subscription I already pay. Enterprises don’t get that excuse.

Oracle expands AI Agent Studio for Fusion Applications with pro-code tools

Wed, 15 Jul 2026 17:19:28 +0200

Oracle on Tuesday expanded its AI Agent Studio for Fusion Applications with new pro-code development tools, including a CLI-based capability called AI Studio Skill, allowing developers to build agentic applications using familiar environments such as VS Code, Codex, and Claude Code.

The AI Studio Skill is the CLI that provides the Fusion-specific context and tooling that AI coding assistants need to build Fusion-native applications. It provides access to the project structure, APIs, templates, validation, packaging, and deployment workflows required for Fusion Agentic Applications, Natalia Rachelson, SVP of product for Fusion Applications at Oracle, told InfoWorld.

“Think of it as Oracle’s development harness for popular AI coding assistants. Developers can use models like Codex or Claude Code to generate code, while the AI Studio Skill connects those models to Oracle AI Agent Studio and the Fusion runtime,” Rachelson said.

Familiar tools and workflows to simplify development

The access to familiar IDEs and harnesses, according to analysts, will make it easier for developers to build and maintain agentic applications for business workflows.

“The AI Studio Skill provides developers a way to build Fusion agents like a new software function versus configuring them like application extensions,” said Scott Bickley, advisory fellow at Info-Tech Research Group.

“Enterprise developers expect source control, code review, repeatable deployments, testing or debugging, and integration into their existing toolchains. Connecting the various IDEs and code assist products will make it easier to build, validate, and maintain agentic applications using already familiar tools and processes. This ostensibly will result in agents that are easier to maintain, govern, and align with enterprise development practices,” Bickley added.

For Robert Kramer, managing partner at KramerERP, the move is likely to drive more adoption of the Studio itself: “Oracle is meeting developers where they already work and making Fusion a more attractive place to build agentic applications.”

Native runtime could aid governance in production deployments

However, the CLI and IDE integrations, for Bickley, extend beyond developer productivity into tackling the governance and execution challenges that often prevent AI prototypes from reaching production.

“One of the most painful barriers to production AI is that many prototypes are built outside the enterprise systems where identity, permissions, workflow approvals, and overall system governance are already built in,” Bickley said.

In contrast, the integrations will allow enterprises to run agentic applications from inside Oracle’s platform, leveraging existing business context, identity, approvals, and governance rather than recreating those capabilities through external orchestration layers when moving them into production, Bickley added.

That shift, the analyst further added, will prove beneficial for CIOs because it will accelerate business outcomes while operating within a trusted environment.

Governance, observability, and lifecycle management matter more to CIOs after agentic applications move into production, Kramer echoed.

Governance gains come with strategic trade-offs

The approach of building and running agentic applications natively inside Oracle Fusion, though, is not without trade-offs, analysts cautioned.

CIOs should pay close attention to vendor lock-in as more business processes become agentic, Bickley pointed out.

“In the case of Oracle Fusion, ensure the ATLAS framework provides an accurate validation layer at a low cost of overhead. Consider the levers that Oracle may avail itself of contractually or commercially in the future,” Bickley said.

“ROI should be modeled against a progressive monetization schema as AI agents operate upon a consumption-based infrastructure. As such, ensure provisions limiting cost overlays and uplifts are agreed upon prior to locking in,” Bickley added.

These considerations, the analyst further added, are becoming increasingly relevant because most enterprise software vendors, including the likes of SAP and ServiceNow, are introducing offerings and features to become the runtime and orchestration layer for enterprise AI.

Earlier in May, SAP expanded its AI strategy with the Autonomous Enterprise vision, introducing a unified Business AI Platform, Joule Studio 2.0, and AI Agent Hub to let enterprises build, govern, and run AI agents within a managed runtime.

In June, ServiceNow expanded its AI transformation by adding new features to its Context Engine and AI Control Tower, in order to better embed governance, enterprise context, and observability into AI workflows across enterprise systems.

During the same month, Salesforce, via its Informatica acquisition, added features to tie AI agents more closely to trusted enterprise data and operational workflows.

For developers and enterprises willing to try out the new CLI-based experience, it can be accessed from within the Studio without any additional cost, Oracle said.

The company is also adding a public GitHub repository that it said will provide templates, starter projects, sample applications, reusable assets, and reference architectures to help developers build and validate agentic applications faster.

Codex Multi-Agent V2 update raises developer concerns over agent transparency

Wed, 15 Jul 2026 17:19:18 +0200

OpenAI’s recent update to its Codex CLI has introduced a new protocol that appears to shift more orchestration decisions from user-defined configuration to the runtime, prompting developers to request greater visibility into the instructions exchanged between AI agents.

In a detailed GitHub merged request, users stated that the Multi-Agent V2 protocol-infused architecture of the CLI no longer exposes the instructions passed between parent and sub-agents, making it difficult to inspect how work is delegated across the system.

“Multi-agent v2 currently routes agent instructions through normal tool arguments and inter-agent context. That means the parent model can emit plaintext task text, Codex can persist it in history/rollouts, and the recipient can receive it as ordinary assistant-message JSON,” the request read.

“This changes the v2 path so agent instructions stay encrypted between model calls: Responses encrypts the message argument returned by the model, Codex forwards only that ciphertext, and Responses decrypts it internally for the recipient model,” it added.

Other users, commenting on the thread, also said that the lack of visibility into agent instructions can be attributed to the recently introduced Multi-Agent V2 protocol, with one user stating that reverting to the previous version of the CLI restored visibility, but only as a temporary workaround.

Separately, Ignat Remizov, CTO at payment service Zolvat, filed a GitHub feature request to offer what can be described as a permanent fix after stating that OpenAI may have introduced the change in efforts to harden security.

“A possible shape is to keep the encrypted message field for model delivery, but add a separate non-encrypted audit field for the readable task text. The audit field should be persisted in rollout/history/trace metadata so users and maintainers can inspect what was delegated without needing to decrypt model-delivery ciphertext,” Zolvat wrote.

Enterprise governance concerns are likely to emerge

While an OpenAI contributor said the protocol remains under development and declined further changes to the request, analysts warned that the issue would create debugging, governance, and operational challenges for development teams and their enterprises if the issue persists or becomes a long-term characteristic of multi-agent systems.

“Hidden agent instructions reduce observability in multi-agent systems. Developers can no longer see whether failures stemmed from incorrect task delegation, poor orchestration, or model reasoning, making debugging, prompt optimization, and root-cause analysis significantly harder. Agent instruction traces are becoming as essential as application logs in modern software,” said Pareekh Jain, principal analyst at Pareekh Consulting.

For CIOs, Jain pointed out, opaque agent interactions create governance challenges.

“Without visibility into how agents delegated and executed tasks, it becomes harder to audit decisions, investigate incidents, demonstrate compliance, and build trust in AI systems. Enterprises will increasingly expect secure but auditable agent communication rather than completely hidden orchestration,” Jain said.

“Any big enterprise, especially in regulated industries such as banks and hospitals, needs to be able to prove what their AI systems did and why, especially if something goes wrong. If a sub-agent does something bad, like touching private data, the company needs to show here’s exactly what it was told to do. If that record doesn’t exist, it is a serious problem for trust and legal accountability, not just an annoyance,” Jain added.

Further, the analyst pointed out that issues around the visibility of agent operations could even slow production deployments of mission-critical AI.

“Enterprises, just like we are seeing with developers on GitHub, are likely to demand stronger observability, audit trails, and governance before trusting autonomous multi-agent systems. It is nearly as important as model performance,” Jain added.

An email sent to OpenAI enquiring about planned changes to the protocol went unanswered.

SAP-Studie: KI rechnet sich – Governance hinkt hinterher

Wed, 15 Jul 2026 12:08:42 +0200

Sean Kask, Chief AI Strategy Officer bei SAP

SAP

Unternehmen stehen derzeit vor zwei gleichzeitigen Herausforderungen: Die Risiken rund um KI entwickeln sich schneller als die Governance, während sich der geschäftliche Nutzen oft nur schwer messen lässt.

Das ist eines der Kernergebnisse von „The Value of AI“, einer Studie, die SAP in Zusammenarbeit mit Oxford Economics in diesem Jahr zum zweiten Mal erstellt hat. Für die Studie wurden weltweit 2.600 Führungskräfte aus 13 Ländern befragt, darunter 200 Entscheiderinnen und Entscheider aus Deutschland.

Hohe Erwartungen, geringe Vorbereitung

Im Durchschnitt wollen deutsche Unternehmen in diesem Jahr rund 35 Millionen Euro in KI investieren und rechnen mit einem ROI von 24 Prozent (Vorjahr: 17 Prozent). Besonders hoch sind die Erwartungen an KI-Agenten: Ihr wirtschaftlicher Nutzen soll innerhalb von zwei Jahren auf rund 18 Millionen Euro steigen. Und: 90 Prozent der befragten Unternehmen schreiben Agentic AI das Potenzial zu, ihre Organisation grundlegend zu verändern. Andererseits fühlen sich nur vier Prozent der Unternehmen vollständig auf den Einsatz von KI-Agenten vorbereitet.

Insbesondere beim Thema Governance bestehen Lücken:

Nur elf Prozent der Befragten halten die Steuerungsfähigkeiten in ihrem Unternehmen für ausreichend,
mehr als 50 Prozent verfügen nicht über Prozesse zur menschlichen Kontrolle von KI-Agenten, und
lediglich 30 Prozent haben Berechtigungs- oder Agentenverzeichnisse eingerichtet.

Gleichzeitig befürchten oder akzeptieren viele Unternehmen, KI-Agenten schneller einzuführen, als sie diese kontrollieren können. Weitere Bremsklötze sind Schwächen in der Organisation des KI-Einsatzes, mangelhafte Datenqualität, unzureichende Qualifizierung der Beschäftigten sowie die weit verbreitete Nutzung von Schatten-KI.

Im CW-Gespräch nimmt Sean Kask, Chief AI Strategy Officer bei SAP, zu den wichtigsten Ergebnissen der Studie Stellung.

“Die Governance-Frage ist aktuell die größere Herausforderung”

Herr Kask, im Vorwort der Studie schreiben Sie, dass Unternehmen derzeit vor zwei Herausforderungen gleichzeitig stehen: Die Risiken rund um KI entwickeln sich schneller als die Governance, während sich der geschäftliche Nutzen oft nur schwer messen lässt. Was bereitet Unternehmen die größeren Probleme?

Sean Kask: Den geschäftlichen Nutzen von IT-Investitionen zu messen, war nie einfach. Das gilt auch für KI. Deshalb halte ich die Governance-Frage aktuell für die größere Herausforderung. Klassische Governance-Prinzipien und bewährte Verfahren für sichere Softwareentwicklung bleiben zwar auch im Zeitalter großer Sprachmodelle und agentischer KI wichtig. Gleichzeitig entstehen aber völlig neue Risiken.

Sobald Unternehmen KI breit ausrollen, entdecken sie beispielsweise plötzlich Hunderte oder sogar Tausende sogenannter „Shadow Agents“, die Mitarbeitende ohne zentrale Kontrolle einsetzen. Oder sie stellen fest, dass ein erheblicher Teil der Belegschaft Inhalte in private ChatGPT-Konten kopiert. Solche Risiken werden häufig erst sichtbar, wenn KI bereits produktiv genutzt wird.

Deutsche Unternehmen investieren laut Ihrer Studie mit durchschnittlich fast 40 Millionen Dollar mehr in KI als Unternehmen in allen anderen untersuchten Ländern. Woran liegt das?

Kask: Mich hat weniger die Höhe der Investitionen überrascht als vielmehr die Tatsache, dass sich Investitionsniveau und erzielter Return on Investment über die verschiedenen Länder hinweg insgesamt sehr ähnlich entwickelt haben. Warum Deutschland mehr investiert, lässt sich nicht eindeutig beantworten. Teilweise dürfte es schlicht daran liegen, dass die Kosten hier höher sind als beispielsweise in Indien.

Wir sehen aber auch eine hohe KI-Adoption bei deutschen Unternehmen. SAP verfügt über ein Dashboard, mit dem wir nachvollziehen können, wie unsere Kunden KI-Funktionen einsetzen. Deutschland gehört dabei zu den Ländern mit einer besonders hohen Nutzung. Hinzu kommen die starke industrielle Basis und die politischen Impulse aus Europa, die den Einsatz von KI vorantreiben. Entsprechend investieren Unternehmen hier gezielt in den Aufbau entsprechender Kompetenzen.

Laut Studie sind 47 Prozent der deutschen Unternehmen mit dem Return on Investment ihrer KI-Investitionen zufrieden. Gleichzeitig sagen 77 Prozent, dass sie das Potenzial von KI noch längst nicht ausschöpfen. Ist das nicht ein Widerspruch?

Kask: Nein, dieses Muster sehen wir weltweit. Unternehmen investieren zunächst in einige wenige KI-Anwendungsfälle und stellen fest: Das funktioniert, wir erzielen einen Mehrwert. Entsprechend sind sie mit ihrer Investition zufrieden.

Doch genau dadurch erkennen sie auch weitere Einsatzszenarien. Sie beschäftigen sich mit KI-Agenten und möchten diese ebenfalls nutzen. Genau an diesem Punkt stoßen viele jedoch auf neue Herausforderungen bei der Einführung und Skalierung.

Die Studie zeigt deshalb vor allem eine Lernkurve: Je mehr Erfahrungen Unternehmen mit KI sammeln, desto größer wird ihr Bewusstsein für das bislang ungenutzte Potenzial.

Der Studie zufolge verfügen nur 35 Prozent der deutschen Unternehmen über KPIs auf Vorstandsebene, die direkt an die Einführung von KI gekoppelt sind. Welche Kennzahlen sollten Aufsichtsgremien und CEOs aus Ihrer Sicht unbedingt messen?

Kask: Ein zentraler Indikator ist für uns das Enablement der Mitarbeitenden. Wie viele Beschäftigte haben bereits Schulungs- oder Upskilling-Programme rund um KI erfolgreich absolviert? Ohne entsprechende Kompetenzen bleibt auch die KI-Adoption hinter ihren Möglichkeiten zurück.

Ebenso wichtig ist Transparenz. Unternehmen sollten wissen, welche KI-Agenten in ihrer Landschaft tatsächlich im Einsatz sind. SAP bietet hierfür den SAP AI Agent Hub an, der der Agenten aus SAP- und Drittanbieter-Umgebungen automatisch entdeckt und inventarisiert. Kunden konnten so bereits Tausende Agenten identifiziert, was den Bedarf an zentraler Governance und Transparenz deutlich macht.

Außerdem sollten Unternehmen einen vollständigen Überblick über alle KI-Anwendungsfälle haben. Für jeden Use Case sollte ein belastbarer Business Case vorliegen. Häufig erleben wir zwei Extreme: Entweder steht der Vorstand unter Druck, möglichst schnell KI einzuführen und stellt dafür pauschal Budget bereit. Oder das Management hält sich zunächst zurück. Dann entstehen überall im Unternehmen eigenständig Pilotprojekte, einzelne Fachbereiche beschaffen eigene Werkzeuge und schließen eigene Verträge ab.

Bei SAP verfolgen wir deshalb einen klar strukturierten Auswahlprozess. Jede Idee durchläuft zunächst eine Bewertung des zu erwarteten Geschäftswerts. Danach prüfen wir die technische Machbarkeit, die Datenverfügbarkeit sowie ethische und Governance-Aspekte. Aus Sicht des Managements ist entscheidend, jederzeit Transparenz über alle laufenden KI-Projekte zu haben und diese konsequent nach ihrem Geschäftswert zu priorisieren.

“Auch Agenten brauchen einen ‘Hire-to-Retire’-Lebenszyklus”

Auch mit der Einführung von Dutzenden oder sogar Hunderten KI-Agenten wird die Governance immer komplexer. Welche Funktionen benötigen Enterprise-Plattformen, um KI-Agenten sicher und kontrolliert im großen Maßstab zu verwalten?

Kask: Wir versuchen bewusst, KI nicht zu stark zu vermenschlichen. Dennoch hilft die Analogie: Für Agenten braucht es einen vollständigen „Hire-to-Retire“-Lebenszyklus. Das beginnt mit der Erkennung und Registrierung eines Agenten. Anschließend wird er in die Unternehmensumgebung integriert, erhält die notwendigen Berechtigungen und Zugriff auf die Datenquellen, die er für seine Aufgaben benötigt.

Ebenso wichtig ist die Observability. Unternehmen müssen jederzeit nachvollziehen können, was ein Agent im System tatsächlich macht. Darüber hinaus sollten sie Leistungskennzahlen erfassen: Erreicht der Agent die gewünschten Ergebnisse? Wie effizient arbeitet er? Wie viele Tokens verbraucht er? Wie viele Verarbeitungsschritte benötigt er für eine Aufgabe?

Letztlich geht es um mehrere Bausteine: ein vollständiges Inventar aller Agenten, geeignete Governance-, Risk- und Compliance-Mechanismen (GRC), Transparenz über das Verhalten der Agenten sowie eine kontinuierliche Überwachung. Nur so lässt sich sicherstellen, dass KI-Agenten dauerhaft innerhalb der definierten Leitplanken arbeiten und den gewünschten Geschäftswert liefern.

Welche Geschäftsprozesse werden Unternehmen Ihrer Einschätzung nach in den nächsten zwei bis drei Jahren tatsächlich vollständig an KI-Agenten delegieren?

Kask: Derzeit funktionieren solche Agenten vor allem in klar abgegrenzten Anwendungsfällen besonders gut. SAP wird mehr als 50 (aktuell 34) spezialisierte KI-Agenten veröffentlichen.

Ein Beispiel ist die periodische Rechnungslegung. Dort müssen Buchungen anhand zahlreicher Regeln erfolgen, die in Dokumenten, E-Mails oder früheren Transaktionen hinterlegt sind. Der Agent analysiert diese verschiedenen Informationsquellen, leitet daraus eine Empfehlung ab und schlägt dem Sachbearbeiter die passende Buchung vor.

Nach dem, was wir aus Kundenprojekten hören, verbringen Mitarbeitende mittelgroßer Unternehmen heute oft rund zwölf Stunden pro Monat mit diesen Aufgaben. Mithilfe eines KI-Agenten lässt sich dieser Aufwand auf zwei bis drei Stunden reduzieren.

Ein weiteres Einsatzfeld ist die Produktionsplanung. Ändern sich Liefertermine oder gehen kurzfristig neue Aufträge ein, muss der gesamte Produktionsplan angepasst werden. Genau solche komplexen Optimierungsaufgaben eignen sich hervorragend für KI-Agenten.

Grundsätzlich gibt es kaum Grenzen dafür, in welchen eng umrissenen Geschäftsprozessen Agenten eingesetzt werden können. Vollständig autonom werden sie allerdings zunächst nicht agieren.

“Vertrauen in KI beginnt mit einer stabilen Basis”

Viele Unternehmen tun sich noch schwer, KI-Agenten zu vertrauen. Schließlich arbeiten große Sprachmodelle probabilistisch und können halluzinieren. Gerade bei Finanzprozessen ist das problematisch. Wie schaffen Sie Vertrauen?

Kask: Vertrauen beginnt mit einer stabilen Basis. Die ERP-Systeme bleiben das verlässliche „System of Record“. Sie arbeiten deterministisch, enthalten die Geschäftslogik und die relevanten Unternehmensdaten. KI-Agenten bauen auf dieser Basis auf – sie ersetzen sie nicht.

Ebenso wichtig ist das „Human in the Loop“-Prinzip. Mitarbeitende müssen nachvollziehen können, was der Agent macht, seine Ergebnisse überprüfen und bei Bedarf eingreifen. Deshalb spielt auch die Qualifizierung der Beschäftigten eine entscheidende Rolle. Sie müssen verstehen, wie generative KI funktioniert und wo ihre Grenzen liegen.

Natürlich können Sprachmodelle halluzinieren. Gleichzeitig darf man nicht vergessen, dass auch Menschen nicht fehlerfrei arbeiten. Entscheidend ist das Zusammenspiel von Mensch und KI. So lassen sich sowohl die Effizienz als auch die Qualität vieler Geschäftsprozesse verbessern.

Ein weiterer wichtiger Baustein ist Transparenz. Unsere globale KI-Ethikrichtlinie schreibt beispielsweise vor, dass Nutzer immer erkennen können müssen, wenn KI beteiligt ist. In Joule lässt sich nachvollziehen, welche Datenquellen der Agent genutzt hat und welche Schritte er bei seiner Entscheidung durchlaufen hat. Diese Nachvollziehbarkeit ist eine wesentliche Voraussetzung für Vertrauen.

Was unterscheidet einen SAP-Agenten von einem allgemeinen KI-Agenten, der lediglich auf ein ERP-System zugreift?

Kask: Der entscheidende Unterschied liegt darin, dass Joule und die SAP-Agenten direkt im ERP-System verankert sind. Dort haben wir beispielsweise einen „Knowledge Graph“ aufgebaut, der die semantischen Beziehungen zwischen sämtlichen Tabellen, Geschäftsobjekten und Datenfeldern beschreibt.

Um die Größenordnung zu verdeutlichen: Der SAP S/4HANA Knowledge Graph basiert auf rund 452.000 ABAP-Tabellen, 7,3 Millionen Datenfelder und Tausenden analytischen Sichten. Die semantischen Beziehungen zwischen diesen Artefakten werden im Knowledge Graph modelliert und für KI-Anwendungen nutzbar gemacht.

Wenn ein Anwender beispielsweise sämtliche offenen Bestellungen einsehen möchte, muss der Agent nicht erst mühsam nach den relevanten Informationen suchen. Er weiß sofort, welche Tabellen und Objekte relevant sind und kennt auch die Beziehungen zwischen einer Bestellung, einer Bestellanforderung, den zuständigen Genehmigern und weiteren Geschäftsobjekten. Dadurch arbeitet der Agent nicht nur deutlich präziser, sondern benötigt auch erheblich weniger Tokens, weil er den Suchraum stark eingrenzen kann.

Versucht man stattdessen, KI lediglich auf ein bestehendes System aufzusetzen oder Daten aus einem relationalen ERP-System herauszulösen, gehen viele dieser Beziehungen verloren. Man zerstört gewissermaßen den semantischen Kontext, der für präzise Antworten entscheidend ist.

Deshalb betrachten wir das ERP-System als einen enormen strategischen Vorteil. Es ist seit Jahrzehnten das System of Record und enthält rund 50 Jahre kodiertes Geschäfts- und Prozesswissen. Dieses Wissen bildet die Grundlage für das, was wir als „Autonomous Enterprise“ bezeichnen. Die Agenten bauen auf diesem Wissen auf und entwickeln es weiter.

Künftig werden SAP-Agenten zudem über Standards wie Agent-to-Agent (A2A) bidirektional mit Agenten anderer Anbieter kommunizieren.

Laut Ihrer Studie schafft KI derzeit den größten Mehrwert bei der Entscheidungsfindung, der Kundeninteraktion und der Gewinnung neuer Erkenntnisse – weniger bei klassischen Produktivitätssteigerungen. Wird sich dadurch die Art verändern, wie Unternehmen KI-Investitionen künftig begründen?

Kask: Die Produktivität wurde in unserer Studie lediglich etwas niedriger bewertet als beispielsweise die Gewinnung neuer Erkenntnisse. Langfristig bleibt Produktivität aber das eigentliche Ziel. Gerade Europa leidet seit Jahren unter einem vergleichsweise schwachen Produktivitätswachstum.

Bei SAP bewerten wir deshalb jede neue KI-Funktion zunächst anhand ihres konkreten Geschäftsnutzens. Für alle Agenten und KI-Funktionen, die wir in unserem „AI Feature Catalog“ erfassen, erstellen wir zunächst eine Wertanalyse. Wir fragen: Welchen Nutzen hat die Funktion für den Anwender? Trägt sie zu mehr Umsatz bei? Steigert sie die Produktivität? Erst dann wird sie weiterentwickelt.

Im Moment liegt der größte Mehrwert häufig noch darin, Informationen aus strukturierten und unstrukturierten Datenquellen zusammenzuführen und per natürlicher Sprache zugänglich zu machen. Der nächste Schritt besteht aber darin, diese Erkenntnisse direkt in effizientere Geschäftsprozesse zu überführen. Genau dort werden sich die größten Produktivitätsgewinne künftig realisieren.

“Der größte Fehler wäre, gleich das gesamte Unternehmen zu transformieren”

Wenn Sie CIOs nur einen oder zwei Ratschläge für den Übergang von generativer KI zu KI-Agenten geben könnten – welche wären das?

Kask: Der größte Fehler wäre aus meiner Sicht, gleich das gesamte Unternehmen transformieren oder zunächst sämtliche Daten perfekt aufbereiten zu wollen.

Stattdessen sollte man überlegen, welche Art von Agent einen hohen Mehrwert schaffen kann – und diesen dann umsetzen. Natürlich braucht dieser Agent Zugriff auf konsistente und kontextreiche Unternehmensdaten. Genau daran arbeiten wir bei SAP mit Technologien wie dem „Knowledge Graph“, der die semantischen Zusammenhänge der Unternehmensdaten abbildet.

Darüber hinaus stellen wir mit „Data Products“ und der „SAP Business Data Cloud“ Werkzeuge bereit, die Daten aus unterschiedlichen Quellen für KI-Agenten nutzbar machen. Dank Zero-Copy- und Data-Fabric-Ansätzen können Informationen aus Altsystemen, Snowflake oder ERP-Systemen zusammengeführt werden, ohne dass Daten dafür zunächst umfangreich repliziert werden müssen. Für einen Einkaufsagenten lassen sich so genau die relevanten Daten für den jeweiligen Anwendungsfall bereitstellen.

Der entscheidende Punkt ist: Unternehmen müssen nicht warten, bis sie vollständig in die Cloud migriert oder ihre gesamte Datenlandschaft konsolidiert haben. Mit den heute verfügbaren Technologien lassen sich Daten bereits jetzt für konkrete KI-Agenten nutzbar machen, kontrolliert verwalten und auf dieser Basis schnell erste geschäftliche Mehrwerte erzielen. Wer dagegen erst auf die perfekte Ausgangslage wartet, läuft Gefahr, den Anschluss zu verlieren.

The hidden AI cost driver: Harness design can make or break enterprise agent economics

Wed, 15 Jul 2026 10:03:51 +0200

A largely overlooked layer of the AI stack is emerging as a major driver of enterprise costs. New testing by AI consultancy Systima found that agent harnesses, the software that coordinates models, tools and workflows, can generate significant token overhead through their configuration alone, potentially inflating the cost of AI deployments as organizations scale agents from experimental pilots to production environments.

The firm, which ran a series of tests by juxtaposing two harnesses on the same tasks, namely Anthropic’s Claude Code and open-source OpenCode using the same Claude Sonnet 4.5 model underneath, found both exhibiting sharply different token overhead because of the differences in their configuration.

These differences included system prompts, tool definitions, agent coordination mechanisms and other orchestration components, resulting in markedly different baseline input token overhead before users even entered a prompt, the consultancy firm wrote in a blog post.

Separately, the firm also found that other configuration choices while setting up the harnesses such as repository instruction files, Model Context Protocol (MCP) servers, prompt framework templates and subagents can each add substantial token overhead.

The consultancy’s conclusions are also supported by emerging academic research examining how orchestration of the harnesses themselves, rather than optimizing models or changing them, can help enterprises reshape the economics around AI agents.

In a paper, titled The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI, researchers showed that changing the harness while keeping models and tasks the same can reduce token consumption by 38%, cost per task by 41%, and execution time by 44% while maintaining comparable quality.

Why enterprises overlook harness costs

Analysts say that enterprises can gain greater control over AI agent operating costs by paying closer attention to how their harnesses are configured and orchestrated, instead of just relying on model pricing as a yardstick.

“The evaluation shows that the model is only one part of agent economics. The harness, tool schemas, instructions, MCP connections, and subagents matter as well. Enterprises therefore need to measure the entire agent configuration, not assume model pricing tells them what an agent will cost,” said Stephanie Walter, practice lead of the AI stack at HyperFRAME Research.

Currently, most enterprises pick agent tooling based on model quality, benchmarks, developer experience, and headline pricing per seat or per million tokens, with almost no one measuring what the harness sends per request, how stable the cache prefix is, or what subagent fan out costs at scale, echoed Advait Patel, site reliability engineer at Broadcom.

“Ask the average CIO whether their coding agent rewrites its cache mid-session, and you will get a blank stare,” Patel added.

However, Ashish Chaturvedi, executive research leader at HFS Research, pointed out that lack of visibility is less a failure of enterprise leaders than a consequence of how AI agent ecosystem components are sold, stacked, and managed presently.

“Most organizations have no visibility, mainly due to the absence of any metric from the vendor’s end that lets CIOs measure the entire agent or at least the harness configuration. None of this shows up in the developer’s experience. The agent just works, and the tokens burn silently in the background,” Chaturvedi said.

The problem is further compounded, according to Chaturvedi, due to the manner in which AI agent configuration is distributed across enterprise teams.

“The harness is chosen by one team, the instruction file written by another, and the MCP servers attached by a third, so no single person sees the cumulative weight,” Chaturvedi noted.

Even when, in some cases, enterprises do have visibility and ownership, Patel argued, the industry, in general, still lack the operational maturity and discipline to systematically optimize AI agent costs.

“FinOps for agents is where cloud FinOps was in 2013. Nobody has hired the equivalent of a cost optimization team focused on prompt engineering, harness configuration, and cache stability,” Patel said.

Separately, Abhishek Satapathy, principal analyst at Avasant, pointed out that the invisibility issue stems from how enterprises evaluate AI agents before deploying them into production: “Most proof-of-concepts involve a limited number of users, relatively short-lived sessions, and controlled agentic interactions, where the accuracy of model output is the primary evaluation criterion.”

The analysts’ comments also echo the conclusions of another research paper, in which researchers argued that token consumption in agentic software engineering systems remains poorly understood because existing metrics provide limited visibility into where tokens are spent across orchestration components.

How CIOs can improve visibility into AI agent costs

Closing that visibility gap, though, according to Satapathy, is increasingly becoming a priority for enterprises, as AI agents move from pilots to production and operating costs become harder to predict.

“Across our advisory engagements, we are seeing growing demand for AI observability frameworks that combine runtime tracing, workload-level cost attribution, and execution analytics. This enables organizations to establish engineering baselines, benchmark workload efficiency, forecast AI operating costs, and continuously optimize agent performance as deployments mature,” Satapathy said.

However, until vendors provide more comprehensive visibility into harness-level token consumption, analysts said enterprises should begin treating harness configuration as an operational governance issue rather than merely a developer preference.

“The single most valuable move is to get visibility into what the harness actually sends. Enterprises should treat configuration as a governed cost decision, deliberately match harnesses to workloads, and closely monitor cache behavior and subagent fan-out, since those were among the biggest cost multipliers identified in the evaluation,” Chaturvedi said.

Walter echoed that recommendation, saying CIOs should require observability across the entire agent configuration: “Without that visibility, enterprises are effectively buying an agent platform without knowing how much of the bill comes from useful work versus orchestration overhead.”

How AI agents are shaping the future of work

Tue, 14 Jul 2026 12:07:53 +0200

I attended several major technology conferences in 2025 where the first AI agents embedded in enterprise SaaS platforms were announced. Some of these agents showed promise and a glimpse into the future of work, while others looked like natural language extensions of a platform’s existing functionality.

At the end of 2025, Anthropic and OpenAI launched new AI models and code-generating capabilities. More developers tried vibe coding, and some platforms launched spec-driven development capabilities. By February 2026, even The New York Times reported that the AI disruption had arrived, noting that code generators were building “apps that may be flawed, but credible.”

Wall Street investors took notice of the code-generation improvements and other disruptive factors, driving a selloff in SaaS stocks, now referred to as the “SaaSpocalypse.” Part of their concern stemmed from the belief that CIOs would use AI to write software that would replace SaaS solutions.

AI innovations from SaaS and solution providers

But I thought differently and wrote a response in my article asking whether AI is the end of SaaS as we know it. CIOs might use AI to accelerate application modernization, but I doubt they would replace their ERP, CRM, and even smaller SaaS point solutions by building them.

Instead, I believed it would be SaaS companies that would take the most advantage of AI code-generation capabilities.

This hypothesis drove me to attend nine conferences this spring to see how SaaS companies were launching AI agents and defining a new future of work. I wrote eight articles on what CIOs need to know about data management, agile organizations, marketing, ERPs, critical process management, and other evolutions to plan for in the AI era.

Now, looking across all nine conferences, I can draw some conclusions about how AI agents are shaping the future of work. Here are my learnings and what CIOs need to consider when evaluating and deploying AI agents in the workplace.

Agentic, human-in-the-middle, or augmenting human?

SaaS companies have very distinct perspectives on the future of work, including the extent to which humans will play which roles and whether and how quickly we’ll see agentic, fully automated work.

For example, Atlassian proclaimed, “step into the future of human-AI collaboration,” while SAP unveiled “the autonomous enterprise.” Snowflake aimed to “make AI real for business,” while Appian targeted “serious AI built on process.”

These vendors’ marketers had to decide whether to lead with AI, people, or business in their messaging, but so must CIOs as they contemplate their AI strategies and how to get employees to fully adopt AI agents.

Some CIOs see a fully automated agentic AI as the future, with human-in-the-middle as a transitional phase as departments build trust in AI agents’ decision-making and automation capabilities.

Other CIOs see AI more as a tool that delivers productivity improvements by augmenting human decision-making capabilities. Many of these CIOs see human augmentation as essential to supporting critical thinking, innovation, and creativity.

Deloitte’s State of AI Report, published in January, provides a benchmark. It states that 36% of IT leaders expect at least 10% of their jobs to be fully automated in the next year, and 82% expect to reach that benchmark in three years.

Many organizations will have a mix of AI agents, choosing automation where reliability at scale is possible, but opting for human augmentation in operationally critical or customer-facing domains. But how CIOs position AI agents is not only an operational strategy; it’s also a cultural statement that shapes employees’ embrace of AI and whether detractors vocalize job-loss fears.

In the short term, it will also weigh in on which AI agents to use from different partners and which areas to build in-house.

Many options to test and deploy AI agents

Many solution providers are demonstrating significantly more AI agents this year. For example, SAP went from 40 Joule Agents in 2025 to over 200 in 2026. Three technology capabilities are fueling this significant growth:

Adobe, Appian, Boomi, Cisco, Domo, Salesforce, SAP, Snowflake, and others offer data fabrics and data-pipeline capabilities to connect data sources outside the primary workflows supported by their platforms. Appian, Pega, Quickbase, and SAP also centralize business process automation, an important starting point for developing AI agents.
MCP servers enable integration and communication between AI agents and are used to facilitate multistep agentic workflows. Virtually all the companies announcing major investments in AI agents are also announcing MCP integration capabilities and related partnerships.
Solution providers are not just using AI code-generating capabilities; many are launching their own AI agent development tools. The first beneficiaries of these development tools are the solution providers themselves and their integration partners, who use them to accelerate the development of AI agents and make them available to customers.

The result is that CIOs will have many options about which agents to test, but will have to dedicate analysts to understand the capability, cost, and compliance trade-offs. Additionally, expect AI agent capabilities to evolve significantly over the next few years, so CIOs should continuously revisit their decisions regarding deployed AI agents, focusing on performance, benefits, and ROI.

CIOs should also watch for signs of shadow AI and employee confusion about which AI agents to experiment with on different platforms. The AI strategy should include a transparent, defined process for selecting, reviewing, evaluating, procuring, deploying, driving adoption, monitoring, and collecting end-user feedback around AI agents.

AI development capabilities for engineers and citizen builders

The apparent ease-of-use of AI code generators may lead some engineering teams to build AI agents rather than buy them from SaaS providers. But CIOs should quickly realize that coding is just one step in developing AI agents, and that aggressively pursuing a build strategy can lead to AI debt and increased AI costs.

DevOps teams can code AI agents using tools such as Claude, Codex, Lovable, and Replit — a do-it-yourself approach. Some SaaS companies are providing an alternative, with AI agent development tools that leverage the data, infrastructure, and governance baked into their platforms. Many of these development tools offer flexibility, allowing developer teams to select AI models and development environments.

Examples of new and enhanced AI development tools I saw at conferences this quarter include:

I also reviewed Nutanix Agentic AI, a platform-as-a-service for accelerating the deployment of agentic AI workloads, and Adobe Firefly AI Assistant for creatives.

These development tools can target different audiences. Some look like low-code development tools targeted at software developers, whereas others are no-code and enable citizen developers, i.e., businesspeople, to develop applications and agents. Additionally, some of these tools support spec-driven development and generate artifacts such as product requirement documents (PRDs), data models, and testing capabilities.

Before commissioning AI development for apps and agents, CIOs should sponsor proofs of technical, data, modeling, security, and governance capabilities.

The context layer powering AI agents

Between AI agents and the enterprise’s intelligence, including structured data sources, defined business processes, and agent interactions (both human-to-agent and agent-to-agent), lies an evolving “context layer.”

This layer refers to the enterprise knowledge that AI agents draw on when evaluating signals and recommending or taking actions. Context may include a knowledge graph, a semantic layer, cleansed document repositories, and other knowledge bases.

The context layer, skills, tools, out-of-the-box agents, and governance capabilities are some areas to review where solution providers differentiate. Some examples:

Many support the Open Semantic Interchange, and some brand their context layers, such as the Atlassian Teamwork Graph, Boomi Knowledge Hub, and the SAP Knowledge Graph.
Some are branding their guardrails, such as Adobe’s AI Brand Intelligence, Appian’s Private AI, and Quickbase AI Control Center.
To manage AI agents at scale, some are extending the notion of data catalogs and other governance tools to the AI domain with products such as Boomi Connect, SAP AI Agent Hub, and Snowflake Horizon Catalog.

CIOs should recognize that while solution providers will compete on capabilities, the real “secret sauce” of the context layer lies in the company’s trusted data, well-defined business processes, and employee adoption of AI agents.

Conversational user experiences and coworkers

AI agents use the context layer, but also tap into skills, which encode the procedures they can follow, and tools, which prescribe the actions they can take. Before AI agents are ready to pilot, their governance, including permissions, approval gates, and other guardrails, must be defined. Other capabilities to look for when defining AI agents include orchestration, testing evals, and observability.

In 2025, many solution providers bolted on AI agents to their existing user experiences. This year, many solution providers showcased new conversational user experiences that employees can use instead of traditional ones built with forms, flows, reports, and static dashboards. Conversational user experiences are where AI agents and people come together, whether it’s human-in-the-middle or human augmentation.

Solution providers also grouped their AI agents into assistants or coworkers. For example, Adobe CX Coworker illustrates human augmentation, helping marketers manage campaigns with prompts and monitor their performance. SAP launched Joule Assistants across several business functions, including finance, human capital, supply chain, and customer experience. Other assistants, such as Appian AI Copilot, Atlassian Rovo, Cisco AI Assistant, Nutanix NIVA, and Snowflake CoWork, offer AI-first user experiences to assist different end-user types.

CIOs should demo these AI-first user experiences to glimpse the future of work.

Developers are already getting used to these experiences through code generators and vibe coding tools. Now, similar capabilities are being tailored across all business functions. CIOs should ramp up their change management programs to accelerate the adoption of these AI capabilities.

Solution providers are showcasing AI capabilities that can help CIOs reshape their businesses. But in Q2, there were only a few examples of how AI can help CIOs drive growth, evolve business models, or embed AI into customer-facing products. I expect to see a wave of further AI innovations that will go beyond productivity improvements and efficiencies and help CIOs pursue growth-driving digital transformation strategies.

Sacolick travelled to conferences mentioned in this article as a guest of Adobe, Appian, Atlassian, Domo, Nutanix, SAP, and Snowflake. In addition, he was hired by Quickbase to speak at its conference.

5 Wege zu mehr KI-Accountability

Tue, 14 Jul 2026 06:05:33 +0200

Wenn mit KI etwas schiefläuft, ist oft der schuld, der am nächsten dran war.

TetianaKtv | shutterstock.com

Intelligente Systeme werden zunehmend produktiv eingesetzt. Ist das der Fall, müssen viele Unternehmen schnell feststellen, dass das im Hinblick auf die Accountability Probleme aufwirft. Schließlich funktionieren KI-Tools nicht wie klassische Enterprise-Software: Ihre dynamische Interaktion mit Daten, APIs und Business-Workflows kann unvorhersehbare Ergebnisse hervorbringen.

Den Status Quo bei vielen Anwendern bringt David DuChene, Manager beim KI-Dienstleister SHI International, auf den Punkt: „Wenn bei der KI etwas schiefgeht, wird die Verantwortung in der Regel demjenigen zugewiesen, der dem Problem am nächsten stand.“

Und weil KI-Systeme im Rahmen von Workflows zunehmend nicht mehr die Rolle des Beraters, sondern die des Akteurs einnehmen, lässt sich Accountability nicht mehr allein über Richtlinien durchsetzen. Vielmehr ist es Aufgabe der IT-Führungskräfte, diese direkt in die Struktur ihrer Betriebsabläufe zu integrieren. Zum Beispiel in Form der folgenden fünf Maßnahmen.

1. Verantwortlichkeiten klar definieren

Immer noch sind diverse KI-Anwenderunternehmen (insbesondere im Enterprise-Umfeld) davon überzeugt, dass KI-Accountability eine Aufgabe für die gesamte Belegschaft ist. Experten argumentieren allerdings, dass diese Annahme sich als falsch erweist, sobald die Systeme produktiv eingesetzt werden. Zum Beispiel Joe Wilson, SVP und CIO beim Softwareanbieter CSG: „Geteilte Accountability ist keine Accountability. Ein direkter Owner ist unabdingbar.“

Laut dem Manager werde bei seinem Arbeitgeber auf diese Weise verfahren. Zudem durchliefen KI-Initiativen Governance Reviews, an denen auch die Geschäftsleitung beteiligt ist. Darüber hinaus setze CSG jedoch auch auf „CIO-Repräsentanten“, die in den Geschäftsbereichen und Produktgruppen eingebettet sind. Auf diese Weise will der Softwareanbieter laut seinem CIO sicherstellen, dass die Accountability den gesamten Lebenszyklus von KI-Initiativen abdeckt.

Formalisierte Verantwortlichkeitsstrukturen wie diese fehlten jedoch bislang in den meisten Unternehmen, hält DuChene fest: „Auf dem Papier mag es zwar Verantwortliche geben, aber sobald ein System tatsächlich ausfällt, wird alles neu verhandelt.“

Ob Organisationen in Sachen Accountability wirklich vorbereitet sind, lässt sich laut dem Manager anhand einer diagnostischen Frage klären: „Wenn Ihr KI-Deployment eine falsche Antwort generiert, die das Unternehmen Geld kostet, wer wird dann das Postmortem schreiben? Wenn Führungskräfte diese Frage nicht direkt beantworten können, existieren Accountability-Strukturen in der Praxis wahrscheinlich noch nicht.“

2. Governance rechtzeitig einziehen

In den vergangenen Jahren haben viele Unternehmen KI-Systeme eingeführt – laut DuChene, bevor sie die dafür notwendigen Grundlagen in Bezug auf Governance und Operations geschaffen haben: „Das größte Problem, das wir regelmäßig beobachten, hängt mit der richtigen Reihenfolge der Maßnahmen zusammen. In vielen Fällen wurden jede Menge Häuser gebaut, deren Wände bereits standen, bevor das Fundament gegossen war.“

Das führe im Nachgang zu kostspieligen Nachrüstungsmaßnahmen, meint der Manager: „Die Teams in diesen Unternehmen stellen dann häufig viel zu spät fest, dass wichtige Dinge wie Datenklassifizierungssysteme, KI-bezogene IAM-Kontrollen oder Eskalationskanäle für Fehler nicht vorhanden sind.“

Laut Seth Dobrin, CEO beim KI-Modellanbieter Arya Labs und ehemaliger Global AI Leader bei IBM, scheitert Governance oft daran, dass Unternehmen sie als reinen Policy-Layer betrachteten, anstatt sie direkt in operative Workflows zu integrieren. „Wenn man das nicht richtig hinbekommt, wird das Ganze auseinanderfallen“, konstatiert der KI-Experte. Er verweist auf das Beispiel eines Versicherungsunternehmens, das über 18 Monate ein intelligentes System aufgebaut hatte, bevor die Rechtsabteilung das Deployment lahmgelegt habe: „Das Problem war nicht die Technologie selbst, sondern, dass Governance in der Frühphase des Projekts keine Rolle gespielt hat. Am Ende musste das Unternehmen das Projekt dann verwerfen.“

CSG-Manager Wilson argumentiert an dieser Stelle, dass Governance die Teams in Unternehmen dabei unterstützen sollte, Komplexität zu bewältigen, statt sie in ihrer Handlungsfähigkeit einzuschränken: „Governance ist eher ein Fahrwerkssystem als ein Bremsmechanismus. Die Dinge sollen schneller gehen, müssen aber auch funktionieren, wenn man in unwegsames Gelände gerät.“

In diesem Zusammenhang kommt es auch auf die Daten an, warnt Quais Taraki, CTO von EnterpriseDB. Viele Unternehmen würden regelmäßig unterschätzen, wie schwierig es ist, die Accountability aufrechtzuerhalten, sobald KI-Systeme mit fragmentierten Datenumgebungen im Enterprise-Umfeld interagierten: „Ein KI-Assistent, der beispielsweise Kundeninteraktionen zusammenfasst, könnte regulierte oder vertrauliche Daten aus Systemen abrufen, die dafür niemals vorgesehen waren.“

Um Probleme wie diese gar nicht erst entstehen zu lassen, sind starke Data-Governance-Praktiken unabdingbar. Konkret:

Lineage,
Provenance Tracking,
Klassifizierungssysteme und
Zugriffskontrollen.

Darüber hinaus schaffen diese Maßnahmen auch die Grundlage für Accountability, falls doch einmal etwa schiefgehen sollte. Denn sie ermöglichen es festzustellen, auf welche Daten ein KI-System zugegriffen hat, wie die Outputs generiert wurden – und auch, ob sensible Informationen dabei eine Entscheidung beeinflusst haben. „Ohne Data Lineage und Provenance sind keine Ursachenanalysen möglich – sprich, man weiß nicht, was zu ändern ist und hat keinen Einblick, wie sich die Dinge auf unerwartete Weise verändert haben“, hält Taraki fest.

Der CTO plädiert dafür, Accountability an regulierten Datenprodukten auszurichten – statt an organisatorischen Silos: „Wenn die Ownership quer über Infrastruktur-, Data-Science- und Entwickler-Teams verteilt wird, kann es schwierig werden, nach einem Fehler zu klären, wer verantwortlich war. Klare Zuständigkeiten für die Datenprodukte, die die KI-Systeme versorgen, tragen dazu bei, die Rechenschaftspflicht über den gesamten KI-Lebenszyklus hinweg sicherzustellen.“

3. Observability integrieren

Klassische Enterprise-Monitoring-Systeme wurden in erster Linie dafür entwickelt, um die Verfügbarkeit, den Infrastrukturzustand und die Applikationsleistung zu überwachen. Künstliche Intelligenz wirft jedoch neue Herausforderungen auf: Bei diesen Systemen müssen Reasoning-Pfade, Entscheidungsketten und Verhaltensabweichungen nachverfolgt werden.

Nik Kale, Mitglied der Coalition for Secure AI (CoSAI), empfiehlt dazu einen sogenannten „Investigation Graph“. Dieser könne Aufschluss darüber geben, was ein KI-System beobachtet, auf welche Tools es zugegriffen hat, zu welchen Schlussfolgerungen es gelangt ist und welche Aktionen es letztendlich ergriffen hat. „Wenn etwas nicht funktioniert, ist der erste Impuls immer die Frage danach, warum die KI diese Entscheidung getroffen hat. Man müsste aber eher danach fragen, wie das System tatsächlich agiert hat – schließlich handelt nicht das KI-Modell, sondern das System um es herum.“

Diese breitere Accountability-Perspektive verändert auch die Wahrnehmung von Observability: Anstatt KI-Modelle isoliert zu überwachen, brauchen Unternehmen zunehmend Transparenz über sämtliche Systeme, mit denen diese interagieren – einschließlich Datenquellen, APIs, Anwendungen, Sicherheitskontrollen und nachgelagerten Workflows. Für die Praxis heißt das, umfassend zu protokollieren – nämlich:

Prompts,
Outputs,
Tool-Aufrufe,
Datenzugriffs-Events sowie
Agentenaktionen.

In Kombination mit herkömmlicher Anwendungs- und Infrastruktur-Telemetrie entstehen so auditierbare Protokolle darüber, wie sich KI-Systeme verhalten haben und warum Entscheidungen getroffen wurden.

Diese Transparenz wird besonders wichtig, wenn IT-Verantwortliche es mit unbefugter KI-Nutzung zu tun bekommen. Während Governance-Richtlinien definieren, welche Tools Mitarbeiter verwenden sollten, hilft Observability dabei, aufzudecken, welche Tools sie tatsächlich nutzen. Indem die Observability über KI-Modelle hinaus auf die gesamte Unternehmensumgebung ausgeweitet wird, kann die IT Schatten-KI früher erkennen, schneller untersuchen und die dadurch entstehenden Accountability-Lücken schließen.

4. Eskalationsmechanismen etablieren

Die wichtigste Accountability-Frage ist allerdings, wann ein KI-System innehalten und um Hilfe bitten sollte. Leider ist das in der Erfahrung von KI-Experte Kale ein Bereich, der bei den meisten KI-Implementierungen in Unternehmen eher wenig Beachtung finde. Der Manager argumentiert, dass Unternehmen explizite Eskalationspfade, menschliche Entscheidungspunkte und klar definierte Stoppmechanismen für KI-Systeme benötigten, die im Produktivbetrieb eingesetzt werden: „Ein ‚Abnicker‘ wäre hier fehl am Platz – Stichwort ‚Human in the Loop‘. Dieser Mensch sollte benannt sein und auch die Befugnis haben, die KI zu stoppen.“

Geht es nach CIO Wilson, sind solche Notaus-Mechanismen auch mit Blick auf die Incident Response nötig: „Ein herkömmlicher IT-Vorfall ist typischerweise ein ‚Up‘- oder ‚Down‘-Szenario. KI-Ausfälle sind etwas subtiler: Modelle können im Zeitverlauf Drift entwickeln oder Workflows Ergebnisse liefern, die unerwartet sind, aber technisch nicht auffallen.“

Daraus ergebe sich laut dem Manager ein wachsender Bedarf für interdisziplinäre Response-Prozesse, an denen Rechts-, Kommunikations-, Security-, Audit-, Business- und IT-Operation-Teams parallel beteiligt sind.

5. KI wie Mitarbeiter behandeln

Traditionelle Software kann oft bereits zum Zeitpunkt ihrer Veröffentlichung geprüft und freigegeben werden, weil ihr Verhalten zwischen den Versionen relativ stabil bleibt. Das ist bei KI-Systemen anders: Modelle entwickeln sich weiter, Prompts ändern sich, Retrieval-Systeme werden aktualisiert, und auch die Informationen, die Agenten zur Verfügung stehen, verändern sich kontinuierlich. Dennoch betrachten nicht wenige Unternehmen KI nach wie vor wie herkömmliche Anwendungen.

Kale ist jedoch der Auffassung, dass die Technologie sich weniger wie deterministische Software, sondern eher wie Mitarbeiter verhält: „Man kann KI nicht einfach einmal bereitstellen und es dann dabei belassen. Ähnlich wie bei der Belegschaft braucht es auch hier ein gewisses Maß an Oversight – etwa in Form von Performance-Reviews, Feedback-Runden oder um abweichendem Verhalten Einhalt zu gebieten.“

Diese Herausforderung geht über intern entwickelte Systeme hinaus, wie der IT-Entscheider festhält: „Unternehmen müssen auch die KI-Services von Drittanbietern im Blick behalten, auf die sie sich verlassen. Denn diese aktualisieren Software und Funktionen möglicherweise hinter den Kulissen.“

Um die Verantwortlichkeiten zwischen Anwenderunternehmen, Software- und Modellanbietern sowie Infrastrukturbetreibern zu klären, verweist Kale auf das „AI Shared Responsibility Framework“ (PDF) der CoSAI. (fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Computerworld.com erschienen.

Apple kauft SigScalr

Mon, 13 Jul 2026 19:40:02 +0200

Apple hat bestimmte Vermögenswerte von SigScalr, dem Unternehmen hinter der Observability-App SigLens, erworben und Mitarbeiter des Unternehmens übernommen. So geht es aus einer Eintragung auf der Webseite der Europäischen Kommission hervor. Apple kauft SigScalr Immer wenn Alphabet, Amazon, Apple, ByteDance, Meta oder Microsoft Akquisitionen tätigen oder andere Maßnahmen ergreifen, die unter den Anwendungsbereich des europäischen […]

The desktop infrastructure problem that kubernetes finally solves

Mon, 13 Jul 2026 17:32:00 +0200

Presented by Kasm Technologies

Enterprise infrastructure teams have spent the better part of a decade pushing workloads into Kubernetes. Applications, APIs, batch jobs, data pipelines — if it runs in a container, it belongs in the cluster. The operational benefits are well-established: declarative configuration, horizontal scaling, self-healing, native integration with CI/CD pipelines and observability tooling. Kubernetes has become the default operating model for production workloads.

Except for desktops.

Secure desktop and application delivery — the kind that enterprises depend on for remote work, privileged access, and regulated-industry workflows — has remained stubbornly outside the Kubernetes model. Legacy virtual desktop infrastructure was built in a different era, for a different set of assumptions: pre-allocated VM pools, bespoke management planes, proprietary appliances, and operational tooling that has nothing to do with how modern platform teams work. The result is a split infrastructure reality: a modern, cloud-native application layer on one side, and a manually managed, operationally isolated desktop layer on the other.

That split is expensive. It means different tooling, different scaling behaviors, different observability approaches, and different operational runbooks. Platform engineers who are proficient in Kubernetes still have to context-switch into an entirely different mental model the moment a desktop infrastructure problem arises.

The more fundamental issue is that this split is unnecessary. Secure, containerized workspace delivery is a workload that Kubernetes is architecturally well-suited to run. Sessions are containers. Scaling is demand-driven. Configuration should be declarative. The only thing missing was a platform built to take advantage of that alignment.

Why the timing is right

The appetite for Kubernetes-native workspace delivery has grown significantly as organizations mature their container platform investments. Platform teams that have spent years standardizing on Helm, GitOps workflows, and Kubernetes-native observability are increasingly unwilling to make an exception for desktop infrastructure. The question has shifted from "can we run this on Kubernetes?" to "why isn't this running on Kubernetes already?"

At the same time, the security case for containerized workspace delivery has become more urgent. Browser-delivered, containerized workspaces provide session isolation that VM-based desktops cannot match — each session is ephemeral, isolated at the container boundary, and terminates cleanly without persistent state. For organizations managing sensitive data, insider risk, or third-party access scenarios, this isolation model is a meaningful security control, not just a deployment convenience.

The convergence of these two trends — Kubernetes-native infrastructure expectations and containerized session security — creates a clear opportunity for platforms that can address both simultaneously.

What Kubernetes-native deployment looks like

A Kubernetes-native deployment uses Kubernetes as the control plane for workspace infrastructure — handling orchestration, scaling, and lifecycle management through the same declarative model used across the rest of the platform. Instead of relying on dedicated management appliances or pre-provisioned desktop pools, infrastructure is managed through the same CI/CD, GitOps, observability, and security workflows the platform team already operates. This gives platform teams a consistent operational model rather than maintaining a separate toolset for desktop infrastructure.

Kasm Workspaces, the browser-delivered workspace platform, is purpose-built to use Kubernetes as the control plane for workspace orchestration and delivery. Its deployment model is designed for real enterprise environments — not simplified demos — with production-grade Helm charts that follow Kubernetes conventions, tested upgrade paths between versions, and a standardized backend architecture validated across production deployments. An RDP Gateway component purpose-built for the Kubernetes topology enables Windows and Linux virtual machine access through the same platform.

Key capabilities include:

Horizontal session scaling driven by actual demand, orchestrated by Kubernetes — no pre-warmed VM pools required.
Declarative configuration through Helm values, enabling GitOps and CI/CD integration for workspace infrastructure.
Namespace-level isolation and compatibility with existing RBAC policies, ingress controllers, and secrets management integrations.
Metrics export for integration with Prometheus and existing observability stacks.
Rolling builds by default, reducing maintenance windows and enabling more predictable version management.

Real-world applications

Regulated-industry remote access. A financial services organization running a Kubernetes-based application platform can deploy Kasm into the same cluster, using the same operational tooling, to deliver isolated browser and application sessions to analysts and advisors. Sessions are ephemeral, network egress is controlled, and the entire deployment is managed through the same GitOps pipeline as their application workloads.

Contractor and third-party access. Organizations that regularly onboard contractors or external vendors — with the associated privileged access risk — can provision Kasm sessions on Kubernetes that scale up during engagement periods and scale back during low-demand windows. No persistent access. No VPN extension to external parties. Containerized isolation at every session boundary.

AI/ML development environments. Teams building and running AI models need GPU-enabled development environments with security controls that general-purpose cloud desktops rarely provide. Deploying Kasm on Kubernetes with NVIDIA MiG Multi-Instance GPU support lets platform teams deliver fractional GPU resources into isolated workspace sessions — giving data scientists the compute they need without shared-infrastructure security exposure.

The operational shift

The practical implication of a Kubernetes-native workspace platform is that platform teams can stop treating workspace infrastructure as a special case. The same engineers who deploy applications can deploy the workspace platform. The same pipelines that manage application configuration can manage workspace configuration. The same dashboards that monitor application health can monitor workspace health.

That operational consolidation reduces overhead, improves consistency, and eliminates the context-switching cost that has made desktop infrastructure a persistent pain point for cloud-native organizations.

For organizations still running legacy VDI alongside modern cloud infrastructure, the question is no longer whether a Kubernetes-native alternative exists. It does. The question is when to make the transition.

Organizations interested in evaluating Kubernetes-native workspace delivery can explore the platform at kasm.com and try out community edition for yourself.

Daniel Ben-Chitrit is the Chief Product Officer at Kasm Technologies.

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

What is generative AI? How artificial intelligence creates content

Mon, 13 Jul 2026 17:04:40 +0200

Generative AI is a kind of artificial intelligence that creates new content, including text, images, audio, and video, based on patterns it has learned from existing data.

Today’s generative models are typically built on foundation-model architectures such as large-language models (LLMs) and multimodal systems, enabling them to carry on conversations, answer questions, write stories, generate code, and produce images or videos from brief prompts.

Generative AI is different from discriminative AI, which draws distinctions between different kinds of input. Where discriminative AI answers questions like “Is this image of a rabbit or a lion?”, generative AI instead responds to prompts such as “Describe to me how a rabbit and lion look different from one another” or “Draw me a picture of a lion and a rabbit sitting next to each other” — and in both cases produces text or imagery that, while grounded in the AI’s training data, isn’t just a copy of something that already existed.

Just a few years ago, generative AI was once a novelty focused on chatbots and artistic image generation. Today, it has become a core enterprise technology, and powers everything from content creation and software development to customer support and analytics workflows. But with that power comes a new set of challenges — from model alignment and hallucination to governance and data-integration hurdles.

In this article, we’ll look at how generative AI works, explore how it has evolved into the foundation-model era, examine how to implement it effectively, and offer best practices for getting value out of it, today and in the future.

How does generative AI work?

For decades, early artificial-intelligence efforts often focused on rule-based systems or narrowly trained models that were built for one task at a time. While these efforts produced useful systems that could reason and solve human tasks, they were generally a far cry from sci-fi visions of thinking machines. Programs that could talk to people never seemed to get very far past the level of ELIZA, a “computer therapist” created at MIT in the mid 1960s; even Siri and Alexa after much fanfare were revealed to be fairly limited.

The big structural shift that gave birth to modern generative AI came with the concept of a transformer, first introduced in “Attention Is All You Need,” a 2017 paper from Google researchers.

Using a transformer architecture as a basis, you can build a system that derives meaning from analyzing long sequences of input tokens (words, sub-words, bytes) to understand how different tokens might be related to one another, then determines how likely any given token is to come next in a sequence, given the others. In AI lingo, we call these systems models. Because a model analyzes very large datasets and parameter counts, it can pick up on statistical patterns and knowledge implicitly embedded in the data.

This is all easier said than done. The process of adjusting a model’s internal parameters so it gets better at predicting the next token in sequences is called training. During training, the model repeatedly guesses the next token in a given sequence, compares its prediction to the actual one, measures the error, and updates its parameters to reduce that error across billions of examples. Over time, that process teaches the model the statistical relationships that will allow it to generate coherent language (or code, or images) later.

What is a foundation model?

You’ll often hear the word large used for transformer-based models of these types, like the LLMs we mentioned earlier. Large in this context refers to the large number of internal numerical values that the model adjusts during training to represent what it has learned, along with breadth and diversity of data used to train the model and the underlying compute resources powering this whole process.

This is in contrast with the narrow models of the earlier era of AI/ML, which werebuilt for one purpose and trained on a limited dataset. For instance, a spam filter may be very good at what it does, but it’s only trained on email data and all it can do is classify emails. Large models, by contrast, serve as what’s known as foundation models. They’re trained broadly on diverse data (text, code, images, or multimodal data) and then adapted or specialized for many downstream tasks.

These foundation models are the basis for most of the popular generative AI tools and services on the market today. They can be specialized in several ways:

Fine-tuning: Giving a foundation model further training on a smaller, task-specific dataset
Retrieval-augmented generation (RAG): Giving the model the ability to pull in external knowledge when asked a question
Prompt engineering: Tailoring a query so the model gives the sort of answers you’re looking for.

How do AI systems write computer code?

One of the surprising discoveries of the gen AI era was that in recent years was that foundation models trained on natural-language text can also, when fine-tuned with code examples, also write computer code — often better than many purpose-built systems. Still, it makes sense, when you think about it — after all, high-level computer languages are designed by humans and ultimately based on human language.

This 2023 InfoWorld article highlights how models like PaLM, LLaMA and other transformer-based systems fine-tuned on code repositories propelled this shift, but since AI giants like OpenAI have moved into this space. This all matters because code generation (or code-assisted productivity) has become a key enterprise use case of generative AI — perhaps the key use, given the industry’s enthusiastic adoption of it.

What are AI agents?

So far, we’ve been talking about chatbots, writing assistants, image-generation tools. They respond to prompts, output text or images, and then stop. A new category of tool called agentic AI goes further: it plans, executes, and in many cases learns as it works.

Because large models already understand language, code, and even structured data to some extent, they can be repurposed to generate not only descriptive text but operational instructions. For example: an agent might parse the intent “generate a sales-report”, then format internal calls like getData(salesDB, region=NA, period=lastQuarter), and then call an API, all by generating text that’s interpreted as instructions. The MCP framework standardizes the “language” of those instructions and the plug-points into tools and data so that the model doesn’t need bespoke integrations for each new workflow.

These kinds of autonomous agents have several enterprise use cases:

Software automation: Agents that generate code, call unit tests, deploy builds, monitor logs and even roll back changes autonomously.
Customer support: Instead of simply drafting responses, agents interact with CRM APIs, update ticket statuses, escalate issues, and trigger follow-up workflows.
IT operations/AIOps: Agents monitor infrastructure, identify anomalies, open/close tickets, or auto-remediate based on defined rules and context from logs.
Security: Agents may detect threats, initiate alerts, isolate compromised systems, or even attempt to manage threat containment — though this raises new risks.

How can you implement generative AI in the enterprise?

We’ve now touched on what generative AI can do. But how can you make it work reliably in your business. The difference between a pilot and full-scale deployment often comes down to systems, structure and governance as much as to models themselves. InfoWorld’s Matt Asay offers a deep dive into enterprise gen AI essentials, but here are some important points to keep in mind:

Choosing between API, open-source or custom fine-tuned models. One of the first major decisions for any enterprise project is: do you use a model via an API (e.g., from a vendor like OpenAI or Anthropic), deploy an open-source model internally, or build/fine-tune a custom model yourself? Each has trade-offs.

APIs offer speed and minimal setup, but may expose data, limit customization or accrue high cost — and will leave you at the mercy of your vendor. Open source allows internal control and may ease fine-tuning, but requires infrastructure, expertise, and support. Custom fine-tuning gives you the tightest alignment to your use-case, but lengthens time to value and increases risk.

Governance, data privacy and compliance. Deploying generative AI in an enterprise setting raises new governance, privacy and regulatory issues. For example: Who owns the data that’s ingested? How is proprietary data protected if you call a third-party API? What traceability exists for model outputs—a huge question for regulated industries? One useful framework is covered in “A GRC framework for securing generative AI” Data governance must adapt for the new era, and new frameworks are evolving to help.

Human-in-the-loop review. Even the best models make mistakes and cannot simply be put on autopilot. You need a human-in-the-loop (HITL) process: real people need to review outputs, validate for bias, approve high-stakes content, and tune prompts or models based on feedback. Incorporating HITL checkpoints helps mitigate risk and improve overall quality.

Integration with existing systems and RAG pipelines. Retrieval-augmented generation, which we touched on earlier, connects foundation models into business workflows, systems, and enterprise data stores. RAG can bind LLMs to your organization’s internal knowledge bases, thereby reducing hallucinations (which we’ll discuss in a moment) and increasing the relevance of gen AI output.

What causes AI hallucinations?

Probably the biggest limitation of generative AI is what those in the industry call hallucinations, which is a perhaps misleading term for output that is, by the standards of humans who use it, false or incorrect.

Every generative AI system, no matter how advanced, is built around prediction. Remember, a model doesn’t truly know facts—it looks at a series of tokens, then calculates, based on analysis of its underlying training data, what token is most likely to come next. This is what makes the output fluent and human-like, but if its prediction is wrong, that will be perceived as a hallucination.

Generative AI, foundation models, agentic AI, governance, and implementation strategy top the list of top generative AI takeaways.

Foundry

Because the model doesn’t distinguish between something that’s known to be true and something likely to follow on from the input text it’s been given, hallucinations are a direct side effect of the statistical process that powers generative AI. And don’t forget that we’re often pushing AI models to come up with answers to questions that we, who also have access to that data, can’t answer ourselves.

In text models, hallucinations might mean inventing quotes, fabricating references, or misrepresenting a technical process. In code or data analysis, it can produce syntactically correct but logically wrong results. Even RAG pipelines, which provide real data context to models, only reduce hallucination—they don’t eliminate it. Enterprises using generative AI need review layers, validation pipelines, and human oversight to prevent these failures from spreading into production systems.

What are some other problems with generative AI?

Generative AI has proven to be such a disruptive technology that’s stoking near-apocalyptic fears that it will result in a superintelligence that will enslave or destroy humanity. Meanwhile, in the present day, increasingly troubling reports of so-called AI psychosis are emerging, where people have mental health episodes triggered by the uncanny and sometimes sycophantic ways chatbots affirm whatever you talk to them about and try to keep the conversation going.

Compared to such existential questions, the following business-related problems may seem petty. But they’re real issues for enterprises considering investing in AI tools.

Data leakage and regulatory risk. When a model is fine-tuned or prompted with sensitive information, that data may be memorized and unintentionally reproduced. Using third-party APIs without strict controls can expose proprietary or personally identifiable information (PII). Regulatory frameworks like GDPR and HIPAA require explicit governance around where training data resides and how inference results are stored.
Prompt injection occurs when an attacker manipulates a model’s instructions—embedding hidden directives or malicious payloads in user input or external content the model reads. This can override safety rules, expose internal data, or execute unintended actions in agentic systems. Guardrails that sanitize inputs, restrict tool-calling permissions, and validate outputs are becoming essential.
Copyright and content ownership. Many foundation models are trained on data scraped from the public internet, creating disputes over copyright and data provenance. Enterprises using generated output commercially need to confirm usage rights and review indemnity terms from vendors.
Unrealistic productivity expectations. Finally, organizations sometimes expect generative AI to deliver instant productivity gains. The reality, it turns out, is more mixed. Enterprise adoption requires infrastructure, governance, retraining, and cultural change. The models accelerate work once properly integrated, but they don’t automatically replace human judgment or oversight.

The current generation of enterprise AI systems includes several layers of defense against these risks:

Guardrails that constrain model behavior and filter unsafe outputs.
Model validation frameworks that measure factual accuracy and consistency before deployment.
Policy layers that enforce compliance rules, redact sensitive data, and log model actions.

These safeguards reduce—but don’t remove—the inherent uncertainty that defines generative AI.

GenAI: essential for the enterprise

Generative AI has evolved from a novelty into a core layer of enterprise technology. Foundation models and agentic systems now power automation, analytics, and creative workflows — but they remain fundamentally probabilistic tools. Their strength lies in scale and adaptability, not perfect understanding.

For organizations, success depends less on chasing model breakthroughs than on integrating these systems responsibly: building guardrails, maintaining oversight, and aligning them with real business needs. Used wisely, generative AI can amplify human capability rather than replace it.

What is devops? Bringing dev and ops together to build better software

Mon, 13 Jul 2026 17:04:38 +0200

A portmanteau of “development” and “operations,” devops emerged as a way of bringing together two previously separate groups responsible for the building and deploying of software.

In the old world, developers (devs) typically wrote code before throwing it over to the system administrators (operations, or ops) to deploy and integrate that code. But as the industry shifted towards agile development and cloud-native computing, many organizations reoriented around modern, cloud-native practices in the pursuit of faster, better releases.

This required a new way to perform these key functions in a more streamlined, efficient, and cohesive way, one where the old frustrations of disconnected dev and ops functions would be eliminated. With two groups working together, developers can rapidly roll out small code enhancements via continuous integration and delivery rather than spending years on “big bang” product releases.

Devops was born at cloud-native companies like Facebook, Netflix, Spotify, and Amazon; but it’s become one of the defining technology industry trends of the past decade, primarily because it bridges so many of the changes that have shaped modern software development.

As agile development and cloud-native computing have become ubiquitous, devops has enabled the entire industry to speed up its software development cycles. Thus, devops has now thoroughly infiltrated the enterprise, especially in organizations that rely on software to run their business, such as banks, airlines, and retailers. And it’s spawned a host of other “ops” practices, some of which we’ll touch on here.[JF1]

Devops practices

Devops requires a shift in mindset from both sides of the dev and ops divide. Development teams should focus on learning and adopting agile processes, standardizing platforms, and helping drive operational efficiencies. Operations teams must now focus on improving stability and velocity, while also reducing costs by working hand in hand with the developer team.

Broadly speaking, these teams need to all speak a common language and there needs to be a shared goal and understanding of each other’s key skills for devops to thrive.

More specifically, engineers Damon Edwards and John Willis created the CALMS model to bring together what are commonly understood to be the key principles of devops:

Culture: One that embraces agile methodologies and is open to change, constant improvement, and accountability for the end-to-end quality of software.
Automation: Automating away toil is a key goal for any devops team.
Lean: Ensuring the smooth flow of software through key steps as quickly as possible.
Measurement: You can’t improve what you don’t measure. Devops pushes for a culture of constant measurement and feedback that can be used to improve and pivot as required, on the fly.
Sharing: Knowledge sharing across an organization is a key tenet of devops.

“Who could go back to the old way of trying to figure out how to get your laptop environment looking the same as the production environment? All these things make it so clear that there’s a better way to work. I think it’s very tough to turn back once you’ve done things like continuous integration, like continuous delivery. Once you’ve experienced it, it’s really tough to go back to the old way of doing things,” Kim told InfoWorld.

What is a devops engineer?

Naturally, the emergence of devops has spawned a whole new set of job titles, most prominent of which is the catch-all devops engineer.

Generally speaking, this role is the natural evolution of the system administrator — but in a world where developers and ops work in close tandem to deliver better software. This person should have a blend of programming and system administrator skills so that he or she can effectively bridge those two sides of the team.

That bridging of the two sides requires strong social skills more than technical. As Kim put it, “one of the most important skills, abilities, traits needed in these pioneering rebellions — using devops to overthrow the ancient powerful order, who are very happy to do things the way they have for 30 to 40 years — are the cross-functional skills to be able to reach across the table to their business counterparts and help solve problems.”

This person, or team of people, will also have to be a born optimizer, tasked with continually improving the speed and quality of software delivery from the team, be that through better practices, removing bottlenecks, or applying automation to smooth out software delivery.

The good news is that these skills are valuable to the enterprise. Salaries for this set of job titles have risen steadily over the years, with 95% of devops practitioners making more than $75,000 a year in salary in 2020 in the United States. In Europe and the UK, where salaries are lower across the board, 71% made more than $50,000 a year in 2020, up from 67% in 2019.

Key devops tools

While devops is at its heart a cultural shift, a set of tools has emerged to help organizations adopt devops practices.

This stack typically includes infrastructure as code, configuration management, collaboration, version control, continuous integration and delivery (CI/CD), deployment automation, testing, and monitoring tools.

Here are some of the tools/categories that are increasingly relevant in 2025, and what is changing:

CI/CD and delivery automation: Traditional tools like Jenkins remain in many stacks, but newer orchestration tools and CLI-driven or GitOps-centric platforms are growing in importance (e.g. ArgoCD, Flux, Tekton). Also, platforms that integrate more tightly with monitoring, secrets management, drift detection, and policy enforcement are gaining traction.
Security, compliance, and devsecops tooling: Security tools are increasingly integrated into devops pipelines. Expect to see more use of static analysis (SAST), dynamic testing (DAST), dependency and supply chain scanning (SCA), secret management, and policy as code. The push is toward embedding security earlier and bridging gaps between dev, security, and machine learning teams. (InfoWorld:)
AI and automation augmentation: AI-assisted tools are increasingly part of tooling stacks: auto-suggestions in CI/CD, anomaly detection, predictive scaling, intelligent test suite selection, and more. The hope is that these tools will reduce manual interventions and improve reliability. Tools that are “AI ready”—that is, they integrate well with AI or have mature built-in automation or assistance—increasingly stand out from the pack.

Devops challenges

Even as devops becomes more widely adopted, there remain real obstacles that can slow progress or limit impact. One major challenge is the persistent skills gap. The modern devops engineer (or team) is expected to master not just source control, CI/CD, and scripting, but also cloud architecture, infrastructure as code, security best practices, observability, and strong cross-team communication. In many organizations these capabilities are uneven: some teams excel, others lag behind. A 2024 survey showed that while 83% of developers report participating in devops activities, using multiple CI/CD tools was correlated with worse performance — a sign that complexity without deep expertise can backfire.

Toolchain fragmentation and complexity is a related issue. Devops toolchains have sprouted into a sometimes bewildering array of packages and techniques to master: version control, CI build/test, security scanning, artifact management, monitoring, observability, deployment, secret management, and more.

The more tools you have, the more difficult it becomes to integrate them cleanly, manage their versions, ensure compatibility, and avoid duplicated effort. Organizations often get stuck with “tool sprawl” — tools chosen by different teams, legacy systems, or overlapping functionalities — which introduce friction, maintenance burden, and sometimes vulnerabilities.

Finally, although devops has spread far and wide, there is still cultural resistance and alignment. Devops isn’t just about tools and processes; it’s about collaboration, shared responsibility, and continuous feedback. Teams rooted in traditional silos (dev vs ops, or security separate) may resist changes to roles and workflows. Leadership support, communication of shared goals, trust, and allowance for continuous learning are all necessary.

Many CIOs focus too much on tools or implementation first, rather than organizational culture and behaviors; but without addressing culture, even the best tools or processes may not yield the hoped-for velocity, quality, or reliability. Organizations that succeed here tend to have proactive strategies: dedicated training programs, mentorship, internal “guilds,” pairing junior and senior engineers, and making sure leadership supports ongoing learning rather than one-off bootcamps.

Why do devops?

Whoever you ask will tell you that devops is a major culture shift for organizations, so why go through that pain at all?

Devops aims to combine the formerly conflicting aims of developers and system administrators. Under its principles, all software development aims to meet business demands, add functionality, and improve the usability of applications while also ensuring those applications are stable, secure, and reliable. Done right, this improves the velocity and quality of your output, while also improving the lives of those working on these outcomes.

Does devops save money — or add cost?

Devops teams are recognizing that speed and agility are only part of success — unchecked cloud bills and waste undermine long-term sustainability. Waste in devops often comes in the form of “devops debt”— idle cloud capacity, dead code, or false-positive security alerts—which was called a “hidden tax on innovation” in recent Java-environment studies.

Embedding finops practices can help fight these costs. Teams should shift left on cost: estimating costs when spinning up new environments, resizing instances, and scaling down unused resources before they become runaway expenses.

How to start with devops

There are lots of resources for help getting started with devops, including Kim’s own Devops Handbook, or you can enlist the help of external consultants. But you have to be methodical and focus on your people more than on the tools and technology you will eventually use if you want to ensure lasting buy-in across the business.

A proven route to achieving this is a “land and expand” strategy, where a small group starts by mapping key value streams and identifying a single product team or workload for trialing devops practices. If this team is successful in proving the value of the shift, you will likely start to get interest from other teams and from senior leadership.

If you are at the start of your devops journey, however, make sure you are prepared for the disruption a change like this can have on your organization, and keep your eye on the prize of building better, faster, stronger software.

Cloud native explained: How to build scalable, resilient applications

Mon, 13 Jul 2026 17:04:33 +0200

What is cloud native? Cloud native defined

The term “cloud-native computing” encompasses the modern approach to building and running software applications that exploit the flexibility, scalability, and resilience of cloud computing. The phrase is a catch-all that encompasses not just the specific architecture choices and environments used to build applications for the public cloud, but also the software engineering techniques and philosophies used by cloud developers.

The Cloud Native Computing Foundation (CNCF) is an open source organization that hosts many important cloud-related projects and helps set the tone for the world of cloud development. The CNCF offers its own definition of cloud native:

Cloud native practices empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) to meet their organizational needs at scale in a programmatic and repeatable manner. It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.

Cloud native technologies and architectures typically consist of some combination of containers, service meshes, multi-tenancy, microservices, immutable infrastructure, serverless, and declarative APIs — this list is not exhaustive.

This definition is a good start, but as cloud infrastructure becomes ubiquitous, the cloud native world is beginning to spread behind the core of this definition. We’ll explore that evolution as well, and look into the near future of cloud-native computing.

Cloud native architectural principles

Let’s start by exploring the pillars of cloud-native architecture. Many of these technologies and techniques were considered innovative and even revolutionary when they hit the market over the past few decades, but now have become widely accepted across the software development landscape.

Microservices. One of the huge cultural shifts that made cloud-native computing possible was the move from huge, monolithic applications to microservices: small, loosely coupled, and independently deployable components that work together to form a cloud-native application. These microservices can be scaled across cloud environments, though (as we’ll see in a moment) this makes systems more complex.

Containers and orchestration. In could-native architectures, individual microservices are executed inside containers — lightweight, portable virtual execution environments that can run on a variety of servers and cloud platforms. Containers insulate the developers from having to worry about the underlying machines on which their code will execute. That is, all they have to do is write to the container environment.

Getting the containers to run properly and communicate with one another is where the complexity of cloud native computing starts to emerge. Initially, containers were created and managed by relatively simple platforms, the most common of which was Docker. But as cloud-native applications got more complex, container orchestration platforms that augmented Docker’s functionality emerged, such as Kubernetes, which allows you to deploy and manage multi-container applications at scale. Kubernetes is critical to cloud native computing as we know it — it’s worth noting that the CNCF was set up as a spinoff of the Linux Foundation on the same day that Kubernetes 1.0 was announced — and adhering to Kubernetes best practices is an important key to cloud native success.

Open standards and APIs. The fact that containers and cloud platforms are largely defined by open standards and open source technologies is the secret sauce that makes all this modularity and orchestration possible, and standardized and documented APIs offer the means of communication between distributed components of a larger application. In theory, anyway, this standardization means that every component should be able to communicate with other components of an application without knowing about their inner workings, or about the inner workings of the various platform layers on which everything operates.

DevOps, agile methodologies, and infrastructure as code. Because cloud-native applications exist as a series of small, discrete units of functionality, cloud-native teams can build and update them using agile philosophies like DevOps, which promotes rapid, iterative CI/CD development. This enables teams to deliver business value more quickly and more reliably.

The virtualized nature of cloud environments also make them great candidates for infrastructure as code (IaC), a practice in which teams use tools like Terraform, Pulumi, and AWS CloudFormation, to manage infrastructure declaratively and version those declarations just like application code. IaC boosts automation, repeatability, and resilience across environments—all big advantages in the cloud world. IaC also goes hand-in-hand with the concept of immutable infrastructure—the idea that, once deployed, infastructure-level entities like virtual machines, containers, or network appliances don’t change, which makes them easier to manage and secure. IaC stores declarative configuration code in version control, which creates an audit log of any changes.

There’s a lot to love about cloud-native architectures, but there are also several things to be wary of when considering it.

Foundry

How the cloud-native stack is expanding

As cloud-native development becomes the norm, the cloud-native ecosystem is expanding; the CNCF maintains a graphical representation of what it calls the cloud native landscape that hammers home to expansive and bewildering variety of products, services, and open source projects that contribute to (and seek to profit from) to cloud-native computing. And there are a number of areas where new and developing tools are complicating the picture sketched out by the pillars we discussed above.

An expanding Kubernetes ecosystem. Kubernetes is complex, and teams now rely on an entire ecosystem of projects to get the most out of it: Helm for packaging, ArgoCD for GitOps-style deployments, and Kustomize for configuration management. And just as Kubernetes augmented Docker for enterprise-scale deployments. Kubernetes itself has been augmented and expanded by service mesh offerings like Istio and Linkerd, which offer fine-grained traffic control and improved security

Observability needs. The complex and distributed world of cloud-native computing requires in-depth observability to ensure that developers and admins have a handle on what’s happening with their applications. Cloud-native observability uses distributed tracing and aggregated logs to provide deep insight into performance and reliability. Tools like Prometheus, Grafana, Jaeger, and OpenTelemetry support comprehensive, real-time observability across the stack.

Serverless computing. Serverless computing, particularly in its function-as-a-service guise, offers to strip needed compute resources down to their bare minimum, with functions running on service provider clouds using exactly as much as they need and no more. Because these services can be exposed as endpoints via APIs, they are increasingly integrated into distributed applications, operating side-by-side with functionality provided by containerized microservices. Watch out, though: the big FaaS providers (Amazon, Microsoft, and Google) would love to lock you in to their ecosystems.

FinOps. Cloud computing was initially billed as a way to cut costs — no need to pay for an in-house data center that you barely use — but in practice it replaces capex with opex, and sometimes you can run up truly shocking cloud service bills if you aren’t careful. Serverless computing is one way to cut down on those costs, but financial operations, or FinOps, is a more systematic discipline that aims to aligns engineering, finance, and product to optimize cloud spending. FinOps best practices make use of those observability tools to best determine what departments and applications are eating up resources.

How cloud-native architecture is adapting to AI workloads

Enterprises deploy larger AI models and make use of more and more real-time inference services. That’s putting demands on cloud-native systems and forcing them to adapt to remain scalable and reliable.

For instance, organizations are re-engineering cloud environments around GPU-accelerated clusters, low-latency networking, and predictable orchestration. These needs align with established cloud-native patterns: containers package AI services consistently, while Kubernetes provides resilient scheduling and horizontal scale for inference workloads that can spike without warning.

Kubernetes itself is changing to better support AI inference, adding hardware-aware scheduling for GPUs, model-specific autoscaling behavior, and deeper observability into inference pipelines. These enhancements make Kubernetes a more natural platform for serving generative AI workloads.

AI’s resource demands are amplifying traditional cloud-native challenges. Observability becomes more complex as inference paths span GPUs, CPUs, vector databases, and distributed storage. FinOps teams contend with cost volatility from training and inference bursts. And security teams must track new risks around model provenance, data access, and supply-chain integrity.

Application frameworks for building distributed cloud-native apps

Microsoft’s Aspire is one of the most visible examples of a shift towards application frameworks to simplify how teams build distributed systems. Opinionated frameworks like Aspire provide structure, observability, and integration out of the box so developer don’t need to stitch together containers, microservices, and orchestration tooling by hand.

Aspire in particular is a prescriptive framework for cloud-native applications, bundling containerized services, environment configuration, health checks, and observability into a unified development model. Aspire provides defaults for service-to-service communication, configuration, and deployment, along with a built-in dashboard for visibility across distributed components.

While Aspire was originally aligned with Microsoft’s .NET platform,Redmond now sees it as having a polyglot future. This positions Aspire as part of a broader trend: frameworks that help teams build cloud-native, service-oriented systems without being locked into a single language ecosystem. Several other frameworks are gaining traction: Dapr provides a portable runtime that abstracts many of the plumbing tasks in cloud-native distributed applications, and Orleans offers an actor-model-based framework for large-scale systems in the .NET world, and Akka gives JVM teams a mature, reactive toolkit for elastic, resilient services.

Frameworks and tools in the expanding cloud-native ecosystem

While frameworks like Aspire simplify how developers compose and structure distributed applications, most cloud-native systems still depend on a broader ecosystem of platforms and operational tooling. This deeper layer is where much of the complexity—and innovation—of cloud-native computing lives, particularly as Kubernetes continues to serve as the industry’s control plane for modern infrastructure.

Kubernetes provides the core abstractions for deploying and orchestrating containerized workloads at scale. Managed distributions such as Google Kubernetes Engine (GKE), Amazon EKS, Azure AKS, and Red Hat OpenShift build on these primitives with security, lifecycle automation, and enterprise support. Platform vendors are increasingly automating cluster operations—upgrades, scaling, remediation—to reduce the operational burden on engineering teams.

Surrounding Kubernetes is a rapidly expanding ecosystem of complementary frameworks and tools. Service meshes like Istio and Linkerd provide fine-grained traffic management, policy enforcement, and mTLS-based security across microservices. GitOps platforms such as Argo CD and Flux bring declarative, version-controlled deployments to cloud-native environments. Meanwhile, projects like Crossplane turn Kubernetes into a universal control plane for cloud infrastructure, letting teams provision databases, queues, and storage through familiar Kubernetes APIs. These tools illustrate how cloud-native development now spans multiple layers: developer-focused application frameworks like Aspire at the top, and a powerful, evolving Kubernetes ecosystem underneath that keeps modern distributed applications running.

Advantages and challenges for cloud-native development

Cloud native has become so ubiquitous that its advantages are almost taken for granted at this point, but it’s worth reflecting on the beneficial shift the cloud native paradigm represents. Huge, monolithic codebases that saw updates rolled out once every couple of years have been replaced by microservice-based applications that can be improved continuously. Cloud-based deployments, when managed correctly, make better use of compute resources and allow companies to offer their products as SaaS or PaaS services.

But cloud-native deployments come with a number of challenges, too:

Complexity and operational overhead: You’ll have noticed by now that many of the cloud-native tools we’ve discussed, like service meshes and observability tools, are needed to deal with the complexity of cloud-native applications and environments. Individual microservices are deceptively simple, but coordinating them all in a distributed environment is a big lift.
Security: More services executing on more machines, communicating by open APIs, all adds up to a bigger attack surface for hackers. Containers and APIs each have their own special security needs, and a policy engine can be an important tool for imposing a security baseline on a sprawling cloud-native app. DevSecOps, which adds security to DevOps, has become an important cloud-native development practice to try to close these gaps.
Vendor lock-in: This may come as a surprise, since cloud-native is based on open standards and open source. But there are differences in how the big cloud and serverless providers works, and once you’ve written code with one provider in mind, it can be hard to migrate elsewhere.
A persistent skills gap: Cloud-native computing and development may have years under its belt at this point, but the number of developers who are truly skilled in this arena is a smaller portion of the workforce than you’d think. Companies face difficult choices in bridging this skills gap, whether that’s bidding up salaries, working to upskill current workers, or allowing remote work so they can cast a wide net.

Cloud native in the real world

Cloud native computing is often associated with giants like Netflix, Spotify, Uber, and AirBNB, where many of its technologies were pioneered in the early ’10s. But the CNCF’s Case Studies page provides an in-depth look at how cloud native technologies are helping companies. Examples include the following:

A UK-based payment technology company that can switch between data centers and clouds with zero downtime
A software company whose product collects and analyzes data from IoT devices — and can scale up as the number of gadgets grows
A Czech web service company that managed to improve performance while reducing costs by migrating to the cloud

Cloud-native infrastructure’s capability to quickly scale up to large workloads also make it an attractive platform for developing AI/ML applications: another one of those CNCF case studies looks at how IBM uses Kubernetes to train its Watsonx assistant. The big three providers are putting a lot of effort into pitching their platforms as the place for you to develop your own generative AI tools, with offerings like Azure AI Foundry,Google Firebase Studio, and Amazon Bedrock. It seems clear that cloud native technology is ready for what comes next.

Learn more about related cloud-native technologies:

Which AI model should you bet your company on?

Mon, 13 Jul 2026 11:33:26 +0200

Every day this past week I did something I suspect millions of other people also did: I stared at an LLM model picker and wondered which one I was supposed to want.

Perhaps Orosz is right. Perhaps he’ll be wrong again in six weeks. Honestly, it’s exhausting.

A quick survey of my LinkedIn crowd suggests others also feel my “WHICH MODEL???” pain. More importantly, I suspect most enterprises do, too.

A model doesn’t rot

Except, of course, when that noise suggests a serious signal.

Sometimes better really is better

Still, that upgrade isn’t free.

Stop making model bets

Make model releases boring

Hungry? We talk Smoked Meat, Poutine, and Bagel - also, Identiverse Interviews! - John Pritchard, Cassie Christensen, Jaime Lewis-Gross, François Proulx, Kim Brown - ESW #467

Mon, 13 Jul 2026 11:21:15 +0200

Interview with François Proulx from Boost Security

Software Supply Chain Security: Build Pipeline (CI/CD) Exploitation

Boost Security is the creator of some very popular build pipeline security tools, like Bagel and Poutine. Today, we discuss their latest tool, Smoked Meat. They describe it as "Like Metasploit, but for CI/CD pipelines".

Segment Resources:

Smoked Meat announcement
Smoked Meat github
Smoked Meat demo with Guillaume and François

Identiverse Interview with Dr. John Prichard from Radiant Logic

The Three Identity Problem: Surviving Identity Security's Chaotic Era

Identity security has entered its chaotic era. Human, non-human, and agentic AI identities no longer just coexist. They form an uncontrolled inheritance chain in which a human creates an agent, the agent spins up service principals, OAuth grants, and role assignments, and that whole chain keeps running long after the human changes roles or leaves. Most of these chains are being spawned by business users on low-code and enterprise AI platforms, outside traditional identity controls and largely invisible to security.

In this segment, Radiant Logic CEO Dr. John Pritchard joins us to unpack why this is no longer a visibility problem. It is an observability problem. And it is shifting the center of gravity in identity security from authentication to authorization. Listeners will leave with a clearer view of where their current IAM, IGA, and NHI programs fall short, and a practical lens for governing the rapidly expanding population of AI agents already inside their environments.

To go deeper on what John discussed today, watch Radiant Logic's on-demand webinar Identities Under Attack: How Adversaries Exploit the Human-Machine-Agent Divide at https://securityweekly.com/radiantlogicidv.

Identiverse Interview with Cassie Christensen from Saviynt

Everyone Wants an AI Assistant. Few Are Ready to Govern One

Explore a growing reality many professionals can relate to: the appeal of using AI agents to handle the work that keeps piling up - from inbox management to research and logistics - and the governance challenges that quickly follow. The real barrier to scaling personal or enterprise AI agents isn't the technology itself, but defining clear roles, access boundaries, oversight, and lifecycle management. As organizations deploy more autonomous AI agents, the same identity frameworks used to govern workforce and non-employee identities must now evolve to manage AI-driven access before scale and risk outpace control.

This segment is sponsored by Saviynt. Learn more or get a free demo at https://securityweekly.com/saviyntidv

Identiverse Interview with Jaime Lewis-Gross from Saviynt

From Sales Engineer to Forward Deployed Engineer: The Rise of Hybrid Technical Roles

As technology organizations evolve, technical roles are becoming increasingly fluid - particularly at the intersection of product, engineering, and customer success. This conversation explores what it means to be a modern sales engineer and how the role is increasingly expanding into responsibilities often associated with forward deployed engineers: translating complex technical capabilities into real-world outcomes, solving customer challenges in real time, and serving as a critical bridge between product teams and end users. At the center of this evolution is a customer-first mindset - one that prioritizes listening, adaptability, and long-term partnership. As organizations race to innovate, the companies that stand out will be those that remain deeply focused on customer needs while empowering technical teams to operate beyond traditional role boundaries.

This segment is sponsored by Saviynt. Learn more or get a free demo at https://securityweekly.com/saviyntidv

Identiverse Interview with Kim Brown from LexisNexis

Stop Identity Fraud: Modern Strategies for Insurance and Healthcare

Identity fraud is growing more sophisticated across both insurance and healthcare, making identity management a critical line of defense. In this executive interview, Kim Brown, VP of Product Management, will explore how organizations can strengthen identity verification, authentication, and risk assessment to reduce fraud while improving user experiences. The discussion will highlight emerging threats, evolving regulatory expectations, and practical strategies for deploying identity solutions at scale. Attendees will gain actionable insights to protect customers, patients, and their organizations without adding friction.

This segment is sponsored by LexisNexis Risk Solutions. Visit https://securityweekly.com/lexisnexisidv to learn more about them!

Visit https://www.securityweekly.com/esw for all the latest episodes!

Show Notes: https://securityweekly.com/esw-467

Hungry? We talk Smoked Meat, Poutine, and Bagel - also, Identiverse Interviews! - ESW #467

Mon, 13 Jul 2026 11:17:45 +0200

Author: Security Weekly - A CRA Resource - Bewertung: 1x - Views:2

Interview with François Proulx from Boost Security

Software Supply Chain Security: Build Pipeline (CI/CD) Exploitation

Boost Security is the creator of some very popular build pipeline security tools, like Bagel and Poutine. Today, we discuss their latest tool, Smoked Meat. They describe it as "Like Metasploit, but for CI/CD pipelines".

Segment Resources:
- Smoked Meat announcement: https://labs.boostsecurity.io/articles/introducing-smokedmeat
- Smoked Meat github: https://github.com/boostsecurityio/smokedmeat
- Smoked Meat demo: https://www.youtube.com/watch?v=F5Hr_201Au8 with Guillaume and François

Dr. John Prichard from Radiant Logic

The Three Identity Problem: Surviving Identity Security's Chaotic Era

Identity security has entered its chaotic era. Human, non-human, and agentic AI identities no longer just coexist. They form an uncontrolled inheritance chain in which a human creates an agent, the agent spins up service principals, OAuth grants, and role assignments, and that whole chain keeps running long after the human changes roles or leaves. Most of these chains are being spawned by business users on low-code and enterprise AI platforms, outside traditional identity controls and largely invisible to security.

In this segment, Radiant Logic CEO Dr. John Pritchard joins us to unpack why this is no longer a visibility problem. It is an observability problem. And it is shifting the center of gravity in identity security from authentication to authorization. Listeners will leave with a clearer view of where their current IAM, IGA, and NHI programs fall short, and a practical lens for governing the rapidly expanding population of AI agents already inside their environments.

To go deeper on what John discussed today, watch Radiant Logic's on-demand webinar Identities Under Attack: How Adversaries Exploit the Human-Machine-Agent Divide at https://securityweekly.com/radiantlogicidv.

Cassie Christensen from Saviynt

Everyone Wants an AI Assistant. Few Are Ready to Govern One

Explore a growing reality many professionals can relate to: the appeal of using AI agents to handle the work that keeps piling up - from inbox management to research and logistics - and the governance challenges that quickly follow. The real barrier to scaling personal or enterprise AI agents isn’t the technology itself, but defining clear roles, access boundaries, oversight, and lifecycle management. As organizations deploy more autonomous AI agents, the same identity frameworks used to govern workforce and non-employee identities must now evolve to manage AI-driven access before scale and risk outpace control.

This segment is sponsored by Saviynt. Learn more or get a free demo at https://securityweekly.com/saviyntidv

Jaime Lewis-Gross from Saviynt

From Sales Engineer to Forward Deployed Engineer: The Rise of Hybrid Technical Roles

As technology organizations evolve, technical roles are becoming increasingly fluid - particularly at the intersection of product, engineering, and customer success. This conversation explores what it means to be a modern sales engineer and how the role is increasingly expanding into responsibilities often associated with forward deployed engineers: translating complex technical capabilities into real-world outcomes, solving customer challenges in real time, and serving as a critical bridge between product teams and end users. At the center of this evolution is a customer-first mindset - one that prioritizes listening, adaptability, and long-term partnership. As organizations race to innovate, the companies that stand out will be those that remain deeply focused on customer needs while empowering technical teams to operate beyond traditional role boundaries.

This segment is sponsored by Saviynt. Learn more or get a free demo at https://securityweekly.com/saviyntidv

Kim Brown from LexisNexis

Stop Identity Fraud: Modern Strategies for Insurance and Healthcare

Identity fraud is growing more sophisticated across both insurance and healthcare, making identity management a critical line of defense. In this executive interview, Kim Brown, VP of Product Management, will explore how organizations can strengthen identity verification, authentication, and risk assessment to reduce fraud while improving user experiences. The discussion will highlight emerging threats, evolving regulatory expectations, and practical strategies for deploying identity solutions at scale. Attendees will gain actionable insights to protect customers, patients, and their organizations without adding friction.

This segment is sponsored by LexisNexis Risk Solutions. Visit https://securityweekly.com/lexisnexisidv to learn more about them!

Visit https://www.securityweekly.com/esw for all the latest episodes!

Show Notes: https://securityweekly.com/esw-467

Routine maintenance as a failure vector in modern networks

Mon, 13 Jul 2026 11:08:40 +0200

Early in my consulting career, I assumed maintenance windows reduced risk. After all, the purpose of planned maintenance is to improve reliability, apply fixes and prevent future outages. That assumption changed after I participated in what should have been a routine infrastructure change.

Every pre-check passed. Device health looked normal. High-availability synchronization was complete. Monitoring showed no obvious concerns. Yet shortly after the change, users began reporting application failures.

The root cause was not a failed upgrade, hardware fault or software defect. The maintenance activity exposed a dependency elsewhere in the traffic path that nobody had considered.

Since then, I have seen similar patterns repeatedly across enterprise environments. The change itself was rarely the problem. The problem was the assumption that the change was isolated.

Planned maintenance is intended to reduce risk, but in practice, it often introduces risk into an otherwise stable network.

Many production incidents result from routine tasks such as firewall updates, DNS changes, certificate renewals, routing adjustments, load balancer failovers, WAF updates, switch upgrades or software patches, rather than dramatic failures.

The reality is that “routine” does not equate to “low risk.” It simply means the activity has been performed before, not that the current environment will respond the same way.

Modern networks have become too interconnected for maintenance to be treated as a simple device-level task. A change to one control point can expose a dependency elsewhere in the traffic path. A firewall update can affect asymmetric return traffic. A DNS change can shift users to a data center where persistence is not aligned. A load balancer failover can expose stale ARP or MAC learning issues. A certificate renewal can cause an inspection or TLS negotiation to fail in the backend. A WAF update can block application behavior that was never visible in testing.

Failures rarely stem from the maintenance activity itself, but rather from the assumption that the change is isolated.

Why routine changes still cause outages

In traditional network operations, the unit of change was often a device: upgrade a switch, modify a router, add a firewall rule, renew a certificate or reboot an appliance. That model worked better when application traffic paths were simpler, and dependencies were easier to understand.

Today, a single user transaction may cross DNS, global traffic management, WAN routing, data center switching, firewalls, load balancers, TLS inspection points, WAF policies, API gateways and backend application tiers. Each layer may make an independent decision about availability, security, routing or session handling.

This creates a risky maintenance pattern. Teams often validate only the component they changed, not the complete traffic flow before and after the change. Devices may appear healthy, configurations may load correctly and all checks may pass, yet users can still experience failures due to a changed dependency somewhere in the end-to-end path.

Google’s Site Reliability Engineering (SRE) guidance highlights that changes remain one of the most common sources of service disruption, which is why mature organizations invest heavily in change validation, rollback planning and observability. The SRE book provides extensive discussion of change management, reliability engineering and operational risk in large-scale environments.

For this reason, maintenance windows should be evaluated as both operational events and potential failure vectors.

Common failure points during maintenance

One common issue is state mismatch. Firewalls, load balancers, NAT devices and application delivery controllers often maintain connection or session state. During failover, reboot or path change, existing flows may not survive even if the standby device becomes active as designed. New connections may succeed while long-lived sessions fail. In other cases, traffic may enter through one device and return through another, causing stateful inspection to drop packets that appear invalid.

Asymmetric routing is another frequent cause. A routing change may look harmless from a Layer 3 perspective, but if the forward and return paths traverse different firewalls or inspection zones, applications can fail intermittently. The network may still be “up,” but the security policy no longer sees the full conversation.

Layer 2 behavior is also underestimated. In highly available data center designs, MAC learning, ARP cache behavior, VLAN tagging, port channels and first-hop gateway behavior can determine whether traffic moves cleanly after a failover. A device may successfully assume an active role, but upstream switches or firewalls may still forward traffic toward the old path until tables age out or are refreshed.

DNS and GSLB changes introduce a different class of risk. Teams often test name resolution, but resolution is only the first step. The more important question is where users are being sent and whether that destination is ready to handle production traffic.

DNS resilience guidance published by the Internet Society emphasizes that successful name resolution alone does not guarantee application availability, particularly when multiple infrastructure dependencies exist behind the DNS response.

If global traffic management shifts users from one data center to another, the receiving site must have aligned firewall rules, load balancer configuration, health monitors, certificates, persistence behavior, routing advertisements and backend capacity. Otherwise, DNS sends users to a site that is not actually ready.

Certificate maintenance can also break more than the browser-facing endpoint. In many environments, TLS is terminated, re-encrypted, inspected or validated across multiple hops. Renewing a certificate on the external virtual server may not address backend certificates, intermediate chains, SNI behavior, cipher compatibility or trust stores used by inspection devices. The maintenance task may be described as a certificate renewal, but the real dependency is end-to-end TLS negotiation.

Security policy maintenance creates another risk. WAFs, IPSs, DDoS protection systems, bot defense platforms and firewall policies are designed to block abnormal behavior. But during updates, tuning changes or signature refreshes, they can also block legitimate application traffic if policy enforcement is not validated against real transaction patterns.

This is especially true for APIs, where small differences in headers, methods, payload structure or authentication flows can trigger unexpected enforcement.

The test environment problem

Many teams rely on pre-checks and test environments, but these controls are often less effective than they seem.

Pre-checks confirm device reachability, interface status, route existence, pool member availability and HA health. While necessary, these checks do not ensure production traffic will survive a path change because they focus on infrastructure rather than transaction validation.

Test environments rarely mirror production. Production environments involve real user volume, client diversity, DNS caching behavior, firewall states, certificates, backend latency and complex dependencies. A failover that succeeds in a lab may behave very differently in the real world.

This does not render testing useless, but test results should not be considered proof of production safety. They provide evidence, not a guarantee.

This challenge aligns with broader operational resilience guidance from the NIST Cybersecurity Framework, which emphasizes continuous monitoring, validation and recovery planning as critical operational capabilities.

A stronger maintenance process starts with mapping the traffic path before the window. For critical applications, teams should understand the normal ingress path, egress path, firewall zones, NAT points, load balancer virtual servers, DNS or GSLB decision points, TLS termination points, persistence requirements and backend dependencies.

The next step is defining failure expectations. What happens to existing sessions if a firewall is rebooted? Should source MAC, floating IP, ARP or upstream forwarding behavior change during a load balancer failover? How long will cached clients continue to access the old site after a DNS shift? Which clients and inspection devices validate the certificate chain when a certificate is replaced?

These questions should be addressed before the maintenance window, not during an outage.

Pre-checks should include both control-plane and data-plane evidence. Control-plane checks confirm configuration, synchronization, device health, routing tables, interface status and object availability. Data-plane checks validate real traffic movement: TCP handshakes, TLS negotiation, HTTP status codes, API responses, session persistence, source NAT behavior and return-path consistency.

During the change, monitoring should focus on symptoms that expose traffic failure early. Device CPU and interface status are useful, but they are not enough. Teams should also watch connection resets, denied firewall logs, WAF violation spikes, pool member selection failures, DNS answer changes, TCP retransmissions, backend 5xx errors and synthetic transaction results.

Rollback planning must also be precise. Simply rolling back a configuration is often insufficient. If a DNS record changes, cached clients may continue using the previous answer. If a firewall state table is cleared, restoring the rule does not recover active sessions. If failover alters forwarding behavior, upstream devices may require ARP refresh, route reconvergence or manual validation.

An effective rollback plan should identify lost state, persistent caches and the evidence required to confirm recovery.

Treating maintenance as a resilience exercise

The objective is not to make maintenance overly complex or bureaucratic. The objective is to avoid underestimating its risks.

Every maintenance window is a controlled opportunity to test whether the network behaves as specified by the architecture.

If failover is part of the design, maintenance should verify failover behavior. If a secondary data center is expected to handle traffic, maintenance should demonstrate that it can process real transactions. If security policies are updated, maintenance should prove that legitimate traffic is still allowed. If certificates are renewed, maintenance should validate the complete TLS path, not just the public endpoint.

Industry outage studies published by the Uptime Institute consistently show that human error and process failures remain significant contributors to downtime. Their annual outage research continues to highlight the role of operational processes and maintenance activities in service disruptions.

Maintenance windows provide an opportunity to identify those weaknesses before they become customer-facing incidents.

This requires closer collaboration between network, security, application and operations teams. Network engineers may own routing or load-balancing changes, but application teams understand transaction flows. Security teams understand inspection and enforcement behavior. Operations teams often see user-impacting symptoms first.

Treating maintenance as a shared traffic event rather than a device event reduces blind spots.

Routine maintenance will always involve some risk. However, the greatest risk is the false confidence that the term ‘routine’ conveys.

Modern networks fail in the spaces between systems: between DNS and load balancing, between firewalls and routing, between TLS inspection and application behavior, between HA design and actual forwarding state. Maintenance exposes those spaces.

For that reason, network teams should view every maintenance window as more than a checklist. It is a live test of architecture, operational discipline and production resilience.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

What’s new with Google Cloud

Sun, 12 Jul 2026 08:06:50 +0200

Want to know the latest from Google Cloud? Find it here in one handy location. Check back regularly for our newest updates, announcements, resources, events, learning opportunities, and more.

Tip: Not sure where to find what you’re looking for on the Google Cloud blog? Start here: Google Cloud blog 101: Full list of topics, links, and resources.

aside_block

Jul 6 - Jul 10

Webinar: Introducing Google Cloud NGFW Enterprise advanced malware protection - powered by Palo Alto Networks
Discover the new Cloud NGFW advanced malware sandbox, arriving in preview later this year. Powered by Palo Alto Networks Advanced Wildfire, it leverages data from 70,000+ customers to help defeat advanced malware. Join us on July 16 at 11 AM EDT to learn how to build a resilient, zero-trust cloud infrastructure that protects your apps and data, wherever they reside.

Register for the webinar now
Safely run AI-generated code in Cloud Run sandboxes
Cloud Run sandboxes, now in public preview, are lightweight, isolated execution boundaries that you can spawn near-instantly within your existing Cloud Run service instances.

Whether you need to let an LLM run a dynamically generated Python script to calculate business margins or spin up a headless browser to perform web research, Cloud Run sandboxes give you a secure, isolated sandbox to run these tasks without leaving your serverless environment.

Read the blog to learn more and get started today.
Australia API Horizon: Scaling Enterprise Governed AI Agents
The transition from AI chatbots to autonomous agents is the most critical integration point for your business. Join Google Cloud at our upcoming events to explore exclusive deep-dive sessions on architecting for the agentic era.

Discover how to use Apigee as an intelligent AI Gateway to govern, secure, and scale high-performance architectures. You will learn to seamlessly build AI tools from your existing APIs and maintain control over your entire ecosystem.

Join us in your preferred city:
Build highly available, multi-region services on Cloud Run
Maintaining uptime for business-critical applications just got a lot easier on Cloud Run. Service health, now Generally Available, automates cross-region failover by leveraging readiness probes for instance-level health checks with a simple, two-click setup. You can configure service health with global external Application Load Balancers for public-facing applications or cross-region internal Application Load Balancers for private networking traffic.

Learn how to configure service health for Cloud Run.
Report: 83% of organizations need infrastructure upgrades for agentic AI
The shift from conversational bots to autonomous agents is breaking legacy systems. Our new State of AI Infrastructure report details how engineering leaders are adapting to these massive new workloads. To eliminate inference bottlenecks, control hidden scaling costs, and manage agent sprawl, the industry is rapidly moving toward fluid compute, centralized governance, and unified, co-designed architectures.

Explore our key infrastructure insights
Stop tinkering, start scaling: the industrialized AI Playbook
Did you know that only 5% of custom AI investments actually return measurable business value? The problem isn’t the technology—it’s how organizations are wired to run it.

In this compelling read, Google Cloud Consulting breaks down the operational blueprint that bridges the stark gap between "cool tech experiments" and real, P&L-impacting enterprise ROI.

Read the full article on Medium
AI Agent Clinic: Slashing App Latency by 80%
Prototyping an AI agent is easy, but scaling for live traffic presents unique challenges. In the latest AI Agent Clinic, our technical experts partner with a developer to optimize PlaybackIQ, a live football analysis agent. This session demonstrates how to use OpenTelemetry to trace bottlenecks in the Gemini Enterprise Agent Platform and deploy to Cloud Run for high-concurrency scaling, achieving an 80% reduction in response time. Learn production-grade debugging strategies to optimize your own LLM applications.

Watch the 60-minute teardown

Jun 29 - Jul 3

Claude Sonnet 5, Anthropic’s latest model, is now available on Agent Platform.
This addition serves as a drop-in replacement for Sonnet 4.6, giving organizations expanded choice for task completion across enterprise workflows. It features enhanced reasoning, cleaner code generation, and computer use capabilities for desktop and browser workflows.

By continuing to rapidly bring frontier models to our platform, Google Cloud offers an uncompromised choice of the industry's best technology to build, test, and scale enterprise-grade AI.

Get started today.
Automate your AI governance with Apigee and YAML
Manual API gateway configurations can quickly slow down your AI engineering velocity. Join the Apigee community on Thursday, July 16, to discover an automated, declarative blueprint for model garden management. Learn how a simple, repeatable YAML pattern lets your AI practitioners instantly spin up secure, policy-backed enterprise configurations without friction. Bring your questions and connect during our live Q&A session.

Register for the July 16 Community TechTalk
Build next-generation AI portals for autonomous agents
Standard developer portals were designed for human developers to subscribe to static APIs. Today, autonomous agents, LLM toolkits, and dynamic runtimes demand a central nervous system for governance. Join our technical deep dive on Thursday, July 23, to explore Apigee's new AI Portals solution. You will see exactly how to deploy full-service, MCP powered hubs to safely manage enterprise self-service for models, tools, and agents.

Register for the July 23 Community TechTalk
Protect your infrastructure from advanced cyberattacks at the API layer (Presented in Portuguese)
In an era of increasingly sophisticated threats, relying solely on traditional firewalls leaves critical data gaps. Join our technical community TechTalk on Thursday, July 30—conducted in Portuguese—to learn how to proactively mitigate risks directly at the gateway layer. This session demonstrates how to configure and govern essential Apigee security policies to build a robust line of defense, ensuring maximum availability and complete integrity for your enterprise microservices.

Register for the July 30 Portuguese Community TechTalk

Jun 22 - Jun 26

Accelerate TPU model loading while saving RAM on GKE.
Large model cold starts often stall scaling and leave high-value TPUs idle. The open-source Run:ai Model Streamer now natively supports TPUs with Google Cloud Storage in TPU vLLM 0.18.0. This integration accelerates inference pipelines on GKE by streaming tensors directly into CPU memory, bypassing local disk bottlenecks and the "double-buffering" trap. In benchmarks, loading a 480B parameter model was over 2x faster while cutting peak host memory usage by half. Read the full guide and get started today.
Stop Training Blind: Scaling AI with the New OpenTelemetry-Based TPU AI Telemetry Collector Agent
Google Cloud’s new AI Telemetry Collector agent standardizes TPU monitoring using OpenTelemetry. It optimizes enterprise ML workloads by identifying silent failures and providing zero-cost operational metrics without draining host CPU cycles. The agent seamlessly routes telemetry to Google Cloud Monitoring or Prometheus and custom Grafana setups. Pre-installed on Google-optimized Ubuntu images or available via Docker, it tracks memory, network latency, and core utilization to maximize multi-node training efficiency.

You can read more of this capability by clicking this link.

Jun 15 - Jun 19

Join us for a deep dive into agentic AI control with AppyThings
Your integrations aren’t failing—they are evolving. When users interact with AI agents, they no longer arrive directly at your site, resulting in experiences stripped of your context, expertise, and intended experience. Join us on Thursday, June 25, for a community tech talk in partnership with AppyThings to learn how to solve this new gateway challenge. We will explore how MTN laid an integration foundation with the Model Context Protocol (MCP) to deliver accurate, consistent experiences. Our technical experts will demonstrate how to leverage Apigee as a centralized tools management solution to govern agent access.

Register for the session
Optimize Spot VM Deployments with Capacity Advisor for Spot, Now in Public Preview
Google Compute Engine has launched Capacity Advisor for Spot to Public Preview, now open to all customers. This tool turns Spot capacity discovery into a data-driven process by providing real-time deployment recommendations to maximize obtainability and minimize preemption risks. Query the Capacity Advisor API for obtainability and minimum estimated uptimes, or use the new Console UI featuring a global availability map, spot price lookups, and historical preemption rate trends to visually find the most cost-efficient compute capacity.

Get started today to start optimizing your Spot VM deployments!
Build a multi-tenant agentic AI system
When scaling generative AI across different business units, your teams need specialized AI agents with unique operational rules and tools. Our new reference architecture helps you build a centralized multi-tenant platform to prevent fragmented silos, eliminate data exposure risks, and maintain unified compliance. Read the guide to design and deploy a multi-tenant agentic AI system in Google Cloud.
How to Configure Gemini Enterprise to Connect to a Custom MCP Server
The Gemini Enterprise MCP Connector was a big announcement at Google Cloud Next because it introduces the ability to connect Gemini Enterprise to MCP servers. This blog post provides a step-by-step guide on how to configure your first Custom MCP Server connector using the Google Maps Ground Lite MCP server as an example. Once you understand this flow, you can configure multiple MCP servers with Gemini Enterprise to bring all the context you need.

Jun 8 - Jun 12

Simplify Multi-Cloud Planning with Cloud Location Finder, now Generally Available
Cloud Location Finder provides up-to-date data on public regions, zones, and Google Distributed Cloud Connected locations across Google Cloud, AWS, Azure, and OCI. You can now programmatically discover locations based on provider, proximity, territory, and carbon footprint to optimize your global infrastructure strategy for performance, compliance, and sustainability.

Get started for free today

Jun 1 - Jun 5

Modeling the physical world with BigQuery Graph
Managing complex supply chains requires more than just spreadsheets; it requires a digital replica of the physical world. In this post, Guru Rangavittal and Candice Chen explore how BigQuery Graph enables organizations to build a digital twin by turning physical assets into an interconnected map of nodes and edges. By moving beyond traditional relational databases, businesses gain real-time clarity into operations—from executing surgical ingredient recalls to analyzing weather-driven logistics risks. Discover how BigQuery Graph transforms reactive firefighting into proactive, precision modeling, allowing you to see critical connections in seconds and future-proof your supply chain.
Apigee for AI: Govern LLMs and MCP Servers (Presented in Spanish)
Learn how to securely transition your AI initiatives from experimental prototypes to enterprise-ready deployments. Join Luis Cuellar on June 18 for a technical deep dive (presented in Spanish) exploring Apigee’s latest AI gateway capabilities. Discover how to centralize governance over Model Context Protocol (MCP) servers, protect Large Language Models (LLMs) with robust API gateway security policies, and manage token-based quotas.

Register for the June 18 Spanish Community TechTalk

May 25 - May 29

Anthropic’s Claude Opus 4.8 is now available on Gemini Enterprise Agent Platform. As we continue to expand our platform's model offerings, this addition gives organizations more options for handling complex, multi-stage enterprise workflows. Claude Opus 4.8 brings strong capabilities in agentic coding, allowing developers to manage extensive refactors and tracking dependencies over extended sessions.
API Horizon Munich July 6, 2026: Orchestrating the Next Era of AI and APIs
Master the orchestration of next-gen AI and digital ecosystems. Join Google Cloud experts and DACH tech leaders on July 6 for an exclusive look at the Apigee roadmap, Agent Management, and Model Context Protocol (MCP). Gain real-world insights and connect with the regional integration community.

Register now
Securing AI Agents: The Extended Agent Gateway Pattern
Learn how to prevent autonomous AI agents from invoking unauthorized APIs. Join Apigee Specialist Joel Gauci on June 4 for a technical deep dive into the Extended Agent Gateway pattern. This session covers enforcing Fine-Grained Authorization (FGA), implementing secure token exchange, and establishing Model Context Protocol (MCP) governance at the API gateway layer to protect enterprise backend services.

Register for the June 4 Community TechTalk
API-to-Agent Security: Exposing REST APIs to Gemini Enterprise via MCP
Connect Gemini Enterprise agents to core data without creating security hazards. Join Google Cloud Specialist Nigel Walters on June 11 to learn how to instantly transform legacy REST APIs into secure Model Context Protocol (MCP) servers. We’ll cover how to safely register tools with Gemini while enforcing gateway-level guardrails like rate limiting and access control policies.

Register for the June 11 Community TechTalk

May 18 - May 22

Chinese Webinar | June 4: AI Command and Control
As AI agents move from experimental pilots to core enterprise functions, governance has become a critical next step. Join Google Cloud on June 4th at 10:00 AM (Beijing Time) to learn how to build a secure AI management layer architecture. We'll explore how to develop governed MCP (Model Context Protocol) endpoints, manage tool access to enterprise data, and leverage robust audit logs to operationalize AI. This session also includes a practical demonstration of these governance frameworks on Google Cloud.

Register here
GCP Announces New Features to Benchmark and Optimize LLMs for On-Device Use Cases
Deploying fine-tuned LLMs from GCP to edge devices like smartphones is complex due to fragmented hardware. Google AI Edge Portal bridges this gap, giving GCP developers the ability to test AI performance on 120+ Android devices, representing the full diversity of high, medium, and low tier smartphones on the market today. This week at I/O, we announced brand new capabilities to benchmark and debug LLM performance across these devices. Sign-up to utilize these new features in private preview today.

May 11 - May 15

Build Your AI & MCP Control Tower for Universal Governance
Master the future of agentic security with Apigee. Join our Community TechTalk on May 21 to discover how Apigee serves as a central "Control Tower" for the Model Context Protocol (MCP). We will explore how new JSON-RPC tool authorization enables fine-grained access policies across your organization, ensuring secure and scalable AI deployments. Whether managing internal tools or external users, learn to govern your agentic ecosystem with absolute precision. This session is designed for global coverage across EMEA and AMER regions.

Register for the May 21 Community TechTalk

Apr 27 - May 1

Master Your Launch: The Apigee Production Go-Live Checklist
Ensure a secure launch with the Apigee production guide. Join Nicola Cardace on May 28 to explore security guardrails, including IAM roles, mTLS configurations, and encrypted KVM migrations. Scheduled at 11 AM EDT / 5 PM CEST to support EMEA and AMER teams, this TechTalk provides the technical roadmap you need to flip the switch with absolute confidence.

Register for the May 28 Community TechTalk
Transforming APIs into Governed Agentic Tools on the Google Cloud Agentic Platform
Turn your APIs into secure, governed agentic tools on the Google Cloud Agentic Platform. Join Specialist Christophe Lalevée on May 7 for a technical deep dive into AI productization. Scheduled at 5 PM CEST / 11 AM EDT to maximize coverage for developers across EMEA and AMER, this session explores the integration and governance frameworks required to scale enterprise-ready AI with confidence.

Register for the May 7 Community TechTalk
Fractional G4 VMs are Generaly Available, providing a highly efficient and cost-effective entry point for AI and graphics workloads. These new configurations, using NVIDIA virtual GPU (vGPU) technology, allow you to leverage the power of the NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs in flexible, smaller increments, so you can right-size your infrastructure to match the specific demands of your applications. By providing more granular access to advanced hardware, fractional G4 VMs let you optimize resource allocation and reduce overhead without sacrificing performance. You can now select from additional GPU slice sizes for your specific needs:
- 1/2 GPU: Ideal for more intensive tasks such as LLM inference, robotics sensor simulation, and high-fidelity 3D rendering.
- 1/4 GPU: Optimized for mainstream workloads, including mid-range creative design, video transcoding, and real-time data visualization.
- 1/8 GPU: Great for lightweight applications such as remote desktops, productivity tools, and entry-level streaming services.
Transitioning AI from a sandbox prototype to an enterprise-grade system is a major hurdle. A monolithic script won't suffice for widespread deployment. To achieve true scale and reliability with Gemini, organizations must adopt service-oriented micro-agent architectures, establish Zero-Trust security, and implement rigorous EvalOps. Master the "Agentic Maturity Ladder" to ensure your AI & Agentic solutions are robust, secure, and ready for the real world.

Watch the deep dive and read the developer blog to learn more.
ML Development in VS Code with Google Cloud Power: Workbench Extension Now Available
Data scientists and developers can now combine the local productivity of VS Code with the scalable infrastructure of Google Cloud. The new Google Cloud Workbench Notebooks extension allows you to connect to and run notebooks on managed cloud environments directly within your local IDE. This integration streamlines the ML lifecycle by eliminating context switching and providing high-performance compute for complex workloads in a familiar interface. As part of our commitment to the developer ecosystem, the extension is fully open-sourced to support community-driven innovation.
- Install from Marketplace: GoogleCloudTools.workbench-notebooks
- Contribute on GitHub: colab-enterprise-vscode

Apr 20 - Apr 24

Announcing the 2026 Google Cloud Partners of the Year
Google Cloud is honored to celebrate the winners of the 2026 Partner of the Year awards! These awards recognize an exceptional group of partners across AI, Security, Infrastructure, and more, who have demonstrated a commitment to customer success. From global system integrators to specialized startups, these winners are leveraging the power of Google Cloud to solve complex challenges and drive digital transformation worldwide. Join us in congratulating these organizations for their innovation, collaboration, and impactful results over the past year.

See the 2026 Partner Award winners

Apr 13 - Apr 17

We're excited to announce the Public Preview of Datastream’s metadata integration with Knowledge Catalog. This is the first step in our vision to provide a centralized, "single pane of glass" for all Datastream assets. The enhancement automatically synchronizes Streams, Connection Profiles, and Private Connections, eliminating data silos. It enhances discoverability, allowing you to search for Datastream assets using the same interface as BigQuery tables. Centralized governance is also provided, making your real-time data estate more transparent and easier to manage.
Upgrading Apigee OPDK to 4.53 with OS Modernization
Modernize your infrastructure using Google’s official, sequential upgrade path. Our Technical expert, Rakesh Talanki outlines how to upgrade Apigee OPDK to v4.53 while migrating to a supported OS (RHEL 8.x/9.x). This guide covers the "build-out" methodology, including multi-data center syncing, to ensure a stable, zero-downtime transition

Read the guide
Cloud Run Worker Pools and CREMA: Powering Serverless AI at Scale
Google Cloud has announced the General Availability of Cloud Run worker pools, a new resource type designed specifically for pull-based, non-HTTP workloads. Unlike traditional Cloud Run services that scale based on request traffic, worker pools provide an "always-on" environment for background tasks like processing message queues or running large-scale AI inference. To support this, Google Cloud also open-sourced the Cloud Run External Metrics Autoscaler (CREMA). Built on KEDA, CREMA enables queue-aware autoscaling for worker pools, allowing them to dynamically scale based on external signals like Pub/Sub backlog or Kafka lag.
Apigee Model Context Protocol (MCP) now Generally Available
Expose enterprise APIs as MCP tools for agentic AI applications with the General Availability of MCP in Apigee. This update allows developers to transform APIs into AI-ready tools using OpenAPI Specifications, removing the need for local MCP servers or additional infrastructure. With managed endpoints and semantic search in API hub, you can now provide AI agents with secure, governed access to enterprise data at scale.

Explore the MCP overview

Apr 6 - Apr 10

Community TechTalk: Powering Retail Agents with ADK, UCP & Apigee X
Move beyond basic chatbots to secure, transactional AI experiences. Join our Community TechTalk on April 16 to learn how Apigee X and Gemini build a "Trust Layer" for AI shopping assistants using UCP standards. We’ll demonstrate how to block prompt injections with Model Armor and implement cost governance via token limits to secure the path from discovery to purchase.

Register for the TechTalk
Implement multimodal capabilities in your AI agents
Explore three new reference architectures for building sophisticated multi-agent AI systems that can process and analyze multimodal data. To analyze disparate multimodal data and produce a high-confidence classification, see Classify multimodal data. To create a fluid conversational AI that processes audio and video streams in real time, see Enable live bidirectional multimodal streaming. To consolidate fragmented multimodal data into a searchable knowledge graph, see Multimodal GraphRAG resource orchestration.
Automate SecOps workflows with an agentic AI system
To accelerate incident response and reduce manual toil for your security team, you need a system that can automate remediation playbooks. Our new reference architecture helps you build an AI agent that orchestrates complex triage and investigation workflows across disparate security tools, such as SIEM, CSPM, and EDR, from a single interface. See the full guide to orchestrate security operations workflows.

Mar 30 - Apr 3

ASEAN Webinar | April 30: Mastering Agentic Governance at Scale with GCP
As AI agents move from experimental pilots to core enterprise functions, governance is the critical next step. Join Google Cloud experts Shilpi Puri & Wely Lau for a webinar on April 30th at 11:00 AM SGT to learn how to architect a secure AI Management layer. We’ll explore developing governed MCP endpoints, managing tool access to enterprise data, and operationalizing AI with robust audit logs. The session includes a live demo of these frameworks in action on Google Cloud.

RSVP here.

Mar 23 - Mar 27

Turn your API sprawl into an agent-ready catalog
As organizations scale, APIs often become scattered across multiple gateways, creating "blind spots" that hinder AI adoption. To solve this, we’ve introduced two new capabilities for Apigee API hub: a new integration with API Gateway to automatically centralize API metadata into a single control plane, and a specification boost add-on (now in public preview). This add-on uses AI to enhance your API documentation with the precise examples and error codes that AI agents need to function reliably.

Read the full blog post to get started.
Webinar | April 16: AI Command & Control
As AI agents move from experimental pilots to core enterprise functions, governance is the critical next step. Join Google Cloud expert Satyam Maloo for a webinar on April 16th at 11:00 AM IST to learn how to architect a secure AI Management layer. We’ll explore developing governed MCP endpoints, managing tool access to enterprise data, and operationalizing AI with robust audit logs. The session includes a live demo of these frameworks in action on Google Cloud.

RSVP here.
Modernizing and Decoupling Event Ingestion with Apigee
In modern cloud-native architectures, decoupling producers from consumers is critical for building resilient systems. While Google Cloud Pub/Sub provides a scalable backbone, exposing it directly to external clients can introduce security and management overhead. This new guide explores how to leverage Apigee as an intelligent HTTP ingestion point. Learn how to handle security, mediation, and traffic control before messages reach your internal bus using the PublishMessage policy or Pub/Sub API.

Read the full guide.

Mar 16 - Mar 20

Gemini-powered Assistant in BigQuery Studio Gets Context-Aware Upgrades
The Gemini-powered assistant in BigQuery Studio has been transformed into a fully context-aware analytics partner, supporting your entire data lifecycle. The new capabilities include intelligent resource discovery, which uses Dataplex Universal Catalog search to find resources across projects and deep dive into metadata using natural language. You can now automate tasks, such as scheduling production-grade queries directly through the chat interface, and instantly troubleshoot long-running or failed jobs with root cause analysis and cost control auditing.

Explore the full range of what the assistant can do.

Mar 9 - Mar 13

Want to use Gemini to develop code and don't know where to start?
This article includes a couple of examples of developing code with Gemini prompts; it identified changes that were needed to be made to get the code working. The article also refers to other examples that are available on github.

Mar 2 - Mar 6

Introducing Gemini 3.1 Flash-Lite, our fastest and most cost-efficient Gemini 3 series model. Built for high-volume developer workloads at scale, 3.1 Flash-Lite delivers high quality for its price and model tier. Gemini 3.1 Flash-Lite can tackle tasks at scale, like high-volume translation and content moderation, where cost is a priority. And it can also handle more complex workloads where more in-depth reasoning is needed, like generating user interfaces and dashboards, creating simulations or following instructions.

Starting today, 3.1 Flash-Lite is rolling out in preview to enterprises via Vertex AI and developers via the Gemini API in Google AI Studio.
TechTalk: Implementing Device Authorization Grant (RFC 8628) for Apigee
Learn how to authorize "headless" devices like Smart TVs or AI agents that lack keyboards and browsers. Join our Community TechTalk on March 19 (5PM CET / 12PM EDT) to go under the hood of Apigee X/Hybrid. We’ll cover the real-world mechanics of state management, polling, and human-in-the-loop security patterns for devices and autonomous agents.

Register for the TechTalk

Feb 23 - Feb 27

Pro-level image generation gets faster and more accessible with Nano Banana 2
Nano Banana 2 is our state-of-the-art image generation and editing model. It delivers Pro-level image generation and editing at the speed you expect from Flash — making the quality, reasoning, and world knowledge you loved about Nano Banana Pro more accessible. Learn more about the model here.

The Intelligent Path to Compliance: Transforming Regulatory QC with Google Cloud
Reducing "Refuse to File" (RTF) risks and submission cycle times is critical for life sciences leaders. Google Cloud’s Regulatory Submission Semantic QC Auditor leverages Gemini and RAG architecture to transform Quality Control from a manual burden into an active, intelligent workflow.

By automating semantic cross-referencing, narrative coherence checks, and dynamic guidance-based auditing, this solution ensures rigorous accuracy and auditability. Operating within a secure GxP-ready environment, it empowers teams to detect subtle inconsistencies and generate remediation plans without sacrificing data privacy.

Learn more.
Stop typing, start interacting! The Gemini Live Agent Challenge is here. Build immersive agents that can help you see, hear, and speak using Gemini and Google Cloud. Compete for your share of $80,000+ in prizes and a trip to Google Cloud Next '26!

Submissions are open from February 16, 2026 to March 16, 2026. Learn more and register at geminiliveagentchallenge.devpost.com

Feb 9 - Feb 13

Introducing Gemini 3.1 Pro on Google Cloud.
3.1 Pro is a noticeably smarter, more capable baseline for complex problem-solving. We’re shipping 3.1 Pro at scale, building upon our goal to help you transform your business for the agentic future. Learn more about the model’s capabilities here. Gemini 3.1 Pro is available starting today in preview in Vertex AI and Gemini Enterprise. Developers can access the model in preview via the Gemini API in Google AI Studio, Android Studio, Google Antigravity, and Gemini CLI.
Automate Storage Compatibility with GKE Dynamic Default Storage Classes
Managing storage across mixed-generation VM clusters in GKE just got easier. With the new Dynamic Default Storage Class, Google Kubernetes Engine automatically selects between Persistent Disk (PD) and Hyperdisk based on a node's specific hardware compatibility. This abstraction eliminates the need for complex scheduling rules and manual pairing, ensuring your volumes "just work" regardless of the underlying infrastructure. By defining both variants in a single class, you reduce operational overhead while maintaining peak performance and cost-efficiency across your entire cluster.

Explore automated disk type selection
Community TechTalk: AI-Powered Apigee Development with strofa.io
Join the Apigee community on February 26 for a deep dive into strofa.io. Guest speaker Denis Kalitviansky will demonstrate how this new AI-powered tool automates and orchestrates Apigee development, from local emulators to large-scale hybrid environments. Discover how to scale your API management and streamline team collaboration using the latest in AI-driven automation.

Register now to reserve your spot.

Jan 26 - Jan 30

Simplify API Governance with Native OpenAPI v3 Support
Eliminate integration debt and accelerate deployment velocity with the General Availability of OpenAPI v3 (OASv3) support for API Gateway and Cloud Endpoints. You no longer need to downgrade modern specifications to OASv2. Instead, you can now define API contracts and enforce critical policies—including telemetry, quotas, and security—using native Google-specific extensions directly within your OASv3 files. This update ensures your APIs are secure by design while remaining fully compatible with the modern developer ecosystem and Google Cloud’s AI services.

Get started with OpenAPI v3 on API Gateway and Cloud Endpoints.

Accelerate API Testing with the New Open Source API Tester
Start validating your APIs with API Tester, a simple, YAML-based Test Driven Development (TDD) framework. Designed for the Apigee community, this tool allows you to write human-readable tests, run them instantly via a web client or CLI, and perform deep unit testing on Apigee proxies. With native support for JSONPath assertions and Apigee shared flows, you can verify everything from payload data to internal variables like proxy.basepath without leaving your terminal.

Explore the API Tester guide and start testing your proxies today.
Secure Sensitive Data with Kubernetes Secrets in Apigee hybrid
Enhance security in Apigee hybrid by accessing Kubernetes Secrets directly within your API proxies. This hybrid-exclusive feature keeps sensitive credentials within your cluster boundary and prevents replication to the management plane. It supports strict separation of duties: operators manage secrets via kubectl, while developers reference them as secure flow variables—ideal for high-compliance and GitOps workflows.

Implement Kubernetes Secrets in your hybrid proxies.
See the Console in a Whole New Light: Dark Mode is Now Generally Available in Google Cloud
Elevate your cloud management workflow with Dark Mode, now generally available in the Google Cloud console. We have delivered a modern, cohesive, and accessible experience reimagined for maximum comfort and productivity—especially during extended working hours and low-light environments. Dark Mode can be enabled automatically based on your operating system's preference, or manually through the Settings -> Appearance menu.

Switch to Dark Mode today to enjoy a modern, comfortable, and productive environment!
Apigee X Networking: PSC or VPC Peering?
Deciding how to connect Apigee X? Watch this video to compare Private Service Connect and VPC Peering. We break down northbound and southbound routing, IP consumption, and how to reach targets on-prem or in the cloud. Learn to simplify your architecture and avoid common networking "gotchas" for a smoother deployment.

Watch the video.

Jan 19 - Jan 23

Bridge the Gap: Excel-to-API Conversion in Apigee Portals
Give your customers more ways to connect! This new article by Tyler Ayers explores how to extend the Apigee Integrated Portal to support direct Excel file uploads. By leveraging SheetJS and custom portal scripts, you can enable users to upload spreadsheets, preview data, and submit it directly to your APIs, all without writing a single line of integration code themselves. It’s a powerful way to simplify onboarding for those who aren't yet API-ready.

Learn how to build it.
Elevate your applications with Firestore’s new advanced query engine
We have fundamentally reimagined Firestore with pipeline operations for Enterprise edition. Experience a powerful new engine featuring over a hundred new query features, index-less queries, new index types, and observability tooling to improve query performance. Seamlessly migrate using built-in tools and leverage Firestore’s existing differentiated serverless foundation, virtually unlimited scale, and industry-leading SLA. Join a community of 600K developers to craft expressive applications that maximize the benefits of rich queryability, real-time listen queries, robust offline caching, and cutting-edge AI-assistive coding integrations.

Learn more about Firestore pipeline operations.

Operate like a Formula 1 team: The new AI operating model

Fri, 10 Jul 2026 11:07:22 +0200

It is lap 47 of 57.

Before the race began, the team had already processed gigabytes of race data, simulations, tire models, weather forecasts, competitor tendencies and scenario plans. But on the pit wall, there is tension.

The race leader’s tires are degrading faster than predicted. A rival has just pitted for fresh tires and is closing the gap by three-tenths of a second per lap. The lead may not hold. In short, the race is not going to plan.

A strategist now has only seconds to synthesize live telemetry, competitor data, weather projections, tire inventory, track position and race simulations into one call that could determine the outcome.

They do not have those seconds because they are simply fast. They have them because the entire system behind the decision was designed that way: the data architecture, simulation models, communication protocols, decision rights, scenario playbooks and feedback loops all work together to compress complexity into a clear decision window.

What if this is not just a racing story? What if it is also a blueprint for how the best enterprises will operate in the AI era?

This builds on a broader shift I’ve described as the intent-driven future of work, where enterprise work begins less with navigating systems and more with expressing outcomes, context and intent.

The AI advantage will not belong to companies with the most tools. It will belong to companies that redesign how work senses, decides, acts and learns.

AI isn’t just a faster engine

The popular story about Formula 1 is usually about speed or the quality of the driver. The fastest car with the most powerful engine with the driver with the quickest reflexes will win. But anyone who follows the sport closely knows that raw speed is only the starting point.

Every car on the track is fast. Speed gets you into the race. It does not guarantee you a win.

The teams that win consistently do so because of the quality of the system surrounding the car. They connect telemetry, simulations, strategy, engineering, pit operations, driver judgment and real-time learning into one high-performance operating model.

Every part of that operating model matters. But the best individual part alone does not win the race.

Enterprise AI strategy is at risk of making the same mistake that would keep an F1 team stuck in the middle of the pack: investing heavily in the engine while underinvesting in the entire race system.

I see enterprising investing in more copilots, more agents, more dashboards, more tools and ultimately more automation.

The AI systems perform their tasks at unprecedented speed. But the business outcomes do not change. In many ways, AI is becoming a new operating system of work not because it replaces every application, but because it changes how intent, context, workflow and execution come together.

That is the gap many organizations are now facing. They have access to powerful AI capabilities, but they have not yet redesigned the operating model around those capabilities. The result is faster individual task execution inside disconnected systems, fragmented workflows and unclear accountability. In fact, a recent McKinsey report found that 88% use AI but two-thirds haven’t scaled it.

The next phase of AI value will not come from simply adding more AI tools. It will come from redesigning how the enterprise senses, decides, acts and learns.

The enterprise has too many disconnected signals

Most enterprises do not suffer from a lack of signals. In fact, they are everywhere across the business.

Customer intent signals, campaign performance data, product usage patterns, sales activity, support interactions, contract information, financial indicators, employee sentiment, security events and operational metrics already exist throughout an organization.

The problem is signal fragmentation.

The average knowledge worker has become the integration layer of the enterprise. They move between CRM, marketing automation, analytics dashboards, spreadsheets, collaboration tools, support systems, workflow platforms and financial reports. Then they manually assemble context that no single system provides.

They do this to answer questions that should take seconds, not hours.

Which customer needs attention?
Which opportunity is at risk?
Which process is slowing down execution?
Which signal should trigger action?
Which decision needs human judgment?

In Formula 1 terms, this would be like a pit crew strategist having to call five different team members to gather tire degradation data, track conditions, competitor lap times, fuel load, weather forecasts and pit stop windows before making a race-defining call.

The data exists. But the latency in accessing, interpreting and acting on it makes it less valuable at the moment of decision.

That is the signal-to-action gap. And closing that gap is one of the most important opportunities in enterprise AI.

The new operating model: Sense, decide, act, learn

The AI-native enterprise needs to operate more like a Formula 1 team: continuously sensing, deciding, acting and learning.

Sense is the foundation. It means connecting the right signals across systems, workflows, customers, employees and operations into a layer that AI can reason across. This is not just reporting on the past. It is creating the ability to understand what is happening now and anticipate what is likely to happen next.
Decide is where AI intelligence and human judgment come together. AI can surface context, detect patterns, model options and recommend actions. Humans bring business judgment, ethical reasoning, organizational context and accountability. The quality of this partnership depends on the quality of the signals and context available to both.
Act is where intelligence turns into execution. The goal is not another recommendation sitting in a dashboard. The goal is a workflow that triggers the right action, with the right controls, at the right time.
Learn is where the operating model becomes a competitive advantage. Every action should generate feedback. Every outcome should improve the next recommendation. Every workflow should become smarter over time.

In Formula 1, every lap creates learning. Tire wear, track temperature, driver feedback, competitor movement and weather changes continuously reshape strategy.

The enterprise needs the same kind of learning loop.

Semantic intelligence is the missing layer

To close the signal-to-action gap, enterprises need more than data integration. They need semantic intelligence.

Semantic intelligence is what helps AI understand enterprise meaning. It connects business language, customer context, workflow relationships, policies, roles, systems and outcomes so AI can reason across the business, not just retrieve information from systems.

A customer health score is not just a number. Its meaning depends on product usage, renewal timing, support history, stakeholder engagement, commercial value, sentiment, implementation milestones and prior interventions.

A delayed workflow is not just a status update. It may signal unclear ownership, missing approvals, poor handoffs, missing context, poor data quality or a decision that needs escalation.

A sales opportunity at risk is not just a CRM field. It may reflect adoption gaps, customer sentiment, usage decline, executive sponsor changes, pricing friction, support issues or service delivery risk.

Without semantic intelligence, AI can summarize what happened. With semantic intelligence, AI can understand what matters, why it matters, who needs to act and what action is most likely to improve the outcome.

This is where enterprise AI value compounds. Foundation models will become broadly available. The model itself will not be the moat. The moat will be enterprise context, semantic intelligence, workflow intelligence, governance and learning loops.

Redesign work before automating it

There is a warning in the Formula 1 analogy that deserves attention: adding more power to a poorly designed system does not make it high performing.

The same is true for enterprise AI. Adding AI to a broken workflow does not fix the workflow. It just compounds the dysfunction.

If the data is fragmented, AI will produce incomplete recommendations confidently. If governance is disconnected from execution, AI can scale risk as quickly as it scales productivity.

The question teams ask shouldn’t be, “Where can we insert AI into this existing process?”

The better question is, “If we were designing this work from scratch, knowing what AI now makes possible, how should it operate?”

This pushes leaders to clarify where work starts, what signals matter, which decisions should be automated, where human judgment is required, what controls must be embedded, how outcomes should be measured and how the system should learn.

This is where CIOs, CTOs and technology leaders have an expanded role. AI transformation is no longer only about deploying technology. It is about redesigning how the enterprise works.

Context becomes the differentiator

In a world where every enterprise can access powerful models, context becomes the differentiator.

The winning organizations will not be the ones with the most AI tools. They will be the ones with the strongest enterprise context and the clearest path from signal to action.

That context includes customer history, product usage, workflow patterns, decision history, business rules, governance standards, risk boundaries, organizational knowledge and outcome feedback.

It also includes knowing what happened after a decision was made. Did the action improve retention? Did it accelerate a deal? Did it reduce cycle time? Did it improve customer experience? Did it create risk? Did it scale?

Without that feedback, AI remains a recommendation layer. With it, AI becomes part of a learning operating model.

This is why the most important AI investments are not always the most visible ones. Data quality, identity, access, governance, workflow integration, observability, semantic models, feedback loops and change management may not sound as exciting as the latest AI agent. But they are what allow AI to create durable enterprise value.

The CIO as architect of the race system

The CIO’s role is evolving from technology operator to architect of the enterprise race system.

That means connecting strategy, workflows, data, platforms, governance, security, talent and execution into an operating model that can move faster without losing control. The CIO’s job is no longer just to provide platforms. It is to design the conditions where intelligence can move safely and effectively through the enterprise with the right context, controls, accountability and feedback loops.

Business teams need the ability to experiment and innovate. But they need to do so within clear standards for data access, identity, security, privacy, model usage, auditability, human oversight and business accountability.

This is the balance every enterprise needs to strike: speed with control.

The future is federated innovation with centralized guardrails. It is an enterprise operating model where more people can create value with AI, but within a trusted architecture that protects the company, the customer and the quality of decisions.

The companies that pull ahead in the next decade will not be the ones that deployed AI first or assembled the largest portfolio of tools.

They will be the ones who built the enterprise equivalent of a winning Formula 1 race system: a connected operating model.

In Formula 1, the gap between the team that wins the championship and the team that finishes fourth is often measured in tenths of a second per lap. Compounded over a race distance, those tenths become decisive.

The same dynamic is emerging in enterprise AI.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

How to teach SRE AI agents to fail safely and earn your team’s trust

Fri, 10 Jul 2026 11:03:12 +0200

Site reliability engineering is entering a new phase. As incidents become faster-moving, more data-rich and more complex, SRE teams are exploring agentic AI to help with alert triage, root cause analysis, runbook execution and mitigation planning. But in production, the question is not whether an agent can act; it is whether people can trust it to act safely, consistently and transparently when the system is under stress.

This blog argues that trust is an engineering outcome, not a marketing promise. Trustworthy agentic SRE systems are built on a foundation of grounded telemetry, explicit safety boundaries, progressive autonomy, auditability and evaluation against real incidents.

Why trust matters

Traditional automation works well when the world is predictable. SRE work is different because incidents are messy, partial and time-sensitive, with ambiguous symptoms, shifting dependencies and business context that rarely fits into a neat playbook. A fluent AI agent that lacks system context can sound convincing while still making dangerous recommendations.

Trust in SRE is earned during failure, not during demos. That means the system must prove it can help during noisy alerts, failed deploys, partial outages and conflicting telemetry, while staying bounded enough that one mistake does not become a major incident. Google’s AI-in-SRE work makes the same point through its emphasis on strict guardrails, progressive authorization and deterministic actuation controls.

Trust pillars

A practical trust model for agentic SRE can be organized into five pillars.

Pillar	What it means	Why it matters
Grounded observability	The agent reasons over correlated metrics, logs, traces, changes, topology and incident history.	SRE decisions often include business context that the agent does not fully see.
Clear guardrails	Permissions, allowlists, approval gates, rollback paths and rate limits constrain action.	Constraints make autonomy usable in production.
Human-in-the-loop design	Humans approve or supervise higher-risk actions.	SRE decisions often include business context that the agent does not fully see .
Explainability	The agent shows evidence, hypotheses, confidence and rationale.	Engineers need to inspect and challenge recommendations.
Real incident evaluation	The agent is scored against historical or replayed incidents.	Trust comes from measured performance, not benchmark theater.

Google’s SRE autonomy model reflects the same progression: From assisted monitoring and investigation to partial autonomy with human approval to higher autonomy only after sustained success and safety proof.

Architecture pattern

A trustworthy agentic SRE system should separate reasoning from actuation. The agent can investigate, summarize, propose and even stage a plan, but the actual execution path should pass through a deterministic safety layer that validates permissions, risk, current production state and blast radius before any change is made.

A strong pattern looks like this:

Alert arrives from monitoring or incident tooling.
Agent gathers context from telemetry, deploy history, ownership and prior incidents.
Agent produces a ranked hypothesis and a candidate remediation plan.
Safety layer checks policy, risk score, current incident state and dry-run outcome.
Human approves low-confidence or high-risk actions.
Actuation layer executes only pre-approved, bounded changes.
The system observes post-action effects and either confirms success or falls back.

Google’s description of AI operator and its mitigation safety verification layer is a useful reference point here: Investigation is not the same as actuation and the two should not share the same trust boundary. That separation reduces blast radius and keeps the system interruptible.

To try out Agentic SRE, StackGen has a community edition where you can see the capabilities of agentic SRE by connecting your Grafana or Datadog.

Guardrails that work

The most effective guardrails are boring in the best possible way. They include least-privilege identity, strict rate limits, dry-run support, explicit approval workflows, action allowlists and hard stop mechanisms for runaway loops. Check out the detailed guide on how SRE trusts AI agents. AWS describes trust in autonomous systems in the same terms: Identity, runtime guardrails, observability and policy enforcement are the backbone of safe autonomy.

For SRE agents, a few guardrails are especially important:

Least privilege identity so the agent only has access to the systems it truly needs.
Dry-run or simulation mode so the likely outcome is known before production state changes.
Circuit breakers and loop detection to stop repeated or runaway tool calls.
Action tiers so low-risk tasks can be automated while high-risk tasks require approval.
Red-button controls so humans can immediately revoke autonomy during a bad incident.

These controls are not signs of immaturity. They are what make autonomy acceptable in high-stakes environments.

Observability for agents

Observability is not just for services; it is for the agent itself. If the agent’s reasoning, tool usage and outcomes are not observable, then debugging it during an incident becomes guesswork. Google explicitly emphasizes exposing reasoning traces and execution traces so that autonomous decisions remain auditable and debuggable.

A good agent observability stack should capture:

Inputs and retrieved context.
Tool calls, parameters and results.
Intermediate hypotheses.
Confidence and uncertainty.
Approvals, denials and overrides.
Final action and outcome.
Post-action verification signals.

This creates the operational memory needed to understand whether the agent helped, harmed or merely added noise. It also supports post-incident review and future training data generation.

Human in the loop

Human-in-the-loop does not mean the agent is weak; it means the system is designed around responsibility. SREs still own the incident, the rollback, the customer impact and the final decision when context is incomplete. The agent should reduce toil and improve speed, not create a false sense of safety.

The best human-in-the-loop model is proportional. Low-risk tasks like summarizing incidents or collecting dashboards can be automated. Medium-risk actions like restarting a worker can require lightweight approval. High-risk actions like draining core capacity or disabling a major dependency should remain human-controlled. This progressive model lets trust grow gradually rather than forcing a dangerous leap to full autonomy.

Evaluation strategy

If you only test an agent on toy benchmarks, you will get toy reliability. Real SRE evaluation should replay historical incidents and score whether the agent identified the right signals, chose the right hypothesis and recommended safe remediation under realistic conditions. Google’s approach uses continuous evaluation pipelines, human-verified gold data and nightly evals against real incident trajectories to measure readiness for autonomous action.

A practical evaluation program should include:

Historical incident replay.
Golden-path and failure-path comparisons.
Tool misuse tests.
Prompt injection and adversarial input tests.
Loop and retry stress tests.
Human review of edge cases.
Regression tracking across model and policy changes.

The key metric is not “did the model sound right?” It is “did the system shorten time to mitigation, reduce toil and avoid new operational risk?”.

Failure modes

Agentic SRE systems fail in ways that classic software often does not. They can hallucinate a root cause, misread telemetry, over-trust stale context, loop on a broken action or optimize the wrong objective while sounding confident. In a high-stakes environment, this is more dangerous than a simple bug because the system can act before humans realize it is wrong.

The main failure modes to design against are:

Confident incompleteness, where the agent lacks key context but still gives a decisive answer.
Runaway loops, where tool calls repeat and consume time or budget.
Unsafe actuation, where a valid-looking action is harmful in the current operational state.
Workflow drift, where the agent bypasses established incident processes.
Hidden fragility, where speed increases but accountability decreases.

Good architecture assumes failure will happen and makes sure the system fails safely, visibly and reversibly.

If you need a more detailed guide to keep points while evaluating AI SRE tools, then check this buyer’s guide by one of the senior leaders.

Operating model

The healthiest way to deploy agentic SRE is to treat it as a bounded operational partner. Start with read-only use cases like alert enrichment, incident summarization and investigation assistance. Then move to recommendation-only workflows, then to low-risk automation and only later to tightly scoped autonomous mitigation.

That staged rollout should be paired with policy, ownership and incident review discipline. Every agent action should map back to a responsible team, a bounded capability and a visible audit trail. This is how the system earns confidence from engineers, security teams and leadership at the same time.

Conclusion

Trustworthy agentic systems for SRE are built, not assumed. The winning formula is grounded telemetry, explicit guardrails, human oversight, explainable reasoning and evaluation against the messy reality of production incidents. When those pieces are in place, AI becomes a reliability multiplier rather than another source of operational risk.

The real goal is not a fully autonomous agent that never makes mistakes. The real goal is an agentic system that stays safe when it does make mistakes, recovers cleanly and keeps SRE teams in control when it matters most.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

“1~2시간 걸리던 장애 분석, 5분이면 끝”…데이터독 ‘비츠 AI’ 전면에

Fri, 10 Jul 2026 07:02:39 +0200

데이터독 코리아는 9일 서울에서 기자간담회를 열고 이 같은 사업 현황과 연례 컨퍼런스 ‘대시(Dash) 2026’에서 공개한 신제품 전략을 소개했다.

엄수창 데이터독 코리아 지사장은 이를 시장 변화의 신호로 해석했다.

엄 지사장은 “연초만 해도 ‘SaaS 아포칼립스’라는 말이 나올 정도로 SaaS 기업들의 미래를 부정적으로 보는 시각이 많았다”며 “하지만 데이터독은 AI와 함께 성장하면서 오히려 큰 미래 비전을 갖게 됐다”고 말했다. 이어 “글로벌 상위 AI 기업 10곳 모두 데이터독을 사용하고 있다는 사실 자체가 시장이 우리의 성장 가능성을 높게 평가하고 있다는 방증”이라고 강조했다.

이 같은 자신감의 배경에는 AI 시대 급증하는 운영 관리 수요가 있다. 과거에는 데브옵스(DevOps)와 SRE(Site Reliability Engineering) 조직이 장애 분석과 인프라 모니터링을 위해 주로 활용했다면, 이제는 AI를 활용해 운영을 자동화하는 기능과 AI 애플리케이션 자체를 관리하는 기능까지 제공하며 AI 시대에 맞춰 사업 영역을 확대하고 있다.

정영석 데이터독 기술총괄은 올해 대시에서 공개한 100여 개의 신기능을 ‘자율 IT 운영(Autonomous Operations)’과 ‘AI 거버넌스’라는 두 가지 축으로 설명했다.

자율 IT 운영 분야에서는 ‘비츠 AI(Bits AI)’가 장애 탐지부터 원인 분석, 해결까지 자동으로 수행한다. 정 총괄은 “장애가 발생하면 비츠 AI가 8가지 안팎의 가설을 세운 뒤 하나씩 검증해 근본 원인을 찾아내고, 코드 수정안까지 PR(Pull Request) 형태로 제안한다”며 “기존에는 엔지니어가 1~2시간 걸리던 분석 및 보고서 작성 작업을 빠르면 5분 이내로 단축할 수 있다”고 설명했다.

또 인프라 자원이 부족하면 슬랙 등을 통해 운영자 승인만 받아 메모리와 CPU를 자동으로 증설하고, 사전에 정의한 가드레일 안에서는 무인 복구도 수행한다. 코드 변경부터 스테이징 배포, 프로덕션 환경에 이르기까지 애플리케이션이 의도대로 동작하는지도 AI가 지속적으로 검증한다.

AI 거버넌스 분야에서는 ▲에이전트 옵저버빌리티(Agent Observability) ▲AI 게이트웨이(AI Gateway) ▲AI 가드(AI Guard) ▲LLM 비용 관리 콘솔 등의 기능 공개했다.

에이전트 옵저버빌리티는 AI 에이전트 내부에서 어떤 LLM과 도구를 사용했고, 토큰과 비용이 얼마나 발생했는지 시각화한다. AI 게이트웨이는 여러 LLM을 통합 관리하고 감사(Audit)를 수행하며, AI 가드는 프롬프트 인젝션과 민감정보 유출을 차단한다.

정 총괄은 “코파일럿, 커서(Cursor), 클로드 등 여러 AI 모델을 함께 사용하는 기업이 늘면서 비용과 보안, 신뢰성을 통제하는 것이 C레벨 경영진의 공통 과제가 됐다”며 “개발자별, 모델별 사용량과 비용을 세분화해 보여주기 때문에 임원들도 최적화 지점을 쉽게 찾을 수 있다”고 말했다.

최근 많은 기업이 멀티 LLM 전략을 채택하는 만큼 이러한 통합 관리 플랫폼의 필요성도 커질 것이라는 설명이다.

CIO 코리아가 AI 기능 추가로 관련 비용이 늘어나는 것 아니냐고 묻자 정 총괄 “데이터독이 제공하는 수백 개의 외부 서비스 연동 기능은 모두 기본 호스트 사용료에 포함돼 있어 AI 기능이 추가됐다고 모니터링 비용이 늘어나는 것은 아니다”며 “다만 로그는 저장량이 늘어나면 비용이 증가하는 구조인데 이는 어느 벤더나 비슷하다”고 답했다.

이어 “AI가 추가됐다고 인프라 모니터링 비용이 올라가는 것은 아니지만 AI SRE처럼 자동 분석 기능을 사용할 경우 토큰(크레딧)이 소모돼 비용이 추가될 수 있다”며 “반면 엔지니어의 업무 시간을 크게 줄일 수 있기 때문에 ROI 측면에서는 충분히 상쇄할 수 있고, UI 대신 MCP(Model Context Protocol)를 활용하면 비용을 낮출 수 있어 국내 여러 대형 고객도 MCP 기반 AI옵스를 구축하고 있다”고 덧붙였다.

AI가 문제 해결책까지 제시하는 것에 대한 고객사의 거부감은 없는지 묻는 질문에는 “잘못 분석할 가능성이 있는 것은 사실이지만 지금까지 고객 반응은 매우 긍정적”이라며 “AI가 잘못 탐지하더라도 사용자가 대화를 통해 추가 분석을 요청하면 계속 수정하면서 근본 원인에 더 가까운 결과를 제시한다”고 설명했다.

이어 “이 경험은 ‘비츠 메모리(Bits Memory)’ 기능에 축적돼 이후 유사한 장애가 발생하면 더욱 정확하게 분석하도록 학습된다”고 말했다.

내부 AI는 자체 모델과 업계 최신 모델을 함께 사용하는 하이브리드 구조다.

정 총괄은 “프론티어 모델과 자체 모델인 ‘토토(Toto)’를 함께 운영하고 있으며 작업 특성에 따라 가장 적합한 모델을 선택해 사용한다”고 밝혔다. 클로드, GPT, 제미나이 등 다양한 외부 최신 모델을 활용하며, AI SRE는 내부적으로 최적 모델이 자동 선택되지만 에이전트 빌더에서는 고객이 MCP와 사용할 모델을 직접 선택할 수 있다. 또한 LLM 옵저버빌리티에서는 환각을 탐지하기 위해 교차 검증용 모델을 별도로 지정하는 기능도 제공한다.

데이터독은 앞으로 옵저버빌리티(Observability), 보안, 핀옵스(FinOps), 비즈니스 인텔리전스(BI)를 하나의 플랫폼에서 통합 제공하는 차별성을 앞세워 국내 시장 공략을 확대하겠다고 밝혔다.
jihyun.lee@foundryco.com

The enterprise AI challenge nobody solves with code generation alone

Thu, 09 Jul 2026 19:02:21 +0200

Presented by SAP

Generating code with AI is fast, but getting that code to run reliably inside a large enterprise, integrated with live systems, governed for compliance, and maintainable over years requires foundational work that most organizations underestimate.

While 81% of all organizations have a detailed strategy, only 12–16% reach AI‑driven execution, says SAP's Michael Ameling, CPO of SAP Business Technology Platform, and the reasons rarely come down to the quality of the generated code.

"Across industries, enterprises that have invested heavily in AI tooling are hitting a wall when generated code meets the reality of their existing environments, because generating code and operationalizing it are not the same problem," Ameling says.

There are specific requirements for deploying AI-generated logic at enterprise scale: what data and integration readiness actually look like, how governance works when AI agents move from producing recommendations to executing workflows, and how development teams are changing their role as AI takes over more of the coding work.

Why AI code generation fails in enterprise production environments

The productivity gains from AI code generation are real and well-documented, but the ease of prototyping has given many organizations a misleading sense of how far along they actually are.

"Generating code is one thing," Ameling says. "Enterprise customers, including multinationals and large organizations, need to ensure there are no compromises in compliance or security. Code that runs reliably for ten or twenty years, as it does at many of SAP's largest customers, also has to be maintained, patched, and understood by whoever inherits it. Life cycle management, in other words, does not generate itself."

The issue is rarely the generation quality. Teams build something compelling, then discover they lack access to the data it depends on, or the integrations it assumes, or the permissions required to run it in a real environment. The problem is essentially that AI amplifies an organization's existing data and process maturity, but it can't substitute for it.

This dynamic intensifies as AI moves from producing code to executing actions. Latency, cost, and system load all increase when logic runs continuously against live data rather than rendering a one-time output. The performance requirements of an autonomous agent operating across a multinational's transaction systems are categorically different from those of a developer copilot.

How to connect AI-generated logic to fragmented enterprise systems

The architecture challenge that most enterprise AI projects underestimate is integration. Real enterprise environments are not clean slates: they combine cloud systems, legacy on-premise infrastructure, fragmented data stores, and dozens of business applications that were never designed to talk to each other. Getting AI-generated logic to operate reliably across all of them requires a layer that unifies data access, process context, and governance, and it has to be in place before any agent starts executing. And organizations that see AI as a reason to defer infrastructure modernization are making a mistake.

"The question is not whether to modernize or not. Of course you need to modernize," Ameling says. "But the value you get on top of this is much higher with AI. Federated data access and harmonized process layers are not alternatives to upgrading a fragmented landscape, they're what make the upgrade worthwhile."

At the platform level, this translates into a set of practical requirements: structured data integration, end-to-end process visibility, and the ability to discover and connect to APIs across both modern and legacy systems. SAP's approach with the Business AI Platform draws on tools including its Joule Studio, Integration Suite, Business Data Cloud, and SAP AI Agent Hub enterprise architecture layer to provide that context. The goal is to give AI-generated logic accurate, current knowledge of what a business is doing and how, rather than just access to raw data.

AI agents handle large challenges by dividing them into smaller, autonomous tasks, with each agent responsible for a specific domain, and all coordinated toward a shared outcome. A financial close, for example, involves dozens of discrete sub-processes. Agents handling each task in parallel, within defined constraints, can compress cycle times dramatically, but only if the underlying systems they interact with are coherent and accessible.

The governance and oversight that AI agents require in production

When AI moves from assistant to operational actor, the governance questions loom large, because agents that trigger workflows, update records, and interact with live business systems need the same accountability framework that applies to human employees, i.e., identities, defined privileges, and auditable behavior.

There are two distinct models:

Principal propagation, where an agent acts on a user’s behalf, inheriting that user’s permissions and scope.

System-triggered agents, where the agent operates under its own identity and role-defined privileges, functioning more like an automated HR role than a personal assistant.

Both models require the same underlying infrastructure: an agent hub where operators can see which agents exist, what APIs they can access, and what they are authorized to do. Observability also needs to be operationalized correctly for AI, combined with both technical and business evals.

"In production, openness is very important," Ameling says. "We use OpenTelemetry as a framework, so we can integrate with other solutions, for end-to-end observability of the tool, third-party agents and the like."

On top of that, standard technical evals, which test whether an agent produces consistent outputs, are necessary but not enough. Business evals assess whether an agent is actually moving the performance indicators it was deployed to improve, but it has to work end-to-end.

Where the testing happens is equally important. The traditional software development cycle across dev, test, and production environments breaks down when a model produces different outputs depending on whether it is running against test data or live data. Getting to trustworthy AI in production means accepting that validation looks fundamentally different from what engineering teams have practiced for decades, with live environment testing, even A/B/C testing to ensure outcomes are reliable.

How AI-driven code generation is changing software engineering roles

The role of the developer is not disappearing in this environment, but its center of gravity is shifting. The productivity multiplier is significant when developers can run multiple coding agents in parallel across open terminals, each working on a separate problem and each taking several minutes to complete. But it introduces a new kind of cognitive demand, because humans have to stay in the loop. That means tracking context across concurrent workstreams, evaluating outputs that range across large codebases, and making architectural judgments that no agent can be trusted to make alone.

"The more specific and complete the prompt, the less intervention is required, and developers are learning that bringing more context upfront pays dividends in reduced back-and-forth," Ameling says. "But the output still needs to be understood, not just accepted."

The competitive edge will remain intellectual property, not tooling. The companies that pull ahead will be those that most effectively encode their domain knowledge into the systems they build.

"A manufacturer's process expertise, a financial institution's risk logic, a logistics firm's routing intelligence, these are the assets that AI can accelerate, but only if the organizations that hold them do the work to make them accessible and usable," Ameling says. "Protect that, and apply AI to accelerate your differentiation."

Three keys to deploying AI agents

Thu, 09 Jul 2026 11:03:34 +0200

Building an agent in an afternoon is now within reach of almost anyone in the enterprise with a credit card. The tools are accessible, the deployments are easy. The hard part is delivering the intended results.

Gartner predicts that more than 40% of agentic AI projects will be canceled by 2027, and the EU AI Act Article 14 requirements for human oversight for high-risk AI systems take effect on August 2, 2026. The deciding factor for whether agentic AI reaches production isn’t the model, the framework, or the use case. It’s the infrastructure beneath the agent: the part the people building agents have never had to think about.

Organizations are racing to deploy agentic AI to stay competitive, which means pressure-testing is often overlooked. Every agent project should be scrutinized by three executives asking three different sets of questions. The CISO asks whether we are exposed. The CFO asks whether we are overspending. The chief AI officer asks whether we are getting value.

As a product leader focused on AI governance, I see this pattern across customer environments. Three architecture layers answer those three questions: identity, observability, and cost optimization. I’ll walk through each of the layers and provide a four-question diagnostic for the next production push.

Why AI pilots stall

An agent is not a faster chatbot. It chains dozens of steps, calls external tools, retains state across sessions, and triggers real-world actions. Most inherit the credentials of whoever deployed them. They operate at machine speed without context for the consequences of each step.

The mismatch is not a competence gap on the human side. It is a time-horizon gap. An engineer reasons about a database change over hours. An agent triggers a hundred of them before anyone reviews the first. Traditional audit logging captures request and response. That does not catch this pattern.

When something breaks, the cost is rarely the incident. It is the months of stalled deployment that follow. The risk committee freezes pilots. The productivity gains the program was supposed to deliver never materialize. Finance still gets the API bill. Three architecture layers decide whether a deployment survives that pattern. Each one is the answer to a question the people building agents never had to ask.

Layer 1: Identity for non-human actors

Start with identity. The default failure looks routine: a product manager with broad API access spawns an agent that inherits the full scope of those credentials and runs at machine speed across systems no one inventoried.

The scale is bigger than most teams realize. Industry IAM research puts non-human identities at more than 100 to 1 versus human accounts, with some 2026 surveys putting the ratio as high as 144 to 1. A May 2026 Identity Gap Report found two-thirds are unseen and unmanaged.

Agents are moving from human identities with their “owners”’ permissions to first-class principals. They are purpose-bound, cryptographically attested, and scoped to one task at a time. Google’s Agent Identity, built on SPIFFE, is one early example. The production pattern has three properties. Credentials are issued per agent task. Token lifetime is measured in minutes to hours, not weeks. Scope is narrowed to the specific tools and data classes the task requires, and the credential revokes automatically on task completion.

If a single static credential is good for a week and 50 different tasks, you are not running agentic AI. You are running a service account with extra steps.

Layer 2: Observability that serves all three executives

Identity controls what an agent can do. Observability shows what it’s actually doing. One instrumentation layer, three views.

First, the security view. Traditional logging captures request and response, which assumes one human action per logged event. An agent’s unit of work is a chain. Pick a tool, call it, read the result, decide the next step. Twenty steps, some of them writing to production. Instrument every step as a durable audit object, independently queryable. Understand which tool was invoked, what data was accessed, what policy applied, and what the agent reasoned to justify the next step. That’s what Article 14 oversight requires for production.

Second, the business-outcomes view. Audit objects answer the CISO. The chief AI officer asks a different question. Is the agent accomplishing what we deployed it for, or burning compute on a tangent? An agent can run 200 tool calls, generate clean audit logs, and produce nothing. It might be looping on a sub-goal that drifted three steps back. Observe each step against the declared business purpose: on-task ratio, sub-goal coherence, progress markers. Project management telemetry for a non-human worker.

Third, the cost view. The same per-step instrumentation produces cost telemetry: token count per step, model per call, context size per turn, downstream tool-call costs. Without that attribution, the next section’s optimizations are blind.

A busy agent and a productive agent look identical in the security log. They look identical on the bill too. The difference shows up only when all three views run from the same instrumentation.

Layer 3: Cost optimization

Cost is where the architecture pays back. Gartner’s March 2026 analysis put agentic workloads at five to 30 times the token cost per task of a standard chatbot. The FinOps Foundation’s 2026 State of FinOps report found that 73% of organizations exceeded their original AI budget projections. Three failure modes drive that overrun.

First, using the wrong model. Agents default to the most capable one available. They call a frontier model for tasks a smaller one could handle with identical quality: summarizing a transcript, formatting JSON, classifying a ticket. The RouteLLM paper at ICLR 2025 demonstrated that intelligent routing cuts total LLM inference cost 40% to 80% with no measurable quality loss on routine work. Move model selection from a per-developer choice to a per-policy layer.

Second, running in loops. Agents can spend without limit if no one is watching. A widely-cited 2026 incident saw a LangChain multi-agent system run an infinite loop for 11 days and burn $47,000 in API charges. Per-session token ceilings, loop-detection circuit breakers that flag tool calls highly similar to prior calls, and hard daily caps stop this before it generates the bill. In our deployments, a three-tier cost structure catches the bulk of runaway patterns: a $50 daily soft alert, a $100 daily hard cutoff forcing routing to cheaper models, and a $1,000 monthly ceiling requiring manager approval.

Third, re-paying for the same context on every step. Every step re-sends the accumulated system prompt and conversation history. By step 20 the agent has paid for that context 20 times. Vantage’s 2026 analysis of agentic coding sessions found re-sent context accounts for roughly 62% of the average agent’s bill, the biggest single optimization target in agentic workloads. Three patterns help: anchored summarization at phase boundaries, sliding context windows, and provider-native prompt caching at the gateway. Most agents skip caching entirely, though Anthropic prices cached input at roughly 10% of base, Gemini at 10% to 25%, and OpenAI at 50%.

Governing agent cost means seeing every call, every model, every token attributed to the agent and the business purpose. Then act on it. Token counts without business attribution tell you how many gallons of gas you burned, not where you drove.

The deployment velocity payoff

The three layers serve the three executive questions. Identity gates what the agent can do. Observability shows what it is doing. Cost optimization controls what it spends.

The honest counterargument is that governance always slows deployment. That is true when governance is bolted on as approval gates layered over an agent that wasn’t built with observability or per-task identity. It is false when governance is built into the architecture from day one. Teams that experience governance as a brake installed the brake without the steering wheel.

Governance built right still costs something. Per-task credentials add work on every tool call. Observability infrastructure adds compute. The question is whether that cost beats the alternative.

The layers compound. Identity without observability is theoretical. Observability without cost control is descriptive. Without identity at the bottom, cost control becomes caps without context, forever reactive. All three together produce a governance review that runs in weeks, not quarters, because the data each executive needs already exists. In our experience, organizations with that infrastructure can deploy six workflows to production in the time competitors complete one governance review. The real ROI of agentic AI is not how much faster a single workflow runs. In practice, it’s how many workflows your team can defensibly put into production in a year.

Before the next pilot

Here are four questions to run against any agent your team is about to push to production:

Identity. For each agent in production, can you point to the per-task credentials it uses today, and the maximum scope of any single token?
Observability. For any agent session, can you produce three views from the same instrumentation: the audit object per step, the on-task ratio versus tangents, and the per-step cost broken down by model and context size?
Cost optimization. Does your platform automatically route by model, cap runaway loops, and avoid re-sending the same context every step?
Velocity. How long does it take a new agent workflow to move from approved pilot to production in your environment today?

If the answer is months, the architecture above is the gap. Gartner’s 40% stat is about your next pilot.

—

Practical challenges in managing Kubernetes at enterprise scale

Thu, 09 Jul 2026 11:03:31 +0200

The first time I used Kubernetes in an enterprise setting, I understood the hype. It gives every team the same way to package, deploy and run their apps. No more custom scripts or unique deployment hacks, just one control plane to rule them all. And really, that’s why it’s so popular with big companies: Kubernetes is an open-source system for automating deployment, scaling and management of containerized applications. It says so right on the box, and that’s what people want. But here’s the truth: Kubernetes doesn’t erase operational headaches. It just moves them around.

When your Kubernetes install is small, it feels like rocket fuel for engineers. At enterprise scale, though, suddenly it’s about governance, not just engineering. The game is no longer “Can we get this container running?” It’s “How do hundreds of engineers roll out their stuff safely, consistently, securely and without breaking the bank or burning out the platform team?”

This is where the fun really starts.

YAML isn’t the enemy

Folks new to Kubernetes obsesses over manifests, Helm charts, namespaces, ingress rules, deployments, all that stuff. But they’re not the hardest part once you start scaling. The real beast is standardization.

Every big company I’ve seen ends up with teams going their own way. One group writes beautiful deployment templates. Someone else copies and pastes from a two-year-old manifest. Some folks set resource requirements properly. Others skip them entirely. One team sticks to a strong naming convention, and someone else throws together random namespaces and service accounts that make sense only to them. Individually, this more or less works. At scale, when the whole platform has to operate like one system, it’s a mess.

That’s why I’ll say it: you don’t just need a Kubernetes cluster. You need a paved road. This would involve ensuring that there are approved templates, good deployment patterns, observability, security controls as defaults, good issue escalation processes and accountability.

There is no need for developers to be Kubernetes experts just to release their services. The best enterprise Kubernetes setups work like real products. They let application teams self-serve but never let anyone veer off road without good reason.

RBAC: necessary, but never enough

Security is paramount. Kubernetes supports role-based access control (RBAC), so on paper you can control who does what. In practice, in a big company, RBAC gets confusing fast.

The issue isn’t that engineers ignore security. It’s that permissions grow over time. You need a quick fix during an incident, so you give a service account more access. Maybe a team needs cluster-wide rights for a migration. That “just for now” permission sticks around because no one cleans it up. Month by month, the gap widens between what a workload should do and what it’s actually allowed to do. The only thing that works long-term: treat RBAC as a living thing, not a one-time checklist. Review it. Test it. Stick to least privilege. Service accounts get only what they need. Cluster-admin rights? Rare. Expiring exceptions. Set permissions as code so changes aren’t invisible.

Same story with workload security. Kubernetes brings you Pod Security Standards. There is baseline, restricted and privileged profiles, so everyone speaks the same language. But simply setting a standard isn’t enough. We’d also need things like admission controls, image scanning, runtime monitoring and audit trails.

Honestly, the NSA/CISA Kubernetes Hardening Guidance is still gold. Scan containers and pods. Run workloads as locked down as possible. Use strong authentication. Separate networks. Set up solid logging. These ideas sound obvious until you see what happens when your organization scales without good ops.

Network policies: where “it should work” meets reality

Kubernetes networking can trip up even the best teams. Engineers often think different namespaces mean automatic isolation between apps. Not true.

Kubernetes network policies decide which pods can talk to which, but the policies only matter if your networking plugin actually enforces them. I’ve seen a lot of teams write network controls that look great in YAML but don’t work, because the underlying network just ignores them. Security validation beats documentation every time. If two namespaces shouldn’t talk, test it. If a workload only needs access to a specific backend, check it. If only specific ingress is allowed, make sure nothing else gets through.

At scale, your Kubernetes security has to prove itself. “We have a policy” means nothing unless the platform can show the policy actually works.

Resource management becomes all about money

One of the biggest challenge is resource allocation. Kubernetes lets you set CPU and memory limits, and sure, there are official docs. But getting these numbers right is tough.

Set them too low, and your workload might get throttled or evicted under load. Set them too high, and you’re paying for unused infrastructure. That barely registers on a small cluster, but when you’re running thousands of pods? That’s cloud bills gone wild.

This is where Kubernetes ops and FinOps meet. Platform teams have to know who’s burning through which resources, what’s over-provisioned or flying blind, and where the real money goes. ResourceQuota helps keep things in check, but quotas alone don’t hold people accountable.

The culture shift is moving from “the cluster has spare capacity” to “every service has an owner, a cost profile and a plan for staying lean.” Teams should understand their infrastructure bill. Platform teams need dashboards that point out waste. Engineering leaders need to care about efficiency, not just hear from finance when things go off the rails.

Autoscaling isn’t a magic trick

The Horizontal Pod Autoscaler is handy. It adjusts your workloads automatically to match demand. But don’t overestimate it. Most real-world services don’t scale simply by CPU or memory. Sometimes a service hits latency limits before CPU usage spikes. Workers chewing through queues? You care more about backlog size. Machine learning? Maybe it’s all about GPU use or loading time. Customer-facing apps? You want to be scaled up before traffic hits, not scramble after users start complaining.

So autoscaling isn’t just a box you check. It’s a feedback loop, and it only works if you use the right signals. Sometimes CPU is enough. Sometimes you need to scale on queue length, request rate, latency or something totally custom.

Then there’s node autoscaling to provision infrastructure in response to demand. On paper, it just works. In real life, it runs into startup delays, availability zones, quotas, cloud provider quirks and pod disruption budgets. Scale pods faster than nodes? Users still see delays.

Test autoscaling like you test your app. Load-test it, break it, see what happens after an incident. Otherwise, you’ll find the limits when it hurts most.

Observability doesn’t matter unless it answers questions

Kubernetes has mountains of data. Things like logs, metrics, traces, events, audits, deployment history, container restarts, control plane noise, you name it. The real challenge isn’t collecting info, but actually it’s making sense of it. The CNCF and others have best practices for logging and telemetry, like centralizing logs and not leaking secrets. Those matter, but at the end of the day, engineers need answers, not just data. When something breaks, no one’s asking, “Is Kubernetes alive?” They want to know what changed. Did something roll out? Did a pod crash? Did autoscaling fire too late? Was a node unhealthy, a secret rotated, a network policy too tight, a downstream DB choking?

Observability should line up with real operational questions and not just ticking boxes for logs, or metrics. Dashboards need to match service ownership. Alerts need to mean something to end users. Telemetry should connect to deployments and incidents. Measure how quickly engineers spot the root cause, not just that you have the data somewhere.

CNCF talks about newer models of unified telemetry and proactive troubleshooting for a reason. All the dashboards in the world don’t help when your team has to play detective during an outage.

Upgrades: Don’t wing it

Kubernetes upgrades catch people out. The CNCF Maturity Model says: Kubernetes drops three big releases a year, so maintenance is part of life—not a once-in-a-blue-moon project.

Upgrading at enterprise scale can involve everything: workloads, admission controllers, CI/CD, service mesh, ingress, storage drivers, monitoring, security, custom controllers. Version skew policies keep you between the lines, but that’s just the beginning. The real question is: can you test your whole stack?

Good upgrade programs need a repeatable process, staging environments that actually look like production, and clear communication so teams know what to expect. The worst upgrade process is the one that relies on heroes to pull it off at the last second. A strong platform turns upgrades into routine.

Reliability: Kubernetes helps, but it doesn’t guarantee it

Yes, Kubernetes restarts crashed containers, reschedules pods and does rolling deployments. But it doesn’t make a bad app reliable.

A poorly coded app will fail on Kubernetes just like anywhere else. Bad readiness or liveness probes? Your app gets traffic too soon. No graceful shutdown? Requests drop during deploy. Forgot pod disruption budgets? The app goes down during node maintenance. A flaky dependency? It will cascade through your services even if all your pods look healthy.

The mature approach is setting service-level objectives and making reliability a product of both platform and engineering. Cluster health isn’t user experience. That green status page can hide a lot of pain.

The platform team is a product team

Here’s the biggest lesson I’ve picked up is that running Kubernetes at enterprise scale isn’t really about the tech. One cluster? Maybe one expert can handle that. But for a full enterprise platform, you need a product mindset. The platform team serves customers such as engineers, security, compliance, finance and business. Everyone wants something a bit different.

Developers want speed and reliability. Security wants oversight. Finance wants transparency. Compliance wants proof. Ops wants predictability. The business wants all of those.

The platform team has to pull those threads together with APIs, docs, dashboards, paved roads, support and feedback. That also means saying “no” to the unique snowflake patterns that create chaos later. Kubernetes is powerful. But it doesn’t replace organizational discipline. That’s still on the shoulders of engineering leaders. The real challenge at enterprise scale isn’t memorizing every API object. It’s building a system where any team can ship safely without needing to be Kubernetes experts themselves.

When you reach that point, Kubernetes stops being just a cluster. It becomes your platform.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Infoblox acquires Kentik, adding network observability to its DNS and DDI platform

Wed, 08 Jul 2026 19:23:46 +0200

Info blox announced today that it has entered into a definitive agreement to acquire Kentik, combining Infoblox’s authoritative DNS, DHCP, and IP address management (IPAM) data with Kentik’s network observability platform. Financial terms were not disclosed.

Kentik was founded in 2014, originally as CloudHelix before rebranding the following year, and has raised more than $100 million in venture funding to date. The platform provides real-time visibility into network traffic and ingests flow data, routing intelligence, and device telemetry across data centers, cloud environments, WANs, and the public internet. In recent years, the company has enhanced its platform with an AI advisor that helps to accelerate investigations.

Infoblox has spent more than two decades managing the DNS, DHCP, and IPAM services enterprises rely on to stay connected. In 2024, it first launched its Universal DDI SaaS platform for managing DNS, DHCP, and IP addresses from a single place, expanding in 2025 to more providers. DDI refers to the trio of core network services in IP networks: DNS, which turns domain names into IP addresses; DHCP, which assigns IP addresses to resources; and IPAM, which manages the network’s IP address infrastructure.

Infoblox and Kentik each had something the other one was missing.

“We know every device, every application across the hybrid multi cloud state, we know because we handed out the IPs, or we have acquired those assets,” Mukesh Gupta, chief product officer at Infoblox, told Network World. “We know what is on the network. We don’t know who is talking to who.”

The path to acquisition

“We’ve been talking for a few years,” Avi Freedman, co-founder and CEO of Kentik, told Network World.

Both Gupta and Freedman said the companies have discussed working together for several years, driven largely by customers who use both platforms and asked the two vendors to integrate them directly.

“We’ve gone from very internet-centric companies to some of the largest enterprises in the world, and guess who they use for all of their core sources of truth,” Freedman said. “So, our customers have been saying, hey, you have this great platform that can take all this enrichment, and we need you to be doing this kind of integration.”

For Infoblox, the situation was similar. Gupta noted that some of the problems his company was trying to solve require network flow information, which Kentik provides.

“We have a lot of common customers, and they were like, ‘Can you bring these platforms together?’” Gupta said.

What the integration will enable

The combination of the two companies’ technologies will bring more capabilities to users.

One specific example cited by Gupta has to do with the company’s Infoblox IQ, an agentic operations layer that was announced in June 2026, One of its existing capabilities, called IQ Actions, is designed to detect problems and begin investigating them automatically, before a customer notices an issue.

The system monitors DNS and DHCP metrics for anomalies, then automatically collects related data and analyzes it using large language models before an operator opens the ticket.

“We throw that data into LLMs and see if they can figure out what the root cause is, and come up with a recommendation, so all of that happens completely automatically,” Gupta said.

What Kentik would add to that workflow is flow data. Combining Infoblox’s DNS-based threat intelligence with Kentik’s flow data could extend the same kind of automatic investigation into security incidents. DNS data can identify devices communicating with a command and control server. Flow data can then show where those devices connected next inside the network.

“With flow data, we can draw that blast radius and tell customers proactively what the issue is and what the exposure is,” Gupta said.

Kentik’s own AI Advisor is moving in a similar direction, from answering direct questions to carrying out tasks on its own. The combination with DDI information will help to support that vision.

“What we’ve been working on is making it proactive, so basically operating Kentik for you, doing your networking tasks, all your planning, capacity optimization, troubleshooting,” Freedman said.

Freedman traced that same logic back to why the deal made sense in the first place.

“We can actually build an amazing platform together, which customers are actually asking for, which is always the best way to build a business,” he said.

AI has collapsed the cyber response window — resilience now starts before the attack

Wed, 08 Jul 2026 17:18:21 +0200

Presented by Rubrik

Enterprise cybersecurity is facing a fundamental speed problem. Frontier AI models are now enabling autonomous attacks that can move from initial access to full system breakout in as little as 27 seconds. That’s faster than any human-operated security workflow can detect, escalate, and respond.

As a result, security operations can no longer assume there is time for humans to respond between breach and damage.

The security posture that enterprises need for the AI era centers on cyber resilience: continuously identifying clean recovery states, mapping critical data and identity dependencies, and automating restoration so that operations can recover in hours not days.

"Everything that relied on process or human-in-the-loop intervention is no longer going to be able to execute at the speed of the attacks," says Dev Rishi, GM of AI at Rubrik. "If the attacks are happening in 27 seconds, it means I need my recovery to happen just as quickly."

Traditional detection and prevention are failing against AI-driven attacks

The rules-based logic that has defined enterprise security for decades, such as static access controls, known signature detection and deterministic behavioral policies, was engineered for deterministic software. AI agents behave differently. They're non-deterministic, capable of pursuing the same objective through many different paths, and increasingly capable of circumventing static guardrails by finding alternative routes when one is blocked.

The deeper problem is that conventional security logic checks identity, permissions, and access, and asks whether each individual access is permitted. But it can’t evaluate whether a sequence of permitted actions, taken across multiple applications, constitutes either a data leak, a destructive operation, or an attack.

"You need a system that can understand context," Rishi says. "You need to use AI to look at what an agent is doing and say, ‘it looks like what you're doing might be a risk of leaking sensitive data externally.’"

How AI agents are blurring the line between internal and external cyber threats

Enterprise security has historically maintained a meaningful distinction between external and internal threat vectors. External threats can be multidimensional, lightning fast, and come from a variety of vectors. On the other hand, internal threats were traditionally bounded by what a single human actor could accomplish before detection, constrained in speed, scope, and scale, but that distinction is falling apart as AI agents operate inside enterprise environments.

These agents have access to multiple systems simultaneously and move at speeds no human employee can match. When an agent makes a mistake, such as a hallucination, misread instruction, or an unintended data transfer, the resulting damage can look operationally identical to a malicious insider attack. And when an external attacker compromises an internal agent, they inherit its full access profile across every connected application.

"Whether or not the agent is an internal threat because of an inadvertent mistake or because it's been maliciously compromised, you need runtime guardrails that enforce your organizations policies consistently across agents," Rishi says. "The practical answer is an AI-native guardian layer that monitors agent behavior semantically, understands intent across actions, and can block or terminate a misbehaving agent at machine speed, then trigger recovery immediately."

Preparing for a world of inevitable compromise

Frontier AI models, including those capable of discovering and operationalizing zero-day vulnerabilities autonomously, are changing the economics of attacks.

As a result, interest in Mythos readiness is growing. Enterprises are increasingly operating under two assumptions: that attacks are inevitable, not exceptional, and that investment in resilience and rapid recovery must be treated as strategically as investment in prevention has been. The shift reframes recovery from a post-incident activity into a capability that is deliberately designed, tested, and continuously validated.

"The idea that you can recover quickly from an attack is going to become one of the most important facets of security," Rishi says. "It's the insurance policy that organizations now have to treat as a first-class citizen."

Why AI-powered cyber resilience depends on small models

True cyber resilience is a two-sided coin: it demands both real-time intelligent enforcement to intercept threats in motion, and automated recovery to restore operations immediately. While having backups is a baseline, organizations need workflows that can continuously monitor systems at machine speed, and instantly determine the most recent clean state under attack conditions.

Applying AI to the first half of that equation—real-time enforcement—creates a fundamental technical and economic challenge. Relying on massive frontier models to monitor every agent action introduces crippling latency overhead and exorbitant computing costs. A guardian AI system that slows down operations or costs as much as the systems it monitors is simply not viable for widespread adoption.

“It has to be a fast, small, and cheap AI model,” Rishi says. “No one wants to sign up for a secure solution that doubles their cost or latency.”

This is why small language models (SLMs) are critical for real-time enforcement. Rubrik’s approach, anchored by its acquisition of Predibase, is to build this frontline defense layer on small models optimized specifically for speed and efficiency. Unlike heavy frontier models, SLMs can semantically evaluate agent behavior at machine speed and at a fraction of the cost, acting as a real-time checkpoint.

That hyper-efficient enforcement layer is what enables a tighter, seamless connection to recovery. When the system observes an agent taking a destructive action—such as deleting a database, corrupting a critical file, or exfiltrating sensitive data—the small model detects it immediately, halts the damage, identifies the most recent clean snapshot from before the incident, and initiates recovery in a single, automated workflow.

The shift from incident response to architectural resilience

The broader implication of Mythos and similar frontier AI systems is a shift in how organizations think about security. As AI compresses the gap between attack and impact, resilience and recovery become architectural requirements rather than operational considerations.

Rubrik’s view is that security systems can no longer stop at detection. As AI agents gain greater autonomy, observability, identity context, and recovery must operate as a coordinated resilience layer. The goal is not simply to identify when something has gone wrong, but to shorten the gap between detection and restoration.

"The same thing that's introducing the threats, the frontier capabilities of models like Mythos, can also be used to help us combat the threat," Rishi says. "Positioning yourself for the AI era means closing the gap between detecting that something has gone wrong and restoring the systems that were affected, before the cost of that gap compounds."

Offiziell verfügbar: Azure Copilot Observability Agent

Wed, 08 Jul 2026 12:03:19 +0200

Der KI-gestützte Agent vereint Telemetriedaten sowie Kontextanalysen und ermöglicht automatisierte Triage-Prozesse zur Reduzierung der Systemwiederherstellungszeit.

ScienceLogic adds geographic service visibility to Skylar One

Wed, 08 Jul 2026 11:23:37 +0200

The post ScienceLogic adds geographic service visibility to Skylar One appeared first on IT Security News.

ScienceLogic adds geographic service visibility to Skylar One

Wed, 08 Jul 2026 11:09:12 +0200

ScienceLogic has released the “Kyoto” update for Skylar One, the core observability offering in its AI Platform. The release adds geographic service visibility, simplified location and device management, enhanced relationship mapping, and platform updates aimed at improving observability across hybrid IT environments. The Kyoto update is designed for organizations managing hybrid infrastructure, cloud environments, and AI workloads. It introduces features for investigating service issues, managing locations and access, and improving platform scalability and resilience. Highlights … More →

The post ScienceLogic adds geographic service visibility to Skylar One appeared first on Help Net Security.

The AI ROI gap isn’t a model problem. It’s a workflow problem

Wed, 08 Jul 2026 11:02:59 +0200

Anthropic says Claude now writes more than 80% of the code merged at one of the most sophisticated AI companies on the planet. Foundry’s 2026 State of the CIO study says fewer than one in five enterprises can show that their AI initiatives have met or exceeded their ROI goals. Both numbers came out this spring. Both are true. And the distance between them is the most important thing an IT leader can understand about AI right now.

Because that distance isn’t a contradiction, it’s a lesson. And the profession sitting in the middle of it, software engineering, is the canary that explains why so much enterprise AI spend has produced so little measurable return.

The report everyone misread

When Anthropic published its recursive self-improvement piece, plenty of people read it as the starting gun for the job apocalypse. Claude writing its own code, models getting better at building models, humans narrowing toward oversight. If you wanted a headline about the end of the software profession, it was right there.

I read it almost the opposite way. What struck me wasn’t how far AI had come. It was how much had to be true first, even in the one profession built from the ground up to let it succeed.

I made this argument back in my “$570K canary” piece, and the Anthropic data only sharpens it. AI coding agents don’t work because coding models are special. The underlying large language models (LLMs) are the same ones answering support tickets and reviewing contracts. They work because software development already had the infrastructure that makes an agent’s output trustworthy: governance baked into branch protection and code review, observability through version control and CI/CD pipelines, evaluation through automated tests, persistent context through commit history. Developers built all of that for themselves over decades. They didn’t build it for AI. But it turned out to be exactly the scaffolding AI needed.

That’s the part the apocalypse reading skips. Claude’s coding gains are real. They also rode on decades of pre-built substrate. Both things are true at once, and the second one is the one CIOs should be paying attention to when it comes to gains from things like recursive self-improvement.

What the CIO data actually shows

Now hold that next to the State of the CIO numbers. Only 19% of the 662 IT leaders surveyed say their AI initiatives have met or exceeded business goals. Another 18% admit fewer than a third of their use cases are hitting defined expectations.

The easy explanation is that the technology isn’t ready. The data says otherwise. This isn’t for lack of trying, and it isn’t for lack of organizing. Eighty-three percent of respondents have stood up cross-functional steering committees or are about to. Just over half have some form of AI approval process in place, with another quarter building one. Forty-seven percent have formal success metrics, with a third more on the way. The field is pouring effort into the organizational machinery of AI. The ROI still isn’t showing up.

Here’s why I think that is. All of that machinery sits above the work. Steering committees, approval gates and KPI dashboards govern the org chart. But the value, or the leak, happens inside the workflow, at the level of the actual task the AI is doing. You can instrument your governance structure perfectly and still have nothing measuring whether the agent’s output was right at the point where it mattered.

TIAA shows how little the org chart settles. The firm is three years in, runs generative and agentic use cases across fraud detection and call centers, and has 85% of its people on TIAA Gate, its internal platform. It also has the full governance stack most CIOs are still assembling. None of it closed the gap. “You need to understand the full cost of operations,” its chief operating, information and digital officer, Sastry Durvasula told CIO.com, “the efficiencies of running tokens or how you’re handling traffic or RAG.” The structures were never the thing leaking value. The workflow underneath them was.

The barriers respondents named back this up. The top three are lack of in-house expertise (40%), ill-defined ROI metrics (32%) and murky corporate AI strategy (31%). Not one of them is “the model isn’t good enough.” And according to the full Foundry report, the expertise gap is deepest in healthcare (52%), retail (51%) and manufacturing (49%), the sectors whose core work looks least like a software development lifecycle. That’s consistent with substrate being the real variable, though a tighter market for AI talent in those industries is surely part of the story too.

The market is already voting

Look at where the AI is actually being pointed, and you’ll see enterprises sequencing by substrate even though nobody’s calling it that. Three-quarters of both IT leaders and line-of-business respondents say AI is primarily being used to automate internal processes rather than customer-facing applications.

That’s not timidity. It’s instinct pointing at the right thing. Internal processes are the ones with structured, observable workflows and users who tolerate a little friction. Customer-facing work is where the trust gaps are still wide open and the cost of a wrong answer is asymmetric. A bad internal draft gets fixed before anyone sees it. A bad customer answer is the whole ballgame.

I’ll be honest about a wrinkle in the data here, because a careful reader will catch it. The same study reports a near-mirror finding, that 66% to 69% of respondents say the bulk of their current AI work is customer-facing. The two stats sit a paragraph apart in the CIO study and almost certainly reflect how the question was framed rather than a real reversal. But the synthesis holds either way: even where customer-facing work is being attempted, it’s where ROI is least realized. The work that lands is the work with the substrate underneath it. The split only reinforces the point.

Sequence by readiness, not by ambition

So, here’s the prescription, and it cuts against the instinct most AI strategies are built on. Stop sequencing your AI portfolio by where the value looks biggest. Start sequencing it by where the work already has, or can be given, a structured workflow with a usable signal for whether the output was right.

The study itself shows what the alternative looks like. Andrea Ballinger, CIO at Rensselaer Polytechnic Institute, described the trap precisely. No one measures ROI on an ongoing basis, she said, “because we are facing counterpressures from every vice president and line-of-business domain looking to implement AI for their own optimization.” The result: “We are saying yes to everyone without stepping back and focusing on the business cases that show real value.” That’s value-led sequencing under pressure from every budget-holder in the building, and it’s exactly how you end up with a sprawling pipeline of pilots and a 19% success rate.

The counterexample comes from the same study. Thomas Prommer, a longtime CTO, CIO and CAIO, funds outcomes instead of deliverables. “We don’t fund ‘build a model,’ we fund ‘reduce returns by 8% on this category’ with checkpoints at 90, 180 and 270 days,” he explained. He kills any project that misses two checkpoints, “roughly a third of what we start, and that’s healthy.” Read that through the substrate lens and you see what he’s really doing. He’s manufacturing a correctness signal where the work didn’t come with one. He’s building the missing piece of scaffolding by hand.

That gives you a simple lens to run any candidate use case through. Does the work break into discernible stages? Can you observe what happens at each one? Is there a usable signal for whether the result was right? Score high on all three and you have a software-engineering-shaped problem, so go now. Score low and you have a choice: build the substrate first or wait. What you shouldn’t do is fund it at scale and hope the ROI materializes, because that’s the pile the 19% number is built on.

The hard part, and the honest caveat

Run the professions through that lens and they sort themselves. Finance is the closest cousin to software. Reconciliation, close processes, approval chains and audit trails already give you staged work with a clear “it reconciles or it doesn’t” signal, which is part of why financial services sits among the sectors furthest along with AI. Legal and medicine are harder. The workflow shell exists, intake to redline to filing, diagnosis to treatment to follow-up, but the correctness signal at the core is weak, delayed or confounded. You can automate the routine staged parts and you hit a wall at the judgment that defines the profession.

And that’s the caveat that keeps this honest. A structured workflow isn’t always buildable in software’s image. For the judgment core of some professions, the substrate is years out no matter how good the model gets or how mature your governance becomes. Anyone selling you a tighter timeline than that is selling.

But notice what this reframe does. It turns “our AI ROI is elusive” from a mystery you wait out into a sequencing-and-instrumentation problem you can actually test. Your timeline isn’t set by how smart the next model is. It’s set by how fast you build the substrate for your own domain, and that’s within your control.

The two numbers, reconciled

Put the 80% and the 19% back next to each other and they stop looking like a paradox. Software engineering didn’t win because its models were better than everyone else’s. It won because the work was already shaped to let an agent succeed, and the scaffolding that makes agent output trustworthy had been in place for decades before the agent showed up.

The question for the rest of the enterprise was never really whether AI can do the work. It’s whether your work is shaped so AI’s output can be trusted. That’s not something you wait for. It’s something you build.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Anthropic shines a light into the Claude AI black hole

Wed, 08 Jul 2026 06:33:50 +0200

Anthropic has found a way to shed new light on how its models solve problems, thanks to its discovery of what it has dubbed the J-space.

“We find that Claude has developed a small collection of internal neural patterns that, compared to all its other internal processing, play a special role. We call the collection of these patterns the J-space, named after the technique we used to find them, involving a mathematical concept called the Jacobian,” Anthropic said in its post about the discovery. It examines the contents of the J-space using what it calls the Jacobian lens, or J-lens.

“Each J-space pattern is linked to a particular word,” Anthropic said. “But when one of these patterns lights up, it doesn’t mean the model is saying that word, just that the word is on its ‘mind.’ If you’ve heard of language models having a scratchpad or chain of thought—text they write to themselves while reasoning—the J-space is something different. It operates silently, in the model’s internal neural activations, allowing the model to ‘think’ about a concept without writing it down.”

This new level of analytical visibility goes well beyond what Anthropic announced as an internal scratchpad for its models in 2024. That scratchpad revealed what the model was considering when preparing an action or delivering an answer. The new development instead focuses on something much deeper which has the potential to change how AI systems are evaluated and purchased.

One example in the paper described how some models did not engage in improper behavior during tests, which would appear to be a very favorable result. But the contents of the J-space revealed that the model sometimes knew that it was being tested, and that awareness might have been the key reason it declined to engage in the problematic behavior, much in the way human children act when they know they are being watched.

“Anthropic built a lens that catches its own model quietly noticing it’s being tested, faking a result to look good, spotting a prompt injection, or sitting on a planted goal it hasn’t acted on yet,” said Rock Lambros, director of AI standards and governance at AI agent vendor Zenity. “Some of that good behavior rode on the model knowing it was on stage.”

Customers should read their safety benchmarks with that in mind, he said. “Fitness for your project still comes from testing on your own data and your own attackers, not from a leaderboard the model knew it was sitting for.”

That kind of visibility is a potentially crucial tool for CIOs.

“A provider that can catch its own model misbehaving in silence, then publish [those results], is telling you something real about its assurance maturity. Put that in your due diligence, not just your newsfeed,” Lambros noted. “Here’s the question I’d hand every model vendor now: what can you see inside your model that I can’t see in its output, and what have you caught?”

Added Noah Kenney, principal consultant at Digital 520: “A model that behaves better because it knows it is being watched is not a safe model. It is a model with a poker face. We have to question every red team result, every internal pilot where the model refused something dangerous, and every ‘we tested this and it was fine’ story, because they now carry an asterisk.”

CIOs need to now determine whether an agent performed a function in a specific way because that is how it will always perform, or whether it was it behaving differently because it figured out you were just testing it, Kenney said. “The answer to that question should change your interpretation in a material way.”

No J-lens for customers – yet

“It is an admission that the industry’s evaluation regime is measuring something less durable than everyone assumed, and now the other frontier labs have to answer whether their own evaluations have the same problem,” Kenney said. “For CIOs, the paper is a warning about their entire model risk framework.”

Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group, said that examining the J-space can even help make models more efficient.

“It gives you the ability to introspect into the model and, as such, can be very useful to the user, especially in cases where explainability is important. Think regulated environments that require explainable responses and full causal analysis of them,” Villanustre said. “This can also be very helpful to users trying to fine tune their prompts, making models more efficient to optimize token cost.”

But currently indirect access, or future access achieved via AI vendor negotiations, is the only path for accessing the new information, though Villanustre noted that some enterprises could gain direct access to J-space by paying for Anthropic’s FDE program.

“It is very useful to CIOs,” he pointed out, “but in order to make use of the capabilities offered by analysis of the J-space, they need appropriate talent that can make sense of it. The type of skills required go far beyond those of the general data analyst, or even data scientist.”

Today, said Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, “enterprise customers cannot enable the Jacobian lens, cannot inspect the residual stream through the API, and cannot run the ablation studies that produced the most interesting findings in the paper.”

So, he said, “on the narrow question of whether a CIO can operationally use J-space monitoring in Q3 of this year to gate a production deployment, the answer is no.”

But Mahapatra argued that there are going to be other ways to access the information, and CIOs must insist on them.

“Without customer-side access, this reduces to trusting Anthropic yet again, and that is exactly why enterprises should start pushing for a different assurance model industry-wide,” he said. “Model providers are converging on a posture where they inspect their own models using proprietary tooling and publish reassuring research about what they found. That is not an assurance framework any regulated industry accepts from any other vendor.”

He pointed out that banks do not accept “we validated our own model, trust us” from a credit scoring vendor, not does the healthcare industry accept it from a clinical decision support vendor. “There is no principled reason to accept it from a foundation model vendor either, and the J-space research crystallizes why,” he said.

New visibility demands

“The right long-term enterprise posture is to demand independent interpretability access, either through customer-facing APIs, through independent third-party auditors with privileged access, or through open interpretability standards that let a bank’s model risk management team apply the same tooling the vendor’s own safety team uses,” Mahapatra stressed. “None of that exists today. All of it should be on the roadmap CIOs are pushing for, and this research is the strongest argument yet for why.”

In fact, the discoveries in the research have the potential to fundamentally rewrite the AI strategy rules.

Mahapatra said that the single hardest problem in enterprise agentic deployment is verifying that an autonomous system’s stated reasoning matches its actual reasoning. “Until now, we could only audit what the model writes, while much of its reasoning happened silently. The J-lens attacks that gap head-on,” he noted.

Thus, he said, sophisticated buyers should start asking model providers during the procurement process about the interpretability tooling they offer to let customers monitor internal model state for deception, evaluation-gaming, and goal misalignment in their specific deployments.

“Almost no vendor can answer that today,” he said. “The CIOs who start requiring internal-state observability as a procurement criterion, even before the tooling is fully mature, will be the ones who shape how their vendors productize it, and the ones with genuine assurance when regulators start asking how they know their autonomous agents are actually doing what they claim.”

The beginning of standards

Another way that CIOs can benefit from this new visibility into Claude is to try and get that information from third-parties that already have access. The report, for example, noted that a Google AI specialist independently replicated some findings on an open-weight model.

That, noted Lewis Carhart, CEO of Comp AI, a software development firm, “is a competitor verifying the method, not just the vendor’s own claim. It shows what’s technically possible, but it doesn’t give enterprises a way to check anything themselves.”

He said that it’s a pattern that compliance has seen before; SOC 2 didn’t start as an independent audit standard either. It started as vendors describing their own controls, and the market spent years building the infrastructure to verify those claims externally.

“Interpretability is at that same starting point now,” he noted. “It becomes meaningful for CIOs once J-lens findings show up in third-party audits, published model cards, or regulator-facing disclosures. Anything a risk team can point to that isn’t just the vendor’s word.”

Leads to AI strategy changes

Justin Greis, CEO of consulting firm Acceligence, said he also expects this development to lead to major AI strategy changes.

“I can easily imagine governance platforms consuming those signals alongside prompts, outputs, identity information, policy decisions, and tool activity,” he said. “A future AI control plane could continuously evaluate whether an agent recognized an attempted prompt injection, understood that sensitive information was involved, detected conflicting objectives, or showed evidence that it was reasoning toward an unsafe action before that action was ever executed. Those signals become inputs into policy enforcement, human escalation, audit logging, and trust scoring across enterprise AI environments.”

This has practical implications for CIOs today, he pointed out, “because it changes how they evaluate AI vendors. A year ago, enterprises primarily asked about model accuracy, latency, security, and cost. Increasingly, procurement teams will also ask how much operational visibility vendors provide into agent behavior, reasoning quality, policy compliance, safety monitoring, and auditability.”

Mahapatra added that all of this could give CIOs a powerful new negotiating tactic.

“The renewal path is where the leverage actually sits: write contractual rights to interpretability reporting and third-party audit access into the next renewal, because those terms are free today and expensive after signature,” he said. “The CIOs who win on assurance in 2027 will be the ones who stopped accepting ‘trust us’ from their model provider in 2026 and put the right clauses in the paperwork while the vendor still needed the deal more than the customer needed the model.”

This article originally appeared on CIO.com.

Anthropic shines a light into the Claude AI black hole

Wed, 08 Jul 2026 06:33:02 +0200

Anthropic has found a way to shed new light on how its models solve problems, thanks to its discovery of what it has dubbed the J-space.

That kind of visibility is a potentially crucial tool for CIOs.

No J-lens for customers – yet

Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group, said that examining the J-space can even help make models more efficient.

So, he said, “on the narrow question of whether a CIO can operationally use J-space monitoring in Q3 of this year to gate a production deployment, the answer is no.”

But Mahapatra argued that there are going to be other ways to access the information, and CIOs must insist on them.

New visibility demands

In fact, the discoveries in the research have the potential to fundamentally rewrite the AI strategy rules.

The beginning of standards

Leads to AI strategy changes

Justin Greis, CEO of consulting firm Acceligence, said he also expects this development to lead to major AI strategy changes.

Mahapatra added that all of this could give CIOs a powerful new negotiating tactic.

Build for the new AI era with Microsoft and NVIDIA

Tue, 07 Jul 2026 18:18:29 +0200

Presented by Microsoft and NVIDIA

Every generation of leaders has its own business transformation challenges to face. A decade ago, modernization meant cloud migration. Five years ago, it meant enabling remote and hybrid work. And just a few short years ago, the generative AI boom prompted organizations globally into enterprise AI adoption.

The demo era is ending

In the years since AI became the big new buzzword, generative models proved to be a crucial stepping stone, but the path to Frontier Transformation is agentic AI. Machine-generated answers aren’t enough when what the business really needs is sophisticated AI that can act. Experimenting with agentic capabilities was a necessary step; prototypes and pilots have proliferated. But the chapter on demos is closing.

Scale acceleration is beginning. In 2026, organizations that want to see agentic results that impact the bottom line must move from the knowledge layer to the action layer. And they certainly intend to—according to Deloitte’s 2026 AI report, 54% of enterprises surveyed expect to move 40% or more of their AI experiments into production. How hard could it be?

Agents are a different engineering problem—here’s why

Moving past prototype is the hardest part. Shipping an agent to production isn’t just a harder version of shipping a generative AI chatbot. Agentic production is a different engineering problem altogether, requiring orchestration, memory, runtime isolation, and ground-up observability—all required to deliver an agent that reasons, acts, and collaborates.

Once an agent moves into production, every tool and data source becomes an integration challenge. Running the agent requires isolation between sessions, durable state, and runtimes that hold up under a working load. And operational blindness turns agentic assets into liabilities. Once an agent is live, you need the ability to monitor, understand, and troubleshoot its systems across its lifecycle—a whole new discipline of observability is required, but teams don’t know how to get there. But we’ve been here before. When microservices faced a similar crossroads a decade ago, the lesson was this: those who recognized the need for a platform approach are the ones with the best success.

The production gap: Why most agent projects stall before scale

Moving from demos to real-world deployment introduces a host of challenges: how to chain multiple steps together reliably, how to ensure security and identity across agent components, how to monitor and improve agent behavior, and more. Many teams attempt to address these challenges with custom scaffolding, but the risk is often greater than the reward—slower time to value, gaps, and unreliability.

This is where the platform approach comes in. Without shared context and intrinsic trust, AI is difficult to rely on and hard to scale, with data fragmentation keeping production agents from matching pilot performance. Agents lack business context, enterprise signals are fragmented, development is complex and brittle, and security and governance are bolted on.

The solution is a unified platform that empowers developers to build, run, and scale agentic and physical AI end-to-end. Together, Microsoft and NVIDIA partner to enable this platform approach, helping enterprises effectively take agents from pilot to production.

What an agent factory actually looks like

Frontier Firms are those that not only successfully take agents into production but that also understand monolithic agents aren’t enough—a system of collaborative agents is key. They are the ones building agent factories, operating on a production philosophy that utilizes a reliable foundation and repeatable process for cross-functional, collaborative agentic solutions at enterprise scale.

So what is an agent factory? It’s a coordinated production architecture that combines an agentic control plane with accelerated specialist models, agents, and skills, allowing organizations to enable a governed system of models and agents at enterprise scale.

Within this production system, Frontier Firms are building heterogenous systems of agents, where the right models, tools, skills, and specialist agents are appropriately orchestrated at the right step of every job. The result is broad-reasoning frontier agents that plan, synthesize, and collaborate with users and other agents while accelerated specialist models and agents execute domain-specific work with speed and efficiency.

Microsoft and NVIDIA jointly empower this agentic factory approach. Microsoft delivers the enterprise control plane enabling runtime, identity, governance, observability, data access, and tool connectivity that agents need to collaborate safely. NVIDIA delivers the intelligence, acceleration, and specialist layers that give enterprises a repeatable way to move from isolated demos to governed, scalable agentic systems that can work together across business processes to accomplish meaningful tasks, not just answer questions.

At Microsoft Build 2026, Microsoft and NVIDIA showed how this architecture is coming together across cloud, local, and developer environments, bringing NVIDIA models, blueprints, and tooling into the Microsoft ecosystem to enable systems of agents with governance and speed:

NVIDIA models are now on the hosted agents in Foundry Agent Service.
NVIDIA’s open model portfolio on Foundry now spans agentic, physical, and scientific AI.
NVIDIA Agent Toolkit and NVIDIA NemoClaw blueprints give developers an open-source platform to build production agents on Foundry.
Foundry Local on Azure Local is now on the NVIDIA RTX PRO 6000 Blackwell Server Edition platform.
NVIDIA OpenShell integrates with GitHub Copilot for secure agent development.

You can read more about these announcements here.

Where to go from here

The organizations that win with agentic AI will be the ones that invest in a factory approach. Ready to take the next step on your agentic journey? Explore these resources:

Dive deeper into the Microsoft Agent Factory—read the Agent Factory blog series.
See how developers accelerate AI deployment with NVIDIA NIM microservices for high-performance AI.
Learn more about Microsoft and NVIDIA’s latest developments for success with agentic AI—read the announcements from Microsoft Build 2026.
See how NVIDIA Nemotron 3 Ultra powers faster, more efficient reasoning for long-running agents.
To discuss your Microsoft Foundry needs or learn more, contact us here.

Five tips for developing data products

Tue, 07 Jul 2026 11:04:19 +0200

Data products help standardize how raw data sets, data warehouse views, and data lake logical views are combined and used to deliver analytics and AI capabilities. By developing data products, teams can streamline much of the upfront data pipelines, governance, and management needed to deliver trusted data assets that people, tools, and AI can then use for different purposes.

The way you cook a meal can serve as a helpful analogy. You can choose to purchase only raw ingredients like tomatoes, wheat flour, eggs, and fresh herbs to make a favorite pasta dish. The approach works well when you have the time and skills to cook from scratch or want to prepare a nice meal for a small family. Otherwise, you may want to buy canned tomatoes, your favorite box of pasta, and a spice mix to cook the same meal, especially if you are time-constrained, are cooking for many people, or want a consistent finished product.

Like the not-from-scratch pasta meal, data products provide a similar level of time-saving effort, so that analytics and AI capabilities start with consistent, streamlined ingredients. Here are five questions teams should consider as they develop data products and their standards.

When to build a data product?

Most organizations can’t afford to develop data products as intermediaries for every data visualization, machine learning model, or AI agent. There’s cost and time to develop data products, and once they’re deployed or “on the shelves,” their product managers must oversee their ongoing support and life-cycle management. So when should agile data teams develop data products, and how should they prioritize which ones are more important? One starting point is to consider data products built from a single data set and what it means to productize them.

“A data set should really become a data product when multiple teams start relying on it to make decisions or to power applications,” says Danielle Ben-Gera, vice president of engineering at Crunchbase. “Developing proper governance, clear ownership, versioning, and a managed life cycle for changes becomes important, or you’ll just be shipping fragile pipelines that break downstream work.”

A second consideration is treating the use of ungoverned data sets as a form of data debt. Establishing a data product can be a tactical approach to standardize usage and address risks.

“Organizations should build a data product when data sets are being used across teams without strong governance, well-defined processes, or clear ownership,” says Yaad Oren, managing director at SAP Labs US and global head of research and innovation at SAP. “When anchored in a unified data foundation, data products eliminate silos, create shared understanding, and establish secure, standardized access that enables teams to leverage the same assets with confidence.”

A third consideration is to apply manufacturing principles by building data products for defined customers, driving reuse, and creating efficiencies. Drafting the data product’s vision statement and qualifying its business value is particularly important when a data product requires combining multiple data sources. It raises the question of how standardization delivers efficiencies, improves quality, reduces data security risks, and provides other benefits.

Christopher Zangrilli, vice president of technology strategy at Vertex, says, “Leaders should ask whether the data will reduce cycle time, improve decision accuracy, or mitigate compliance risk as a lens on the business impact. When governance, change management for adoption, quality, and value measurement are embedded from the start, data products transform from experimental tools to strategic assets.”

Why define standards for data products?

The products at the grocery store have packaging with a detailed list of ingredients, an expiration date, and a price. Data governance leaders should also standardize how data products are defined, cataloged, and managed.

“Any modern data product should answer four questions clearly: where the data originates, how it transforms across systems, who or what is consuming it, and what governance obligations apply at every step,” says Abhi Sharma, cofounder and CEO at Relyance AI. “Without that end-to-end context, teams are building features on top of data they don’t fully understand.”

Although food products publish their ingredients and label them for dietary restrictions, few document the sourcing of raw ingredients and the logistics of the path from farm to grocer. But when building data products, capturing data lineage may be required in regulated industries and is particularly important when standardizing data sources for AI applications.

“Without lineage, teams operate blind, and governance becomes reactive cleanup,” says Carter Page, executive vice president of research and development at Astronomer. “When teams can see where data originated, how it was transformed, and every system that relies on it, updates become predictable, the right pipelines get tested, the target stakeholders are notified, and breaking changes are documented before they cause incidents.”

What is a data product’s life cycle?

Life-cycle management of an API, application, or AI model requires defining a release schedule for delivering improvements, fixes, and other required upgrades. Data product life-cycle management involves several similar disciplines. Ulf Viney, executive vice president of engineering, support, and operations at Precisely, says, “Life-cycle management must include versioning, testing, structured deployment, and stakeholder communication.”

One fundamental difference with data products is that their life-cycle management is closely linked to how their underlying data sets grow or undergo structural changes. Having a data product that works today but isn’t resilient to changes or doesn’t generate alerts when fixes are necessary can break downstream use cases and erode stakeholders’ and users’ trust in the data.

“Managing data as a product means that data consumers can trust the data from the outset, which requires a sustainable and scalable governance framework that ensures data is easy to find, understand, and use,” says Bethany Sehon, senior director of enterprise data at Capital One. “By embedding observability, quality checks, and interoperability from day one, you can manage the full data life cycle from versioning and testing to measuring adoption and performance.”

Teams managing mission-critical, real-time data products that feed multiple downstream analytics and AI use cases should consider the following devops and data governance practices.

Establish data governance non-negotiables, especially on setting data quality benchmarks, qualifying any data biases, and adhering to data privacy policies.
Support advanced continuous integration/continuous delivery (CI/CD) and continuous deployment, with continuous testing and production deployments fully automated.
Ensure all data integrations have observable dataops with monitoring for data quality issues and alerting when pipelines stop running. IT services should be defined to address requests and incidents.
Align with data management technology platform strategies, including data fabrics, data security posture management (DSPM), document processing, and vector databases.

How to encourage adoption?

Unfortunately, building a data product doesn’t guarantee adoption. Think back to the challenges of getting code reuse, API adoption, or standardizing in-house-developed devops tools. These are all examples of intermediary products aimed at reducing developer toil and improving quality, yet many teams adopted “not-invented-here” postures and do-it-yourself practices rather than learning and adopting standards developed by other teams.

Data products face even greater challenges, especially when they aim to consolidate data silos or eliminate spreadsheets. Product managers overseeing data products must develop a change management program to grow adoption and gather feedback.

“A data product earns its place when it drives a real business decision and can be trusted at scale,” says Quais Taraki, CTO at EnterpriseDB. “Treat data products like software, with versioning, testing, and controlled releases, not one-off pipelines. That discipline securely delivers the right data to the right place and turns data into measurable value through adoption, speed, and risk reduction.”

Product managers can accelerate adoption by communicating how a data product aligns with the business’s AI strategy and culture transformation. For example, show how the data product improves AI literacy, democratizes AI through the right business use cases, or prepares the workforce to use AI agents.

How to measure business value?

The value delivered by a customer-facing product is often measured through revenue impact, usage metrics, and customer satisfaction (CSat). Internal, employee-facing products can be measured in terms of workflow efficiency, productivity improvement, and employee satisfaction (ESat). Data products are intermediaries, so quantifying their value can be more challenging.

“Too many organizations still treat data products as technical outputs instead of strategic assets,” says Daniel Ziv, global vice president of AI and analytics at Verint. “Their true value becomes clear when assessing how uniquely the data is generated, how much measurable impact it can drive across decisions, and how you can safely extract insight while managing risk. When every organization has access to the same AI models, competitive advantage comes from your unique data and how quickly you turn it into action.”

Sunil Kalra, head of the Databricks center of excellence at LatentView Analytics, adds, “Value should be measured through adoption, usage, and outcomes such as faster insights, reduced manual work, and improved revenue or cost performance.”

A best practice is to use digital transformation velocity metrics such as time to data, time to decision, time to innovation, and time to value. As more organizations seek to deliver business value from AI agents, creating data products will be seen as a path to accelerate delivery, reuse data assets, reduce risks, and manage costs.

데이터 주권 시대, AI 운영도 달라진다…오픈텍스트가 제시한 3대 원칙

Tue, 07 Jul 2026 04:50:19 +0200

오픈텍스트는 데이터 주권 요건이 강화될수록 기존 중앙집중형 IT 운영 모델의 한계가 더욱 뚜렷해진다고 설명했다. 기존에는 장애 발생 시 여러 지역의 로그와 운영 데이터를 중앙으로 수집해 전체 시스템을 분석하는 방식이 일반적이었지만, 데이터 이동이 제한되는 환경에서는 이러한 접근이 더 이상 효과적으로 작동하기 어렵다는 것이다.

회사에 따르면 텔레메트리(원격 운영 신호)가 국경을 넘지 못하면 장애 대응 속도가 저하되고, 워크로드가 특정 지역에 제한되면 배포와 운영 조율도 복잡해진다. 그 결과 운영 조직은 기존에 확보했던 통합 가시성을 유지하기 어려워질 수 있다.

오픈텍스트는 데이터 주권 요구사항을 기존 인프라 위에 사후적으로 추가하는 방식만으로는 한계가 있다고 진단했다. 규정 준수 정책을 기존 시스템 위에 덧붙이는 방식이 아니라, AI 시스템 설계 단계부터 거버넌스를 핵심 원칙으로 반영해야 한다는 설명이다.

회사는 시스템의 배포 방식과 접근 권한, 운영 데이터가 환경 간 어떻게 이동하는지 등을 설계 초기부터 거버넌스 체계에 포함해야 한다고 밝혔다. 이 같은 경계를 시스템 아키텍처 자체에 내장할 경우 규정 준수가 별도의 운영 부담이 아니라 시스템 운영 방식의 일부가 될 수 있다고 설명했다.

데이터 주권과 운영 안정성 위한 세 가지 원칙

오픈텍스트는 실제 운영 환경에서 데이터 주권과 안정성을 함께 확보하기 위한 세 가지 핵심 원칙도 제시했다.

첫 번째는 자동화된 주권 가드레일이다. 회사는 주권 정책이 문서나 운영자의 판단에 의존할 경우 우회될 가능성이 높다며, AI 환경에서는 ‘정책 코드화(Policy as Code)’를 통해 인프라 배포뿐 아니라 AI 추론 실행 위치와 기업 데이터가 벤더 AI 모델 학습으로부터 기술적으로 분리되는지까지 자동으로 관리해야 한다고 설명했다.

두 번째는 관할권을 고려한 인프라 배치다. 민감한 워크로드는 로컬 환경에서 운영하고, 비민감 워크로드는 하이퍼스케일러 클라우드를 활용하는 하이브리드 아키텍처를 구축하면 규정 준수와 운영 효율성을 동시에 확보할 수 있다는 것이다.

세 번째는 주권 경계 내에서 운영되는 AI 운영 플랫폼이다. 모든 로그와 추적 데이터를 중앙 플랫폼으로 전송하는 대신 서비스 관리, 보안 모니터링, 장애 대응 등 운영 시스템 자체를 동일한 관할 환경에 구축해야 데이터 주권을 유지하면서도 안정적인 IT 운영이 가능하다고 설명했다.

오픈텍스트는 한국 역시 이러한 규제 흐름에 포함된다고 분석했다.

국내에서도 개인정보보호법, 클라우드 보안인증제(CSAP), 금융분야 인공지능 가이드라인 등 데이터 보호와 AI 거버넌스를 강화하는 제도들이 마련되면서 기업의 AI 운영 환경에도 변화가 요구되고 있기 때문이다.

오픈텍스트는 국내 규제 환경 역시 데이터 저장 위치를 넘어 AI 추론 수행 위치와 데이터 격리 방식까지 요구사항이 확대되고 있으며, 이에 따라 기업의 IT 운영 전략 전반에 변화가 요구되고 있다고 설명했다.

AI 운영 제품군으로 데이터 주권 지원

오픈텍스트는 이러한 요구에 대응하기 위해 오픈텍스트 옵저버빌리티 앤 서비스 매니지먼트(OpenText Observability and Service Management) 제품군을 제공하고 있다. 이 제품군은 오픈텍스트 AI 오퍼레이션스 매니지먼트(OpenText AI Operations Management), 오픈텍스트 서비스 매니지먼트(OpenText Service Management), 오픈텍스트 유니버설 디스커버리 앤 CMDB(OpenText Universal Discovery and CMDB) 등으로 구성된다.

오픈텍스트 AI 오퍼레이션스 매니지먼트는 AI 기반으로 장애를 사전에 탐지하고 근본 원인을 분석해 운영 가시성을 높인다. 오픈텍스트 서비스 매니지먼트는 서비스 관리와 장애 대응, 운영 자동화를 주권 경계 내에서 수행할 수 있도록 지원한다. 오픈텍스트 유니버설 디스커버리 앤 CMDB는 클라우드와 온프레미스 자산 및 서비스 구성을 통합 관리해 AI 운영의 기반 정보를 제공한다.

오픈텍스트는 AI 플랫폼이 관할권 경계를 준수하면서도 가시성과 거버넌스, 통제력을 유지하도록 설계될 경우 데이터 주권과 운영 안정성은 상충하는 과제가 아니라고 설명했다. 또한 AI 도입을 확대하는 기업은 규제를 우회하는 방식보다 AI 추론과 모니터링, 서비스 관리 전반을 처음부터 주권 경계 내에 구축하는 전략이 장기적인 경쟁력 확보에 도움이 될 것이라고 밝혔다.
dl-ciokorea@foundryco.com

*이 기사는 스폰서십 콘텐츠입니다.

Operationalizing Agentic AI: from assisted to autonomous

Mon, 06 Jul 2026 16:54:43 +0200

Ever since ChatGPT made its public debut nearly four years ago, governance and security have largely lagged behind AI adoption.

Eager to experiment with AI tools and find ways to improve their work and personal lives, users have uploaded corporate data, financial records, and even their own health information to large language models (LLMs). While this freewheeling activity presents obvious risks, many users and businesses have so far been spared from catastrophic consequences.

Stephen Wilson, field chief technology officer for HashiCorp, an IBM company, notes that most people are still using AI tools largely as “assistants,” with the technology only taking action at the direction of human users. But, as AI agents are given more ability to act on their own, the risk calculus is changing. And so far, Wilson says, security and governance practices aren’t keeping up.

“Right now, what’s happening is that organizations are starting to use AI tools as full partners but governing the tools the same way they did when they were only using them as assistants,” Wilson says. “When AI is an assistant, the user is very close to the execution, and they’re handing over API keys, social media credentials, and bank information. But now we’re starting to ask AI to do things on our behalf autonomously.”

As organizations move from assisted use cases toward more autonomous workflows, Wilson says, they need to mature their governance models across three common adoption patterns: AI as assistant, AI as an agent, and AI as operator.

AI as assistant

The most basic and widespread form of enterprise AI adoption is AI as an assistant. In this model, a human remains close to the work, using the technology to summarize information, draft content, generate code, and complete other discrete tasks. The user enters a prompt, evaluates the response, and decides what to do next.

Although humans remain close to the execution at this stage, activity is not free from risk. When users interact with AI assistants, they can easily bring sensitive data, credentials, or permissions with them into the workflow. A user with privileged access might paste an API key into a prompt or even ask an LLM to analyze confidential records.

“You need to have a very tight handoff from the human identity to the machine identity,” Wilson says. “You also need to be able to govern what that machine can access from a machine-to-service perspective, because if I get elevated privilege, it’s not hard to inject that privilege into the context window.”

At the assistant stage, organizations largely need to ensure that AI activity is governed by the same boundaries already established for users. But as AI moves from answering prompts to completing work, those governance boundaries must expand.

AI as an agent

At this stage, human users begin asking AI tools to complete certain tasks autonomously. For example, instead of going back and forth with an LLM to outline and draft a piece of content, a user might simply give an AI tool a set of inputs and basic instructions and then ask the tool to generate the piece on its own. In fact, the writing agent may even pass off the finished draft to an editing agent or other AI tools before coming back to a human user.

“When that happens, the governance controls and the identity and auditability have to go up because you’re moving the human out of the loop even more,” Wilson says. “With AI assistants, the human is still the initiator of the request that happens back and forth. But with AI as agent, you’re making a request and then just letting it run.”

At this stage, Wilson says, organizations must determine what level of access different agents need to complete certain tasks, as well as how to confer identity upon AI agents. “How do you manage the persona? How do you accelerate its ability to be more correct often? These are the things you have to think about as you start to move to AI as an agent.”

AI as operator

This is the stage where AI agents take on not just individual tasks but entire projects. Instead of prompting agentic tools to write and edit a single article, an organization might ask a team of AI agents to design and execute an entire marketing campaign.

“The human comes back in two or three hours and has the entire project, including where to publish, individual social media posts, and engagement strategies,” Wilson says. “The level of governance and identity and auditing have to increase as your level of oversight decreases.”

Wilson notes that it is important at this stage to establish strong governance not only around data access but also around accuracy. For example, if an AI agent creates social media content, the organization needs to know that the content uses approved messaging, moves through the right review process, and is published only through authorized channels.

This is a complex challenge because AI agents are probabilistic systems, while many enterprise workflows are deterministic. Before giving agents the power to complete these workflows, Wilson says, leaders must think carefully about where AI-generated work should end and controlled execution should begin.

The road ahead

Most organizations are only beginning to deploy agentic AI beyond the assistant stage, and Wilson notes that security leaders are still debating the right governance, identity, auditability, and observability models for these systems.

But the overarching governance demand is clear: As AI systems gain more autonomy, organizations must implement more rigorous controls. An AI assistant can be governed largely as an extension of the individual user. An AI agent must be governed as part of a team, with clear visibility into the work it performs and the systems it touches. And an AI operator must be governed as a business function, with controls that span data access, workflow execution, approvals, and audit trails.

“Your scope of governance, identity, and observability has to increase at the same rate as if you were moving from an individual to a team to an organization,” Wilson says.

To learn more, visit us here.

Identity: The operational control plane for agentic AI

Mon, 06 Jul 2026 16:54:41 +0200

Existing security controls weren’t designed for AI agents.

Static credentials and standing privileges aren’t sufficient for an emerging model where organizations need to rapidly authorize, limit, and revoke permissions from autonomous agents, sometimes more than once within a single workflow.

Agentic AI requires organizations to carefully consider how to govern agentic identity, agent-to-agent communication, secrets management, privileged access, and workforce identity.

Agentic identity

The first challenge is to establish a reliable identity for agents themselves.

The “how” here is still being hotly debated. Some organizations treat AI agents as another form of non-human identity, similar to service accounts or machine identities. Others argue that agents should be their own category, distinct from both human users and machine accounts.

In any case, agents need something like a “certificate” to give them an identity that can be recognized and governed across environments. This is especially important because, in most enterprises, agents will operate across multiple environments, including cloud platforms, on-premises systems, and SaaS applications.

Agent-to-agent communication

Securing agentic AI requires organizations to limit not only which resources AI agents can access, but also which other access-enabled agents they can communicate with. This is often currently handled with Model Context Protocol (MCP) gateways, although this approach is largely giving way to the use of agentic mesh.

An agentic mesh is a distributed architecture where multiple specialized AI agents can discover one another, coordinate, and collaborate on tasks without a central controller. This approach lets organizations overlay intent-based communication rules via certificates, but also allows permissions to be revoked on demand.

Agentic secrets

Traditionally, secrets like passwords and API keys are managed via requests through IT service management platforms. But this mechanism doesn’t work for AI agents, which operate too quickly and across too many systems to rely on static credentials.

Instead, secrets should be generated dynamically, used for a specific purpose, and then retired when the task is complete. This approach can be compared to modern hotel key cards. Unlike the physical room keys of the past, a key card is issued for a specific stay, but after that, it becomes worthless to both legitimate users and malicious actors.

Privileged access

AI agents may start with the same permissions as a given human user, drawing on relevant business systems and data for context. However, as workflows get handed off from agent to agent, this privilege should not be passed along throughout the process. Rather, privileges should be whittled down at each stage until only a thin layer remains to authorize a specific execution step.

Workforce identity

Organizations already manage the identities of human workers, of course, but often these identities are handled differently across separate management platforms and sign-on tools. To support agentic AI, organizations must find ways to break through this fragmentation, ensure that worker identities are current, and translate workforce permissions correctly into agentic workflows.

A lifecycle approach to identity

These five areas should not be addressed in isolation. Rather, organizations should apply governance and observability across the identity lifecycle, ensuring that every agentic action can ultimately be traced back to approved access and permission levels.

The outcomes of this effort—including dynamic access, the principle of least privilege, strong identity, and clear auditability—are goals that many organizations have long been pursuing. The rise of agentic AI makes them more urgent than ever.

To learn more, visit us here.

6 ways to make AI accountability stick

Mon, 06 Jul 2026 13:04:49 +0200

As intelligent systems move into production environments and begin taking actions, organizations quickly discover that accountability becomes much harder. Unlike traditional enterprise software, these tools can produce unpredictable outcomes as they interact dynamically with data, APIs, and business workflows.

“When something goes wrong with AI, it is generally assigned to whoever was closest to the pain point,” says David DuChene, manager of data and AI pre-sales at SHI International, which works with enterprises on AI deployments and governance.

As these systems shift from advisor to actor within workflows, accountability becomes harder to enforce through policies alone. IT leaders must build it directly into the fabric of their operations through clear ownership, continuous observability, defined escalation paths, and infrastructure designed to make responsibility visible when things go wrong.

Here are six ways to make AI accountability enforceable in production.

1. Assign direct ownership from the beginning

Many enterprises still view AI accountability as a shared responsibility, but some experts argue that this is the first assumption to fail when systems enter production.

“Shared accountability is not accountability,” says Joe Wilson, SVP and CIO of CSG, a customer experience, billing, and payments software provider. “You need a direct owner.”

He says that at CSG, AI initiatives go through governance reviews involving executive leadership, and direct ownership is assigned at the start of projects. Wilson, who oversees the AI governance and deployment strategy for CSG, says the company also created “CIO reps” embedded inside business units and product groups to ensure accountability spans the entire lifecycle of AI initiatives.

According to SHI’s DuChene, many enterprises still lack formalized accountability structures for those environments. “They may have responsible parties on paper, but once a system actually breaks down, everything gets relitigated,” he says. “It goes back to who’s closest to the pain point.”

One diagnostic question, he argues, reveals whether organizations are truly prepared: “If your AI deployment generates a wrong answer and costs the business money tomorrow, who’s going to write the postmortem?”

If leaders cannot answer that question quickly, accountability structures likely don’t yet exist in practice.

2. Build governance before scaling deployments

In the past few years, many enterprises deployed AI systems before establishing the governance and operational foundations necessary to support them safely. “The biggest gap we see is a sequencing problem,” says DuChene. “We’ve gone around and built a bunch of houses where we’re standing up the walls before we’re pouring the foundations.”

That sequencing problem creates expensive retrofitting efforts later. DuChene says teams frequently discover they lack data classification systems, AI-aware identity and access controls, lineage and provenance tracking, audit capabilities, and escalation channels for failures.

According to Seth Dobrin, CEO of deterministic AI model maker Arya Labs and former global AI leader at IBM, governance often fails because organizations treat it as a policy layer rather than something embedded directly into operational workflows. “How do you integrate it into the workflow?” he asks. “If you don’t get that right, it’s going to fall apart.”

Dobrin recalls working with an insurance company that spent 18 months building an intelligent system before legal teams blocked deployment entirely. The problem was not the technology itself, but the absence of governance early in the process. “They had to throw it away,” Dobrin says. “Had they started earlier, they would have steered it to a place where they could have gotten to yes.”

Dobrin says governance should not slow projects down. Instead it should be integrated deeply enough into workflows that teams can move quickly without downstream compliance or operational failures. “The objective should never be to say no,” he says. “It should always be to figure out how to say yes.”

Wilson at CSG makes a similar point, arguing that governance should help teams absorb complexity rather than simply restrict what they can do. He compares it to a vehicle suspension system rather than a braking mechanism. “Our intention is not to slow things down,” he says. “Our intention is to speed stuff up, but also when you get into rough terrain, to be able to navigate that terrain.”

3. Treat data governance as the foundation of accountability

According to Wilson, CSG focused on governing its data before scaling AI initiatives across the business. Those efforts started with data synchronization and privacy impact assessments.

“The foundation is data,” Wilson says. “If we don’t have clean, synchronized, and governed data across the board, we’re not going to win this battle.”

Many organizations underestimate how difficult it becomes to maintain accountability once AI systems begin interacting with fragmented enterprise data environments, says Quais Taraki, CTO of EnterpriseDB, a company that works with enterprises on data infrastructure and governance.

An AI assistant summarizing customer interactions, for example, may pull regulated or confidential data from systems that were never intended to feed generative AI tools.

Strong data governance practices — including lineage, provenance tracking, classification systems, and access controls — not only help head off such problems but also create the foundation for accountability when something does go wrong. Otherwise, teams struggle to determine what data an AI system accessed, how outputs were generated, and whether sensitive information influenced a decision.

“Without lineage and provenance, you can’t do root-cause analysis,” Taraki says. “You won’t know what to change, or how things mutated in ways you didn’t expect.”

Taraki argues that accountability should follow governed data products rather than organizational silos. When ownership is split across infrastructure teams, data scientists, and application developers, responsibility can become difficult to establish after failures occur. Assigning clear ownership to the data products that feed AI systems helps create accountability throughout the AI lifecycle.

4. Build observability into (and beyond) AI systems

Traditional enterprise monitoring systems were designed primarily to track uptime, infrastructure health, and application performance. AI introduces a different challenge: tracing reasoning paths, decision chains, and behavioral drift.

Nik Kale, a member of the Coalition for Secure AI (CoSAI) and participant in AI security and agent identity standards efforts, describes this through what he calls an “Investigation Graph.” This is a reasoning trail showing what an AI system observed, what tools it accessed, what conclusions it reached, and what actions it ultimately took.

“When something breaks, the first instinct is always to ask, ‘Why did the AI make that decision?’” Kale says. “Honestly, I think that’s the wrong question. The right question is, ‘What did the system actually do?’”

That distinction is increasingly important because AI failures rarely originate from a model alone. Instead, they emerge from interactions between models, credentials, APIs, workflows, policies, and downstream systems.

“The model didn’t act,” Kale says. “The system around the model acted.”

That broader view of accountability is also changing how IT leaders think about observability. Rather than monitoring AI models in isolation, enterprises increasingly need visibility across the systems those models interact with, including data sources, APIs, applications, security controls, and downstream workflows.

In practice, that starts with comprehensive logging of prompts, model outputs, tool calls, data access events, and agent actions. Combined with traditional application and infrastructure telemetry, those logs create an auditable record of how AI systems behaved and why decisions were made.

That visibility becomes especially important when IT leaders try to identify unauthorized AI usage. While governance policies define which tools employees should use, observability helps reveal which tools they are actually using. Unusual data access patterns, unexpected API calls, traffic to external AI services, and unexplained movement of sensitive data can all be indicators of shadow AI.

Even well-governed organizations can struggle when employees adopt unauthorized AI tools outside approved workflows. “If it’s shadow IT, we don’t even know it exists,” says DuChene. “We don’t know what data of ours is going into it, how it’s being used, or how it’s being distributed.”

By extending observability beyond AI models to the broader enterprise environment, IT can detect those activities earlier, investigate them more quickly, and reduce the accountability gaps that shadow AI creates.

5. Create ‘escalate’ and ‘stop’ mechanisms

The most important accountability question may not be what an AI system can see or do, but when it should stop and ask for help.

According to Kale, that’s often the most underdeveloped part of enterprise AI deployments. “Most enterprises have figured out how to monitor their AI systems,” he says. “But nobody has really built the third piece, which is, when does the system actually stop and ask for help?”

Kale argues that enterprises need explicit escalation paths, human decision points, and clearly defined stop mechanisms for systems operating in production.

“You don’t want a rubber stamp — you want a human in the loop,” he says, adding that the human should be named and have the authority to say no.

According to Wilson, incident response processes also need to evolve, because AI failures behave differently from traditional IT outages. “A traditional IT incident typically looks like it’s an up or down scenario,” he says. “AI failures are a little more subtle than that.”

Models may drift gradually, outputs may degrade over time, or workflows may begin producing unexpected results without systems technically failing. The result, says Wilson, is a growing need for multidisciplinary response processes involving legal, communications, security, audit, business teams, and IT operations simultaneously.

6. Treat AI systems more like workers than software

Some enterprises still govern AI like traditional applications. But according to Kale, AI systems behave more like workers and less like deterministic software.

“You cannot just deploy once and be done,” he says. “Like workers, they need ongoing oversight.”

That ongoing oversight is becoming a core accountability function. Employees are not hired, trained, and then left unsupervised indefinitely. Managers monitor performance, provide feedback, evaluate changing responsibilities, and intervene when behavior drifts from expectations. Kale argues that AI systems increasingly require similar treatment.

Traditional software can often be reviewed and approved at release time because its behavior remains relatively stable between versions. AI systems are different. Models evolve, prompts change, retrieval systems are updated, and the information available to agents changes continuously.

That challenge extends beyond internally developed systems. Enterprises must also monitor the third-party AI services they rely on. Not only do vendor models evolve on their own, but vendors also update software and capabilities behind the scenes.

“The vendor we approved last quarter is functionally a different vendor this quarter,” Kale says.

As a result, accountability cannot end when a system is deployed. Someone must remain responsible for monitoring performance, reviewing changes, assessing risk, and determining whether systems continue to operate within acceptable boundaries. Kale points to CoSAI’s AI Shared Responsibility Framework as one emerging effort to clarify those responsibilities across enterprises, software vendors, model providers, and infrastructure operators.

The organizations making the most progress are discovering that accountability cannot be assigned on paper and forgotten. As AI systems become more autonomous, accountability is becoming an operational capability built into data governance, observability, escalation processes, and ongoing oversight. For IT leaders, the challenge is no longer defining responsibility. It is making responsibility enforceable.

Related reading:

Why developers are over the cloud

Mon, 06 Jul 2026 12:19:48 +0200

You can be forgiven if you think the most important thing AWS ever sold developers was EC2. It’s not. No, AWS’s big gift to developers was permission to stop fretting about servers. That sounds obvious now, but it was close to magical at the time. Before the cloud, getting infrastructure meant waiting on procurement, hardware, and the somewhat arcane process that stood between a developer and a running machine. AWS turned that into a credit card and an API.

It was awesome.

AWS still (over)uses a great phrase for what it removed: “undifferentiated heavy lifting.” That is, all the mess associated with racking servers, patching operating systems, managing storage, planning capacity, etc. Important work, sure, but not the work that makes your application special. Let AWS do that, the company intoned, and developers could focus on the thing their customers actually cared about.

It was a brilliant abstraction. It helped build one of the most important technology companies of the past two decades. It’s also the same logic that increasingly makes the cloud seem superfluous. Not because the cloud is dying. It isn’t. The cloud is bigger and more essential than ever. But developers don’t begin by asking, “Which cloud should I use?” They begin with, “How quickly can I get this thing working?”

That is a different question, and it leads to different tools.

Where to begin?

Let’s get the obvious thing out of the way: AWS remains the biggest developer cloud, and its revenue growth has accelerated in the wake of AI. In the 2024 Stack Overflow Developer Survey⁠, AWS was the top cloud platform, used by 48% of respondents. Microsoft Azure and Google Cloud followed at 27.8% and 25.1%, respectively.

The 2025 Stack Overflow Developer survey⁠ is more interesting, however, because the “cloud development” category no longer reads like a clear cloud-vendor horse race. Docker jumped 17 points to 71% usage, followed by npm and then AWS at 43%. Kubernetes, Azure, Google Cloud, Cloudflare, Terraform, Firebase, Vercel, Netlify, and Supabase all show up in the same mental map.

This is my point: Developers aren’t simply choosing a different cloud first. Often, they’re not choosing a cloud first at all. They’re choosing a workflow, and a workflow is an increasingly separate decision from the underlying cloud.

The first mile moved

For a long time, AWS owned the first mile. If you wanted to build something, you opened an AWS account. Need compute? Launch EC2. Storage? S3. Whatever a developer needed—database, queue, function, CDN, identity layer—AWS, the “everything store,” almost certainly had an answer.

It was magical! Then it became the norm. And, over time, it became a lot. The “everything store” arguably had too much, making it hard for developers to know how to use it effectively. The developer’s question became, “How much AWS do I have to understand before I can ship?” Developers increasingly don’t want to answer that question at the start.

The first mile now often begins in GitHub⁠, which says more than 36 million developers joined in a single year. Or it begins in VS Code, which keeps winning because it’s familiar, extensible, and already open. Or it begins in Cursor, GitHub Copilot, Claude, Codex, and the broader AI coding layer. GitHub’s 2025 Octoverse⁠ says nearly 80% of new developers on GitHub use Copilot within their first week. Stack Overflow’s 2025 AI survey results⁠ point the same way, with 84% of respondents using or planning to use AI tools in their development process, up from 76% in 2024.

The starting point is changing. The default interface to building software is becoming an AI-assisted workflow, not a cloud console. This doesn’t make the cloud less important, but it definitely makes it less visible.

The joy of not caring

The developer platforms with momentum right now are winning because they expose less cloud infrastructure. Call it serverless if you like, but it’s deeper than AWS Lambda ever was. AWS Lambda still made you think in AWS. These new platforms make you think in your app.

Take Vercel⁠. It didn’t win developer mindshare by offering more than 200 services and praying developers would navigate them all. Instead, it attached itself to the way many front-end and full-stack developers already work: GitHub, Next.js, previews, deployments, performance, and a short path from code to live application. It seems to be working: Reuters reported last year that Vercel raised $300 million at a $9.3 billion valuation⁠, after doubling its user base and growing revenue 82%.

Cloudflare offers a similar promise from a different angle, as I’ve written: deploy globally, run close to users, scale automatically, and don’t make infrastructure the developer’s first problem. Supabase⁠ does the same for data, wrapping Postgres with authentication, instant APIs, edge functions, real-time subscriptions, storage, and vectors so the database feels less like a separate system and more like an app platform.

None of this is anti-cloud. But it’s very definitely stripping away the need to even think about cloud. And it’s just as definitely where developers are focused today.

AI accelerated all of this because it changed the first question developers ask. For an AI application, the opening move often isn’t where do you host it, but rather which model, which agent framework, etc., will get you to a live application fastest? For this reason, OpenAI’s developer platform⁠ isn’t framed as renting infrastructure. It’s framed as building with models, APIs, tools, docs, and examples. Similarly, Anthropic’s Claude Code⁠ isn’t positioned as configuring a cloud environment; it’s an agentic coding system that works in your code base and helps you build, test, and ship.

The second mile matters more

I’m not saying the cloud vendors should abandon hope. Indeed, though the first mile has moved away from the hyperscalers, the second mile is still very much theirs to win.

Vercel, Cloudflare, Supabase, OpenAI, Anthropic, and GitHub are brilliant at helping developers make something work, fast. But in the enterprise, “fast” isn’t the key priority: Enterprises eventually need the boring stuff like identity, network controls, observability, cost management, compliance, and the rest of the unglamorous apparatus that keeps customer data from leaking onto Reddit.

Boring is good when boring means the thing works.

This is where AWS, Azure, Google Cloud, Oracle, and other infrastructure companies should have an advantage. But it won’t be enough to say, “We have the grown-up features.” That’s true, but it’s dull, and in this case, “dull” isn’t a winning proposition. No, the strategic challenge for the hyperscalers is to make the jump from prototype to production feel like an upgrade instead of a punishment.

AWS’s new $1 billion investment in forward-deployed AI engineers⁠ is interesting for exactly this reason. AWS says the new organization will embed experts with customers to co-develop and deploy agentic AI solutions in days. That’s not classic bottom-up developer love, but it’s a smart recognition that the bottleneck has moved closer to the application. The hard part is turning capability into a working system, not merely getting access to infrastructure or a model.

Yep. Exactly.

Hiding the cloud

The mistake for cloud infrastructure companies would be to respond to this by trying to become a Vercel, Supabase, GitHub, OpenAI, or Anthropic all at once. That’s the classic incumbent move, and it rarely works. The better move is narrower: become the most natural next step when the prototype starts to matter.

That means meeting developers where they work: GitHub, VS Code, Cursor-style environments, CI/CD systems, and AI agents. It means outcome-native starts: deploy this app, connect this data, expose this API, add auth, evaluate this agent, secure this workflow, move this prototype into production. It means fewer scavenger hunts across product pages and establishing more golden paths (yes, even if that infuriates a service team that gets left out).

The old question was, “Can you run my workload?” For AWS, Azure, Google Cloud, Oracle, and others, the answer is almost always yes. But no one is impressed by this anymore. Therefore, the better question is, “Can you become part of how I build?”

Developers came to the cloud because it was the easiest way to get infrastructure. They’re shifting to developer experience platforms because those are the easiest way to get outcomes. If the cloud providers can become part of the first mile before the Vercels of the world become part of the second mile, they’ll win, and big. If they don’t, well….

Why AI agents will make your governance playbook obsolete

Mon, 06 Jul 2026 11:03:53 +0200

Large Australian banks have started implementing agentic AI at scale this year. The same is happening across the country’s larger enterprises. These are not pilots, but production systems that are the tip of a global trend. Research company Gartner expects 40% of enterprises to embed AI agents in applications by the end of 2026, up from less than 5% in 2025 — an eightfold jump in 12 months.

Most governance teams at enterprises are responding to these changes by building playbooks as they always have: through committees, policies, approval gates and periodic audits. It’s a model that assumes humans review most decisions and that governance is a central function that sets and enforces all the rules. None of those assumptions holds for AI agents. The playbook most organisations are drafting at this moment is already obsolete before it is even finished.

In our view, three central changes must happen together for AI governance to work in environments where agents are used at scale:

Enterprises need agents’ behavioural telemetry, which they currently lack, to better understand what the bots are doing from a quality, compliance and cost perspective.
They need controls that operate at the speed of the systems they govern, which means AI helping govern AI.
They must distribute accountability across the organisation, because no centralised system can keep up with what is happening.

Find it and measure it

“You cannot govern what you cannot measure” sounds like a platitude, but most enterprises do not yet know how to measure AI agents’ actions. For instance, what counts as normal agent behaviour? What telemetry tells you that an agent is drifting from its original scope? What does an incident look like when it is not a single breach but four hundred micro-decisions, each individually defensible, that add up to an outcome you would never have approved or anticipated?

Businesses are still working this out. In the meantime, they are building and deploying agents without the capacity to see or understand in detail what they are doing.

A 2026 Gravitee survey found that only 24.4% of organisations report having full visibility into how AI agents communicate with one another. Almost nine in ten (88%) have reported “confirmed or suspected” agent security incidents in the past year. Despite that, 82% of executives say they are confident that existing policies protect against unauthorised agent actions.

These numbers indicate a widening gap between confidence and risk whenever AI agents are deployed. In my experience working with enterprise clients across the region, this gap is not a matter of negligence. Most governance teams are doing what they have always done well. The problem is that the systems they are now responsible for are behaving in ways their existing tools were never designed to detect.

Visibility matters because policy, control frameworks and ethics boards are all scaffolding that collapses without behavioural data that can be analysed and acted upon. You cannot write a meaningful policy for a system whose normal actions and performance you have never characterised or audit an agent whose decisions you cannot investigate or understand.

In this context, observability means instrumentation, baselines, anomaly detection on agent behaviour and telemetry that humans can interpret.

Governance at machine speed

Once you can see and understand what agents are doing, the next problem is how to manage them at scale. When the average enterprise runs 12 agents, as Salesforce’s 2026 Connectivity Report suggests, human oversight is still feasible. When leading deployments are already running into the hundreds — IQVIA has deployed more than 150 agents, for example — that approach stops working.

We don’t necessarily need a completely new security framework, but the updated model must allow companies to operate non-human interactions at scale with confidence. And the only way to ensure this is to use AIs to govern other AIs, because it is not economical to rely solely on humans to do the work.

This agentic AI governance model needs to monitor agentic behaviour and respond within milliseconds when needed. It must provide situational awareness and key insights to support informed decision-making.

Humans are responsible for establishing the parameters and guardrails, but they only intervene on demand and spend most of their focus on continuously improving their AI governance capabilities and the governance agents.

Distributed accountability

If governance must be observed continuously at machine speed and at a high level of complexity, no single function can do it all. That is why another essential change is organisational, with accountability distributed by design.

Today, most businesses use a centralised model that no longer works. Legal owns policy; security focuses on runtime monitoring and response; developers build controls into the agents themselves. The problem is that each function is limited in its own way.

Security can monitor telemetry data, for instance, but lacks insight into what each agent is supposed to do and therefore cannot develop customised anomaly-detection controls.

Closing the gaps in the overall systems requires understanding a specific approach to building agents. Developers cannot simply ship unmanaged agents that operate in stealth mode. They need to send key metrics to a centralised AI governance layer. To enable this layer, a clear shared responsibility model between the developer and governance functions must be defined. Developers are required to implement reporting hooks that generate data to create key metrics and task-specific insights and detect anomalies across clearly defined governance domains.

The centralised AI governance layer analyses this incoming data from the agents and provides situation awareness across all deployed AI agents. Guardrails that are baked into AI agents can’t be trusted, as they have proven to be vulnerable to prompt injection attacks. That is why an independent AI-powered governance layer is required to supervise all agent behaviour and provide insights and key metrics to key stakeholders.

Distributed accountability like this is hard to set up. It requires an understanding of the reasons behind the changes and an agreement between many stakeholders on how the new model must operate and where different responsibilities lie. It also needs a shared language across functions that have not historically worked together at this pace and clarity about who decides what when something goes wrong. But it is the only model that survives an environment with AI agents deployed at scale.

Faster decisions, new mindset

One way to think about these changes is to reflect on cloud adoption over time. That experience showed us that investing in governance and assurance early reduced risks and created a competitive advantage for the businesses that understood why they should do it. The same dynamic is playing out with AI agents, only faster, more distributed and very likely at a much larger scale.

Managing security, compliance, privacy, responsible AI, quality and cost in an agentic world at machine speed hasn’t been done before. Vendors help innovate on the customer’s behalf and can offer building blocks for this governance layer. But organisations also need to consider creating AI-powered custom capabilities to fill their processes and observability gaps. AI governance teams, therefore, require engineering capabilities and an agentic development environment that is tightly integrated with out-of-the-box AI security and compliance solutions.

What I see across the market right now is that the professionals responsible for governance have the expertise and experience to lead this shift. What they need is the confidence to rethink their operating model and recognise that the centralised control they are accustomed to will not scale for agentic environments. Good governance practices that consider people, processes and technology have always paid off in the long run. Now is the time to define the individual North Star for your AI governance layer, because retrofitting these capabilities will carry high risk and cost.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Private AI ist die smartere Strategie

Mon, 06 Jul 2026 06:07:46 +0200

Um sich vor potenziellen KI-Kostenexplosionen zu schützen, setzen immer mehr Anwender auf den Einsatz in der Private Cloud oder On-Premises.

Carsten Medom Madsen | shutterstock.com

In den letzten Jahren ging man in der Unternehmens-IT standardmäßig davon aus, dass KI denselben Weg wie viele andere Workloads einschlagen würde – und sich in der Public Cloud etabliert. Die Annahme schien auf den ersten Blick plausibel: Schließlich verfügen Hyperscaler über Infrastruktur, GPU-Kapazität, Managed Services und Entwickler-Ökosysteme. Wer schnell vorankommen wollte, für den schien KI in der Public Cloud lange die naheliegende Lösung zu sein.

Diese Logik wird nun durch die Realität in Frage gestellt. Unternehmen vollziehen mit Blick auf KI zunehmend den Schritt von Experimenten hin zum Produktivbetrieb. Dabei stellen immer mehr Anwender fest, dass die Public Cloud zwar ein komfortabler Ausgangspunkt ist – aber langfristig nicht die praktischste Lokation: Immer öfter kommt in Unternehmen die Frage auf, ob sie es sich leisten können, ihre KI-Strategie langfristig aufzubauen auf:

Kostenmodellen, die sie nicht kontrollieren,
Risiken, die sie nicht vollständig eindämmen können, und
Architekturen, die eher auf die Skalierbarkeit der Anbieter als auf die Wirtschaftlichkeit des eigenen Unternehmens optimiert sind.

Deshalb wird KI in der Private Cloud sowie On-Premises zunehmend populärer. Die Anwender wechseln jedoch nicht auf diese Lösungen, weil das gerade angesagt ist. Sondern, weil es in vielen Fällen die finanziell vernünftigste Entscheidung ist.

Wann schnappt die KI-Token-Falle zu?

Allgemein gelten Token-basierte KI-Preismodelle weiterhin als stabiles, ausgereiftes Geschäftsmodell. Das trifft allerdings nicht zu: Vielmehr handelt es sich weiterhin um ein stark von den Anbietern subventioniertes Umfeld, das von aggressiver Rabattpolitik geprägt ist. Marktanteile haben für die Anbieter dabei Priorität vor anständigen Margen. Das mag für die Anwender kurzfristig eine gute Nachricht sein. Es ist aber gefährlich anzunehmen, dass diese Bedingungen von Dauer sein werden.

Wenn Unternehmen ihre KI-Nutzung skalieren, kann der resultierende Token-Konsum schnell zu einem ernstzunehmenden finanziellen Risiko werden. Ein Chatbot-Pilotprojekt ist eine Sache. Eine unternehmensweite Applikation für Geschäftsprozesse, Kundeninteraktion, Wissenssysteme, Automatisierung, Analytics oder Embedded Software etwas ganz anderes. Die in der Pilotphase einst vertretbaren Gebühren für KI-Token verwandeln sich in diesen Fällen zu wiederkehrenden Betriebskosten. An diesem Punkt können dann selbst geringfügige Preisanpassungen erhebliche Auswirkungen auf das Unternehmensbudget haben.

In der Konsequenz überdenken viele Führungskräfte im Technologiebereich derzeit ihre Annahmen bezüglich der Kosten von KI. Dabei erkennen sie zunehmend auch, dass die aktuelle Preisgestaltung möglicherweise nicht die langfristigen Ausgaben widerspiegelt. Wenn die Subventionen auslaufen und die Nutzung zunimmt, dürften die Token-Kosten stark ansteigen und damit großangelegte KI-Implementierungen unter Umständen wirtschaftlich unrentabel machen.

Das ist die Falle, die Unternehmen vermeiden sollten: Kein CIO möchte erklären müssen, dass das Unternehmen KI zwar erfolgreich in Betrieb genommen hat – aber kein Geschäftswert entstanden ist, weil die Anbieterrechnung ihn aufgefressen hat. Ganz ähnlich ist es vielen Firmen bereits mit Blick auf die Cloud ergangen – denselben Fehler bei KI zu wiederholen, ist kein gangbarer Weg.

Hybrid AI – das natürliche Endziel

Es kristallisiert sich zunehmend heraus, dass die Zukunft der Enterprise-KI weder ausschließlich in der Public Cloud noch On-Premises liegt. Vielmehr ist diese Zukunft in vielen Fällen hybrid: Der Markt reift über ideologische Gräben hinaus und entwickelt sich in eine Richtung, in der Workloads auf der Grundlage von Wirtschaftlichkeit, Governance, Latenz und Kontrolle platziert werden.

Dieser Wandel ist bedeutsam, weil nicht jedes KI-Problem ein riesiges gehostetes Modell erfordert – im Gegenteil: Immer mehr Anwender stellen fest, dass kleinere, domänenspezifische KI-Modelle bei spezifischen Business-Tasks genauso gut und oft sogar besser abschneiden. Einige nutzen optimierte Modelle, andere setzen auf klassisches Machine Learning und prädiktive Systeme. Wieder andere kombinieren Retrieval-Techniken mit Small Language Models (SMLs). Und wieder andere entwickeln eingeschränkte Modelle, die strikt auf bestimmte Betriebsdomänen zugeschnitten sind. Diese Systeme sind für eine Private-Infrastruktur oft deutlich besser geeignet: Sie befinden sich näher an den Unternehmensdaten, lassen sich für vorhersehbare Workloads optimieren und gehen nicht mit einem, nach oben hin offenen, Token-basierten Abrechnungsmodell einher.

Das gilt insbesondere, wenn das KI-Modell häufig innerhalb von internen Geschäftsprozessen eingesetzt wird und nicht nur gelegentlich von einer begrenzten Anzahl von Nutzern. Mit anderen Worten: Unternehmen entscheiden sich nicht nur für Private AI, weil ihnen die Preisgestaltung der Public Cloud missfällt. Sie entscheiden sich dafür, weil sie lernen, KI-Systeme zu entwickeln, die den Anforderungen des Unternehmens entsprechen, anstatt sich standardmäßig auf das zu verlassen, was (von außen) am einfachsten zu nutzen ist.

Security und Governance als Zusatztreiber

Die Kosten von KI sind für die meisten Anwender zwar das drängendste Anliegen sein – aber nicht das einzige. Security und Governance entwickeln sich zu ebenso wichtigen Triebkräften, denn Anwenderunternehmen fühlen sich zunehmend unwohl bei dem Gedanken daran, dass sensible Informationen über öffentlich zugängliche KI-Tools, APIs und Benutzer-Workflows verarbeitet werden, die diffizil zu überwachen und zu kontrollieren sind.

Und diese Sorge ist nicht abstrakt: Regelmäßig halt vertrauliche Informationen in öffentlichen KI-Schnittstellen Einzug, weil die Mitarbeiter danach streben, ihre Produktivität zu steigern. So arbeiten etwa Dev-Teams manchmal schneller, als die Richtlinien Schritt halten können oder führen Geschäftsbereiche Tools erst einmal außerhalb der Governance ein. Das erhöht das Risiko für Datenlecks, Compliance-Verstöße und Sicherheitsvorfälle, die in direktem Zusammenhang mit dem KI-Einsatz stehen.

Zwar können Public Clouds ein hohes Maß an Sicherheit bieten, doch viele Anwender bevorzugen für sensible KI-Workloads strengere interne Kontrollen, um eine optimierte Observability, Zugriffskontrolle, Datenlokalität und Richtliniendurchsetzung zu gewährleisten. Private AI reduziert hingegen die Anzahl der Unbekannten: Sie gibt Unternehmen eine direktere Kontrolle darüber:

wo sich Daten befinden,
wie Modelle genutzt werden,
wer darauf zugreifen darf und
wie Systeme geprüft werden.

Das beseitigt das Risiko zwar nicht vollständig, sorgt aber dafür, dass es besser zu managen ist.

Private AI – der Aufwand lohnt sich

Die schlechte Nachricht: Private AI ist nicht trivial. Die Technologie On-Premises oder in der Private Cloud einzusetzen, erfordert:

Investitionen,
Planung,
spezielles Knowhow,
operative Disziplin, sowie
die Bereitschaft, einen größeren Teil der Infrastruktur selbst zu managen.

Anwenderunternehmen, die diesen Weg beschreiten, müssen sich zudem mit Infrastrukturdesign, GPU-Auslastung, Lebenszyklusmanagement, Modellbetrieb, Integration und Ausfallsicherheit auseinandersetzen – also die Aspekte, die bei Public Services oft abstrahiert werden. Dieser zusätzliche Aufwand birgt ebenfalls echte Risiken: Manche Unternehmen werden den betrieblichen Aufwand unterschätzen, andere werden zu viel für die Infrastruktur ausgeben – und wieder andere werden Schwierigkeiten damit haben, die richtigen Fachkräfte zu finden.

Aufgrund der möglichen Kosteneinsparungen sind jedoch viele Unternehmen inzwischen bereit, das auf sich zu nehmen. Diese Anwender steigen nicht auf Private AI um, weil es einfacher ist, sondern weil es auf lange Sicht klüger ist. Sie sind zu der Überzeugung gelangt, dass es besser ist, in eigene erfolgskritische Kapazitäten zu investieren, als diese über eine externe Plattform mit unklarer wirtschaftlicher Zukunft zu beziehen. (fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.

So spüren Sie kompromittierte KI-Agenten auf

Fri, 03 Jul 2026 06:07:33 +0200

Kompromittierte KI-Agenten sind nicht leicht zu erkennen. Lesen, wie es trotzdem klappt.

amgun | shutterstock.com

Im Juni 2025 veröffentlichte der prominente britische Softwareentwickler Simon Willison einen in der Security-Community vielbeachteten Blogbeitrag. Darin warnte der Experte, der im Jahr 2022 den Begriff „Prompt Injection“ geprägt hatte, vor einer tödlichen Dreierkombination („Lethal Trifecta“), die ausreichen um einen KI-Agenten mit nahezu hundertprozentiger Erfolgswahrscheinlichkeit durch indirekte Prompt Injection zu kompromittieren. Diese „Lethal Trifecta“ bei KI-Agenten manifestiert sich demnach im:

Zugriff auf private Daten,
dem Kontakt mit nicht vertrauenswürdigen Inhalten, sowie
der Fähigkeit zur externen Kommunikation.

Ein Angreifer, der schadhafte Anweisungen an beliebiger Stelle in dieser Inhalts-Pipeline einschleust, kann Daten exfiltrieren, ohne dass das überhaupt auffällt. Willison veranschaulichte diesen Punkt in seinem Beitrag mit einer langen Liste realer Exploits in Produktionsumgebungen. Das „tödliche Triple“ fungierte dabei zu einer Zeit als Security-Warnsignal, in der KI-Agenten einen meist eng begrenzten Anwendungsbereich hatten. Die Kombination der oben genannten Fähigkeiten zu vermeiden, schien eine tragfähige Designstrategie.

Das hat sich mittlerweile geändert: Ein kundenorientierter Support-Agent erfasst heute Ticketverläufe und Kundendaten, Benutzernachrichten sowie angehängte Dateien und ruft CRMs, Rückerstattungs-APIs oder Ticketing-Systeme auf. Ebenso lesen und beantworten KI-Agenten E-Mails, verwalten Kalender und Nachrichten. Das sind keine „Edge Cases“, sondern genau die Art von Agenten, nach denen Unternehmen und Privatanwender streben – und auf die die Anbieter hinarbeiten.

Das „tödliche Triple“ als neuer Standard

Ross McKerchar, CISO bei Sophos, bringt das Problem in einem eigenen Blogbeitrag auf den Punkt: „Die Funktionen, die Praktiker tatsächlich wollen, führen unweigerlich in gefährliches Terrain. Das ist keine Fehlkonfiguration, sondern der architektonische Preis für die Nützlichkeit.“

Damit liegt der Security-Entscheider richtig: Ein Agent ohne Zugriff auf private Daten ist nutzlos. Einer, der keine externen Inhalte verarbeiten kann, agiert isoliert. Und ein Agent, der nicht nach außen kommunizieren kann, ist handlungsunfähig. Nimmt man auch nur einen dieser drei Aspekte weg, steht im Ergebnis eher eine Suchleiste als ein KI-Agent. Wenn jede legitime Agentenarchitektur sämtliche Eigenschaften der „Lethal Trifecta“ aufweist, kann diese kein aussagekräftiger Indikator für erhöhtes Risiko mehr sein – sondern ist de facto die Standardkonfiguration. Sie weiterhin als Warnsignal zu betrachten, ist so, als würde man die DNS-Auflösung als Anzeichen für ein kompromittiertes Netzwerk werten. Technisch gesehen trifft das zwar auf einige Threat-Modelle zu, ist aber in jedem realen Deployment allgegenwärtig.

Die Antwort auf diese Situation beschreibt der Sophos-CISO in seinem Blogbeitrag als „Blast Radius Reduction“. Gemeint ist eine realistische operative Philosophie, die die „Lethal Trifecta“ als gegeben akzeptiert. Das wäre ein guter erster Schritt – allerdings stellt sich die Frage, was nach der Akzeptanzphase folgt. Das Security-Team von Meta gelangte zu einer ähnlichen Erkenntnis wie McKerchar, nur aus einer anderen Richtung: Im Oktober 2025 veröffentlichte der Konzern sein „Rule of Two“-Framework. Dieses sieht vor, dass KI-Agenten nicht mehr als zwei der drei Komponenten der „Lethal Trifecta“ aufweisen sollten. Sind alle drei Merkmale vertreten, wird eine menschliche Genehmigung erforderlich. Von der Idee war auch Simon Willison angetan, der das Meta-Framework im November 2025 als den besten praktischen Ratgeber bezeichnete, um sichere Agentensysteme auf LLM-Basis aufzubauen.

Mit Blick auf sein Framework räumt Meta allerdings auch Limitationen ein. Demnach passten diverse populäre Use Cases nicht nahtlos in das Rahmenwerk, wodurch Designs, die auf der „Rule of Two“ aufbauen, dennoch anfällig für Fehler sein könnten. Das ist nur die Bestätigung dafür, dass das Problem die Lösung auf Architekturebene bereits überholt hat. Denn das Ausmaß der Sicherheitslücken ist längst nicht mehr nur theoretischer Natur: So brachte eine Untersuchung des Common Crawl Repositories durch Sicherheitsforscher von Google diverse Prompt-Injection-Angriffe auf öffentlich zugängliche Webseiten ans Licht. Laut Google haben die Angriffsversuche dieser Art zwischen November 2025 und Februar 2026 um 32 Prozent zugelegt. Zwar stellten die Sicherheitsexperten fest, dass deren Reifegrad derzeit noch gering ist. Allerdings weisen sie auch darauf hin, dass der Trend ein klares Signal dafür ist, dass das Interesse der Angreifer zunimmt. Anders ausgedrückt: Das Umfeld, vor dem die „Lethal Trifecta“ einst gewarnt hat, ist zur Realität geworden.

5 Anzeichen für kompromittierte KI-Agenten

Wenn nahezu jeder eingesetzte KI-Agent die Merkmale der „Lethal Trifecta“ aufweist, benötigen Praktiker die richtigen Anhaltspunkte, um kompromittiertes Verhalten vom normalen Betrieb innerhalb eines Systems zu unterscheiden. Das erfordert einen Shift: Weg von Assessments auf Architekturebene und hin zu Behavioral Detection auf Laufzeitebene. Wie nötig dieser Umschwung ist, zeigte sich zuletzt im Januar 2026, als innerhalb von nur fünf Tagen vier verschiedene Exploits gegen populäre KI-Produktivitäts-Tools bekannt wurden. Betroffen waren IBM Bob, Superhuman AI, Notion AI und Claude Cowork. In allen vier Fällen setzten die Angreifer auf indirekte Promp Injection, um Daten zu exfiltrieren. Und zwar über einen Kanal, auf den der jeweilige Agent legitimen Zugriff hatte.

Im Fall von Claude Cowork sorgte ein in ein hochgeladenes Dokument eingebetteter, versteckter Prompt etwa dafür, dass der KI-Agent Dateien über die von Anthropic selbst auf die Whitelist gesetzte API-Domain exfiltrierte – unsichtbar für sämtliche Perimeterkontrollmaßnahmen und nicht von normalem Agentenverhalten zu unterscheiden, bis die Daten bereits gestohlen waren. Die vier Exploits hatten außerdem gemein, dass die „Lethal Trifecta“ Betriebsbedingung war.

Die folgenden fünf Signale können dazu beitragen, kompromittierte KI-Agenten zu erkennen:

Anomalien bei der Befolgung von Anweisungen: Ein kompromittierter Agent verhält sich in der Regel nicht grundlegend anders als ein intakter – er befolgt Anweisungen. Die Frage ist nur, wessen. Agenten-Aktionen, die keinen plausiblen Bezug zu einer vom Benutzer initiierten Aufgabe haben, sollten deshalb die Alarmglocken schrillen lassen. Ein Agent, der dazu aufgefordert wurde, einen Quartalsbericht zusammenzufassen, dann aber eine DNS-Anfrage an eine unbekannte Domain aussendet, hat sich dazu nicht spontan „entschlossen“ – er wurde dazu veranlasst.
Tool-Call-Sequenzen, die die erwartete Topologie durchbrechen: In einem gut konzipierten KI-Agentensystem sollte die Sequenz der Tool-Aufrufe für eine spezifische Aufgabe relativ vorhersehbar sein. Ein Programmier-Agent, der einen Bug fixen soll, muss Dateien bearbeiten, Tests ausführen und möglicherweise die Dokumentation überprüfen. Er sollte allerdings nicht auf E-Mail- oder Kalender-APIs zugreifen. Sobald die erwarteten Grenzen eines Workflows in diesem Rahmen überschritten werden, ist deshalb Skepsis angesagt: Solche Tool-Call-Sequenzen sollten als verdächtig markiert werden, selbst wenn jeder einzelne Aufruf für sich genommen legitim erscheint.
Exfiltration über Kanäle mit geringer Bandbreite: Der klassische Exfiltrationsangriff durch Prompt Injection leitet gestohlene Daten über einen Mechanismus weiter, auf den der Agent legitim zugreift – die URL eines gerenderten Bildes mit verschlüsselten Abfrageparametern, einen API-Call mit Daten, die in einem Parameter eingebettet sind oder einen Link in einem generierten Dokument. Für sich genommen sehen diese Aktionen nicht nach Datendiebstahl aus, sondern wirken völlig normal. Um eine Exfiltration erkennen zu können, sollte geprüft werden, auf welche Daten der Agent Zugriff hatte und was er in seinen Output eingebettet hat. Das erfordert wiederum, dass die Agentenaktionen durchgängig transparent sind – nicht nur der endgültige Output.
Zugriff auf Anmeldedaten und Secrets außerhalb des Task-Scope: Greift ein Agent mit legitimen Zugriffsrechten auf einen Secrets Store oder einen Key Vault zu, die in keinem Zusammenhang mit dem aktuellen Task stehen, ist das ebenfalls ein Warnsignal. Ein Agent, der einen React-Rendering-Fehler beheben soll, braucht dazu mit Sicherheit keine AWS-Anmeldedaten. Das Least-Privilege-Prinzip dient hier als architektonische Abwehrmaßnahme. Doch erst ein Monitoring, bei dem gezielt überprüft wird, ob „out of scope“ auf Login-Daten zugegriffen wird, kann solche Abläufe zu Tage fördern.
Anomalien bei Memory-Write-Vorgängen: Agenten mit persistentem Speicher stellen eine wachsende Angriffsfläche dar. Ein manipulierter Memory-Eintrag, der wie legitimer Benutzerkontext aussieht, könnte versteckte „Trigger Instructions“ enthalten, die Session-übergreifend erhalten bleiben und erst lange nach der eigentlichen Prompt Injection ausgelöst werden. Dagegen hilft, die Observability-Pipeline für KI-Agenten entsprechend auszugestalten: Memory-Schreibvorgänge sollten auf befehlsähnliche Inhalte überwacht werden. Ebenso müssen Schreibvorgänge, die im Rahmen von Sessions mit nicht-vertrauenswürdigen Inhalten stattgefunden haben, kritisch beäugt werden.

Für Security-Praktiker, die eine Agentic-AI-Infrastruktur im Produktivbetrieb managen, bestätigt die Entwicklung der „Lethal Trifecta“ zum neuen Standard nur das, was Sie ohnehin längst wissen: Ihre KI-Agenten sind gefährdet. Dieser Herausforderung ist auf Ebene der Runtime zu begegnen, nicht auf Architekturebene. Dort sind für traditionelle Architekturen EDR und SIEM angesiedelt. KI-Agenten benötigen dieselbe Instrumentierung – was auf die allermeisten Deployments bislang nicht zutrifft. (fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation CSOonline.com erschienen.

Enterprises lost Claude Fable 5 for a few weeks. New data shows two-thirds had already built their hedge

Fri, 03 Jul 2026 03:02:52 +0200

Two-thirds of enterprises have hedged their AI model strategy, and the past few weeks of controversy around Anthropic’s Claude Fable 5 model showed why that posture has gone mainstream.

On June 12, a U.S. export-control order pulled Anthropic's Claude Fable 5 — the most capable model on the market — offline for every customer, with no warning and no timeline. It returned this week wrapped in tighter safeguards, after China's Z.ai released its open-weights GLM-5.2 into the vacuum. New VentureBeat Pulse Research, which surveyed 145 enterprises across these last few weeks, shows that two-thirds had already hedged their model strategy before the order came down: 51% blend closed frontier models with open-weight models deployed on their own infrastructure, and another 16% are moving core workflows off closed APIs entirely. The remaining third was all-in on closed ecosystems when the lights went out.

The blackout put a spotlight on vendor dependency, by showing what happens when the model you rely on disappears. But vendor dependency is only the most visible piece of a deeper problem: Most enterprises lack the monitoring to know when an AI system they've put into production stops working correctly.

Just 1 in 10 enterprises has automated monitoring that would catch an AI model drifting, misbehaving, or failing in production. Roughly a quarter would learn of a production failure only when end users — internal or external — report it, or lack the visibility to detect it at all. And 79% of enterprise organizations have already taken a real financial or operational hit from autonomous agents — most often shadow AI, unauthorized agentic work run by enterprises' own employees on corporate credit cards, outside anyone's oversight.

We call this the “Control Gap,” or the distance between how aggressively enterprises are deploying AI and how little of it they can see, own, or govern. June’s blackout turned this into a live stress test.

About this data: VentureBeat Pulse Research surveyed 145 qualified respondents at organizations with 100 or more employees in June 2026, with fielding spanning the Fable 5 blackout that began June 12. The sample is self-selected and directional: 41% work in technology/software, 20% are consultants or advisors, and the respondent base skews senior and technical — CIO/CTO/CISOs (18%), directors of engineering/IT (14%), enterprise architects (12%). More than half of the respondents were from companies with 10,000 employees or more.

While our sample is not huge, what you can trust more than the exact percentages is the pattern: Every question in the survey, independently, points the same way, with deployment running ahead of governance, visibility, and cost control.

The full methodology is in the report.

How the Fable 5 export order rewrote enterprise AI risk

Fable 5 launched June 9 to immediate acclaim — and sticker shock, at $10 per million input tokens and $50 per million output. Three days later, the U.S. government issued an emergency export-control directive barring access by foreign nationals. Anthropic, with no way to verify nationality in real time, suspended the model for everyone.

Z.ai has continued to pick up momentum; on Wednesday it released an open agentic coding environment, called Zcode. OpenAI, meanwhile, previewed its cutting-edge GPT-5.6 line on June 26.

Enterprises had already spent the spring learning what AI dependence costs in dollars. Uber burned through its entire 2026 AI coding budget in four months after Claude Code adoption hit 84% of its roughly 5,000 engineers, Forbes reported. Microsoft canceled most internal Claude Code licenses in its Windows and Microsoft 365 division, steering engineers to its own tooling, according to The Verge.

June added the harder lesson: The model your workflows depend on can vanish overnight, by government order, through no decision of yours or your vendor's. And Chinese companies like DeepSeek were releasing hugely disruptive, powerful models, driving down costs to a fraction of Western ones.

Brian Craig, senior director of architecture at Liberty IT, the Ireland-based engineering arm of Liberty Mutual, one of the world’s largest insurance companies, saw both lessons collide in real time. Craig is Irish, which meant the export order hit him directly as a foreign-national user.

Onstage at VentureBeat's AI Impact event in New York on June 24, mid-blackout, I asked him about it. "Fable arrived, and immediately you saw the sticker price of using it, and you went, 'Ooh, goodness, it better be really good,'" Craig said. "But luckily enough, we didn’t get to use it enough to get to fall in love with it." Then it was gone.

The hedge was already built before the blackout hit

Craig's company was built to route around exactly this kind of disruption. Liberty IT runs what it calls an AI backbone — roughly 50 components spanning security, governance, observability, and orchestration, each independently replaceable.

"You can't lock in right now in one vendor and even one framework," Craig told the room. "You need to keep being able to have the flexibility with that backbone to be able to hook into different models, different vendors, depending not so much on who's the flavor of the day, but on what you can feel confident about for the next six months."

The survey shows Craig has plenty of company. A 51% majority of enterprises run a hybrid posture — closed frontier models for general reasoning, open-weight models deployed locally for specialized execution — and 16% are making a hard pivot, moving core workflows onto open weights running on their own hybrid or private cloud. The 32% holding a closed commitment are candid about why: The operational overhead of self-hosting still outweighs the savings for them. After June, that calculus has a new variable in it.

Defection is now the active posture, and the target may surprise you. Asked which primary AI vendor they are most likely to downsize or phase out over the next 12 months, respondents named Microsoft first at 30% — most citing cutbacks to Copilot and Azure AI frameworks in favor of direct model access — ahead of the 28% who plan to trim no vendor at all. OpenAI drew 21%, largely on pricing volatility, with Anthropic at 15% and Google at 6%. No vendor faces an exodus. But loyalty by inertia has ended: Among these enterprises, actively cutting at least one provider is now more common than expanding across all of them.

Just 1 in 10 enterprises would catch a failing production model automatically

How would an enterprise know if one of its production AI models was drifting, behaving unsafely, or failing to complete tasks? We asked directly. Forty percent say they are very confident they would detect it. The question also asked what that confidence rests on, and respondents split into two camps: 30% rely on humans reviewing critical AI outputs, and just 10% — 14 of the 145 organizations — have automated monitoring and alerting running against production systems. The remaining respondents hold weaker positions still: 32% expect to catch most issues "eventually," 19% say they would likely hear about a failure from end users first, and 8% report no systematic visibility into production AI behavior at all.

That distinction matters because the two approaches are very different. Human review may seem like the gold standard, but it only reaches the outputs someone designates as important for such a review — and it happens at the pace humans can move at, with the inconsistency any manual process carries. Automated monitoring watches everything the system produces, continuously, and flags anomalies as they happen — for the same reason enterprises stopped depending on manual checks for uptime and security a decade ago.

As agentic workloads multiply output volumes far beyond what any review team can read, the manual approach starts to fall behind. The leaders at our June 24 event in New York treat human review as a designed control with automation underneath it. "Nothing gets deployed into production unless it's a human actually reviewing it and signing off," Craig said of Liberty's agentic software factory, where planning, coding, testing, critic, and librarian agents ship features from epic to production.

"It always has to be risk-based. That's why we work for an insurance company." Todd Johnson, the Morgan Stanley managing director who runs agentic AI across the bank's end-of-day P&L controller process, described the same principle from finance: "One of our strong principles in our AI governance generally is that there always has to be human accountability, even if there's a degree of automation." VentureBeat covered Morgan Stanley's new results around its P&L resolution agent system separately.

Liberty Mutual and Morgan Stanley chose manual sign-off deliberately, layered on top of observability, identity, and governance infrastructure. Whether the human-review camp has similar infrastructure underneath is more than a single-select question can establish. The 16% who separately named missing observability tooling as their biggest governance barrier are the ones saying outright that it hasn't been built.

The top governance barrier is organizational: no single owner for AI across platforms

Why does the AI visibility tooling never get built? The respondents' answers suggest it is an organizational shortcoming. The single most-cited barrier to governing AI across platforms is the absence of a single owner or accountable team, at 32%. Vendor opacity follows at 25%, missing tooling at 16% — and a lack of talent lands dead last at 5%.

The skills exist, but the organizational mandate does not: Only 38% say a central team actually governs AI behavior across their platforms today, 21% say ownership is unclear or actively contested between teams, and 17% say no role holds formal accountability at all.

The AI surface being governed makes the vacuum worse. Fully 85% of enterprises run two or more platforms each claiming to be the "primary" AI layer — ERP, ITSM, productivity suite, data platform, each with its own AI, its own controls, and its own assumptions. 36% describe an open contest between four or more. Just 8% have consolidated to one. Asked in a free-text question what one thing they would fix, respondents converged from different directions on the same answer: a single accountable owner, and a control plane that abstracts cost, drift, and model choice away from the end user.

79% have already paid for an agent control failure — led by shadow AI

The cost of the vacuum is showing up on corporate cards.

Asked to name the most severe financial or operational control failure they have experienced from autonomous agents, 49% of enterprises cite shadow AI — departmental teams running unauthorized agentic pipelines on corporate credit cards, bypassing central financial oversight entirely. Another 25% have been hit by an infinite-loop bill, an uncaught recursive workflow racking up thousands in token costs in a single incident, and 6% by an agent that degraded production databases with unthrottled queries. Only 21% report guarded stability, with hard token throttling and budget caps at the infrastructure layer. Add it up: 79% of these enterprises have already paid for an agent control failure in real money or real downtime.

Finally, the economics of tokens suggest the pressure will keep rising. Per-token inference costs are falling 70 to 80% a year, and agentic workloads consume 100 to 500 times the tokens of the LLM tools they replaced.

Brian Gracely, senior director of portfolio strategy at Red Hat, told our New York audience the answer starts with right-sizing: "If I'm simply trying to resolve an insurance claim, I don't need to know about the history of Western civilization in my model. I don't need to know soccer scores."

Enterprises are pairing smaller, specialized models with semantic routing, he said, so the platform decides which requests genuinely need frontier-scale reasoning — and which are burning premium tokens on commodity work. (One adjacent data point from the survey underlines the appetite for pragmatism: 73% of enterprises report little or nothing to show for their custom fine-tuning investments of the past 18 months — a reckoning we'll examine in its own report.)

The bottom line: Replaceability is spreading faster than ownership

The survey describes enterprises moving fast on AI with weak controls underneath. 58% are adding more AI initiatives than they retire. 85% run multiple platforms that each claim to be the primary AI layer. Three times as many enterprises rely on human review to catch a failing production model as have automated monitoring in place. And 79% have already paid for an agent control failure — most often unauthorized agent spending on corporate cards, outside IT's oversight.

On one problem, enterprises have clearly adapted: model dependency. Two-thirds hedge their model strategy, either running open-weight models alongside closed ones (51%) or moving core workflows off closed APIs entirely (16%). The Fable 5 shutdown showed the value of that position — the hedged companies could route around a model that a government order made unavailable overnight.

The remaining problems are internal, and no purchase fixes them: 32% name the lack of a single accountable owner as their top governance barrier, and 17% say no role holds formal accountability for AI at all. Assigning an owner costs nothing and requires no vendor. It still hasn't happened at most of these companies.

Our coming Q3 wave of research will measure whether June changed this — whether enterprises assigned owners and installed automated monitoring, or just added a second model and moved on.

Get the full Control Gap report here.

The themes in this report — agent orchestration, governance, and cost control — are the agenda at VB Transform, VentureBeat's flagship event, July 14-15 at Hotel Nia in Menlo Park, with technical leaders from Visa, GM, Waymo, Intuit, Instacart, LangChain and others. Details and registration here.

Disclosure: VentureBeat's June 24 AI Impact event in New York was sponsored by Red Hat and Intel. Sponsors have no input into VentureBeat Pulse Research survey design, findings, or editorial coverage.

Beyond Benchmarks: Engineering a Science-Grounded Validation for the Envoy AI Gateway

Fri, 03 Jul 2026 00:17:06 +0200

The enterprise adoption of Large Language Models (LLMs) presents profound architectural challenges that extend far beyond simply hosting a model. Organizations demand robust, high-performance API gateways capable of providing identity-based routing, strict rate limiting, zero-trust security, and granular observability. Managing LLM traffic is uniquely demanding because it typically involves long-lived, chunked HTTP/2 streams that generate … Continued

The post Beyond Benchmarks: Engineering a Science-Grounded Validation for the Envoy AI Gateway appeared first on VMware Cloud Foundation (VCF) Blog.

Real-Time Observability: Introducing Akamai Cloud Pulse Alerts

Thu, 02 Jul 2026 19:38:39 +0200

This post doesn’t have text content, please click on the link below to view the original article. This article has been indexed from Blog Read the original article: Real-Time Observability: Introducing Akamai Cloud Pulse Alerts

The post Real-Time Observability: Introducing Akamai Cloud Pulse Alerts appeared first on IT Security News.

Cisco details Live Protect’s real-time threat mitigation capabilities

Thu, 02 Jul 2026 17:24:11 +0200

Cisco this week shared more details about its new Live Protect package and how it will help Nexus-based data center operators safeguard valuable resources.

Announced and demoed at the recent Cisco Live event, Cisco Live Protect for Nexus infrastructure replaces disruptive, traditional patching cycles with real-time shields that mitigate vulnerabilities instantly, according to Shankar Varanasy, product management leader with Cisco’s data center networking team.

“By orchestrating these proactive defenses through Cisco Nexus One and Cisco Nexus Dashboard on premises, administrators can neutralize threats the moment they arise, ensuring a hardened security posture without sacrificing operational uptime,” Varanasy wrote in a blog post this week. “This approach effectively eliminates the traditional trade-off between security and availability, allowing data centers to maintain a hardened, high-performance posture while ensuring continuous, uninterrupted service delivery.”

“Live Protect uses extended Berkeley Packet Filter (eBPF) technology, a powerful Linux kernel feature, through the Tetragon agent embedded in NX-OS. This allows deep visibility and enforcement directly within the kernel, monitoring system calls, file operations, process control, and network traffic to detect and prevent privilege escalation, control-plane attacks, and other sophisticated threats,” Varanasy wrote.

The Live Protect vulnerability shields are basically policies for a selected, validated vulnerability condition, according to Varanasy. These shields are intended as temporary measures and should be decommissioned once a permanent software fix is applied, he said.

“Live Protect is not a patch,” wrote Tom Gillis, senior vice president and general manager of the Cisco infrastructure & security group, in blog post about Live Protect in June. “It does not replace the need for core lifecycle discipline or permanent software updates. Instead, it serves as a temporary, targeted shield that mitigates the risk of a specific vulnerability with a few clicks. It is intended to be a ‘finger in the dike’, an emergency control that is applied to a running system without disrupting that system between more frequent maintenance windows.”

Live Protect works by using eBPF to run sandboxed programs within the operating system kernel, Gillis wrote: “This gives us the deep visibility and surgical control to intercept and block exploit attempts at the source without changing the kernel’s source code or requiring a system reboot.”

“The unique capabilities of eBPF allow us to make very fine grained, pin-point controls that shield a known vulnerability from being exploited. The shield can be as specific as ‘do not allow this particular process to access this particular file.’ Because these shields are so fine grained and specific, they are designed to have ultra-low false positive rates. In simple terms, that process should never access that particular file. So, we don’t allow it,” Gillis wrote.

“Data center environments are becoming more complex,” Varansasy wrote. “This increases the number of possible entry points for attackers. Older systems and outdated infrastructure make things even harder because they often lack hardened products, software compatibility, and the latest security features. Legacy systems therefore require frequent manual updates, troubleshooting, and patching to react to security threats—especially with technologies like Claude Mythos, Anthropic’s AI model that can autonomously discover and exploit software vulnerabilities at unprecedented speed. Teams spend more time maintaining and securing infrastructure than focusing on business-critical outcomes.”

“Traditional security patching methods require scheduled downtime and maintenance windows, which can delay the deployment of critical fixes and leave networks exposed to zero-day attacks. These delays create windows of vulnerability that sophisticated attackers can exploit,” Varanasy wrote.

World Wide Technology on Cisco Live Protect

Technology provider World Wide Technology (WWT) has been closely watching the development of Cisco Live Protect and called new capability “genuinely exciting.”

“One of the most practically impactful announcements this week was the general availability of Live Protect on the Cisco Nexus 9000 series,” WWT wrote in a blog post following the Cisco Live event.

“The problem Live Protect solves is one that every infrastructure and security team knows well,” WWT wrote. “When a critical vulnerability is disclosed, the permanent fix requires a patch cycle: testing, change control, maintenance windows, coordination across teams. In a high-velocity threat environment, that process takes time an organization may not have. Live Protect inserts Cisco-validated runtime protections immediately, closing exposure while the permanent remediation proceeds through its normal workflow. No reboots required. No disruption to operations.”

Some other Live Protect facts from Cisco:

Live Protect is a compensating control designed to mitigate risk during the interim period between vulnerability disclosure and remediation. Customers should continue to prioritize regular software maintenance and deploy permanent patches or fixed software releases.
Live Protect doesn’t protect customers from everything. Shield availability is determined by a range of factors, including the nature of the vulnerability, exploit characteristics, supported platform, software release, policy, mode, and Cisco validation status.
Availability is specific to the supported Cisco product, software release, policy, mode, delivery path, management surface, and lifecycle support, though currently Nexus systems are the only portfolio offered support now. Other systems such as campus and branch products are expected later this year.

Digital readiness gaps emerge around FIFA World Cup 2026

Thu, 02 Jul 2026 17:18:26 +0200

Dynatrace research highlights disparities in federation website performance around the FIFA World Cup 2026, with Saudi Arabia among the slowest performers, as organisations turn to AI and observability to manage unpredictable traffic spikes

What do AI observability tools actually do?

Thu, 02 Jul 2026 11:04:36 +0200

As organizations rush to move AI into production, they’re finding that the tools they rely on to monitor traditional software don’t translate cleanly to AI systems. The reason is fundamental: AI doesn’t fail as software does. It doesn’t throw clean error codes or follow predictable execution paths. It drifts, hallucinates, and degrades in ways that are often subtle, intermittent, and hard to reproduce.

The result is a growing gap between what teams think observability should provide and what current tools actually deliver. The uncomfortable truth? The AI observability tools we have today are built for yesterday’s problems.

To understand where the industry is headed, we need to look at where it is today and why that’s not enough.

AI observability today: The era of evals

Today’s AI observability landscape is dominated by one concept: evaluation.

Most tools focus on scoring model outputs after the fact. They rely on test datasets, human graders, or, increasingly, “LLM-as-a-judge” approaches to determine whether a system is behaving correctly. These evaluation pipelines are useful and can provide a baseline for model quality, helping teams benchmark improvements.

But they do share a critical limitation. They’re static, offline, and backward-looking.

Evaluations tell you how a model performed on a predefined set of inputs. But they don’t tell you what’s happening in production, where inputs are unpredictable and context can shift. You need to capture long-running interactions, multi-step workflows, and the behavior of systems composed of multiple models and tools as a part of your evals.

Even when teams use human-in-the-loop feedback, it can be tough to scale. High-quality feedback requires domain expertise, consistency, and time, each of which is in short supply in most engineering organizations. You also need deep knowledge of the models themselves and how they’re working in production to help identify and provide feedback around the source of the error. Was it a lack of context? A bad retrieval-augmented generation (RAG) implementation? The model itself? Or bad feedback poisoning the results?

Some progress is being made. OpenTelemetry (OTel) and LLM tracing are emerging as early attempts to bring runtime visibility into AI systems. But these are still just first steps, and the core issue remains: you can’t understand AI systems by evaluating them after the fact. You need to observe them as they operate.

The security turn: guardrails, PII, and prompt injection

As AI systems move into production, observability becomes more about managing risk. The attack surface has expanded dramatically, with teams now dealing with:

Prompt injection attacks
Jailbreak attempts
Leakage of sensitive data, including personally identifiable information (PII)
Unintended model behavior triggered by edge-case inputs

In response, a new category of “guardrail” tools has emerged. These systems aim to monitor inputs and outputs in real time, flagging or blocking unsafe behavior. In theory, they provide a safety layer that sits between users and models.

In practice, however, the picture is more complicated.

Most guardrails today are reactive. They rely on predefined rules or classifiers that attempt to catch known patterns. But AI systems are inherently open-ended, and adversarial inputs evolve quickly. What works today may fail tomorrow.

There’s also a deeper issue: guardrails operate on the assumption that you already have sufficient visibility into the system. In reality, many teams lack the underlying telemetry needed to understand how and why a failure occurred in the first place.

This creates a gap between what guardrails promise (real-time protection) and what they can reliably deliver. Closing that gap requires something more foundational than filtering inputs and outputs. It requires rethinking observability itself.

The coming shift: from models to agents

The next wave of AI is clearly about autonomous agents. Instead of single inference calls, we’re seeing systems that orchestrate multiple models, interact with external tools and APIs, and execute multi-step workflows over extended periods of time.

These systems don’t just generate outputs; they make decisions. And that changes the observability problem entirely.

Just as containers required orchestration platforms like Kubernetes to become manageable at scale, AI agents will require their own observability and control layer. That layer must go beyond tracking inputs and outputs. It needs to capture:

Decision paths
Tool usage
Resource consumption
Interactions across agents
Behavior over time, not just at a single point

In many ways, this is similar to what we saw with the evolution of cloud-native observability. We moved from simple metrics to a combination of logs, metrics, and traces to understand distributed systems.

Now we need the equivalent for agentic systems.

As AI becomes embedded across the software development life cycle, from code generation to testing to operations, observability is evolving into a system of truth that feeds both humans and machines. AI agents can only build, debug, and improve systems if they have access to rich, high-fidelity production context. Observability is what provides that context.

Why kernel-space observability will be essential

There’s a fundamental trust problem at the heart of AI observability. If an AI agent is responsible for reporting its own behavior, how do you know that behavior is being reported accurately?

Traditional observability relies heavily on instrumentation within the application layer. But instrumentation can be incomplete, misconfigured, inadvertently bypassed, or simply incorrect.

This problem becomes more acute as AI systems begin generating their own code. Agents don’t think like human engineers when it comes to instrumentation, nor should they be expected to. But the result is a growing need for independent, out-of-band observability.

This is where kernel-level approaches, such as eBPF, become critical. By operating at the kernel level, eBPF enables teams to:

Capture system behavior without modifying application code
Eliminate blind spots caused by missing instrumentation
Ensure consistent visibility across all workloads, both human-driven and AI-generated

More importantly, eBPF provides a trusted source of truth. In high-stakes environments where compliance, security, and reliability are non-negotiable, this independence is essential. You need telemetry that’s not influenced by the systems it observes.

Three needs for AI observability

If current tools fall short, what comes next? The answer is a shift in how we think about observability.

First, we need behavioral anomaly detection for AI systems. Traditional observability focuses on latency, errors, and resource utilization. But AI systems require a different lens to detect when behavior deviates from expectations, even when no explicit “error” occurs.

Second, we need tamper-proof audit trails. As AI systems take on more responsibility, you have to be able to reconstruct decisions. Teams need to understand what happened and, more importantly, why. And they need to trust that the data hasn’t been altered.

Third, observability must become dynamic and adaptive. Static dashboards and predefined metrics won’t cut it. AI systems operate in constantly changing environments, and observability must be able to:

Adjust data collection in real time
Increase granularity during incidents
Focus on what matters in the moment

Finally, observability must integrate directly into AI workflows. It’s no longer enough to surface insights to human operators. The same telemetry must be consumable by AI agents feeding back into development, debugging, and optimization loops.

Observability as a part of infrastructure, not an afterthought

We are still early in the evolution of AI observability. Most of today’s tools are extensions of existing paradigms adapted for AI, but not fundamentally redesigned for it. Predictably, they solve parts of the problem, but not the whole.

The next generation of these systems will look very different. They’ll treat observability as a core layer that enables AI systems to operate safely, efficiently, and autonomously. The teams that succeed will be those that recognize this shift early.

Ultimately, in a world of non-deterministic systems, long-running workflows, and autonomous agents, one thing becomes clear: AI reliability strongly correlates with your observability layer.

—

SnapLogic MCP Builder eases creation of MCP servers

Thu, 02 Jul 2026 01:18:41 +0200

SnapLogic has released MCP Builder, a template-based tool designed to help organizations operationalize AI faster by turning existing integration pipelines into agent-ready Model Context Protocol (MCP) servers.

Announced July 1 and generally available in the MCP Server workflow of the SnapLogic platform, MCP Builder generates MCP servers from existing integrations, OpenAPI specifications, and API management services, SnapLogic said. Organizations can publish MCP tools without rebuilding workflows, writing code, or manually constructing MCP implementations, resulting in faster deployment and greater consistency, according to the company.

SnapLogic said MCP Builder makes it easier to create MCP Servers, connecting AI agents to trusted enterprise systems and workflows. Unlike DIY MCP approaches, SnapLogic accelerates MCP adoption by turning existing deterministic pipelines into governed MCP tools through a one-step creation experience, while providing enterprise connectivity, identity propagation, observability, and life-cycle governance through the unified SnapLogic Agentic Integration Platform.

AWS aims to lower log analytics costs with new analytics engine for managed OpenSearch

Wed, 01 Jul 2026 22:47:38 +0200

AWS is offering to help enterprises address the growing cost of retaining telemetry for talkative AI applications with a new engine for its managed Amazon OpenSearch Service optimized for log analytics, which it claims can reduce storage costs by 70% and at the same time deliver better price-performance.

AI and agentic applications are generating more telemetry than conventional observability architectures were built to manage economically, forcing enterprises to balance retaining the operational data needed for security, compliance and incident response against rising related infrastructure costs.

The new engine will allow customers to continue using the same management console, APIs, security model and networking configuration as the service’s existing general-purpose engine, while storing data in Apache Parquet format and maintaining Lucene search indexes for searchable fields, AWS said.

It uses Apache Calcite to parse and optimize queries before routing analytical operations to Apache DataFusion and search predicates to Lucene, allowing search and analytical aggregation to run within the same query, AWS executives wrote in a blog post.

The optimized engine supports SQL and Piped Processing Language (PPL), they said.

Keeping costs down without losing detail

In a recent survey of enterprises’ log management practices, Dynatrace found that AI workloads drove a 93% increase in log volume over the previous year, organizations to exclude an average of 86% of log data to manage costs and system capacity.

“Managing growing log volumes while keeping the cost almost flat is a persistent challenge that enterprises share,” said Ashish Chaturvedi, executive research leader at HFS Research.

“Most end up dropping retention windows or sampling logs, which is exactly when you lose the data you need for unanticipated incidents,” he said.

Shashi Bellamkonda, principal research director at Info-Tech Research Group, said AI agents have broken the math behind general purpose OpenSearch: “Constant background queries from agents touching logs didn’t fit the cost and performance assumptions baked into the original engine. The bill got too big. Enterprises started going blind on purpose.”

But the new AWS engine could help, said HyperFrame Research AI stack analyst Stephanie Walter, even if users realize only some of the gains that AWS promises.

“Lower storage costs can translate into longer retention periods, better compliance support, and more complete incident investigations,” Walter said.

Cheaper retention could also help CIOs curb tool sprawl as it reduces the incentive to fragment observability tooling across vendors purely for cost arbitrage, according to Bellamkonda. “Tool sprawl carries its own tax: integration overhead, headcount to maintain five dashboards instead of one,” he said.

Migration and compatibility could temper adoption

However, the analysts cautioned that realizing those benefits may require more work than AWS’s emphasis on compatibility initially suggests.

“AWS states that the optimized engine can’t be added to an existing domain and can’t be enabled on individual indices within a general-purpose domain. Adoption means standing up a new domain and migrating ingestion pipelines to it, making the transition more involved for engineering teams than a simple lift-and-shift,” Bellamkonda said.

Another point against the new engine, according to Chaturvedi, is its lack of support for Domain Specific Language (DSL).

This means that enterprises with existing OpenSearch deployments built around DSL queries or workloads that need frequent updates may need to rewrite dashboards, alerts and automation workflows before moving to the optimized engine, potentially extending migration timelines, Chaturvedi said.

Those implementation considerations are likely to influence the pace of adoption of the new engine more than the technology behind it, Bellamkonda said: “Migration friction, not cost, usually keeps enterprises on infrastructure they’ve outgrown.”

“AWS lowered the friction inside the migration by supporting ingestion through the same Bulk API and client libraries, which means no changes to ingestion pipelines or application code. However, it didn’t remove the migration entirely,” he said. The new optimized engine for Amazon OpenSearch Service has been made generally available.

This article originally appeared on InfoWorld.

AWS aims to lower log analytics costs with new analytics engine for managed OpenSearch

Wed, 01 Jul 2026 22:18:43 +0200

The optimized engine supports SQL and Piped Processing Language (PPL), they said.

Keeping costs down without losing detail

“Managing growing log volumes while keeping the cost almost flat is a persistent challenge that enterprises share,” said Ashish Chaturvedi, executive research leader at HFS Research.

“Most end up dropping retention windows or sampling logs, which is exactly when you lose the data you need for unanticipated incidents,” he said.

But the new AWS engine could help, said HyperFrame Research AI stack analyst Stephanie Walter, even if users realize only some of the gains that AWS promises.

“Lower storage costs can translate into longer retention periods, better compliance support, and more complete incident investigations,” Walter said.

Migration and compatibility could temper adoption

However, the analysts cautioned that realizing those benefits may require more work than AWS’s emphasis on compatibility initially suggests.

Another point against the new engine, according to Chaturvedi, is its lack of support for Domain Specific Language (DSL).

The Control Gap: Enterprise AI organizations have an ownership problem, not a technology problem — and most are governing it by hand

Wed, 01 Jul 2026 21:32:49 +0200

AI portfolios are expanding far faster than the ability to govern them across enterprises. Most organizations run a contested field of platforms, each claiming to be the “primary” AI layer; few could confidently detect a model drifting or failing in production; and the single most-cited barrier to control is the absence of any one owner accountable for AI across the stack. The result is a widening control gap — ambition and spend racing ahead of visibility, ownership, and cost control — with autonomous agents already producing real financial and operational failures.

This wave of VentureBeat Pulse Research examines the enterprise AI control gap: how many platforms claim to be the primary AI layer, who actually governs AI behavior across them, whether organizations could detect a model failing in production, what most blocks cross-platform governance, and how the financial and operational control failures of autonomous agents are already surfacing.

The central finding is a control gap — the distance between how aggressively enterprises are expanding AI and how little of it they can see, own, or govern. Just under three-fifths (58%) are net-adding AI initiatives, with “expanding significantly” the largest single posture.

Yet 85% run two or more platforms each claiming to be the “primary” AI layer and only 8% have consolidated to one. Against that contested surface, 40% say they are very confident they would detect a model drifting, behaving unsafely, or failing in production — but only 10% back that confidence with active monitoring and alerting, the rest leaning on manual human review. The machinery to expand AI is running well ahead of the machinery to control it.

The gap is, above all, a question of ownership. Only a third (38%) say a central team governs AI today, and a fifth (20%) say each platform team governs its own independently; the single most-cited barrier to cross-platform governance is the absence of a single accountable owner (32%), and roughly one in six (17%) say no role holds formal accountability at all. The same vacuum shows up in spend: just under half (49%) name shadow AI — unauthorized agentic pipelines run on corporate cards outside central oversight — as their most severe control failure, and another 25% have been hit by a runaway “infinite loop” agent bill. Enterprises have standardized the ambition well before they have standardized the control.

Methodology

VentureBeat fielded this survey as part of its ongoing Pulse Research series, this instrument focused on the enterprise AI control gap — governance, observability, and cost control across multiple AI platforms. Responses are filtered to organizations with 100 or more employees and, for this cut, exclude the respondents who selected “Other” as their job function, leaving a base of identifiable roles (n=145); all are drawn from a single Q2 2026 (June) wave.

By organization size the sample tilts toward the mid-market and lower-large bands: 100–499 and 500–2,499 employees (23% each) lead, with 10,000–49,999 (22%) and 2,500–9,999 (20%) close behind and 50,000+ at 11%. By role it is senior and technical: consultants and advisors (20%), CIO/CTO/CISO (18%), directors of engineering/IT (14%), product and program managers (13%), and enterprise architects (12%) make up the core. Technology/Software is the largest industry at 41%, followed by Financial Services and Professional Services (12% each) and Healthcare/Life Sciences and Manufacturing/Industrial (10% each).

The findings should be read as a directional signal rather than a precise measurement; it is self-selected and is not a probability sample. Where a single share would be fragile on its own, the report leans on the direction and grouping of responses rather than the exact percentage point.

Finding 1: Expansion is outrunning control

AI portfolios are growing faster than the means to govern them

We asked enterprises to describe how their AI portfolio has changed over the past 12 months. Growth leads — with a meaningful minority deliberately pulling back.

Expansion leads. Combining “expanding significantly” (33%) and “net positive growth” (25%), just under three-fifths of enterprises (58%) are net-adding AI initiatives. Yet a substantial share is easing off deliberately: roughly a quarter (23%) are actively rationalizing — scaling what works and cutting the rest — and another 12% hold their portfolios flat. Only a handful (3%) have paused to get governance in order first.

This is the engine behind every gap that follows: enterprises are accelerating into a landscape they have not yet learned to see or own, and a notable 4% cannot even describe their own portfolio. The ambition documented here is exactly what makes the visibility and ownership shortfalls in Findings 3 and 4 consequential rather than academic.

Finding 2: No single “primary” AI layer — the surface is contested

More than four in five run multiple platforms each claiming primacy

We asked how many enterprise platforms currently claim to be the organization’s “primary” AI layer — the ERP, EHR, ITSM, productivity suite, or data platform each positioning itself as the center of gravity. Almost no one has a single answer.

The defining condition is contested primacy. Adding the two multi-platform bands, 85% of enterprises have at least two platforms each asserting itself as the primary AI layer, and more than a third (36%) describe an open four-way-or-more contest. Only 8% have consolidated to a single layer, and another 6% have not even mapped the question. This is the structural reason governance is hard: there is no agreed center of gravity to govern from. Each platform brings its own AI, its own controls, and its own assumptions — and, as Finding 3 shows, the question of who governs across them increasingly has no settled answer.

Finding 3: Governance is claimed at the center but contested in practice

A central team owns it on paper; in practice, it's fragmenting

We asked who is actually responsible for governing AI behavior across all of those platforms today, and which function holds primary accountability. The headline answer is reassuring; the detail is not.

On the surface, a central governance function is the leading answer — but only a third (38%) claim one, well short of a majority. The rest of the distribution undercuts it further: a fifth (21%) say ownership is unclear or contested between teams, a fifth (20%) say each platform team simply governs its own AI independently, and 19% say no one has addressed it at all.

Accountability fragments further when we asked which role actually holds it — CIO/CTO/CISO leads at 27%, a Chief AI Officer or equivalent at 22%, and a striking 17% say no one holds formal accountability yet. Even where a central team is claimed, the named owner is most often the general technology executive rather than a dedicated AI authority. The governance function exists more often as an org-chart aspiration than an operating reality — the precondition for the detection gap in Finding 4.

Finding 4: The detection gap — confidence is real but largely manual

Only one in 10 have active monitoring and alerting

We asked how confident enterprises are that they would detect an AI model in production that was drifting, behaving unsafely, or failing to complete tasks correctly. This is the heart of the control gap.

This is the report’s central number. While 40% say they are very confident they would detect a failing model, the overwhelming majority of that confidence rests on manual human review (30%) rather than automation — just 10% have active monitoring and alerting actually in place.

At the other end, more than a quarter combine the two reactive answers — no systematic visibility (8%) and would hear it from end users first (19%) — meaning they would learn of a production failure after the fact, from the people it affected. The plurality (32%) sit in a hopeful middle, expecting to “catch most issues eventually.” Set against the aggressive expansion of Finding 1, this is the crux of the control gap — enterprises are scaling AI into production faster than they are building automated means to know when it breaks. Confidence is real, but it is largely manual, and automated detection remains the exception.

Finding 5: The missing owner is the biggest barrier

Governance stalls on accountability first, visibility second

We asked enterprises to name their single biggest barrier to governing AI across multiple platforms. The org chart tops the list.

The single missing owner leads at 32%, the most-cited barrier. Vendor opacity (25%) and the lack of tooling or infrastructure to observe across platforms (16%) sit behind, and together these two technical-visibility barriers (41%) outweigh the ownership gap. Leadership deprioritization accounts for another 17%, while a clear lack of talent is rare (5%). Rounding out the picture, another 5% say it isn't a barrier for them at all — they've already solved it.

Read together, the picture is more contested than the headline suggests: enterprises still most often name a missing owner, but a good share locate the obstacle in vendor black boxes and the absence of cross-platform observability.

Asked in a free-text question what one thing they would fix, respondents converged from different directions on the same answer — a single accountable owner, and a control plane that abstracts cost, drift, and model choice away from the end user.

Finding 6: The fine-tuning ROI reckoning

Roughly seven in 10 have little to show for custom model investment

We asked what share of the proprietary foundation models enterprises have invested in fine-tuning over the past 18 months have delivered clear, measurable positive ROI in production today. Most describe a sandbox graveyard — or a deliberate decision to avoid one.

Custom fine-tuning has, for most, not paid off. Combining the three disappointing outcomes — sandbox graveyard, strategic avoidance, and total write-off — roughly seven in ten (73%) either failed to get custom models into productive use or deliberately declined to try, against 27% for whom fine-tuned models are a reliable advantage. The largest single group (45%) remains the graveyard: projects too expensive or complex to maintain, stranded in development. Another quarter (24%) never started — they priced in the downstream maintenance burden and avoided it.

The signal is that many enterprises still treat bespoke model training as a cost trap, which helps explain the pragmatic, buy-and-blend vendor posture in Finding 7.

Finding 7: Vendor posture — hybrid by default, with defection rising

Enterprises blend open and closed models; more are now trimming a vendor

We asked two related questions: whether enterprises are shifting workloads toward open-weight models to escape API costs and lock-in, and which proprietary vendor, if any, they are most likely to phase out over the next year. The answers describe hedging — and a rising willingness to cut.

On open weights, a clear majority (51%) strike a hybrid balance, with a deliberate closed commitment second at 32% and a hard pivot to self-hosted open models at 16%. The hybrid plurality is the same instinct visible throughout this survey — keep optionality, avoid being trapped — while the closed group remains candid that the operational overhead of self-hosting still outweighs the savings for them.

On vendor defection, loyalty by inertia no longer leads: Microsoft is now the single most-named target (29%, often citing Copilot/Azure cutbacks in favor of direct model access), narrowly ahead of the 27% who are downsizing no one at all. OpenAI follows at 21% (citing pricing volatility), with Anthropic at 15% and Google at 6%. No single vendor faces a wholesale exodus, but among identifiable roles the balance has tipped from “expanding across all” toward actively trimming at least one provider.

Finding 8: The agentic spending crisis — shadow AI leads the failures

Unauthorized pipelines, not runaway loops, are the top control failure

Finally, we asked what the most severe financial or operational control failure enterprises have experienced as autonomous agents run over longer execution windows. Shadow AI tops the list — and very few have escaped a scare.

The control gap has a price, and it is being paid. Just under half of enterprises (49%) cite shadow AI — unauthorized agentic pipelines spun up on corporate cards outside any central oversight — as their most severe failure, the operational twin of the “no single owner” barrier in Finding 5. Another 25% have been burned by a runaway infinite-loop agent bill, and 6% by an agent that degraded production databases. Only 21% report guarded stability — the minority that has imposed hard token throttling and budget caps at the infrastructure layer and avoided surprises.

Put differently, roughly four in five of these enterprises (79%) have already experienced a real financial or operational control failure from autonomous AI, not merely worried about one. As with detection in Finding 4, the deterministic controls that would prevent these failures exist at only a fraction of organizations.

The bottom line: A control gap that spending cannot close on its own

Organizations with 100 or more employees describe AI programs that are expanding fast and governing slowly. Just under three-fifths are net-adding to their portfolios; more than four in five run a contested field of platforms with no agreed primary layer; and the thing they most often name as their chief obstacle is a single accountable owner. The visibility to match the ambition is largely manual — only 10% have active monitoring and alerting, and confidence in detecting a failing model rests mostly on human review rather than automation.

The consequences are already concrete rather than hypothetical. Custom fine-tuning has disappointed more often than not, pushing enterprises toward a hedged, hybrid, buy-and-blend model posture; and the autonomous agents now reaching production have produced real control failures for roughly four in five respondents, led by shadow AI running outside any central oversight. This reads as a directional signal rather than a precise measurement — but the direction is consistent across every question: ambition, spend, and deployment are racing ahead of ownership, observability, and cost control. The control gap is not a tooling problem that more spending will close on its own; it is, first, a question of who owns the answer.

Based on survey responses from 145 qualified enterprise respondents (100+ employees). Sample size is small; data should be treated as directional. Respondents include Directors, VPs, CIOs, CTOs, and Enterprise Architects across Technology, Financial Services, Retail, Healthcare, and other sectors.

칼럼 | 모델은 빌리고 그라운딩은 소유한다···AI 경쟁력의 새로운 공식

Wed, 01 Jul 2026 13:50:40 +0200

지난 2년간 기업 AI 인프라 분야에서 일하며 업계의 흐름을 지켜본 결과, 필자는 같은 질문이 반복해서 제기되는 것을 목격했다. ‘우리도 자체 LLM을 구축해야 할까?’라는 질문이다.

이런 생각이 드는 이유는 충분히 이해할 수 있다. 모델은 AI의 핵심이자 엔진이며 두뇌이고, 반드시 확보해야 할 자산처럼 보이기 때문이다.

하지만 고객 경험과 데이터 그라운딩 인프라 분야에서 AI 제품 관리자로 오랜 기간 일하며 내린 결론은 다르다. 다소 의외로 들릴 수 있지만, 모델은 AI 전략에서 가장 오래 지속되지 않는 요소다.

이 말을 하는 이유는 논쟁을 불러일으키기 위해서가 아니다. 지난 몇 년 동안 많은 기업은 가장 빠르게 범용화되고 있는 기술 계층에 가장 귀중한 자원을 집중해 왔다. 경영진의 관심, 우수한 엔지니어 인력, 투자 자본까지 모두 모델에 쏟아부었다.

반면 AI의 신뢰성과 정확성, 그리고 경쟁력을 좌우하는 데이터 그라운딩 계층은 단순한 기반 인프라 정도로 취급돼 왔다. 필자의 경험으로는 이러한 우선순위의 역전이 현재 기업들이 AI 도입 과정에서 범하는 가장 비용이 큰 실수다.

진정한 경쟁력은 그라운딩이다

그라운딩(Grounding)은 범용 AI 모델을 기업이 보유한 최신의 신뢰할 수 있는 정보와 연결하는 기술이다. 가장 대표적인 방식은 검색증강생성(Retrieval-Augmented Generation, RAG)이다. 모델이 학습 과정에서 필요한 정보를 모두 기억하고 있기를 기대하는 대신, 사용자의 질의가 들어오는 순간 기업 내부 시스템에서 관련 정보를 실시간으로 검색해 모델에 제공함으로써 정확한 답변에 필요한 맥락을 전달하는 방식이다.

AI 경쟁력을 고민하는 기업이라면 여기서 중요한 점이 있다. 경쟁사도 기업이 사용하는 것과 동일한 모델을 얼마든지 사용할 수 있다. 하지만 기업의 데이터와 축적된 업무 지식, 업무 프로세스, 그리고 이러한 정보를 적시에 정확하게 제공하는 데이터 파이프라인까지 빌릴 수는 없다.

바로 이 파이프라인이 진정한 독점 자산이다. 쉽게 모방할 수 없고 시간이 지날수록 가치가 축적된다. 이것이 경쟁 우위(Moat)의 전형적인 조건이며, 어떤 모델을 선택했는지와는 거의 관련이 없다.

업계도 이러한 변화를 인식하기 시작했다. 가트너는 2027년까지 기업들이 범용 LLM보다 특정 업무에 특화된 소형 모델을 최소 세 배 이상 많이 활용할 것으로 전망했다. 실제 업무에서는 모델 규모보다 업무 도메인에 대한 이해와 맥락이 정확도를 좌우하기 때문이다.

또한 소형 모델은 설계상 내부 파라미터에 저장하는 정보가 적다. 그만큼 최신의 신뢰할 수 있는 정보를 실시간으로 제공하는 검색 기능에 더욱 크게 의존하게 된다. 결과적으로 모델은 더 작아지고 교체하기 쉬운 요소가 되는 반면, 그라운딩은 AI 성능을 좌우하는 핵심 계층으로 자리 잡게 된다.

가트너는 같은 분석에서 기업 경쟁력을 결정하는 요소로 데이터 준비와 검증, 버전 관리, 운영 역량을 꼽았다. 다시 말해 기업을 차별화하는 요소는 모델이 아니라 데이터를 관리하는 역량이라는 의미다.

이러한 분석은 필자가 현장에서 직접 경험한 내용과도 일치한다. 뛰어난 모델을 확보하는 것이 어려웠던 적은 거의 없었고, 실제 문제가 발생한 원인도 대부분 모델 자체는 아니었다. 문제는 모델을 적절한 데이터 소스와 연결하지 못하거나 검색 체계를 제대로 설계하지 못했을 때 발생했다.

비슷한 문제가 반복됐다. 데이터가 부족하면 요약 결과가 불완전해지고, 문서가 일부만 검색되면 중요한 내용이 빠진 답변이 생성됐다. 불필요한 정보가 함께 검색되면 관련성이 떨어지거나 혼란스러운 응답이 나왔다.

그라운딩이 제대로 이뤄지지 않으면 사용자마다 서로 다른 답변이 제공된다. 검색 결과가 없으면 모델은 빈 부분을 환각(Hallucination)이나 무의미한 내용으로 채운다. 오래된 데이터는 자신 있게 틀린 정보를 제시하고, 검색 누락은 원론적인 답변으로 이어진다. 데이터 품질이 낮으면 응답 속도와 결과물의 품질 모두 떨어진다.

이 가운데 어느 것도 모델 자체의 문제가 아니다. 모두 그라운딩의 문제다. 그리고 경영진이 AI로부터 잘못된 답변을 받았을 때 이사회는 모델이 얼마나 뛰어났는지를 따지지 않는다. 중요한 것은 답변이 틀렸다는 사실이며, 해결책은 언제나 그라운딩 계층에 있다.

실제 기업 사례 하나가 특히 기억에 남는다. 한 기업에서는 그라운딩을 사용할 수 없는 환경에서 동일한 질문을 했을 때 실행 환경에 따라 서로 다른 답변이 나왔고, 일부 답변은 서로 모순되기까지 했다.

원인은 나중에 돌아보면 단순했다. 그라운딩이 없자 AI는 기업의 공통 데이터가 아닌 자체 학습 지식을 기반으로 답변을 생성했고, 환경과 설정이 달라질 때마다 응답 내용도 달라졌다.

피해는 단순한 기술적 문제가 아니었다. 같은 질문에도 항상 같은 답을 하지 못하는 AI를 사용자는 더 이상 신뢰하지 않았다.

이것이 부실한 그라운딩이 초래하는 진짜 비용이다. 실제 운영 환경에서 AI의 일관성과 신뢰성을 결정하는 것은 모델이 아니라 데이터 계층이다. 어떤 최신 모델로 교체했더라도 이 문제는 해결되지 않았을 것이다.

경영진은 어디에 투자해야 하는가

기업의 경쟁력이 그라운딩에서 나온다는 사실을 받아들인다면, 예산과 관심을 어디에 집중해야 하는지도 달라져야 한다.

첫째, 조직의 데이터 기반을 AI 프로젝트를 위한 사전 준비 작업이 아니라 핵심 투자 대상으로 바라봐야 한다. 데이터를 정제하고 구조화하며, 거버넌스를 구축하고 버전을 관리하는 일은 화려해 보이지는 않지만 AI의 품질을 결정하는 가장 중요한 작업이다. 필자라면 뛰어난 모델과 부실한 검색 파이프라인보다 평범한 모델과 우수한 검색 파이프라인을 언제나 선택할 것이다.

둘째, 처음부터 모델을 쉽게 교체할 수 있는 구조를 설계해야 한다. 지금 사용하는 모델은 1년 안에 다른 모델로 대체될 가능성이 높다고 가정하는 편이 맞다. 실제로 그렇게 될 가능성이 크기 때문이다. 만약 모델을 교체하는 작업이 어렵다면 시스템 아키텍처가 잘못된 계층에 결합돼 있다는 의미다. 그라운딩 인프라와 평가 체계, 데이터 계약(Data Contract)은 안정적으로 유지되는 핵심 요소가 돼야 하며, 모델은 최소한의 영향만으로 교체할 수 있는 구성 요소여야 한다.

셋째, 모델뿐 아니라 검색(Retrieval) 과정에 대한 관찰성(Observability)과 평가 체계에도 투자해야 한다. 이는 앞으로 더욱 중요해질 분야다. 가트너는 생성형 AI에 대한 신뢰 요구가 기술 발전 속도를 앞지르면서 LLM 관찰성에 대한 투자가 현재 15% 수준에서 2028년에는 생성형 AI 구축 사례의 50%까지 확대될 것으로 전망했다. 시스템이 특정 정보를 왜 검색했는지, 검색된 정보가 실제로 정확했는지를 확인할 수 있어야 AI의 결과를 설명하고 감사할 수 있다. 규제 준수나 기업 평판 관리가 중요한 조직이라면 이는 선택이 아니라 필수다.

물론 그렇다고 모델이 중요하지 않다는 뜻은 아니다. 여전히 성능이 뛰어난 모델은 필요하며 어떤 모델을 선택할지도 중요하다. 하지만 이제 모델 선택은 여러 우수한 대안 가운데 하나를 고르는 조달의 문제일 뿐, 지속적인 경쟁 우위를 만드는 요소는 아니다. 진정한 차별화는 모델을 둘러싼 데이터와 시스템, 운영 역량에서 나온다.

필자는 이러한 사실을 일찍 이해한 기업이 앞으로 몇 년 뒤에는 여전히 자체 모델을 학습시켜야 하는지를 고민하는 기업보다 한발 앞서 있을 것으로 본다. 더 과감한 결정을 내렸기 때문이 아니라, 더 오래 지속되는 선택을 했기 때문이다. 누구나 뛰어난 AI 모델을 사용할 수 있는 시대에는 자사 비즈니스의 현실을 가장 잘 반영하도록 AI를 그라운딩한 기업이 진정한 경쟁 우위를 확보하게 된다.

모델은 빌려 쓰는 자산이다. 그라운딩은 기업이 직접 소유하는 자산이다. AI 전략도 이 원칙을 중심으로 설계해야 한다.
dl-ciokorea@foundryco.com

Shadow agents: How IT leaders must govern ‘headless’ AI before it breaks the enterprise

Wed, 01 Jul 2026 12:08:28 +0200

Earlier this year, I was running my own local AI agent, a system I built called LaptopAI-Agent, which uses a LangGraph reasoning loop, a local Ollama model and a set of tools that can read files, query my git repositories and monitor system processes, all running entirely on my laptop with no cloud calls. I had given it a broad task and walked away. When I came back, it had completed the work. Every file it touched was within its allowed paths. Every action was technically correct.

What unsettled me was not what the agent had done. It was that I could not reconstruct the sequence of decisions that led to it. Without the SHA-256 chained audit log I had deliberately built in, I would have had no record of why the agent made each choice, only what it produced. That gap between visible outcomes and invisible reasoning is what I had to engineer around for a single-user personal tool. Enterprises face the same problem at the scale of thousands of agents, with far less instrumentation.

This is what I mean by shadow agents: autonomous AI processes that operate at the API layer, chain tools together and complete multi-step workflows without logging in, generating session records, or waiting for a human to approve. They already run inside enterprise systems today. The governance infrastructure to manage them is, in most cases, far behind.

The question is no longer whether your organization will run these autonomous processes. It already does. The question is whether you can see what they are doing.

The economics that opened the door

The immediate catalyst for this shift is financial. Enterprise teams that embedded frontier AI models from providers like OpenAI and Anthropic into everyday workflows quickly discovered that per-token cloud inference costs compound fast once agents run autonomously, making hundreds of API calls per task rather than one.

The industry response has been a push toward local AI processing. Google’s Gemma 4 12B, released in June 2026, is the clearest signal yet. Designed to run on consumer-grade hardware with just 16GB of VRAM, it brings multimodal AI, covering text, audio and visual processing, fully local to enterprise laptops without any cloud API dependency. Apache 2.0 licensing means any organization can deploy it without per-token fees.

For finance teams, this is cost relief. For IT governance teams, it is a new category of exposure. When inference moves onto thousands of distributed laptops, centralized telemetry disappears. The natural network choke points that monitoring tools rely on vanish with it. Without visibility infrastructure built before rollout, IT has no reliable way to know what those agents are accessing or deciding in the organization’s name.

The visibility gap is structural

Every monitoring tool, security scanner and compliance platform most enterprises rely on was designed to track human behavior: logins, session durations and file accesses triggered by a person at a keyboard. The implicit assumption in all of it is that a human is somewhere in the loop, generating observable signals.

Agentic AI generates none of those signals. It operates at the API layer, bypasses the user interface entirely, retrieves context from data stores, reasons over it and takes action. It does not log in. It produces no session record.

Box’s April 2026 launch of the Box Agent shows exactly how fast enterprise software is moving in this direction. The Box Agent works natively on the enterprise content layer, respecting existing permissions and compliance controls while it autonomously searches, summarizes and routes documents. That is solid engineering for business teams. It also means that contract reviews, approval chains and regulatory filings can now be executed by an agent that leaves no login trace in the monitoring systems IT manages.

The compliance consequence is real. An agent can chain tools in ways that move sensitive data from a secured internal store to an external processing endpoint because the agent found the connection useful, all within valid permissions, with no single step appearing suspicious and no record in any system IT is watching. The violation happens in the reasoning layer.

A new role: The forward-deployed AI engineer

Closing the governance gap requires a type of technical talent that most enterprise IT teams have not hired for. I have been calling this the forward-deployed AI engineer, a distinct role from DevOps.

A DevOps engineer asks whether the system is up. A forward-deployed AI engineer asks whether the agent is doing what was intended and only that. Their work covers three areas.

The first is prompt governance. The instructions that drive agent behavior function as code. They need version control, hardening against prompt injection attacks and rigorous re-testing after every model update. A prompt producing correct output in January can behave differently after a model version change in March, with no external indication that anything shifted.

The second is guardrail design: defining in technical terms what each agent is permitted to access, which external systems it may contact and which categories of action, financial transactions, credential access, outbound data transfers require human authorization before the agent can proceed.

The third is RAG pipeline governance. Enterprise agents typically access corporate knowledge through Retrieval-Augmented Generation pipelines. Scoping those pipelines correctly and auditing them on a consistent schedule is one of the most underestimated security responsibilities in agentic deployment. Overly permissive retrieval creates data exposure paths that are hard to detect until something has already gone wrong.

Runtime isolation: The right security model for agents

The architectural shift required here is from perimeter defense to runtime isolation. Perimeter defense assumes you control what enters the environment. When agents run locally, call external APIs dynamically and chain tools based on autonomous reasoning, the perimeter boundary is no longer a meaningful control surface.

Microsoft’s Agent Executor, part of the Microsoft Agent Framework, provides a practical model here. The Agent Executor wraps an agent in a sandboxed runtime that manages session state, conversation context and tool permission boundaries within a controlled envelope. An agent inside a properly configured executor cannot reach unauthorized systems or take unapproved actions regardless of what the model decides to do. The security guarantee shifts from trusting the model’s output to controlling what it is allowed to execute. For any organization under compliance mandates, that distinction between trust and control is not a nuance; it is the design requirement.

Governing at scale: The multi-agent challenge

One sandboxed agent with clear guardrails is manageable. A fleet of coordinating agents with distinct permissions, running simultaneously across cloud, desktop and on-premises environments, is a qualitatively different problem that requires dedicated infrastructure.

Automation Anywhere’s EnterpriseClaw, launched in May 2026 with Cisco, NVIDIA, Okta and OpenAI as partners, is the most comprehensive platform I have seen address this. NVIDIA contributes OpenShell, an open-source runtime for deploying autonomous agents safely, plus NIM microservices with Nemotron models for on-premises customers. Okta handles cross-agent identity management and policy enforcement across the entire agent fleet. Cisco AI Defense provides an agent-specific threat detection layer that conventional network monitoring cannot replicate. OpenAI enables production workflows on its latest models, including GPT-5.5.

The platform gives IT a single governance surface: centralized policy, behavioral monitoring and auditable observability across every agent regardless of where it runs. The core principle is that no agent, cloud-hosted or running locally on a laptop, operates outside a defined policy boundary. EnterpriseClaw is currently in preview, with general availability expected later in 2026.

Accountability cannot be an afterthought

Building governance into LaptopAI-Agent took deliberate effort: a permission guard with path allowlists, blocked commands, manual approval triggers and a chained audit log. That overhead for a personal tool on a single laptop previews what enterprises face at an orders-of-magnitude larger scale, across systems they did not build and agents they did not deploy themselves.

The tools are available. The architectural patterns are documented. What is missing in most organizations is the deliberate decision to build governance in parallel with deployment, not as remediation after the first incident.

Every shadow agent in your environment was approved somewhere, by someone, for a specific purpose. The question is whether you still have a current, verifiable line from that approval to what the agent is doing right now. If the answer is no, or we are not sure, that is exactly where the work needs to start.

Shadow agents are not a future problem. They are in production today, summarizing documents, routing decisions and interacting with systems your monitoring tools cannot observe. IT leaders who build real accountability infrastructure around them will be positioned to harness autonomous AI with confidence. The ones who wait will spend their time explaining, after the fact, how something happened that nobody could see.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

A framework for operational autonomy: Integrating CloudOps, FinOps and AIOps

Wed, 01 Jul 2026 11:06:18 +0200

Operational autonomy is quickly becoming one of the defining capabilities of a modern enterprise. As digital estates become more distributed, cloud environments more dynamic and AI consumption more expensive and less predictable, traditional operating models begin to show their limits. Teams can no longer rely only on manual oversight, disconnected monitoring tools or periodic financial reviews to keep enterprise technology healthy and cost efficient. What is needed instead is a coordinated operating framework that brings together CloudOps, FinOps and AIOps, while also addressing the emerging discipline of AI token and model consumption governance. When these disciplines are designed as one connected system rather than as isolated workstreams, organizations move closer to operational excellence: faster decisions, better resilience, improved financial control, stronger compliance and a more measurable connection between technology investments and business outcomes.

What operational autonomy means in enterprise IT

Operational autonomy does not mean removing people from operations. In practice, it means designing enterprise IT so that routine sensing, decision support, remediation, optimization and policy enforcement happen with minimal friction and with the right human oversight at the right moments. A mature autonomous operating model continuously observes infrastructure, applications, data flows, AI services and financial consumption patterns; detects risk or inefficiency early; and triggers guided or automated action based on policy, confidence and business criticality. This approach depends on four connected pillars: CloudOps to maintain reliable and scalable digital infrastructure, FinOps to govern cost and value, AIOps to detect patterns and automate response, and AI consumption governance to manage token usage, model selection, inference workloads and unit economics.

Gartner’s 2024 research on FinOps for data and analytics emphasizes that cloud operations and financial governance are no longer separate concerns, especially as AI workloads reshape cost structures and accountability expectations. Forrester’s 2024 analysis of AIOps and observability similarly notes that modern enterprises need deeper operational visibility and broader insight-driven coordination to handle hybrid complexity. IDC’s 2024 perspective on future operations adds another useful lens by framing data-driven operations around agility, resilience and predictability. Taken together, these viewpoints reinforce the same idea: autonomy is not a tool purchase; it is a management framework.

Design principles for an enterprise operational autonomy framework

A practical framework begins with a few disciplined principles. First, the enterprise must build around a shared operational data layer. Telemetry from cloud infrastructure, applications, service management systems, security controls, business transactions and AI services should be normalized so that operations, finance and governance teams work from the same facts. Second, every automated action should be policy-aware. Cost optimization, scaling, failover, remediation, model routing, data retention and access control should all reflect business guardrails rather than isolated technical rules.

width="1024" height="688" sizes="auto, (max-width: 1024px) 100vw, 1024px">

Figure: The four pillars of autonomous IT.

Magesh Kasthuri

Third, the framework should be value-led rather than purely cost-led. FinOps has matured beyond simply lowering spend; the stronger objective is to align spend with business priorities, performance requirements and acceptable risk. Fourth, autonomy should progress in stages. Enterprises usually start with visibility, then introduce recommendations, then guided automation and finally closed-loop autonomy for low-risk scenarios. Fifth, executive accountability must be explicit. Operational autonomy touches architecture, finance, privacy, security, data stewardship and business strategy. Without a cross-functional ownership model, autonomy becomes fragmented and difficult to govern. Everest Group’s 2024 FinOps Cloud Cost Management assessment highlights the growing demand for role-based access, cost intelligence, governance and automation as core requirements for enterprise cloud cost management products. That is a useful signal that the framework must be built for collaboration, not just analytics.

Integrating CloudOps, FinOps and AIOps into one operating model

CloudOps, FinOps and AIOps are often discussed separately because each emerged from a different operational problem. CloudOps grew out of the need to run cloud estates reliably and at scale. FinOps developed in response to unpredictable consumption-based billing. AIOps emerged because traditional monitoring could not keep pace with the volume and complexity of telemetry generated across modern digital systems. Yet in a mature enterprise, these disciplines converge naturally.

A performance incident in a cloud platform is rarely only an availability problem; it may also drive higher infrastructure consumption, trigger excess logging charges, degrade customer experience or increase token usage in AI-enabled workflows. Similarly, a cost spike may not be a finance issue alone; it may reveal inefficient architecture, poor scheduling, unnecessary data movement or an AI agent behaving outside policy.

An integrated operating model therefore links observability signals, service context, business KPIs, financial metrics and automation rules into one decision fabric. CloudOps provides the runtime discipline, FinOps introduces value and accountability, and AIOps adds pattern recognition and intelligent response. When connected well, the enterprise can answer not only what is happening, but why it is happening, what it is costing, what risk it creates and what the best next action should be.

AI token optimization and AI cost spend governance

AI introduces a new cost curve into enterprise operations. Unlike traditional software costs, token spend can vary sharply based on prompt design, model choice, context length, retrieval patterns, orchestration logic, concurrency, caching strategy and user behavior. This makes AI cost governance an essential part of operational autonomy. A strong framework begins by defining the unit economics of AI consumption: cost per request, cost per conversation, cost per business workflow, cost per user segment and cost per outcome.

Once these baselines are visible, the enterprise can introduce optimization controls such as prompt compression, response-length policies, semantic caching, model tiering, workload routing to lower-cost models where quality tolerance allows, context-window discipline, batch processing for non-real-time use cases and approval thresholds for premium model usage. AI gateways and model brokers can enforce these policies consistently across teams.

width="1024" height="709" sizes="auto, (max-width: 1024px) 100vw, 1024px">

Figure 2: AI FinOps framework

Magesh Kasthuri

Chargeback or showback mechanisms should also extend to AI services so that business units see both value and consumption behavior. Recent analysis in Forbes has drawn attention to the financial risks of unmanaged token growth and argues for governance layers that connect finance and engineering before AI expenditure becomes opaque. FinOps Foundation guidance on FinOps for AI reinforces the same message, noting that token-level metrics, quotas, tagging, GPU allocation practices and real-time monitoring are necessary to keep AI costs aligned to business value. In enterprise settings, the lesson is straightforward: if cloud cost needed FinOps, AI cost needs an even tighter form of FinOps because usage can scale much faster and become far less transparent as mentioned in IDC report.

FinOps for cloud infrastructure cost management

Cloud infrastructure cost management remains one of the foundational layers of operational autonomy because every autonomous workflow eventually rests on compute, storage, networking, platform services and data transfer. An effective FinOps capability does more than flag overspend after the month has ended. It creates near-real-time visibility into consumption, ownership, unit economics, forecast variance, commitments and waste patterns.

The enterprise should define standard practices for tagging, cost allocation, commitment management, rightsizing, idle resource detection, storage tiering, Kubernetes cost visibility, environment lifecycle controls and architecture reviews for high-cost services. More importantly, these practices should be tied to business context. For example, a workload serving a mission-critical customer channel may justify higher spend if it supports revenue protection, whereas a non-production environment should have stricter shutdown and spend caps.

Gartner’s 2024 research on FinOps for data and analytics underscores that AI and data workloads are changing the financial profile of cloud operations and increasing the need for more sophisticated tooling and governance. IDC’s market perspective on intelligent cloud and edge operations with FinOps software also points to the rapid growth of platforms that combine operations intelligence with financial control, suggesting that enterprises increasingly view operational management and cost management as linked disciplines rather than separate layers.

Autonomous operations through AIOps

AIOps gives the framework its intelligence and response speed. In most enterprises, operations data is noisy, fragmented and too voluminous for humans to interpret quickly during incidents or performance degradation. AIOps platforms reduce that burden by correlating events, identifying anomalies, clustering symptoms, surfacing probable root causes and recommending or initiating remediation actions. The best outcomes appear when AIOps is connected not only to infrastructure monitoring but also to service maps, change records, configuration data, incident workflows and business priorities.

That connection allows the enterprise to distinguish between a harmless signal fluctuation and an issue that threatens a critical business service. Forrester’s 2024 research on AIOps and observability explains this well by describing the complementary value of breadth and depth: observability provides richer technical insight, while AIOps helps transform those signals into operational action. In practice, autonomy grows when low-risk responses such as service restarts, resource adjustments, ticket enrichment, dependency checks or rollback decisions are automated under policy. High-risk actions should remain human-approved until confidence improves. Over time, the enterprise can move from reactive incident management to predictive operations, where emerging capacity risk, recurring error patterns or unusual AI workload behavior are addressed before service impact is visible to users.

How the framework leads to operational excellence

Operational excellence is the cumulative result of better decisions made earlier, faster and with clearer accountability. A well-designed autonomy framework improves service reliability because systems are observed continuously and remediation can be triggered before failures spread. It improves cost discipline because consumption anomalies are identified at the same time as performance or usage anomalies, not weeks later in a billing report.

It improves strategic focus because technology leaders can evaluate trade-offs in terms of business value rather than technical activity alone. It also improves employee productivity by removing repetitive operational effort and shifting skilled staff toward engineering improvements, policy tuning and service innovation. The most important outcome, however, is predictability. Enterprises become more confident in how they scale AI services, how they control cloud spend, how they handle operational events and how they meet compliance obligations. That confidence is what separates routine automation from genuine operational autonomy.

Security, governance, process implementation and people upskilling

No autonomy framework survives without strong security and governance. Automated operations amplify both efficiency and risk, which means identity controls, segmentation, least-privilege access, secrets management, encryption and auditability have to be embedded from the start. AI services add further concerns: prompt leakage, data residency, model misuse, training-data exposure, shadow AI adoption and uncontrolled access to external models.

Governance therefore needs to extend across cloud resources, operational workflows, AI services and data assets. Enterprises should establish clear policy domains covering infrastructure provisioning, AI model approval, token limits, vendor usage, observability data handling, retention rules, access reviews and exception management. Process implementation is equally important. The framework should define standard operating patterns for incident triage, automated remediation approval, cost anomaly review, model lifecycle management and post-incident learning. None of this works unless people are prepared for the shift.

Operations teams need skills in cloud economics, observability, automation engineering and policy-driven operations. Finance teams need to understand cloud and AI consumption models. Security and privacy teams need fluency in AI risk scenarios and control design. Business leaders need a clearer grasp of unit economics and value realization. IDC’s 2024 briefing on enterprise AI strategy highlights the tension between rapid AI investment, ROI pressure, staffing constraints, security and compliance. That is exactly why upskilling must be treated as part of the framework itself, not as an optional change-management activity as per FinOps Foundation documentation.

The role of regulatory compliance

Regulatory compliance is not a side topic in operational autonomy; it is one of the main reasons the framework must be formalized. Cloud environments frequently span jurisdictions, AI systems process sensitive information, observability platforms collect detailed operational data and automated decisions may influence customer experience or internal controls. Regulations such as GDPR, DPDP, sector-specific cybersecurity directives, financial reporting obligations, contractual data-handling requirements and internal audit standards all shape what autonomy can and cannot do.

Compliance requirements should therefore be translated into operational policy. Examples include residency-aware workload placement, data minimization in logs and prompts, access segregation for financial and regulated data, explainable automated actions, evidence retention, periodic control attestations and approval workflows for AI usage involving personal or confidential information. Chief privacy and data leaders play a central role here because the compliance question is no longer just where data is stored, but also how data is observed, transformed and consumed by AI-driven services. A mature framework reduces compliance risk by making control enforcement systematic rather than dependent on manual effort.

How to implement the framework in practice

Implementation is usually most successful when handled in phases. The first phase is baseline visibility: consolidate telemetry, cloud billing data, service inventory, AI usage data and business ownership into one operational picture. The second phase is governance design: define policies for tagging, spend thresholds, automation boundaries, access controls, model usage and compliance checkpoints.

The third phase is prioritization: choose a small number of use cases where autonomy can produce measurable value, such as cloud rightsizing, incident correlation, cost anomaly detection, AI token governance or automated remediation for recurring low-risk faults. The fourth phase is automation with guardrails: deploy workflows, approval rules and rollback paths. The fifth phase is optimization and learning: review outcomes, refine policies, update unit economics, expand autonomy coverage and measure business impact.

This staged approach matters because full autonomy is not achieved by switching on one platform. It is built progressively through trusted control, good data and disciplined execution.

Useful tools for building the framework

The tool landscape should be chosen based on architecture, governance maturity and operating model rather than vendor popularity alone. Cloud-native cost and operations tools from hyperscalers provide baseline visibility, but many enterprises supplement them with specialized FinOps platforms for allocation, forecasting, commitment analysis and chargeback. Observability platforms help unify metrics, logs, traces and service maps, while AIOps platforms add anomaly detection, event correlation and automation orchestration.

Service management platforms remain important for change control, incident workflows and audit evidence. AI gateways and model management layers are increasingly useful for token monitoring, policy enforcement, prompt controls, model routing and usage analytics. Security posture management, DSPM, identity governance and compliance automation tools also become part of the architecture because autonomy without trust quickly becomes fragile. The most effective toolchains are the ones that integrate technical telemetry, financial signals, governance policy and workflow automation into a coherent operating system for the enterprise.

Executive roles in developing and managing the framework

Here is a table that summarizes various Executive Roles and their responsibilities in Operational Autonomy governance.

Executive Role	Primary Responsibility in the Framework	Key Decisions and Governance Focus
CIO	Owns the enterprise operating model and ensures CloudOps, FinOps and AIOps are aligned to business service outcomes.	Sets operating priorities, funds enabling platforms, establishes accountability, sponsors service reliability and cost transparency programs, and chairs cross-functional governance.
CTO	Defines the target architecture for autonomy, including cloud platforms, observability, automation, AI services and integration patterns.	Approves technical standards, automation design principles, platform engineering choices, model architecture strategy and engineering guardrails for scale and resilience.
Chief Privacy Officer	Ensures that data use in observability, automation and AI operations complies with privacy law and internal policy.	Defines controls for personal data handling, retention, consent boundaries, cross-border transfer considerations, prompt and log privacy, and privacy impact assessments.
Chief Data Officer	Leads data governance, data quality, metadata management and trustworthy access to the shared operational data layer.	Defines data classification, stewardship, lineage expectations, AI data usage standards and interoperability rules required for accurate autonomous decision-making.
Chief Strategy Officer	Connects the autonomy framework to enterprise transformation goals, investment priorities and measurable business value.	Shapes business case design, prioritizes value pools, aligns the framework with growth and efficiency strategy, and ensures operating metrics support executive decision-making.

Conclusion

Developing operational autonomy for an enterprise is not about chasing a futuristic ideal. It is about building a disciplined and connected operating model that helps the organization run technology with greater confidence, speed and accountability. CloudOps keeps the estate reliable, FinOps ensures that spending reflects value, AIOps makes complexity manageable and AI cost governance brings much-needed control to token-driven consumption. Security, privacy, compliance, process rigor and people capability are what make the framework sustainable. When all of these parts work together, the enterprise does not just automate tasks; it strengthens resilience, improves financial stewardship and creates a more adaptive path to operational excellence.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Was KI-Agenten wirklich kosten

Wed, 01 Jul 2026 06:08:13 +0200

Die Kosten für Agentic-AI-Initiativen können schnell aus dem Ruder laufen.

Gorodenkoff | shutterstock.com

Agentic AI hat sich vom „Konferenz-Hype“ zu einem eigenständigen Budgetposten entwickelt. Im Gegensatz zu herkömmlichen KI-Systemen, die auf einen einzelnen Prompt reagieren, sind agentische KI-Systeme darauf ausgelegt, Ziele zu verfolgen. Sie planen, greifen auf Tools zurück, überprüfen Ergebnisse oder delegieren Tasks an andere Agenten, bevor sie eine Antwort liefern oder eine Maßnahme ergreifen.

Diese zusätzliche Autonomie ist das Alleinstellungsmerkmal von Agentic AI – schafft aber auch ein Kostenproblem: Während eine einzelne Chatbot-Interaktion einige Tausend Token verbrauchen kann, konsumiert ein agentischer Workflow möglicherweise Hunderttausende oder Millionen von Token pro Tag. Deswegen sollten die wirtschaftlichen Aspekte auch auf Ebene der „Agenteninstanzen“ betrachtet werden – nicht nur auf der der Modellaufrufe.

KI-Agenten – die konkreten Kosten

Für die nachfolgenden Preisschätzungen für KI-Agenten gehen wir von Token-Kosten von drei Dollar pro einer Million Token aus. Hierbei handelt es sich um einen gemittelten Planungswert, der von einem Mix aus Input- und Output-Tokens, Reasoning-Schritten, RAG, Zusammenfassungen, Tool-Aufrufen, Memory Updates und dem gelegentlichen Einsatz größerer Kontextfenster ausgeht. Einige Unternehmen werden weniger zahlen, weil sie Mengenrabatte erhalten oder Tasks an kleinere Modelle weiterleiten. Andere Anwender, die beispielsweise Premium-Modelle nutzen oder umfangreiche Dokumente verarbeiten, werden mehr bezahlen.

Die Grundformel ist simpel: Wenn ein Agent zwei Millionen Token pro Tag verbraucht, ergibt das auf das Jahr gerechnet 730 Millionen Token. Bei drei Dollar pro einer Million Token belaufen sich die (Token-)Kosten für diesen einzelnen Agenten also auf circa 2.190 Dollar pro Jahr. Das klingt nach überraschend wenig, bis man sich bewusst macht, dass diese Zahl mit der Anzahl der Agenten, Workflows und Nutzer multipliziert werden muss – und dann noch die Kosten für die erforderliche Infrastruktur hinzukommen.

Je nach Anwendungsfall variieren die jährlichen Kosten pro KI-Agent (nur für Token) entsprechend:

Ein ressourcenschonender Agent für die HR – etwa für die Personalbeschaffung oder das Onboarding – der täglich eine Million Token verbraucht, kostet etwa 1.095 Dollar pro Jahr.
Ein anspruchsvollerer Agent für die Softwareentwicklung, der täglich 3,5 Millionen Token verbraucht, schlägt mit etwa 3.833 Dollar pro Jahr zu Buche.
Agenten für den Kunden-Support kosten etwa 2.190 Dollar pro Jahr.
Für KI-Agenten, die sich mit Vertragsmanagement auseinandersetzen, werden etwa 2.409 Dollar pro Jahr fällig.
Agenten für die Security-Triage kosten circa 2.738 Dollar pro Jahr.
KI-Agenten für Research-Zwecke sorgen für jährliche Kosten von etwa 3.066 Dollar.

Diese Zahlen sind nützlich, aber unvollständig: Sie umfassen lediglich den Token-Verbrauch von LLMs. Außen vor bleiben hingegen Orchestrierungsplattformen, Vektordatenbanken, Observability, Modellevaluierung, Sicherheitskontrollen, Workflow-Überwachung, menschliche Reviews, die Integration von Unternehmensanwendungen, Daten-Pipelines, Audit-Protokollierung, Prompt-Management sowie die für den Aufbau und die Wartung der Systeme benötigten Spezialisten. In realen Einsatzszenarien würde ich davon ausgehen, dass die Gesamtbetriebskosten in etwa das Zwei- bis Fünffache der reinen Token-Kosten betragen. In regulierten oder geschäftskritischen Umgebungen kann dieser Multiplikator noch höher ausfallen.

An dieser Stelle werden viele Anwendungsfälle für Agentic AI weniger klar: Ein Modell aufzurufen mag kostengünstig sein, das System rund um das Modell ist es jedoch nicht. Agenten, die ein CRM-System aktualisieren, eine Rückerstattung genehmigen oder eine Sicherheitsmaßnahme empfehlen, benötigen entsprechende Schutzmechanismen, Berechtigungen, Protokollierung, Rollback-Mechanismen sowie Eskalationswege für menschliche Eingriffe. Dabei handelt es sich nicht um optionale Funktionen, sondern um solche, die den Unterschied zwischen einer Demo und einem Enterprise-System ausmachen.

Wirtschaftlich sinnvolle Anwendungsfälle für KI-Agenten

Der Kunden-Support ist einer der offensichtlichsten Anwendungsfälle. Bei einer typischen Implementierung zur Support-Automatisierung könnten etwa acht verschiedene Agenten zum Einsatz kommen. Diese klassifizieren eingehende Anfragen, rufen Wissen ab, generieren Antworten, eskalieren an Menschen, prüfen die Qualität, aktualisieren das CRM, erfassen das Sentiment und fahren Analysen. Bei zwei Millionen Token pro Agent und Tag kostet jeder Agent pro Jahr etwa 2.190 Dollar (Token-Verbrauch). Das treibt die jährlichen Gesamtkosten auf rund 17.520 Dollar. Wenn dieses System auch nur eine bescheidene Anzahl von Tickets abfängt oder die Produktivität der Agenten verbessert, kann es wirtschaftlich attraktiv sein.

Sales Development ist ein weiteres praktisches Beispiel. Ein System mit fünf Agenten für Kundenrecherche, Lead-Anreicherung, E-Mail-Personalisierung, CRM-Aktualisierungen und die Planung von Folgeaktionen kann 1,2 Millionen Token pro Agent und Tag konsumieren. Daraus ergeben sich jährliche Token-Kosten von etwa 1.314 Dollar pro Agent und 6.570 Dollar für das gesamte Agenten-Team. Das kann wirtschaftlich überzeugend sein, wenn dadurch die Qualität der Pipeline optimiert wird. Es kann aber auch zu Verschwendung führen, wenn die Mitarbeiter in großem Umfang Kontakte von geringer Qualität generieren.

Agentic AI in der Softwareentwicklung ist zwar teurer, aber potenziell auch wertvoller. Ein System mit zwölf Agenten, das Anforderungsanalyse, Architektur, Codegenerierung, Tests, Reviews, Sicherheitsprüfungen, Dokumentation, CI-Debugging, Refactoring, Versionshinweise, Abhängigkeitsanalyse und Hotfix-Support abdeckt, kann pro Agent und Tag 3,5 Millionen Token verbrauchen. Das entspricht etwa 3.833 Dollar pro Agent und Jahr – oder rund 45.990 Dollar für das gesamte System. Im Vergleich zu den Entwicklergehältern sind diese Kosten gering. Die eigentliche Frage ist allerdings, ob das System den Durchsatz zuverlässig verbessert – ohne Fehler, Sicherheitslücken oder komplexe Wartungsarbeiten nach sich zu ziehen.

Auch der Bereich Security Operations passt zum agentenbasierten Modell, da die Arbeit repetitiv, zeitkritisch und kontextintensiv ist. Ein Sicherheits-Triage-System mit zehn Agenten könnte Alarm-Triage, Protokollanalyse, Bedrohungsinformationen, Endpunktuntersuchung, Netzwerkuntersuchung, Zusammenfassung von Vorfällen, Ticketerstellung, Compliance-Nachweise, Eskalation sowie Nachanalyse umfassen. Bei 2,5 Millionen Token pro Agent und Tag belaufen sich die jährlichen Token-Kosten auf etwa 2.738 Dollar pro Agent. Das gesamte System kostet 27.375 Dollar. Dieser Invest lässt sich leicht rechtfertigen, wenn dadurch die Alert Fatigue reduziert und die Reaktionszeit verkürzt wird. Allerdings geht das auch nicht ohne Risiko einher: Wenn Agenten Kausalzusammenhänge halluzinieren oder kritische Signale in „selbstbewussten“ Zusammenfassungen verschleiern, kann die Initiative schnell nach hinten losgehen.

Auf dieser Grundlage wären Multi-Agenten-Systeme darüber hinaus auch in den Bereichen Finanzen, Recht, Healthcare, Marktforschung, Personalwesen und Supply Chain realisierbar:

Ein Finanzabschlusssystem mit sechs Agenten verursacht jährlich etwa 9.855 Dollar an Token-Kosten.
Ein System zur Überprüfung von Rechtsverträgen mit vier Agenten bringt es auf 9.636 Dollar.
Ein administrativer Workflow im Healthcare-Bereich, der sieben Agenten umfasst, verursacht circa 13.797 Dollar an Kosten.
Ein Team aus sechs Agenten, dass den Wettbewerb beobachtet kostet 18.396 Dollar.
Personalbeschaffung und Einarbeitung mit fünf Agenten abzuwickeln, belastet das Budget mit 5.475 Dollar.
Lieferkettenplanung und Ausnahmemanagement auf der Grundlage eines Teams von acht Agenten zu händeln, kostet etwa 21.024 Dollar.

Traditionelle und agentische KI im Kostenvergleich

Die Wirtschaftlichkeit von Agentic AI sollte stets mit simpleren Ansätzen verglichen werden. Traditionelle KI, Workflow-Automatisierung, Regel-Engines, RPA und nicht-agentische LLM-Calls sind oft kostengünstiger, einfacher zu steuern und besser vorhersehbar. Für Aufgaben wie Klassifizierung, Extraktion, Zusammenfassung, Weiterleitung oder einen Entwurf innerhalb eines engen Kontexts, ist agentische KI in der Regel überdimensioniert. Ein deterministischer Workflow mit einem einzigen Modellaufruf kann diese Tasks einem Bruchteil der Kosten (und Risiken) erledigen.

Agentische Systeme sind immer dann sinnvoll, wenn der Prozess Ermessensentscheidungen über mehrere Schritte hinweg, dynamische Planung, Tool-Einsatz, Exception Handling und die Anpassung an unvollständige Informationen erfordert. Sie sind wertvoll, wenn der Weg zur Antwort nicht vollständig im Voraus festgeschrieben werden kann – und deutlich weniger wertvoll, wenn Unternehmen sie als trendigen Ersatz für grundlegende Automatisierung nutzen.

Die beste Architektur ist in der Regel hybrid: Setzen Sie traditionelle Automatisierung dort ein, wo der Prozess stabil ist. Nutzen Sie nicht-agentische KI, wenn die Aufgabe begrenzt ist. Agentic AI sollte nur an den Stellen zum Einsatz kommen, wo Autonomie einen messbaren Hebeleffekt erzeugt. Das resultiert in weniger Agenten, engeren Anwendungsbereichen, expliziten Budgets, Modell-Routing, Token-Überwachung und menschlichen Kontrollpunkten für Entscheidungen mit großer Tragweite.

Der finanzielle Fehler, den viele Organisationen begehen werden, besteht darin, Agenten als digitale Mitarbeiter mit Grenzkosten nahe Null zu behandeln. Das sind sie nicht. Es handelt sich um probabilistische Softwarekomponenten, die Token verbrauchen, Tools auslösen, operative Abhängigkeiten schaffen und Überwachung erfordern. Die Kosten für die Token lassen sich vielleicht bewältigen. Die Kosten für die Governance möglicherweise nicht.

Agentische KI kann sich durchaus lohnen. In vielen Fällen liegt der jährliche Token-Verbrauch für ein nützliches Agenten-Team unter den Gesamtkosten eines einzelnen Mitarbeiters. Das bedeutet jedoch nicht, dass die Technologie günstig ist. Unternehmen sollten die Agentenkosten pro erreichtem Geschäftsergebnis messen, nicht pro Prompt oder Modellaufruf. Letztendlich geht es auch gar nicht darum, wie viel ein Agent kostet. Sondern darum, die richtige Frage zu stellen – nämlich: Überwiegt die Autonomie, die ein KI-Agent bietet, die Komplexität, die er mit sich bringt? (fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.

AI is exposing the real limits of enterprise cloud strategy

Tue, 30 Jun 2026 13:06:15 +0200

Across the global corporations, I advise, in financial services, healthcare, retail and the public sector, the same crisis surfaces in leadership meetings. Executives approved a bold AI roadmap. Cloud spending climbed 40, 50, even 70 percent. And yet the AI workloads that made perfect sense in the boardroom presentation now stall, overshoot their budgets or collapse under production load before they reach real users.

I am writing this just after the spring 2026 conference season, and the signal from Google Cloud Next, Microsoft Build, and a run of AWS summits only sharpens the point. Over the past several weeks the industry shipped, in production form, the infrastructure to run and govern AI at scale. What most enterprises still lack is the operating model to decide how to use it.

The problem is not the AI models. The models work. The problem is that organizations built their AI ambitions on cloud strategies designed for a world that no longer exists: strategies built for SaaS applications, predictable traffic and linear cost curves. AI workloads break all three assumptions at once.

Why AI breaks traditional cloud assumptions

For a decade, cloud-first served enterprises well. It delivered elasticity, reduced capital expenditure and democratized access to compute, because enterprise workloads were predictable: web applications, ERP systems, databases and analytics pipelines that scaled smoothly and billed in ways finance could model on a spreadsheet. GenAI and agentic AI change every one of those assumptions at once.

When organizations move AI into production, real inference, retrieval pipelines, vector search and real-time decisioning, the cloud equation breaks in at least five ways:

Training clusters demand power densities far above standard compute.
Inference needs millisecond latency that network geography can defeat.
Vector databases generate cost spikes invisible in standard billing.
Agentic workloads chain hundreds of tool calls with cascading dependencies.
And data-sovereignty rules constrain where any of them can run.

In short, what works at the platform level fails at the workload level.

The costs are the first thing to surprise leaders, because they hide. CloudZero’s analysis and the FinOps teams I work with put it plainly: AI spend surfaces as generic compute, storage and instance line items, rarely labeled “AI.” Three layers drive most of the waste:

The most visible is LLM API cost, where stateless calls re-send the full conversation history on every request, so a deployment with a couple hundred users can burn many times the token budget in the business case.
The biggest is idle GPU: teams’ provision for peak and then run at 10 to 20 percent utilization, and most miss their AI cost forecasts by more than a quarter.
The most underestimated is the vector database and retrieval layer, where storage I/O, query volume and embedding refresh appear nowhere labeled AI until the bill arrives.

The dimensions leaders underweight resilience and control

Cost and latency dominate the conversation. Two dimensions rarely get the same rigor until something breaks:

Resilience, whether an AI-dependent system can survive failure, degrade gracefully and recover predictably.
Control, who can observe, halt and audit it.

AI introduces failure modes that traditional architecture never faced: GPU single points of failure under revenue-critical inference, agentic pipelines that fail mid-execution with no rollback, and models that degrade silently from drift or throttling.

I see the pattern repeated across industries. Organizations design resilience for their traditional applications, then deploy AI on top without asking whether the same guarantees hold. In one global financial services firm I advise, a real-time credit-decisioning model running on a single cloud region took a 47-minute outage during a regional availability event. The halted loan approvals cost more than the system’s entire annual infrastructure budget, and the resilience rework that followed cost several times what designing it in from the start would have. The leaders who avoid this should ask four questions before go-live:

What happens when the network fails?
What happens when the model degrades?
What happens when an agent executes only halfway?
Who holds the authority to halt and audit?

What the cloud providers signaled this spring

The major providers are on track to spend close to $700 billion on AI infrastructure in 2026, roughly three and a half times the 2024 level. Their announcements are strategic signals, not just features. Last year they converged on one message: enterprises cannot run everything in public cloud, so all three built ways to bring their infrastructure into your data center and your sovereign environment. This year the signal advanced a step. They stopped talking about where workloads run and started shipping the layer that governs what agents are allowed to do: identity, containment, auditability and rollback.

Microsoft introduced an “Agent Computer” model with execution containers and machine identity for agents. AWS built Amazon Bedrock AgentCore around runtime, memory, identity and auditability. Google shipped an agent gateway and sovereign controls for cross-cloud traffic. As Bain observed, agentic AI is now an economics and operations problem, not just a capability problem. The through-line, captured by Microsoft’s own framing, is that AI alone will not change your business; the system running it will. McKinsey’s read is consistent: workloads are becoming more distributed, specialized and operationally demanding, which forces more deliberate infrastructure decisions.

Vipin Jain

From platform choice to placement decision

The failure I document most often is not a technology failure; it is a governance failure. Most enterprises lack a clear, repeatable way to decide what runs where, under what conditions and with what tradeoffs. Platform teams make that call informally, under deadline pressure and repeat it hundreds of times as new use cases launch. Workloads then accumulate in public cloud by default, not by design and 30 to 50 percent cost overruns follow, not because public cloud was the wrong choice but because no deliberate choice was ever made.

In one global manufacturer I advise, a predictive-maintenance model went live on public cloud and performed exactly as validated in staging. But real-time inference on the factory floor ran at 80 to 120 milliseconds across the WAN, when the machine-control system needed under ten. Moving the model to edge nodes fixed the latency, but the company lost most of a quarter of the cost, rework and delayed benefits, and the line had run for weeks on stale recommendations: a control failure that could have caused a safety event. The fix was never more AI talent. It was a structured placement decision at the start, weighing six dimensions:

Latency: real-time (under 10 ms, edge or on-prem), interactive (50 to 500 ms, cloud) or batch.
Cost and TCO: token spend, GPU utilization, vector-database queries, egress and unit economics per workload.
Resilience: failover architecture, degraded-mode behavior, recovery SLA and rollback policy.
Control: observability, audit trails, governance authority and the ability to halt or reverse.
Data sensitivity: sovereignty requirements, privacy and compliance rules, and IP protection.
Integration: legacy system dependencies, pipeline complexity and data-residency constraints.

Run consistently, those dimensions produce a placement pattern like this:

Workload	Latency	Cost predictability	Data sovereignty	Recommended path
Customer-facing chatbot	200-500 ms	Medium	Low risk	Public cloud, reserved instances
Real-time fraud detection	Under 10 ms	Medium	High	On-prem or sovereign private cloud
Clinical decision support	100-300 ms	Predictable	Critical	Sovereign cloud or dedicated VPC
Demand forecasting (batch)	Hours	High	Low risk	Spot instances or scheduled cloud
Factory-floor vision AI	Under 5 ms	Predictable	Medium	Edge node (Azure Local, AWS on-prem)
Internal knowledge assistant	1-3 sec	Variable tokens	High (IP risk)	Private cloud with on-prem retrieval

This is no longer optional. Cloudian’s 2026 enterprise AI infrastructure survey found that 79 percent of enterprises have already moved AI workloads out of public cloud, and 93 percent are repatriating or actively evaluating it, driven by data sovereignty, cost overruns and real-time performance. Repatriation is now the norm, not the exception.

The agentic layer makes discipline urgent. An agent chains 20 to 100 tool calls, each with its own latency, cost and failure mode, so the governance model that works for a chatbot does not work for an autonomous agent approving procurement or onboarding a customer. This spring the providers shipped production infrastructure for exactly this, yet Deloitte’s 2026 survey of more than 3,000 leaders finds only about one in five companies has a mature governance model for autonomous agents. The platforms solved the mechanism. Most enterprises have not yet written the policy.

What the leaders do differently

The organizations extracting compounding value from AI, not just running experiments, share one discipline: they treat workload placement as a repeatable process, and they build resilience and control in from the start rather than after the first production incident. In practice, they do five things:

Classify every use case at intake across the six dimensions, before any infrastructure is provisioned.
Separate AI budget lines for experiments, production inference and training, so cost is governable.
Treat unit economics, cost per inference, per query and per agent run, as engineering KPIs, not month-end surprises.
Define repatriation triggers in advance, typically 12 to 18 months of stable volume.
Write an explicit resilience contract, and agentic observability and rollback rules, before scaling.

The gap between strategy-ready and infrastructure-ready is the remediation backlog, and most enterprises stall moving from proof of concept to production for exactly this reason. Deloitte’s tech-trends analysis frames the same shift as the move to inference economics: the bottleneck is infrastructure governance, not model capability.

Vipin Jain

For CIOs, a 90-day agenda. Five actions separate the leaders from those managing infrastructure crises:

Audit every AI workload in production across latency, cost, sovereignty, volume, resilience, control and integration.
Separate AI infrastructure budget lines so each workload type is attributable and governable.
Define unit economics by workload and review them as engineering KPIs.
Set a quantitative repatriation evaluation trigger.
Define observability, cost attribution and rollback policy before scaling agents.

The strategic reframe

The organizations making real progress on AI are not distinguished by the sophistication of their models or the size of their cloud contracts. One discipline sets them apart: a clear, repeatable way to decide what runs where, under what conditions, with what tradeoffs and what happens when something fails. That discipline is not an IT problem. It is a strategic capability that requires CIO ownership, CFO alignment and executive accountability.

This spring the cloud providers handed enterprises the infrastructure to run and govern AI, and agents, at every tier of the architecture. The gap is no longer supply. It is the operating model to use deliberately. The companies building that model now build the operating foundation for AI at scale. Everyone else builds a remediation backlog. The infrastructure decisions you make in the next 12 months will decide which of those two you become.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Five tools to bolster your AI coding stack

Tue, 30 Jun 2026 11:18:27 +0200

Whether you are using an AI code generator, vibe coding, or applying spec-driven development methodologies, your job doesn’t end with AI writing the code. Whether you’re using AI to develop applications, APIs, data pipelines, AI agents, or other automations, writing the code is just one part of the job. Developers must still perform code validation, test applications, automate deployment, and configure infrastructure.

According to one survey, only 16% of a developer’s time is spent writing code. The remaining 84% is spent on other activities including defining requirements, triaging bugs, and addressing vulnerabilities.

Additionally, while AI code generation speeds up development, it can come at the cost of quality and collaboration. In Atlassian’s State of Teams 2026 survey, nearly 50% of respondents say their AI outputs aren’t reliably high quality and admit that using AI is a compromise between speed and quality. Knowledge workers say the pressure to execute is also problematic, with 87% saying they lack time to coordinate and 70% saying their processes aren’t well-optimized for AI.

So, although AI capabilities have changed drastically in the past few years, code-generation tools are not the only ways AI can improve software development. In fact, developers should seek additional AI capabilities to support the full software development life cycle (SDLC). Here are five recommendations for the AI coding stack.

Scale up testing environments

If coding is faster, development teams should have suitably configured environments that they can use to quickly and easily test changes against real APIs and databases. Testing apps and AI agents against environments that don’t mimic production can slow down development.

“Remote + local” development environments (local execution with remote context) are one option to accelerate testing. Developers can code locally on their own physical or virtual machine, but build and deploy to remote instances. Additionally, when developing AI agents, developers need an execution environment, such as secure sandboxes or ephemeral virtual machines.

“GenAI has been a step-change for developer productivity, absorbing the repetitive work of writing boilerplate, tests, and refactors so engineers can focus on intent and design,” says Aviram Hassan, CEO and cofounder at MetalBear. “But by compressing the time it takes to produce all of this, genAI has also exposed what’s always been the real bottleneck in the SDLC: the feedback loop against the real world. Validating code and configurations against a realistic cloud environment still depends on the same slow build-and-deploy cycles teams have tolerated for years.”

The goal should be to remove the friction and delays from where developers code to a complete, real-world infrastructure they can use to validate changes. Three tools to review are mirrord, Signadot, and Telepresence.

Validate the AI-generated code

At a recent Coffee With Digital Trailblazers LinkedIn Live event that I hosted on AI coding competencies, one speaker shared how he quickly went from a short spec to more than 10,000 lines of AI-generated code. He admitted he didn’t have the time, expertise, or tools to validate the code. He’s not alone. In Sonar’s State of Code Developer Survey, 96% of developers don’t fully trust AI’s output, but only 48% always verify it before committing.

“Agentic software development is generating code faster than any team can manually review it, but speed without confidence only results in technical debt,” says Scott Sanders, corporate vice president of engineering at Sonar. “What’s needed to avoid this is an automated independent verification layer embedded directly into the development workflow—one that unifies code quality and code security into a single, deterministic platform to deliver actionable intelligence before code ever reaches the repository.”

A big concern is that AI-generated code can produce 1.4 times as many critical issues as code created by developers, according to CodeRabbit’s State of AI Versus Human Code Generation Report. Top issues include code readability, cross-site scripting, code formatting errors, and incorrect concurrency control.

Another challenge is that 82.4% of AI tools originate from third-party packages, according to Snyk’s 2026 State of Agentic AI Adoption. The implication is that development teams have much more code to validate than they develop themselves, whether by humans or AI code generators.

“When tools like Cursor are installing dependencies and running actions on a developer’s behalf, they can unintentionally pull in malicious or unvetted packages,” says Randall Degges, vice president of AI engineering and developer relations at Snyk. “That’s why techniques like intercepting tool calls, validating inputs and outputs, enforcing least-privilege access, and isolating credentials are becoming foundational to how AI-driven development systems operate. Without security embedded directly into the agent loop, teams risk shipping faster into more exposure, not less.”

According to Qodo’s report on The AI Coding Paradox, 89% of enterprise engineering teams have experienced an AI-generated code incident and have had a production outage caused by AI-generated code. Development teams building a large portfolio of AI agents or heavily relying on AI code-generation capabilities may want to look at AI code-review tools that provide more contextual analysis than basic static code review tools.

“Current AI coding assistants suffer from a severe amnesia problem, and each session starts without memory of an organization’s unique context, subjective standards, and business logic,” says Itamar Friedman, CEO and cofounder at Qodo. “To safely scale AI, it requires integrating stateful systems equipped with persistent organizational memory that continuously learn from past pull requests and automatically enforce enterprise-specific governance. Ultimately, developers need tools that ensure code is guided by continuously learning organizational experience rather than just raw machine-generated code.”

Tools to review include static application security testing (SAST), software composition analysis (SCA), software bill of materials (SBOM), and AI code review tools.

Security and end-to-end testing

Even when AI-generated code passes all the tests, how can devops teams validate whether it meets business and non-functional technical requirements? Many devops teams have invested in continuous testing, and some support continuous deployment, but the underlying assumptions behind those practices are being challenged now by who is coding and how much code is being generated.

Some spec-driven development platforms aim to bridge the gap. Tools like Appian Composer and SAP Joule Studio 2.0 generate product requirements documents (PRDs) before coding, enabling the introduction of business acceptance criteria. These tools create knowledge graphs from the business processes implemented on their platforms and provide environments for validating AI agents before deployment.

“For most organizations, the AI code-generation methodology question matters less than the verification question,” says Gal Vered, CEO and cofounder at Checksum.ai. “Whether your team is prompting from intent or working from specs, AI-generated code still needs to be validated against a production environment before it ships.”

Beyond functional testing, developers must look at new security concerns, especially as AI agents integrate with Model Context Protocol servers. “Most teams are stacking generation tools on top of review tools and on top of testing tools, but without security validation embedded at every stage, you’re just automating the path to your next breach,” says Harshit Agarwal, CEO at Appknox. “Mature teams treat security feedback as a non-negotiable part of the build loop, running automated checks continuously rather than catching issues after the fact.”

Add observability tools

Developers save an average of 3.6 hours per week with AI coding tools, according to one report, and the more experienced engineers achieve the largest productivity gains.

What’s one way to blow these savings? When defects get pushed to production, it’s often the site reliability engineers and senior developers who are left to triage and resolve the issue. Establishing observability practices as a devops non-negotiable is a development investment that pays off significantly to help diagnose issues, resolve errors, and improve performance.

“In data and AI systems, even small changes like model updates, tool decisions, or shifts in data flow can silently cascade into issues no one anticipated, and the AI agent has no way to know that,” says Barr Moses, cofounder and CEO at Monte Carlo. “Leading teams are addressing this by embedding observability across the entire agentic stack, particularly at precommit checkpoints, so agents can surface the true impact of changes before they go live.”

While many devops teams have mature observability practices for APIs, applications, and data integrations, observability practices for AI agents are relatively new. One technique to consider is AI tracing platforms with notation queues for human review and LLM-as-judge evals. A second option is to implement an AI gateway with observability, caching, routing, and cost-tracking capabilities.

Develop reusable agent skills

One last element of the AI stack, especially for organizations heavily investing in AI agent development, is to adopt best practices for developing reusable skills embedded in code-generating tools.

“A key emerging pattern is purpose-built AI skills: reusable, scoped instructions that give agents deep context for specific tasks, rather than relying on general-purpose prompting alongside antagonist agents that challenge other agents’ outputs,” says Phillip Goericke, CTO of NMI. “The defining shift is that developers are no longer writing code with AI assistance—they’re architecting the systems that produce and validate it.”

Development organizations that leverage code-generation tools are recognizing that coding is just one part of delivering business value from AI and resilient AI agents. Developing AI skills and establishing an AI stack are steps toward scaling to a dependable AI software development life cycle.

IT-Umgebungen ganzheitlich überwachen

Tue, 30 Jun 2026 05:19:52 +0200

Full-Stack Observability (FSO) verbessert die Sicht auf die gesamte IT erheblich. Besonders anschaulich zeigt sich das bei SAP-S/4HANA-Migrationen.

Tags: #Full-Stack Observability | #SAP S/4HANA

U.S. Open powers up AI-ready network in challenging environment

Tue, 30 Jun 2026 05:19:51 +0200

Cisco’s work with the USGA at the 2026 U.S. Open at Shinnecock Hills Golf Club was a live testbed for what AI-ready networking and security look like in the wild — not in a lab, not in a climate-controlled data center, but across 18 holes of constantly changing terrain, crowds, and threats. It’s also a blueprint that network engineers in other industries can borrow as they grapple with the convergence of connectivity, security, and AI apps.

Golf as a worst‑case network environment

From a distance, it’s tempting to lump golf in with stadium or arena networking. The reality on the ground is very different. Stadiums offer a fixed concrete bowl and predictable RF patterns. A U.S. Open venue is effectively rebuilt every year: temporary structures, new hospitality layouts, shifting fiber routes, and a crowd that never sits still.

Christian Rodriguez, senior manager, IT operations, from the USGA’s technology team, captured that reality when he explained why they tear down and rebuild from scratch: No two championships share the same layout, ISP entry points, or even the placement of critical compounds. They don’t simply clone last year’s configs; they design for the specific course, topology, and constraints of that site. That level of contextual design is expensive, but it’s also the only way to avoid brittle architectures that fall apart as soon as the environment changes.

Environmental conditions add another layer of complexity. Anthony Santora, managing director of IT for the USGA, describes the championship network as a data center without the usual comforts. There’s dust, rain, wind, and wide temperature swings instead of clean, controlled air. Hardware resides in trailers and weatherproof enclosures, not in racks behind raised floor tiles. For network engineers who spend most of their time on office campuses and in colos, that’s an important reminder: Critical infrastructure increasingly sits in places that look nothing like a traditional wiring closet.

User behavior is just as hostile. The U.S. Open has its own term — the “Tiger effect” (though one could argue it’s now the Scottie effect) — for what happens when tens of thousands of fans follow a single golfer. The hot spot moves with the group, and the RF design must cope with a dense, moving cluster of devices. That pattern should sound familiar to anyone who supports large conferences or festivals; it’s the same phenomenon, just under a different name.

Building an AI‑ready, fault‑tolerant course network

Cisco’s answer to this environment is a fully redundant, mobile core design. Instead of a single large core in a building, the network collapses into dual trailers that serve as cores on the go, typically anchored at the NBC broadcast compound and another central location. Each core hosts Cisco Secure Firewall appliances, FMCs, core Catalyst switches, DHCP, UPS, and generators, all in pairs. Rodriguez was matter-of-fact about the philosophy: “We do everything in pairs as much as we can.” If one fails, its twin picks up the load.

From those cores, the team builds a ring topology around the course, using diverse fiber paths — including trenching fiber through wooded areas — to avoid single points of failure. Mobile IDF kits in cooled cabinets serve as distribution points, delivering connectivity to weatherproof access switches and Wi-Fi access points around hospitality tents, grandstands, and entry gates. Everything on the backbone operates at Layer 3, with HSRP (Hot Standby Routing Protocol) and routing redundancy to ensure that a single switch failure doesn’t take out large swaths of the network.

The scale of a golf course deployment is massive as well, with about 500 access points and more than 100 switches, many of them the latest Wi‑Fi 7 and campus platforms. What matters is not the absolute numbers but the duty cycle. Every TV, every POS terminal, every credential pedestal, every media workstation, and every fan device share this converged fabric during a compressed, high‑risk period. Santora points out the business impact in simple terms: If merchandise goes down for even five minutes, lines explode and fans walk away. There’s no “we’ll patch it on the next maintenance window.”

On the RF side, the shift to Wi‑Fi 7 is more than a speed upgrade. Santora’s team has seen real-world performance improvements — hundreds of megabits down in the middle of a packed media center – but the more important change is resilience under high density. When you combine wider channels, better scheduling, and smarter management with a dense deployment, you get something that can withstand the Tiger Effect and the crush of content creators and broadcasters.

That last group is critical. Rob Neumann from Cisco notes that at these events, upload traffic now dominates download traffic. Influencers, media teams, and fans are publishing in near-real time, and cellular uplink simply can’t keep up. High-capacity Wi-Fi with solid backhaul isn’t a luxury; it’s the only way to avoid a miserable experience for the most vocal, visible part of the audience.

width="894" height="1024" sizes="auto, (max-width: 894px) 100vw, 894px">

Zeus Kerravala

Security: Treat every device as untrusted

If the connectivity story feels familiar, the security posture at the U.S. Open is where this deployment begins to diverge from more generic “converged stadium” narratives. Santora has to contend with “thousands of untrusted devices” each championship week: fans, vendors, media, broadcasters, and staff, many of whom plug in or connect to networks the USGA doesn’t control outside the event. The USGA is well aware of the risks: outages or breaches could lead to data and financial losses, as well as reputational damage that would undermine the organization’s core mission, not just its IT metrics.

Cisco Secure Firewall, AnyConnect, Duo, and other components form the core security stack, but how they’re used is the differentiator. Fan Wi‑Fi runs with strict isolation: every client is segmented, so lateral movement is essentially off the table. Neumann explains it simply — each fan has an isolated path out — but under the covers, you get VLAN separation, policy enforcement, and inspection that treat fan traffic as untrusted end-to-end.

The rest of the network is equally segmented. There’s a separate network for ShotLink and everything “inside the ropes,” including scoring and betting feeds. Back-of-house traffic for staff, concessions, and retail runs on its own network. Remote POS systems are segmented again. Broadcast compounds and production systems have their own paths and policies. The result is a unified, converged physical fabric with tightly controlled logical overlays.

This is a pattern many enterprises discuss but struggle to implement: a single platform that carries many classes of traffic, each with its own risk profile, without collapsing into a flat, lateral-friendly network. The U.S. Open shows that it’s possible — but only if segmentation is treated as a core design principle, not an afterthought.

Observability and AI security in the loop

Security and availability at this scale demand observability. Here again, Santora’s team is in the middle of a transition many enterprises are grappling with: moving from reactive log-scraping to proactive, correlated telemetry.

Instead of manually combing through firewall and switch logs, the USGA and Cisco have built a pipeline into Splunk and Cisco’s observability tools. Neumann describes it as a single pane of glass across the network, but the more important point is what feeds that view: APs, switches, firewalls, cameras, and applications, all instrumented and reporting. When you combine that with full-stack observability, you can spot anomalies in real time, whether they’re performance issues or indicators of compromise.

That observability story extends to AI. One of the headline features of the renewed Cisco–USGA partnership is the AI-powered rules assistant: an application that lets golfers and fans ask complex rules questions in the USGA app and receive near-instant guidance. Under the hood, Santora’s team started with question–answer pairs and built a knowledge graph that now spans hundreds of topics and clusters. They also built an evaluation program that identifies outliers — questions the system struggles with — and feeds them back into human review.

Cisco AI Defense wraps the assistant with security controls. It’s not enough to get rules right; the system must resist prompt injection, data exfiltration, and other AI-specific threats that are increasingly appearing in the wild. The teams monitor usage, validate models, and protect applications at runtime against misuse or abuse. Perhaps most importantly, they keep a human override in place. If the system isn’t confident, it won’t answer; it escalates to rules experts rather than bluffing.

This is a model network engineers should watch as AI assistants and agents proliferate across other industries. The U.S. Open rules assistant isn’t treated as a toy or a sidecar; it’s a mission-critical application that resides within the same protected fabric as POS, scoring, and broadcast and is subject to the same observability and security rigor.

Lessons for network engineers beyond golf

Strip away the golf-specific details, and a set of lessons emerges:

Design for tough, not ease. Assume transient structures, unknown RF patterns, seasonal layout changes, and harsh environmental conditions. The U.S. Open team rebuilds from scratch for each venue; most enterprises don’t need to go that far, but they should at least validate designs against real-world changes rather than assuming a static topology.
Make redundancy systemic. Dual cores, dual firewalls, ring topologies, HSRP, Layer 3 everywhere, spare hardware on site, and live failover drills are all part of the fabric. Redundancy isn’t a checkbox on a data sheet; it’s an operational discipline.
Treat every device as untrusted. Fan devices, vendor systems, broadcast laptops, and staff phones all arrive with unknown posture. Segmentation — per-client isolation, dedicated networks for sensitive functions, and strong identity — is the only sustainable way to cope with that diversity.
Upload is the new download. Traditional designs optimized for download traffic are increasingly misaligned with reality. Conferences, stadiums, and campuses now behave like the U.S. Open: content creators and collaborative apps push far more data than they pull. Wi-Fi 7 and modern campus platforms help, but you still need to design RF and backhaul with upload and lateral traffic in mind.
Integrate observability and AI security from day one. Logs alone aren’t enough. Coherent telemetry, full-stack observability, and AI-focused security controls should be treated as first-class requirements, especially as AI assistants move into business-critical workflows.

Final thoughts

Perhaps the most important takeaway is cultural rather than technical. Santora and his team position AI and automation as tools for scale, not as replacements for experts. The rules assistant accelerates responses and expands reach, but it still defers to human judgment when confidence is low. The network uses automation and observability to keep a complex environment running, but it still depends on experienced engineers, in trailers on-site, watching for issues and making decisions.

For network engineers in other industries, that’s a useful template: Build AI-ready, secure, observable networks that assume the worst about their environment, and pair them with human expertise that can adapt when reality inevitably diverges from the design.

width="1024" height="673" sizes="auto, (max-width: 1024px) 100vw, 1024px">

Zeus Kerravala

Debugging production agents with Amazon Bedrock AgentCore Observability

Mon, 29 Jun 2026 19:32:33 +0200

In this post, you learn how to debug production agent failures using built-in observability capabilities. We walk through common failure patterns, show how to analyze agent behavior with traces and metrics, and provide structured workflows for resolving issues such as infinite loops and tool invocation failures. This is Part 1 of a two-part series. Part 2 covers performance optimization and memory management.

How AI observability helps organizations move from experimentation to production

Mon, 29 Jun 2026 16:47:37 +0200

AI observability prevents invisible drift and reduces AI overheads to deliver multiple model, agent driven systems.

Grounding, not models, will define your AI advantage

Mon, 29 Jun 2026 13:03:15 +0200

Over the past two years, working inside the enterprise AI infrastructure world, tracking where the industry is heading, I have noticed the same question surface repeatedly: should we build our own large language model? I understand the instinct. The model feels like the thing, the engine, the brain, the asset worth owning. But after significant years as a product manager in the AI world in both customer experience and grounding infrastructure I concluded that it tends to unsettle the room: the model is the least durable part of your AI strategy.

I say this not to be provocative, but because over the last few years we have seen organizations pour their scarcest resources, executive attention, engineering talent, capital, into the one layer of the stack that is commoditizing fastest. Meanwhile, the layer that determines whether their AI is trustworthy, accurate and defensible gets treated as plumbing. That inversion is, in my experience, the single most expensive mistake enterprises are making with AI right now.

The model is becoming a commodity

Let us consider economics. Gartner projects that by 2030, performing inference on a trillion-parameter model will cost providers more than 90% less than it did in 2025, with models becoming up to 100 times more cost-efficient than the earliest versions of comparable size. When the cost of the underlying capability collapses by that magnitude, it stops being a differentiator. Anything that gets that cheap, that fast, is not where competitive advantage lives.

Models that feel innovative are routinely surpassed by something cheaper and better within months. If your advantage is tied to a specific model, it will evaporate the moment the frontier moves, which it always does. But if an enterprise instead invests in how reliably it can feed any model its proprietary context, that investment holds. That part travels from one model generation to the next. When a better model arrives, the organization can simply connect it and immediately capture the upside, because the hard and durable work was already done one layer down.

I wish more leaders could observe this pattern before they commit. The model layer is improving so quickly that any advantage you build into it has a short half-life. The grounding layer behaves in the opposite way: every improvement you make to your data quality, your retrieval logic and your governance compounds, and it carries forward regardless of which model sits on top.

This is why the build-your-own LLM debate so often misses the mark. Training or even meaningfully fine-tuning a foundation model is enormously expensive, and the moment you finish, the open and commercial frontier has usually moved past you. So, technically you spent a fortune to own a depreciating asset. The capability that you should focus on is an AI that knows your business, was never going to come from the weights of the model anyway. It comes from what you put in front of it.

Why grounding is the real moat

Grounding is the discipline of connecting a general-purpose model to your enterprises’ current and authoritative information, most commonly through retrieval-augmented generation, or RAG. Rather than hoping the model memorized something useful during training, you retrieve the relevant facts from your own systems in real time of the query and give the model the context it needs to answer correctly.

Here is the part that matters for anyone thinking about competitive advantage: your competitors can rent the exact same model you use. What they cannot rent is your data, your institutional knowledge, your processes and the quality of the pipeline that surfaces all of it accurately at the right moment. That pipeline is genuinely proprietary, genuinely hard to replicate and it compounds in value over time. That is the textbook definition of a moat, and it has almost nothing to do with which model you chose.

The industry is starting to recognize this. Gartner predicts that by 2027, organizations will use small, task-specific models at least three times more than general-purpose LLMs, precisely because accuracy in real business workflows depends on domain context rather than raw model scale. But a smaller model holds less in its parameters by design, which means it leans even harder on retrieval to supply current, authoritative context in real time. The model gets smaller and more swappable. The grounding becomes the part that carries the weight. In that same analysis, Gartner makes the same point from the data side: what sets enterprises apart is how well they prepare, check, version and manage their own data. Read that again: the differentiator is the data discipline, not the model.

This matches what I have observed directly. Getting hold of an excellent model was never the hard part, and it was rarely where things broke. The failures I have seen came from not connecting the model efficiently to the right data sources or orchestrating retrieval well. The patterns repeat: missing data produces incomplete summaries, truncated documents leave answers without key details, and noisy context yields irrelevant or confusing responses.

When grounding is absent, answers become inconsistent from one client to the next; when retrieval comes back empty, the model fills the gap with something hallucinated or useless. Stale data produces confidently outdated answers, retrieval gaps surface as generic non-answers, and poor-quality data drags down both speed and output. None of these are model problems. They are grounding problems. And when a system hands an executive an answer that is wrong, no one in the boardroom cares how sophisticated the model was. They care that it was wrong, and the fix always lives in the grounding layer.

One example has stayed with me. In a real enterprise scenario, an AI assistant returned inconsistent answers to the same query across different environments whenever grounding was unavailable, and some of those answers contradicted each other outright. The cause was straightforward in hindsight. With no grounding, the system fell back on its own internal knowledge instead of a shared, grounded source of truth, so its responses drifted with each configuration and context. The damage was not just technical. Users stopped trusting an assistant that could not give them the same answer to the same question twice. That is the actual cost of weak grounding, and it is why consistency and reliability in production depend far more on the data layer than on the model sitting above it. No model upgrade would have fixed that.

Where leaders should focus their investment

If you accept that grounding is where advantage accrues, a few priorities shift in ways that should change how you allocate budget and attention.

First, treat your organization’s data foundation as a first-class AI investment, not a prerequisite you rush through. The unglamorous work, cleaning, structuring, governing and versioning your knowledge, is the work that determines AI quality. I would rather inherit a mediocre model with an excellent retrieval pipeline than the reverse, every single time.

Second, build for model portability from day one. Assume the model you use today will be replaced within a year because it certainly will. If swapping it out is painful, you have coupled your architecture to the wrong layer. Your grounding infrastructure, your evaluation framework and your data contracts should be the stable core; the model should be a component you can swap with minimal disruption.

Third, invest in observability and evaluation for retrieval, not just for the model. The emerging discipline here matters: Gartner expects LLM observability investments to reach 50% of GenAI deployments by 2028, up from 15% today, as trust requirements outpace the technology itself. Knowing why your system retrieved a particular piece of context, and whether that context was correct, is what makes an AI output defensible and auditable. For any organization operating under real regulatory or reputational scrutiny, that is not optional.

None of this means the model is irrelevant. You still need a capable one and choosing well matters. But choosing a model is now a procurement decision with several excellent options, not a source of lasting differentiation. The lasting differentiation is everything you wrap around it.

I think the organizations that internalize this will look, in a few years, meaningfully ahead of the ones still debating whether to train their own model. Not because they made a bolder bet, but because they made a more durable one. They understood that in a world where everyone has access to the same extraordinary models, the advantage belongs to whoever grounds those models best in the reality of their own business. The model is rented. The grounding is owned. Build accordingly.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Cloud-Strategien sind komplexer denn je

Mon, 29 Jun 2026 06:07:07 +0200

Mit dem KI-Boom spielt die Auswahl der Cloud-Lösung(en) für Unternehmen eine noch stärkere Rolle.

Gorodenkoff / Shutterstock

Nach jahrelanger Erfahrung mit der Cloud glaubten IT-Führungskräfte, ihre Strategien diesbezüglich endlich fest im Griff zu haben. Dann kam die KI.

Die aktuellen Herausforderungen rund um die Cloud gehen jedoch weit über künstliche Intelligenz hinaus. Dazu zählen neben der Frage, wo Workloads für maximale Effizienz platziert werden sollten, auch Governance-Anforderungen, Datensouveränität, zunehmend ausgefeilte Cyberbedrohungen und steigender Kostendruck. All diese Faktoren machen die Cloud-Landschaft immer komplexer.

Mehr als ein Infrastrukturthema

„Das Ganze hat sich zu einem ziemlich komplexen Durcheinander entwickelt“, stellt der Cloud-Experte David Linthicum fest. Eine moderne Cloud-Strategie müsse heute Private Clouds, Multi-Cloud-Umgebungen, Hybrid-Cloud-Modelle und souveräne Clouds berücksichtigen – deutlich mehr, als die meisten CIOs bislang bewältigen mussten.

Anfangs drehten sich die Diskussionen rund um Cloud vor allem um Agilität, Skalierbarkeit und Kostenoptimierung, erklärt Joshua Bellendir, CIO des Einzelhändlers WHSmith North America. „Heute müssen wir eine wesentlich größere und komplexere Zahl von Faktoren berücksichtigen: KI-Bereitschaft, Cybersicherheit, Data Governance, Anforderungen an die Datensouveränität, Edge Computing, Integrationsarchitekturen und operative Resilienz.“

Eine der größten Veränderungen bestehe darin, dass die Cloud nicht mehr nur ein Infrastrukturthema sei, so Bellendir. „Sie ist inzwischen eng mit Unternehmensarchitektur, Business Transformation und Datenstrategien verknüpft.“

Auch Amit Basu, Vice President, CIO und CISO bei International Seaways, beobachtet zunehmende Komplexität. „Zwar gelten die Vorteile geringerer Investitionskosten und höherer Flexibilität in vielen Bereichen weiterhin, doch das Management der Cloud-Umgebung ist deutlich anspruchsvoller geworden.“, erklärt er.

Jason Johnson, CIO des Musikinstrumentenhändlers Sweetwater, beschreibt die aktuelle Situation als eine der komplexesten Phasen überhaupt für das Cloud-Management. Die Anbieter erweiterten ihre Portfolios kontinuierlich um neue Services, Produktvarianten und Optionen.

„Das schafft zwar zusätzliche Möglichkeiten, verursacht aber auch erheblichen Aufwand, um den Überblick zu behalten. Man braucht Fachkräfte, die nicht nur wissen, was verfügbar ist, sondern auch beurteilen können, welche Lösung für den jeweiligen Anwendungsfall die richtige ist“, meint der IT-Entscheider.

Viele Unternehmen würden inzwischen in eine zweite Phase ihrer Cloud-Reife eintreten, nachdem sie in der ersten Phase den Fokus auf Migration und Modernisierung gelegt hätten, erklärt Johnson. „Heute geht es stärker um Optimierung, Governance, KI-Unterstützung und nachhaltigen Betrieb. Dieser Wandel verändert die Diskussionen, die ich mit CIOs führe, grundlegend.“

Die wenigsten CIOs können es sich jedoch leisten, lange über ihre nächsten Schritte nachzudenken. Sie müssen den Herausforderungen zunehmend komplexer werdender Cloud-Strategien aktiv begegnen.

Wie KI die Cloud-Gleichung verändert

„Der Wunsch, KI möglichst schnell einzuführen, setzt IT-Verantwortliche erheblich unter Druck. Dabei spielt die Cloud eine zentrale Rolle“, führt Linthicum aus. „Die Aufsichtsräte treiben das Thema noch stärker voran als den Cloud-Boom vor 15 Jahren“, erklärt er. CIOs spüren diesen Druck und müssen so schnell wie möglich handeln, um zusätzliche Rechenkapazitäten für KI-Initiativen bereitzustellen – und das in einem ohnehin schon komplexen Umfeld.“

Gleichzeitig müssten CIOs das Problem der Datenkomplexität lösen, bevor KI-Systeme erfolgreich integriert werden können, betont der Cloud-Experte. „Derzeit drehen sich viele im Kreis und versuchen herauszufinden, welcher Ansatz dafür der Beste ist.“

Hyperscaler galten früher als der einfache Weg, so Linthicum, könnten aber drei- bis viermal so teuer werden. KI-Systeme kosten seiner Einschätzung nach etwa zehnmal so viel wie vergleichbare, traditionelle Anwendungen.

Basu von International Seaways erklärt, dass KI die Diskussion über die IT-Architektur grundlegend verändert habe. „Die Verfügbarkeit von GPUs, Vektordatenbanken, Inferenz mit geringer Latenz und groß angelegte Datenpipelines bringen Anforderungen mit sich, die sich nicht nahtlos in herkömmliche Cloud-Designmodelle einfügen“, merkt er an. Unternehmen verlagern Workloads nicht mehr einfach nur in die Cloud. Sie entwerfen Architekturen für völlig andere Rechen- und Datenanforderungen.“

Laut Zachary Lewis, CIO und CISO der University of Health Sciences and Pharmacy, verstärkten die Bedürfnisse interner Stakeholder diese Komplexität noch. „Geschäftsbereiche wünschen sich unterschiedliche KI-Fähigkeiten, Sicherheitsteams wollen Governance und eine gewisse Kontrolle über KI-Anwendungen, der Justiziar möchte wissen, welche Art von Daten in das KI-Modell eingespeist werden, und das Finanzteam erwartet Kostenvorhersehbarkeit. CIOs müssen all dies unter einen Hut bringen – und das erfolgreich versteht sich“, so Lewis.

Seit der Online-Händler für Musikinstrumente und professionelle Audiotechnik Sweetwater seine Cloud-Strategie um das Jahr 2016 formalisiert hat, versucht Johnson, Workloads dort zu platzieren, wo sie für externe und interne Kunden den größten Nutzen bringen.

„Alles mit Kundenkontakt muss so nah wie möglich am Endnutzer ablaufen“, erklärt er. Die gleiche Logik gilt auch für interne Workloads: Sie gehören in die Nähe derjenigen, die sie nutzen. KI wäre ohne die Cloud nicht möglich. Die für KI erforderliche Rechenkapazität war bereits vorhanden – die Cloud verfügte darüber und konnte sie bereitstellen. In vielerlei Hinsicht ist KI vielleicht das größte Geschenk der Cloud an die Branche. Beide haben sich gegenseitig ermöglicht“, fügt der Manager hinzu.

Cloud-Kostenmanagement wird immer komplexer

Johnsons größtes Problem ist die konsistente Steuerung der Kosten. „Früher war es relativ einfach: Rechenleistung, Speicher, Datenverkehr. Heute ist es ein Puzzle. Reservierte Instanzen, Sparpläne, Spot-Preise, Kosten pro Anfrage, Gebühren für Datenübertragungen zwischen Regionen – das summiert sich schnell. Und es ist wirklich schwer vorherzusagen, wie Ihre Rechnung aussehen wird, bis sie eintrifft.“

Deshalb sei FinOps inzwischen zu einer eigenen Disziplin geworden.

Auch Basu hält FinOps für unverzichtbar. „Kosten für KI-Inferenz, Datenübertragungen und wachsende Speichermengen können monatliche Kostenschwankungen verursachen, die selbst erfahrene Teams überraschen“, führt er aus. Kostenmanagement ist heute eine kontinuierliche operative Disziplin und nicht mehr nur eine gelegentliche Überprüfung.“

Auch die Gefahr des Vendor Lock-in beschäftigt Johnson ständig. „Je tiefer man die nativen Dienste eines Anbieters integriert, desto schwieriger wird ein Wechsel. Das ist nicht zwangsläufig schlecht, aber ein Kompromiss. Ich sehe das wie technische Schulden. Man gewinnt heute Geschwindigkeit und zahlt später Zinsen, wenn man die Richtung ändern möchte.“

Gleichzeitig erkennt Johnson an, dass Cloud-Anbieter Unternehmen sind, die auf Umsatz und Marge achten und regelmäßig die Regeln für Rabatte und Kostenmodelle ändern.

Finanzielle Effizienz entstehe nicht von selbst, betont er: „Das erfordert Teams, Prozesse und echte Investitionen in FinOps. Die Werkzeuge sind vorhanden. Die eigentliche Herausforderung besteht darin, sie richtig einzusetzen.“

In den meisten Unternehmen liege das Finanzwissen in der Buchhaltung und das technische Wissen in der IT, erklärt Johnson. Beide Gruppen beim Cloud-Kostenmanagement zusammenzubringen, sei eine vergleichsweise neue Herausforderung.

„Vor zehn Jahren war das Modell einfach: Man beantragte ein Investitionsbudget, die Buchhaltung genehmigte es, Hardware wurde bestellt und die IT installierte und optimierte alles. Fertig“, sagt Johnson. „Heute ist es eine tägliche Aufgabe. Neue Dienste werden aktiviert, Verträge ändern sich, Preisstrukturen werden angepasst. Die Finanzabteilung versteht die Geldströme, aber nicht die Technik. Die IT versteht die Technik, aber nicht die finanziellen Hebel.“

Jeder große Cloud-Anbieter verfügt über die entsprechenden Tools, erklärt Johnson. „AWS Cost Explorer, Azure Cost Management, die Abrechnungs-Dashboards von Google Cloud. Die Daten sind alle vorhanden. Doch viele Unternehmen nutzen diese Daten nicht. Dann kommt die Rechnung und alle sind überrascht. Die Werkzeuge haben die Entwicklung angekündigt. Man hat nur nicht hingehört.“

Datenregulierung bringt zusätzliche Herausforderungen

Die University of Health Sciences and Pharmacy hat Studierende aus der ganzen Welt. Laut Lewis ist Cloud-Management aufgrund der zunehmenden Datenschutz- und Regulierungsanforderungen weltweit deutlich schwieriger geworden.

„Wir müssen verstehen, in welcher Cloud-Region Metadaten gespeichert werden und wo sie dauerhaft liegen. Wenn diese Daten in ein intern trainiertes Modell einfließen, können wir garantieren, dass sie in der EU bleiben? Und wenn jemand die Löschung seiner Daten verlangt, können wir alle Speicherorte zuverlässig identifizieren?“

Basu ergänzt, dass Datensouveränität zu einer weiteren zentralen Architekturfrage geworden sei.

„Sie beeinflusst, wo Workloads ausgeführt werden dürfen, wie Daten zwischen Regionen bewegt werden und was mit bestimmten Datensätzen geschehen darf. Man kann nicht davon ausgehen, dass die Standardkonfiguration eines Hyperscalers automatisch alle regulatorischen Anforderungen erfüllt.“

Private Cloud, Public Cloud oder On-Premises?

KI hat eine Neubewertung der Platzierung von Workloads ausgelöst. Johnson glaubt jedoch, dass sich die Frage nach Private Cloud, Public Cloud oder On-Premises häufiger verändert, als viele denken.

„Ich denke, die meisten unserer Workloads befinden sich derzeit am richtigen Ort. Aber wir sind nur dorthin gelangt, weil wir bereit waren, Standardannahmen zu hinterfragen.“

Bei Sweetwater gebe es keine Regel, dass neue Workloads automatisch in die Cloud gehören. Ein Workload könne in der Cloud starten und später wieder ins eigene Rechenzentrum zurückkehren, wenn die Wirtschaftlichkeit dies erfordert.

„Die eigentliche Disziplin besteht darin, dies laufend zu überprüfen, Wendepunkte zu erkennen und die Größe der Umgebung kontinuierlich anzupassen. Das richtige Werkzeug zur richtigen Zeit – das ist das einzige Prinzip, das langfristig Bestand hat.“

Basu plant keinen Umstieg auf eine Private Cloud, da die Wirtschaftlichkeit und der betriebliche Aufwand dies für sein Unternehmen nicht rechtfertigen.

„Die richtige Frage lautet: Welches Modell für Datenresidenz, Latenz und Kontrolle ist für jeden Workload angemessen? Das ist eine Frage der Datenklassifizierung, nicht der Cloud-Bereitstellungsstrategie.“

Lewis, dessen Universität rund 95 Prozent ihrer Infrastruktur in der Cloud betreibt, sieht angesichts der Anforderungen von KI und moderner Hardware kaum praktikable Alternativen.

„Wenn man groß angelegte Data Lakes trainieren und fundierte Geschäftsentscheidungen mithilfe von maschinellem Lernen und der dahinterstehenden Intelligenz treffen möchte, ist es fast nicht mehr praktikabel, auf eigene Server zu setzen“, so Lewis.

CIOs müssten sich fragen, ob sie überhaupt über das notwendige Know-how verfügen, um eine solche Infrastruktur selbst zu betreiben. Letztlich müsse man das Beste aus den vorhandenen Möglichkeiten machen.

Fokus auf die Grundlagen

Unternehmen mögen vielleicht dem neuesten Trend hinterherjagen – derzeit ist das die agentische KI –, doch IT-Führungskräfte sollten sich auf ihre Infrastruktur, das Management und die Plattformplanung konzentrieren, betont Linthicum.

„Das ist vielleicht weniger spannend, aber wenn man KI im Unternehmen einsetzen will, muss man diese Probleme zuerst lösen.“

Johnson warnt, dass die Cloud eine Vielzahl architektonischer Muster ermöglicht – und diese Freiheit könne ohne Leitplanken zum Problem werden. „Erstellen Sie das Leitliniendokument, bevor Sie es brauchen – nicht erst, wenn bereits fünf Teams auf fünf verschiedene Arten vorgehen.“

IT-Verantwortliche sollten außerdem frühzeitig für ein sauberes Tagging und Transparenz bei den Kosten sorgen. Das müsse der erste Schritt sein und dürfe nicht erst als Aufräumprojekt betrachtet werden, warnt Johnson: „Wenn Sie Ihre Ausgaben nicht vom ersten Tag an klar nachvollziehen können, sind Sie bereits im Rückstand.“

Ein weiterer wichtiger Schritt sei der Aufbau eines Audit-Programms mit klaren Kontrollen darüber, wer Änderungen an Produktivsystemen vornehmen darf: „Die Auswirkungen einer fehlerhaften Änderung in der Cloud sind größer und treten schneller ein, als die meisten Menschen erwarten – bis sie es selbst erleben.“

Die Frage nach den Kompetenzen

Die Fähigkeiten, die für den Betrieb moderner Cloud-Umgebungen erforderlich sind, entwickeln sich laut Basu schneller weiter, als die meisten internen Teams realistischerweise mithalten können. Deshalb setzt International Seaways auf spezialisierte Managed Service Provider (MSPs), anstatt in jedem Bereich tiefgehendes internes Expertenwissen aufzubauen.

„Dadurch haben wir Zugang zu aktuellen Fähigkeiten, ohne Teams ständig umschulen oder neu aufbauen zu müssen, wenn sich die Technologie ändert. Die Entscheidungen, die uns 2020 geschützt haben, wurden Jahre zuvor getroffen – lange bevor jemand ihre Bedeutung erkannt hatte. Infrastrukturstrategie bedeutet immer, sich auf eine Zukunft vorzubereiten, die noch nicht vollständig sichtbar ist.“

Entscheidend sei, solche Entscheidungen bewusst und auf Basis klarer Überlegungen zu treffen, anstatt später unter Druck reagieren zu müssen.

Anpassungsfähige Organisationen aufbauen

Edge-Computing fügt laut Johnson eine weitere Ebene der Komplexität hinzu. Erfolgreich werden nicht diejenigen sein, die die perfekte Architektur finden. „Es sind diejenigen, die Organisationen aufbauen, die sich schnell anpassen können, wenn sich die richtige Antwort morgen ändert“, erklärt er.

Der eigentliche Wettbewerbsvorteil liege nicht in der gewählten Cloud-Plattform, sondern darin, wie schnell ein Team lernen und handeln kann, so Johnson.

Auf die Frage, wie sich Cloud-Umgebungen weniger kompliziert gestalten lassen, gaben die CIOs folgende Empfehlungen:

Behandeln Sie Ihre Cloud-Architektur wie ein Produkt, nicht wie ein Projekt. Sie benötigt kontinuierliche Verantwortung und Weiterentwicklung, nicht nur eine einmalige Implementierung.
Überprüfen Sie Ihre Entscheidungen regelmäßig. „Die richtige Entscheidung im ersten Jahr ist oft nicht mehr die richtige im dritten. Planen Sie feste Überprüfungspunkte ein“, erklärt Johnson.
Ordnen Sie jeden Workload einer Kostenstelle zu. Basu hat dies umgesetzt; die IT überprüft kontinuierlich Auslastung und Größenanpassungen, anstatt auf periodische Audits zu warten.
Die Datenklassifizierung bestimmt die regionale Platzierung. Bevor ein Workload in Produktion geht, sollten Rechts- und Compliance-Abteilungen von Anfang an eingebunden sein.
Entwickeln Sie Cloud-fähige Lösungen. Das kann günstiger und risikoärmer sein als die unveränderte Migration stark angepasster Altsysteme.
Konsolidierung ist eine strategische Entscheidung, kein Rückzug. Weniger Plattformen, die gut gesteuert werden, schneiden dauerhaft besser ab als eine zersplitterte Multi-Cloud-Landschaft.
Unterschätzen Sie nicht die Governance-Lücke, die durch KI entsteht. Schaffen Sie jetzt eine KI-Governance-Struktur, bevor sich technische und organisatorische Schulden anhäufen.
Cloud-Strategie ist keine reine IT-Architekturentscheidung. Die Pandemie habe gezeigt, dass sie vor allem eine Entscheidung zur Sicherung der Unternehmensresilienz sei. „Die Organisationen, die schwierige Entscheidungen vor einer Krise treffen, sind diejenigen, die unbeschadet daraus hervorgehen.“
Verknüpfen Sie Cloud-Entscheidungen mit messbaren Geschäftsergebnissen. Bellendir von WHSmith berichtet, dass sein Unternehmen stark in Integrationsarchitekturen, Cybersicherheitskontrollen, Observability und Data Governance investiert, um hybride Umgebungen besser zu unterstützen.
Legen Sie größeren Wert auf Cloud-Kostenkontrolle und operative Disziplin. Dadurch wird die Transparenz über die Cloud-Nutzung verbessert und sichergestellt, dass die Skalierung von KI-, Analyse- und Digitalisierungsinitiativen langfristig finanziell tragfähig bleibt.

Auch wenn niemand vorhersagen kann, ob Cloud-Umgebungen künftig weniger komplex werden, werden Unternehmen sie weiterhin nutzen.

„Die Cloud ist nicht mehr die Zukunft der IT – sie ist die Gegenwart. Die Diskussion hat sich von der Frage ‚Sollen wir das tun?‘ hin zu ‚Wie werden wir darin besser?‘ verschoben. Und genau damit verbringe ich heute den Großteil meiner Zeit“, konstatiert Johnson. (mb)

Dieser Artikel basiert auf einem Beitrag von CIO.com

Im Fokus: Cloud Computing

Erfahren Sie in unserem kostenlosen PDF, was IT-Entscheider 2026 in puncto Cloud wissen müssen.

Jetzt herunterladen!

CineVI – shutterstock.com

Why private AI is the smarter bet

Fri, 26 Jun 2026 11:18:38 +0200

For the past several years, the default assumption in enterprise IT was that AI would follow the same path as many other workloads and settle into the public cloud. That assumption seemed reasonable on the surface. The hyperscalers had the infrastructure, GPU capacity, managed services, and developer ecosystems. If you wanted to move fast, public cloud AI looked like the obvious answer.

That logic is now being challenged by reality. As enterprises move from AI experiments to AI in production, they increasingly find that the public cloud is a convenient place to start but not the most practical place to stay. Enterprises are wondering if they can afford to base their long-term AI strategies on cost models they do not control, risks they cannot fully contain, and architectures that are optimized for provider scale rather than enterprise economics.

This is why private cloud AI is becoming more popular. Enterprises are not moving on-premises because it’s a fashionable choice. They are moving because, in many cases, it is the financially rational choice.

The expense of token-based AI

The market still treats token-based AI pricing as a stable, mature economic model. It is not. Much of what enterprises pay today reflects a highly competitive environment in which providers are still subsidizing adoption, offering aggressive discounts, and prioritizing market share over normalized margins. That may be good news in the short term, but it is dangerous to assume those conditions will persist.

As enterprises scale their usage, token consumption shifts from an interesting line item to serious financial exposure. A chatbot pilot is one thing. Enterprisewide inference across business operations, customer engagement, knowledge systems, automation, analytics, and embedded software is something else entirely. When AI becomes part of the daily operating fabric of the business, token charges stop being experimental expenses and become recurring utility bills. At that point, even modest changes in pricing can have major budget consequences.

Many tech leaders are now rethinking their assumptions about AI costs, realizing that current pricing may not reflect long-term expenses. As subsidies fade and usage increases, token costs are likely to rise sharply, potentially making large-scale public AI deployments less economically viable. That is the trap enterprises want to avoid. No CIO wants to explain that the company successfully operationalized AI only to discover that a growing bill from a public provider offsets every business gain. Enterprises have seen this before with cloud cost overruns, and they do not want to repeat it with AI.

Hybrid AI is the natural end state

It is becoming clear that the future of enterprise AI is neither all public cloud nor all on-premises. It is a hybrid. The market is maturing beyond ideology and moving toward workload placement based on economics, governance, latency, and control.

That shift matters because not every AI problem requires a giant hosted model. In fact, many enterprise use cases do not. A growing number of organizations are finding that smaller, domain-specific models can perform as well as, and often better than, larger ones for targeted business tasks. Some use tuned models. Some rely on classic machine learning and predictive systems. Some combine retrieval techniques with smaller language models. Others build tightly constrained models tailored to specific operational domains.

These systems are often better suited to private infrastructure. They run closer to enterprise data, can be optimized for predictable workloads, and avoid the open-ended cost profile of external tokenized services. This is especially true when the model is used repeatedly within internal business processes rather than occasionally by a limited set of users. In other words, enterprises are not just choosing private AI because they dislike public cloud pricing. They are choosing it because they are learning to build AI systems that meet enterprise requirements rather than defaulting to whatever is easiest to consume from the outside.

Security and governance

Cost may be the loudest concern, but it is not the only one. Security and governance are becoming equally powerful drivers. Enterprises are increasingly uncomfortable with the idea of sensitive information flowing through public AI tools, public APIs, and user workflows that are difficult to monitor and control. The concern is not abstract. Employees routinely paste confidential information into public AI interfaces to boost productivity. Development teams sometimes move faster than policy can keep pace. Business units adopt tools before governance can catch up. The result is a growing risk of data leakage, unauthorized exposure, compliance failures, and security incidents directly tied to the use of AI.

This changes the conversation. Once AI touches customer records, financial models, regulated data, or other proprietary information, the focus shifts from deployment speed to the risk you introduce to the core of the business. While public clouds can provide strong security, many enterprises prefer tighter internal controls for sensitive AI workloads to ensure better observability, access, data locality, and policy enforcement.

There’s no question that private AI reduces the number of unknowns. It gives enterprises more direct control over where data resides, how models are used, who can access them, and how systems are audited. That does not eliminate risk, but it makes risk easier to manage.

Private AI is harder but worth it

Private AI is not effortless. Building AI on premises or in a private cloud requires investment, planning, specialized skills, operational discipline, and a willingness to own more of the stack. Enterprises must think about infrastructure design, GPU utilization, life-cycle management, model operations, integration, and resilience in ways that public services often abstract away.

That extra work introduces real risk. Some organizations will underestimate the operational burden, some will overspend on infrastructure, and some will struggle to attract the right talent. Even with those challenges, many enterprises are concluding that the cost savings are too compelling to ignore.

Enterprises are not moving toward private AI because it is easier. They are moving because it’s smarter in the long term. They would rather take on more responsibility now than remain exposed to a pricing model that could become unsustainable later. They would rather invest in owned capability than rent critical intelligence from an outside platform with uncertain future economics.

The public cloud will remain important, especially for experimentation, bursting, and select services. But for many production workloads, the balance is shifting. As token costs rise, governance pressures intensify, and organizations become better at building focused models rather than defaulting to giant LLMs, more enterprises will conclude that their most valuable AI belongs closer to home.

Vom Monitoring zur Entscheidungsplattform: Was Observability heute leisten muss

Fri, 26 Jun 2026 05:35:59 +0200

Wenn autonome KI-Agenten selbstständig Entscheidungen treffen, versagt das klassische IT-Monitoring. Nur moderne Observability sichert künftig die Kontrolle über unvorhersehbare Betriebsrisiken.

Tags: #Monitoring | #Observability

OpenAI's updated GPT-5.5 Instant is better at shopping, complex constraints, and understanding user intent — and it's already in the API

Thu, 25 Jun 2026 19:18:02 +0200

OpenAI has made a significant update to its most widely used language model, GPT-5.5 Instant, which is the default in the free version of ChatGPT.

The company announced the upgraded version of GPT-5.5 Instant yesterday on X, calling it "much more fun to talk to" and saying it is "better at understanding the intent behind a question and adapting its response accordingly," as well as offering improvements in shopping results, local recommendations, and handling "complex constraints."

However, it has not yet provided any benchmarks or numerical results to quantify these claims.

The company said the updated GPT-5.5 Instant was rolling out first to paid ChatGPT subscribers and then to free users as of today, June 25.

OpenAI also updated its chat-latest API alias, which points to the latest GPT-5.5 Instant model currently used in ChatGPT, while continuing to recommend the separate gpt-5.5 model for production API usage.

That distinction matters, but it should not obscure the main news: this is primarily a ChatGPT-side update to GPT-5.5 Instant, not a new release of the broader GPT-5.5 API model family.

Let's dig into what's changed...

Origins of GPT-5.5 Instant, and why OpenAI updated it less than two months later

GPT-5.5 Instant was first unveiled in early May 2026, just under two months ago, to replace the aging GPT-5.3 Instant engine as the baseline default model for ChatGPT users.

Developed as a fast, high-throughput variant of OpenAI’s core flagship model family, the initial spring release focused heavily on correcting systemic factuality deficits.

Internal benchmarks from that spring deployment reported a 52.5% reduction in hallucinated claims compared to GPT-5.3 Instant on high-stakes medical, legal, and financial prompts, alongside a 37.3% drop in factual error rates on user-flagged historical conversations.

Independent evaluators noted that its predecessor, GPT-5.3 Instant, had struggled in public rankings, placing 44th overall in Arena benchmarks. That gave the May rollout a clear purpose: OpenAI needed a stronger default model for everyday ChatGPT interactions, not just a more capable frontier model for advanced users.

Stylistically, the initial spring model introduced a sharper conversational baseline, demonstrating a 30.2% reduction in word count and a 29.2% drop in line usage over typical advice prompts.

However, the spring deployment also introduced an operational fault line for enterprise software systems: a feature known as "memory sources." Designed to grant users visibility into the specific past chats, files, and connected Gmail accounts shaping a personalized answer, memory sources introduced a loose, model-reported observability layer.

As reported by VentureBeat, these internal summaries frequently clashed with the deterministic logs of localized vector databases and enterprise Retrieval-Augmented Generation (RAG) pipelines.

The resulting friction created dual, competing context records, making it difficult for administrators to reconcile what the model claimed it referenced against what it actually accessed in production.

The June 24 update does not appear to expand memory sources directly. Instead, it focuses on making GPT-5.5 Instant better at understanding user intent, carrying context across turns, following multi-part instructions, and producing more useful shopping and local recommendations.

A smarter, more 'fun' ChatGPT for consumers

For everyday users of ChatGPT, the most noticeable change in GPT-5.5 Instant will be the model’s improved intent recognition.

According to OpenAI’s latest release notes, GPT-5.5 Instant has improved at identifying the underlying goal behind a user's question, particularly in decision-support scenarios like planning, shopping, asking for advice, researching options and comparing local choices.

Historically, large language models have struggled when given prompts with multiple overlapping constraints — often dropping one or two requirements in favor of a generalized response.

The updated GPT-5.5 Instant handles these complex instructions more reliably. When users push back on an answer, clarify their meaning, or introduce new constraints mid-conversation, the model should adapt dynamically rather than stubbornly repeating its original approach.

This contextual awareness extends heavily into commerce and local recommendations. GPT-5.5 Instant now makes better use of location context to surface nearby options, weaving together product recommendations, business information, and relevant images into a more cohesive output when those elements are useful.

Furthermore, OpenAI notes that the stylistic formatting of these responses is less rigidly templated, trading robotic lists for a more intentionally designed, warmer and restrained conversational tone.

Developers can test the latest Instant behavior through `chat-latest`

For the developer ecosystem, the June 24 GPT-5.5 Instant update is accessible through OpenAI’s updated chat-latest API alias.

chat-latest is not the same thing as the production gpt-5.5 model slug. OpenAI says chat-latest points to the latest Instant model currently used in ChatGPT, and it recommends the separate gpt-5.5 model for production API usage. Developers can use chat-latest to test the newest ChatGPT-style improvements, while using gpt-5.5 when they need a stable production target.

The current chat-latest model page lists a 400,000-token context window and support for up to 128,000 maximum output tokens. Its knowledge cutoff is Aug. 31, 2025.

On pricing, chat-latest uses the same $5.00 per 1 million input tokens and $30.00 per 1 million output tokens listed on its model page. Cached inputs cost $0.50 per 1 million tokens, a 90% discount that strongly incentivizes developers to optimize prompts by placing static instructions first and dynamic data later.

The model supports text and image input, text output, streaming, function calling and structured outputs. Through the Responses API, the chat-latest page also lists support for web search, file search, image generation, code interpreter and MCP.

The practical takeaway is simple: chat-latest gives developers access to the updated Instant-style behavior, but OpenAI is still steering production API builders toward the separate gpt-5.5 model. The broader GPT-5.5 API model includes a larger feature set and different production profile, but that is not the main focus of this update.

Why this matters for enterprise AI teams

For enterprises, the June 24 GPT-5.5 Instant update lands at the intersection of two related but distinct trends: better default user experience in ChatGPT, and more reliable orchestration behavior in the API.

The consumer-facing changes make ChatGPT more useful for everyday decision-making. Users should see better handling of messy, real-world requests: planning a trip with several constraints, comparing products, finding nearby businesses, or adjusting a recommendation after adding a new requirement.

The enterprise relevance is less about a new technical architecture and more about default behavior. A model that better infers intent, preserves context across turns and follows multi-part constraints can make ChatGPT more reliable for employees using it for research, planning, purchasing decisions, customer-facing drafts and internal analysis.

But enterprises should remain careful about observability. Memory sources can help users understand why ChatGPT personalized an answer, but they do not provide a complete audit trail. Organizations that already rely on RAG pipelines, vector databases, orchestration logs and internal agent traces should define which record acts as the source of truth when a model’s visible memory sources do not fully match the system’s own logs.

What’s next?

The release of GPT-5.5 Instant and the updated chat-latest alias signals a maturation in how generative models are deployed.

OpenAI is moving away from models that require heavy hand-holding and toward systems that can better infer the user’s goal, preserve constraints and adapt across multiple turns.

Whether it is a consumer planning a complex multi-city vacation in ChatGPT, or a developer orchestrating a codebase-navigating agent through the API, GPT-5.5 represents a faster, smarter and more capable baseline for the future of AI workflows.

The most important takeaway for developers is also the simplest: GPT-5.5 Instant, chat-latest and gpt-5.5 are related, but they are not the same product surface. GPT-5.5 Instant is the ChatGPT model users experience directly. chat-latest is a moving alias for testing the latest Instant behavior through the API. gpt-5.5 is the production model OpenAI recommends for developers building stable applications.

Tap to verify: No SMS, no Friction with Firebase Phone Number Verification

Thu, 25 Jun 2026 17:06:38 +0200

Author: Firebase - Bewertung: 0x - Views:15

Add Firebase Phone Number Verification to your Android app (Codelab) → https://goo.gle/3SbV0Mm
Firebase Phone Number Verification documentation → https://goo.gle/4dTlgCv
Get started with Firebase Phone Number Verification on Android→ https://goo.gle/49tCFR4

Are you still relying on SMS OTPs to verify user phone numbers? Nohe explains how to use Firebase Phone Number Verification (PNV) to securely verify user numbers directly through mobile carriers with a single tap. Learn how to prevent SMS pumping fraud, bypass slow carrier delivery times, and build a frictionless Kotlin Android onboarding flow.

More resources:
Verify tokens on your backend → https://goo.gle/49Bhn3Y
Phone Number Verification production mode → https://goo.gle/4uKIrpW
Firebase Phone Number Verification observability → https://goo.gle/4vGkPmz

Chapters:
0:00 - Introduction
0:50 - What is Firebase Phone Number Verification (PNV)?
1:44 - Demo set up: Testing
2:33 - Kotlin implementation and Credential Manager
3:15 - Monitoring metrics and observability

#Firebase #AppSecurity

Watch more Firebase Fundamentals → https://goo.gle/Firebase-Fundamentals
Subscribe to Firebase → https://goo.gle/Firebase

Speaker: Alexander Nohe
Products Mentioned: Firebase, Firebase Phone Number Verification

BlackLine enhances Agentic Financial Operations Platform with CFO-focused AI oversight tools

Thu, 25 Jun 2026 14:39:09 +0200

The post BlackLine enhances Agentic Financial Operations Platform with CFO-focused AI oversight tools appeared first on IT Security News.

BlackLine enhances Agentic Financial Operations Platform with CFO-focused AI oversight tools

Thu, 25 Jun 2026 14:23:51 +0200

BlackLine has announced new governance and observability capabilities within its Agentic Financial Operations Platform, further advancing the trust infrastructure finance organizations need to deploy, govern, and scale AI across the Office of the CFO. As finance teams transition from deploying a handful of AI agents to managing potentially hundreds of thousands across BlackLine, partner, customer-developed, and third-party applications, the challenge shifts from automation to governance and control. The Finance Control Console provides a centralized layer … More →

The post BlackLine enhances Agentic Financial Operations Platform with CFO-focused AI oversight tools appeared first on Help Net Security.

New Linux Foundation project aims to bring DNS-style trust to AI agents

Thu, 25 Jun 2026 13:33:51 +0200

As enterprises deploy increasing numbers of AI agents across applications and organizations, the Linux Foundation on Wednesday announced plans to launch a new Agent Name Service framework designed to establish identity, ownership, and trust for these systems.

The ANS framework, which is expected to allow systems and users to verify who an agent represents, what permissions it has, and whether its code and operational history remain authentic and unchanged, will be based on the existing Domain Name System (DNS), the Foundation said in a statement.

Just like DNS translates human-readable website names into internet addresses, ANS aims to create a standardized naming and discovery layer for AI agents, with the ability for enterprises to publish agent identities through domains they already control, enabling other agents and systems to verify who an agent represents and discover information about its capabilities and ownership before interacting with it, it added.

This, the Foundation further added, creates a federated mechanism for agent discovery and verification without any reliance on any proprietary registry or centralized control.

Growing demand for an agent identity framework

ANS solves an emerging problem for enterprises, especially in scaling AI deployments, said Charlie Dai, principal analyst at Forrester, too. “The agent identity problem is already emerging in early production deployments, particularly where multiple agents interact across tools, APIs, and organizational boundaries without consistent authentication and accountability models,” he said.

“We have seen growing concerns around provenance, authorization scoping, and auditability in agent-to-agent interactions, especially in regulated industries and multi-vendor environments,” Dai said.

Agent identity has become a more critical concern for enterprises, pointed out Jaishiv Prakash, director analyst at Gartner: “Agent identity has moved from an architectural consideration to an operational control-plane gap.”

“The evidence we see from enterprise clients is consistent: they need to know which agent acted, who it represented, what authority it had, and whether its runtime behavior matched its intended design,” Prakash said.

Beyond the problem ANS seeks to solve, analysts also said the framework’s architecture could prove equally important for enterprise adoption.

“For enterprises, one of ANS’s biggest advantages may be its reliance on DNS, especially since they already use it to manage domains and trust. It avoids creating a new registry and lets companies publish and verify agent identities using existing internet infrastructure, making adoption easier and cheaper,” said Pareekh Jain, principal analyst at Pareekh Consulting.

More so because enterprises don’t have to build anything new, according to Amit Jena, AI development manager at IT consulting firm Kanerika.

However, there are downsides to being built on DNS, especially on the security front, Dai cautioned.

“DNS was not originally designed for high-assurance identity. This will make it susceptible to spoofing, hijacking, and latency or propagation inconsistencies that can undermine trust guarantees,” Dai said.

To bypass these security concerns, enterprises should complement ANS with IAM, workload identity, AI gateways, and API security controls, according to Prakash.

The Foundation, though, argues that DNS alone is not intended to serve as the sole trust mechanism inside ANS and the framework supports Decentralized Identifiers (DIDs) and Legal Entity Identifiers (LEIs), allowing enterprises to tie agents to existing digital and organizational identity systems as part of the broader identity verification model.

Battle of the standards

Even so, ANS is entering an increasingly crowded ecosystem of standards and frameworks that enable and govern enterprise AI agents.

While protocols such as MCP and A2A focus on connecting agents to tools and facilitating communication between each other, the Foundation itself hosts two standards that touch on agent identity, discovery, and trust.

One of them is DNS-AI Discovery (DNS-AID), a proposed framework that uses DNS records to help agents advertise their capabilities and make themselves discoverable across networks. Another is AGNTCY, a Cisco-led project that aims to provide a broader infrastructure stack for multi-agent systems, including capabilities for agent discovery, identity, messaging, and observability.

That raises the possibility of fragmentation if competing approaches evolve in parallel.

However, Prakash pointed out that the presence of multiple similar frameworks that touch on agent trust, identity, and discovery shows that the agent infrastructure market has entered its standards discovery phase, not its standards consolidation phase.

“Overlap in discovery, identity, messaging, and observability is expected at this stage,” Prakash said.

Enterprises, thus, the analyst added, should wait for “clarity and clearer interoperability guidance” before they treat any one initiative as strategic infrastructure.

New Linux Foundation project aims to bring DNS-style trust to AI agents

Thu, 25 Jun 2026 13:32:56 +0200

This, the Foundation further added, creates a federated mechanism for agent discovery and verification without any reliance on any proprietary registry or centralized control.

Growing demand for an agent identity framework

Beyond the problem ANS seeks to solve, analysts also said the framework’s architecture could prove equally important for enterprise adoption.

More so because enterprises don’t have to build anything new, according to Amit Jena, AI development manager at IT consulting firm Kanerika.

However, there are downsides to being built on DNS, especially on the security front, Dai cautioned.

To bypass these security concerns, enterprises should complement ANS with IAM, workload identity, AI gateways, and API security controls, according to Prakash.

Battle of the standards

Even so, ANS is entering an increasingly crowded ecosystem of standards and frameworks that enable and govern enterprise AI agents.

That raises the possibility of fragmentation if competing approaches evolve in parallel.

“Overlap in discovery, identity, messaging, and observability is expected at this stage,” Prakash said.

Enterprises, thus, the analyst added, should wait for “clarity and clearer interoperability guidance” before they treat any one initiative as strategic infrastructure.

The article originally appeared on InfoWorld.

Building a state-of-the-art development platform with Backstage

Thu, 25 Jun 2026 11:34:09 +0200

Key takeaways

Backstage solved the portal problem, not the platform problem. A portal organizes catalogs, documentation, and templates. A platform owns deployments, environments, policies, and runtime operations. Backstage assumes that the execution layer exists beneath it.
Point-to-point integrations become a maintenance burden. Many organizations end up with a “messy middle” where Backstage is connected directly to CI/CD, GitOps, Kubernetes, and observability tools through custom wiring that’s fragile and hard to evolve.
Abstractions are the interface between developers and infrastructure. Developers work with components, endpoints, and dependencies. Platform engineers work with environments, pipelines, and component types. The platform compiles both into Kubernetes resources.
A control plane bridges the gap. It sits between the portal and runtime, compiling abstractions into infrastructure, enforcing policies consistently, reconciling drift, and aggregating runtime state back to the portal.
Good abstractions enable advanced capabilities. Unified observability, automated guardrails, and AI agents that can reason about and act on your platform. All becomes possible when you have well-defined concepts and a control plane that understands both sides.

…

Start with Backstage

If you’re building an internal developer platform, Backstage is certainly part of your architecture. It solved the discovery problem and became the default choice for developer portals.

Before Backstage, developers navigated wikis, spreadsheets, and tribal knowledge just to find who owned a service or how to spin up a new one. Backstage brought structure: a unified catalog, a plugin ecosystem, and golden-path templates that actually got adopted.

Backstage is a Cloud Native Computing Foundation (CNCF) project with one of the most active contributor communities in the ecosystem. When organizations evaluate developer portals, Backstage is the starting point.

However, many teams discover something after deployment: Backstage provides a portal, not a platform. A portal organizes information. A platform owns execution: deployments, environments, policies, observability, and runtime operations.

Backstage assumes that the execution layer exists beneath it. That layer is where most of the complexity lives, and it’s what this article is about.

What a developer platform actually is

A developer platform or an internal developer platform is a self-service framework you build to help developers build, deploy, and manage applications independently.

WSO2

Most organizations already have an organically grown version of this:

Developer commits code
CI pipeline builds and pushes images to a registry
Pipeline updates a GitOps repo containing Helm charts or Kubernetes manifests
Argo CD or Flux syncs those manifests to clusters

You may have this workflow running today. The question is whether it’s a pipeline stitched together with scripts and tribal knowledge, or a platform with consistent abstractions and self-service capabilities.

What usually happens after adopting Backstage

How do you add Backstage to this setup? The common approach is for developers to maintain Backstage entity files (primarily component and API entities) alongside the source code. Then you configure the built-in entity provider in Backstage to scan source code repositories to populate the catalog. Eventually, you’ll end up with a portal with all your systems, components, APIs, and other resources. So far, so good.

Once developers start using the portal, you’ll be hit with a consistent flow of feature requests:

“I see my component in the catalog, but is it actually running?” You configure the Kubernetes plugin and link components to their corresponding manifests. Now developers can see pod status, deployment state, and replica counts.
“I need logs, metrics, and traces related to my component.” You integrate your observability stack or developers context-switch to Grafana, Datadog, or whatever you’re running. Either way, more wiring.
“Can I create new components from here?” You build Backstage templates that scaffold repos with the right structure, Backstage entities, Helm charts, and CI pipelines, all of which encode your organization’s best practices. Now you’re maintaining golden paths in templates, separately from the runtime configuration that actually enforces them.

Each request is reasonable and achievable, but they add up.

The messy middle

Eventually, you end up with a platform held together by point-to-point connections. Every new capability requires new wiring. Every upgrade risks breaking something. You spend more time maintaining integrations than building features.

WSO2

You would never design a production system with this many point-to-point dependencies. Why accept it for your platform?

Treat the platform as a product, but also as a system

Organically grown systems get you started, but once you commit to Backstage as your portal, you need a product mindset. Start from developer experience, understand their pain points, then design a system that addresses them coherently.

A platform is also a system. Approach it the way you would approach any production system you’re building. You wouldn’t design a back-end service without thinking about separation of concerns, clear interfaces, and extensibility.

The same principles apply here:

Separation of concerns: Don’t mix developer-facing abstractions with infrastructure implementation. Keep them separate so you can evolve each independently.
Clear interfaces: Define explicit abstractions. Developers and platform engineers should interact with well-defined concepts rather than implementation details scattered across Helm charts and CI scripts.
Extensibility: Requirements keep changing. If every new capability requires custom wiring, you’ll spend more time maintaining than improving. Design for extension from the start.

The difference between a pile of integrations and a platform is architecture. Get the system design right, and new capabilities slot in cleanly. Get it wrong, and every feature request becomes a maintenance burden.

The missing layer beneath Backstage

Moving from an organically grown pipeline to an actionable developer platform is a big leap. You probably have CI/CD pipelines that work, a Kubernetes cluster running workloads, and a Backstage catalog describing what exists.

The questions are:

How do you transform an informational portal into one with a platform under the hood?
How do you bridge the gap between what the catalog describes and what’s actually running?
How do you enforce golden paths beyond initial scaffolding?
How do you design a platform that evolves with your organization’s needs?

What’s missing is a connective layer between Backstage and your runtime, something that makes the portal operational rather than just informational. Let’s look at the key architectural elements to consider when designing that layer and the whole platform.

Start with abstractions

One of the main goals of a developer platform is to reduce cognitive load. The platform should meet developers where they are and speak their language, not Kubernetes’.

Every organization has its own vocabulary, but the Backstage system model is a good starting point. It may not cover everything, but you can extend it with custom entities. The key is that developers work with high-level concepts while the platform compiles them into Kubernetes resources. Developers are abstracted away from the underlying details, but they can still see what’s happening underneath.

Concept	Description	Backstage mapping
Project	A cloud-native application composed of multiple components. It is also a unit of isolation.	System
Component	A deployable unit, such as web services, APIs, workers, or scheduled tasks.	Component
Endpoint	A network-accessible interface exposed by a component.	API
Resource	External infrastructure such as databases, queues, and caches.	Resource
Dependency	A component’s reliance on endpoints or resources.	consumesAPI, dependsOn

These are not just static abstractions; they also have associated runtime semantics. The following diagram illustrates runtime representations of these concepts.

WSO2

In the workload cluster, a project becomes an isolation boundary for all of its components. The platform translates this into Kubernetes namespaces and network policies that enforce the boundary, not just document it.

Endpoint visibility determines which endpoints can talk to which. A project-scoped endpoint gets network policies that block traffic from outside the project. An organization-scoped endpoint is exposed to internal traffic but remains behind the internal gateway. An external endpoint gets routed through the public gateway with appropriate authentication. Developers declare visibility; the platform generates the policies.

Dependencies work the same way. When a component declares a dependency on an endpoint, the platform injects the URL and other environment variables required to connect to the dependency. It configures the network policies for both directions, egress from the calling endpoint and ingress to the target endpoint. Without the declared dependency, egress is blocked by default. The dependency graph you see above reflects actual permitted traffic flow, not just intended relationships.

You need platform abstractions, too

Developer abstractions help your developers. Platform abstractions help you.

While developers work with components, endpoints, and dependencies, you need a different vocabulary to design and operate the platform itself. These abstractions let you and your team define standards, enforce policies, and create structure without writing low-level configurations for every scenario.

Concept	Description
Namespace	A logical grouping of users and resources, typically aligned to a company, business unit, or team. Defines ownership and access boundaries.
Data plane	A Kubernetes cluster that hosts one or more deployment environments. You can have multiple data planes for isolation, regional distribution, or scaling.
Environment	A runtime context, such as dev, test, staging, or prod, where workloads are deployed and executed. Environments carry their own policies and resource configurations.
Pipeline	A defined process that governs how work, such as builds, deployments, promotions, or any automated workflows, flows through the platform. Encodes your operational processes as a platform primitive.
Component type	Defines a category of workload—Service, Worker, Cron, Job.
Trait	A reusable capability that attaches to any component, such as autoscaling, resilience, observability, and security policies. Compose behaviors without duplicating configuration.

These abstractions separate platform concerns from application concerns. Developers don’t need to know which cluster their code runs on or how environments are wired together. They deploy to “staging” or “prod,” and you define what those terms mean.

The missing layer is a control plane

The control plane is where abstractions become real. It sits between the portal and your workload clusters, translating developer intent into infrastructure configuration.

You can think of it as a compiler that targets Kubernetes clusters, converting higher-level abstractions into what Kubernetes and its underlying frameworks understand. It can also apply platform-wide rules during this compilation. Resource limits, security requirements, etc., can be enforced consistently, not merely documented and hoped for.

But compilation is only half the job. The control plane also reconciles continuously. It monitors drift between the declared and actual states. When they diverge, it corrects. Your abstractions remain the source of truth; the control plane enforces them over time.

Programmability is not optional

One of the key aspects of this control plane is programmability. If you want your platform to evolve, the control plane needs to be extensible. Different teams have different requirements. New capabilities emerge. You can’t anticipate everything up front.

This means allowing customization of how abstractions compile to Kubernetes manifests. But extensibility without guardrails is dangerous. You need programmability that preserves your invariants. The goal is constrained flexibility, open enough to evolve, structured enough to stay coherent.

Observable abstractions make the portal useful

The control plane also aggregates runtime state and associates it with your abstractions. This is what makes the portal useful. Without this, developers piece together information from different tools: Kubernetes dashboard for pod status, Argo CD for the deployment state, Grafana for metrics, Jaeger for traces. Each tool knows part of the story; none shows the full picture.

With the control plane aggregating state, the portal tells a connected story. When a developer opens a component page in Backstage, they see:

Deployed environments and their status
Current replicas and resource usage
Recent deployments and who triggered them
Logs, metrics, and traces that are scoped to that component, in each environment
Dependencies and their health

No context-switching. No reconstructing which pod belongs to which service in which cluster. The abstraction is the anchor; everything else attaches to it.

This only works because the control plane understands both sides. It compiled the abstractions to Kubernetes, so it knows how to map runtime data back. Information flows in both directions. Downward: developer intent flows through the control plane and becomes running workloads. Upward: runtime state flows back through the control plane and appears in the portal.

This is what makes the portal actionable. It’s not just displaying information; it’s connected to a system that can act.

Data plane: keep it simple

The data plane is where your workloads actually run. In most cases, this means one or more Kubernetes clusters. The data plane doesn’t know about your abstractions. It understands Kubernetes primitives such as pods, deployments, services, and ingresses. The control plane’s job is to compile your higher-level concepts into these primitives and apply them.

The data plane does one thing: it runs what the control plane tells it to run. The intelligence lives in the control plane; the execution happens in the data plane.

Where AI fits into the platform

AI is now part of every platform conversation, but the architectural question is where it actually belongs.

The abstractions and control plane you’ve built create the foundation. You have well-defined concepts such as components, endpoints, and dependencies. You have a runtime state aggregated and tied to those concepts. You have a connected view of your system. AI agents can definitely leverage this.

Agents as platform users

AI agents should be able to interact with your platform as first-class participants. This requires exposing platform capabilities through interfaces that agents can use, such as Model Context Protocol (MCP) servers, APIs with clear semantics, user-friendly CLIs, and skills that map to platform operations.

These capabilities of the platform enable agents to create components, trigger builds and deployments, query environment status, and reason about dependencies. They help you and your developers become more productive.

Agents as platform capabilities

You can also embed agents inside your platform to help your teams’ day-to-day operations. Here are some examples of agents you can develop:

SRE agents: Analyze logs, metrics, and traces to surface likely root causes. Instead of developers digging through dashboards, the agent correlates signals and suggests where to look.
FinOps agents: Help teams understand and optimize resource costs across environments and components.
Architect agents: Assist with system design decisions, such as dependency analysis, capacity planning, and migration impact assessment.

These agents work because they have access to the control plane’s unified view. They see abstractions, runtime state, and observability data in one place, the same connected story developers see in the portal.

The pattern holds. Good abstractions make everything easier, including AI.

OpenChoreo as a reference implementation

OpenChoreo is an open-source developer platform for Kubernetes. It was recently accepted into the CNCF as a sandbox project. OpenChoreo implements the architecture described in this article: developer abstractions backed by a control plane, a Backstage-powered portal, integrated CI/CD and GitOps, and observability wired to your abstractions.

If you’re building this architecture yourself, OpenChoreo is worth studying as a reference, even if you don’t adopt it directly. The project demonstrates how these pieces fit together: how abstractions compile into Kubernetes resources, how runtime state flows back to the portal, and how guardrails are enforced during compilation.

You can use OpenChoreo as a complete platform, or install its Backstage plugins into your existing portal and use just the control plane layer. Either way, the underlying patterns are what matter. The architecture is the idea. OpenChoreo is one way to implement it.

WSO2

A useful mental model: multi-plane architecture

OpenChoreo separates concerns across five planes:

Experience plane: Where developers, platform engineers, and SREs interact with the platform via the Backstage-powered portal, CLI, GitOps, or AI agents.
Control plane: The brain that translates high-level abstractions (components, APIs, environments, pipelines) into Kubernetes manifests. Programmable through component types and traits, so you can extend it without forking or writing low-level controllers. Continuously reconciles the runtime state back into those abstractions.
Data plane: Where workloads run. Enforces the semantics of your abstractions, such as project isolation, traffic policies, and security boundaries. These aren’t just configurations; the platform guarantees them.
Observability plane: Feeds metrics, logs, and traces back through the same abstractions developers already understand, requiring no translation.
Workflow plane (optional): Handles builds using Cloud Native Buildpacks and Argo Workflows by default.

These planes work together but remain separate concerns. You can reason about each independently, evolve them at different rates, and deploy them flexibly: a single cluster with namespace isolation for dev/test, fully separated multi-cluster setups for production, or hybrid topologies that colocate planes like Control and CI for cost efficiency.

AI and OpenChoreo

OpenChoreo is being built to treat AI agents as first-class participants. In OpenChoreo 1.0, external agents can interact with the platform via MCP servers, agent skills, or the CLI to generate and edit component configurations, reason about releases and environments, and more. The built-in SRE Agent is a first example of this. It analyzes logs, metrics, and traces from your deployments and uses LLMs to surface likely root causes and actionable insights.

WSO2

From portal to platform

Backstage solved the portal problem. It gave you a unified interface for catalogs, documentation, and golden paths. But a portal isn’t a platform. There’s a gap between what developers see and what’s actually running, and that’s where you get stuck. You fill it with point-to-point integrations, custom plugins, and scripts that become their own maintenance burden.

The pattern that works is portal, control plane, data plane:

A portal that gives developers ready access to catalogs, documentation, and templates.
A control plane that compiles platform abstractions, reconciles drift, and aggregates runtime state.
A data plane that runs workloads and enforces guarantees.

Whether you build this yourself or you adopt something like OpenChoreo, the architecture matters more than the tools. Get the layers right, and new capabilities slot in cleanly. Get them wrong, and every feature request becomes a project.

Backstage gives you the front door. The real platform begins behind it.

—

When flat-fee support stops working: How UK MSPs can turn observability into margin

Thu, 25 Jun 2026 09:08:33 +0200

XXX

Xiaomi's HarnessX rewrites its own AI scaffolding mid-task — and smaller models gain the most

Wed, 24 Jun 2026 21:18:03 +0200

As enterprise AI agents take on increasingly complex, long-horizon tasks, their performance is often restricted by their harness, the software scaffolding that connects the backbone LLM to its environment.

Currently, harnesses are largely static and hand-crafted. Improving them is largely manual and they do not automatically improve based on the execution data they collect from their environment.

To address this engineering bottleneck, researchers at Xiaomi introduced HarnessX, a framework that treats the AI harness as a composable object and autonomously applies improvements to its code.

In real-world enterprise applications, this automated adaptation enables AI systems to dynamically adjust to application-specific requirements. Practical tests showed HarnessX delivering substantial performance gains across domains like software engineering and web interaction.

The results demonstrate that scaling the foundation model is not the only path to more capable AI — and for smaller models, it may not even be the best one. HarnessX's harness evolution yielded an average +14.5% performance gain across 15 model-benchmark combinations; for the open-weight Qwen3.5-9B, gains reached +44% on embodied planning tasks.

The challenges of harness engineering

In AI applications, a foundation model's capability relies heavily on its surrounding harness. The harness acts as the operational layer that converts raw model outputs into structured, executable agent behaviors. It comprises the prompts, external tool integrations, memory management, and control flows that dictate how an AI system observes its environment, reasons through a problem, and takes action.

As enterprise agents take on more complex, long-horizon workflows, harness engineering has become a fundamental part of AI development. Despite its importance, harness development remains far from a mature engineering discipline and presents three key challenges.

First, harnesses are static and hand-engineered. Any shift in the underlying foundation model, the introduction of new tools, or a pivot to a different operational domain requires bespoke, manual code rewrites. Traditional harnesses lack mechanisms to autonomously learn and improve from past execution experiences.

Second, most existing harnesses suffer from architectural entanglement. They tightly couple prompt templates, tool wrappers, retry policies, and memory management within the same code paths. This entanglement means that tweaking one component can silently break others. Attempting to reuse a harness across different business domains often devolves into raw code copying rather than clean, modular composition.

Third, the harness and foundation model are optimized in isolation. When engineers run tests to improve the harness, the execution traces generated are typically discarded rather than used as training data to improve the model. Consequently, model upgrades do not naturally lead to harness improvements, creating a bottleneck where teams fail to capture the full value of their agent's operational data.

HarnessX: an autonomous foundry for AI agents

HarnessX solves the engineering bottlenecks of manual harness development with what the researchers call a “unified harness foundry.”

The core innovation of HarnessX is treating the harness as a "first-class object". In software engineering terms, this means the harness is an independently serializable, modular, and substitutable entity. By separating the model configuration (i.e., which AI model is operating) from the harness configuration, engineers can seamlessly swap, adapt, and evolve the scaffolding without touching the underlying model.

HarnessX breaks agent behavior down into different components, such as context assembly, memory management, tool ecosystems, control flow, and observability. Every specific behavior is implemented as a "processor" that plugs into precise lifecycle hooks of the harness. This modular structure allows the system to swap, add, or remove these processors without breaking the surrounding pipeline.

To automate the optimization of this modular structure, HarnessX introduces AEGIS, a trace-driven evolution engine. AEGIS frames harness adaptation as a reinforcement learning (RL) problem over the different symbolic components of the harness.

Framing harness optimization as a reinforcement learning problem introduces three pathologies the researchers had to explicitly engineer against:

Reward hacking: The system might exploit shortcuts to the solution instead of genuinely solving the task.
Catastrophic forgetting: An edit that fixes a failure pattern in one domain might silently break a previously solved workflow in another.
Under-exploration: The system might iterate on minor prompt tweaks rather than exploring new, structurally superior tool configurations.

To prevent these problems, AEGIS relies on full trace observability and a four-stage pipeline:

Digester: Compresses execution traces into structured summaries to identify where the agent failed.
Planner: Analyzes these summaries to enable the system to explore structural changes rather than just local prompt tweaks.
Evolver: Generates code-level harness edits and tests to ensure they run correctly before deployment.
Critic and gate: A Critic assesses the edits to detect reward hacking, while a deterministic gate rejects any update that regresses a previously solved task to prevent catastrophic forgetting.

HarnessX enters a growing field of self-improving harness research — but what separates it is harness-model co-evolution.

The researchers highlight that optimizing either component in isolation eventually hits a wall. Evolving only the harness hits a scaffolding ceiling if the underlying model lacks the reasoning capacity to use the new tools. Training only the model hits a training-signal ceiling if the harness never prompts the model to use its advanced capabilities.

HarnessX interleaves harness evolution with model training. The execution traces generated while the harness attempts to adapt to tasks are converted into reinforcement learning signals for the foundation model. Every time the harness improves its strategy, the model simultaneously learns to better exploit that new strategy, breaking the capability ceilings of traditional AI agent development.

HarnessX makes this co-evolution possible through cross-harness GRPO (Group Relative Policy Optimization). GRPO is the popular RL algorithm used to train reasoning models such as DeepSeek-R1.

When fine-tuning the model, cross-harness GRPO pools an agent's execution trajectories for the same task across entirely different versions of the application's harnesses. This allows the underlying model to internalize high-level strategy shifts, like using a new API endpoint or managing an execution budget, rather than just learning minor prompt-phrasing variations.

HarnessX in action on industry benchmarks

To validate the practical utility of HarnessX, the researchers tested it across five benchmarks comprising software engineering, multi-turn customer service dialog, web navigation, open-ended multi-step reasoning, and embodied planning.

They separated the AI into two roles. The “meta-agent,” powered by Claude Opus 4.6, analyzed logs and wrote the code to evolve the harnesses. The “task agents” ran the actual workflows. To prove the framework is model-agnostic, they tested it on three different worker models: Claude Sonnet 4.6, GPT-5.4, and the open-weight Qwen3.5-9B.

HarnessX was compared against two primary baselines. The first was a static harness, representing how most enterprises deploy AI today, using hand-crafted, frozen setups with benchmark-specific prompts and tools. The second was the Claude Code SDK, a baseline representing a single-agent evolver to test if the complex, four-stage AEGIS pipeline outperformed asking a single language model to iterate on the code.

Dynamically evolving the harness yields significant gains on the same base model. HarnessX improved performance in 14 out of 15 model-benchmark combinations. Across all tests, evolving the harness yielded an average absolute performance gain of +14.5%.

The weakest models benefited the most from dynamic harness improvement. The open-weight Qwen3.5-9B saw a +44.0% performance jump on the ALFWorld embodied planning benchmark, and an +18.2% jump on SWE-bench Verified for software engineering.

Co-evolution also proved highly effective. When the researchers trained the foundation model using the data generated while evolving the harness, they saw an additional +4.7% average performance boost. Improving the harness and the model simultaneously yields the highest ceiling. The co-evolution gain applies only to open-weight models.

Anecdotal evidence from the experiments shows how HarnessX solves pernicious problems when creating agent harnesses for real-world tasks. For example, in the GAIA multi-step reasoning benchmark, the task agent consistently failed because the headless browser tool it used to scrape Wikipedia timed out on the site's JavaScript-heavy frontend. HarnessX analyzed the execution traces, diagnosed the error, and wrote a new tool that bypassed the browser entirely and queried the MediaWiki API directly for plain text. It swapped this tool into the harness and instantly unlocked the failing tasks.

During the WebShop e-commerce tests, the AI agent often got stuck in pagination loops, endlessly clicking "next page" and reformulating searches without ever committing to buying a product. Rather than just tweaking the prompt, HarnessX built an advisory processor that detected when the agent was repeating navigation actions. It injected a warning into the context to force a decision, curing the looping behavior and raising performance.

Limits of automated harness engineering

One important caveat is that the system currently relies on powerful models to act as the meta-agent that rewrites the harness code. In their experiments, the researchers relied on closed frontier models like Claude Opus. Open-weight models are quickly improving, but their ability to serve as the meta-agent remains untested.

Another limitation worth considering is the intrinsic capabilities of the used models. If the underlying task model is fundamentally too weak to execute the complex workflows the new harness proposes, HarnessX will not be able to improve the agent’s overall abilities (the researchers observed this with the Qwen3.5-9B model on the SWE-bench coding tests).

Despite these limitations, HarnessX makes a concrete case that harness engineering — not just model scaling — is a lever practitioners can pull now. For teams running smaller open-weight models on complex workflows, the gains here are large enough to justify evaluating harness evolution as a first step before reaching for a more expensive frontier model. The researchers plan to release the code in a future update.

Visa will offer an inside look at Project Glasswing and how the most powerful agentic models are changing enterprise security at VB Transform 2026

Wed, 24 Jun 2026 20:03:07 +0200

The security implications of advanced AI models were immediately clear to Visa’s technology team when they began testing Anthropic’s Mythos model.

Just weeks into Project Glasswing, the team observed how quickly attackers can identify and weaponize vulnerabilities in critical code bases, creating security risks, explained Rajat Taneja, Visa’s president of technology, during a call to prepare for his session at VB Transform 2026, VentureBeat’s upcoming agentic AI event.

Visa is among the companies selected to test Anthropic’s upcoming model — a version of which was released June 9 but abruptly disabled days later to comply with U.S. government directives.

The findings of Project Glasswing put a spotlight on widening enterprise security gaps and the vulnerabilities malicious actors can take advantage of.

"Security has always been important, but currently, in the age of AI, is going to be even more important because the attacks become autonomous,” Taneja told VentureBeat. “The defenses have to become autonomous. And we are not there. And there's an asymmetry there, which is a very big risk for the world."

Threat actors now have access to powerful AI agents that can work 24/7, “operating at a scale and speed that human teams cannot match, automating the tedious reconnaissance and exploitation phases of a cyberattack,” according to Cisco’s State of AI Security 2026 report. Amy Chang, Cisco’s head of AI threat intelligence and security research, will also be a speaker at VB Transform.

To mitigate these risks, Visa is building its own abstraction layers, observability, and data guardrails to secure its autonomous commerce frameworks. The payment services giant also rolled out an open‑source, AI-driven security framework that turns vulnerability discovery and remediation into a structured, repeatable pipeline.

Their work represents a shift enterprise IT teams must make to protect enterprise systems against threats posed by bad actors wielding autonomous agents. Taneja will share these insights and valuable technical details during his session at VB Transform, titled Inside Project Glasswing and Mythos: Securing the agentic future today, on July 15.

Other agentic AI security-focused sessions at VB Transform include:

CrabTrap: How Brex built an open source proxy to secure OpenClaw’s critical flaws for everyone with Brex co-founder and CEO Pedro Franceschi;
When AI Agents have wallets: Building the trust layer for autonomous B2B commerce with Mastercard’s Chief AI and Data Officer, Greg Ulrich;
Expedia's blueprint for building autonomous agents for high-stakes transactional systems with Chief AI and Data Officer Xavier Amatrain; and
Securing agentic AI: A playbook for permissioning, sandboxing, and human-in-the-loop controls, a panel discussion with AI security leaders from Intuit, Box and Cisco.

Interested in attending VB Transform 2026? Register here. A select number of complimentary passes are also available to senior technology leaders. Contact us to get yours.

The AI readiness gap: Why networks matter more than ever

Wed, 24 Jun 2026 15:32:38 +0200

Ask enterprise leaders about AI and you’re likely to get a wave of excited responses. BCG research found that two-thirds of global CEOs put accelerating AI among their top three priorities, with CIOs under pressure to turn that ambition into business value.

But there’s a problem. Many enterprise AI initiatives are struggling to move beyond pilots into production. Despite near-universal adoption, McKinsey finds that 88% of organizations now use AI in at least one business function, while almost two-thirds remain stuck in pilots and experimentation.

“When it comes to AI readiness, most organizations are still trying to figure it out,” says industry expert Bill Burns. “We’re all asking the same questions: where should workloads live, how will traffic move, what does security look like, and where are the bottlenecks going to appear?”

The reasons are well documented, and most have nothing to do with infrastructure: unclear ROI, poor data quality, governance gaps, change-management fatigue, and a shortage of talent. Any honest account of why pilots stall has to start there.

But there is a common thread why these problems keep surfacing at the same companies, and it sits underneath all of them. Businesses can fix their data strategy, governance model, and talent pipeline, and still find that workloads won’t move where they need to, when they need to, at the cost they need. That constraint is the network – the one layer that gates whether the rest can actually run in production.

Why AI traffic is different and legacy networks can’t cope

Enterprise networks have always evolved to reflect changes in technology and working patterns. The rise of cloud computing and mobile devices in the mid-2000s, for example, shifted enterprise applications from the data center to public clouds and made the internet the network of choice.

AI is triggering the next major shift. It changes the shape, speed and economics of data movement, creating new traffic patterns that legacy infrastructure was never designed to handle. Unless networks adapt, AI will struggle to move beyond pilots into production.

The first challenge comes from training AI models. Unlike traditional enterprise traffic, AI workloads are persistent and continuous, creating demands that can overwhelm existing networks.

“The problem is that many of us are trying to modernize while still keeping the lights on,” says Burns. “It’s a pendulum every day between operational stability and preparing for what comes next.”

Training AI models requires data centers with high bandwidth, ultra-low latency and near-zero packet loss. Networks previously handling 100Gb may now need 400Gb or even 800Gb capacity. In distributed GPU clusters, one delayed packet can stall synchronization across thousands of dollars of compute resources in real-time.

The inference challenge

The second challenge comes from inference, where users interact with AI systems and AI agents talk to each other. This shifts traffic from north-south flows to far greater volumes of east-west machine-to-machine traffic, potentially increasing network demands by as much as 100x.

Furthermore, AI agents operate far faster than humans, meaning millisecond-level delays can become critical bottlenecks. As devices are increasingly used by both people and agents, enterprise networks will need to operate at machine speed.

“The network is no longer a foster child in the AI era,” says Murali Krishnan, associate vice president and head of the strategic products group for the Americas at Tata Communications. “It is the fabric – the epicenter around which performance, ROI and experience will be measured. CIOs need to unlearn what they knew about networks of the past, because how you design and deploy the network has changed from the ground up.”

What AI-ready networks look like

After the physical networks of the 1990s and the software-defined networks of the 2010s, we’re moving into the era of cognitive and contextual networks, fit for the unique requirements of AI. Static, best-effort infrastructure is giving way to networks that can observe, prioritize and adapt in real-time. We believe this new infrastructure must be built on three principles.

Unlike today’s enterprise networks, AI-ready networks will be natively intelligent and autonomous, with deep observability built in as standard. In AI environments, one delayed flow can ripple across an entire workload.

“Most networks can move AI traffic. The difference is whether they understand it,” says Rajat Gopal, vice president, cloud networking and security solutions at Tata Communications. “That means application awareness – knowing which workload a flow serves – consistency you can measure in jitter, not just an uptime number, and sovereignty enforced in the path itself, so data is geofenced by default.”

Given enterprises’ hunger for data, IT leaders will need to architect their future networks with elasticity and scalability in mind – not just increased link capacity, but also more effective congestion domain boundaries and more controlled interconnect paths between clouds.

Because the old perimeter-based security model is defunct in an era of AI-powered threats, when data moves continuously across domains, security and control have to be embedded into routing logic, not bolted on.

Those guiding principles start to map out a way for enterprises to prepare for AI at a foundational level. The network is becoming an active control plane for AI performance, cost and compliance. It also helps address some of the biggest headaches facing IT leaders currently, such as data sovereignty compliance (through visibility into data paths and metadata) and cost optimization (via lowering egress fees).

“We didn’t set out with AI in mind,” says Thor Wallace, CIO at NETSCOUT. “But as it turns out, the decisions we made through our digital transformation have put us in a position where we’re ready for it. The biggest driver was ensuring we had pervasive visibility across the network.”

The time to act

As AI agents spread, the network is becoming a critical – yet frequently overlooked – enabler of enterprise AI success.

The opportunity is significant. As Seth Goodman, CRO at Boost Payment Solutions, argues: “To view AI as primarily a cost saver is missing the point entirely.” The organizations seeing the greatest value are using AI to increase productivity, accelerate decision-making and unlock entirely new capabilities.

With industry leaders already benefiting from AI’s productivity gains, CIOs have no time to waste. Fixing the foundations should be the key first step for IT leaders looking to get ready for AI.

AI-powered enterprises are being built today. It’s time to get real about your AI readiness. Discover how to evolve your network for the next era in Tata Communications latest whitepaper.

Data lakehouses are becoming foundations for enterprise AI

Wed, 24 Jun 2026 12:03:48 +0200

Data lakehouses have become the gold standard for enterprise data platforms since they combine a data lake’s ability to support a variety of different types of data at low cost, and the reliability, structure and governance of a traditional data warehouse.

The fact they offer a central repository of information that might come from different places at a company, together with security and auditing tools, make them a perfect fit for enterprise AI systems, too. In fact, they’ve become so popular and useful that all the major data lake and data warehouse vendors have all but converged into data lakehouse vendors. Snowflake, for example, started out as a data warehouse and over the course of several years and acquisitions, has transformed into a full data lakehouse platform.

Docusign is now using it to support its agentic AI ambitions, too. For example, data is pulled in from Salesforce and then used to train an internal AI agent for sales, says Shivi Verma, Docusign’s senior manager of engineering. The company is also training ML models in order to serve customers more accurately.

The information also goes out to LLMs using RAG embedding pipelines, and MCP connectivity is being explored as the technology matures.

One issue Docusign keeps top of mind when exposing the data in its lakehouse is security and governance.

“We’re proceeding very cautiously,” Verma says. “It goes through a stringent security review and discussion with both technical and business stakeholders to make sure we’re not doing anything that isn’t allowed from the security lens and compliance lens.”

The security checks are in place both when the data first goes into Snowflake, he says, and when it goes out again. The restrictions are particularly tight when it comes to access to anything sensitive, such as customer data.

“We’re first exposing those with a low risk profile,” he says. That can include publicly-facing information like website content or product details.

Docusign isn’t alone. “We see 65% adoption of lakehouses among Gartner’s client base,” says Gartner analyst Prasad Pore. “It’s a very strong number in a short time.”

And the future of lakehouses looks even brighter.

“Lakehouse is becoming the foundation for the future of AI,” Pore says, adding that vendors are evolving to support this use case. For example, lakehouse as a concept doesn’t support vector databases, which are a key type of data structure for AI systems that use RAG to feed data into LLMs.

“But many lakehouse vendors have added capabilities for vector indexing,” he says. “Databricks and Microsoft Fabric both have a vector capability built into their platform.” Yet smaller players might not provide the functionality, he adds.

Similarly, support for MCP, a standard that allows AI agents to connect to data and systems, varies by vendor, and isn’t traditionally a core lakehouse functionality.

A matter of choice

A data lakehouse isn’t the only option for companies looking to provide their AI system with the critical business context they need to be useful to the enterprise.

For example, companies can build vector databases or vector database pipelines manually from individual sources, or use a data fabric to make the connection.

“Fabric can directly connect to original sources, which is a good use case for quick analytics,” Pore says. “But then you’re overloading your source systems, which isn’t a good thing for those products and machines.”

Microsoft Fabric is a lakehouse platform, though, and not a data fabric platform in the way Gartner defines the term.

Another downside is that the data models used in original systems aren’t usually optimal for analytics, and can be expensive. “Connecting to direct sources isn’t efficient,” Pore says.

Finally, there are well-established processes for managing data permissions in a lakehouse.

“A lakehouse physically unifies your data, maintenance, security, and governance,” he says. “This is very critical for AI implementation. As an organizational single source of truth, a lakehouse is the modern way to create a central repository.”

Consulting firm Lemongrass originally started out with a data lake about a decade ago, and then began upgrading it to a lakehouse four years ago.

“Back then, the concept of a lakehouse wasn’t that popular,” says Kausik Chaudhuri, chief innovation officer at Lemongrass. So the firm built custom lakehouse functionality on top of its Amazon S3 data lake. Now that it’s using the data lakehouse to support AI, it’s time for another upgrade.

“Right now, we’re working on something for our incident and change management,” he says. The original data is in ServiceNow, and it’d be too expensive to pull it out directly from the lakehouse to use in an AI system. “So now we’re thinking of building an MCP server to query that data,” he adds.

And they also plan to upgrade from its own custom lakehouse add-ons to a standard solution. “Lemongrass was primarily an AWS evangelist when we started, and a lot of our tooling was on top of AWS,” Chaudhuri says. “Now we’re thinking of changing this because with AI, there’s a lot more opportunity.” Then again, AWS now offers lakehouse functionality. “The data’s already there,” he adds. “We don’t have to reinvent it.”

Plus, AWS has connectivity to Anthropic’s Claude AI and other AI models. And since the models are also running on AWS, there are no data egress fees. Lemongrass plans to start the upgrade with a POC in Q3 this year. “Everybody’s busy, so we need to pull in people and figure out when and how we implement that,” he says. For example, the company has to be careful about what data and how much is pulled in from the lakehouse and sent to the AI.

“We don’t send out customer data to an LLM,” he says. “And I’m not reading 10,000 rows and sending it to Claude, which would blow up to token usage. We figured out a couple of years ago we can go bankrupt if we’re not careful about the amount of tokens we use.”

And for some use cases, the LLM doesn’t need to see anything at all after the solution is deployed. For example, firm employees used to manually generate status reports about its customers for internal use, which was a time-consuming process. An AI model could, in theory, take over that job, but then it’d see the customer data. And since AIs aren’t deterministic, each report would look different.

Or, say, the firm needs to generate forms to fill out and then the customer would sign. Again, an LLM could create a custom form each time. “So then we asked Claude to write a program that takes this input and writes this report,” says Chaudhuri. The process of generating reports or the forms is traditional, deterministic software. The customer data is never exposed, and the reports are cheap and fast to produce.

But other companies are use AI to make better use of its data. In a recent report by Databricks based on data from 20,000 organizations, the percentage of databases created by AI agents rose from 0.1% to 80% over the past two years, and agents now create 97% of database branches.

Security and governance

One major area of struggle for enterprises is to figure out how to handle security and other related issues for when AI agents access data lakehouses.

In the past, data went out to dashboards, in which the security and access controls were programmed. Or the data went to data analysts, who worked within their own access privileges. The first use cases for AI involved RAG embeddings, which were easier to manage.

In a RAG embedding, traditional, deterministic software is used to pull in data and embed it into an LLM prompt for a particular workflow. The developers setting it up would handle the security aspects for each particular use case. With agentic AI and MCP servers, however, the AI can go and grab data autonomously, as needed.

According to Genpact’s Arellano, enterprises need to figure out how to manage the identities of AI agents, control access to data, create audit trails, and filter prompts and content.

“Agents need their own credentials,” he says. For example, AI agents might not have permissions to ever touch patient records. “And audit trails are important, with full observability of what the agent did.”

Some lakehouse vendors, including Databricks, offer this functionality, he says, and there are other tools that can be brought in like Okta, Palo Alto, or Zscaler.

The new semantic frontier

The next evolution of the lakehouse is the semantic layer, and Gartner estimates that universal semantic layers will be critical infrastructure by 2030.

“Developing a universal semantic layer is now a must‑do for data and analytics leaders either leading or supporting AI,” Gartner says. “It’s the only way to improve accuracy, manage costs, substantially cut AI debt, align multiagent systems, and stop costly inconsistencies before they spread.”

It’s one thing for an AI to have access to data, but entirely something else to understand what that data actually means to the business. The semantic layer is the business knowledge that’s not normally formalized in a structured database, such as, say, the knowledge that an order or a customer means different things in different systems.

“Before, the semantic layer was nice to have but not as necessary because data scientists know what data sources they want to query,” says Amit Kinha, board member of the FinOps Foundation and field CTO at DoiT International, a cloud consultancy.

But now, without it, an AI agent won’t know where to look for the data it needs, he says. “Or it’ll do a bad join, or do something that creates a cost explosion,” he adds. “The semantic layer is going to be critical for leveraging lakehouses effectively.”

This semantic layer can also become part of a feedback loop, where the agentic systems learn from experience, says Kevin Martelli, consulting AI solution development leader at EY Americas.

Say for example a company has a process where approvals are required for certain payments, and a CFO is required to sign off for payments over half a million. If the AI agent goes to a human for approval, he says, the human might say this is telling me to approve this invoice, but I know it’s over $500,000 and I need to get CFO approval on this. “Then it can be stored in the session and persisted back in the lakehouse as a procedural document or as a record of something that occurred,” says Martelli. “This is where it becomes more beneficial and aggregates over time with usage because you’re never going to get it perfect on day one.”

The semantic layer is still very much an evolving area, and different data lakehouse vendors handle it differently.

“There’s this great debate going on in the industry of how lakehouses converge with semantic layers and where they actually live,” says Matt Arellano, SVP of data and AI at digital transformation consultancy Genpact.

Some vendors are building semantic tools into their data lakehouse platforms, or acquiring additional firms to get the technology. In other cases, customers are using third-party tools instead.

“Clients are struggling with that,” Arellano says. “They’re all trying to figure out the different combinations and permutations of tools and processes.”

Steven Karan, VP of AI transformation for Capgemini Australia and New Zealand, says he sees the lakehouse as evolving into a central orchestration layer.

“Organizations are now less focused on analytics and reporting, and more on building AI-driven applications and agentic systems,” he says. “The most effective architectures I see today combine a lakehouse core with specialized serving layers.”

That includes vector databases for AI, streaming platforms for real-time data, and operational databases for low-latency applications. The lakehouse isn’t just for analytics anymore, he adds. It’s the foundation for enterprise data and AI. “Its role is now less about replacing all other systems, and more about unifying and governing them to accelerate innovation while maintaining control,” he says.

Effizientere AKS-Fehlersuche mit dem Azure Copilot Observability Agent

Wed, 24 Jun 2026 09:04:02 +0200

Der neue Azure Copilot Observability Agent in Azure Monitor verknüpft verteilte Cluster- und Applikationssignale für eine evidenzbasierte Ursachenanalyse von AKS-Infrastruktur-Problemen.

Forward Deployed Engineers vom KI-Anbieter – lohnt sich das?

Wed, 24 Jun 2026 06:08:12 +0200

loading="lazy" width="400px">

KI-Anbieter schicken auf Wunsch eigene Teams zu ihren Kunden, um bei der KI-Implementierung zu unterstützen. Fragt sich nur, ob das Ihre beste Option ist.

ESB Professional | shutterstock.com

Wenn es um den Einsatz von KI geht, befinden sich IT-Führungskräfte oft in einer schwierigen Zwickmühle: Sie versuchen, widersprüchliche Vorgaben des Managements mit sich ständig verändernden KI-Modellen, Funktionen und Kosten, Anforderungen an die Datenverwaltung und -sicherheit sowie den Grenzen ihres eigenen Teams in Einklang zu bringen. Gartner-Analyst Nader Henein schreibt das in Teilen auch den Anbietern zu: „Es lassen sich nur sehr wenige echte Vorteile erzielen, wenn man einfach ein KI-Produkt kauft und es den Mitarbeitern zur Verfügung stellt. Die KI-Anbieter haben diesen Irrglauben in den letzten drei Jahren allerdings übermäßig angepriesen und gefördert.“

In der Realität, so der Analyst weiter, seien ein hoher KI-Nutzwert und ein konsistenter ROI fast immer das Ergebnis einer tiefgreifenden und gezielten Integration von KI-Fähigkeiten in bestehende Workflows. Dafür benötige man spezialisierte Teams, weiß Henein: „Diese sind alles andere als günstig und werden von Unternehmen auf vielfältige Art und Weise rekrutiert.“

Zu diesen Support-Optionen für KI-Implementierungen gehören:

traditionelle IT-Beratungsunternehmen,
KI-spezifische Beratungsunternehmen,
unabhängige Auftragnehmer,
eine „Acquihiring“-Strategie, oder auch
Open-Source-Lösungen.

Die Option, die in letzter Zeit die größte Aufmerksamkeit gezogen hat, ist allerdings der Einsatz von Forward Deployed Engineers (FDEs). Diese Expertenteams von KI-Anbietern unterstützen die Kunden vor Ort dabei, die Technologie in ihre Umgebung zu integrieren.

Für diesen Artikel haben wir mit Experten nicht nur diskutiert, welche Vor- und Nachteile es hat, auf die FDE-Teams von KI-Anbietern zu setzen. Sondern auch das Pro und Kontra der Alternativoptionen. Eine übersichtliche Tabelle, die sämtliche Ansätze samt ihrer Vor- und Nachteile abbildet, finden Sie am Ende dieses Beitrags.

KI-FDEs – die Vor- und Nachteile

Von KI-Anbietern beschäftigte FDE-Teams verfügen über entscheidende Stärken. Dazu gehören etwa:

ein besseres Verständnis der zugrundeliegenden Modelle,
Erfahrung bei der Integration dieser Modelle in verschiedene Arten von Enterprise-Umgebungen, sowie
Kenntnisse über geplante neue Funktionen, noch bevor diese offiziell angekündigt werden.

Auf der anderen Seite steht allerdings der offensichtliche Nachteil der Anbieterabhängigkeit: Selbst wenn zukünftige Rollouts nicht zu den vertraglich vereinbarten Leistungen gehören, könnten die FDE-Teams eines KI-Anbieters subtilen Einfluss auf die zukünftigen KI-Initiativen ihrer Kunden nehmen. Auch deshalb mahnt Flavio Villanustre, CISO bei LexisNexis Risk Solutions, IT-Führungskräfte zur Vorsicht: „FDEs sind – auch aufgrund finanzieller Anreize ihrer Arbeitgeber – darauf ausgerichtet, die KI-Nutzung des Kunden zu steigern und in Sachen Services ‚Stickiness‘ zu erzeugen. Auch wenn diese Teams einen sinnvollen Mehrwert bieten, ist es Anwendern zu empfehlen, stets auch unvoreingenommene Experten zu konsultieren, die konkurrierende Lösungen verschiedener Anbieter unbefangen bewerten können.“

Das sei laut Villanustre besonders wichtig in einer Zeit, in der die von Investoren subventionierten Geschäftsmodelle rund um KI-Token erste Risse zeigten: „Angesichts des derzeitigen rasanten Innovationstempos könnte es erhebliche Wettbewerbsvorteile schaffen, flexibel genug zu sein, um den Anbieter zu wechseln.“

Auch Sanchit Vir Gogia, Chefanalyst bei Greyhound Research, sieht den Einsatz eines FDE-Teams vom KI-Anbieter als zweischneidiges Schwert: „FDEs sind zwar in die Umgebung des Kunden eingebettet, vertreten aber eben auch die kommerziellen Interessen ihres Arbeitgebers. Den Experten von KI-Anbietern übermäßigen Einfluss auf Implementierungsentscheidungen einzuräumen, könnte nicht nur zu einer erhöhten Abhängigkeit, sondern auch zu hohen Preise führen, gegen die man sich dann unter Umständen nicht wirksam wehren kann.“

Neben der möglicherweise steigenden Anbieterabhängigkeit gibt es weitere Aspekte, die IT-Entscheider berücksichtigen sollten, bevor sie die Teams ihres KI-Anbieters engagieren. Zentral ist etwa die Frage, wie lange die FDE-Teams überhaupt benötigt werden. Schließlich wird es mit einer einzelnen Implementierung kaum getan sein. Die sich daraus ergebenden langfristigen Kosten sind laut John Sangyeob Kim, KI-Engineer bei Solidroad, etwas, das Unternehmen häufig übersehen: „Die Bereitstellung selbst macht vielleicht 20 Prozent der Gesamtkosten aus. Die übrigen 80 Prozent entfallen darauf, den Systembetrieb durch Modell-Upgrades aufrechtzuerhalten, sowie Datenverschiebungen und Randfälle zu händeln, die erst nach Monaten im Produktivbetrieb auftreten.“

Dazu kommen Risiken, die entstehen, wenn das FDE-Team des KI-Anbieters nicht mehr vor Ort ist. Dabei werde beispielsweise in gravierendem Maße unterschätzt, wie umfassend die Einblicke sind, die externe Spezialisten bei der KI-Implementierung gewinnen, meint etwa Justin Greis, CEO der IT-Beratung Acceligence: „Das FDE-Team erhält im Rahmen der Implementierung Insights zu einer Vielzahl operativer Details. Zwar sind die Daten, auf die dabei zugegriffen wird, durch NDAs und Geheimhaltungsklauseln geschützt – die eingesehenen Prozesse und Workflows bleiben jedoch oft außen vor.“

Dieses Problem ist laut Greis aber nicht auf FDE-Teams von KI-Anbietern beschränkt. Wer auch immer bei der Einführung von KI unterstütze, werde deutlich mehr Erkenntnisse gewinnen, als im Statement of Work festgehalten, erklärt der Manager: „Dazu zählen etwa die tatsächlichen, konkreten Arbeitsabläufe, undokumentierte Ausnahmen, Lücken in der Datenqualität, Genehmigungs-Bottlenecks oder Security-Workarounds. Dieses Wissen ist ebenso wertvoll wie sensibel.“

Eine weitere kritische Frage, die laut Greis zu selten gestellt werde: Wie viel sinnvolle Kontrolle wird die IT über das Projekt haben, wenn das FDE-Team seine Unterstützung beendet? „Die Gefahr besteht nicht darin, externe Hilfe in Anspruch zu nehmen – die werden die meisten Unternehmen benötigen. Kritisch wird es vor allem dann, wenn externe Hilfe so eingesetzt wird, dass das Unternehmen nach Beendigung des Auftrags weniger leistungsfähig und abhängiger ist“, konstatiert der CEO.

KI-Experte Kim teilt diese Bedenken und empfiehlt Anwendern insbesondere, zu klären, ob das Projekt auf dem eigenen Observability-Stack oder dem des Anbieters aufbaue: „Wenn der Implementierungspartner den eigenen Observability-Stack nutzt, ist das während des Builds in Ordnung. Aber Sie brauchen einen Plan, um diesen auf eine eigene Lösung zu migrieren, bevor der Anbieter das Projekt beendet. Anderenfalls wird die Visibility mit ihm verschwinden.“

Ein eklatantes Problem entstehe laut Kim hingegen, wenn weder der eigene Observability-Stack, noch der des Anbieters verwendet wird: „Das führt zu einem System ganz ohne Observability-Layer – also ohne Einsichtsmöglichkeit. Wenn in der Produktion etwas ausfällt, haben Sie keine Möglichkeit festzustellen, ob es sich um eine Modellregression, ein Datenproblem oder einen Codefehler handelt.“

Externer KI-Support – die Alternativen

Zwar sind FDE-Teams kein neuartiger Ansatz, dennoch steht nur eine begrenzte Zahl solcher Engineers zur Verfügung. Nicht jedes Unternehmen hat also die Möglichkeit, Spezialisten-Teams von Anbietern einzusetzen. Schwierig wird es mit der FDE-Verfügbarkeit laut Gartner-Analyst Henein insbesondere außerhalb der USA. Das muss jedoch kein Grund sein, auf externen Support in Sachen KI-Implementierung zu verzichten. Schließlich steht Anwendern dazu, wie eingangs dargelegt, eine breite Palette weiterer Optionen zur Verfügung. Diese haben jedoch – ähnlich wie der FDE-Einsatz – nicht nur Vor-, sondern auch Nachteile.

So auch die traditionelle IT-Beratung, wie Ishraq Khan, CEO beim Dev-Tool-Anbieter Kodezi, erklärt: „Klassische Beratungsunternehmen sind in der Regel stärker in den Bereichen Governance, Prozesse, Compliance und organisatorische Koordination. Sie wissen, wie große Unternehmen politisch und strukturell funktionieren. Der Nachteil ist, dass viele langsamer vorankommen und oft keine tiefgreifende Spezialisierung vorweisen können, wenn es um Frontier-KI geht.“

Spezialisierte KI-Beratungsunternehmen wiesen hingegen andere Stärken vor, wie Khan festhält: „KI-native Berater agieren deutlich schneller und sind oft technisch auf dem neuesten Stand. Operativ sind viele dieser Unternehmen aber noch nicht ausgereift. Das schlägt sich dann beispielsweise in beeindruckenden Demos nieder, wobei die langfristige Wartbarkeit, Governance oder Zuverlässigkeit in der Produktion nicht vollständig verstanden wird.“

Acceligence-CEO Greis sieht zudem die Einbindung unabhängiger Auftragnehmer als mögliche Option für externe KI-Unterstützung: „Das kann dem Evaluierungsdesign, Architekturprüfungen, Red-Teaming, Agentendesign zuträglich sein – oder festgefahrene Teams wieder in Gang bringen. Es birgt aber auch das Risiko, sich von einer Schlüsselperson abhängig zu machen – die parallel möglicherweise die Einzige ist, die das System wirklich versteht.“

Für Großunternehmen bietet sich zudem mit dem sogenannten „Acquihiring“ eine weitere Option. Dabei werden (KI-) Unternehmen aufgekauft und dessen Expertise und Mitarbeiter in die eigene Organisation integriert. Unter bestimmten Voraussetzungen könne das ein Gewinn sein, meint Greis: „Nämlich dann, wenn die eingebrachten KI-Fähigkeiten und das Fachwissen für das übernehmende Unternehmen wirklich strategisch wichtig sind. Es besteht dabei jedoch die Gefahr, dass das übernommene Team von der Bürokratie der neuen Muttergesellschaft erstickt wird. Das ist dann in etwa so, als würde man ein Speedboat kaufen, es an einen Flugzeugträger hängen und sich dann wundern, dass es nicht mehr vorankommt.“

Schließlich kann auch eine Open-Source-Strategie Anwenderunternehmen in Sachen KI Flexibilität verschaffen und Abhängigkeiten reduzieren. Das geht allerdings nicht ohne erhöhten operativen Aufwand. Dieser wird ebenfalls häufig unterschätzt, wie Khan darlegt: „Open Source ist nur eine echte Option, wenn die Organisation über die internen Talente und die Disziplin verfügt, um eine ordnungsgemäße Wartung sicherzustellen.“

Externe Unterstützung bei KI-Deployments – die Optionen im Überblick

	Pro	Kontra
FDEs von KI-Anbietern	beste Expertise mit Blick auf das Haupt-KI-Modell	Vendor Lock-In betriebliche Details dringen nach außen
Klassische IT-Beratung	beste Expertise in Sachen Change Management, Legacy-Integration, Rollout, Governance sowie Neugestaltung des Betriebsmodells	möglicherweise zu langsam, zu teuer oder zu generisch
KI-Consulting-Unternehmen	mehr praktische Erfahrung als traditionelle Berater mit Blick auf KI-Deployments Vendor Lock-In weniger ausgeprägt als bei FDEs	unter Umständen mangelndes Verständnis von Enterprise-Anforderungen, etwa in den Bereichen Security, Identity, Auditability, Incident Response, Kostenkontrolle und langfristige Wartbarkeit
Unabhängige Dienstleister	nützlich für Präzisions-Tasks wie Eval Design, Architektur-Reviews, Red Teaming oder Agenten-Design	Risiko der Abhängigkeit von bestimmten Schlüsselpersonen
„Acquihiring“	funktioniert, wenn die eingekauften Fähigkeiten wirklich strategisch wichtig sind	übernommene Teams fallen möglicherweise existierender Bürokratie zum Opfer
Open-Source-Lösungen	reduziert die Abhängigkeit von einzelnen Anbietern attraktiv, wenn es um Datensouveränität, die Kontrolle von Enterprise-Systemen, Kosteneffizienz und regulierte Umgebungen geht	Unternehmen tragen die volle Verantwortung für Security, Patching, Evaluierung, Deployment, Monitoring und Lifecycle Management

(fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Computerworld.com erschienen.

PostgreSQL Diagnostic Superpowers: Deep Visibility with VMware Data Services Manager 9.1

Tue, 23 Jun 2026 18:46:04 +0200

VMware Data Services Manager (DSM) 9.1 enhances observability and diagnostics for PostgreSQL environments. It offers advanced diagnostic tools, a detailed Metrics History View for trend analysis, refined alert routing, and improved audit log forwarding. By automating monitoring tasks, DSM 9.1 significantly boosts productivity, transforming database management into a more efficient and transparent process.

The post PostgreSQL Diagnostic Superpowers: Deep Visibility with VMware Data Services Manager 9.1 appeared first on VMware Cloud Foundation (VCF) Blog.

Rami Rahim’s message for network pros: Legacy networks can’t withstand rigors of AI

Tue, 23 Jun 2026 18:25:59 +0200

Last week’s HPE Discover event in Las Vegas marked the first time the annual user conference included the now-fully-absorbed Juniper Networks. Rami Rahim, former CEO of Juniper Networks and current EVP, president and general manager of HPE Networking, took to the main stage for a dedicated networking session after HPE CEO Antonio Neri’s morning keynote.

Rahim emphasized the network’s importance to AI and how AI is changing networking. He framed the AI conversation around one thing: network foundations. “AI is reshaping every part of the enterprise,” he said, “but none of that happens without the right foundation underneath it. And that foundation starts with the network.”

For network engineers, his keynote and customer conversations offered a clear blueprint for what comes next. Here are five key themes from the keynote and what they mean for your day‑to‑day work life and future career.

1. The network is now the AI foundation

Rahim opened with the story of San Francisco’s Millennium Tower, a visually stunning skyscraper that began to tilt because its foundation wasn’t built for long‑term environmental realities. He used it as an analogy for AI in the enterprise: Massive data movement, constant inference, real‑time responsiveness, and explosive scale will break any network that wasn’t designed for this new era.

“The network is no longer infrastructure sitting quietly in the background,” he said. “It’s become the strategic platform for how organizations operate, innovate, and scale.” You can buy “millions, if not billions, spent on GPUs,” he warned, but “if the network introduces latency and bottlenecks and instability, you’re limiting performance and slowing down outcomes.”

What this means for network engineers:

Architect for AI-era baselines, not legacy traffic assumptions. Design for sustained east-west flows, low jitter, and deterministic paths that support AI training and inference, not just classic north-south traffic.
Translate network health into AI business outcomes. When you speak to leadership, link latency, loss, and path diversity to model training time, inference SLA, or customer experience, not just “link utilization.”
Get in early on AI projects. Push to join the initial design discussions so connectivity, security, and data movement patterns are engineered in rather than patched later.

2. AI for networks: Self‑driving operations are becoming table stakes

The core thesis of Rahim’s presentation is that the legacy network can’t withstand the rigors of AI. “The old model of networking, static, manual, and reactive, simply cannot keep up with the speed and complexity AI introduces.” His alternative is an AI-native, self-driving operations model spanning Aruba Central and Mist, powered by Marvis, Marvis Minis, and an “agentic AI framework.”

On stage, he was joined by Sunalini Sankhavaram, VP of product management at HPE, who elaborated on this shift. “Experience-first AI in action” is built on “real-life experience data, every user, every minute, validated against real customer support cases, and enriched with digital twins.” In one demo, Marvis detected that “over 6% of user minutes were bad,” isolated the issue to a few overutilized APs, and “autonomously fixed the problem by enabling dual-band 5 GHz,” cutting peak utilization from 90% to 54%. Rahim summarized the outcome: “The network identified the issue, understood the root cause, determined the right action, and resolved the problem automatically before any user even had a chance to complain.”

For engineers, that’s a fundamental shift: from being the resolver to configuring, supervising, and governing these AI systems.

How to respond:

Lean into AIOps rather than treating it as a dashboard. Feed full-fidelity telemetry (“every user every minute”) into platforms like Mist and Aruba Central and actively test their recommendations.
Redefine your role as a guardrail designer. Your value increasingly lies in defining SLAs, allowed action scopes, and approval workflows for autonomous changes, rather than hand-tuning every parameter.
Learn the new language of operations: SLAs and “bad user minutes.” If your tooling speaks in experience metrics, you need to as well; they will become the common currency between IT and the business.

3. One AI‑native fabric across campus, branch, and routing

A big structural message in the keynote is unification: Juniper plus Aruba, Mist plus Central, wired plus wireless plus routing, all tied together by a common AI engine.

“We are innovating across both platforms to deliver a consistent self-driving experience,” Sankhavaram said. “With microservices, we can develop self-driving innovations once and deploy them on both the HPE Aruba Central and HPE Mist platforms,” much like a single app running on both iOS and Android. Marvis is being brought “right into the global north view” in Aruba Central, including the “Marvis Trust List”—actions you can set to run fully autonomously, such as automatically recovering a dead camera port to restore video without human intervention.

On the hardware front, HPE has already shipped a dual-platform AP and is bringing the “world-class HPE networking CX portfolio” to Mist for day zero, day one, and day two operations.” Rahim articulated the design principle clearly: “Our mission is simple. Bring the best innovations to both platforms, so that every customer in every industry gets the same powerful self-driving network, no matter which platform they choose.”

Advice for engineers:

Design for platform optionality. Assume that over the life of your hardware, management planes may change. Favor equipment that can switch between Mist and Central (or similar ecosystems) without rip-and-replace.
Embed digital twins into your workflows. Experience twins and synthetic testing should be part of pre-deployment validation and change management, not just a vendor demo.
Build API-first automation muscle. Sankhavaram emphasized “an API-first approach,” making data and actions accessible programmatically. That’s your cue to deepen your skills in Python, CI/CD, and infrastructure-as-code.

4. Networking and security are converging, with AI‑aware controls

Rahim repeatedly stressed that networking and security can no longer operate separately. “Attackers are already using the network as their weapon of choice,” he said, “and with AI making threats faster, smarter, and more sophisticated, defenders need to use the network as part of their defense.” This aligns with my research, which has found that 83% of network engineers now have security as part of their remit.

Customer voices underscored the point. “Security for us is job number one,” said Royal Bank of Canada’s Marlon Drummond. “We don’t have any other job other than protecting our client data. It’s our competitive edge, so we protect it with everything in our fiber.” RBC troubleshoots “at the network layer – the only place that you can get some immutable evidence,” using SD-WAN and DPI to create a “persona or personality for a user” and treat deviations as anomalies.

On the product side, HPE announced a unified SASE orchestrator that combines its Edge Connect SD‑WAN with its SSE stack into a unified SASE orchestrator with a single console. During the session, HPE showed an “AI‑aware firewall” that distinguishes sanctioned, unsanctioned, and tolerated AI apps, enforcing fine‑grained guardrails on uploads, prompts, and keywords. As Rahim put it, this lets customers “see, govern, and protect how AI is being used across their entire organizations without slowing down their businesses.”

For network engineers:

Expect to own more of the zero‑trust and AI‑governance story. Policies like “block ChatGPT, tolerate Gemini with upload and keyword controls” will be implemented in your SASE and firewall fabric.
Instrument the network as a primary security sensor. Follow RBC’s lead: build detection pipelines around network telemetry, lateral movement patterns, and per‑user “personas.”
Treat self‑driving changes as security‑sensitive. Autonomous routing shifts, RF changes, and port resets must respect segmentation and zero‑trust boundaries. Think like both a network engineer and a security architect.

5. Experience‑first networking at real‑world scale

The most compelling parts of the keynote were the customer segments, which showcased just how unforgiving modern environments have become.

Ohio State CIO Rob Lowden described a campus that is “a small city” with 66,000 students, 8,500 faculty, 22,000 HPE APs, and a football stadium that can see “200,000 plus people” in and around the venue on game day. With that density, “we need AI ops to crunch all of that data in real time,” he said. They’ve gone from problems that “can take hours” to being “resolved in minutes versus hours.”

At Sentara Health, director Tom Johnson did a great job highlighting the problem in his industry. “We move massive amounts of data across the organization, and it directly impacts patient care. That’s why our network must be resilient, secure, and always available. Because when data is delayed, care is delayed.” Ambient AI that listens to patient conversations and generates clinical notes is already in production, but “for those kinds of capabilities to work, our network has to deliver that data in real time, reliably, securely.”

Disney’s Ben Croy, who runs global networking, described studio networks where a single animated feature “could easily generate a petabyte of content,” with “over 200 concurrent productions globally.” In that world, the requirement is simple: “speed and simplicity… that’s it.” The network must be “foundational” yet “ideally invisible,” so filmmakers focus on story rather than connectivity.

What network engineers should take from these stories:

Measure what users feel, not just what devices report. Adopt SLAs around app quality (Zoom, EMR, VFX pipelines) as primary KPIs, and design your telemetry and AI‑ops to optimize those.
Use AI‑driven twins and synthetic tests to avoid “disasters that never happened” becoming real ones. Pre‑test big launches (stadium events, AI rollouts, global premieres) with synthetic users and paths, then let Marvis‑style systems validate and remediate.
Become a vertical expert. Whether you support healthcare, finance, education, or media, understanding domain‑specific workflows lets you prioritize and tune the network for what matters to clinicians, traders, students, or artists.

Final thoughts

Rahim closed with a challenge: “The old way of operating networks has reached its limits. The scale is too large, the complexity is too high, the pace of change is too fast, and AI is accelerating all of it.” In that world, “self‑driving networks are not a futuristic idea but a practical necessity.” For network engineers, the opportunity is to be the ones who build, govern, and extend that self‑driving foundation—before someone else does it for you.

I know many engineers still fear AI, but as the expression goes: AI won’t take your job, but another person who uses AI will.

A proof of concept forgives a fragile data path. Operational AI does not.

Tue, 23 Jun 2026 17:19:40 +0200

Presented by F5

When enterprises move AI workloads from pilot to production, data delivery often becomes the factor that determines whether those systems can scale reliably. Point-to-point architectures connecting storage directly to compute hold up under demonstration conditions, but they often break down under sustained, concurrent production traffic. The result is stalled inference pipelines, delayed RAG systems, underutilized GPUs, and SLA violations, all of which carry direct business consequences.

"Organizations successfully operationalize AI when their infrastructure is built to handle real-world failures, not just controlled conditions," says Hunter Smit, senior manager of product marketing at F5.

Production traffic exposes architectural weaknesses

In a pilot, a stalled transfer is an inconvenience, while in production, that same stall is an outage someone now owns. The underlying architecture is often identical in both cases: when a client is wired directly to storage, the system becomes increasingly fragile under sustained, concurrent production traffic because that direct connection has no answer when a node fails or traffic spikes. From there, retries and timeouts cascade, and the entire pipeline backs up right at the moment the business is depending on the output.

"Point-to-point architectures, where the S3 client connects directly to S3 storage, are not resilient," says Paul Pindell, principal solutions architect for technology alliances at F5. "If a single storage node fails, all traffic to that cluster degrades, and in some cases the cluster can fail entirely."

The problem is that AI workflows, including RAG-based inference and agentic AI, increasingly treat S3 storage as a first-class citizen in the AI cluster. However, the network connectivity between that storage and the cluster was never designed for the high-throughput, uninterrupted data movement that's needed to keep GPUs running optimally.

The real cost of stalled pipelines and underutilized GPUs

"Enterprise leaders tend to frame AI infrastructure around GPU utilization, but what makes AI different from traditional deterministic workloads is that infrastructure continuously influences those outcomes at every interaction," says Tanu Mutreja, senior director of product management at F5. "In AI environments, infrastructure is no longer just a back-end concern. It shapes customer experience, quality, resilience, and cost with every transaction."

There can be significant business consequences. For instance, when inference pipelines stall, it becomes an SLA and customer experience issue. When RAG systems are delayed, models lose access to timely, relevant context, which results in inaccurate, outdated, or hallucinated responses, all of which create operational, compliance, and reputational risks. At the same time, the infrastructure issues that create those problems can also drive up costs by leaving expensive GPU resources idle or underutilized.

"When GPUs are underutilized, it signals infrastructure inefficiencies that inflate costs while limiting scalability and responsiveness," Mutreja says. "The leadership question is whether the end-to-end AI infrastructure consistently delivers reliable, secure, high-quality, and governed AI experiences at sustainable unit economics."

Building a production-ready data delivery layer

F5 treats data delivery as a first-class infrastructure layer rather than assuming the network path will simply work. Where application delivery optimized the flow of requests between users and applications, data delivery optimizes the flow of data between storage, networks, and compute, including AI compute.

Making data delivery a first-class layer means building three properties into it:

Observability provides real-time visibility into latency, throughput, and flow health.

Programmability enables policy-driven control over how data moves, through dynamic routing, traffic optimization, rate management, and automated failover.

Failure-awareness builds resilience for degraded networks, storage throttling, and service disruptions.

In the architecture F5 has developed for Dell ObjectScale, F5 BIG-IP sits between ObjectScale and AI compute as a programmable control point at the storage edge.

"We have seen cases where a misconfiguration in the AI compute layer effectively DDoS'd the S3 storage infrastructure, " Pindell says. "Not in a malicious way, more of an 'Oh no, what did I do?' moment, but it still took storage down for the entire organization."

Placing BIG-IP as the application delivery controller between the storage and compute layers protects storage with QoS, rate limits, and connection limits, keeping it resilient and operational under that kind of load. SecureIQLab-validated testing confirmed that this protection does not come at the cost of throughput, which matters architecturally, Pindell says.

"Preserving, and even improving, throughput is a must-have," he explains. "It's what lets you layer on the higher-level functionality, resilience and enhanced security, without giving up performance to get there."

The added complexity of hybrid and multicloud AI

AI deployments in hybrid multicloud environments have an even greater data delivery challenge because of the heterogeneity involved. In other words, data traversing these environments must contend with inconsistent policies, security controls, identity systems, governance requirements, fragmented visibility, and distinct failure boundaries.

Programmable traffic management and observability address this complexity together. Observability provides a unified view of application, network, and infrastructure health across otherwise disconnected environments. Programmable traffic management uses those insights to intelligently route, balance, and fail over traffic in real time. Together, they create a closed-loop feedback system that enforces consistent policies, improves resilience across failure domains, and ensures reliable, high-performance AI data delivery regardless of where applications, data, or users reside.

What separates production AI from perpetual pilots

The organizations that move beyond perpetual pilots share a specific engineering discipline, Smit says.

"They're the ones that reach for production design with failure as the normal state, not the exception," he explains. "They will assume latency, congestion, and partial outages will happen. And they build a data path observable and failure-aware enough to absorb them, with explicit mitigation for every degraded condition rather than a hope that the network will hold."

Organizations stuck in perpetual pilots are still optimizing for the perfect lab result and discovering the real-world gap only when a workload goes live. The issue is not model quality or GPU count, but whether the data delivery layer was engineered with the same rigor as the compute.

"Teams need to understand that a real-world network behaves very differently from an optimized lab network," Pindell says. "They need a mitigation plan for the failure states and performance bottlenecks they will hit in production."

The hidden cost of becoming AI-ready?

Tue, 23 Jun 2026 13:03:03 +0200

Governance debt

Modernization of legacy systems is not a new phenomenon. I have personally been involved in legacy system migration to a more efficient & modern software. Driven by the goal of achieving efficiencies, it may take months for the initial results to show up while the migration continues in other phases. The emergence of AI has triggered an enterprise-wide race to drive efficiency across nearly every business process.

Today’s CIOs are under pressure to see measurable returns from AI investments and as a result, chatbots, agents and GenAI tools are being deployed at an unprecedented pace. The primary metric used to evaluate success is productivity, with AI delivering massive gains through faster coding, documentation, content generation and prototyping. However, these benefits often obscure a less visible reality: AI-generated outputs need code verification, compliance reviews and ongoing oversight.

I have not personally seen an organization where the “AI First” mandate is accompanied by a “governance-first” strategy. Yet, as executives push for faster delivery and measurable gains, risk assessments are often viewed as obstacles rather than necessities. This creates an interesting organizational paradox: the very technology adopted to accelerate work simultaneously introduces new requirements for oversight, accountability and trust. The phenomenon becomes even more significant as it gets embedded into every facet of organization, from software development to business reporting as well as customer support.

Having a manual human in the loop review for every agent output will not scale in the long run. But if not governed, the results are much more devastating with undocumented AI behavior and auditability gaps. Another factor necessitating governance is the AI inconsistency. Most leaders assume that AI behaves like traditional software with an input and an output. But with most AI models, the behavior differs even with the same prompt, model and data as different agents interpret context differently. Inconsistent AI outputs make enterprise quality standards harder to scale.

According to a study “Global AI Pulse” by KPMG in 2026’, 54% organizations remain in the early stages of the AI journey, while 75% executives expressed concern about AI-related risk and security, which begs a vital question – How do leaders enforce AI adoption while keeping the safeguards in place?

How should AI be reviewed?

As organizations embrace AI, the question of governance involves thinking at the grassroots level. In my fifteen years of overseeing complex architectures, having a human in the loop for daily pipelines generating output defeats the premise of AI adoption. Why is this operationally challenging? Most AI agents are generating thousands of answers to prompts and writing multiple lines of code. Additionally, AI agents are working at several stages of cleansing data, algorithm design and model configuration. The volume of generated AI artifacts will quickly exceed human review capabilities. One of the ways of countering this dilemma is to have additional oversight where human judgment delivers the most value in the initial phases of adoption. The AI leaders should be asking teams to validate for high-risk decisions, regulatory requirements, customer facing interactions. The objective can be to define a set of AI red flags for every team to be used as a governance framework, helping to identify the most common risks and maintain standards across the organization. This also leads to an important question of AI usage metric: What should leaders be using as a metric for measuring AI success while governance safeguards are being put in place?

The token trap

Enterprises have traditionally had to evolve their metrics of measuring digital transformation. Since productivity is the byproduct of AI, there is a temptation to use AI activity as a proxy for the value it generates. In many organizations, AI usage is getting measured by prompts, queries submitted, tokens used and interaction with chatbots. “Token maximization” — where employees are asked to track AI token usage, thereby correlating productivity with using more tokens — is driving up the organization’s costs without considering AI validation costs. In one of the articles on Fortune, this stark reality is exposed. According to the article, even the least expensive version of Clause Opus 4.6, which costs $5 for every million tokens and token usage going into billions, one user alone can cost the firm more than $1.4 million in costs. This creates a dangerous incentive structure with employees working towards higher token usage than maximizing the business outcomes.

In complex engineering environments, high activity does not correlate with high productivity. Employees trying to research a proprietary tool can use millions of tokens to get basic information, while seasoned employees trying to add value to the work may end up using a fraction of them. So how can leaders address this? The answer once lies in governance. During the cloud transformation era, organizations established teams responsible for Cloud deployment, migration standards and cost optimization. AI adoption requires a similar operating model for measuring AI activity as well as outcomes.

Measuring adoption to outcome

For a CIO, measuring AI impact is as critical as the adoption of AI. To get measurable values out of AI tools, the urge to deploy and measure usage activity should be replaced with a tactical, long-term approach to measure gains. AI adoption should be evaluated based on its impact on workflows. Leaders should focus on measurable improvements in the day-to-day tasks themselves. Organizations can track the reduction in deployment time for processes with or without the use of AI, along with the costs incurred on tokens or queries. Another metric to measure is improvements in accuracy by comparing established baselines with AI-generated output. An AI agent that generates faster output but requires more corrections might end up being less productive than a human. Cost efficiencies that compare AI cycle time with token usage are another good indicator of AI adoption measurement.

AI and its impact on organizational learning is another critical metric where the objective should be for employees to build expertise faster, transfer knowledge with better decisions over time. AI adoption that leads to less learning and more dependency (due to reliance on AI) may lead to organizational risk rather than adding value. Finally, as AI adoption matures, organizations should establish prompt governance frameworks. Aggregated team-level reporting that highlights prompt usage will reveal key training opportunities among employees. The idea is to help teams develop stronger AI practices while optimizing token usage and business impact.

From adoption to value

One of the most overlooked aspects of organizations adopting AI is its long-term operating cost. The underlying economics of AI carry the same level of discipline that organizations apply to all the other assets. While AI observability has emerged as an important metric to gauge AI adoption, CIOs must think beyond usage metrics and focus on the long-term return of AI investments. An organization’s AI maturity assessment should be calculated on the basis of spend vs created value, accuracy, skill development and cost effectiveness. Creating a framework to measure the value that AI creates will define the success of AI adoption for the organization and enable it to innovate and scale. Ultimately, the enterprises that succeed with AI will not be the ones to show it the fastest. AI success will not be a function of deployment speed; it will be a function of architectural discipline

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Principal Drift

Tue, 23 Jun 2026 12:33:42 +0200

Over the past year I’ve reviewed enterprise agent architectures at roughly two dozen organizations, including banks, retailers, healthcare systems, and a couple of regulators. The architecture diagrams have been reliably impressive. There are boxes for the MCP gateway, the tool registry, the vector store, the orchestrator, the policy engine, and the observability stack. There are […]

Beyond the Doomsday: Operational Resilience, Identity Sprawl, and Back-to-Basics Cyber Defense

Tue, 23 Jun 2026 09:08:40 +0200

This special episode brings together top industry experts to dissect the rapidly shifting landscape of modern cyber threats, cloud technologies, and artificial intelligence. The conversation moves past standard industry hype to deliver practical frameworks for building true operational resilience. Listeners will walk away with actionable strategies to harden their environments, manage expanding identity footprints, and move from basic network visibility to deep behavioral observability.

AWS Continuum offers devs help with securing code

Mon, 22 Jun 2026 18:38:22 +0200

AI coding agents are making it easier than ever to produce software. Ensuring that software is secure before deployment is another matter — one that AWS thinks AI should help with too.

As enterprises adopt agentic development workflows, the volume of first-party code being created and modified is rising rapidly. Yet the process of validating vulnerabilities, determining whether they are exploitable, and fixing them often still depends on developers and security teams working through findings manually.

AWS is aiming to address that imbalance with Continuum, a new service designed to continuously discover, investigate, and remediate vulnerabilities in enterprise environments, whether the code is their own or from third parties.

Rather than simply generating alerts, the service is intended to help enterprises move findings through the entire remediation lifecycle, AWS VP of Security and Observability Chet Kapoor wrote in a blog post.

For first-party applications, Continuum can analyze code, validate whether vulnerabilities are exploitable, generate remediation recommendations, and propose fixes that can be reviewed through existing software development workflows, helping developers address security issues without requiring security teams to manually investigate every finding, Kapoor said.

Once users think Continuum has learned enough about their environment and understands their guardrails, they can put it in what AWS calls “enforce mode” to autonomously fix any code lapses, Kapoor said.

Continuum borrows some of its capabilities, penetration testing and code scanning features, from an existing service, Security Agent.

Other capabilities are all-new, including threat modeling, which is designed to automatically generate threat models from source code or design documents and output them in STRIDE format.

Keeping pace with AI-driven software development

Analysts see Continuum helping enterprise developer teams ship more secure code while keeping pace with AI coding tools.

“The harder problem is no longer just finding issues, it is knowing which ones are real, which ones matter in their environment, and which ones need to be fixed first,” said Akshat Tyagi, associate practice leader at HFS Research. “Traditional workflows built around dashboards and manual triage struggle with that volume. A dashboard can show the backlog, but it does not validate the finding, assess business impact, or help remediate it.”

Continuum’s value, according to Tyagi, “is not just more detection, but using AI to prioritize risk findings, suggest mitigations, and support faster action while keeping humans in control of high-risk decisions.”

Taking faster action is becoming increasingly important as attackers are gaining access to many of the same AI capabilities that enterprises are using to accelerate software development and security testing, according to Amit Chandak, chief analytics officer at IT consulting firm Kanerika. “The gap between a flaw being disclosed and a working exploit is shrinking rapidly from months to hours,” he said.

While Continuum may reduce repetitive work for developers and SREs, it could also create new responsibilities for CISOs around governance, oversight, testing, and maintaining guardrails for automated actions.

“Continuum changes the CISO’s role from managing findings to governing how findings are handled. The focus moves to setting rules: what can be automated, what needs human approval, and what level of risk is acceptable in production,” Tyagi said. “Staffing will shift too. There may be less manual triage, but more need for people who can review AI-generated fixes, set guardrails, and know when not to trust the system.”

Even so, Chandak does not expect the offering to lead to immediate headcount reductions, particularly given that Continuum is only available as a gated preview.

Continuum could change how CISOs measure work, Tyagi said: “Ticket count matters less. Better measures are how quickly real risks are validated and fixed, how many false positives are removed, and whether automation is reducing risk without causing new problems.”

Those same metrics could also become a yardstick for CISOs determining how much autonomy to give tools like Continuum, said Chandak. Most enterprises’ data and governance practices are not yet ready for fully autonomous remediation, said Chandak, adding that, “AWS’ graduated trust design, under which enterprises have the option of choosing the degree of autonomy, from human in the loop to fully automatic remediation, is an admission of that fact.”

Beyond first-party code

Continuum could also help CISOs with third-party code vulnerability analysis, where enterprises often have less visibility and control.

“Most third party vulnerability alerts are noise. A tool may flag a vulnerable library, but the real question is whether that vulnerable code is actually used in production. If Continuum can answer that, it helps teams focus on the few issues that matter,” Tyagi said. “This is especially useful for open-source and software supply chain risk, where enterprises depend on packages and hidden transitive dependencies they may not fully track. It also helps when no patch is available yet.”

However, he warned, Continuum might not offer a direct fix to third-party code: “You usually cannot patch third-party code yourself as you don’t own it, so remediation there means version pinning or compensating controls.”

This article first appeared on InfoWorld.

AWS Continuum offers devs help with securing code

Mon, 22 Jun 2026 18:33:47 +0200

AI coding agents are making it easier than ever to produce software. Ensuring that software is secure before deployment is another matter — one that AWS thinks AI should help with too.

Continuum borrows some of its capabilities, penetration testing and code scanning features, from an existing service, Security Agent.

Other capabilities are all-new, including threat modeling, which is designed to automatically generate threat models from source code or design documents and output them in STRIDE format.

Keeping pace with AI-driven software development

Analysts see Continuum helping enterprise developer teams ship more secure code while keeping pace with AI coding tools.

Even so, Chandak does not expect the offering to lead to immediate headcount reductions, particularly given that Continuum is only available as a gated preview.

Beyond first-party code

Continuum could also help CISOs with third-party code vulnerability analysis, where enterprises often have less visibility and control.

Why agentic enterprises need to become learning systems

Mon, 22 Jun 2026 17:48:01 +0200

Presented by Splunk

Every day, organizations learn things their AI systems never get to use.

A security analyst corrects an AI-generated investigation. A network engineer identifies the root cause of a recurring outage. An observability team discovers that a pattern of latency, logs and infrastructure changes predicts service degradation. A customer operations team learns which signals indicate an escalation is likely.

Each moment contains valuable organizational knowledge. But in most enterprises, that knowledge disappears into tickets, dashboards, chat threads, post-incident reviews and the minds of individual experts. It may help solve the immediate problem, but it rarely becomes part of a reusable system that improves future AI-driven decisions.

That is the next challenge for the agentic enterprise.

The future will not be defined simply by who has the most capable model or the most autonomous agents. Many organizations will have access to similar frontier models. Many will deploy agents across security, IT, engineering, customer service, and business operations.

The real differentiator will be whether those agents can learn from the organization around them.

Not by constantly retraining the underlying model, but by capturing operational experience, converting it into institutional knowledge and making that knowledge available to future agents, workflows, and decisions.

The agentic enterprise is not just an enterprise that uses AI. It is an enterprise that learns through AI.

Agentic enterprises allow AI systems to learn from them

The AI conversation has been dominated by model capability: larger context windows, better reasoning, faster inference, stronger tool use, and more sophisticated agentic behavior.

Those advances matter. But in the enterprise, a model is only one part of the system.

A model does not automatically know how a specific organization operates. It does not inherently know which remediation step solved last month’s outage, which analyst correction improved a threat investigation, which network signal preceded a service disruption, or which internal policy should override an otherwise plausible recommendation.

That knowledge belongs to the enterprise.

For agentic systems to improve, organizations need a way to capture that knowledge and make it reusable. In many cases, that does not require changing the model itself. It requires changing the ecosystem around the model: the knowledge base, retrieval layer, prompts, policies, guardrails, routing logic and workflows that shape how agents behave.

The model may remain the same. The learning system around it becomes smarter.

Feedback loops turn every outcome into a teachable moment for agents

Every agentic workflow creates signals.

An agent receives a request. It retrieves context, reasonsthrough possible actions, calls tools, and generates answers. A human accepts, rejects, or modifies that answer. Downstream systems reveal whether the action worked.

That entire chain is valuable.

AI observability gives organizations visibility into what happened: the prompt, response, reasoning path, tool calls, data sources, intermediate steps, failure modes and outcomes. Without that visibility, organizations cannot understand why an agent behaved the way it did, let alone improve it.

But observability alone is not enough.

The larger opportunity is to turn observed behavior into institutional knowledge. A trace should not only help a developer and operators debug an agent. It should help the enterprise understand what the agent learned, what the human corrected, what outcome followed, and what should change before the next similar event.

That is the shift from monitoring AI to teaching AI.

In the agentic enterprise, feedback loops connect action to outcome, outcome to knowledge and knowledge back to future action.

A learning system in practice across security, observability and the network

Consider a service experiencing intermittent degradation.

An observability agent detects unusual latency and error rates. A network agent identifies packet loss across a specific path. A security agent notices that the same time window includes suspicious authentication behavior and unusual traffic from a previously unseen source.

Individually, each agent has only a partial view. Together, they create a richer operational picture.

The first time this incident occurs, human experts may need to intervene. A network engineer confirms that packet loss was caused by a misconfigured routing change. A security analyst determines that the suspicious traffic was not an attack, but a side effect of a misrouted internal service. An SRE connects the network event to the application degradation.

That resolution contains knowledge the organization should not have to relearn.

A mature agentic learning system would capture the traces, human corrections, topology context, security findings, observability signals and final remediation steps. It would preserve the relationship between those signals: latency pattern, network path, identity behavior, routing change and remediation.

The next time a similar pattern appears, agents would not start from zero. They could retrieve the prior case, compare current conditions, recommend the proven diagnostic path and escalate with better context.

The underlying frontier model did not need to be retrained.

The enterprise learned.

The architecture of the learning agentic enterprise

A learning-oriented agentic enterprise needs more than a model or chatbot. It needs an architecture that can capture experience, turn it into usable knowledge, connect that knowledge to operational context, and govern how it changes future agent behavior.

Memory preserves what happened: what the agent saw, what it did, where humans intervened, and what outcomes followed.

Knowledge bases turn that experience into reusable guidance, including playbooks, examples, policies, procedures, and evidence.

A data fabric connects the operational environment. The signals agents need live across logs, metrics, traces, tickets, identity systems, security tools, network telemetry, collaboration platforms, and business applications. A data fabric makes those signals discoverable, correlated, governed, and usable in context.

AI observability explains how agents behave by capturing prompts, tool calls, intermediate steps, responses, feedback, and outcomes. That visibility helps organizations understand where agents succeed, where they fail, and what should improve.

The control plane governs how learning becomes change: what knowledge is promoted, which prompts or policies are updated, which agents can use new information, what approvals are required, and how changes are audited.

Together, these capabilities allow AI systems to improve over time in a controlled, trustworthy way that allows the enterprise to learn from its own operations.

The organizations that learn fastest will win

The next era of AI will not be won by models alone. It will be won by organizations that can capture what they learn from every workflow, expert correction, incident, investigation, and outcome.

The most advanced agentic enterprises will not simply deploy more agents. They will build systems that allow every agent to benefit from the collective knowledge of the organization.

That means connecting operational data through a data fabric. It means observing agent behavior deeply enough to understand it. It means preserving experience in memory and institutionalizing it in knowledge bases. It means using a control plane to govern how learning changes agent behavior.

The future of AI is not a single autonomous agent acting alone. It is an ecosystem of agents, humans, data and controls that learns over time.

The organizations that build that ecosystem will create AI systems that get better with every interaction. Not because the model is constantly changing, but because the enterprise itself is becoming more intelligent.

Learn more about how Cisco Data Fabric powered by the Splunk Platform is accelerating agentic operations.

Hao Yang is Vice President AI at Splunk, a Cisco Company.

Is Mistral late or savvy?

Mon, 22 Jun 2026 11:19:13 +0200

For the past few years, the most visible corner of the AI market has been easy to caricature: OpenAI gets the consumer attention, Anthropic gets the developer love, Google gets the benefit of the doubt with increasingly capable models and a complementary product suite, and everyone else gets to explain why they’re not dead yet.

That’s unfair, of course, but not completely wrong. In AI, attention compounds and it’s leading to outsized revenue, with both OpenAI and Anthropic reportedly rushing toward trillion-dollar-sized IPOs on the backs of billions in revenue.

So it’s easy to underrate Mistral AI.

Honestly, I hadn’t thought of the Paris-based company for a year. Maybe longer. But then Brian Hall announced he’s joining Mistral as CMO, and I had an Arrested Development “Her?” moment. Hall, a longtime Microsoft exec, hired me at AWS and went on to run product marketing at Google Cloud. His move prompted curiosity because Mistral doesn’t dominate developer chatter in the United States or boast the same seemingly endless compute budgets as Anthropic or OpenAI. If the AI market is simply a race to build the biggest, most magical, most general-purpose model, Mistral isn’t the company to bet on.

But that’s the wrong question, and likely the wrong bet.

The more interesting question is when the enterprise AI market will revert to type and demand that AI deliver the same security, predictability, and control we’re used to from other IT investments. Here Mistral has a real story. As Hall notes, Mistral’s approach is to “prioritize AI for mission-critical environments that need the confidence and self-control to bet for the long term (with open weights and real sovereign capabilities).”

While this might have sounded like an overly hopeful talking point, it became real in June when the US government ordered Anthropic to suspend access for foreign nationals to its most advanced Fable 5 and Mythos 5 models. Anthropic said it would disable the models for all users because of the export-control directive. “Can this vendor be forced to turn us off?” is no longer a theoretical question.

That’s why Mistral’s quiet focus on enterprise control just might work.

The wrong race

The enterprise control story is much more compelling than the narrative I used to hear. You know, the “Europe needs its own OpenAI” schtick. There is a market for “patriotic AI,” but it’s relatively small. The far bigger market is comprised of enterprises that just want AI that works, costs less (or delivers more) than expected, and can be customized while fitting their compliance requirements.

Though the company’s initial launch page went out of its way to mention that the company was operating out of Europe and headquartered in Paris, since at least October 2023 Mistral’s product posture has centered on enterprise control. Scattered throughout its current (and past) website are words like “customize,” “fine-tune,” “open source,” and “complete control.” Mistral pitches Studio for building and running AI apps, Forge for custom model training and alignment, Vibe for agentic work, Vibe for Code for coding workflows, and Compute for training and inference infrastructure. The company talks about observability, evals, guardrails, deployment portability, and running production AI “from edge to cloud.”

In other words, it sounds less like a chatbot company and more like an infrastructure company.

That positioning becomes clearer when you look underneath the product names. Mistral AI Studio includes an AI Registry that acts as a system of record for agents, models, data sets, judges, tools, and workflows. It tracks lineage, ownership, and versioning. It enforces access controls and promotion gates before deployment. That’s boring governance plumbing (and “boring” is good in enterprise IT, as I’ve written).

Forge may be even more important. Mistral describes it as a way for enterprises to train frontier-grade models on proprietary enterprise data. Rather than training on others’ copyrighted information strewn across the web or on a mountain of Reddit posts, Forge goes well beyond retrieval-augmented generation (RAG) to not simply “read in” proprietary docs/info/etc., but rather to give an enterprise its own private OpenAI, as it were.

That’s super interesting.

But is it different? I mean, OpenAI and Anthropic can do plenty of this, with greater scale and the benefit of leading frontier models. Both have enterprise products, cloud partnerships, evals, agents, governance tools, and varying forms of model customization. Mistral’s bet with Forge isn’t that the big labs can’t customize models. It’s that some enterprises aren’t interested in customization as a side feature bolted onto a frontier API. It is the product. OpenAI and Anthropic can build everything around Forge but not Forge itself, because the one thing they almost certainly aren’t interested in selling is independence from them.

This is where Mistral may have found a useful seam, one that allows it to ask a different set of questions. What if the best enterprise model isn’t the smartest general-purpose model? What if the best model is the one that’s small enough to run where the customer needs it, open enough to inspect and adapt, cheap enough to use broadly, and specialized enough to do the job? What if “good enough, governable, and your own” beats “slightly smarter, mostly opaque, and rented”?

This won’t matter for every use case, of course. If I’m asking AI to reason through a spreadsheet or write code, I probably want the best model I can get. But for banks, defense agencies, manufacturers, utilities, telcos, and governments, “best” is multidimensional and includes questions like latency, auditability, etc. It’s why banks, for example, still run so many workloads on premises: They want control.

What about compute?

None of this makes compute irrelevant. But it may change how compute matters.

If Mistral is trying to be a French version of OpenAI, its lack of hyperscale compute is a fatal weakness. It won’t outspend OpenAI, Oracle, Microsoft, Google, Amazon, SpaceX, or Anthropic. It probably won’t out-recruit them across every frontier research area, either. The AI market is already littered with companies that underestimated how quickly “good model” became “not good enough.”

But if Mistral is trying to become the enterprise-controlled AI layer for organizations that don’t want all intelligence to live behind someone else’s API, compute becomes a more nuanced issue. It still needs infrastructure, and Mistral seems to know it. After all, Mistral raised $830 million in debt to buy 13,800 Nvidia chips for a data center near Paris. That’s a rounding error compared to OpenAI and Anthropic, of course, but the real question is whether Mistral can turn relative compute scarcity into a virtue, like Amazon’s Leadership Principle “Frugality” on steroids. If lower compute capacity leads Mistral to deliver smaller, more efficient, and more specialized models, which in turn helps enterprises maintain more control of their data at lower cost, then less really does become more.

Mistral’s compute challenge, then, is not to try and have as much compute as OpenAI. It’s to make customers care less about raw compute scale and more about deployment flexibility, specialization, and control.

That’s a hard sell. But it’s not a dumb one.

What Mistral must prove

The bear case remains obvious. OpenAI has consumer distribution, developer mindshare, capital, and a brand that has basically become synonymous with AI. Anthropic has become the developer darling and has an unusually strong enterprise story of its own. Google has the models, the infrastructure, the data, and a bevy of complementary services. AWS, Microsoft, and Oracle have customer relationships and infrastructure.

Mistral has to prove that there’s room for another center of gravity. More specifically, it must prove three things.

First, it has to show that open-weight and controllable AI matter enough to influence buying decisions, not just conference panels. Everyone says they want control, just as most like the idea of open source. But proprietary software and cloud services still dominate the market. Mistral must make control feel like the easy button.

Second, it must prove that specialization beats generality in enough high-value markets. “Our model is almost as good” is not a strategy. “Our model is better for your bank, your government agency, or your retailer” just might be.

Third, it needs to establish a beachhead within enterprise IT before OpenAI and Anthropic become “boring” enough to satisfy the same buyers. This is the real race. The biggest AI companies are hiring enterprise sales teams, building admin controls, and cutting deals with every major cloud. Mistral’s window exists because the market is still young, but that window won’t stay open much longer.

If AI remains a model benchmark race, Mistral likely loses. But if AI keeps evolving to become grown-up enterprise infrastructure, Mistral has a real chance.

Why open infrastructure will define the AI era

Mon, 22 Jun 2026 11:19:12 +0200

A new form of vendor lock-in is here. And it’s not proprietary languages or rigid enterprise software suites — it’s something more fundamental. It’s the very thing that writes the code.

JetBrains Research found that 74% of developers worldwide use AI tools. Claude Code, available only since May 2025, is now the most popular AI coding tool, followed by Gemini Code Assist and GitHub Copilot, according to Jellyfish’s 2026 State of Engineering Management Report.

The latter study also found that 91% of developers say their productivity has increased in the past 12 months. As coding output expectations are rewritten daily, the engineering world is becoming heavily reliant on paid external AI services.

Gartner predicts that by 2028 spending on AI coding tokens could exceed developer salaries. Yet, tokenmaxxing while vibe coding through a vendor’s cloud-based API feels like a far cry from the open foundations of free programming languages and open models, which many of today’s AI platforms now abstract.

“Open infrastructure will be the backbone of the AI era,” says Peter Farkas, CEO of Percona, a provider of open-source database solutions. “Right now, too many companies are building their entire AI strategy on top of proprietary platforms because the convenience is seductive.”

“It’s ‘three clicks’ to stand up a database or an AI service in a hyperscaler, and that convenience blinds people to the lock-in they’re signing up for,” he adds. “As AI workloads mature, organizations will realize that depending on one vendor for their data, models, runtime, and pricing is not a strategy.”

AI-assisted coding is democratizing software engineering for non-engineers and accelerating top performers. But if teams are always working within the confines of how one platform thinks the world should work, it could create locked-in toolsets at scale. And as AI platform costs rise, a fundamental question arises: will software developers consume AI on their own terms, or on someone else’s?

There’s a strong case that the long-term winners in tech will be built on open-source standards and foundations, similar to the history of cloud-native computing and the internet itself.

“Open always wins,” says Brian Alvey, CTO at WordPress VIP, a managed WordPress hosting platform. “Not because it’s a fancy ideology, but because it gives you total freedom to adapt, evolve, and stay in control.”

Open infrastructure avoids a future where developers perpetually rent. “For AI to be useful to people at large, it can’t be something you’re paying rent for the rest of your life,” says Manik Surtani, CTO and co-founder of the Agentic AI Foundation (AAIF), a vendor-neutral home for open-source agentic AI technologies. “And it can’t be concentrated in one particular corporation or a small handful of corporations, because we know how that goes.”

Pricey, closed, proprietary AI

AI development today is traveling two parallel paths. On one path, open-source AI is thriving and fueling tremendous growth in the number and variety of AI models and tools. Just take the thousands of open-weight models on HuggingFace, the community around the OpenClaw AI agent, or the many academic institutions publishing new breakthroughs.

“Open-source models and tooling are hot on the heels of state-of-the-art, with interesting and boundary-pushing work being shared by labs and researchers across the world,” says Austin Parker, director of AI strategy at Honeycomb, an observability platform provider, citing frontier open-source models like Mistral, DeepSeek, and Ai2’s OLMo as examples.

Others agree. “There’s unprecedented openness at the model and tooling layer, with open-source models, frameworks, and orchestration advancing at remarkable speed,” says Mark Collier, general manager of AI and infrastructure at the Linux Foundation.

On the other path, we’re seeing heavy reliance on proprietary AI systems controlled by Anthropic, Cursor, Google, Microsoft, OpenAI, and others. As Collier says, “Many platforms are wrapping those open components in closed, opinionated interfaces that trade short-term speed for long-term constraints.”

Open source and the AI tooling market don’t always mix well. LangChain’s Open Agent Platform, for instance, was open-sourced to much fanfare in 2025, but by 2026 had been deprecated, with the repository now recommending fully managed alternatives.

For Roman Shaposhnik, co-founder and CTO of Ainekko, provider of an open-source, composable AI stack, the current AI platform landscape is reminiscent of low-code and no-code platforms, which promised democratization of software development but often failed to deliver, becoming synonymous with platform lock-in and inflexibility.

“Honestly, it feels familiar,” Shaposhnik says. “We have incredibly powerful AI tools right now, but most of them come bundled as tightly controlled platforms.” This is a risk for AI, he says, because the infrastructure, models, and hardware are tightly coupled. “If those layers are closed, you lose flexibility fast.”

Some abstractions that sit on top of models, like routing and agent frameworks, tend to be tightly coupled and optimized for certain models. Other platforms take the walled garden concept quite literally. Anthropic, for instance, has repeatedly made headlines for blocking access to its Claude models over vague policy violations. The company recently shut off competitor xAI’s use and stonewalled OpenCode, drawing community backlash.

Moves toward increasingly closed systems don’t bode well for an AI economy already built on shaky economics. As Vikram Srivats, head of product experience at WaveMaker, provider of an agentic application development platform, adds, “Given the unit economics of AI tooling and pace of accelerated change to keep up, it seems obvious that some will evolve to more of a closed system to be able to monetize and gain ROI.”

Why openness matters in the AI era

Reliance on proprietary AI platforms can create long-term operational dependencies. As systems become less interoperable, organizations may be forced to standardize on a single stack across data pipelines, models, and decision logic, says the Linux Foundation’s Collier.

“As infrastructure consolidates, enterprises become more exposed when platforms change direction, raise prices, or fall behind technically,” he says. “If you can’t change platforms without re-architecting your AI systems, you’ve already given up too much control.”

“When you build on someone else’s platform, you have to live by their rules and those rules always change,” adds WordPress VIP’s Alvey. “We’ve all seen this before, businesses wasting time and money building to serve Google, Facebook, YouTube, and the App Store, instead of building to serve their customers.”

Platform lock-in can also create direct business risk. As Ainekko’s Shaposhnik says, “It usually shows up as higher costs, fragile systems, and growing risk when it’s time to change direction.”

At Ainekko, an internal group called the AI Plumbers focuses on back-end AI infrastructure like inference, scheduling, memory, and hardware integration. “Their view is simple,” says Shaposhnik. “If those layers are closed, everything above them becomes fragile.”

Open standards, interfaces, and infrastructure provide a necessary hedge against closed systems to prevent this sort of fragility. “In the AI era, open infrastructure gives enterprises control, portability, and choice at exactly the time they need it most,” says Percona’s Farkas.

It can cost upwards of $100,000 to migrate enterprise software, according to Cloudaware, making portability a major enterprise concern. From this perspective, procuring closed systems can become a costly architectural dependency.

Others argue that openness is a critical hedge against vendor concentration risks at large, especially if AI replaces human labor en masse. “If all of that economic value is now being concentrated in the hands of one or two companies,” says the AAIF’s Surtani, “that’s an order of magnitude bigger problem than we’ve seen in any other wave of computing.”

Instead, open foundations allow adaptability to evolving conditions so enterprises can swap out models, agents, data, hardware, and orchestration, as needed. “Open standards let those components change independently without breaking the system,” says Collier.

Openness can also help future-proof businesses against economic upheaval. “Open everything will help build a cushion for businesses and users to survive and thrive after the almost-certain correction in the current hype cycle,” says WaveMaker’s Srivats.

Momentum toward open AI infrastructure

At the industry level, momentum toward open AI infrastructure is growing. The establishment of the Agentic AI Foundation, Anthropic’s donation of Model Context Protocol (MCP), and Block’s donation of its Goose agent are significant ecosystem-wide moves toward openness. Other advances include the donation of llm-d, a Kubernetes framework for LLM inference, to the Cloud Native Computing Foundation (CNCF).

For Parker, donations like this help ensure long-term support and care. “Open standards aren’t just the foundation of the internet, they’re the foundation of the AI space,” he says. “I predict that we’ll see these practices continue, especially as enterprise adoption increases in earnest,” he adds.

Still, some question whether this level of stewardship is enough for a rapidly evolving ecosystem. “The internet benefited early on from groups that helped keep vendors aligned,” says Shaposhnik. “In AI infrastructure, we don’t really have that yet.”

“All of us open source veterans are hopeful,” he says, “but we also need to adapt to this new reality in what we do regarding AI infrastructure.”

Beyond industry governing bodies, companies themselves are also spearheading open AI initiatives. Warp, an agentic development environment, recently went open source amid closed-source rivals. Arcade.dev, meanwhile, is pushing an open-source Agent Library for agentic memory.

Where openness matters most in the AI stack

While AI infrastructure can be open in many ways, a few layers stand out as especially important. First is the openness of the model itself. “Open-source models must be the foundation of future trust and value,” says WaveMaker’s Srivats.

“The forms of open infrastructure that reduce integration friction and accelerate adoption stand out,” adds Neeraj Abhyankar, VP of data and AI at R Systems, a global digital solutions provider. For him, open model representation formats, open orchestration and execution layers, open agentic protocols, and open governance and metadata standards are all essential for enterprise flexibility.

Others place more value on the connective tissue between AI components. “The most important forms of open infrastructure are the ones that connect systems together,” says Collier. “That includes open APIs, metadata standards, identity and policy frameworks, and protocols for how models and agents communicate.”

Arguably, MCP has become the connective tissue between AI agents and the broader API ecosystem. “If we get MCP right we unlock the same level of interoperability between entities on the web and models driving them as we came to enjoy during the Web 2.0 era and the API-first boom,” says Shaposhnik. “If we don’t we risk massive proprietary lock-ins.”

Parker agrees that open protocols will underlie future AI progress. “We’ll see continued development and progress on AI agents which will rely on protocols like MCP and ACP [Agent Client Protocol] to interoperate with various clients and each other,” he says. Yet a gap remains around API conventions for models. “It would be nice if we could get a commitment from model providers to use a standard here.”

For the AAIF’s Surtani, opening up the protocol layer is the most important aspect. “I think it’s really important for interoperability, for choice,” he says. “It means you can bring your own agent, you can bring your own framework, you can bring your own harness, and pick what model you want.”

Open standards may also play a significant role within inference architecture. “As AI expands to the edge, developers need visibility into how models run, how memory is used, and how performance scales,” says Shaposhnik. Open systems could make it easier to optimize, debug, and adapt while helping enterprises avoid observability fragmentation.

Lastly, cloud-native architectural standards are a key ingredient for open AI infrastructure. “We’re seeing Kubernetes become the missing link for people who want the hyperscaler-style convenience without hyperscaler lock-in,” says Percona’s Farkas. For him, Kubernetes has become the de facto hybrid enterprise deployment option for data, workloads, and AI components.

History repeats itself

The 2026 State of Open Source Report found avoiding vendor lock-in to be the primary driver of open source adoption. But beyond being a strategic decision for a single company, open infrastructure provides a layer for entire industries to be built upon.

Arguably, the internet itself is evidence of this, where groups like the IETF and the IEEE were instrumental in defining the fundamental protocols. “Without open protocols we would’ve been in telco hell and without phenomenons like Google or Facebook,” says Shaposhnik.

Or, take the history of Linux as a parallel. “Linux became the default operating system because it offered a common, vendor-neutral foundation that everyone could build on,” says Collier. “In the AI era, open infrastructure will define the layers that organizations rely on for long-term continuity.”

At the infrastructure level, open standards have repeatedly underpinned major platform shifts, from Docker to Kubernetes. The question now is whether AI will develop a similarly durable standards layer.

For Parker, it’s too early to say, but the current growth of AI mirrors the early cloud. “Remember that it took many years before we saw the development and popularization of the open source cloud-native ecosystem,” he says. “I think it would be a mistake to extrapolate from the current trajectory towards a closed, proprietary future.”

Others agree the future must be rooted in openness. “I see open infrastructure becoming the foundation of enterprise AI,” says R Systems’s Abhyankar. “As systems become more distributed and agent‑driven, closed ecosystems simply won’t scale.”

The groundwork is being laid through open agentic protocols, open frameworks, and industry support intended to reduce fragmentation around proprietary standards.

“Ironically, the AI movement has mostly seemed to learn from the mistakes of the past and is starting off on a more open foot,” says Parker. “Over time, I believe we’ll see innovation and openness thrive.”

Cloud at 20: How AWS shaped enterprise IT

Fri, 19 Jun 2026 18:49:14 +0200

It is tempting to date cloud computing from the launch of Amazon S3 in 2006 and the rise of infrastructure as a service (IaaS) that followed. That was certainly the moment the market changed in a visible, irreversible way. But the truth is that cloud began earlier, in the 1990s, when software as a service (SaaS), application hosting, managed services providers, and various forms of remote subscription computing started to reshape how enterprises thought about owning and operating technology. Even then, the core value proposition was familiar: Let someone else run the infrastructure, abstract the complexity, deliver capability as a service, and allow the business to consume only what it needs.

What AWS changed was the scale, accessibility, and precision of the execution. Amazon turned infrastructure into a programmable utility. It made compute and storage available in ways that were elastic, self-service, API-driven, and globally reachable. That was the breakthrough. Enterprises had outsourced pieces of technology before, but now they could rent raw infrastructure with unprecedented speed and flexibility. The launch of Amazon S3 was especially important because it provided a durable, scalable storage foundation that became one of the building blocks for modern digital business.

AWS changed everything

Technology markets are rarely transformed by the first company to think of an idea. They are transformed by the first company to make that idea operationally real, economically viable, and broadly consumable. AWS did exactly that. It built a model for infrastructure as a service that allowed enterprises, startups, and eventually governments to rethink the entire life cycle of IT delivery.

Looking back from 2026, it is difficult to remember how radical this concept once seemed. At the time, many enterprise leaders considered public cloud too risky, too immature, too uncontrolled, or simply too foreign for conventional IT governance. There were concerns about security, compliance, vendor dependency, performance, data residency, and reliability. Many of those concerns were valid. Early cloud adoption often ran ahead of cloud maturity, and many organizations discovered that moving quickly did not always mean moving wisely.

Still, the economics of agility overwhelmed the inertia of the old model. Provisioning that once took months could be done in minutes. Capital expenditure gave way, at least in part, to operating expenditure. Experimental workloads became easier to justify. Digital businesses could scale without building data centers first. AWS led that transition, and the rest of the industry followed, including competitors that helped mature the market.

Cloud’s strengths and liabilities

If the first decade of cloud was about acceleration, the second decade was about correction. Enterprises learned that cloud was not automatically cheaper, not automatically simpler, and not automatically better. It was better when used with discipline. It was more cost-effective when architected intelligently. It was more resilient when governance, operations, and security were designed into the system rather than added later.

This is when the industry grew up. We learned about cloud financial management because too many organizations assumed elasticity would control cost, only to discover that unused resources, poor workload placement, and fragmented accountability could drive spending far beyond expectations. We learned that public cloud could provide extraordinary innovation and reach, but also that not every workload belongs there. Latency, sovereignty, compliance constraints, legacy integration challenges, and predictable high-volume workloads all forced a more nuanced view.

We also learned about concentration risk. As enterprises standardized on a small number of hyperscalers, questions emerged around resilience, lock-in, and strategic dependency. The answer was never simplistic multicloud posturing for its own sake. It was architectural realism. Use the public cloud where it creates a clear advantage. Keep options open where business risk requires it. Understand portability, but do not romanticize it. In other words, cloud became less ideological and more practical.

Cloud is now an assumption

Perhaps the most important shift of all is that we no longer debate whether cloud is real or whether enterprises should use it. That argument is over. Cloud is baked into the cake. It is part of enterprise operating reality. The modern enterprise assumes on-demand infrastructure, platform services, automation pipelines, managed databases, identity fabrics, observability stacks, and globally distributed application delivery. Even when workloads remain on-premises or at the edge, they are often built, governed, or operated with cloud-native thinking.

This is maturity. Cloud is not a project or a trend. It is not even a strategy by itself. It is an enabling model that now underpins enterprise strategy. Businesses no longer ask whether to adopt cloud in the abstract. They ask how much cloud, which cloud services, under what governance model, at what cost profile, and in support of which business outcomes.

That may sound less exciting than the early days of disruption, but it is actually the mark of success. The most powerful technologies eventually disappear into standard practice. Electricity, networking, virtualization, and mobile platforms all went through this process. Cloud has done the same.

How cloud supports the AI race

As enterprises move aggressively into AI, cloud has entered another pivotal phase. AI is not replacing cloud. It is intensifying the importance of cloud while also changing how value is measured. Training, tuning, deploying, and governing AI systems require immense computational scale, specialized infrastructure, distributed data access, and operational consistency. Public cloud providers are well positioned to offer those capabilities, particularly with GPUs, AI platforms, managed model services, and data integration tools.

But this is not a repeat of the early cloud era. Enterprises are more sober now. They know the importance of cost, latency, and data gravity. They know that governance and accountability matter more in AI than perhaps anywhere else in modern IT. The role of cloud in the AI race is therefore foundational, but not absolute. Some AI workloads will run in public cloud. Some will be distributed across edge computing environments. Some will remain in private environments for reasons of sovereignty, economics, or control. The key is not to force a universal answer. The key is to create an architecture that aligns AI ambitions with operational reality.

Cloud should play the role it has gradually earned: not as a religion, but as a strategic utility. For AI, the cloud is where many enterprises will source scale, experimentation speed, global reach, and managed innovation. The winning organizations understand where cloud creates leverage and where other operating models make more sense.

Changing how enterprises think

The real story of the past 20 years is not just that AWS launched S3 and helped popularize infrastructure as a service. It is that cloud changed enterprise behavior. It normalized service consumption over asset ownership. It moved architecture toward abstraction, automation, and modularity. It forced IT organizations to broker capability rather than build everything from scratch. It redefined speed as a core competitive requirement.

And now, as AI becomes the next forcing function, cloud stands less as a novelty and more as the platform on which the next era will be built. That is a remarkable outcome for something that, in many ways, started with the old idea that computing could be delivered remotely on a subscription basis. We have been heading here for longer than many people realize. In the past two decades, led in large measure by AWS and the broader hyperscale movement it accelerated, cloud has evolved from a gamble to an indispensable foundation.

Hard to believe? Yes. But also inevitable in retrospect.

Solving an ARD problem in AI: Agentic Resource Discovery

Fri, 19 Jun 2026 18:49:08 +0200

Enterprises implementing agentic AI face a challenge: Which tools should they allow their agents to use, where can they be found, and how can they be used safely? A new protocol, Agentic Resource Discovery, or ARD, aims to let agents answer those questions for themselves. Behind it are Google, Microsoft, Cisco, Nvidia, Salesforce and others.

ARD aims to standardize the way that tools and services are shared across systems within a corporate domain. For example, when investigating a production problem, an agent may want to query engineering documentation and open support tickets, deployment history and observability systems, all of which could be managed by different registries and across different silos. There is no common layer that pulls them together. ARD has been designed to be that layer.

It operates across two levels. Catalogs and Registries. In the first, an organization publishes a catalog setting out its available capabilities. The Registries layer act as a form of search engine, crawling those published catalogs.

The ARD specification is available now. Organizations are invited to publish their own catalogs using the quickstart guide. After this, they are able to join the community and participate in the evolution of ARD.

Fine-tuning forgets. RAG leaks context. Hypernetworks build the model your agent needs on demand.

Fri, 19 Jun 2026 18:48:14 +0200

Enterprise teams keep watching the same thing happen. An AI agent demos beautifully, goes to production, and stalls: it runs for a short stretch, then needs a human to top up its context and check its output, and the promised efficiency drains into supervision. The agent did the work; you did the watching. It’s one reason so many agent pilots never turn into production systems.

The pitch on the other side of that wall is the one every team wants to believe: an agent that runs a long job on its own, overnight if it has to, and leaves a person to validate only the last 10%. Whether that is achievable turns on a problem the orchestration conversation mostly skips. When AI firm Chroma tested 18 leading models, every one lost accuracy as its input grew, a property of how attention works, not a gap a stronger model closes. An agent fed more and more of your business as it runs does not get steadier. It gets shakier.

This is the layer beneath the orchestration race. Routing, durable execution and observability all assume each agent is already competent enough to coordinate in the first place. The deeper question is how long an agent can run before a human has to step in, and that comes down to where your company's knowledge lives relative to the model. Both standard fixes leave a human in the loop.

Why teaching a model your business keeps you in the loop

Frontier models keep getting more capable, and the gap does not close, because it is not a capability problem. It is about where your knowledge sits relative to the model, and enterprises have had two ways to place it there.

The first is fine-tuning, which bakes knowledge into the weights. It remains subject to catastrophic forgetting, a problem identified in the 1980s and still unresolved in 2026: teaching a model something new tends to erode what it already knew. Teams work around it by isolating each task in its own fine-tuned model or adapter, which produces a sprawling estate of models that raises cost and governance overhead. And a fine-tuned model is a snapshot, stale the day a policy changes, when the expensive, slow retraining cycle starts over.

The second is in-context learning, which skips retraining by placing the relevant policies in the prompt at run time. This is where context rot bites. Retrieval narrows what goes into the prompt, but a retrieval miss looks identical to a confident answer, and both cost and latency climb with every token added.

The two failures rhyme. With fine-tuning, the model can be confidently working from last quarter's policy. With in-context learning, it can be confidently working from a detail it lost in the middle of a long prompt. Either way the output looks equally assured, so you cannot tell which parts are wrong without checking all of them. That is why the human never gets to leave. Some teams often run both at once, fine-tuning the stable knowledge and retrieving the rest. That softens each failure but removes neither: on any given output you still cannot be sure the model is both current and working from the right context, so you still check it.

A third path: generate the specialist model on demand

A third approach is moving from research into early product. Instead of retraining one model or stuffing its prompt, a generator builds a small, task-specific model on demand from your policies, at inference time. The generator is a hypernetwork: a network whose output is the weights of another network.

The idea was named in 2016; applying it to produce specialist language models from text or documents is recent and active. Sakana AI's Text-to-LoRA, presented at ICML 2025, generates a model adapter from a plain-language description in a single pass, and a 2026 system called SHINE calls hypernetwork adaptation a promising new frontier, precisely because it sidesteps both the retraining cost of fine-tuning and the context limits of prompting.

The point of generating adapters rather than training and storing them is to collapse a sprawling library of per-task LoRAs into one network that can produce them on demand, including for tasks it has not seen.

The elegant part is how this closes the loop on the problem above: the per-task adapter teams hand-build to dodge catastrophic forgetting is the same object a hypernetwork produces automatically. The model zoo stops being a governance headache and becomes a generated output.

The case for going small underneath all this was put most directly in a 2025 paper by Nvidia researchers: for the narrow, repetitive tasks that fill agent workflows, small models are capable enough and 10 to 30 times cheaper to run than frontier generalists. Nace.AI, a Palo Alto company that raised a $21.5 million seed round in May, is the clearest commercial instance. Its core technology, a generator it calls a MetaModel, produces parameter adaptations for a model at inference time from a company's policies, pointed at regulated work: audit, compliance, risk assessment. The company says its agents handle the bulk of a workflow while human experts validate the result, a split it markets as 90/10.

How the three approaches compare

	Fine-tuning	In-context / RAG	Hypernetwork-generated model
Where business knowledge lives	In the model's weights	In the prompt, re-supplied each run	In on-demand generated weights
Cost to update on a policy change	High: retrain	Low: edit the source	Low: regenerate
Staleness	High: a snapshot	Low	Low: regenerated from current policy
Per-call cost and latency	Low	High, grows with context	Low at run time
Dominant failure mode	Forgetting; model-zoo sprawl	Context rot; silent retrieval misses	Generator quality; calibration
Who owns the improving asset	Whoever trains the model	Whoever holds the data store	Depends where generator and feedback live

Why a hypernetwork-built model raises the autonomy ceiling

A model that is narrow, current and small has a smaller surface on which to be wrong. Fewer errors, confined to a known domain, mean fewer outputs an agent has to escalate to a person, which is the real basis for any high-autonomy claim. It is also where a number like 90/10 comes from: not a dial set in advance, but an outcome of how little the system needs to hand back. Reported autonomy shares are best read as measurements of an architecture, not as settings.

Two design choices decide whether that autonomy is trustworthy or merely fast. The first is grounding: tying every output to its source so a reviewer can verify rather than redo. Research models built for exactly this, such as HalluGuard, label each claim as supported or not and cite the passage they relied on. Nace ships its agents with grounding models and reasoning traces for the same reason. A 10% review only means something if the human can confirm provenance in seconds.

The second is the feedback loop, and it forces a question every buyer should ask: when your experts validate the output, whose model improves, and where does it live? That decides whether the compounding asset belongs to the vendor or to you. Arrangements differ. Nace, for instance, uses an external network of certified experts for some engagements and, for direct enterprise deployments, the customer's own staff, with the resulting model kept inside the customer's cloud. Each choice routes the learning, and the ownership, somewhere different.

Where the third path breaks

The approach is still early, and a few questions will decide how far it goes. Calibration is the linchpin: the value rests on the model knowing when it is unsure. And it is genuinely unsettled, recent work generating these adapters found they do not automatically improve calibration over ordinary fine-tuning, with gains appearing only under specific constraints.

The quality of the generated model also depends heavily on the policy data it is built from, which puts a premium on data curation. And scale is the open research frontier, the hypernetworks shown in published work so far have been small. This is where Nace's own work gets interesting: in our interview, the company said it has scaled its generator well beyond those published sizes and derived a scaling law for how performance grows, results it has begun to share publicly and is now putting through peer review. If it holds up, it would help answer one of the central open questions in the field, and it is the paper worth watching.

Whichever approach wins, the work still ends at a human, and that handoff is its own design problem. When Deloitte Australia delivered a roughly A$440,000 government report, it shipped with fabricated citations and an invented court quote after passing senior review, because the reviewers checked the conclusions, which were sound, and not the provenance, which was not. Controlled research suggests the pattern is general: experts corrected an identical flawed recommendation less often when it was labeled AI-generated.

The EU AI Act's Article 14 now names this automation bias. The lesson is not about any one vendor: a high autonomy share concentrates human attention into a thin, late slice of the work, so the value of that review depends entirely on whether the human can check provenance fast, which loops back to grounding.

What to build, and what to ask before you buy

The honest takeaway: what holds your agents back is usually not orchestration or model size, but whether the model knows your business well enough to be left alone, and the right fix depends on the job. To automate a long, repetitive, high-volume process end to end, run most of your internal audit overnight and have your own experts check the final slice, a hypernetwork generated model is the approach most likely to do it cheaply and run long enough to matter. For a short task that finishes in a few steps and never needed to run unattended, the gap between this and a well-prompted frontier model shrinks to almost nothing, and is not worth the integration cost.

When a vendor pitches autonomous or specialist agents, four questions cut through it.

Where does the business knowledge live: in the weights, the prompt, or generated on demand?
What does each output come with, so a reviewer can verify it instead of redoing it?
What decides which work gets escalated to a human?
And whose model improves from that feedback, and where does it run?

The answers, not the headline ratio, tell you what you are buying.

The hypernetwork approach is the most credible attempt yet at making a small model know a specific business without forgetting it and without re-explaining it on every run. It is also the least proven, and the parts that matter most, calibration and scale, are still in peer review. For the right job, pilot it now. For the wrong one, the integration cost buys you little that a well-prompted frontier model wouldn't.

Solving an ARD problem in AI: Agentic Resource Discovery

Fri, 19 Jun 2026 18:48:05 +0200

This article first appeared on InfoWorld.

Solving an ARD problem in AI: Agentic Resource Discovery

Fri, 19 Jun 2026 18:48:02 +0200

This article first appeared on InfoWorld.

Monitor and debug generative AI inference with SageMaker detailed metrics and Insights dashboard on CloudWatch

Fri, 19 Jun 2026 01:33:38 +0200

Amazon SageMaker AI provides fully managed real-time inference hosting for machine learning models. You deploy a model to a SageMaker endpoint backed by one or more compute instances, and SageMaker handles provisioning and scaling. SageMaker supports multiple endpoint architectures. This post focuses on the two most relevant to generative AI workloads with detailed observability: Single-model endpoints (SME) and Inference component (IC) endpoints.

Databricks targets AI operations bottlenecks with ZeroOps

Thu, 18 Jun 2026 14:18:57 +0200

Databricks is pitching a fix for what it sees as the growing operations mess in enterprise AI. With the launch of Genie ZeroOps, unveiled at its Data + AI Summit, the company is targeting a problem many data teams know too well: it’s no longer building pipelines and models that hurts, it’s keeping them running.

As data estates sprawl and AI workloads multiply, engineering time is increasingly eaten up by maintenance. Meanwhile, AI coding tools are accelerating development, churning out even more assets that need oversight, widening the gap between how fast teams can build and how much they have to manage.

Databricks Genie ZeroOps is a new agentic operations capability that is designed to automate the monitoring, investigation, and remediation of issues across data and AI workloads.

Currently in private preview, ZeroOps uses an AI agent to identify anomalies, trace root causes using metadata and lineage information via Unity Catalog, generate proposed fixes, and then test those fixes in an isolated environment before pushing them out for human review to be applied in production.

Targeting real operational complexity?

Genie ZeroOps addresses a legitimate enterprise challenge around operational complexity, particularly the growing burden of maintaining data and AI workloads in production, analysts say.

“Most data teams spend more time keeping pipelines and models alive than building new ones,” said Amit Chandak, chief analytics officer at IT consulting firm Kanerika.

Echoing Chandak, independent consultant David Linthicum said enterprises continue to grapple with deployment drift, incident response, compliance checks, and root-cause analysis across increasingly fragmented data and AI estates.

Those challenges, echoed Victor Coimbra, CTO of IT consulting firm Artefact, are compounded by the emergence of agentic coding tools that accelerate the development of assets, such as machine learning pipelines and models that need “babysitting.”

That maintenance burden carries a significant productivity cost, said Robert Kramer, managing partner at KramerERP, noting that activities such as managing infrastructure, deployment environments, support processes, and operational workflows consume time without directly creating business value.

Those productivity drains, according to Coimbra, have proven difficult to eliminate despite the emergence and widespread adoption of automated observability and governance tools.

“What is different here is the agentic piece. Databricks is trying to move from tools that alert humans to systems that diagnose issues, propose fixes, and validate them in a governed environment without breaking anything in production,” echoed Stephanie Walter, practice leader of AI stack at HyperFRAME Research.

Shifting the role of platform teams

That shift, according to analysts, could change the way most enterprise platforms and development teams work currently.

“Skilled engineers spend the majority of their time on toil. If the ZeroOps agent, in the background, handles monitoring, investigation, and fix-proposal, engineers shift from doing the operational work to reviewing it. The traditional split between ‘people who build’ and ‘people who keep things running’ starts to blur,” said Ashish Chaturvedi, leader of executive research at HFS Research.

“Additionally, this would also mean that platform teams (engineers responsible for maintenance) can focus on genuinely novel failures rather than the repetitive ones,” Chaturvedi added.

The shift, according to Coimbra, could also affect how enterprises scale platform teams: “They can stop hiring operations staff in lockstep with every new pipeline. The same team can cover a lot more.”

Given that the capability is still in preview, Kanerika’s Chandak pointed out that the headcount reduction claims may be overstated.

ZeroOps could instead pose the risk of “skill atrophy,” Chandak said.

“If engineers stop debugging because the agent does it, the team’s ability to handle the cases the agent cannot handle becomes a real exposure,” Coimbra added.

What ZeroOps could mean for CIOs

Genie ZeroOps could be attractive to CIOs because it links innovation capacity with operational discipline rather than forcing a tradeoff between the two, Linthicum said.

“The appeal is straightforward: reduce operational drag, shorten deployment cycles, improve service resilience, and enforce governance without scaling headcount at the same rate as workloads,” Linthicum said.

That combination of efficiency and reliability could help CIOs rein in one of the biggest costs associated with operating data and AI environments, Chaturvedi said. “ZeroOps attacks time spent on maintenance. CIOs have watched their data engineering budgets balloon while the proportion of that spend going to net-new value shrinks.”

Linthicum warned that CIOs should consider the new offering with calculated skepticism and seek metrics to validate Databricks’ claims.

“The headline metrics are mean time to detect and mean time to resolve, plus the share of incidents the agent closes without a human stepping in. Those tell you whether it is actually removing the operational complexities that it promises,” Kanerika’s Chandak echoed.

“Underneath these metrics, CIOs should track the accuracy of their root cause calls, the false positive rate on proposed fixes, and the proportion of fixes engineers approve without editing, because that last number is the real trust signal. On cost, they should measure cost per incident handled against the human baseline, net of agent compute,” Chandak added.

That scrutiny, Chandak further added, is even more important for CIOs because Databricks is entering an emerging category.

“Most vendor agent announcements target the build and use layers, helping people write code or ask questions of their data. ZeroOps targets the operate layer, which is less crowded,” Chandak said.

ENDS

The role of CSPs in natural disaster recovery

Thu, 18 Jun 2026 13:05:47 +0200

How AI integration and real-time observability are critical in emergency response scenarios.

Why agentic architecture is still so puzzling

Thu, 18 Jun 2026 12:18:55 +0200

Many IT leaders looking to capitalize on the promise of agentic AI still struggle with a basic step — building out their agentic architecture — even as they roll out dozens or hundreds of agents.

AI agent deployment is expected to skyrocket over the next year, with IDC predicting a tenfold increase in agent use by large enterprises by the end of this year. But in some cases, CIOs haven’t focused on the building blocks needed to run a huge team of agents, experts say.

Many CIOs have underestimated the infrastructure work required to get agents to scale responsibly, says Hilary Packer, EVP and head of enterprise data and AI at American Express.

“There’s a tendency to focus on what an agent can do and then move quickly to deployment before the underlying infrastructure is in place,” she says. “It is essential to first build the enterprise capabilities that allow agents to operate consistently across systems, data sources, and workflows.”

IT leaders must also set up well-governed data foundations, but many companies still operate with fragmented systems, inconsistent data definitions, and siloed ownership structures, Packer adds.

“Before deploying increasingly sophisticated models and agents, organizations need confidence that the underlying data is accurate, accessible, and fit for purpose,” she says. “That requires investments in governance, lineage, and modern data infrastructure that allows information to move efficiently across the enterprise.”

More than an IT challenge

Packer sees agentic AI as much a governance and operating model challenge as a technology challenge. In some cases, IT teams are reinventing the wheel with each agent pilot, she suggests.

“As organizations experiment, teams often end up rebuilding the same capabilities repeatedly — for example, identity management, access controls, monitoring, and observability,” she says. “That may be sufficient for isolated pilots, but it becomes difficult to manage and scale across the enterprise.”

What agentic architecture really requires

CIOs need to take a wholistic approach to agentic architecture. While some IT leaders think of architecture as the AI model powering agents, it goes much deeper.

Agentic architecture includes several elements, and in some cases, CIOs have underinvested in some functionality, says Saurabh Pitkar, director of product management for agentic commerce at Dell Technologies.

Agentic architecture, Pitkar says, includes an orchestrator, the brain that controls subagents; subagents themselves, which have specialized functions; APIs and other tools; memory to maintain context of an agent session and overall behavior over a longer period; and guardrails to set boundaries for agents

Many organizations are now building agentic architecture, but those still struggling have failed to make the right investments in areas such as building memory and creating MCP tool standardizations, Pitkar says.

A lack of data access and integration can be a huge barrier to agent deployments despite heavy investments in data modernization, he adds.

In addition, IT leaders struggling to deploy agents have often failed to manage organizational changes to account for a faster, agent-driven delivery cycle, he says. Adoption can slow down considerably if teams aren’t ready to engage with agent-speed outputs.

“AI does not care about org structure when it comes to accessing data,” he says.

Use cases determine the details

While the elements of agentic architecture are fairly standard, CIOs may need to focus more on different functionality depending on the use case, according to Pitkar. The devil is in the details.

“Customer support may need higher investments in dynamic intent mappings, memory, effective UX as these are emotionally charged conversations with human users who need a problem solved to continue their job,” Pitkar adds. “Agentic commerce may focus on deterministic APIs with machine readable data, guardrails, and compliance to securely process transactions with real money.”

Another way to look at agentic architecture is to think about four layers:

System of context, including unified, semantically enriched data
System of work, or composable application services agents can act on
System of agency, where planning, coordination, and governance live
System of engagement, the interfaces that enable agents to interact with employees and customers

Most organizations have these four functions happening in other enterprise software packages, but they are built for human-paced orchestration instead of machine-speed agents, says Shibani Ahuja, SVP for enterprise IT strategy at Salesforce.

“Agentic architecture is the enterprise foundation that allows AI agents to autonomously reason and act — not just respond — in a way that’s governed and secure,” she says. “It’s the difference between an AI that drafts an email and an AI that closes tickets, triggers payments, and updates records, without waiting for a human to pass the baton.”

Ahuja sees organizations struggling to even define agentic architecture, much less deploy it. Throughout 2025, she heard CIOs describing how they implemented AI on a scale.

“If you listened carefully, one was describing predictive AI, one generative AI, and one an agentic workflow that was really just a sophisticated chatbot,” she says. “We were using the same word for fundamentally different things. When the ROI didn’t materialize, organizations didn’t know what had actually failed.”

Agent deployment struggles, meanwhile, have been less about capability and more about where organizations focus their energy, Ahuja says. Many IT leaders focus on the agent, including the use case, the prompt, and the model, but it’s just as important to ask whether the organization’s architecture actually supports its agentic goals, she adds.

“Can agents access real-time, governed data across your entire business?” she says. “Can they act across systems with minimal human input to reconcile inconsistencies? In most enterprises, the honest answer is not yet, and no amount of prompt tuning fixes that.”

Setup is only the first step

It’s now trivial to set up an agent, with most organizations able to do it in days, if not hours. But the work doesn’t stop there, says Adam Field, chief AI officer at workflow automation provider Tungsten Automation.

Good agentic architecture allows agents to operate reliably inside real business processes, not just in isolation, he says. For the past 30 years, enterprise systems were built for humans to navigate UIs, but agents work silently on the inside by calling APIs and requiring action-level permissions rather than login access.

The underestimated piece of agentic architecture is the governance controls that define what agents can do autonomously and when they must stop and hand off control to a human, Field says.

“Deploying an agent on a discrete task is straightforward,” he adds. “The hard part is that businesses don’t run on discrete tasks.”

Instead, enterprises operate on end-to-end, regulated processes with exceptions, dependencies, compliance requirements, and humans in the loop at specific moments, he notes.

“Designing agentic architecture that works across an entire process, not just a single step, is a fundamentally different challenge,” Field adds. “Traditional software fails obviously. Agents fail silently, confidently, at scale.”

Why AI coding debt is different

Thu, 18 Jun 2026 11:18:48 +0200

In hardware, when you ship something broken, the consequences are severe and often irreversible. That’s the world I worked in for years, in verification roles at Mellanox and later at Alibaba. The stakes forced the industry to build a rigorous verification culture. You proved designs worked before they left the building.

In software, verification disciplines look like CI/CD pipelines, static analysis, canary deployments, and observability. But those systems were built around code written at human speed, with human comprehension baked into the process. AI code generation has broken that assumption. The writing process can no longer be trusted to carry institutional knowledge and judgment into the codebase. The industry is being pushed toward the kind of rigorous verification culture that hardware engineers have practiced for decades.

Enterprises are generating code faster than at any point in history. Google recently disclosed that 75% of the company’s new code is now AI-generated. Meta has set internal targets requiring most of its engineers to generate the majority of their committed code with AI tools by mid-2026. The velocity gains are significant. But a growing body of evidence suggests the industry is accumulating a new form of technical debt, one that is less visible than the traditional kind and harder to unwind. It’s also preventable, and the organizations that get ahead of it will have a meaningful advantage over those that don’t.

Understand what makes this debt different

The standard narrative frames this as AI writing bad code. That’s not quite right. The more precise problem is cognitive debt: the loss of understanding of how and why software was built the way it was.

When a human writes code, something else happens alongside the typing. They simulate edge cases, reason through dependencies, and make judgment calls grounded in organizational context, including the business requirements behind a feature, the best practices the team has established, and the reasoning behind past architectural choices. That cognitive loop is how institutional knowledge gets built. When AI writes the code, you can get output that is syntactically correct, passes CI, ships cleanly, and leaves no one holding the mental model. The code works until something changes or breaks, and then the team is excavating a black box.

This is distinct from traditional technical debt, which is messy code. Cognitive debt is invisible code that functions but that nobody truly owns. And it compounds faster, because the same velocity that makes AI generation attractive is what prevents anyone from stopping to build the understanding that maintainability requires.

GitClear’s analysis of 211 million changed lines of code across major repositories found that during 2024, duplicate code blocks of five or more lines increased eightfold, while refactoring dropped from 25% to under 10% of all code changes. Refactoring is the slow, unglamorous work that keeps codebases healthy, and developers are doing far less of it. Google’s 2024 DORA report found that a 25% increase in AI adoption correlates with a 7.2% decrease in delivery stability. DORA analysts note that the root cause isn’t flawed code per se; AI inflates batch sizes, and larger changesets have always been riskier to ship.

These findings aren’t indictments of AI-assisted development. They’re diagnostics, and they point toward a specific set of fixes.

Close the context gap first

In a survey of 609 developers we conducted last year, 65% said AI misses relevant context during critical tasks like refactoring, writing tests, or reviewing code. Context is the primary driver of AI code quality, and it’s where most enterprise organizations are underinvesting.

When an AI tool generates code without access to your organization’s architectural decisions, historical pull requests, security policies, or existing module patterns, you get solutions that are locally correct but globally incoherent. Closing that gap requires context engineering: ensuring the tools and agents you use have access, at the right moment, to the right organizational knowledge, and the judgment to determine what is actually relevant for a given task. A retrieval system that surfaces too much irrelevant context can degrade output quality as readily as one that surfaces too little. The specific tooling matters less than the discipline. Context infrastructure needs to be actively maintained, not indexed once and forgotten.

Build this infrastructure before you scale AI generation. Retrofitting is significantly harder. Treat it the way you treat your CI pipeline, as a prerequisite for safe production deployment.

Consider what happens when a team has built this context infrastructure well. Their code review tooling knows about a deprecated internal API, because that deprecation decision lives in months of past pull request discussions that have been indexed and surfaced. When generated code references the old API, the review flags it. Without that context layer, the same mistake gets waved through every time. That’s the kind of institutional knowledge that evaporates when humans stop writing every line of code, and that you have to actively work to preserve.

Build a verification layer that matches your generation velocity

Almost all of the investment in AI-assisted development has gone into generation. Very little has gone into verification. That imbalance is where the tech debt accumulates.

I think of these as the blue team and the red team. The blue team covers code generation, autocomplete, and agentic coding. It’s getting the headlines, the budgets, and the product launches. The red team covers integrity checks, behavior coverage, and alignment with organizational standards. In most organizations, it’s an afterthought. A CI pipeline catches obvious failures. A code review might happen, but reviewers are overwhelmed by the volume of AI-generated output and cannot meaningfully evaluate all of it. The result is code with a veneer of having been reviewed without anyone having actually understood it.

The Crowdstrike outage of 2024 is worth keeping in mind here. AI didn’t generate the problematic code, but the incident illustrated what happens when a single software error propagates through production systems without sufficient verification. That exposure multiplies when code is being generated faster than humans can understand it.

A real verification layer means automated analysis that evaluates whether generated code aligns with your organization’s best practices, architectural standards, and compliance requirements. It means test coverage that reflects intended behavior, not only the happy path the AI chose to generate tests for. And it means traceability: a connection between the requirement and the implementation, so that six months from now, someone can understand what the code does and why it exists.

The numbers support investment here. In the same developer survey, teams that integrated AI into their code review workflow saw quality improvements in 81% of cases, compared to 55% for comparable teams without it.

Make ownership non-negotiable

Every piece of AI-generated code in production needs an accountable human who understands it well enough to maintain it. This is harder than it sounds, and it’s where most organizations are falling short.

The same velocity that makes AI generation attractive also creates pressure to skip the slow work of genuine comprehension. A developer reviews a 500-line pull request that an AI generated in three minutes and faces a real choice: spend two hours actually understanding it, or approve it because it looks right, passes the test, and “LGTM” (looks good to me).

Real ownership means slowing down generation velocity enough to allow for meaningful review, and being explicit with your team that this is the right trade-off. When that doesn’t happen, you’ve started building your next legacy system.

What to do this quarter

The good news is that none of this requires a multi-year transformation. The structural problems are real, but they have concrete solutions, and engineering leaders can make meaningful progress on all three fronts without waiting for the next budget cycle.

Audit your context infrastructure. If your AI tools are generating code without access to your organization’s architectural decisions, deprecated APIs, and security policies, fix that before expanding generation velocity further. The quality of context determines the quality of output.
Invest in the red team. Establish an automated code quality and governance layer that evaluates generated code against your specific organizational standards, beyond functional correctness. This is a distinct investment from your code generation tooling and needs to be treated as such.
Establish ownership explicitly. Every AI-generated feature in production should have a human owner who genuinely understands it. Make that a formal requirement.

The organizations that get this right will find that AI generation becomes far more reliable once it has a verification layer underneath it. The ones that don’t will keep shipping faster while understanding their systems less, until the accumulated debt forces a reckoning. That’s a solvable problem. The question is whether you solve it now or later.

—

Cisco: AI growth is exposing campus network limits

Wed, 17 Jun 2026 23:53:06 +0200

While enterprise IT leaders have spent the past two years focusing AI infrastructure discussions on GPUs, cloud platforms, and data centers, new Cisco research suggests that enterprise networks may not be ready for the next phase of AI adoption.

A Cisco and Foundry survey of 3,472 IT and networking leaders across 15 countries found AI is already changing traffic patterns across campus and branch environments and exposing capacity, security, and visibility gaps that many organizations aren’t prepared to address.

“We have entered a networking supercycle, because the network is so central to all the AI infrastructure the world is building now,” said Jeetu Patel, Cisco president and chief product officer, in a statement.

The findings reveal that enterprises may need to expand AI readiness planning beyond data centers and cloud environments and pay more attention to the networks connecting employees, applications, and devices. This issue will become more significant as enterprise organizations move beyond generative AI pilots and begin deploying AI agents that communicate continuously with other systems and applications, according to the report.

The Cisco survey found:

Organizations reported a 34% increase in AI-related campus and branch network traffic over the past 12 months.
Traffic is projected to climb 209% over the next three years, with companies broadly deploying AI expecting total network traffic to triple.
73% already face, or expect to face, campus and branch network capacity constraints within the next two years.
67% said AI workloads are increasing east-west traffic between internal systems and applications.
80% said AI has expanded their attack surface.
61% said they are delaying additional AI deployments until they gain more confidence in their security posture.
85% expect moderate or significant growth in AI agent deployments over the next two years.

Changing traffic patterns inside enterprise environments are causing additional pressure for enterprise network teams. (See also: AI traffic is radically reshaping WANs)

“Usually, networks are designed for consistent traffic, like SaaS and CRM traffic, and there aren’t a lot of unpredictable traffic patterns,” said the head of AI strategy for global IT and network engineering operations at a large U.S. technology company who participated in the research. “Suddenly, three AI agents are trying to talk to each other and solve a problem. That is going to be a big thing … how do we support increased east-west traffic?”

Cisco defined aggressive AI adopters as organizations with broad generative AI deployments across the enterprise, but only 30% of those organizations said they are fully prepared to support projected AI growth across their networks. As a result, 93% of IT decision makers said they are accelerating network modernization efforts.

The report also highlighted an observability challenge that could complicate future deployments. As employees and business units increasingly experiment with AI tools, IT organizations may not know what is actually running on their networks.

“Right now, we don’t even know what the AI-driven demand is,” the AI strategy executive said. “Observability is a huge gap. There is experimentation going on all over the place, and there is no way for us to really identify if somebody is deploying some kind of service on our network, whether it is a genAI solution or an agentic solution.”

Security is also emerging as a barrier to AI expansion as organizations struggle to govern rapidly growing numbers of AI tools and workloads.

“The issue from a security standpoint is that it’s hard to create the guardrails for every possible AI tool that your organization must use,” said the vice president of infrastructure, network, and end-user services at a U.S. retail enterprise interviewed for the report.

The AI readiness conversation has often centered on data centers, but AI applications operate where employees work, devices connect, and business processes run. That means campus and branch environments may become just as important to AI success as the infrastructure supporting AI models.

The Cisco research shows that AI infrastructure planning can no longer focus only on back-end systems if enterprises expect to scale AI deployments over the next several years. Patel said in the statement: “Eventually there will be only two kinds of companies: those that are AI companies, and those that are irrelevant.”

For more Cisco news, see our coverage from Cisco Live 2026:

HPE CTO Russo drills into data, orchestration, and observability for the agentic enterprise

Wed, 17 Jun 2026 23:23:07 +0200

HPE CTO Fidelma Russo took to the main stage at HPE Discover 2026 in Las Vegas to detail a set of product announcements focused on governing data, orchestrating infrastructure, and operating AI agents in production. Where CEO Antonio Neri’s day-one keynote covered the portfolio architecture across networking, compute, and storage, Russo’s session went deeper on the software and operations layer that sits on top of that infrastructure.

Russo framed all of it around a single operational shift: Enterprises have moved from static workflows and human decision-making to distributed intelligence operating across fragmented infrastructure. The products she announced address what it takes to govern and operate that intelligence once it is in production. Key announcements include:

HPE Data Fabric 8.2 with agent-aware capabilities
HPE Morpheus 9 with federated multi-site management and integrated software-defined networking
HPE OpsRamp Operations Copilot for AI factory observability
New partnership with ServiceNow connecting GreenLake Intelligence with autonomous service delivery

“The question is no longer whether AI will transform the enterprise,” Russo said. “The question is, how do we make that transformation secure, governed, scalable, and operational?”

Data Fabric as the trusted layer for AI

Russo reiterated the now-familiar mantra that every AI strategy requires a data strategy, but argued that in an agentic world, data becomes part of the operational engine, not just an input. Agentic AI, she said, doesn’t simply retrieve information once, it continuously accesses data throughout the lifecycle of a task. That puts pressure on organizations to make data discoverable, governed, secured, and accessible wherever those agents operate.

To help solve that challenge, Russo announced HPE Data Fabric 8.2, with agent-aware capabilities; an enhanced global data catalog; and an appliance option aimed at simplifying deployment and reducing time-to-value.

“Before AI can act on that data, data must be discoverable, it must be governed, it must be secured, and it must be accessible wherever those agents operate,” Russo said.

HPE Morpheus 9: Central control plane for hybrid and AI infrastructure

Russo also used her keynote to announce HPE Morpheus 9. Part of the new HPE CloudOps Software Suite, Morpheus handles runtime orchestration and automation for traditional virtualization, container platforms, and AI workloads.

With version 9, HPE is introducing Morpheus Central, a federated multi-site management layer delivered as a GreenLake cloud service, with an air‑gapped on‑premises option. Morpheus Central provides a single operational view across multiple Morpheus deployments spanning data centers, regions, and cloud providers. From one console, operators can see:

Fleet health (healthy, warning, and critical appliances)
Software currency and version drift across sites
Cost and license utilization for the entire estate

Morpheus 9 also adds integrated software-defined networking (SDN) based on Juniper technology, bringing policy, security, and micro‑segmentation into the same platform. HPE is pitching these capabilities as transforming Morpheus from a provisioning tool into a true enterprise control plane for hybrid infrastructure, including AI workloads.

“This is our most advanced platform for operating modern and traditional infrastructure, as well as AI workloads,” Russo said.

Distributed agentic enterprises

HPE is extending its AI strategy beyond infrastructure into daily IT operations with an expansion of HPE GreenLake Intelligence, built around an agentic mesh and a growing family of copilots. At the core is a centralized agent registry and planning service that assigns identity, governance, and policy controls to AI agents, then coordinates which specialized agents should work together to deliver a requested outcome.

“Intelligence, which is usually trapped in products, has to move across and beyond individual products,” Russo said.

On top of this framework, HPE is rolling out multiple copilots aimed at making complex hybrid environments more manageable. A compute copilot is designed to help teams operate server infrastructure more intelligently, while a Morpheus orchestration copilot lets operators automate infrastructure using natural language. The flagship for observability is the OpsRamp Operations Copilot, which sits on GreenLake Intelligence and lets operators interact with their environment conversationally instead of hunting through dashboards, tickets, and logs. It uses frontier-scale models to reason across signals from infrastructure, applications, networks, AI services, and operations tools, surfacing related incidents, context, and recommended remediation in a single conversational view.

“Data powers intelligence, intelligence powers AI, and intelligence helps us operate it all,” Russo said. “We are now entering an era where people, systems, and agents are working together at a scale we’ve never seen before, and to do that successfully, organizations need three things: a trusted data layer, a platform for an agentic era, and intelligence embedded in day-to-day operations.”

Turn enterprise AI into real business value with a secure, scalable factory

Wed, 17 Jun 2026 19:37:50 +0200

Building an enterprise AI factory is a complex endeavor that few organizations can tackle alone. The solution requires infrastructure capable of managing massive compute workloads generated by AI training and inferencing, high-capacity/low-latency networking within data centers and to the edge, and security to mitigate the risks that AI introduces.

Abhinav Joshi, leader of AI solutions and product marketing at Cisco, identifies three key challenges inherent in building enterprise AI infrastructure: deployment complexity, security vulnerabilities, and performance bottlenecks. Agentic AI, with its heavy reliance on inferencing, places greater demands on infrastructure across all three dimensions.

3 challenges in building enterprise AI factories

The deployment complexity challenge is driven by the need to quickly operationalize an AI infrastructure that fully integrates compute, networking, storage, security, and observability. A Kubernetes-based container management platform and a robust AI software toolchain are likewise essential to ensure the consistent development, testing, and deployment of containerized AI applications, Joshi says.

The second challenge is mitigating security vulnerabilities. “Many organizations lack integrated security measures to protect the AI models, frameworks, applications, and the supporting infrastructure throughout the stack,” Joshi says. Attackers can exploit vulnerabilities by manipulating large language models (LLMs) with malicious inputs, which can disrupt operations and extract sensitive information. As AI agents ingest diverse data and act independently, they introduce new attack surfaces, including prompt injection, model poisoning, and data leaks.

Performance, especially around networking, is the third challenge. Tasks such as pre-training, post-training, and fine-tuning AI models, along with retrieval-augmented generation (RAG) pipelines and inferencing (including reasoning and agentic) all generate enormous amounts of network traffic. This creates severe bottlenecks across three critical communication paths: high-speed interconnects between graphics processing unit (GPU) servers, data throughput to storage layers, and real-time response delivery to end users.

Without high-performance network connections, GPUs may be underutilized and jobs may take longer to complete, affecting token economics. If bottlenecks reduce infrastructure utilization, organizations may pay more for every useful token generated. High-performance networking helps keep AI workloads moving efficiently as agents retrieve context, coordinate tools, and execute multi-step workflows.

Address all 3 issues at the same time

Cisco and NVIDIA jointly address these challenges with Cisco Secure AI Factory with NVIDIA, a modular reference design for rapid, core-to-edge AI adoption. The solution integrates high-performance compute, networking, and storage infrastructure with Kubernetes and AI software. With built-in security and observability, it ensures resilient AI operations across a variety of AI use cases, enabled by a robust software provider and technology partner ecosystem. The full stack is also pre-validated, reducing deployment risk and accelerating time to value — particularly as enterprises move beyond pilots toward production-scale agentic AI deployments.

The design is modular and compliant with NVIDIA Enterprise Reference Architectures. It provides flexibility for users to choose the components that best meet their immediate needs, with the assurance that they can add capacity later.

Security is embedded at every layer of the full stack, including AI models, applications, and agents to provide protection from the supply chain to runtime. This protection is delivered through Cisco products such as Cisco AI Defense, Cisco Hybrid Mesh Firewall, Cisco Isovalent Runtime Security, and Splunk Enterprise Security.

Tight solution integration also enables quicker response to critical exposures. Cisco’s Live Protect capability puts guardrails around AI jobs, enabling them to keep running despite vulnerability, an important consideration given that jobs like model training can take days to complete.

Another challenge Cisco helps organizations overcome is a lack of in-house IT talent with AI experience. Enterprises can take advantage of professional services from Cisco and its channel partners.

At a recent Cisco Live event, Cisco announced new deployment automation software, Stack Automation by Quali. “It further reduces deployment time from a few days to a few hours for secure AI infrastructure,” Joshi says. “It will help both our own professional services teams and our customers who want to stand up environments on their own.”

Taken together, these offerings reduce the risk of deployment errors, accelerate time to value, and provide a foundation for deploying efficient, secure agents grounded in enterprise context.

As enterprises move from experimentation to production-scale agentic AI, success will depend on more than raw compute. Organizations will need AI factories that securely deliver valuable outcomes while operating efficiently at scale.

Learn how Cisco Secure AI Factory with NVIDIA helps you build a sound foundation for your enterprise AI projects.

Root Cause in unter einer Minute: Wie KI-gestützte Observability fragmentierte Cloud ...

Wed, 17 Jun 2026 13:39:09 +0200

IT-Security · DevOps · Datenbanken · Java. ☰. Entwicklung/Architektur · Betrieb ... Für Security- und Application-Security-Teams ist es zusätzlich ...

Who owns the control plane? Google Cloud Next 2026 and the real contest in agentic AI

Wed, 17 Jun 2026 11:09:08 +0200

I recently spent some time reflecting on the announcements from Google Cloud Next 2026, as well as a series of vendor briefings and a handful of enterprise architecture engagements, where the same question kept coming up across different venues: once an organization has agents, who governs them? For two years, the enterprise AI conversation has been a conversation about models — whose is largest, whose is cheapest, whose context window stretches furthest. Virtually no one was talking about data and semantic context.

After getting some perspective, I was forced to consider that model obsession might have finally fizzled out under the grim reality of non-existent ontologies and limited to no semantic context for enterprise data. The interesting question is no longer which model an enterprise runs. It is who controls the connective context layer — the agentic control plane — that decides what those agents know, what they are allowed to do and who is accountable when a thousand of them are running at once. Whoever owns that layer owns the next decade of enterprise AI and judging by the “marketecture” of every major vendor at Next 2026, the industry has reached the same conclusion.

The urgency here is clearly not a slide-ware exercise. Gartner has reported an exponential surge in enterprise inquiries about multi-agent systems and predicts that 40% of enterprise applications will embed task-specific agents by the end of 2026, up from less than 5% a year earlier. Yet the same analysts deliver an equally important counterweight: Gartner also expects more than 40% of agentic AI projects to be canceled by the end of 2027, citing escalating cost, an expanded risk surface and governance that no one built in advance. The 2026 Gartner Hype Cycle for Agentic AI makes the diagnosis plain — governance, security and FinOps capabilities are proliferating precisely because enterprises are alarmed about accountability and control as agents grow more autonomous and interconnected. Exponential demand colliding with non-existent guardrails is the environment Google walked into. So, what is the path forward to a control plane an enterprise can actually trust?

What Google actually brought to Next 2026

I’m not ardent supporter of single-ecosystem architectures. That’s not the world we live in and interoperability has always prevailed as the final arbiter of truth. Beneath all the agent drama, however, Google’s message was fundamentally architectural. The company repositioned Gemini less as a standalone model and more as the connective and contextual tissue binding data systems, applications and agent runtimes, and assembled Big Query, Alloy DB, Spanner and its managed Spark service into a new category it calls the Agentic Data Cloud. As Constellation Research observed, the standardization of data on Apache Iceberg has put the data layer itself in play, and Google responded by stacking its assets into a cross-cloud lakehouse and a knowledge catalog, complete with migration tooling pointed squarely at Snowflake and Databricks.

Three pillars define the offering. The first is a federated data layer built on the principle of reach, not relocation. By integrating Cross-Cloud Interconnect directly into the data plane and pairing it with the Apache Iceberg REST Catalog, Google lets agents query data residing on AWS or Azure as though it were local, with no egress fees and extends bi-directional federation in preview to Databricks’ Unity Catalog, Snowflake’s Polaris and the AWS Glue Data Catalog, according to Google’s own technical briefings and independent analysis. Google data cloud managing director Yasmeen Ahmad summarized in Google’s Next ’26 announcement with characteristic economy: you don’t move the data, you connect it.

The second pillar is a semantic layer — the Knowledge Catalog, an evolution of Dataplex — which uses Gemini to tag assets, infer relationships and map business meaning so that agents are grounded rather than, as one analysis put it, fast but blind. Critically, its retrieval is permission-aware, meaning agents can only retrieve and act on assets they are explicitly authorized to see — a design choice that fuses context delivery and access control into a single operation. The third pillar is a build layer, the Data Agent Kit, which ships as portable skills, MCP tools and IDE extensions that drop into VS Code, Claude Code, Gemini CLI and Codex, deliberately declining to impose a new proprietary interface.

This is a credible and, to Google’s credit, a mostly real offering. A control plane, however, is a claim, not a feature, and the term deserves more focus and detail than vendors typically provide. An agentic control plane is not a product it is a semantically governed set of domain services and underlying structured and unstructured data. How we federate agentic access and data with intention and governance means everything.

What an interoperable control plane requires

A control plane governs how a system behaves rather than performing the work itself. For agents, a genuine control plane must deliver at least five functions, and an interoperable one must deliver them across vendor, model and cloud boundaries rather than only within a single domain or scope.

The first is identity. Agents are a new class of non-human actors, and an enterprise must be able to authenticate them and manage their actions. Microsoft’s competing Agent 365, unveiled at Ignite 2025, is built explicitly around a registry of which agents exist, plus access control and security — as an Ignite 2025 industry analysis noted, that identity is foundational. The second is context and semantics, the half of the problem the data clouds have collectively rushed toward. The third, and the most consistently underplayed, is action governance — control not merely over what an agent can read, but over what it can do: the writes, the state changes, the transactional operations. The fourth is observability and lifecycle management, the simulate-evaluate-monitor-optimize loop across an agent fleet, where Google’s integrated offering is, by most accounts, the most complete a hyperscaler has yet shipped. The fifth is economics; the reason so many projects are forecast to fail is partly cost, and FinOps for agentic AI is now an expressly named discipline on Gartner’s Hype Cycle.

Interoperability cuts across all five, and here the industry has done something genuinely impactful and useful: it has agreed on protocols. The Model Context Protocol, originated by Anthropic and since donated to the Linux Foundation under multi-vendor governance, standardizes how an agent connects to tools and data. The Agent2Agent protocol, originated by Google and likewise moved to the Linux Foundation, governs how agents discover and delegate to one another across organizational boundaries. Forrester predicts that 30% of enterprise app vendors will launch their own MCP servers in 2026, and Gartner’s Anushree Verma positions standardized protocols as the enabler of the seamless interoperability that, by 2028, will let networks of specialized agents collaborate dynamically across applications.

What is key here — and what enterprise leaders miss — is that open protocols deliver portable messages, not a portable control plane. Two agents can exchange tasks across clouds in A2A all day long, but identity, semantics, action governance, observability and cost remain platform functions. A2A and MCP have ensured that the communication protocol has been commoditized. The final frontier and the competitive moat is not the communication and access protocol, it is the semantic context and the business ontology

Where Google is strong, and where leaders should look twice

Google deserves real credit for embracing open standards where it counts. It adopted MCP across its own services, repositioned Apigee as an MCP bridge that turns any standard API into a governed agent tool and built its federation story on the open Iceberg REST Catalog rather than a proprietary format. Technology Business Research (TBR) characterized this as a meaningful strategic shift: a company historically defensive about keeping data inside BigQuery now signals that it cares less about where data physically resides than about ensuring Gemini is the semantic context layer generating value on top of it.

That repositioning is exactly the lock-in risk an enterprise must carefully consider, and two limitations matter significantly and deserve an architect’s attention. The first is that federation is not the same as unified control. In my view, TBR’s analysis is totally on point: The Knowledge Catalog addresses upper-stack governance but is not an operational catalog in the way that Databricks’ Unity Catalog, Snowflake’s Polaris and AWS Glue are — those systems govern the underlying Iceberg tables. Google reads into them; it does not replace them. The second is that the focus of lock-in has simply moved up the stack to the semantic context and ontology layers. Moor Insights & Strategy and others all have cautionary tales that exiting Google-managed semantics, Gemini agents or BigQuery abstractions may prove harder than migrating the data itself. The semantics and the orchestration are now the sticky layer. I think this is a logically coherent and impressive strategy, but for every gain, something is lost. That loss is exactly the moment where an enterprise either preserves its independence or succumbs to lock-in for convenience and expedience.

There is a maturity gap also worth mentioning here as well. One widely-circulated analysis of Next 2026 carried its verdict in the title — the agent stack is ready, the semantic engine isn’t — arguing that the Knowledge Catalog, however promising, is not yet the governed business-context layer a true enterprise operating system demands and remains more aspirational than operational. With much of the federation and catalog functionality still in preview, optimism is the right approach from my perspective, not “all-in” commitment.

Meanwhile, the competition is playing a different game

The competitors are not building the same artifact, and the differences are instructive. The data-cloud catalogs — Databricks Unity Catalog, Snowflake Polaris and Cortex, AWS Glue, Microsoft Fabric — govern data and, increasingly, semantics; the entire field now accepts that agents need context, not merely access, as industry analysis of the field documents. Their structural limit is that catalog constraints are frequently informational rather than strictly enforced, and metric-oriented semantic layers model measures rather than actions or state changes. They excel at conversing with data and remain weaker at agents that act. The agent-management planes, exemplified by Microsoft’s Agent 365, approach the problem from fleet control — registry, identity, observability — and are excellent for organizations living inside Microsoft 365, bounded by that same dependence.

Palantir Foundry represents a genuinely different category. Where catalogs register tables and semantic layers define metrics, Foundry is built around an ontology that models entities, their typed relationships and the actions that can be taken against them — semantics in service of operational execution, not merely analytics. That distinction is the single most important idea for anyone designing an agentic control plane today. As Atlan frames it, a semantic layer hands agents governed metrics, which solves half the problem; agents that reason across domains and act need a knowledge-representation layer underneath — what things are, how they relate and what operations are possible. A control plane that governs reads but not writes, metrics but not actions, is fundamentally limiting for agents, and semi-autonomous action is the entire point. It is also worth noting, the semantic layer itself is now standardizing: the Open Semantic Interchange initiative, launched in late 2025 by Snowflake, dbt Labs, Salesforce and a coalition of partners under an Apache 2.0 license, finalized its v1.0 specification in early 2026. Just as MCP and A2A commoditized the agent communication protocols, OSI aims to commoditize semantic portability.

A blueprint for enterprise leaders

As always, the path forward is clear enough to state but extremely demanding to execute. An interoperable agentic control plane is not a product an enterprise purchases from a single vendor; it is an architecture it composes — open standards at the commoditized layers, owned assets at the differentiating one. Drawing on both the Next 2026 announcements and recent architectural engagements, I would urge leaders to prioritize four design commitments.

First, standardize on open formats at the storage layer. Apache Iceberg and its REST Catalog deliver genuine data portability, and this is the one element of Google’s model worth adopting wholesale, precisely because the broader industry already has. Second, standardize on open protocols at the agent layer— A2A between agents and MCP to tools and systems — so that a Gemini agent, a Claude agent and a partner’s agent can interoperate without any one of them owning the others. Third, own the semantic and ontology layer in the middle. Don’t just model metrics but entities, relationships and the typed actions agents may perform; this is what delivers semantic portability and keeps the vendor lock-in at bay and in the enterprise’s own hands rather than a vendor. Fourth, own the control-plane core components — identity, registry, observability and policy — so that governance remains independent of any single platform.

Any vendor relationship that requires managed semantics will make it intentionally harder to migrate data. The architectural response should never be to place those semantics in any single vendor’s control in the first place. Federation buys data portability; an owned ontology buys semantic portability; open protocols buy agent portability. Composed together, they close the gap that the analysts identified.

The vendors will continue to make the case that the control plane is a product. The analysts — Gartner on governance and failure rates, Forrester on protocol proliferation, TBR and Moor on the limits of federation — are collectively telling enterprise leaders something more useful: it is an architectural decision, and the organizations that treat it as one, that build adaptive governance before their agentic minions outpace them and that preserve the option to change their minds, will be the ones still in command of their AI a decade from now.

Google Cloud Next 2026 is a genuinely strong architecture, and there is no doubt that it is the most complete agentic control-plane offering any hyperscaler has yet shipped. It is also the clearest illustration to date of why no enterprise should outsource its control plane to anyone. The shift from owning models to owning the control plane is not just underway; for organizations serious about operating at the speed of an agent-driven business, it is inevitable. The winning move at this point is to show up with an architecture, not a purchase order.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time, as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Embedding Pipelines sind das neue ETL

Wed, 17 Jun 2026 06:06:31 +0200

Unsere Expertin erklärt, was den Unterschied macht zwischen cooler KI-Demo und wirklich verlässlicher Lösung.

freedomnaruk | shutterstock.com

Ich habe schon diverse Male erlebt, dass vielversprechende KI-Prototypen nach dem Launch scheitern. Und das lag selten daran, dass das Modell schlecht gewesen wäre. Meistens beginnt das Problem schon viel früher. Nämlich dort, wo die Teams den Data Layer als nachrangig behandeln: Spezialisten verbringen Wochen damit, Prompts zu optimieren, Modelle zu testen und Evaluations-Scores zu diskutieren. Nur, um dann an einem Wochenende die Retrieval-Pipeline zusammenzuschustern und zum nächsten Projekt überzugehen. Erste Demos sehen zunächst großartig aus – allerdings liefert das System ein paar Monate später veraltete Outputs. Die Embeddings stimmen nicht mehr mit den Quelldokumenten überein und niemand versteht wirklich, was sich geändert hat. So werden anfänglich vielversprechende Prototypen im Produktivbetrieb unzuverlässig.

Solche Szenarien lassen sich vermeiden, wenn Teams frühzeitig erkennen, dass Embedding-Pipelines im Grunde ein Data-Engineering-Problem und keine völlig neue KI-Disziplin sind. Denn im Kern geht es immer noch um Extract, Load, Transform (ETL). Der Unterschied: Statt eines Data Warehouse sind Embeddings und Vektorspeicher der Zielort. Diese Sichtweise sorgt für Klarheit – und dafür, dass sich Versionierung, Datenaktualität, Lineage und Wiederholungsversuche nicht mehr „KI-spezifisch“ anfühlen. Und das sollten sie auch nicht. Es sind Dateninfrastrukturprobleme, mit deren Lösung wir uns schon seit Jahren beschäftigen.

Wozu Embedding-Pipelines?

Large Language Models (LLMs) sind bezüglich ihrer Reasoning-Fähigkeiten in einer Zeitkapsel gefangen. Sobald das Training beendet ist, wird der Wissensstand des Modells quasi „versiegelt“. In Kombination mit strikt beschränkten Kontextfenstern – also einer Obergrenze dafür, wie viel Text das Modell in einer Interaktion verarbeiten kann – wird das Problem mehr als deutlich: Auch LLMs haben Grenzen.

Bei der Suche nach einer Lösung für dieses Problem hat sich die Branche auf Retrieval Augmented Generation (RAG) geeinigt: Statt einfach alles in das Kontextfenster zu stopfen, wird ein Retrieval-Layer aufgebaut, der nur die relevantesten Informationen genau in dem Moment abruft, in dem eine Frage gestellt wird. Angetrieben wird dieser Layer von einer Vektordatenbank – und dem Prozess, der sie befüllt (Rohdokumente werden in durchsuchbare semantische Repräsentationen umgewandelt). Das ist mein Verständnis einer Embedding-Pipeline. Diese braucht jedes Team, das einen internen KI-Assistenten, ein smartes Enterprise-Search-Tool, einen Support-Agenten oder ein Q&A-System für Dokumente entwickelt.

Die nächste (und entscheidende) Frage ist dann, wie man diese Embedding-Pipeline aufbaut: Wie einen Prototyp oder wie eine Infrastruktur?

Embedding-Pipeline meets ETL

Eine Embedding-Pipeline beinhaltet drei Stufen:

Ingestion (Datenerfassung),
Chunking (Datenzerlegung) und
Indexing (Indizierung).

Nachfolgend sehen wir uns diese Phasen genauer an – und bringen diese mit dem klassischen ETL-Prozess in Verbindung.

Ingestion als Extraction

Bei der Datenerfassung geht es darum, Rohdaten – also beispielsweise PDFs, Wiki-Seiten, Word-Dokumente, Datenbankeinträge, Transkripte – von ihrem jeweiligen Speicherort in die Pipeline zu übertragen. Das entspricht der Extract-Phase im ETL-Prozess.

Ich beobachte, dass viele Teams an dieser Stelle Abstriche machen – und zwar mehr als an anderen. Das ist dann oft der erste Point of Failure von Produktionssystemen: Ein Dokument wird aktualisiert, aber die Pipeline erfasst es nicht. Eine Datei wird gelöscht, aber ihre Chunks verbleiben im Index und liefern noch Monate später veraltete Ergebnisse. Und weil kein offensichtlicher Fehler vorliegt, reportet es auch niemand.

Die Lösung ist Change Data Capture (CDC): Dabei wird ein Manifest aller erfassten Dokumente vorgehalten, inklusive einer Content-Hash-Datei und einem Zeitstempel. Bei jedem Durchlauf werden die Quellen mit diesem Manifest abgeglichen und geänderten Daten neu eingelesen sowie nicht mehr vorhandene gelöscht. Damit behandeln Sie Ihre Inhalte so wie jede Source-Tabelle, die inkrementell synchronisiert wird.

Chunking als Transformation

Sobald sich die Dokumente in der Pipeline befinden, können Sie diese nicht mehr in einem Stück einbinden. Ein 30-seitiger technischer Bericht ist zu lang, um ihn sinnvoll als einzelnen Vektor darzustellen. Und selbst wenn das nicht der Fall wäre: Den kompletten Report als Antwort auf eine eng gefasste Frage zurückzugeben, würde das Modell in irrelevantem Kontext versinken lassen. Deshalb gibt es Chunking: Es ist der Prozess, bei dem jedes Dokument in kleinere Teile zerlegt wird. Und zwar solche, die fokussiert genug sind, um exakt eingebettet und präzise abgerufen zu werden. Das entspricht nicht nur der Transform-Phase von ETL, sondern erfordert auch dasselbe Maß an Design-Disziplin.

Der häufigste Fehler, den ich in diesem Zusammenhang beobachte, ist, die Chunk-Größe als Standardkonfigurationsoption zu behandeln statt als Produktentscheidung. Die richtige Chunk-Größe hängt vollständig von der Art der Inhalte und der Queries ab. Eine komplexe technische Dokumentation erfordert mehr Granularität als eine FAQ-Sammlung. Anders ausgedrückt: Was für einen Inhalt funktioniert, kann bei einem anderen die Retrieval-Qualität negativ beeinflussen.

Ich bevorzuge es deshalb, Chunking-Konfigurationen als versionierte Pipeline-Parameter zu behandeln und nicht als fest-codierte Logik. Wenn Sie diese verändern (und das werden Sie), müssen Sie auch das Chunking auf kontrollierte, nachvollziehbare Art und Weise neu durchführen und dabei die Abfragequalität vergleichen und eventuell zurücksetzen, falls sie sich verschlechtert. Das verstehe ich einfach als gute Transform-Layer-Hygiene.

Indexing als Load

In der Indizierungsphase wird der in Chunks unterteilte Inhalt schließlich in Vektoren umgewandelt und in einer entsprechenden Datenbank abgelegt. Anschließend stehen die Inhalte für semantische Ähnlichkeitssuchen zur Verfügung. Die Einbettung erfolgt beim Umwandlungsschritt durch ein Modell, das speziell darauf trainiert ist, Text, beziehungsweise Content in dichte numerische Darstellungen umzuwandeln, die dessen Bedeutung kodieren. Zwei Chunks, die denselben Gedanken mit unterschiedlichen Worten ausdrücken, erzeugen Vektoren, die in diesem mathematischen Raum dicht beieinander liegen. Behandeln sie hingegen unterschiedliche Themen, liegen sie weit auseinander.

Stellt ein User nun eine Frage, bettet das System diese auf die gleiche Weise ein, findet die Chunks, deren Vektoren am nächsten liegen und gibt sie als Kontext für den Reasoning-Prozess des Modells zurück. Das unterscheidet sich zwar vom Load-Prozess – aber nicht, wenn es um die Disziplin geht: In Embedding-Pipelines muss jeder Chunk im Index mit dem Namen und der Version des Embedding-Modells gekennzeichnet sein, mit der er generiert wurde. Schließlich entwickeln sich Embedding-Modelle weiter und Vektoren, die von verschiedenen Versionen erzeugt wurden, sind nicht zuverlässig miteinander vergleichbar.

Genau dieses Problem tritt auf, wenn Embedding-Modelle in der Pipeline ohne ordnungsgemäßen Migrationsplan aktualisiert werden. Am Ende werden Vektoren aus verschiedenen Generationen im selben Index miteinander vermischt – und die Suchqualität verschlechtert sich. Das Tückische dabei ist, dass sich das still und leise vollzieht – oft in Form subtil falscher Antworten. Beim Upgrade eines Embedding-Modells gehe ich deshalb genauso vor wie bei einer Schema-Migration: Ich plane explizit, ziehe es an einem Stück durch und validiere die Retrieval-Qualität anhand eines repräsentativen Query-Sets. Schließlich steht hier ebenso viel auf dem Spiel wie bei jeder grundlegenden Änderung am Datenmodell.

Pipeline-Observability ist nicht optional

Sobald eine Embedding-Pipeline in der Produktion läuft, ist die Frage nicht mehr, ob sie läuft, sondern vielmehr, ob sie das auch auf korrekte Weise tut. Das ist in diesem Fall wichtiger als bei den meisten anderen Pipelines, weil Fehler seltener auffallen: Der Index sieht einwandfrei aus, Abfragen werden fehlerfrei zurückgegeben – und dennoch liefert das System falsche Antworten. So lange, bis jemandem auffällt, dass die KI keinen Nutzwert hat.

Deshalb braucht es an dieser Stelle auch Observability-Disziplin. Sobald man Embedding-Pipelines als Produktionssysteme behandelt, denkt man nicht mehr in isolierten Schritte, sondern in Signalen. Beispielsweise wird die Anzahl der Chunks pro Dokument zu einem einfachen, aber leistungsstarken Health Check: Ein plötzlicher Rückgang ist in der Regel kein Modellproblem, sondern ein Zeichen für eine gestörte Datenerfassung oder Upstream-Parsing-Fehler.

Darüber hinaus brauchen Sie auch ein „Golden Set“ von Queries mit nachweislich korrekten Outputs. Dieses kann nach jeder Pipeline-Änderung als eine Art Datenqualitätsprüfung fungieren und Regressionen sichtbar machen, die nicht als explizite Fehler auftreten. Zusätzlich können Sie auch die Lineage tracken und so herausfinden, welche Version des Einbettungsmodells welche Chunks erzeugt hat und wann jedes Dokument zuletzt eingelesen wurde. Das ermöglicht es, Probleme bei der Abfrage auf bestimmte Änderungen zurückzuführen – anstatt einfach zu raten.

Die Datenaktualität wird schließlich zu einem Signal erster Güte. Wenn Dokumente über eine akzeptable Schwelle hinaus veralten, sollte das auch im Rahmen des Monitorings sichtbar sein – und zwar bevor die Benutzer schlechte Ergebnisse geliefert bekommen. Die Metrik, die all das zusammenführt, ist die Abfragequalität im Zeitverlauf (Retrieval Quality over Time). Diese ist wie jede andere Pipeline-SLA zu behandeln: Sie muss gemessen, getrackt und ge-„ownt“ werden. (fm)

Dieser Beitrag wurde im Rahmen des englischsprachigen Expert Contributor Network von Foundry veröffentlicht. Alle Infos zum deutschen Experten-Netzwerk finden Sie hier.

Cloud strategies have become more complicated than ever

Tue, 16 Jun 2026 16:57:06 +0200

With years of cloud experience, IT leaders thought they finally had firm control of their cloud strategies. And then came AI.

Of course, cloud issues today extend beyond artificial intelligence. Where to place cloud workloads for maximum efficiency is one. Questions about governance, sovereignty, the growing sophistication of cyberthreats, and escalating cost concerns are also conspiring to make the cloud ever more complicated.

“It’s just grown into a complex mess,” observes cloud expert David Linthicum, emphasizing that cloud strategy today needs to address private cloud, multicloud, hybrid cloud, and sovereign clouds — much more than most CIOs have dealt with to date.

Initially, cloud discussions centered around agility, scalability, and cost optimization, says Joshua Bellendir, CIO of retailer WHSmith North America. “Today, we are balancing a much broader and more complicated set of considerations, including AI readiness, cybersecurity, data governance, sovereign data requirements, edge computing, integration architecture, and operational resilience.”

One of the biggest shifts is that “cloud is no longer simply an infrastructure conversation,” Bellendir says. “It has become deeply tied to enterprise architecture, business transformation strategy, and data strategy.”

Amit Basu, vice president, CIO, and CISO of International Seaways, also notes cloud’s growing complexity. While reduced capital expenditure and greater flexibility still apply in some areas, dealing with the environment has become significantly more challenging, he says.

Sweetwater CIO Jason Johnson describes the current state as “genuinely one of the more complex times to be managing cloud.” Providers keep expanding their catalogs with more SKUs, more services, and more options, he says. “While that’s great for capability, it creates real overhead in just keeping up. You need people who understand not just what’s available, but what’s actually the right fit for your use case.”

Many organizations are now entering a second phase of cloud maturity. “The earlier phase was focused heavily on migration and modernization,” Johnson says. “The current phase is more focused on optimization, governance, AI enablement, and operational sustainability. That shift is changing the conversation significantly for the CIOs I’m speaking with.”

But few CIOs have the luxury of simply pondering what to do. All must meet the challenges of complexifying cloud strategies head on.

How AI changes the cloud calculus

The desire to deploy AI quickly is creating tremendous pressure on IT leaders, with cloud a central concern, Linthicum says.

“The board of directors are screaming for it worse than the cloud push 15 years ago,” he says. “CIOs are feeling the pinch and having to make that move as quickly as they can” to gain more compute for AI initiatives in an already tricky environment, he adds.

At the same time, CIOs must solve the data complexity problem before integrating AI systems, Linthicum notes. “They’re running around in circles right now trying to figure out the best way to do that.”

Hyperscalers used to be “the easy button,” Linthicum says, “but they’ll be three, four times the cost.”

AI systems cost 10 times as much as traditional equivalent applications, he estimates. “So [CIOs are] putting a lot of money on the line.”

International Seaways’ Basu says AI has changed the architecture conversation. “GPU availability, vector databases, low-latency inference, and large-scale data pipelines introduce requirements that do not fit neatly into traditional cloud design models,” he notes. “Organizations are no longer simply lifting and shifting workloads. They are designing for very different compute and data requirements.”

Zachary Lewis, CIO and CISO of University of Health Sciences and Pharmacy, says the needs of internal stakeholders only compound that complexity. Business units want disparate AI capabilities, security teams want governance and some control over AI apps, the general counsel wants to know what kind of data is being put in the AI model, and the finance team wants cost predictability.

“CIOs have to reconcile all of this and try to deliver on everyone’s needs, and you have to do that successfully,” Lewis says. “Everyone has a different end goal and demand and we’re trying to square all of that for them.”

Ever since the online retailer of musical instruments and pro audio equipment formalized its cloud strategy around 2016, Sweetwater’s Johnson has sought to place workloads wherever it made the most sense for external and internal customers.

“Anything customer-facing needs to be geo-specific; as close to the end user as possible,” he says. “Same logic applies — internal workloads belong close to whoever is using them.”

The cloud offers infinite opportunities, and with that comes infinite levels of complexity, he says. “It’s just the reality of the model.”

“AI wouldn’t be possible without the cloud. The compute scale AI needed had already been built — the cloud had it and could deliver it,” he adds. “In a lot of ways, AI might be the cloud’s greatest gift to the industry. They enabled each other.”

Cloud cost control complexifies

Johnson’s biggest headache is managing costs consistently. “It used to be relatively straightforward: compute, storage, egress. Now it’s a puzzle,” he says. “Reserved instances, savings plans, spot pricing, per-request costs, data transfer fees between regions — it stacks up fast — and it’s genuinely hard to predict what your bill is going to look like until it arrives.”

Consequently, FinOps has become a discipline in its own right, he says.

Basu also believes FinOps has become essential. “AI inference costs, egress charges, and storage growth can create month-over-month cost swings that surprise even experienced teams,” he says. “Cost management is now a continuous operational discipline rather than an occasional review exercise.”

Vendor lock-in is also always in the back of Johnson’s mind. “The more deeply you integrate with a provider’s native services, the harder it is to move.” While that’s not always bad, he adds, it’s a tradeoff. “I think about it like technical debt. You’re borrowing speed now and paying interest later if you ever want to change direction.”

But Johnson recognizes that cloud providers are businesses that “squeeze for revenue and margin, and they change the rules on how you buy committed discounts and manage spend.”

Financial efficiency doesn’t happen by accident, he points out. It requires teams, processes, and real investment in FinOps. “The tools exist. Using them well is the harder part,” he says.

Most organizations have their financial expertise sitting in accounting and their technical expertise sitting in IT, Johnson explains. Getting those two to work together on cloud cost is a relatively new challenge.

“Ten years ago, the model was simple: You asked for a CapEx budget, accounting approved it, you placed hardware orders, and IT installed and optimized. Done. Now it’s a daily exercise,” Johnson says. “New services get turned on, contracts change, pricing structures shift. Finance understands the cash but not the tech. IT understands the tech but not the financial levers.”

Every major cloud provider has the tools, Johnson explains. “AWS Cost Explorer, Azure Cost Management, GCP’s billing dashboards. The data is all there.” But most organizations aren’t acting on that data, he says, “and then the bill shows up and people are surprised. The tools told you it was coming. You just weren’t listening.”

Data regulations add sovereign subtleties

The University of Health Sciences and Pharmacy has students from all over the world. Cloud has become significantly more difficult to manage due to the rise in regulatory laws around the globe surrounding data, Lewis says.

“We have to understand if the metadata is in a specific cloud region, where it is stored, and kept,” he says. “If that data ends up in a model we trained internally, can we guarantee it stays in the EU? Then, if someone wants their data purged, can we find all those locations with some level of competence?”

Basu says data sovereignty has become another major architectural consideration. “It affects where workloads can run, how data moves between regions, and what can be done with certain datasets,” he says. “You cannot assume a hyperscaler’s default configuration satisfies your regulatory obligations.”

Private vs. public vs. on-prem

AI has sparked a rethink on where to place cloud workloads, but Sweetwater’s Johnson believes the question of whether to pull more workloads into private clouds versus public clouds shifts more often than people expect. “I think the vast majority of our workloads are in the right place right now, but we got there by being willing to question the default,” he says.

Sweetwater does not operate under a rule that says new workloads always go to the cloud, he notes. A workload might start in the cloud and end up on-prem if the math changes. “The discipline is in reviewing that in real-time, finding the inflection points, and right-sizing as you go. Right tool, right time. That’s the only principle that holds up over time.”

International Seaways’ Basu is not planning a move toward private cloud, as the economics and operational overhead do not justify it for his organization.

“The right question is what is the correct data residency, latency, and control model for each workload,” he says. “That is a data classification discipline, not a cloud deployment strategy.”

Lewis, who has about 95% of the University of Health Sciences and Pharmacy’s infrastructure running in the cloud, doesn’t see a good alternative given how the stakes have changed for AI and hardware.

“If you want to train large scale data lakes and make informed business decisions with machine learning and the intelligence behind it, it’s almost not practical anymore” to be on-prem, Lewis says.

CIOs need to ask themselves whether they have the expertise to handle that infrastructure, he adds. Ultimately, “you have to make the best of what you’ve got,” he says.

Stay focused on fundamentals

Organizations may want to chase the shiny object, which is agentic AI right now, but IT leaders should focus on their infrastructure, management, and platform planning, Linthicum stresses.

“It’s not as fun,” he says, “but to do any AI within your environment, you have to solve those issues.”

The cloud enables a lot of architectural patterns, and that freedom will work against you if you don’t have guardrails, cautions Sweetwater’s Johnson. “Write the guidance document before you need it — not after you’ve already got five teams doing things five different ways.”

IT leaders also need to get ahead of tagging and cost visibility early, saying that it needs to be a first step, not a cleanup project. “If you can’t see your spend clearly from day one, you’re already behind,” he says.

A key step is to build an auditing program with solid controls around who can create production changes, Johnson says. “The blast radius of a bad change in the cloud is bigger and faster than most people expect, until they experience it.”

The skills question

The skills needed to operate a modern cloud environment are evolving faster than most internal teams can realistically keep up with, Basu says. As a result, International Seaways relies on specialized MSPs rather than trying to maintain deep in-house expertise across every domain.

“That gives us access to current capabilities without constantly retraining or rebuilding teams as the technology changes,” he explains. “The decisions that protected us in 2020 were made years before anyone realized how important they would become. Infrastructure strategy is always about preparing for a future that is not yet fully visible.”

The key is to make those decisions deliberately, with clear reasoning, rather than reacting under pressure later, he adds.

Build adaptable organizations

Edge computing is adding another layer of complexity, Johnson says. Leaders who navigate this effectively won’t be the ones who find the perfect architecture, he notes. “They’re the ones building organizations that can adapt quickly when the right answer changes tomorrow,” he says.

The real competitive advantage is not the cloud you picked, but how fast your team can learn and move, Johnson says.

Asked about other advice to make cloud less complicated, the CIOs offered the following:

Treat your cloud architecture like a product, not a project. It needs ongoing ownership, not just implementation, Johnson stresses.
Make sure you’re reviewing your decisions regularly. “The right call at year one often isn’t the right call at year three. Build in the checkpoints to revisit,” Johnson says.
Tie every workload to a cost center. Basu has done this, and IT continuously reviews utilization and rightsizing rather than waiting for periodic audits.
Data classification determines regional placement. Before any workload reaches production, ensure “Legal and Compliance are in that conversation from the start, not at the end,” Basu says.
Create a cloud-ready solution. This can sometimes be less expensive and lower risk than lifting and shifting a heavily customized legacy environment, Basu says.
Consolidation is a strategic choice, not a retreat. Fewer platforms, governed well, consistently outperform a fragmented multicloud estate, he says.
Don’t underestimate the governance gap AI is opening. Build your AI governance layer now, before the debt accumulates, Basu says.
Cloud strategy is not an IT architecture decision. The pandemic proved that it is a business resilience decision, Basu says. “The organizations that make the hard calls before the crisis arrives are the ones that come out intact.”
Ensure cloud decisions are tied to measurable business outcomes. WHSmith’s Bellendir says IT is also investing heavily in integration architecture, cybersecurity controls, observability, and data governance to better support a hybrid ecosystem.
Place greater emphasis on cloud cost governance and operational discipline. This will improve visibility into cloud usage and ensure that scaling AI, analytics, and digital initiatives remains financially sustainable over time, Bellendir says.

While no one can foresee whether cloud will grow less complicated down the road, organizations will continue to use it. “Cloud is no longer the future of IT — it’s the present,” says Sweetwater’s Johnson. “The conversation has shifted from ‘should we?’ to ‘how do we get better at it?’ That’s where I spend most of my time.”

This story originally appeared on CIO.

Wie Jeetu Patel Cisco bis zur Unkenntlichkeit verändert hat

Tue, 16 Jun 2026 16:08:23 +0200

width="1024" height="683" sizes="auto, (max-width: 1024px) 100vw, 1024px">

Ciscos Chief Product Officer Jeetu Patel auf der Cisco Live US 2026

Cisco

Auf der Cisco Live 2026 war es Zeit für Jeetu Patel, Chief Product Officer von Cisco, ein vor 24 Monaten gegebenes Versprechen einzulösen. Zwei Jahre zuvor hatte der Manager versprochen, dass Cisco in zwei Jahren kaum wiederzuerkennen sein würde – im positiven Sinne, versteht sich.

Die auf der Veranstaltung vorgestellten Innovationen lassen darauf schließen, dass er sein Versprechen tatsächlich weitgehend eingelöst hat. Cisco positioniert sich neu: weg von einer Holding-Gesellschaft für Produkte und Dashboards hin zu einer einheitlichen, KI-nativen Infrastrukturplattform. Dabei fungiert Cloud Control als Steuerungsebene, Cisco IQ als CX-Zentrum und Secure Networking als verbindendes Element.

Dieser Wandel betrifft nicht nur neue Funktionen, sondern ein völlig neues Betriebsmodell. Cisco schafft eine Umgebung, in der sich menschliche Administratoren und KI-Agenten dieselben Daten, denselben Kontext und dieselben Handlungsmöglichkeiten teilen, wobei die Menschen die Kontrolle behalten.

Vom Dashboard-Wust zu Cloud Control

Der sichtbarste Beweis für das „neue“ Cisco ist Cloud Control, eine einheitliche Management-Plattform für Networking, Security, Compute, Observability, Collaboration und ein wachsendes Ökosystem von Drittanbieter-Tools. Cisco betont, dass es sich hierbei nicht nur um eine weitere zentrale Übersicht handelt. Stattdessen ist es eine aktive Ausführungsumgebung, in der Richtlinien und Identitäten direkt in den Steuerungsprozess integriert sind. Die Plattform wurde von Grund auf dafür konzipiert, dass Menschen und KI-Agenten die Infrastruktur gemeinsam betreiben.

Wenn sich Betreiber in Cloud Control anmelden, sehen sie eine vertraute, ChatGPT-ähnliche Oberfläche mit drei Modi:

„Assistant“ ermöglicht es Betreibern, mit der Plattform in natürlicher Sprache zu kommunizieren.
„Canvas“ bietet einen Arbeitsbereich für mehrere Nutzer, in dem Menschen und Agenten gemeinsam Probleme untersuchen und lösen können.
„Actions“ fungiert als Leitstelle zur Überwachung dessen, was Agenten vorschlagen und ausführen.

Cloud Control stellt zudem gemeinsame Plattformdienste wie Bestands- und Topologieinformationen über die gesamte Cisco-Infrastruktur hinweg bereit. Meraki, Intersight, Sicherheitsdienste, Splunk, Webex Control Hub und Cisco IQ sind alle mit einem einzigen Login zugänglich. Damit entfällt der Wechsel zwischen mehreren Dashboards und Authentifizierungsdomänen, stattdessen können sich die Betreiber nahtlos zwischen Plattformdiensten und Produkterfahrungen innerhalb derselben Umgebung bewegen.

Cloud Control als „KI-Harness“, nicht als Konsole

Technisch basiert Cloud Control auf einer gemeinsamen Datenstruktur, die Telemetriedaten aus Benutzern, Geräten, Anwendungen, Netzwerken und Bedrohungen korreliert. Diese Datenbasis dient sowohl menschlichen Entscheidungen als auch agentengestützter Automatisierung.

Cisco beschreibt diesen Wandel als Übergang von „Infrastructure as Code“ zu „Infrastructure as a Harness“. Anstatt ausschließlich von Menschen geschriebene Skripte und Playbooks zu verwenden, wird Cloud Control zur kontrollierten Umgebung, in der KI-Agenten Systeme beobachten, analysieren und sicher steuern können.

Drei zentrale Komponenten prägen diesen Ansatz:

„AI Canvas“ bildet den Arbeitsbereich, in dem Menschen und Agenten gemeinsam Vorfälle untersuchen, wobei der Kontext über Schichten und Eskalationen hinweg erhalten bleibt.
Das „Cloud Control Studio“ ermöglicht Kunden und Partnern, mit Agent Builder und App Buildermithilfe natürlicher Sprache und integrierter Programmierassistenten ihre eigenen Agenten und Anwendungen auf Basis der Daten, Richtlinien und der Steuerungsebene von Cisco zu erstellen .
Der „Cloud Control Marketplace“ stellt Eigenentwicklungen und Partnerlösungen über einen zentralen Marktplatz zur Verfügung.

Aus Sicht von Unternehmen wandelt sich Cloud Control damit von einer Plattform „zum Durchklicken von Einstellungen“ zu einer sicheren Plattform für agentengestützte IT-Prozesse: Eine geregelte Umgebung, in der KI-Agenten durchgängig bereitgestellt, überwacht, eingeschränkt und geprüft werden können. Dies ist ein ganz anderes Konzept als die herkömmliche Netzwerkmanagement-Konsole.

Ein gemeinsames „Gehirn“ für Customer Experience und Produkte

Unter der Leitung von Liz Centoni, Executive Vice President und General Manager, hat Cisco zudem seine Customer-Experience-Organisation (CX) grundlegend umgebaut. Lange Zeit wirkten die CX- und Produktorganisationen wie zwei Parallelwelten: Services wurden auf Produkte aufgesetzt, statt eng mit deren Funktionsweise verzahnt zu sein. Um diese Lücke zu schließen, arbeitete Centoni eng mit Patel zusammen, um sicherzustellen, dass Produktentwicklung und CX vollständig aufeinander abgestimmt sind.

Cisco IQ verändert diese Dynamik, indem die modernisierten CX-Funktionen direkt in die gleiche Cloud-Control-Umgebung integriert werden, in der auch die Produkte betrieben werden. Zudem werden die CX-Workflows an dieselbe Telemetrie- und Policy-Ebene angebunden. Bemerkenswert ist dabei, dass Cisco IQ nicht einfach ein weiteres Dashboard ist, sondern ein integraler Bestandteil von Cloud Control.

Cisco IQ ist als KI-gestützte Plattform für Support und Professional Services positioniert. Ziel ist es, Kunden vollständige Transparenz über die gesamte IT-Landschaft, proaktive Ausfallsicherheit, schnellere Problemlösungen und kontextbezogene Services zu bieten. Die Lösung wird als SaaS-Plattform bereitgestellt, kann aber für Kunden mit strengen Anforderungen an Datenhoheit auch On-Premises betrieben werden.

Durch die Nutzung der gemeinsamen Data Fabric kann Cisco:

IQ Assets inventarisieren, unabhängig davon, ob sie bereits im Einsatz sind oder sich noch im Lager befinden,
Risiken kennzeichnen, bevor Kunden Probleme erleben, und
die Sicherheitslage eines Unternehmens anhand anonymisierter Vergleichswerte nach Branche, Marktsegment oder Region benchmarken.

Neue Funktionen unterstreichen die enge Verzahnung von CX und Produktentwicklung weiter:

„Resilient Infrastructure Services“ nutzt ein dreistufiges Framework aus Expositionsbewertung, Infrastrukturmodernisierung und Verteidigungsresilienz, um Kunden bei der Vorbereitung auf Bedrohungen nach dem „Frontier-Modell“ zu unterstützen.
„Quantum Ready Assessments“, die über Cisco IQ bereitgestellt werden, identifizieren Systeme, die besonders anfällig für sogenannte „Harvest Now, Decrypt Later“-Angriffe sind, und zeigen einen Weg zu einer quantensicheren Infrastruktur auf.

Die Verlagerung des „CX-Gehirns“ in Cloud Control und dessen Anbindung an dieselben Daten- und KI-Modelle, die auch den operativen Betrieb steuern, stellt sowohl kulturell als auch architektonisch einen grundlegenden Wandel dar.

Secure Networking als Beweis für die Integration

Wer verstehen möchte, wie stark das neue Cisco inzwischen integriert ist, sollte sich den Bereich Secure Networking ansehen.

Ciscos Vision besteht darin, Sicherheit direkt in die Infrastruktur einzubetten – vom Silizium über das Netzwerk bis hin zum operativen Betrieb –, statt sie als separaten Technologie-Stack zu behandeln.

Diese Strategie manifestiert sich auf verschiedene, konkrete Weisen.

Live Protect, intern als „digitales Immunsystem“ bezeichnet, wendet präzise Ausgleichskontrollen auf Cisco-Produkte im Betrieb an, um diese vor neu entdeckten Schwachstellen zur Laufzeit zu schützen. Dies geschieht ohne Neustarts, Upgrades oder Wartungsfenster. Die Kontrollen sind zielgerichtet eingesetzt, um Leistungseinbußen zu vermeiden und Fehlalarme zu minimieren.

Live Protect ist bereits auf Nexus-9000-Switches verfügbar und wird auf das gesamte Portfolio ausgeweitet, einschließlich Campus-Switches, wodurch die Rückkopplungsschleife zwischen der Entdeckung von Schwachstellen und deren Behebung von Wochen auf Minuten verkürzt wird.

Die Hybrid Mesh Firewall erweitert einheitliche Sicherheitsrichtlinien über Netzwerke, Anwendungen sowie Firewalls von Cisco und Drittanbietern hinweg und begrenzt so den Schadensumfang, wenn etwas schiefgeht.

Gleichzeitig integriert Cisco Post-Quantum-Krypto-Bibliotheken, Secure Boot und Trust Anchors in sein Kernportfolio und hat sich verpflichtet, bis Dezember 2026 quantensichere Kommunikationsfunktionen für die meisten Kernprodukte bereitzustellen. Neue Router-, Switch- und Firewall-Serien für Unternehmen und Rechenzentren werden als „standardmäßig quantensicher“ auf den Markt gebracht.

All dies wird über Cloud Control orchestriert, laut Cisco die Sicherheitsleitstelle für die Zeit nach Mythos. Dabei stellt Splunk das Telemetrie-Backbone sowie agentenbasierte SOC- und SRE-Funktionen bereit. Auf diese Weise soll es möglich sein, Vorfälle mit maschineller Geschwindigkeit zu erkennen, zu priorisieren und darauf zu reagieren.

Secure Networking ist damit mehr als klassische Firewalls oder SD-WAN. Es bildet das Rückgrat, das Ciscos Netzwerk-, Sicherheits-, Observability- und KI-Ressourcen zu einer einheitlichen Plattform verbindet.

Multicloud Fabric: Networking as a Service für KI

Ein weiteres Kennzeichen des neuen Cisco ist die Bereitschaft, Netzwerke als vollständig verwaltete Fabric bereitzustellen, anstatt Kunden lediglich Werkzeuge in die Hand zu drücken, die selbst zusammenstellen müssen.

„Multicloud Fabric“ veranschaulicht diesen Wandel. Die Lösung wird als Network-as-a-Service-Angebot über Cloud Control bereitgestellt und bietet Unternehmen eine einheitliche Struktur für sicheres Site-to-Cloud- und Cloud-to-Cloud-Networking. Cisco betreibt hierfür virtuelle Points of Presence (PoPs) bei den wichtigsten Cloud-Anbietern und in verschiedenen Regionen.

Kunden können dadurch Standorte und Cloud-Umgebungen einbinden, absichtsbasierte Konnektivität definieren, Sicherheitsrichtlinien zuweisen und die Leistung „mit einem Klick“ über Cloud Control überwachen, anstatt eigene Hub-and-Spoke-Architekturen aufzubauen und zu warten.

Sicherheit und Observability sind integriert – in Form von Zero-Trust-Routing, Cloud-Firewall-Service-Chaining sowie über in jeden Point of Presence eingebettete ThousandEyes-Agenten. Das Netzwerk ist somit nicht länger eine passive Leitung, sondern Teil des KI-Intelligence-Stacks.

Dies gewinnt an Bedeutung, da AI-First-Anwendungen zunehmend Inferenzprozesse über mehrere Clouds und Datenquellen hinweg ausführen. Cisco-eigene Untersuchungen zeigen, dass diese agentenbasierten Workflows ein Vielfaches an Netzwerkverkehr generieren können als manuelle Entsprechungen, wobei es sich bei einem Großteil um latenzempfindliche Inferenz handelt. Multicloud Fabric, das als Service betrieben und in dieselbe Cloud Control-Umgebung integriert ist, ist Ciscos Antwort auf diese neue Realität.

Was bedeutet das für Kunden?

Cisco hat vier Jahrzehnte damit verbracht, branchenführende Produkte zu entwickeln, von Meraki und Nexus bis hin zu Webex und ThousandEyes. Die größte Chance des Unternehmens lag jedoch schon immer darin, wie diese Komponenten zusammenwirken. Nämlich, wie es Patel formuliert, „eng integriert und dennoch lose gekoppelt“.

Cloud Control, Cisco IQ, Multicloud Fabric und Secure Networking deuten darauf hin, dass Cisco diese Lücke zunehmend schließt. Einzelne Dashboards werden zu agentischen Workflows und isolierte Produkte verwandeln sich in ein sicheres Gerüst für das KI-Zeitalter.

Für Kunden ist die Transformation von Cisco von Bedeutung, da sie nicht nur die Produktpalette, sondern auch das Betriebsmodell verändert. Cloud Control bietet IT-Teams eine einheitliche Verwaltungsebene für Netzwerke, Sicherheit, Observability, Zusammenarbeit und Dienste und ersetzt damit die fragmentierte Dashboard-Erfahrung, die für Cisco-Umgebungen lange Zeit eine Bürde waren. Dies dürfte den Betrieb schneller und einfacher machen, setzt aber auch höhere Anforderungen an die Kunden.

Da Cisco AgenticOps, AI Canvas, Live Protect und Cisco IQ in den Mainstream bringt, verschiebt sich die Rolle der IT von der manuellen Bedienung einzelner Werkzeuge hin zur Überwachung von KI-Agenten. Dieser Wandel erfordert neue Kompetenzen in den Bereichen Prompt-Design, Richtlinienmodellierung, Risikobewertung und Governance. Insbesondere, weil Agenten immer mehr Änderungen vorschlagen und testen, bevor Menschen überhaupt auf „Genehmigen“ klicken.

Für Kunden bedeutet dies auch einen Perspektivwechsel: Cisco sollte künftig weniger als Sammlung einzelner Best-of-Breed-Produkte betrachtet werden, sondern vielmehr als integrierte Plattform.

Je mehr der Cisco-Umgebung mit Cloud Control verknüpft ist, desto mehr Nutzen sollten Kunden aus gemeinsamer Telemetrie, einheitlichen Workflows, integrierter Sicherheit und domänenübergreifender Automatisierung ziehen – insbesondere in Bereichen wie Secure Networking und Multicloud-Betrieb.

Umgekehrt benötigen Kunden, deren Umgebungen weiterhin stark heterogen sind, klare Integrationsstrategien und Governance-Modelle, um sicherzustellen, dass Tools von Drittanbietern sicher in das System eingebunden werden können.

Der vielleicht größte Nutzen des neuen Cisco liegt in der Reduzierung von Komplexität – einem der größten Schmerzpunkte vieler Unternehmenskunden. Wenn das Unternehmen diese Vision umsetzen kann, werden Kunden möglicherweise feststellen, dass Cisco nicht nur auf positive Weise nicht wiederzuerkennen ist. Sondern auch einfacher zu kaufen, zu implementieren und zu betreiben ist als jemals zuvor. (mb)

Dieser Artikel basiert auf einem Beitrag der Network World.

Advait Patel on How SRE and Security Engineering Are Converging

Tue, 16 Jun 2026 15:09:34 +0200

The convergence of SRE and Security Engineering is reshaping how organizations build, operate, and protect modern cloud environments. As infrastructure grows more complex and distributed, reliability, security, identity management, and observability are becoming increasingly interconnected disciplines rather than separate functions.

Advait Patel, Senior Site Reliability Engineer at Broadcom and author of DockSec, has witnessed this shift firsthand. With experience spanning cloud infrastructure, DevSecOps, and observability platforms such as Wavefront (Tanzu Observability), he has worked on systems processing more than 10 million data points per second while leading initiatives in IAM, cloud migration, and security engineering.

In this interview, Patel shares his insights on securing observability platforms at scale, managing identity across multi-cloud environments, balancing automation with human oversight, and the role AI is playing in the future of DevSecOps and incident response.

Advait Patel Breaks Down SRE and Security Engineering

TCE: How are you seeing SRE and security engineering converge in modern cloud environments?

Advait Patel: The short version is that the failure modes started overlapping and the org charts are catching up. A misconfigured IAM policy that takes down a service and a misconfigured IAM policy that exposes data are usually the same mistake. SREs already own the deployment pipeline, the observability stack, and the incident process, which happen to be the three places security has to live if it wants to be effective instead of decorative. What changed it for me was security as code. When I ran the zero-downtime migration of our observability platform from AWS to GCP, security could not be a review step bolted on at the end. It had to be expressed the same way reliability was, as policy in the pipeline, with the same testing and the same rollback story. That is the real convergence. Not security and SRE attending the same standup, but security becoming something you can measure and enforce the way you measure latency or error rate. We are not all the way there as an industry. Plenty of shops still treat security as a gate at the end. But the teams moving fastest have stopped pretending the two disciplines are separate.

TCE: What are the biggest challenges in securing large-scale observability platforms handling high-volume data streams?

Advait Patel: This one is close to home, since I spent a long time on a platform ingesting north of 10 million data points per second. A few things make it genuinely hard. First, telemetry is one of the most underrated attack surfaces in a company. Your metrics, traces, and logs describe your entire architecture. Get read access to that and you do not need to break into anything, the map is already drawn for you. And secrets leak into logs constantly. Someone logs a full request, the token rides along with it, and now your observability store is a credential store you never meant to build. Second, at that volume you cannot inspect everything inline. Any control you add has to be cheap or it becomes the exact bottleneck you were hired to prevent. That single constraint rules out a lot of textbook advice. Third is tenant isolation. When many teams share one pipeline, one team seeing another team's data is both a security incident and a trust failure at once. Getting that right without wrecking throughput was one of the harder problems in that migration.

TCE: How do you approach identity and access management (IAM/CIAM/WIAM) in multi-cloud architectures?

Advait Patel: I have spent enough time here to have written a couple of books on identity in the cloud, and the honest summary is that multi-cloud IAM is hard mostly because the providers disagree with each other. AWS, GCP, and Azure each have a different mental model for what an identity even is and how permissions attach to it. The abstractions do not map cleanly, so anyone selling you one tidy policy language across all three is usually hiding the seams. The part I am most interested in right now is workload identity. For years, we secured machines the same way we secured people, with long-lived static credentials sitting in config files waiting to leak. That model is finally dying. Short-lived, attested identities through approaches like SPIFFE and workload identity federation are a much better answer, because the credential expires before an attacker can do much with it. For human and customer identity, the rules are simpler, but the stakes are higher. Kill static keys, federate to one source of truth, and treat access review as something continuous rather than an annual audit nobody reads. Entitlement creep is the quiet killer here. People accumulate access and almost never lose it.

TCE: What role do you see AI playing in improving reliability and security operations (AIOps/DevSecOps)?

Advait Patel: I will give you the unfashionable version. AI is genuinely good at one specific thing in security operations and oversold at most of the rest. The thing it is good at is the layer between detection and action. You run a scan, you get 200 findings, and historically, a human burns half a day working out which three actually matter for their system. AI is very good at that triage and at explaining a finding in the context of your specific setup. That is most of the real value, and it is the whole reason I built DockSec the way I did. Where it gets oversold is autonomous action in production and the idea that it replaces the analyst. It does not. The right pattern is AI sitting on top of deterministic signals, not in place of them. A coding assistant telling you a Dockerfile looks fine does not survive an auditor's first question. You still need the scanner underneath and the human judgment on top. And there is a twist people forget. AI is also a new attack surface. Agentic systems can be manipulated through their own inputs in ways we are only starting to score properly, which is part of why I put time into AI-specific vulnerability scoring. We are adding capability and risk in the same motion.

TCE: How can teams balance automation with human oversight in incident response?

Advait Patel: My rule of thumb is to automate the reversible and the boring and keep humans on the irreversible and the ambiguous. Automation is excellent at the parts of incident response that are well understood and repetitive. Detect a known pattern, enrich it, page the right person, contain something you have contained a hundred times. That should all run at machine speed. Where I get nervous is letting automation take actions with real blast radius on its own, because automation fails confidently and at scale. A human making a bad call breaks one thing. A bad automated remediation can take the whole fleet down before anyone has read the alert. So I think of it as trust earned in increments. New automation runs in suggest mode first, where it only tells you what it would have done. Once it has been right enough times on low-risk actions, you let it act on those, and you keep the high-consequence decisions with a person. The piece people skip is the after. Humans own the retro and the learning. You do not automate understanding why it broke.

TCE: What are the most important security practices for containerized environments today?

Advait Patel: A few that matter more than the rest. Start small. Minimal base images and multi-stage builds do more for your posture than almost any tool you can buy, because you cannot be vulnerable to something that is not in your image. Most containers ship with a full operating system that they never touch. Do not run as root, and drop the capabilities you do not need. It is basic, and people still skip it. Care about provenance. Sign your images, generate an SBOM, and know where your base layers came from, because you inherit every vulnerability in them, whether you wrote that code or not. The supply chain is where the interesting attacks are now. But the practice I would push hardest is making your scanning actionable. A report with 200 CVEs that nobody can act on is security theater. The problem most teams actually have is not detection, it is prioritization and remediation. Coverage without a path to a fix just manufactures guilt. Closing that gap between found and fixed is what genuinely moves your risk down, and it is the problem I have spent the most time on.

Conclusion

From securing observability platforms handling millions of data points per second to managing identity across multi-cloud environments, Advait Patel's experience highlights the practical challenges facing today's infrastructure teams. His views on automation, AI, incident response, and container security reinforce a common theme throughout the discussion: the growing overlap between SRE and Security Engineering.

As organizations continue to modernize their cloud environments, the ability to balance reliability, security, and operational efficiency will become increasingly important. For teams navigating that shift, Patel's insights offer a grounded perspective on what it takes to build and secure systems at scale.

Develop smarter AI agents with data fabrics

Tue, 16 Jun 2026 11:03:45 +0200

Every organization has data scattered across data warehouses, data lakes, SaaS platforms, cloud drives, and data centers. Data fabrics enable organizations to centralize and control data access, making it easier for users, such as data scientists and citizen data analysts, to find and use trusted and governed data sources.

Data fabrics, data meshes, and distributed data clouds are all platforms to help IT and data teams put some order to the chaos around the myriad of data sources they support. Large companies need data fabrics due to the volume and variety of their data sources.

“A data fabric can be thought of as the connective tissue that ensures consistent accessibility, availability, and understanding of data across an organization,” says Dominic Wellington, data and AI expert at SnapLogic. “Individual siloed platforms may have their own internal data transfer systems, and particular teams or departments may adopt interchanges that work for that domain, but a data fabric operates at a higher level, ensuring that unified data policies are applied end-to-end across the entire enterprise.”

Types of data fabrics

When reviewing data fabrics, it’s important to consider their primary use cases, supported data types, data processing capabilities, data management structures, and governance functions. Below are some considerations when reviewing data fabrics as features, platforms, and stand-alone products.

Some data fabrics are optimized for analytics and machine learning use cases and may have limited support for unstructured data.
Other data fabrics extend the functionality of data governance platforms beyond data cataloging and metadata management and now include persistent data management, data quality, and dataops capabilities.
Many data integration and API connectivity platforms go beyond proxying, pipelining, and transforming data to include search, governance, and other capabilities from data centralization.
Some SaaS platforms are extending their connectivity and data integration capabilities, enabling multicloud portability and persistent data.
The more advanced data fabrics support features needed for AI agents and AI model training. These platforms create a semantic context layer for structured and unstructured data sources, support Model Context Protocol (MCP) integrations, have real-time query capabilities, centralize policy-driven governance, and track data lineage.

Why data fabrics are needed for AI

Data fabrics are not just for enterprises, and today, even smaller companies need them as part of their AI democratization programs. Here are a few reasons why:

AI agents in enterprise SaaS solutions need access to broader data sets than those core to their workflows. Platforms such as Adobe, Appian, Oracle, Salesforce, ServiceNow, SAP, and Workday offer data fabric capabilities to bring data outside of the business processes they manage into scope for their AI agents.
Unstructured data is important for setting the context for AI agents, and data fabrics are now used to provide access to documents, emails, transcripts, and other media formats.
Data fabrics provide data access standards for the devops teams experimenting with AI code generators, vibe coding tools, and spec-driven development approaches to develop applications and AI agents.
As companies use MCP servers to connect AI agents, data fabrics provide a standardized way for the agents to access governed, trusted data sources.

“As AI agents move from generating insights to taking action, the data fabric becomes foundational in the agentic era,” says Irfan Kahn, president and chief product officer of SAP Data & Analytics. “Most enterprises operate across scattered data sources and diverse data landscapes, and what’s needed is shared business context, governed access, and clear accountability for how data is used in decision-making. Without that context, agents can’t fully understand or coordinate across the enterprise to deliver meaningful value.”

Sanjay Koppikar, chief product officer and cofounder of EvoluteIQ, adds, “Multi-agent architectures become untrustworthy when a unifying data fabric architecture is missing, since agents will often work against each other in the service of their own objectives.”

Delivering context to AI agents

AI agents need a combination of real-time data, user information, problem details, and historical context to guide their decision-making. Vishal Sood, president of research and development at Typeface, says, “MCP and data fabrics give agents access, but the harder problem is contextualizing data across multiple sources and ensuring the underlying content, media, and unstructured data are trustworthy.”

Data fabrics are the foundational elements for providing current information and long-term memory to AI agents. They simplify the many-to-many problem of connecting multiple AI models, AI agents, and MCP server integrations to multiple structured and unstructured data sources.

“The data fabric does a beautiful job of encompassing three concepts needed to create applications and processes: the data catalog, the data model, and data access,” says Sanat Joshi, executive vice president of product and innovations at Appian. “But now add business rules, process models, APIs, security groups, the organizational model, and their interrelationships into one unified view of the enterprise, and that becomes your context layer.”

Integrations with data fabrics

Devops teams just getting started on an AI agent proof of concept may want to connect directly to the optimal data sources and APIs. Michel Tricot, CEO and cofounder at Airbyte, says connecting agents to live APIs is a great start, but it creates two big problems: APIs only return data that an agent already knows to ask for, and every query is an expensive API call chain that, with overhead, can overwhelm infrastructure in production volumes.

Tricot says the data fabric for AI use cases must be dynamic, leveraging discovery of available information from replicated data, fetching live contextual information, and writing the data back to business applications to update records.

Moving data in and out of the data fabric requires an integration strategy. Zero-ETL (extract, transform, load) is one low-cost, efficient approach for connecting to structured data sourced without replicating information. Once information is accessed centrally, it also enables streamlined security and governance.

“The promise of AI agents breaks down when they’re stuck waiting on brittle ETL, dealing with poor data quality, and lacking the right context to perform analysis,” says Preston Wood, chief security and strategy officer at Databahn. “Generating AI-ready data within a data fabric gives agents real-time access to operational data without the latency and drift that undermine decision quality. A well-architected data fabric provides the governance and lineage controls that let you deploy agents confidently, knowing exactly what data they’re touching and why.”

Centralizing AI-ready data

Data fabrics centralize AI-ready data and help data governance teams address data quality issues, biased data concerns, privacy compliance, and other data governance non-negotiables. Data fabrics also help address integration issues, monitor for data pipeline errors, and report on performance latencies. The result is that AI agents, models, and other analytics capabilities can then connect to trusted data sources with consistency.

“As AI agents and MCP architectures increasingly rely on data fabrics as their golden source of truth, data quality stops being a hygiene problem and becomes a trust problem, as we all know that trust is foundational to autonomous decision-making,” says Kellyn Gorman, database and AI advocate and engineer at Redgate Software. “Organizations that invest now in semantic consistency, lineage tracking, and observable data contracts across data fabrics will be the ones whose AI agents can be trusted to act without constant human correction.”

Data fabrics that support zero-ETL and other bidirectional integrations with sources thus become an organizational knowledge base, the data source for training AI models, and a foundation for producing data metrics.

“AI agents are only as reliable as the data they’re built on, and most organizations underestimate how much implicit tribal knowledge lives in their transformation logic rather than their source systems,” says Tobias Ostwald, director of analytics at NMI. “If you’re exposing a data fabric to agents or MCP integrations, you need lineage, testing, and metric definitions baked into the layer itself, not just documented somewhere, because the agent can’t call a colleague to gut-check a number.”

Streamlining security and governance

With a data fabric in place, governance, security, and other risk management leaders have a central location to manage data security, centralize access controls, and fulfill other governance responsibilities. Miles Ward, CTO of AI in Solution Lines at Insight, says, “We have to move past security by isolation to a governance model where the fabric itself enforces the pavement and walls of compliance.”

The data fabric also governs entitlements for AI agents and their users. Centralizing these business rules can help organizations avoid creating AI debt, a risk if controls are implemented directly in data sources or consumers.

“The convergence of AI-generated code sprawl and autonomous MCP connectivity creates a ‘perfect storm’ of architectural drift and toxic permission combinations,” says Karen Cohen, vice president of product at Apiiro. “Effective governance requires a security data fabric that monitors these autonomous connections in real time to enforce intent-based policies and strictly limit agent scope to its specific purpose. By integrating guardrails that align AI-assisted development with secure architecture principles, enterprises can proactively secure their expanding attack surface without sacrificing developer velocity.”

Future considerations for data fabrics

Expect vendors to expand the scope of their data fabrics beyond text and documents. Some will include specialized document processing for common formats such as invoices, contracts, and product documentation. There will be skills and tools to support industry-specific documents such as health records and construction documents. Others will support multimedia file types and provide metadata extraction and search capabilities.

“Enterprises are asking agents to reason across contracts, images, PDFs, and video, and this is where most data fabrics break,” says Dave Shuman, chief data officer at Precisely. “Multimodal data must be chunked, embedded, and governed with the same rigor as structured data, including lineage and access controls.”

Several other emerging capabilities include:

Extended support for AI agent interfaces to aid in data discovery, and with greater contextual controls on where and when AI agents can access sensitive data
Business ontologies, semantic layers, and knowledge graph capabilities, with management tools or integrations with third-party platforms
Support for data contracts, service-level agreements, centralized data observability, auditing, and other functions that will enhance explainable AI capabilities
Finops functions to track costs for data owners and consumers

As more companies depend on AI agents in their operations, expect top data fabric platforms to release capabilities to expand scope, scale, use cases, and governance.

How to Debug Linux Container Logs in Real-Time with Logdy (2026 Guide)

Tue, 16 Jun 2026 06:35:05 +0200

Logdy is a lightweight open-source log viewer that adds a web browser UI to any log stream. I show you how to install it on Linux and use it to debug Docker containers, systemd services, and multi-container stacks in real time without heavyweight observability platforms.

The causes of cloud outages are changing

Mon, 15 Jun 2026 19:33:57 +0200

For years, the cloud market has made a simple promise: Move workloads to large-scale platforms, gain better resilience, and worry less about downtime. That promise was never entirely wrong, but it is becoming less complete. The latest findings from Uptime Institute’s seventh Annual Outage Analysis suggest that the outage landscape is changing in ways that should concern both cloud providers and cloud customers. The biggest risks are no longer limited to broken physical infrastructure. They are increasingly tied to the complexity of the systems used to run, coordinate, update, and recover that infrastructure.

The most alarming number in the report is that IT and networking issues accounted for 23% of impactful outages in 2024. Uptime Institute links these increases to growing IT and network complexity; the long-term shift toward colocation, cloud, and third-party digital services; and the resulting increase in change-management failures and misconfigurations. That number is more than a statistical footnote. It points to a structural change in how outages happen and why cloud outages are becoming such a stubborn problem.

Hardware redundancy can protect against component failures, but it doesn’t help much when the outage stems from a bad configuration, an automation error, a faulty network change, or an underappreciated control-plane dependency. In those cases, the infrastructure itself may remain intact while the system that governs it breaks down. The industry is learning that resiliency is less about duplicating equipment and more about managing complexity. Today’s increasingly distributed and software-defined environments cannot operate safely at scale.

Failures at the operational level

Uptime’s findings show that power remains the leading cause of major outages, underscoring that traditional infrastructure engineering still matters a great deal. But even as providers continue to improve physical resilience, outages can still arise from the digital and procedural layers above it. Cloud platforms are now dense stacks of services, APIs, orchestration systems, software-defined networks, identity controls, failover logic, and third-party dependencies. That complexity creates more possible points of interaction and more opportunities for an error in one layer to cascade into several others.

This helps explain why outages can feel more surprising today than they did a decade ago. In older data center models, an outage often had a more apparent root cause, such as a power event, a cooling failure, or a hardware fault. In cloud environments, the trigger may be a small configuration change that propagates across regions, a policy update that unintentionally blocks service communication, or a network control failure that affects seemingly unrelated services. These are not failures of raw infrastructure capacity. They are failures of complexity management.

The report’s language around change management and misconfiguration is especially important because it challenges one of the most common assumptions in the cloud market: that scale automatically produces better operational outcomes. The reality? Scale can magnify both strengths and weaknesses. Large cloud providers have more engineering talent, more sophisticated tools, and more redundancy than almost any enterprise customer. But they also run far more interconnected systems at far greater speeds with far more automation. A single process failure can have a wider blast radius.

Another important lesson from the Uptime analysis is that automation has not removed the human factor. If anything, it has changed its form. Even in highly automated environments, human error remains central to the problem. The report notes that in 2025, the share of outages caused by human failure to follow procedures rose by 10 percentage points compared with 2024. A related industry summary of the report notes that 58% of human error-related outages were caused by staff failing to follow established procedures.

That matters because cloud providers often position automation as the answer to reliability. Automation is essential, but it only works as well as the operational model that surrounds it. If teams deploy changes too quickly, rollback paths are weak, approval chains are bypassed, or procedures are incomplete, automation can accelerate failure rather than prevent it. In a modern cloud environment, a human mistake is rarely just a single keystroke. It is more often a design weakness in process, governance, testing, or accountability.

This is also why customers should resist the comforting notion that outages are somebody else’s problem once workloads move to the cloud. Provider-side mistakes remain real, but customer architectures are increasingly entangled with provider networking, identity, observability, and platform services. When an outage occurs, the customer may not have caused it, but they still bear the business impact. The shared responsibility model does not end with security. It extends to resilience planning as well.

Better change management

The Uptime data points to a clear conclusion: Cloud providers need to treat operational discipline as a first-class design requirement. That starts with better change management. High-risk changes should be tested more aggressively, staged more gradually, and accompanied by stronger rollback mechanisms. Providers also need better dependency mapping to understand how a change in one control layer can affect services far beyond its immediate scope. If the system is too complex to clearly explain, it is too complex to operate.

Providers also need to improve procedural quality. The rise in outages caused by failing to follow procedures suggests that procedures are being ignored under operational pressure or that they are too cumbersome, outdated, or unclear for real production conditions. Neither explanation is comforting. Stronger runbooks, better training, more realistic failure drills, and tighter operational guardrails are not glamorous investments; they are increasingly central to resilience.

Another pressure point is visibility. Uptime notes that software-based and distributed resiliency tools can improve availability, but they also introduce new risks and complicate root-cause analysis. Cloud providers need more transparent and faster incident diagnosis, not just more layers of abstraction. Customers cannot build trust in resilience if every major incident becomes a long exercise in reconstructing opaque service dependencies after the fact.

Design with outages in mind

What’s the financial impact of more frequent problems? Uptime’s 2024 analysis found that 54% of respondents reported that their most recent significant outage cost more than $100,000, and 20% said it cost more than $1 million. These are not edge-case losses. They show that outages remain costly even if they are less frequent than in earlier years.

Customers need to stop evaluating cloud resilience through uptime promises and start evaluating it through failure behavior. How does a provider isolate faults? How transparent is incident communication? How portable are workloads if a major service degrades? How dependent is the architecture on a single region, network path, identity service, or control plane? These are not just technical questions; they are now critical business questions.

The core lesson from Uptime’s data is simple. Outages are becoming a bigger problem for cloud providers and customers because the cloud’s biggest vulnerabilities are increasingly tied to complexity, process failures, and control-plane mistakes, not just broken infrastructure. In addition to adding redundancy, the next phase of cloud improvement will focus on building systems that are easier to understand, safer to change, and more disciplined to operate.

Tokenomics in enterprise AI

Mon, 15 Jun 2026 12:05:48 +0200

Tokenomics has quickly become one of the most practical subjects in enterprise AI. In simple terms, it is the discipline of understanding how tokens are consumed, how that consumption turns into cost and how an organization can shape usage patterns so that AI remains valuable without becoming financially unpredictable. In most large language model services, every prompt, every retrieved context block, every tool description, every system instruction and every generated response contributes to the token bill. That means the economics of AI are no longer driven only by licenses or infrastructure. They are increasingly driven by usage behavior, prompt design, model choice and governance decisions. For technology leaders, this creates a new operating responsibility: they must treat tokens the way they already treat compute, storage and network consumption. Token usage needs to be measured, planned, optimized and governed with the same discipline as any other cloud resource.

Understanding tokenomics in AI services

A token is the smallest billing unit used by many AI services to represent pieces of text, code, symbols or structured content processed by the model. A single user request usually consumes input tokens and output tokens. Input tokens come from the instructions sent to the model, including the system prompt, user prompt, conversation history, retrieved documents, tool schemas and metadata. Output tokens are the tokens generated in the response. In most commercial AI services, output tokens are priced higher than input tokens, which means long and unconstrained responses can silently become one of the largest sources of waste. This matters even more in enterprise settings where thousands of requests are executed every day across assistants, search copilots, engineering agents, document summarizers, support bots and automated workflows.

width="1024" height="522" sizes="auto, (max-width: 1024px) 100vw, 1024px">

Token optimization in AI services.

Magesh Kasthuri

In practice, token costs are shaped by a handful of recurring patterns as per the Gartner report. The first is context inflation, where applications keep sending large prompt prefixes, verbose policy instructions, long chat history and oversized retrieval payloads on every call. The second is poor model matching, where high-end models are used for routine tasks such as classification, extraction, formatting or test data generation, even though smaller and cheaper models would do the job well. The third is response sprawl, where no output length controls are enforced and the model returns far more text than the user or process actually needs. The fourth is retry amplification, where agentic or automated workflows invoke the model repeatedly because the surrounding application lacks validation, caching or routing logic. Once AI usage expands across departments, these issues accumulate rapidly and can distort the economics of a program even when the underlying models are technically sound.

How an organization should plan token optimization

Organizations that manage AI well do not begin with model selection alone. They begin with operating intent. That means clearly identifying which use cases need premium reasoning, which use cases can tolerate lower latency or asynchronous processing, which ones need strict output controls and which ones are suitable for summarization or retrieval before generation. You can refer to Gartner’s “Tokenomics will become a new discipline” for guidelines.

A sensible token optimization plan usually starts with workload segmentation. Interactive experiences such as executive copilots, complex engineering assistance or contract analysis may justify higher-quality models. Routine workloads such as log classification, regression test explanation, boilerplate documentation, FAQ answering and metadata tagging often do not. Segmenting workloads this way allows the enterprise to create a service catalog for AI usage rather than exposing every consumer to the most expensive model by default.

The next step is governance. Every enterprise AI platform should collect token telemetry at the request level and aggregate it by application, environment, team, model and use case. Without that visibility, optimization becomes guesswork. Leaders should define token budgets, monthly thresholds, rate limits and environment-specific quotas. It is also wise to introduce approval paths for long-context models, tool-heavy agents and experimental multi-step reasoning workflows because these patterns can multiply token consumption very quickly.

A mature operating model also includes prompt standards, retrieval size limits, output token caps, response templates and model routing policies. This turns token optimization into an engineering discipline rather than a one-time cost exercise. When done well, the organization creates a feedback loop where usage data improves architecture decisions and architecture decisions reduce unnecessary consumption over time.

Core token optimization techniques across cloud AI platforms

Some optimization practices are effective regardless of whether the organization is using AWS, Azure or Google Cloud. The first is prompt minimization with purpose. This does not mean making prompts unnaturally short. It means sending only the instructions and context required for the current task. Static instructions should be kept stable and separated from dynamic content. Retrieved documents should be ranked and trimmed instead of being attached in full. Tool definitions should be exposed only when needed. Few-shot examples should be used selectively and removed when they no longer improve quality. In many enterprise systems, the easiest savings come not from changing the model, but from removing repetitive and low-value prompt baggage. You can refer to Deloitte’s report “The pivot to tokenomics” for more details on this scenario.

The second technique is model routing. Not every prompt deserves the largest model. A classifier, router or policy layer can evaluate the request and direct simple tasks to lighter models while reserving premium models for complex reasoning, domain-sensitive analysis or code-heavy interactions. The third technique is response shaping. If the application needs three bullet points, a JSON object, a summary or a fixed-length explanation, that expectation should be explicit. Output token controls, concise formatting instructions and schema-bound responses help contain cost while also improving consistency. The fourth technique is caching. Repeated prompt prefixes, repeated documents, repeated tool descriptions and repeated intermediate outputs should be cached wherever the platform allows it. Prompt caching can reduce the need to recompute long shared prefixes, while response caching prevents duplicate model calls for frequently repeated requests. These approaches are especially valuable in internal copilots, support bots and engineering assistants where repetitive interactions are common. AWS, Azure and Google Cloud all support variations of context or prompt caching for repeated content, which can significantly reduce repeated input-token processing when prompts share the same stable prefix.

The fifth technique is asynchronous and batch execution for non-urgent work. Many AI jobs inside enterprises do not need interactive response times. Offline summarization, document enrichment, code review snapshots, test case explanation, defect clustering and log interpretation can often be queued and processed later at lower cost. The sixth technique is context lifecycle management. Long conversations and agent sessions must be pruned, summarized or checkpointed instead of carrying the full history forever. If a session needs memory, a summarized state is usually cheaper than replaying every turn. In retrieval-augmented systems, only the top-ranked passages should be injected into the prompt and documents should be chunked intelligently so that the model receives the smallest high-value context possible. These changes reduce cost, improve latency and often improve answer quality because the model is forced to focus on more relevant inputs.

Token optimization on AWS

On AWS, token optimization typically centers on Amazon Bedrock and the architecture built around it. A strong starting point is model selection by task type. Bedrock gives organizations access to multiple foundation models and that creates an opportunity to route simple workloads to smaller models and reserve more capable models for difficult reasoning or coding tasks. This is often the single biggest cost lever. Another major lever is prompt caching. Amazon Bedrock supports prompt caching for supported models, allowing repeated prompt prefixes to be reused instead of being recomputed on every request. This is particularly useful when the application repeatedly sends large system instructions, policy context, product manuals or codebase guidance. Bedrock documentation explains that cached prefixes can reduce latency and lower input-token cost for repeated context, with model-specific checkpoint thresholds and time-to-live behavior. [Amazon Bedrock]() prompt caching can reduce repeated input processing when stable prompt prefixes are reused across calls.

width="1024" height="575" sizes="auto, (max-width: 1024px) 100vw, 1024px">

Figure: Token optimization in AWS

Magesh Kasthuri

AWS environments also benefit from separating real-time and non-real-time inference paths. Bedrock batch-style or queued processing patterns are far more economical for workloads such as nightly test artifact analysis, bulk document summarization, defect triage and generated knowledge extraction. Engineering teams should also place a policy layer in front of Bedrock to cap output size, restrict unsupported long-context prompts and enforce retrieval limits. If the application uses agentic orchestration, every tool call and every retry should be monitored because agents can consume tokens far faster than interactive human users. A practical AWS pattern is to combine Bedrock with a lightweight gateway that logs tokens per request, tags usage by environment and application and routes requests to the least expensive model that still meets quality objectives. This gives CIO and CTO teams better visibility into where token spending is justified and where it is simply accidental.

Token optimization on Azure

On Azure, token optimization is often discussed in the context of Azure OpenAI and Microsoft Foundry model services. Azure provides one of the clearest examples of prompt caching as a cost and latency lever. Microsoft documentation explains that prompt caching can reduce repeated processing of identical prompt prefixes and supported models can keep cached prefixes available for short in-memory periods or extended retention windows, depending on the model and configuration. To benefit from this, organizations must structure prompts carefully. Stable content, such as system instructions, compliance rules, coding standards or tool schemas, should appear at the beginning of the request, while variable user content should appear later. [Microsoft Foundry]() documents that prompt caching applies to supported Azure OpenAI models when prompts meet minimum length and prefix-match requirements, helping reduce latency and input-token cost.

width="1024" height="295" sizes="auto, (max-width: 1024px) 100vw, 1024px">

Figure: Token optimization in Azure

Magesh Kasthuri

Azure environments are also well-suited for strong observability. Organizations can capture request telemetry, prompt tokens and completion tokens through platform diagnostics and application-level logging, then correlate that usage with deployment names, environments and business applications. This makes it easier to spot noisy prompts, excessive completions or teams that are using premium models for low-value work. In mature Azure estates, leaders often separate pay-as-you-go experimentation from predictable, high-volume workloads. Stable workloads may justify reserved or provisioned capacity, while spiky or uncertain workloads can remain on variable pricing. For DevTest, Azure teams should use model allow-lists, token ceilings and shorter retention periods for conversation history. Developers should never have unrestricted access to large-context and premium reasoning deployments unless the workload genuinely requires it. Governance is most effective when prompt templates, response formats, budget thresholds and environment-level quotas are built into the platform rather than enforced only by policy documents.

Token optimization on Google Cloud

On Google Cloud, token optimization is commonly associated with Vertex AI and Gemini-based workloads. Google Cloud has emphasized context caching as a way to reduce the cost of repeatedly sending large prompt content such as detailed instructions, codebases, multimodal assets or long documents. Vertex AI supports both implicit and explicit caching patterns, which allow organizations to either benefit from automatic reuse or deliberately persist reusable context for predictable savings. Google notes that Vertex AI context caching reduces repeated token processing and can lower the cost of cached tokens for supported Gemini models, while also improving latency.

width="1024" height="538" sizes="auto, (max-width: 1024px) 100vw, 1024px">

Figure: Token optimization in GCP

Magesh Kasthuri

Google Cloud also offers a practical ecosystem for prompt improvement and token discipline. Vertex AI prompt optimization capabilities help teams refine prompts so that they are clearer, more compact and more effective without depending on excessive examples or unnecessary instruction text. That matters because poor prompts often lead to repeated retries, broader context injection and inflated output lengths. Another valuable pattern on GCP is workload routing through Model Garden or application logic so that lower-cost models handle straightforward summarization, extraction and routing tasks while premium models are reserved for high-value reasoning. In large enterprise deployments, teams should also use token-count estimation before execution for expensive workflows, especially when long documents, code repositories or multimodal content are involved. This creates a preflight check that can stop oversized requests before they reach production inference paths.

Real-time example: AI-powered test failure analysis in a DevTest program

Consider a large engineering organization that uses AI to analyze failed test cases during continuous integration. Every failed build triggers an AI workflow that reads stack traces, selected log fragments, recent code changes, known defect patterns and testing guidelines, then generates a root-cause summary and recommended next steps for developers. At first, the team builds the solution straightforwardly. It sends the entire recent build log, the full testing policy, the complete conversation history from the issue thread and a long instruction template to a premium model for every failure. The results are useful, but the token bill rises sharply. The reason is obvious in hindsight: the same policy content is sent repeatedly, the logs are far longer than necessary and many failures are routine enough that they do not require the most capable model.

Now, imagine the same workflow after token optimization. The platform first classifies the failure type. If it is a known regression signature, a smaller model handles the explanation. Only ambiguous failures go to the premium model. The testing policy and coding standards are moved into a reusable cached prefix. The log stream is preprocessed so that only the most relevant error windows and surrounding events are included. Older conversation turns are summarized into a short state object instead of being replayed in full. The response is constrained to a fixed template: probable cause, impacted component, confidence level and recommended action. If the same failure signature appears again, the prior explanation is served from the response cache unless recent code changes suggest a new interpretation. This redesigned flow typically reduces unnecessary input tokens, lowers output verbosity and improves turnaround time. More importantly, it turns AI usage into a disciplined engineering service rather than a loosely controlled experimental feature.

How CIOs and CTOs can optimize AI usage in DevTest

DevTest environments are where token waste often hides in plain sight. Teams experiment freely, prompts change often, logs are verbose and developers naturally gravitate toward the best available model because they are trying to move quickly. That is exactly why CIO and CTO leaders need a distinct DevTest token strategy rather than simply copying production policies. The goal in DevTest is not to eliminate experimentation. The goal is to make experimentation cost-aware. A sensible starting point is environment segmentation. Sandbox, development, testing, performance validation and pre-production should each have their own token budgets, model permissions and rate limits. Premium reasoning models should be limited to approved scenarios, while most routine experimentation should default to cheaper models with smaller context windows.

Leadership teams should also insist on a small set of operating controls. First, every DevTest AI request should be tagged with application, team, engineer, environment, model and use case so that usage can be traced accurately. Second, token ceilings should exist at both user and application level, with alerts when thresholds are crossed. Third, platform teams should provide reusable prompt templates that are already optimized for brevity, schema-based output and caching compatibility. Fourth, batch windows should be used for heavy non-interactive workloads such as codebase summarization, test artifact enrichment and bulk defect clustering. Fifth, long-running agent workflows should be monitored for retry loops and context growth, because these are common sources of runaway consumption. When these controls are present, DevTest remains innovative without turning into an uncontrolled cost sink.

From an executive planning perspective, CIOs and CTOs should treat AI token usage as part of both cloud FinOps and engineering governance as you can read from this forbes report on “Best practices for designing effective Tokenomics”. Monthly reviews should not focus only on total spend. They should examine token consumption per workflow, cost per successful outcome, model utilization by task category, cache hit rates and the percentage of requests routed to lower-cost models. Teams that repeatedly exceed expected token usage should not simply be blocked; they should be helped to redesign prompts, reduce retrieval payloads, improve orchestration logic and replace verbose responses with structured outputs. This creates a healthier operating culture. The conversation moves away from restricting AI and toward making AI economically sustainable at scale. That shift is important because enterprise AI programs succeed not when usage is unlimited, but when value and consumption stay in balance.

Conclusion

Tokenomics is now a foundational part of enterprise AI architecture. As organizations scale AI across engineering, operations, support and knowledge work, token usage becomes a direct determinant of cost, responsiveness and sustainability. The most effective organizations plan for this early. They segment workloads, match models to task complexity, constrain outputs, trim context, use caching intelligently, batch non-urgent work and govern DevTest with the same seriousness they apply to production infrastructure. AWS, Azure and GCP each provide useful mechanisms to support this approach, but the bigger advantage comes from disciplined design. When token optimization is treated as a core architectural practice, AI programs become easier to scale, easier to govern and far more likely to deliver measurable business value without waste.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Architecture-as-code is the next frontier for enterprise governance

Mon, 15 Jun 2026 11:08:18 +0200

Enterprise architecture governance has always carried a difficult mandate: helping organizations move faster without allowing technology decisions to fragment, duplicate or create unacceptable risk. In large enterprises, that mandate is usually executed through review boards, standards, approved patterns, reference architectures and experienced architects’ judgment. These mechanisms remain necessary, especially in regulated environments, but are increasingly strained by cloud adoption, AI systems, managed services, data platforms and continuous delivery.

Most organizations do not lack architectural intent. They have security standards, cloud patterns, integration principles, data-classification policies, resilience expectations, review forums and exception processes. Too much of this intent remains trapped in documents, slide decks, meeting notes and expert interpretation. That model can work when architecture change is episodic, but it becomes harder to scale when teams are continuously changing APIs, cloud configurations, data flows, identity patterns, observability settings, dependencies and third-party service integrations.

Architecture-as-code offers a different operating model. Instead of treating architectural standards as documents to be interpreted manually, it treats architectural intent, approved patterns, evidence requirements, exceptions and review outcomes as machine-readable artifacts that can be versioned, evaluated, tested and observed. The goal is not to reduce enterprise architecture to infrastructure-as-code, but to make architectural constraints and evidence expectations executable enough to participate in the software delivery lifecycle.

The idea has parallels in software architecture and platform engineering. Thoughtworks has discussed architecture-as-code in the context of fitness functions, while the evolutionary architecture community has used fitness functions as automated checks that preserve architectural characteristics as systems evolve. The next step is applying similar thinking to enterprise architecture governance.

From point-in-time review to continuous architecture assurance

In many enterprises, architecture governance is still organized around a point-in-time review model. A team prepares a design package, presents it to an architecture review board, receives feedback, records decisions or exceptions, and proceeds into delivery. This model remains useful when a system is new, high-risk or materially changing because it creates a forum for judgment, enterprise alignment, risk acceptance and trade-offs.

Its weakness is that software systems do not remain static after the review meeting. APIs change, authentication patterns evolve, cloud services are added, data flows expand, observability settings drift and implementation details diverge from original design assumptions. In traditional governance models, that drift often becomes visible only during a later review, an audit, a production incident or a security assessment.

Architecture-as-code creates the possibility of moving from episodic review to continuous architecture assurance. The analogy is automated testing. Software teams did not eliminate human judgment about quality, but they moved repeatable checks into the delivery pipeline so regressions could be detected earlier and more consistently. Architecture governance can follow a similar pattern: review boards should still handle judgment, trade-offs, exceptions and accountability, while basic conformance checks become executable and repeatable across the software lifecycle.

This is not a purely theoretical direction. The second edition of Building Evolutionary Architectures explicitly connects fitness functions with the automation of architectural governance, while Open Policy Agent provides a well-established policy-as-code precedent for enforcing rules across microservices, Kubernetes, API gateways and CI/CD pipelines. In both cases, the underlying lesson is similar: when important system properties can be expressed as executable checks, governance can move closer to the point where change happens.

In practice, this means architecture evidence can be evaluated when a design brief changes, when an OpenAPI specification is updated, when infrastructure configuration is modified, when a pull request introduces a new dependency or when a service is promoted toward release. The goal is not to turn architecture governance into a rigid gate for every code change. It is to make architectural drift more visible and to surface evidence gaps before they become late-stage delivery risks.

A governance workflow for software delivery

A practical architecture-as-code workflow should sit inside the software delivery lifecycle, not outside it. It should not wait until a final review meeting to discover basic gaps. It should evaluate architecture evidence as part of design iteration, pull requests, CI/CD runs, release readiness checks and periodic posture reviews.

This structure is deliberately layered. Deterministic controls handle what should be deterministic. Human review handles what requires accountability and judgment. AI assists with interpretation and review preparation, but it does not own the decision.

Nitesh Varma

Figure 1: Architecture-as-code embeds governance into the software delivery lifecycle. Design intent and implementation evidence are evaluated through deterministic controls, interpreted by AI-assisted review, and returned to human architects for judgment, exceptions and risk acceptance.

The critical move is comparing what a team claims architecturally with what the implementation evidence shows. Many governance processes rely too heavily on what the design package says. A team may declare that a public API uses an approved identity pattern, that sensitive data is classified, that observability requirements are met or that a threat model exists. Those claims may be accurate, but they still need supporting evidence.

A stronger model compares declared intent with observable implementation signals. If a design brief says a public API uses OAuth/OIDC, but the OpenAPI specification defines an API-key security scheme, the governance issue is not simply that authentication failed. It is that implementation evidence does not support the declared architecture intent. The team may need to update the implementation, correct the design brief or submit a time-bound exception with compensating controls.

Similarly, if a public webhook has proper authentication evidence but no threat model or architecture decision record, the right conclusion may be “needs more evidence,” not “non-compliant.” Governance should distinguish between direct control violations, missing evidence, incomplete documentation, contextual risk and passed controls. That classification makes governance more useful to engineering teams and more defensible to security, risk, audit and compliance.

The role of AI: interpretation, not authority

The rise of agentic AI makes architecture-as-code more interesting, but also more dangerous if framed poorly. The wrong framing is that AI will automate the architecture review board. That would be naïve. Architecture approval involves accountability, risk acceptance, organizational priorities, cost, regulatory obligations, delivery sequencing and long-term platform direction. Those are not decisions that should be delegated to an LLM.

AI’s more credible role is downstream of deterministic evaluation. Once controls-as-code have produced findings, an AI-assisted governance layer can interpret them, draft remediation guidance, identify review questions and prepare an architecture review narrative. It can help architects distinguish hard violations, evidence gaps, design-implementation mismatches and possible exception candidates.

For example, a deterministic control engine might produce the following result:

AUTH-001: Claim/evidence mismatch
Design brief declares OAuth/OIDC.
OpenAPI implements API key.
Outcome: human review required.
CI action: require review.

An AI-assisted governance layer can turn that into a more useful review narrative:

The primary governance concern is that the implementation evidence contradicts the declared authentication pattern. Before this design can proceed, the team should either align the OpenAPI specification and implementation with the approved OAuth/OIDC pattern or submit a time-bound exception with compensating controls. The missing threat model and incomplete observability evidence further prevent the package from being approval-ready.

The AI is not deciding the outcome; it is preparing the human review.

The same AI layer can perform a reflection pass, checking whether its narrative overstated a finding, softened a deterministic failure, confused missing evidence with confirmed non-compliance or introduced unsupported claims.

To make that separation concrete, I built a small architecture-as-code sandbox using bounded API governance scenarios. It is not a production governance platform. It is a working demonstration of the operating pattern: design intent is declared, implementation artifacts provide evidence, controls-as-code evaluate the package, a deterministic policy gate assigns a bounded posture, AI assists with interpretation and human architects remain accountable.

A project registry points to design briefs, OpenAPI specifications, architecture decision records, threat models and evidence files. Controls then evaluate whether the declared design intent is supported by the actual implementation artifacts.

The most useful sample case was a public customer-profile API where the design brief declared OAuth/OIDC, but the OpenAPI specification implemented API-key authentication. The deterministic engine classified this as a claim-evidence mismatch, assigned the case to human review and generated remediation guidance. The AI-assisted layer then produced a review narrative and reflection check but did not change the outcome.

Other samples exercised different governance postures. A public webhook with authentication but no threat model or architecture decision record produced “needs more evidence,” while a public API with no authentication produced “does not meet standard.” These distinctions matter because enterprise architecture governance should not treat every gap as the same kind of issue.

Architecture governance becomes part of delivery

One important implication is that architecture governance becomes observable. A review is no longer just a meeting, a diagram or a document attached to a ticket. It becomes a run with inputs, controls, evidence, findings, policy outcome, remediation guidance and review artifacts. In the sandbox, I used MLflow as a lightweight run ledger to capture governance metrics and review artifacts for later inspection.

This does not eliminate formal approvals, but it gives them a stronger evidence base and useful operating history. Architecture leaders could see which controls fail most often, where evidence is frequently missing, which patterns generate exceptions and where standards may be unclear.

This matters even more as organizations adopt AI systems, which increase the need for architectural discipline around data flows, observability, model interactions, security boundaries, policy constraints, operational ownership and runtime monitoring. If governance remains manual and episodic, it will struggle to keep pace. If it becomes executable and observable, it can become part of the delivery system.

The danger is automated governance theater. A system can generate polished reports, plausible AI narratives and dashboards while still resting on vague standards or incomplete evidence. Automation does not fix unclear architecture principles. AI does not compensate for missing accountability. A policy gate is only useful if the underlying controls are meaningful.

Enterprises should therefore treat architecture-as-code as an operating-model change, not just a tooling pattern. The model works only when standards, approved patterns, evidence expectations and exception processes are explicit enough to be evaluated consistently. Exceptions need owners, expiry dates and rationale; deterministic controls need to remain separate from AI interpretation; and human accountability must remain visible throughout the process.

This is why the agentic AI layer should be bounded. It can summarize, interpret, critique, prepare review materials, propose architecture board questions and identify missing artifacts. But it should not override policy gates or approve high-risk designs. The stronger architecture is one in which deterministic controls produce the governance posture, AI explains it and humans decide what to do.

The strategic shift is that architecture governance can move closer to the rhythm of software delivery. Not every architecture concern becomes a CI/CD rule, and many decisions will still require judgment, negotiation and risk acceptance. But many governance signals can be surfaced earlier, more consistently and with better evidence.

The goal is not to replace the architecture review board with software. It is to ensure that architecture review is no longer confined to a single meeting, a static document or a one-time approval. Like automated testing, architecture governance should become a repeatable signal that travels with the system as it changes.

Architecture-as-code creates the foundation, agentic AI adds a reasoning and narrative layer, CI/CD provides the control point, run logging provides observability and human review preserves accountability.

As systems become more distributed, cloud-based, AI-enabled and continuously delivered, enterprise governance cannot depend on static standards and periodic reviews alone. Architecture-as-code offers a path toward governance that is executable, evidence-driven, observable and accountable to human judgment.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

5 runtime signals for catching a compromised AI agent

Mon, 15 Jun 2026 11:08:16 +0200

In June 2025, Simon Willison, the engineer who coined the term “prompt injection,” published a warning that circulated widely through the security community. He called it the lethal trifecta — three capabilities that, when combined in a single AI agent, create a near-guaranteed path to exploitation through indirect prompt injection: access to private data; exposure to untrusted content; the ability to communicate externally.

The framing was sharp and useful. If your agent reads your email, ingests arbitrary web content, and can make outbound requests, an attacker who embeds malicious instructions anywhere in that content pipeline can direct the agent to exfiltrate your data without you ever knowing. Willison illustrated the point with a long list of real production exploits: Microsoft 365 Copilot, GitHub’s MCP server, GitLab Duo, Slack AI, Google Bard, Amazon Q. The same class of attack, over and over.

The trifecta worked as a signal because, at the time, agents were mostly narrowly scoped. An agent capable of performing only one or two of the lethal trifecta activities could be assessed as lower risk. Avoiding the combination felt like a viable design strategy.

That window has closed given what practitioners deploy today: A customer-facing support agent reads ticket histories and customer records, ingests user messages and attached files, and calls CRMs, refund APIs, or ticketing systems. An email AI reads your inbox and calendar, processes inbound messages from strangers, and sends replies on your behalf.

Rather than being edge cases or poorly designed deployments, these are the agents enterprises and individuals actually want, and they’re the ones vendors are building toward.

Lethal trifecta as default configuration

Ross McKerchar, CISO at Sophos, put it plainly in a piece published this May: “the capabilities practitioners actually want (read my data, understand external context, take action) push firmly into dangerous territory. This isn’t a misconfiguration; it’s the architectural cost of usefulness.” He’s right. An agent without private data access is useless, one that can’t process external content is isolated, and the one that can’t communicate externally is inert. Strip any leg of the trifecta and you have something closer to a search box than an agent.

If every legitimate agent architecture exhibits all three trifecta properties, the trifecta is no longer a meaningful indicator of elevated risk. It’s the default configuration. Treating it as a red flag is like treating DNS resolution as a signal of network compromise. Technically true in some threat models, but universally present in every real deployment.

McKerchar’s piece frames the response as “blast radius reduction”: a reasonable operational philosophy, but one that accepts the trifecta as a given condition rather than a preventable one. That’s a reasonable call. The question is what comes after the acceptance.

Meta’s security team arrived at the same conclusion from the other direction. In October 2025, they published the “Rule of Two,” a framework that recommends agents satisfy no more than two of the three trifecta properties in a single session, with human-in-the-loop approval required if all three are necessary. Willison himself endorsed the framework as “the best practical advice for building secure LLM-powered agent systems today.”

Meta’s limitations section, however, concedes that many sought-after use cases won’t fit the framework cleanly, and that “designs that satisfy the Agents Rule of Two can still be prone to failure.” That’s not a criticism of the framework but confirmation that the problem has outgrown the architecture-level solution.

The scale of exposure is no longer theoretical. Google’s April 2026 sweep of the Common Crawl repository found prompt injection attempts across public web pages, ranging from pranks to data exfiltration payloads, with malicious attempts up 32% between November 2025 and February 2026. Google noted sophistication remains low for now but flagged the trend as a signal of maturing attacker interest.

The environment the trifecta warned about has arrived.

How to sleuth out a compromised agent

If the trifecta describes nearly every deployed agent, practitioners need signals that distinguish compromised behavior from normal operation within a trifecta-exhibiting system. That means shifting from architecture-level assessments to runtime behavioral detection.

The production evidence arrived in a cluster. From Jan. 7 to Jan. 15, 2026, researchers disclosed exploits against four separate AI productivity tools in eight days: IBM Bob, Superhuman AI, Notion AI, and Anthropic’s Claude Cowork. Each used indirect prompt injection to exfiltrate data via a channel the agent had legitimate access to. In the Cowork case, a hidden prompt embedded in an uploaded document directed the agent to exfiltrate files via Anthropic’s own allowlisted API domain, invisible to any perimeter control and indistinguishable from normal agent behavior until the data was already gone. In all of these cases, the trifecta wasn’t a risk factor but the operating condition.

Here’s what’s worth watching to detect an agent has been compromised.

Instruction-following anomalies. A compromised agent doesn’t usually do something structurally different from a healthy one. Following instructions is its normal function. The difference is whose instructions it’s following. Look for agent actions that have no plausible correspondence to a user-initiated task. An agent that was asked to summarize a quarterly report but then attempts an outbound DNS request to an unfamiliar domain didn’t spontaneously decide to do that. Something in the content it ingested told it to.

Tool call sequences that break expected topology. In a well-designed agent system, the graph of tool calls for any given task should be relatively predictable. A coding agent invoked to fix a bug should touch files, run tests, perhaps check documentation. It shouldn’t be reaching for email or calendar APIs. Tool call sequences that cross expected workflow boundaries are worth flagging even when each individual call looks legitimate on its own.

Exfiltration via low-bandwidth channels. The classic prompt injection exfiltration attack routes stolen data through a mechanism the agent has legitimate access to: a rendered image URL with encoded query parameters, an API call with data embedded in a parameter, a link in a generated document. These don’t look like data theft in isolation; they look like normal agent output. Detection requires correlating what data the agent had access to against what it embedded in its output. That requires end-to-end visibility into the agent’s actions, not just the final response.

Credential and secret access outside task scope. If an agent with legitimate access to a secrets store or key vault touches credentials that have no relationship to the current task, that’s a signal. An agent fixing a React rendering bug should likely not be reading AWS credentials. Least-privilege scoping is the architectural defense here, but monitoring for out-of-scope credential access is the detection layer that catches failures in that scoping.

Memory-write anomalies. Agents with persistent memory are a growing attack surface. A poisoned memory entry that looks like legitimate user context but contains dormant trigger instructions can persist across sessions and fire long after the initial injection. Monitoring for memory-writes containing instruction-like content, or writes made during sessions that ingested untrusted content, is worth adding to any agent observability pipeline.

Runtime alone can address the agent redirection threat

For practitioners operating production agent infrastructure, the lethal trifecta tells you what you know: Your agents are exposed. The question is what to do about it.

The answers are at the runtime layer, not the architecture layer. That’s where EDR and SIEM live for traditional infrastructure — agents need the same instrumentation, and most deployments don’t have it yet. Full execution traces on every agent invocation. Tool call anomaly detection. Input screening at ingest. Credential access monitoring scoped to task context. Memory-write auditing. Not a human attacker logging in. An agent that’s been quietly redirected.

Willison’s trifecta was the right alarm for its moment, which was last year. Almost every production agent now fits the profile. Because of that, only runtime anomaly detection can potentially provide adequate defense. The above signals are a good place to start.

AI needs young developers – and old developers

Mon, 15 Jun 2026 11:03:22 +0200

Enterprises are increasingly investing copious amounts of cash in AI without a lot to show for it. This could be, in part, because the wrong people are leading the change.

As I’ve argued before⁠, AI isn’t likely to eliminate developers so much as change what we need from them. For example, we keep asking whether junior developers are needed in a world where large language models can write code faster and cheaper. What this overlooks is the reality that these younger developers and their relative inexperience may be exactly what we need to rewrite the rules of software development.

This thought hit me while reading James Governor’s riff on something Ben Griffiths⁠ wrote about our industry’s habit of confusing age with authority. Griffiths remembered sitting through a conference talk in which a speaker tried to shame a young audience for not recognizing some of the older men who had shaped computing. The irony, Ben noted, was that many of those “old men” had done their world-changing work when they were younger than the people being lectured. Bill Joy wrote vi when he was 22, John Carmack created Doom at 23, Linus Torvalds launched Linux at 22, etc. Many of our industry’s titans made their biggest contributions before they had decades of experience.

The point isn’t that young people are smarter. They’re not. The point isn’t that the key to AI success is to ignore more experienced developers. That’s dumb. Rather, it’s a suggestion that Griffiths’ larger point is right: At the beginning of big shifts, experience can be a mixed blessing. It can help you see risk, but it can also make you overconfident in old ways. The most successful enterprises will find ways to balance youthful innovation with experienced guardrails.

The factory doesn’t redesign itself

Zara Zhang recently pointed to Paul David’s classic 1990 paper, “The Dynamo and the Computer,”⁠ as a way to understand why so many companies have “adopted” AI without much to show for it. David’s argument, simplified, is that electricity didn’t immediately transform factories. For a long time, factories simply swapped out the central steam engine for an electric motor while keeping the same layout, the same workflows, and the same assumptions.

Electricity was new, but we largely stifled its potential by force-fitting it into old factory systems.

The big productivity gains came later, when factories stopped treating electricity as a cleaner steam engine and started redesigning work around smaller motors distributed throughout the factory. Once each machine could have its own motor, the factory no longer had to organize itself around a single driveshaft. Work could instead be reorganized around the flow of production.

That’s a decent description of where many enterprises are with AI. Enterprises today are buying copilot licenses by the thousands, wiring agents into existing applications, etc., and then wondering why the results are so uneven, as I’ve written⁠. This is the equivalent of swapping the steam engine for an electric one and declaring that the AI modernization work is done. It’s not. Not even close.

The real payoff won’t come from asking AI to write the same tickets a bit faster. It will instead come from changing how teams define work and how (and what) developers build. The “factory” has to change.

So here’s the uncomfortable question: Who is most likely to build the new factory?

Experience cuts both ways

There’s an obvious danger in romanticizing youth. Plenty of bad software has been written by people with unlimited confidence and limited context. Enterprises need software that works, yes, but “works” also means it complies, scales, respects security boundaries, and more.

This is where experienced developers matter. A lot.

As I pointed out recently, the agent era makes engineering judgment more important than ever. After all, AI makes it easier to generate code, but easier code generation can become easier technical debt generation. Hence, the limiting factor becomes less of “Can we create something?” and more of “Can we create the right thing, in the right place, with the right constraints?” Taste is required, in other words.

Senior engineers are often better at seeing those constraints because their experience gives them “taste.” They know why the weird validation rule exists, and they remember the customer who depended on the undocumented behavior. They understand why a simple schema change can turn into a multi-week migration.

But experience also has a shadow side, because it can make the current process feel inevitable. A senior engineer may see an AI assistant as a faster autocomplete because that’s the easiest way to fit AI into their existing mental model. A junior developer, less invested in the old workflow, may ask the more interesting questions: Why are we doing this ticket at all? Why isn’t the spec executable? Why can’t the agent generate the test harness first?

It’s not that the more experienced developers don’t know these questions. Rather, they may simply not have the energy to rage against the machine, as it were.

The value of inexperience

The worst way to use junior developers in the AI era is to treat them as cheaper versions of senior developers. That was always a bad idea, but AI makes it worse. If the job is “take this ticket, generate some code, and send it to a senior person for review,” the junior developer becomes a human wrapper around a coding assistant. That helps no one. The junior doesn’t learn much, the senior gets buried in review, and the enterprise ends up with more code, which, as I’ve said, is hardly a good thing.

Instead, junior developers should be given room to explore new workflows, with just enough oversight from experienced colleagues. That might mean giving these newer developers interesting questions to answer, such as:

How would we redesign onboarding if every internal API had an AI-readable contract and examples that actually worked?
How would we change code review if the agent produced a change summary, test evidence, dependency risk, and rollback plan with every pull request?
How would we build features if product requirements were written as executable acceptance tests rather than vague prose?
How would we reduce toil if agents could safely perform routine migrations, dependency updates, or incident triage within clearly defined boundaries?

These are not toy problems. They’re not “junior work.” They’re exactly the sort of process redesign that enterprises need but generally avoid because everyone is too busy running on the existing hamster wheel.

Finding the balance

So what should engineering leaders do? First, stop treating AI adoption as an individual productivity contest. We seem to be moving quickly away from the idea that “lots of tokens” equals “great engineer,” but the fact that we even flirted with it is damning. I love how Santiago Valdarrama eviscerates this vanity metric: “Measuring AI productivity in number of lines written is a stupid mistake. One day, everyone will have always been against this.” Instead we should be asking questions like, “What part of our software delivery process no longer makes sense?” AI’s biggest gains will come when we change how we specify, test, review, and ship software.

Second, mix up your AI workflow teams. No, not committees or PowerPoint-producing centers of excellence. I’m talking about combining two or three newer developers who are already fluent in AI-native tools with two or three senior engineers who understand production, security, architecture, and organizational constraints. Then give them a real workflow to redesign, such as dependency upgrades or test creation.

Third, make the senior engineer’s job less about saying no and more about defining the guardrails within which others can say yes. I’ve argued that golden paths are key to using AI effectively. Good senior engineers should define the paved roads: approved patterns, test requirements, observability standards, etc. Then let junior developers and agents move quickly inside those boundaries.

Fourth, reward deletion. This may be the most important point. Going back to the factory electricity metaphor, we’ll fail with AI modernization if we simply add AI without removing outdated processes.

Bring everyone to the table

The future of software development won’t belong to the young. It won’t belong to the old, either. It will belong to teams that combine the talents of both.

Newer developers often bring impatience. They’re less likely to accept the existing workflow as sacred. They’re more likely to try weird tools, compose them in unexpected ways, and wonder why enterprise software development feels like a ritualized exercise in waiting for permission.

Experienced developers bring judgment. They know that software has users, auditors, attackers, budgets, latency, history, and consequences. They know that the right answer is often boring, and boring is good.

Enterprises need both. They need the developer who asks why the factory is still organized around the old drive shaft, and they need the developer who knows which machines will kill someone if moved casually. In sum, every development team needs people who know why the old system exists… as well as those who don’t.

MCP solved tool calling. A2A solved coordination. What solves transport?

Sun, 14 Jun 2026 21:18:54 +0200

The history of distributed computing is one of protocol proliferation followed by consolidation.

Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM), Java remote method invocation (RMI), and early simple object access protocol (SOAP) competed for the enterprise integration market in the late 1990s before representational state transfer (REST) quietly won by being simpler and HTTP-native.

Extensible Messaging and Presence Protocol (XMPP), Internet Relay Chat (IRC), and a dozen proprietary protocols fragmented real-time messaging before MG telemetry transport (MQTT) and WebSockets carved out their respective niches. Every new computing paradigm generates a burst of competing standards, then slowly converges as implementations accumulate and interoperability becomes economically necessary.

The AI agent ecosystem is currently in the proliferation phase. Four significant protocols have been published in the past eighteen months: Model context protocol (MCP) from Anthropic in late 2024, agent communication protocol (ACP) from IBM Research in March 2025, Agent2Agent (A2A) from Google in April 2025, and agent network protocol (ANP) from an independent working group.

The W3C AI Agent Protocol Community Group has opened a standards track. The Internet Engineering Task Force (IETF) is receiving Internet-Drafts on agent transport. Conferences are running workshops on interoperability. Every week brings a new GitHub repository claiming to solve the agent communication problem.

Understanding where and how quickly this converges has real consequences for architecture decisions being made right now.

What the protocols actually solve

The proliferation looks more chaotic than it is, because most of these protocols address different layers of a stack rather than competing for the same slot. The confusion comes from marketing, which describes each as "the standard for AI agent communication" without specifying which aspect of communication.

MCP is a tool-calling interface. It defines how a model discovers what functions a server exposes, how to invoke them, and how to interpret the response. It is a typed remote procedure call (RPC) contract between a model client and a tool server, running over HTTP. The Linux Foundation confirmed more than 10,000 active public MCP servers and 164 million monthly Python SDK downloads by April 2026. MCP has already won the tool-calling layer. The standardization work is effectively done.

A2A is a task coordination interface. Where MCP defines how an agent calls a tool, A2A defines how two agents delegate a task. It introduces Agent Cards (capability advertisements), task lifecycle states, and three interaction modes: Synchronous, streaming, and asynchronous. Google donated it to the Linux Foundation in June 2025, and enterprise AI teams have adopted it broadly because it fills a real gap that MCP leaves open.

ACP is a message envelope format. Lightweight, stateless, designed for agent-to-agent message exchange without A2A's full coordination semantics. It is useful in systems where simple message passing suffices and A2A's task lifecycle overhead is unnecessary.

ANP is a discovery and identity protocol. It uses Decentralized Identifiers (DIDs) for agent identity and JSON-LD graphs for capability descriptions, providing a foundation for decentralized agent marketplaces where no central registry is required.

The stack that is emerging: Capability discovery via ANP or simpler registries, task coordination via A2A, tool calls via MCP, and lightweight messaging via ACP for cases that do not require full task lifecycle management. These layers complement rather than compete.

The transport problem that remains

Every protocol in this list runs over HTTP. This reflects where the protocols came from: Research teams, API providers, and enterprise software companies building systems where HTTP is an unquestioned assumption. HTTP is the protocol they know, the one their servers already speak, and the one that makes demos easy.

The production problem is that HTTP assumes a reachable server. Behind network address translation (NAT) — and 88% of networked devices sit behind NAT — there is no reachable server without a relay. For agent fleets that need to route tasks directly between peers across cloud boundaries, home networks, and edge deployments, this centralization forces every message through relay infrastructure. Relay infrastructure adds latency, cost, and a failure mode.

The application-layer protocols solve the semantics of what agents say to each other. They do not solve how agents find each other and establish direct connections. That is a session-layer problem, Layer 5 in the open systems interconnection (OSI) model and none of MCP, A2A, ACP, or ANP address it.

The technologies for solving it exist. UDP hole-punching with session traversal utilities for NAT (STUN) provides NAT traversal for roughly 70% of network topologies. X25519 Diffie-Hellman and AES-256-GCM provide authenticated encryption at the tunnel level without a certificate authority. Quick UDP internet connections (QUIC) (RFC 9000) or custom sliding-window protocols over user datagram protocol (UDP) provide reliable delivery without TCP's head-of-line blocking. These are the same primitives that WireGuard uses for VPN tunnels and that WebRTC uses for browser-to-browser media streams.

What differs in the agent context is capability-based routing. Agents need to find peers not by hostname but by what those peers can do. A research agent should be able to query "which peers have real-time foreign exchange data?" and receive a list of currently active specialist agents. This is closer to a service registry than to DNS, and it is a natural extension of ANP's design philosophy applied to the transport layer.

A handful of projects are assembling these pieces. Pilot Protocol has the most complete published specification, with an IETF Internet-Draft covering addressing, tunnel establishment, and NAT traversal for agent networks. libp2p provides a battle-tested foundation with similar primitives. The IETF's QUIC working group is developing NAT traversal extensions that will be relevant here.

What convergence will look like

The HTTP-based protocols (MCP, A2A) are already converging on stable versions. The next 12 months will see production hardening, security improvements, stateless MCP servers for horizontal scaling, better A2A federation — rather than new fundamental designs. The tool-calling and task-coordination layers are largely solved.

The transport layer is 18 to 24 months behind. Expect a period of implementation diversity as teams experiment with different approaches to peer-to-peer (P2P) agent networking, followed by consolidation around a small number of implementations once empirical data on performance and reliability accumulates. The IETF and W3C standardization tracks will likely produce something in the 2027-2028 window, by which time one or two open-source implementations will have accrued enough production deployments to establish de facto standards ahead of the formal specification.

For engineering leaders making architecture decisions today, the practical implication is layered adoption. The application-layer protocols are stable enough to build on. MCP adoption now is low-risk. A2A adoption for multi-agent coordination is reasonable with the expectation that the protocol will evolve. The transport layer is where you either build something custom and plan to replace it, or you evaluate early implementations knowing the space is still moving.

The teams that will have the most leverage when the transport layer stabilizes are the ones that designed their agent systems with a clean separation between application semantics (MCP, A2A) and transport (whatever sits below). Clean separation is cheap to implement now and expensive to retrofit later, a lesson the microservices era taught anyone who tried to add observability or circuit breaking to systems that had none.

Philip Stayetski is a co-founder of Vulture Labs.

NetBox at 10: Network inventory tool now a full infrastructure intelligence platform

Fri, 12 Jun 2026 18:04:45 +0200

NetBox was not originally designed to manage AI infrastructure. When the project was first released as an open source tool in 2016, the goal was straightforward: Give network teams a reliable record of what was on the network. The project spread well beyond that original scope. It is now embedded across more than 10,000 organizations, from enterprise networks to AI data centers running some of the most demanding infrastructure builds in the industry.

As the technology marks its 10-year anniversary, NetBox Labs is expanding the platform further with the launch of its Infrastructure Intelligence Platform. Key capabilities in the platform include:

NetBox Data Exchange (NDX): A database of infrastructure component metadata covering device logical characteristics, lifecycle dates, environmental data, and observability profiles across tens of thousands of device types.
NetBox Asset Lifecycle: A procurement pipeline connecting network design to physical deployment through bills of materials, purchase orders, shipment tracking, and spares management against planned DCIM objects.
NetBox Validation: Pre-change compliance and safety verification against regulatory frameworks and organizational policy, with self-correction capabilities for AI agents,
NetBox Labs Platform MCP Server and Agent Skills: An enterprise-grade hosted MCP server that exposes the full platform to any MCP-compatible agent, alongside an open source library of agent skills.

“It is not at all uncommon for me to hop on with the VP of infrastructure in some large enterprise and hear, ‘I have 14 network observability tools right now. Help,'” Kris Beevers, CEO of NetBox Labs, told Network World. “Tool sprawl is the problem at the moment that is holding these teams back. So, we’re giving them a cohesive platform that they can consolidate against, that works well together, which is really driving velocity for us.”

A decade of NetBox

Beevers didn’t create the open-source NetBox project. He first encountered it while he was leading DNS platform provider NS1. “We kept finding NetBox at such a volume and frequency that it caused us to say, what is this thing? Why is it everywhere?” Beevers said.

NS1 hired the core open source contributors around 2020 and began building commercial tooling around the project. NetBox Cloud launched in 2021. Then IBM acquired NS1 in 2023, and NetBox Labs was spun out as an independent company in 2023, led by Beevers.

NetBox Labs has continued to expand both the open-source project as well as a growing set of commercial offerings. In the last several years, in particular, there has been a focus on helping to enable AI infrastructure buildout as well as providing AI-enabled tooling.

NetBox is deployed at more than 10,000 organizations across enterprise networks, AI data centers and OT environments. The project has more than 20,000 GitHub stars across 350-plus releases, with contributions from nearly 400 developers.

That portfolio of products, combined with an accelerating infrastructure market, created the need for a unifying platform story. The Infrastructure Intelligence Platform is the answer to that.

“The rate of change of infrastructure is super fast, and the time pressure around infrastructure is super high,” Beevers said.

The Infrastructure Intelligence Platform: From design to deployment

NetBox Labs is positioning the platform to span the full infrastructure lifecycle, from initial procurement through decommission. That scope extends well beyond NetBox’s traditional role as a network inventory system, now reaching into procurement teams and buying centers.

“The infrastructure intelligence platform now covers that whole array of jobs and spans that whole lifecycle — from as early as design and procurement, racking and stacking, and plugging in, through to configuration and lifecycle management of the infrastructure across every dimension of operations for our customers,” Beevers said.

NDX provides the device metadata foundation that feeds the lifecycle workflow. Environmental and lifecycle data, covering heat output, end-of-support dates and physical specifications, flows into Asset Lifecycle, where it drives procurement planning, bill of materials generation and hardware reconciliation against the network design.

Maintaining that data thread through to production is where Validation comes in. Validation addresses two questions: whether the intended configuration meets compliance requirements and policy, and whether a planned change is safe before it reaches production. As agents take on more infrastructure work, the pre-change guardrail becomes more critical.

Validation pairs with the existing NetBox Assurance product. Where Validation operates on design intent, Assurance checks whether operational infrastructure matches that intent.

“So, is my intent correct? And is the infrastructure operating in line with my intent? Those are the two halves of this,” Beevers said. “Validation and assurance go really well together.”

Agentic infrastructure and the road ahead

AI infrastructure is leading to network buildouts, but there is also a need to enable agentic AI for Netbox as well. The platform is designed to support two concurrent access paths: full agent addressability and improved interfaces for human operators.

“The general philosophy that we’re pursuing right now is what we call a two front doors philosophy,” Beevers said. “We need everything in our platform to be accessible and operable by agents, because increasingly they’re going to do more of the work. But at the same time, we’re investing a lot, in up-leveled, more strategic experiences for the humans operating this stuff, so that they can drive the strategy and the shape of the work that’s being done by the agents.”

How Jeetu Patel made Cisco unrecognizable

Fri, 12 Jun 2026 17:29:18 +0200

Cisco Live 2026 is in the books, and it was “prove it” time for a promise made 24 months ago. At Cisco Live 2024, Chief Product Officer Jeetu Patel promised that Cisco would be unrecognizable as a company—in a positive way—in two years. The innovation payload at the event suggests he has largely delivered on that pledge. Cisco is repositioning itself from a holding company of products and dashboards to a unified, AI-native infrastructure platform, with Cloud Control as the control plane, Cisco IQ as the CX brain, and Secure Networking as the glue binding it all together.

The shift is not just about new features; it is about a new operating model. Instead of humans clicking through a sprawl of consoles, Cisco is building an environment where human operators and AI agents share the same data, context, and system of action, with humans staying in control. For longtime Cisco customers, the result is a company that, in fact, looks and feels very different from the one Patel inherited.

From dashboard sprawl to Cloud Control

The most visible proof point of the new Cisco is Cloud Control, the unified management plane that now spans networking, security, compute, observability, collaboration, and an expanding ecosystem of third-party tools. Cisco is careful to note that this is not just another single pane of glass but an active execution environment with policy and identity embedded in the control path, designed from the ground up for humans and AI agents to operate infrastructure together.

Patel’s demo underscores how far Cisco has come from its historical dashboard sprawl. When operators land in Cloud Control, they see a familiar, ChatGPT‑style interface with three modes: Assistant, Canvas, and Actions. Assistant lets operators converse with the platform in natural language. Canvas provides a multiplayer workspace where humans and agents can investigate and resolve issues together. Actions become the mission control for supervising what agents propose and execute.

Crucially, Cloud Control surfaces shared platform services such as inventory and topology across the entire Cisco estate and exposes product tiles for Meraki, Intersight, security services, Splunk, Webex Control Hub, and Cisco IQ, all accessible with a single login. Instead of bouncing between multiple dashboards and authentication domains, operators can move seamlessly between platform services and product experiences within the same environment. For customers who have lived with overlapping portals and inconsistent workflows, this alone makes Cisco feel fundamentally different.

Cloud Control as an AI harness, not a console

Under the hood, Cloud Control is built on a shared data fabric that correlates telemetry across users, devices, applications, networks, and threats. That fabric fuels both human decision-making and agentic automation. Cisco describes this evolution as moving from “infrastructure as code” to “infrastructure as a harness.” Rather than relying solely on scripts and playbooks written by humans, Cloud Control becomes the governed substrate where AI agents can safely observe, reason, and act on real systems.

That harness appears in three visible dimensions. First, AI Canvas provides the workspace where humans and agents co-investigate incidents, with context persisting across shifts and escalations so nothing is lost. Second, Cloud Control Studio offers Agent Builder and App Builder, which let customers and partners build their own agents and applications on top of Cisco’s data, policy, and control plane using natural language and embedded coding assistants. Third, everything built in Studio—plus partner solutions—flows into the Cloud Control Marketplace, where integrations from dozens of ecosystem partners are already available.

For enterprises, the net effect is that Cloud Control shifts from a place to click through settings to the “secure harness” for agentic operations: a governed environment where AI agents can be deployed, monitored, constrained, and audited end-to-end. That is a very different proposition from the traditional network management console.

CX and products finally share a brain

Historically, Cisco’s Customer Experience (CX) organization (services) and product groups have often felt like parallel universes. Services were layered on top of products rather than tightly integrated into how those products operated. Cisco IQ changes that dynamic by placing CX capabilities directly within the same Cloud Control environment where the products themselves live and by wiring CX workflows into the same telemetry and policy plane. This is notable as Cisco IQ isn’t yet another dashboard but an integrated part of Cloud Control.

Cisco IQ is positioned as the AI‑powered delivery vehicle for support and professional services. The goal is to give customers “complete landscape clarity,” proactive resilience, rapid resolution, and contextualized services. It runs as a SaaS platform, with an on‑premises deployment option for customers with strict data sovereignty requirements. By tapping the shared data fabric, Cisco IQ can inventory assets whether they are deployed or still in the warehouse, flag risks before customers experience issues, and benchmark an organization’s posture against anonymized peers by vertical, market segment or geography.

New capabilities, including Resilient Infrastructure Services and Quantum Ready Assessments, further underscore the integration of CX and product engineering. Resilient Infrastructure Services uses a three-step framework: Exposure Assessment, Infrastructure Modernization, and Defense Resiliency to help customers prepare for frontier-model threats. Quantum Ready Assessments, delivered through Cisco IQ, identify assets most exposed to “harvest now, decrypt later” attacks and map a path to quantum-safe infrastructure. Putting CX’s “brain” into Cloud Control and connecting it to the same data and AI models that drive operations is both a cultural and an architectural shift.

Secure Networking as the integration proof point

If you want a single domain that illustrates how integrated the new Cisco has become, look at Secure Networking. Cisco’s stated vision is to embed security directly into the fabric of the infrastructure, from silicon through the network to operations, rather than treating it as a separate stack. That strategy manifests in several concrete ways.

Live Protect, described internally as a “digital immune system,” applies precise compensating controls to Cisco products in production to protect them from newly discovered vulnerabilities at runtime. It does so without reboots, upgrades, or maintenance windows. The controls are narrowly targeted to avoid performance impact and minimize false positives. Live Protect is already shipping on Nexus 9000 switches and expanding across the portfolio, including campus switches, tightening the feedback loop between vulnerability discovery and mitigation from weeks to minutes.

Hybrid Mesh Firewall extends a unified security policy across networks, applications, and both Cisco and third-party firewalls, limiting the blast radius when something goes wrong. At the same time, Cisco is embedding post-quantum crypto libraries, secure boot, and trust anchors across its core portfolio, and has committed to enabling quantum-safe communications capabilities across most core products by December 2026. New enterprise and data center routers, switches, and firewall series are launching as “quantum-safe by default.”

All of this is orchestrated through Cloud Control, the security command center for a post-Mythos era, with Splunk providing the telemetry backbone and agentic SOC and SRE capabilities to detect, triage, and respond at machine speed. Secure Networking is no longer just about point firewalls and SD-WAN; it has become the spine that ties Cisco’s networking, security, observability, and AI assets into a coherent platform.

Multicloud Fabric: networking as a service for AI

Another hallmark of the new Cisco is a willingness to deliver networking as a managed fabric rather than a toolkit that customers must stitch together themselves. Multicloud Fabric, introduced as a network‑as‑a‑service offering delivered through Cloud Control, illustrates this shift.

Multicloud Fabric gives enterprises a single fabric for secure site-to-cloud and cloud-to-cloud networking, with Cisco operating virtual points of presence across major cloud providers and regions. Customers can onboard sites and cloud environments, define intent-based connectivity, attach security policies, and monitor performance “with one button” from Cloud Control, instead of building and maintaining their own hub-and-spoke architectures. Security and observability are built in—Zero Trust routing, cloud firewall service chaining, and ThousandEyes agents embedded in each point of presence—so the network is no longer a passive pipe but part of the AI intelligence stack.

This matters because AI-first applications increasingly chain inference across multiple clouds and data sources. Cisco’s own research shows that these agentic workflows can generate many times more network traffic than manual equivalents, with much of it being latency-sensitive inference. Multicloud Fabric, operated as a service and integrated into the same Cloud Control environment, is Cisco’s answer to this new reality.

What this means for customers

Cisco has spent four decades building category-leading products, from Meraki and Nexus to Webex and ThousandEyes. But the company’s biggest opportunity has always been in how those pieces work together. As Patel has said, tightly integrated and loosely coupled. Cloud Control, Cisco IQ, Multicloud Fabric, and Secure Networking suggest the product organization is finally closing that gap, turning dashboards into agentic workflows and discrete boxes into a secure harness for the AI era.

For customers, Cisco’s transformation matters because it changes the operating model, not just the product lineup. Cloud Control gives IT teams a single management plane across networking, security, observability, collaboration, and services, replacing the fragmented dashboard experience that has long complicated Cisco environments. That should make operations faster and simpler, but it also raises the bar for customers.

As Cisco pushes AgenticOps, AI Canvas, Live Protect, and Cisco IQ into the mainstream, IT teams will need to shift from manually managing tools to supervising agents, setting policy guardrails, and validating machine-speed actions. That shift will demand new skills in prompt design, policy modeling, risk scoring, and governance, especially as agents propose and test more changes before humans ever click “approve.”

It also means customers should view Cisco less as a best-of-breed product and more as an integrated platform. The more of the Cisco estate that is tied to Cloud Control, the more value customers should derive from shared telemetry, unified workflows, embedded security, and cross-domain automation—especially in areas like Secure Networking and multicloud operations. Conversely, customers that remain heavily heterogeneous will need clear integration strategies and governance models to ensure third-party tools plug safely into the harness.

Finally, this new Cisco has the potential to reduce one of the biggest pain points enterprise buyers have faced for years: complexity. If the company can deliver on its vision of one login, one view, tighter product integration, and CX services finally aligned with the product groups, customers may find that Cisco is not only unrecognizable in a positive way but also easier to buy, deploy, and operate than at any point in its history.

Why cloud outages are such a stubborn problem

Fri, 12 Jun 2026 11:34:40 +0200

Failures at the operational level

Better change management

Design with outages in mind

IBM, ServiceNow team to bring AI to legacy enterprise systems

Thu, 11 Jun 2026 21:05:39 +0200

IBM and ServiceNow are teaming up for new services they say will help enterprise customers bring aging legacy environments into an AI-ready infrastructure.

The collaboration will combine IBM’s AI, data, and automation capabilities and ServiceNow’s AI platform for a variety of offerings that will modernize aging systems, enable autonomous IT operations, and help organizations evolve existing systems rather than replace them, the companies stated. ServiceNow says its AI-Platform offers a workflow layer that sits on top of an enterprise’s existing systems and helps automate work across them.

Decades of deeply interconnected legacy systems are the biggest barrier to moving fast on AI, the companies stated. Their pairings will take advantage of Big Blue’s expertise in working with large systems, such as its mainframe environment, and extensive legacy applications, along with ServiceNow’s workflow and agent management platforms.

“Most enterprises have the ambition to deploy agentic AI, but lack the foundation to run it at scale,” said John Aisien, senior vice president and general manager, central product management, security and risk, at ServiceNow. “IBM brings the tooling to modernize the systems and extend ServiceNow’s data capabilities. ServiceNow provides the platform to put that data to work across every workflow in the business.”

The vendors will focus on three core services that will be available in the second half of 2026:

Application modernization: Scans and refactors legacy systems using tools like IBM Bob, Enterprise Application runtime (Java) and IBM watsonx.data to help enterprises bring existing applications into the AI era without starting from scratch.
Autonomous infrastructure operations: Integrates Red Hat Ansible, IBM Bob, Instana, Hashicorp Terraform, and Hashicorp Vault into ServiceNow IT workflows to detect, remediate, and resolve issues before they affect the business.
Data governance: Extends ServiceNow Workflow Data Fabric with IBM watsonx.data to unlock key capabilities like Data Quality, Observability, Master Data Management – employing the ServiceNow Data Catalog so that mutual customers can keep track of their AI-ready data.

IBM and ServiceNow have a long-standing relationship, having worked together to help large enterprise customers implement everything from cloud computing, automation, and security to IT service management and observability technologies.

From “try restarting it” to real-time intelligence: Conversational AI for IT operations and mainframe modernization

Thu, 11 Jun 2026 19:02:54 +0200

As experienced members of the workforce retire, organizations lose critical system knowledge at the same time their environments become more complex. This challenge is especially acute in mainframe modernization initiatives, where deep, experience-based knowledge of legacy systems remains essential. Mainframe and hybrid systems continue to expand across platforms, but the expertise required to manage and modernize them is becoming harder to access and scale.

As a result, CIOs must recognize the operational fragility, including slower resolution and higher downtime, that this lag causes. The true barriers to innovation here are a lack of context and accessibility. As complexity grows and expertise becomes less accessible, organizations must move from reactive, knowledge-dependent troubleshooting to a model built on system-driven, explainable intelligence.

From guesswork to guided intelligence: The rise of agentic operations

The way teams troubleshoot hasn’t kept pace with innovation. Diagnosing and resolving issues still depends on fragmented tools and knowledge that lives in the heads of a few individuals. Even in organizations actively pursuing mainframe modernization, limited visibility and inconsistent workflows slow teams down, forcing them to rely on who remembers what rather than what the system can clearly explain.

Conversational AI for IT operations is a system that enables engineers to query infrastructure in natural language and receive real-time, context-aware diagnostics along with recommendations that can be converted into human-in-the-loop agentic actions generated from correlated logs and performance data. Instead of digging through logs or relying on undocumented expertise, teams can interact directly with their systems and receive clear, contextual answers. This marks a novel shift toward proactive operations, where emerging risks are surfaced early and addressed before they become disruptions.

Mainframe modernization without rip-and-replace

Modernization doesn’t require abandoning the systems that power the business. For many organizations, platforms like the mainframe remain essential, supporting everything from financial transactions to core customer experiences. A rip-and-replace approach often overlooks the proven reliability and performance these systems continue to deliver, not to mention the healthy degree of risk it introduces to the system.

A more effective path is building incrementally on existing investments while introducing new capabilities that make them easier to operate and optimize. Traditionally, troubleshooting has been manual and reactive, requiring teams to navigate fragmented tools, correlate logs, and rely on individual expertise to diagnose issues. Currently, when something breaks, engineers have to connect the dots manually or rely on a single source of truth who “knows the system,” but this is inconsistent and stress-inducing.

With the emergence of agentic AI for operations, IT teams can put boots on the ground inside the system itself. A user can ask something like, “Why is this application slowing down?” and it springs into action by looking across your systems from the mainframe to the cloud and connecting related events to identify what caused the issue. From there, the model can explain it to the user in plain English and suggest what to do next.

What explainable troubleshooting actually looks like

Explainable troubleshooting is the ability of an AI system to diagnose issues and clearly communicate the underlying cause, as well as recommend actions in plain language based on transparent analysis of system data across mainframe, COBOL, and hybrid environments.

This approach comes to life through Rocket EVA, an AI-powered, agentic platform that delivers precise, end-to-end operational diagnostics across core systems. EVA connects system behavior across the full stack, giving teams the context needed to safely modernize without disrupting critical operations.

In the context of COBOL modernization, EVA reduces reliance on scarce subject matter experts by making application behavior, dependencies, and system interactions visible and understandable. By analyzing signals across multiple operational domains and connecting information that would otherwise require manual investigation across teams, it helps organizations identify root causes faster and significantly reduce mean time to resolution. For mainframe modernization, EVA enables teams to operate hybrid environments with greater confidence, bridging the gap between legacy systems and modern observability practices while providing a unified view of what’s happening across the enterprise.

Key capabilities

Cross-platform observability (mainframe, COBOL, hybrid cloud, distributed systems)
Automated log correlation and event analysis across legacy and modern environments
AI-driven root cause analysis for mainframe workloads
Natural language interaction and diagnostics for faster troubleshooting
Continuous anomaly detection and pattern recognition across modernization pipelines

Outcomes

Reduced mean time to resolution (MTTR) in complex legacy environments
Improved root cause accuracy across mainframe systems
Decreased reliance on tribal knowledge during modernization initiatives
Increased operational resilience and uptime for hybrid systems
Faster onboarding of engineers unfamiliar with legacy platforms
Greater visibility into mainframe and legacy system dependencies

Why CIOs should care

Technologies like these can serve both as solutions to problems and as tools to enhance the present strengths of your organizational processes. If IT teams spend less time diagnosing issues and more time resolving them, reducing downtime while easing dependence on a shrinking pool of specialized talent, organizations as a whole will benefit from increased resilience and workforce scalability. Just as important, systems become active participants in problem solving, making expertise broadly accessible. Simply put, the systems that endure will be the ones that can think alongside the people who run them.

Learn more about how Rocket Software can meet you at any point on your modernization journey with EVA.

AI vendor FDEs: Key considerations and concerns

Thu, 11 Jun 2026 13:17:52 +0200

When it comes to AI deployments, IT leaders are often caught in an awkward middle space, trying to reconcile conflicting directives from senior management with constantly changing AI models, capabilities, and costs; data governance and security needs; and the limitations of their own team.

“Very few real benefits can be attained by simply purchasing an AI product and giving it to employees. Vendors have been overselling that fallacy for the past three years,” said Nader Henein, a Gartner VP analyst.

“The reality is that strong AI value and consistent ROI are almost always a result of deep and intentional integration of AI capabilities into existing workflows. For that you need specialized teams, which do not come cheap, and organizations have been recruiting those teams in a variety of ways,” Heinen said.

Among the options available to IT leaders looking for help with AI deployments are traditional IT consultancies, AI-specific consultancies, and independent contractors. Large enterprises with deep pockets can consider acquiring an AI firm and integrating its technology and expert staff. The use of open source to reduce vendor lock-in is a strategy that can sit on top of those others, an approach that Capital One has used.

But the option that has been getting the most attention recently is bringing in forward-deployed engineers (FDEs), teams of experts from AI vendors that embed with a customer’s in-house engineers to oversee AI rollouts within the enterprise environment. Both OpenAI and Anthropic have recently announced FDE offerings, for example, and Microsoft is partnering with consulting giant EY in a new FDE program for agentic AI deployments.

Engineering teams employed by AI vendors have key strengths, such as understanding their models better than anyone else, having experience integrating those models into different types of enterprise environments, and knowing about upcoming model capabilities before they’re announced. But they also have the obvious drawback of vendor lock-in. Even if future rollouts are not within their contracted deliverables, those vendor employees could subtly influence a client’s future AI efforts.

Flavio Villanustre, CISO for LexisNexis Risk Solutions, cautions IT executives to move into FDE programs carefully.

FDEs “are financially incentivized to grow customers’ use of a vendor’s AI products and to create stickiness with that vendor’s services,” he said. “While FDEs may be a reasonable value-added service by the AI vendor, customers should always find other unbiased expert opinions that can evaluate competitive solutions across multiple vendors.”

This is particularly important at a time when “investor-subsidized AI token business models are starting to show cracks,” Villanustre said. “Also, in the current rapid pace of innovation in this field where AI vendors are constantly leapfrogging each other, retaining the agility to move from one vendor to the next could create significant competitive advantages.”

Analysts, consultants, and other industry experts who spoke with Computerworld about FDEs echoed Villanustre’s caution, citing concerns around hidden costs, confidentiality, observability, and vendor lock-in.

Long-term costs and vendor lock-in

A key issue that IT executives need to consider is how long the FDE teams will be needed. The enterprise will likely need an ongoing series of AI deployments synced with the current AI model(s). If help is needed today, why would that change tomorrow?

Enterprises tend to overlook those longer-term costs, said John Sangyeob Kim, an AI engineer at software development vendor Solidroad.

“Deployment is maybe 20% of the total cost. The other 80% is keeping the system running through model upgrades, data drift, and edge cases that only appear after months in production,” Kim said. “Most contracts price the first part and assume the rest. Deployment isn’t the hard part of enterprise AI anymore. The next eighteen months are.”

And whether it’s intentional or not, FDEs will naturally favor their own product portfolio — it’s what they know best.

“FDEs from model labs are good at making their own models work in your environment. They are less suited for multi-model systems, because their incentive is to keep you inside their ecosystem,” Kim said.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said IT leaders should look at the FDE model as a strategy involving ongoing operational power.

“Whoever shapes the deployment pattern shapes the enterprise’s future muscle memory. Whoever owns the evaluation layer owns the truth layer. Whoever controls the integration logic controls the dependency map,” Gogia said. “This is why the FDE model matters. It is not just another delivery option. It is the frontier AI vendor moving closer to the customer’s workflow, operating model, and decision architecture.”

That proximity cuts both ways, Gogia noted. “FDEs are embedded inside the customer’s [environment], but they are also connected to the vendor’s commercial center of gravity. Their instinct will be to build around the model family, tooling assumptions, deployment patterns, and product roadmap they know best. This is perfectly natural. It is also precisely why CIOs must be cautious,” he said.

Allowing AI vendor employees an outsized say in enterprise deployment decisions could lock in model vendor dependency, which in turn will fuel high prices that can’t be fought effectively.

“FDEs can accelerate deployment and deepen dependency at the same time,” Gogia said. “Frontier AI vendors are no longer content to sell access to models. They increasingly want to shape how enterprises deploy intelligence. That is a larger prize.”

What happens when the FDE team leaves?

FDE post-departure risks are severe and often underappreciated, according to Justin Greis, CEO of consulting firm Acceligence and former head of the North American cybersecurity practice at McKinsey.

For one thing, the FDE team learns a massive number of operational details from the enterprise deployment. Although NDAs and confidentiality contracts protect any data accessed, they often don’t regulate observed processes and procedures.

“The learnings are absolutely going to be taken from client to client,” Greis said. “Whoever helps deploy AI will learn far more than what appears in the statement of work. They will learn the real workflows, the undocumented exceptions, the data-quality gaps, the approval bottlenecks, the security workarounds, and the places where the business depends on a few people knowing what to do when the process breaks. That knowledge may be as sensitive and precious as the data itself.”

Another critical but often overlooked issue is how much meaningful control will IT have over the project if and when the FDE team leaves.

“The danger is not using outside help. Most companies will need outside help,” Greis said. “The danger is using outside help in a way that leaves the enterprise less capable and more dependent when the engagement is over.”

It is precisely those operational decisions that IT often neglects, said Solidroad’s Kim.

“The best predictor of success is not the vendor. It is whether one internal engineer truly understands the system before the implementer leaves. What matters is who owns the evaluation loop after the demo,” Kim said.

“What happens to our prompts, scorers, and guardrails when the model version changes? If we paused this engagement tomorrow, what would actually stop working, by design or by accident?” Kim asked. “Where do you want the enterprise’s AI learning, control, and dependency to live after the engagement is over?”

Kim argues that observability — the ability to understand and manage all elements of a complex enterprise environment — is a critical function to which IT often gives insufficient attention. Determining whether the project uses the enterprise’s observability stack or the vendor’s observability stack is crucial.

“If the implementer is using their observability stack, that is fine during the build, but you need a plan to migrate it to something you own before they leave; otherwise the visibility walks out of the door with them,” Kim said. “If they are using yours, that is the best case. It means they are working inside the system your team will operate long-term.”

A major problem crops up when they are using neither the enterprise’s nor the vendor’s observability stack. “Neither means they are building the system without any production observability layer at all, and you inherit a system you cannot see into. The first time something breaks in production, you have no traces, no failure history, and no way to tell whether the issue is a model regression, a data problem, or a code bug,” Kim said.

“If observability was not a priority during the build, evals and regression testing usually weren’t either, so you are inheriting a system you cannot measure and cannot safely change. That’s the worst possible handoff position,” he said.

Weighing the alternatives

While the FDE approach is not new, it is just now beginning a surge in popularity, and there are a finite number of such specialists available. That means not all companies even have the option of using FDEs.

This availability disconnect is especially prominent for non-US deployments, where on-site FDEs are rarer, said Gartner’s Henein. “Where is the development happening? There may not be FDEs available in that region,” he said.

There are plenty of other places enterprises can turn to for AI help. Ishraq Khan, CEO of coding productivity tool vendor Kodezi, encourages IT executives to consider a wide range of options but notes that all approaches have major drawbacks.

“Traditional consultancies are usually stronger at governance, process, compliance, and organizational coordination. They know how large enterprises operate politically and structurally. The downside is that many move slower and often lack deep frontier AI specialization,” Khan said.

Gogia from Greyhound Research put it more colorfully: Traditional IT consulting firms “know how to get legal, risk, security, finance, HR, and business units into the same room without anybody setting fire to the carpet. For regulated enterprises, that matters,” he said.

Specialized AI consultancies have a different set of strengths, Khan said. “AI-native consultancies move much faster and are often more technically current, but many are still immature operationally. Some can build impressive demos without fully understanding long-term maintainability, governance, or production reliability.”

Greis from Acceligence commented on two other options for bringing in outside AI help. Using an independent contractor “can be great for eval design, architecture reviews, red teaming, agent design, or getting a stalled team unstuck,” he said, but it can increase the risk of “key-person dependency,” where a single external person is the only one who understands the system.

As for purchasing an AI firm and onboarding its employees, a practice known as “acquihiring,” Greis said it can work well when the AI capability and expertise being brought in are truly strategic for the acquiring enterprise. But there is a risk that the acquired team will be smothered by the parent company’s bureaucracy: “You buy a speedboat, bolt it to an aircraft carrier, and then wonder why it stopped moving,” he said.

Finally, an open-source strategy can give companies flexibility and reduce vendor dependence, but “many companies underestimate the operational burden that comes with it,” Kodezi’s Khan said. “Open source only helps if the organization has the internal talent and discipline to maintain it properly.”

Bottom line: enterprises need to define their true objectives before deciding on an approach. Khan offered several key questions for CIOs to consider: “Who owns the deployment after implementation? Can we move providers later without rebuilding everything? What happens if the vendor relationship changes or disappears? Are we optimizing for short-term deployment speed or long-term operational resilience?”

In any scenario where outside firms have direct access to enterprise systems, IT needs to be kept fully in the loop. “The worst outcome is when an enterprise successfully deploys AI but no longer fully understands how its own systems operate underneath,” Khan said.

External help for AI deployments: 6 options

	Pros	Cons
AI vendor FDEs	+ Best expertise on the main model being used	– Vendor lock-in – Operational detail leaks
Traditional IT consultancies	+ Best understanding of change management, legacy integration, global rollout, governance, and operating-model redesign	– Can be too slow, too expensive, or too generic
AI consulting firms	+ More practical AI deployment experience than traditional consultants + Less vendor lock-in than model-provider FDEs	– May not sufficiently understand enterprise-grade requirements: security, identity, auditability, compliance, incident response, cost controls, and long-term maintainability
Independent contractors	+ Useful for precision tasks: eval design, architecture reviews, red teaming, agent design, or getting a stalled team unstuck	– Risk of ‘key-person dependency’
‘Acquihiring’ an AI firm	+ Works when the acquired capability is truly strategic	– Acquired team can be smothered inside existing bureaucracy
Deploying open-source products	+ Reduces dependency on one model vendor + Attractive for data sovereignty, control over enterprise systems, cost efficiencies, and regulated environments	– Enterprise takes on full responsibility for security, patching, evaluation, deployment, monitoring, and lifecycle management

Source: Acceligence

Related reading:

CIOs plagued by growing AI accountability gap

Thu, 11 Jun 2026 12:18:11 +0200

IT leaders are getting a sneak preview of governance in the agentic era, and it’s shaping up to be a horror show.

Two-thirds of CIOs and CTO surveyed by the IBM Institute for Business Value say they’re accountable for AI systems they don’t fully control as employees and other business units spin up new agents.

In addition, 70% of the IT leaders surveyed say their organizations are deploying tech systems faster than their IT teams can track. Moreover, CIOs expect a 38% increase in the number of AI agents deployed at their organizations by next year, with just one in 10 IT leaders saying they’re prepared for the anticipated scale of agent deployment.

The study reinforces growing concerns about the state of AI governance, with many IT organizations challenged to track output, security, and value as employees spin up new agents without IT’s input, says Matt Lyteson, CIO of technology transformation at IBM.

“A lot of enterprises have policies that make it easier for more people to develop agents, and it’s not just the only two people in the IT department to be able to develop these solutions,” he says.

Danger for IT leaders

While there’s value in encouraging employees to experiment with AI, doing so can create major problems for IT leaders, experts say.

When CIOs and CTOs are held accountable for AI tools they don’t control, it creates real tension in the enterprise, says Ben Schein, chief AI and analytics officer at data platform vendor Domo.

AI tools at many organizations are being deployed outside of IT teams faster than they can be inventoried, he adds. “The pace problem isn’t usually that AI is being shipped recklessly,” he says. “It’s that AI is being adopted faster than governance models can adapt.”

In many cases, the AI deployments are reasonable actions taken by employees, but CIOs and CTOs don’t see it happening, Schein says.

“Someone in marketing connects an LLM to a content workflow,” he adds. “Someone in finance pastes a forecast into ChatGPT to clean it up. Someone in product gives a new agent access to a customer dataset. The aggregate is invisible to the CIO.”

AI governance and observability are huge issues that need IT leader attention at many organizations, he says.

“Can you see what AI is doing?” Schein adds. “Treat your AI agents like employees: who are they, what data did they touch, what did they produce, what did it cost, what went wrong?”

AI governance isn’t a posture; it’s basic plumbing, he says. “The CIOs who’ll succeed in the next 24 months are the ones who build observability and policy enforcement into the same layer where data already lives — not a separate AI governance workstream bolted on after the fact,” he says.

Governance gap

Aatish Salvi, CTO at software testing vendor Applause, agrees that there’s an AI governance gap.

“We’re seeing that people are developing agentic workflows and AIs and products at a rapid scale across all industries, and they’re developing them faster than they understand how to govern, control, or evaluate them when CIOs or CTOs don’t have full control over AI systems,” he says.

Salvi sees the same challenge that Schein does: that many organizations encourage or permit employees outside the IT team to deploy agents, without letting the CIO or the CTO know. Control rests with whoever happened to build the agent.

“They may or may not have the technical expertise to manage, govern, or evaluate it,” he adds. “So someone somewhere in the company built something in order to help them do work, and now they’re getting their work done at some cost or expense to tokens, security, compliance, and all sorts of other concerns.”

Salvi sees a huge AI governance challenge for many organizations. “When people are building agentic systems by the dozen, democratizing the tools to build them throughout their organizations, and have absolutely no evaluation frameworks, they do not understand that they are compromising the quality of the work their employees produce in exchange for getting that work done significantly faster,” he says. “They’re producing mediocrity at great speed — and probably defects as well.”

There’s a danger in agent control sitting with someone outside the IT team, Salvi adds. “That someone does not have the tools, know-how, or technical experience to be exercising that control intelligently,” he adds.

In many cases, there’s no control at all over the agents deployed outside the IT team, counters Itai Schwartz, cofounder and CTO at data security vendor MIND. Without agent guardrails in place, agents often run without supervision, he suggests.

“Every AI tool should have a business owner who’s accountable, and usually there’s a name on paper,” he says. “But most of these systems are autonomous and non-deterministic. They don’t follow a fixed script. So in practice, the tool is controlling itself.”

The answer isn’t to slow down AI deployments in enterprises, but to give IT leaders visibility and enforcement tools that can keep up with the adoption curve, Schwartz says.

“No technology leader I talk to wants to slow AI down,” he says. “They want better tools to move fast and stay safe at the same time. The answer is better tooling, not more caution.”

Sanctioned AI platform

One possible approach is what IBM did: The company created an AI agent platform that allows employees to create their own tools within a controlled environment, Lyteson notes. New agents are checked for security and privacy, as well as whether they already replicate existing IBM tools.

“Very early on, we built an enterprise platform and invited people to build these solutions in a way that I feel comfortable working with my CISO on, by protecting the data by only using certain models that we feel comfortable with,” he says. “I want to know what that thing is doing, whether it is an individual productivity capability or whether this is supporting a full workflow, and I want to know the cost and value it brings to the organization.”

What SRE teams need before they trust AI agents

Thu, 11 Jun 2026 12:08:32 +0200

The future of reliability will not be defined by whether site reliability engineering (SRE) teams use AI agents, but by the conditions under which they choose to trust them. In high-stakes systems, trust is never granted because a demo looks impressive; it is earned through observability, constraints, accountability and repeated evidence that the system helps more than it harms.

Right now, many teams are exploring AI for incident response, alert triage, root cause analysis and runbook automation because modern systems generate more context than humans can process quickly under pressure. That interest is justified. But the most mature SRE organizations understand something important: the real challenge is not building an agent that can act, it is building an operating model that people can trust in production.

Trust is operational, not emotional

SRE teams do not trust tools in the abstract. They trust behavior under stress. A platform earns credibility when it helps engineers make better decisions during noisy alerts, partial outages, failed deploys and ambiguous telemetry, not when it generates polished answers in ideal conditions .

That is why generic AI often falls short in production. It may be fluent, but fluency is not reliability. Live systems demand awareness of ownership, dependency maps, escalation paths, blast radius and policy boundaries, and without that context an AI agent can sound helpful while being operationally dangerous . For SRE teams, trust starts when the agent proves it understands the system it is operating around.

The trust ladder

Neel Shah

Teams do not move directly from experimentation to autonomy. They move up a ladder of trust, where each step is validated in production-like conditions before the next one is allowed.

The 1st requirement: Grounded observability

Before teams trust an AI agent, they need a telemetry foundation that the agent can actually reason over. If logs are incomplete, traces are missing, ownership is unclear and deployment metadata is scattered across tools, the agent will not become intelligent by magic. It will simply become confidently under-informed.

This is why observability is the real prerequisite for agentic SRE. The strongest AI SRE approaches are grounded in correlated metrics, logs, traces, changes and incident history so that recommendations are evidence-backed rather than speculative. An AI agent cannot create operational truth; it can only synthesize the truth your systems already expose.

In practice, that means teams need more than dashboards. They need clean service ownership, change tracking, incident timelines, runbooks and enough signal quality that an agent can distinguish a symptom from a cause. Without that groundwork, the AI layer becomes theatre

What grounded observability looks like

Neel Shah

Monitoring tells you that something is wrong, while observability helps explain why. AI becomes useful only when it sits on top of both layers, not instead of them.

The 2nd requirement: Clear guardrails

The fastest way to lose trust in AI is to give it authority before defining its boundaries. In operations, the question is not “Can the agent do this?” but “Under what conditions should it be allowed to do this, and who is accountable if it is wrong?”

This is where guardrails matter. Strong SRE teams want explicit permission models, approval gates, action allowlists, audit trails and rollback paths before an agent touches anything meaningful in production. That may sound restrictive, but it is exactly what makes adoption viable. Constraint is not the enemy of agentic systems; constraint is what makes them usable.

The most practical path is progressive autonomy. Let the agent start by summarizing incidents, correlating changes and suggesting next steps. Then move to read-only diagnostics. Only after consistent success should it be allowed to trigger low-risk automation, and even then, within tightly defined policies. Trust grows when the blast radius stays small.

Visual: Progressive autonomy model

Stage	Agent role	Risk level	Human involvement
Stage 1	Summarize alerts and incidents	Low	Human reviews output [cite:8]
Stage 2	Pull telemetry and correlate changes	Low to medium	Human approves decisions [cite:41][cite:52]
Stage 3	Recommend remediation actions	Medium	Human confirms action [cite:42][cite:43]
Stage 4	Execute pre-approved low-risk actions	Medium	Human supervises and can override [cite:44][cite:52]
Stage 5	Broad autonomous action	High	Rarely acceptable without strict policy controls [cite:43][cite:54]

The 3rd requirement: Human-in-the-loop design

SRE teams are not looking for an AI replacement. They are looking for leverage. The most credible operating model is not autonomous-by-default but supervised-by-design, where agents accelerate understanding and execution while humans retain judgment over risk, trade-offs and unusual conditions .

That distinction matters because incidents are rarely just technical events. They involve business impact, customer communication, cross-team coordination and decisions shaped by context that may not exist in telemetry alone . An agent can help identify a likely bad deploy, but it cannot fully own the decision about whether to roll back during a major customer launch without broader situational awareness.

Human-in-the-loop does not mean slowing everything down. It means designing different levels of oversight for different classes of action. Low-risk tasks such as drafting an incident summary or pulling related dashboards may be automatic. Restarting a background worker might require lightweight approval. Disabling a core production dependency should remain firmly human-controlled . Mature trust comes from matching autonomy to risk.

The 4th requirement: Explainability over magic

SRE teams will not trust an agent that gives answers without showing its work. In reliability engineering, a recommendation is only as useful as the evidence behind it. Engineers need to know which metrics changed, which deployment correlated with the issue, which logs support the hypothesis and how confident the system actually is.

This is one of the biggest lessons emerging from operational AI systems. Precision matters but trust also depends on whether humans can inspect the reasoning path, challenge it and understand uncertainty in familiar terms . The best agent experiences feel less like oracles and more like disciplined collaborators: they surface context, rank hypotheses and make clear what they know versus what they infer .

That is especially important because AI failure in SRE is rarely dramatic at first. It often starts as subtle overconfidence. The agent sounds convincing, the team moves faster and only later does it become clear that the recommendation was based on incomplete evidence. Explainability is what keeps speed from turning into hidden fragility.

The 5th requirement: Evaluation in real incidents

Trust cannot be built on benchmarks alone. SRE teams need evidence from scenarios that resemble their actual world: noisy alerts, incomplete data, conflicting symptoms, repeated incidents and multi-service failures . This is why post-incident evaluation is becoming one of the most important practices in AI-assisted operations.

Some of the most interesting approaches focus on replaying past incidents and measuring how the AI would have performed once the real outcome is already known . That creates a concrete way to score whether the agent identified the right signals, prioritized the right hypotheses or recommended safe and useful next steps. It also shifts the conversation from hype to measurable reliability impact.

For SRE leaders, this is a critical mindset change. Do not ask whether the agent is impressive. Ask whether it consistently shortens investigation time, reduces false escalation, improves documentation quality and avoids introducing new operational risk . Trust follows evidence, not enthusiasm.

The 6th requirement: Fit with existing workflows

One reason some AI initiatives fail inside engineering teams is that they force a new workflow instead of strengthening the one that already works. SRE teams already have paging tools, Slack channels, dashboards, escalation policies and runbooks. An AI agent earns trust faster when it respects those patterns rather than trying to replace them all at once.

This is where incremental adoption becomes strategic. If the agent can appear in the incident channel, pull context from observability tools, draft timelines and recommend actions inside the systems engineers already trust, the barrier to adoption drops sharply. The agent becomes part of the response loop rather than another platform demanding attention during an outage.

That compatibility matters culturally as much as technically. SRE is built on disciplined operational habits. Tools that complement those habits can gain traction. Tools that disrupt them without providing value usually get ignored after the first few frustrating incidents.

If you need a more detailed guide to keep points while evaluating AI SRE tools, then check this buyer’s guide by one of the senior leaders.

What trust looks like in practice

When an SRE team truly trusts an AI agent, several things are visible. The team does not treat it as a novelty. They treat it as a bounded operational partner. They know where it adds value, where it must ask for approval and where it should stay out of the way.

Trust also changes behavior. Engineers stop wasting the first 10 minutes of an incident assembling basic context because the agent already did that well. Incident channels become more structured because summaries, timelines and likely causes are surfaced early. Runbooks improve because teams start writing them in ways both humans and machines can execute or reference . In that environment, AI is not replacing rigor. It is reinforcing it.

Most importantly, trusted AI agents reduce toil without eroding accountability. The on-call engineer is still responsible. The incident commander is still responsible. The organization still owns the reliability posture. The agent simply helps the system operate with more speed and clarity.

The leadership shift behind all of this

This is why the conversation about AI agents in SRE is ultimately a leadership question, not just a tooling question. Teams do not need another shiny automation layer. They need a clear philosophy for how autonomy, human judgment, safety and reliability will work together.

The most forward-looking SRE leaders will not ask, “How quickly can we automate incident response?” They will ask, “What conditions must be true before our engineers feel safe delegating part of this workflow to a machine?” That is a much better question because it forces investment in the real foundations: observability, governance, evidence, workflow design and measurable trust.

AI agents may become standard in reliability engineering over the next few years, but standard does not mean automatic. The teams that benefit most will be the ones that treat trust as infrastructure. They will build it deliberately, test it relentlessly and expand autonomy only where the evidence justifies it.

Closing thought

Before SRE teams trust AI agents, they need more than a capable model. They need grounded telemetry, explicit guardrails, human-centered workflow design, explainable reasoning, rigorous evaluation and operational fit with the systems they already rely on. Only then does the promise of agentic SRE become credible.

That is the real frontier. Not autonomous operations for their own sake, but reliable collaboration between humans and intelligent systems. In the end, SRE teams will trust AI agents for the same reason they trust any production system: because it behaves predictably, shows its work, respects constraints and makes the organization more resilient when it matters most .

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

A quick look at Cisco’s strategy to become a software monster

Wed, 10 Jun 2026 21:53:21 +0200

Cisco is in the years-long process of shifting from a hardware-centric business focused on switches and routers toward a broader software and services strategy, aiming to position itself as a central player in cloud, security, and AI-driven networking.

Cisco remains a dominant hardware vendor but has spent recent years investing heavily in software to build recurring revenue streams, said Jack Gold, president of J.Gold Associates. In fact in its Q3 earnings call in May, Cisco said that 49% of total quarterly revenue now comes from subscriptions to software, security and contract support rather than one-time purchases.

“What they are trying to do is get to a place where rather than just sell you a server or network switch and I’m done, is make themselves into basically a cloud service provider,” said Gold.

At the core of Cisco’s strategy is its growing focus on security and network visibility. With its equipment embedded across enterprise, telecom, and service provider networks, Cisco has a unique vantage point into data traffic. Gold noted that this visibility allows the company to expand into advanced security offerings, particularly as artificial intelligence introduces new challenges.

One emerging opportunity is identity management for AI agents. While identity tools for human users have been around for decades, managing identities for potentially millions of AI agents represents a largely untapped market. “This is a greenfield environment,” Gold said, adding that many organizations are still uncertain how to approach the issue.

In May Cisco announced plans to acquire Astrix Security for an undisclosed amount to bolster its AI agent security portfolio. Astrix is known for its security platform that specializes in identifying, managing and securing AI agents and non-human identities, such as machine-to-machine connections.

Cisco is also working to unify its existing portfolio into integrated platforms, which Gold says is its greatest challenge. “They still have a lot of ‘components’ that are not fully integrated at their customer sites. That’s why they are trying to build an overarching cloud management console. But it might be problematic for many customers who still have individual components they’ve had in place for years to fully get the overall integration in place, especially if they also have other vendor’s networking products in place,” he said.

Cisco did just this month roll out an overarching management scheme called Cloud Control that promises a single management plane spanning networking, security, compute, observability, and collaboration.

Competition remains strong. Rivals like Hewlett Packard Enterprise and Palo Alto Networks are pursuing similar platformization strategies, while cloud providers including Amazon Web Services, Microsoft, and Google offer security and identity solutions tied to their own infrastructures. However, Cisco’s strength lies in its extensive installed base and partnerships across enterprises, hyperscalers, and semiconductor firms, Gold said.

Despite some smaller product lines, such as its UCS server business and Webex, Gold believe Cisco retains a significant advantage due to its scale and reach. “They’re the 800-pound gorilla in this space,” Gold said.

Looking ahead, Cisco’s ambition is to become more than a hardware provider. The company aims to act as a comprehensive network fabric operator—effectively overseeing and securing the flow of data and AI-driven activity across complex environments.

openclaw 2026.6.6-beta.1

Wed, 10 Jun 2026 19:47:10 +0200

2026.6.6

Highlights

Security boundaries are substantially tighter across transcripts, sandbox binds, host environment inheritance, MCP stdio, Codex HTTP access, native search policy, elevated sender checks, deleted-agent ACP bypasses, loopback tools, Discord moderation, and Teams group actions; exec approvals now fail closed on timeout. (#91529, #91618, #91615, #91619, #91741, #91745, #91746, #91748, #91749, #91750, #91751, #91752, #91763, #89938) Thanks @joshavant, @pgondhi987, @mmaps, @eleqtrizit, @shakkernerd, and @drobison00.
Telegram delivery is safer and more coherent: account-scoped topics route to the right agent, streamed text survives tool calls, /compact works on generic ingress, callback handling uses concrete APIs, draft chunking is shared, durable dispatch dedupe moved into the SDK, and unauthorized DM text stays out of cache and prompt context. (#91189, #88682, #89588, #90212, #91876, #91874, #91904, #91478, #91915) Thanks @codysai001, @alexzhu0, @joelnishanth, @snowzlm, @obviyus, and @sallyom.
iMessage recovery and delivery now cover always-on inbound restart, durable echo markers, block streaming, idle approval discovery, hardened outbound transport, and actionable inbound startup diagnostics. (#91335, #91449, #88969, #88530, #91783, #91785) Thanks @omarshahine, @jmissig, and @colmbrogan.
Browser and MCP connectivity gained existing-session CDP support, discovered WebSocket validation, default-profile cdpUrl handling, safer browser-output boundaries, Streamable HTTP loopback transport, corrected OAuth/SSE authorization handling, and broader schema compatibility. (#91422, #89851, #91736, #91747, #91451, #80143) Thanks @pgondhi987, @anagnorisis2peripeteia, @lifuyue, @eleqtrizit, @LiuwqGit, and @HemantSudarshan.
Control UI startup and first-reply latency are lower through cached model metadata, removal of the startup catalog wait, lazy slash-command loading, and first-event tracing with slow-reply diagnostics. (#91531, #91538, #91568, #91583, #91598)
Provider support expands with OpenRouter OAuth onboarding and Claude Fable 5 adaptive thinking, while Codex sessions keep correct compaction ownership, local models skip guardian review, dynamic tool progress normalizes cleanly, and Gemma 4 reasoning replay is preserved. (#91830, #91882, #91590, #88630, #88768, #91696) Thanks @Patrick-Erichsen, @joshavant, @bdjben, and @Coder-Wangyankun.

Changes

CLI progress: emit Claude CLI commentary progress events and bridge inter-tool commentary into channel progress without exposing internal protocol scaffolding. (#89834, #90883) Thanks @anagnorisis2peripeteia.
Observability: allow trusted diagnostics channels to capture tool input/output content, add first-assistant-event traces, and warn on slow initial replies. (#91256, #91568, #91583) Thanks @amknight.
Plugins/ClawHub: dogfood reusable package publishing, let dry runs skip publish approval, allow declared installed trusted hooks, report managed plugin version drift, and warn instead of failing on retired Skill Workshop configuration. (#91574, #91591, #90004, #90927, #90838) Thanks @Patrick-Erichsen, @brokemac79, and @lonexreb.
Memory/providers: move the local llama.cpp runtime into its provider plugin, batch embeddings across files, persist the agent model catalog cache, and keep QMD JSON search one-shot while filtering stale REM recall previews. (#91324, #89138, #90457, #91837, #91851) Thanks @osolmaz, @mushuiyu886, @ai-hpc, and @TurboTheTurtle.
Channels/mobile: add the QQBot group mention toggle, improve iPad and iPhone control surfaces, and expose the active connection host in the TUI footer. (#91423, #91557, #89909) Thanks @cxyhhhhh, @Solvely-Colin, and @baskduf.
Performance: prewarm TUI runtime plugins, deduplicate plugin auto-enable fanout, trim dense text-delta snapshots, and reuse prepared startup model metadata. (#90782, #89978, #91580, #91531) Thanks @RomneyDa and @ai-hpc.

Fixes

Agent/session recovery: drop stale approval follow-ups after session rebind, remove drained reply-queue items by identity, recover stale main and visible replies, preserve Codex context-engine compaction ownership, lower the default compaction timeout to 180 seconds while respecting explicit configuration, and keep provider-failure terminal lifecycle state correct. (#85679, #91450, #91566, #91840, #91590, #91361, #91895) Thanks @openperf, @yetval, @joshavant, @wangmiao0668000666, and @TurboTheTurtle.
User-visible content boundaries: suppress Codex/Harmony protocol artifacts, neutralize browser and LanceDB memory media directives, redact transcript images, and preserve native /compact replies through source suppression. (#89151, #91422, #91425, #91529, #90212) Thanks @joelnishanth, @pgondhi987, @joshavant, and @snowzlm.
Channel delivery: keep WhatsApp captured replies attached to the successor controller after restart, retry Feishu rate limits, preserve Mattermost thread replies, canonicalize LINE webhook paths, restore Discord reply hydration and runtime timeout exports, and show OpenAI Realtime WebRTC assistant transcripts. (#85823, #89659, #91684, #91649, #90263, #91686, #90426) Thanks @itsuzef, @ladygege, @jacobtomlinson, @fuller-stack-dev, and @shushushv.
Cron: cancel active task runs cleanly, preserve terminal timeout/cancel state, and recover no-deliver tool warnings instead of silently losing the outcome. (#90666, #90678) Thanks @ai-hpc.
Gateway/config/auth: share the approval runtime socket token, replace arrays explicitly in config.patch, skip the deleted-agent guard only for valid ACP harness sessions, surface headless LaunchAgent state, verify SQLite auth migration before cleanup, and arm QMD startup maintenance. (#87105, #91551, #91219, #91614, #91740, #91978) Thanks @fuller-stack-dev and @scotthuang.
Providers/Codex: clarify quota errors, restore the Codex synthetic usage line, canonicalize Codex protocol assets, require API-key auth for realtime voice, normalize ACP model refs, preserve Gemma 4 reasoning_content, and avoid guardian review for local models. (#91390, #91709, #91507, #91567, #88630, #91696) Thanks @hxy91819, @brokemac79, @RomneyDa, @joshavant, and @Coder-Wangyankun.
Updates/builds: recover package Gateway restarts after refresh failure, expose plugin convergence repair, fall back to Corepack in PATH-less pnpm environments, seed the correct Docker store packages, and keep ClawHub dry-run and publish paths reusable. (#91581, #91599, #91547, #91591) Thanks @fuller-stack-dev, @sallyom, and @Patrick-Erichsen.
UI: require explicit user intent before opening chat sessions and drain restored chat queues after session switches. (#91480) Thanks @TurboTheTurtle.
Android: avoid the dataSync foreground-service type for persistent nodes. (#80082) Thanks @davelutztx.
Native hooks: bound relay lifetimes so abandoned native hook connections cannot linger indefinitely. (#91550) Thanks @joshavant.

From the data center to the edge: How to build secure, effective enterprise AI infrastructure

Wed, 10 Jun 2026 15:38:23 +0200

While hyperscalers and neo-cloud providers may get the lion’s share of attention for providing AI infrastructure, many enterprises are taking a build-it-themselves approach to meet their specific AI requirements. The success of such projects is crucial to achieving business objectives, yet companies face significant challenges as they try to scale pilots to production.

Organizations must keep up with the dynamic, ever-changing demands that AI applications place on compute and network infrastructure, from the data center to the edge. That means architecting systems to grow as demand warrants and to avoid performance bottlenecks. The architecture must also account for AI-driven security vulnerabilities and ensure appropriate defenses are in place.

Yes, it’s a tall order. But here, in simplified form, is a three-step plan for meeting those objectives.

Step one: Go modular

Integrating all the required components in piecemeal fashion for an AI factory is complex, costly, and fraught with integration risk. Start with a modular design, based on proven NVIDIA reference architectures. A modular approach combines pre-validated accelerated computing hardware, AI software, and orchestration platforms, as well as networking and storage capabilities.

A modular strategy speeds implementation and creates a faster time to value for your AI infrastructure. Using modules that combine compute, networking, and storage makes it easier to scale capacity as needed, whether in the data center or at edge facilities.

In addition, the modular approach simplifies the job of addressing varying requirements, from inferencing engines at the edge to massive-scale model training in the data center, while staying within the same solution family.

The same applies to easing integration processes, as modular platforms offer pre-validated software. The Cisco Secure AI Factory with NVIDIA approach, for example, includes hardware (Cisco AI PODS) that is pre-validated to work with NVIDIA AI Enterprise software; Cisco Security and Splunk Observability software; orchestration platforms such as Ubuntu, Red Hat OpenShift, and Rancher by SUSE; as well as storage systems including VAST Data, Everpure (formerly Pure Storage), Hitachi Vantara, Nutanix, and NetApp.

Companies can also choose to manage the hardware and software with the cloud-based Cisco Intersight platform, which provides monitoring and management for physical and virtual infrastructure from the data center to the edge.

Step two: Provide security at every layer

Embedding security throughout your AI infrastructure is critical to ensure continuous monitoring, threat detection, and response. However, this step can introduce tremendous complexity, especially given the bevy of cyber threats that AI introduces. Addressing them means implementing security solutions to cover all components of your AI infrastructure, including AI models, agents, applications, workloads, and the underlying infrastructure.

With agentic AI, which essentially empowers agents with decision-making capabilities, you need to secure agents as if they were employees. That means zero-trust policies should apply, including precise, context-aware controls to enforce least-privilege access for AI agents. If an agent is behaving suspiciously, it should be quarantined and investigated.

A critical benefit of Cisco’s modular approach is having all required security software built in. It simplifies integration and deployment while ensuring all security bases are covered.

Step three: Apply best practices from experts

Even if you follow steps one and two, you may still need assistance in determining your best deployment options.

Working alongside a vendor with a strong partner program and expert guidance can be a great asset. Value-added resellers (VARs) add value through expertise gained from numerous customer deployments and close relationships with their partners. Many also carry relevant certifications, such as the new Cisco AI Infrastructure Specialist Certification, which demonstrates credibility.

Vendors and VARs also offer professional services and NVIDIA enterprise support. The upfront costs are well worth it in the long run to minimize technical deployment and financial risks, lower your overall AI cost per token, and realize faster time-to-value from AI investments.

Learn how the Cisco Secure AI Factory with NVIDIA can help ensure a sound foundation for your enterprise AI projects.

Datadog baut Observability-Plattform zum autonomen KI-Teamkollegen aus

Wed, 10 Jun 2026 10:08:57 +0200

Auf der DASH-Konferenz präsentiert Datadog mit Bits AI SRE, AI Guard und Bring Your Own Cloud neue Funktionen für autonomen IT-Betrieb und KI-Sicherheit.

AWS adds FinOps Agent to bring cloud cost management into engineering workflows

Wed, 10 Jun 2026 05:33:03 +0200

For many CIOs, the challenge of cloud cost management is no longer identifying spending problems but determining what caused them, why they happened, and how quickly they can be fixed. As cloud environments expand and AI workloads add new layers of complexity, cost governance is increasingly becoming an operational challenge that stretches beyond centralized FinOps teams.

AWS is betting that its new FinOps Agent, currently in public preview, can help solve that problem by automatically investigating anomalies, answering cost questions, and routing findings directly to engineers and finance team members after drawing data and findings from existing services, such as AWS Cost Explorer, Cost Anomaly Detection, Cost Optimization Hub, and Compute Optimizer.

That routing, according to AWS, is made possible due to the agent’s integration with Jira and Slack, enabling alerts and optimization recommendations to be surfaced directly within the collaboration and ticketing tools that most engineering teams use.

Faster remediation and improved accountability

FinOps Agent’s value lies in stronger accountability and faster remediation that could result in improved cloud financial governance maturity.

“Most enterprises can already identify cost anomalies. What they struggle with is latency: Determining ownership, tracing the operational cause, and getting the issue in front of the correct engineering team quickly enough to matter,” said Dion Hinchcliffe, lead of the CIO practice at The Futurum Group. “FinOps Agent seeks to close the loop between detection, investigation, attribution, and operational response. That is strategically important because cloud inefficiency is often cumulative and highly distributed. Small misconfigurations repeated across thousands of workloads create enormous aggregate waste over time.”

In fact, the new agent’s automated root-cause analysis and routing, according to Ashish Chaturvedi, leader of executive research at HFS Research, is precisely what most enterprises currently lack.

“The gap in enterprise FinOps has never been data availability. The gap is what happens after the data surfaces. A cost anomaly detection alert fires, and then what? That workflow used to take hours and depended on a human remembering to do it. FinOps Agent collapses that entire chain into an automated loop,” Chaturvedi said.

The agent’s automated workflow could act as a way to embed accountability directly into cloud cost management processes, Chaturvedi noted.

“The agent traces the anomaly to a root cause, identifies the responsible owner (using your account-to-team mappings), and opens a Jira ticket in that engineer’s queue. When the person who caused the cost change gets the investigation summary in their own ticketing system, the accountability loop closes itself,” Chaturvedi said.

“That’s the real unlock: not better data, but data that arrives at the right desk at the right time with enough context to act on,” Chaturvedi added.

That automated workflow, according to Hinchcliffe, should also help reduce one of the biggest hidden costs in FinOps today: “The manual coordination overhead between finance, platform engineering, operations, and application teams.”

Bringing cost intelligence closer to developers

While the governance benefits may resonate most with CIOs and FinOps leaders, analysts say the new agent could also help reduce the burden on developer and engineering teams by making cost information more accessible and actionable without disrupting workflows.

“Traditionally, devs have had really poor visibility into the downstream financial impact of infrastructure decisions. Cost data often arrives too late, in the wrong format, or through centralized governance channels disconnected from day-to-day engineering work,” Hinchcliffe said.

“FinOps Agent brings cost reasoning directly into developer tooling and collaboration environments. The result is that developers can increasingly treat cost efficiency as a real-time engineering signal alongside performance, reliability, and security, which is exactly where mature cloud enterprises want it to be,” Hinchcliffe added.

New operating model for FinOps?

Beyond accountability and faster remediation, analysts also see the new agent as capable of driving “meaningful evolution” in the FinOps operating model for CIOs.

“FinOps teams move away from being the people who manually chase anomalies and toward being the designers of guardrails, policies, and operating models. Engineers take on more day-to-day ownership because the feedback loop becomes immediate and embedded. For CIOs, the implication is significant: governance becomes more distributed, which can improve speed and accountability,” said David Linthicum, an independent consultant.

However, Linthicum warned that CIOs shouldn’t take the FinOps Agent at face value: “Enterprises should watch for three things — whether recommendations are trusted, whether ownership routing is accurate, and whether actions actually get completed.”

“If AWS can make FinOps more embedded, contextual, and automated, this could be meaningful. If it becomes just another interface over existing data, the impact will be more incremental than transformational,” Linthicum pointed out.

Why AI may accelerate the shift to agentic FinOps

FinOps Agent could become more common and replace traditional FinOps due to the growing complexity and cost of AI deployments, analysts say.

“Traditional FinOps was built for infrastructure that scales predictably. Existing practices will buckle under AI workloads, and that will challenge this core underpinning principle. First, cost attribution is harder. Second, consumption is less predictable. Third, the ROI measurement is fundamentally different,” Chaturvedi said.

In fact, Hinchcliffe sees the new agent as part of a much larger industry transition from passive observability systems toward autonomous operational agents.

“FinOps is simply one of the first major operational domains where this transition is becoming commercially visible. The big implication is that CloudOps, SecOps, infrastructure management, governance, and even IT financial management are all likely to become increasingly agentic over the next several years,” Hinchcliffe added.

Enterprises and developers willing to try out the new FinOps Agent can do so from the AWS Management Console, the hyperscaler said.

The agent, which is available only in the US East region, currently comes at no charge, with a monthly usage limit, although standard charges apply for other AWS Services used in connection with the agent, it added. “It (FinOps Agent) can manage costs across other AWS Regions and accounts when set up in the management account,” the hyperscaler further said.

Elastic brings AI-driven incident investigation to Kubernetes and observability tools

Tue, 09 Jun 2026 16:37:52 +0200

Elastic has introduced an agentic Kubernetes investigation workflow and MCP-based observability skills that diagnose incidents the moment an alert fires. By the time an SRE opens the alert, the root cause has already been identified, evidence has been assembled, and recommended next steps have been surfaced. For teams running Kubernetes at scale, the gap between alert and answer costs time, compounds outages, and wears down on-call engineers. Elastic closes that gap by starting the investigation … More →

The post Elastic brings AI-driven incident investigation to Kubernetes and observability tools appeared first on Help Net Security.

Elastic brings AI-driven incident investigation to Kubernetes and observability tools

Tue, 09 Jun 2026 16:37:40 +0200

The post Elastic brings AI-driven incident investigation to Kubernetes and observability tools appeared first on IT Security News.

Adopting AI models is easy — scaling them requires shared open standards

Tue, 09 Jun 2026 13:08:52 +0200

The AI market is as competitive as any I have seen. When organizations look to implement the latest AI model or agent platform, many skip over the infrastructure-building required for successful deployment. This instinct is understandable – teams want to move quickly, deliver business impact and avoid falling behind in a fast-paced market. But models and frameworks only deliver value over time if they sit on a foundation built for production, not just initial deployment. As AI evolves from models to copilots to increasingly autonomous agents, the systems behind them must also evolve to support reliable, coordinated behavior at scale.

This foundation may not be as exciting as a new model release, but it becomes essential once you deploy AI broadly across an organization and allow access to enterprise tools and data. To responsibly build and scale this foundation, we need interoperable frameworks, shared protocols and secure, community-driven innovation. The agentic ecosystem will not scale or meet developer needs for reliability, security and consistency in isolated, proprietary silos.

The most important lessons from scaling cloud systems—shared standards and open-source community innovation—will be directly relevant to the AI era.

I’m seeing many of the same patterns emerge as when we built Kubernetes: a community converging on shared interfaces and operational patterns that made it possible to run distributed systems reliably at scale. Over the last decade, workloads have shifted from traditional web applications to AI-native applications, but the underlying operational constraints have remained the same.

Lessons from scaling the cloud

To understand what this looks like in practice, we can look at how we learned to operate distributed systems in the cloud. While AI introduces unique complexity, the operational shape is familiar. In distributed environments, feedback is slower, failures are complex and harder to diagnose and system-wide updates are difficult to implement safely, increasing the possibility that unnoticed failures accumulate into systemic instability. Those constraints shaped the cloud, and they shape production AI systems as well.

Kubernetes didn’t just make it possible to run containers: it addressed the harder problem of how to change live systems without breaking them. The solution wasn’t a single tool, but a set of operational patterns such as health checks, controlled rollouts and a consistent way to describe, review and manage change. Furthermore, the definition of health became more flexible, allowing users to evolve what a “healthy” application means over time within familiar contexts.

Another important lesson is the value of good defaults for a healthy system. Letting every team define their own patterns turns every operator into a system expert, which does not scale. If everyone follows their own individual approach, the subtle differences in choices make it impossible to build standardized tools which can work for everyone. This is why modern AI systems need to provide best practices and good defaults while still allowing flexibility to adapt over time.

The role of the open-source community in shaping standards

Most organizations treat AI as a product launch: ship a model, spot-check outputs and iterate quickly. This works for many features and updates, but it doesn’t work for probabilistic systems, where behavior can drift quietly and without obvious failure modes. AI requires us to move past the mindset that something is either “working” or “broken” and shift to a continuous understanding of output quality.

Open-source communities solved this problem for cloud systems by converging on shared interfaces and patterns. That convergence enables ecosystems of tooling and operational practices that make distributed systems repeatable at scale. AI systems need the same kind of convergence and consistency.

As agents operate across frameworks, clouds and environments, interoperability becomes critical. This means developing standards for the surfaces every team interacts with:

Interfaces for inference and routing
Common representation of quality gates and system health
Clear telemetry and tracing for understanding system behavior
Auditable identity and permissions that follow across multiple systems
Standard definitions to describe potential actions and their effects.

When standards are in place, organizations can standardize platform defaults, roll out changes gradually and keep rollback paths simple. The good news is that this is an extension of patterns already established in the cloud native ecosystem rather than a complete rethinking of what we need to build. The world of AI stands on the shoulders of a decade of cloud-native technologies, but we must adapt these technologies to the world of AI-native applications.

What Kubernetes can teach us about reliable AI systems and operating them at scale

Kubernetes worked because it assumed that within any application or service, change is constant and made change manageable by making it observable, staged and reversible.

AI systems need the same properties, but with an added dimension: “healthy” also now includes behavior. A model can return responses with low latency and still be wrong in ways that matter. Regressions show up as degraded results, not necessarily errors, which makes them harder to detect.

Because of this, “ship it and see” is a poor strategy, especially as agents begin to take on more autonomous roles. Testing a model on one or two prompts is no longer sufficient. You have to run thousands of tests and determine whether outputs have improved. Determining whether a change is better or worse requires evaluation across a wide variety of inputs. In practice, this often means both testing at scale with thousands of inputs and testing in production, where percentages of traffic can be sent through the new model and compared against the existing system.

Better models alone won’t produce reliable systems. But a focus on intentional, disciplined operations will. The success of AI systems is tied to user inputs and to the outcomes of probabilistic systems. While probabilistic systems aren’t as straightforward to manage as deterministic software, we’ve learned reliability comes from controlled release processes, observability tied to outcome quality and the ability to roll back quickly.

A similar lesson can be applied to operating AI systems at scale, ensuring it’s portable and durable for teams to build on it for years to come. The fastest way to fail with AI is treating it as a feature you ship instead of a system you operate. As organizations move beyond pilots and into production, the bar shifts from “it works” to “it operates safely.”

That requires a small set of non-negotiable practices:

Treat every model, prompt and data update as a full production release. If you can’t stage, observe and roll back, you’re not in control.
Measure full system behavior, not just health. Uptime and latency won’t tell you when output quality is degrading.
Design for safe failure. Build fallbacks, guardrails and clear escalation paths before the system is under load.
Standardize shared surfaces. Common interfaces, telemetry and release patterns are how operators build muscle memory.
Reuse proven patterns. Bad patterns create system failures. Reusable, open patterns reduce surprise.

We don’t need to invent a new operational philosophy for AI. We need to apply what Kubernetes and the cloud-native ecosystem already established: standardize where it matters, make change controlled and make system behavior observable. If we apply those lessons early, we avoid relearning them later under production pressure. AI is moving at a fast pace, and we must ensure we’re ready for continued innovation.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

7 sources of AI debt and how to avoid them

Tue, 09 Jun 2026 12:09:20 +0200

CIOs racing to experiment with AI models, test AI agents, and use vibe coding to develop applications may find themselves dealing with a new form of technical debt: AI debt. The pressure to accelerate proofs of concept (POCs) into production will likely drive teams to cut corners and leave known improvements as “to-dos” for future releases.

But speed isn’t the only factor that will create AI debt. Even with strong AI governance in place, advances in frontier models and new AI agents from SaaS platforms means that what gets POC’ed and moved to production today will require unanticipated changes in future releases.

Learnings from technical debt

Creating a framework for understanding, avoiding, and resolving AI debt should build on practices for reducing technical debt.

First, not all technical debt carries the same risks or priorities for resolution. Understanding the source of technical debt can help rank the likelihood of the issue impacting business operations and its severity. Seven types of technical debt include performance-limiting data management practices, open-source dependencies, architecture limitations, and cultural inhibitors. Data debt includes data quality issues, manual steps in data pipelines, and data management that lacks observability.

Second, prioritizing the work to address technical debt requires CIOs to communicate in terms that both technologists and business leaders comprehend. When there isn’t a shared understanding, business pressure to upgrade or deliver new capabilities may limit the work needed to address security vulnerabilities, fix defects, or improve operational resiliency.

AI debt can also be categorized by its sources. It also requires CIOs to communicate the risks of deploying AI capabilities before they are fully tested. But as we are early in the AI era, CIOs should put significant focus on ways to avoid the different types of AI debt as part of defining governance and guardrails.

Here are seven AI debt sources to consider, along with ways to avoid them.

AI experiments without targeted outcomes

The pressure to get more employees learning AI and testing AI agents is needed but comes at a cost. In addition to people’s time and rising token costs, prioritizing work without defining objectives can increase AI debt without leaving a clear understanding of whether the AI capability is delivering value.

“Outcome debt builds when organizations deploy AI without defining the specific, measurable business results they expect it to deliver,” says Rob Scudiere, CTO at Verint. “When teams chase experimentation or hype instead of outcomes, they accumulate systems that are technically impressive but operationally irrelevant. Anchoring every AI initiative to clear, verifiable results prevents this debt and ensures investments translate into stronger, faster, scalable impact.”

Recommendation: Avoid chaotic AI experiments by creating an ideation process before committing resources and by tracking active AI initiatives. Require teams to define their targeted outcomes and establish a risk registry covering any unknowns, concerns, and future fixes related to their AI implementations.

Feeding poor data quality to AI models

Poor data quality, a data risk CIOs should be paranoid about, gets amplified when used with AI models and agents. One key practice is to define a data trust score and prevent teams from allowing AI models and agents to use datasets that fall below targeted thresholds.

“Data quality debt is one of the most dangerous forms of AI debt because errors in training data and inputs cascade through models, pipelines, and downstream decisions,” says Abhi Sharma, co-founder and CEO at Relyance AI. “The best way to prevent it is to establish continuous data lineage and governance so teams can trace inputs, monitor transformations, and correct issues before they propagate into model behavior.”

A second practice is to extend data catalogs and data fabrics by establishing reusable data products. Data products become shareable multi-purpose assets with their own release cycle, treating AI agents and other users as customers.

“Organizations often don’t recognize data quality issues until an AI agent acts on flawed data, amplifying errors at speed and without human judgment,” says Mayank Mahajan, associate director of engineering at Xebia. “Unlike humans, agents cannot question inconsistencies or fill gaps, so they execute on whatever data is available. Package data as governed, well-documented products and implement observability early so issues like schema drift or stale data are caught before they scale.”

Recommendation: Communicate a set of data governance non-negotiables that establish clear minimal criteria for using data in AI, including compliance requirements around data privacy. Strong data governance practices help reduce the risk of data-related AI debt.

AI model drifts

One key concern when deploying machine learning models is recognizing when real-time inference data drifts from the model’s training data. Model drift is also an issue when using retrieval-augmented generation (RAG) or providing other contextual data to large language models.

“AI model debt builds when models drift or degrade without teams knowing why, leading to compounding performance and reliability issues,” says Amitkumar Rathi, chief product officer at Virtana. “Observability across models, data pipelines, and infrastructure helps identify whether issues stem from data drift, pipeline failures, or resource constraints like GPU contention.”

Recommendation: The key to avoiding AI model debt is through modelops practices, including cataloging models, implementing observability, baselining training data statistics, and monitoring for outcome drift. Rathi recommends, “By continuously linking model outcomes to operating conditions, teams can act early by retraining, fixing data inputs, or rebalancing resources before issues accumulate into long-term model debt.”

Overly entitled AI agents

Should AI agents have the same data access rights as their users? One form of AI debt is when access permissions and the underlying entitlements for AI agents require revisiting and auditing. Worse is when over-permissioned AI agents expose confidential data or make erroneous decisions when accessing sensitive data.

“Enterprises are deploying AI agents that query databases, trigger workflows, and make decisions at machine speed, yet they’re granting these agents broad, static permissions modeled on how humans access data,” says Ganesh Kirti, CEO at TrustLogix. “Every agent running with over-provisioned access or without context-aware controls is quietly accumulating security, compliance, and data integrity risk that compounds over time.”

Part of the challenge is that more organizations are deploying AI agents in mission-critical business processes. Deploying wide-scoped AI agents with broad data access rights can lead to operational risks and AI debt to address them.

“You insert AI into the process with a specific job defined, not any job, and you make sure that the inputs match the job specification,” says Matt Calkins, CEO of Appian. “You must give the AI agent a narrow range of possible outputs.”

Recommendation: To reduce the risk of AI debt from overly empowered AI agents, review the outcomes, decisions, and recommendations AI agents will be responsible for and apply a bottom-up review of the required data entitlements. “To avoid this debt, organizations need to treat AI agents as governed non-human identities with their own entitlement lifecycle, continuous, policy-driven authorization that adapts in real time, and not one-time role grants that nobody revisits,” Kirti recommends.

Teaching AI agents broken business processes

Robotic process automation (RPA) delivered significant ROI when applied to well-defined business processes. With AI agents, some have suggested that role- and task-based agents can perform the required work by providing sufficient context. But this assumes that existing business processes and the data they generate are accurate and reliable.

“Too many organizations are rushing to layer agentic automation on top of their existing processes and infrastructure,” says Don Schuerman, CTO and VP of marketing and technology strategy at Pegasystems. “Anyone can now quickly create an app with gen AI, but they struggle when they try to deploy it to do the real work inside real enterprises with all their complexities and dependencies.”

Recommendation: Avoid the rush to deploy AI agents before conducting upfront audits of existing processes and discussing future needs with business owners. Before generating a single line of code or deploying an AI agent, Schuerman recommends reimagining how work could be optimally done and how best to engage with customers across channels.

AI agent sprawl

AI agents are available across many platforms, and DevOps teams can use spec-driven development practices to build them. One organization’s chief digital officer recently told me they have already deployed over 1,000 AI agents.

The question is whether CIOs will repeat past mistakes when deploying tools that make it easy for business users to create new assets that are challenging to manage.

Consider the debt created by sprawling behaviors:

Spreadsheets were great for analytics until business users created too many of them, and there were few tools to manage the underlying data practices and change lifecycles.
Data visualizations were an upgrade, but top CIOs realized that governance practices were needed to manage citizen data science programs.

“Many companies already have more agents than employees, but lack lifecycle management, with no visibility into what agents exist, what data they access, or when they should be retired,” says Saket Srivastava, CIO at Asana. “Each unmanaged agent compounds risk, including security exposure, duplicated logic, and decisions no one can audit. CIOs should manage agents with the same rigor as employees, with clear ownership, role-based access to the right systems and data, and defined onboarding and retirement, before sprawl becomes a costly, hard-to-contain problem.”

Recommendation: CIOs of organizations with SaaS sprawl, especially those with a history of shadow IT, should define processes and controls for selecting, deploying, and managing AI agents.

Security lagging AI-generated code

The speed at which AI agents are developed, integrated with MCP servers, and deployed can compound security vulnerabilities. There are also questions about AI-generated code, with one study reporting that AI pull requests produce 1.4 times as many critical issues as human-generated ones.

Nikhil Mungel, head of AI R&D at Cribl, says, “AI-generated code debt can occur when teams use off-the-shelf tools that generate code that isn’t consistent with the company’s standards.”

Vrajesh Bhavsar, CEO and co-founder at Operant AI, adds, “As organizations scale AI agents and multi-step AI workflows, they inherit a rapidly expanding attack surface where adversaries are actively exploiting new threat patterns, including zero-click attacks that require no user interaction to trigger data exfiltration, poisoning, or leakage mid-workflow.”

Recommendation: Organizations that use AI code generators, vibe coding, or spec-driven development methodologies should consider adding AI code review tools such as CodeRabbit, DeepCode, Qodo, SonarQube, or open source options to their security programs. Mungel recommends embedding engineering best practices into skill frameworks, such as agents.md or skill.md, to ensure outputs comply with internal guidelines. In addition, Bhavsar recommends deploying adaptive, agentic-aware security controls that can detect and stop threats targeting AI agents in real-time.

AI is only reshaping businesses and not transforming them yet. The question for CIOs is whether the pressure to move AI experiments into production and deliver business value will create new forms of AI debt for them to manage in the years to come.

Lovelace boasts it can equal Gemini Deep Research at less than 1% of the cost

Tue, 09 Jun 2026 05:50:15 +0200

AI startup Lovelace has released a benchmark of 12 financial and business research tasks on which it says its agent achieved parity with Google’s Gemini Deep Research Max at “less than 1% of the cost.”

To carry out the test, the company says it built an investment banking research agent on top its context engine, YottaGraph, and Gemini 3.1 Flash Lite, with no grounding beyond the YottaGraph itself.

The benchmark, a release stated, “evaluated a range of complex financial and business questions, including company comparisons, acquisition scenarios and investment analyses. Reports were judged based on factual accuracy, analytical rigor, use of evidence and citation quality.”

The experiment was designed to answer this question: Can an agent powered by a lightweight LLM hooked up to Lovelace’s YottaGraph, and nothing else, provide deep, research-grade reports significantly faster and more cheaply than a flagship Deep Research model?

Looming crisis due to AI cost

According to a company blog post, it could: “Across 12 investment banking topics judged on a six-dimension, 1–10 rubric, it scored 9.67 mean versus 9.87 for Gemini Deep Research Max (3.1 Pro), at roughly six cents per report instead of seven dollars, and in under five minutes instead of 17 minutes.”

When asked what prompted the decision to embark on the benchmark, Andrew Moore, CEO of Lovelace, and the former head of Google Cloud AI, replied via email, “we know that there is a crisis looming because of the expense of AI.”

The Foundation Labs such as Google, OpenAI and Anthropic are, he said, “racing so fast towards more powerful AI that they, perhaps quite reasonably, are ignoring the expense in order to hit the finish line first. But if society is going to start deploying AI usefully, we feel it must be possible to do so without building thousands of new nuclear reactors and data centers.”

Moore predicted that context, not compute, will define the next generation of AI systems “because LLMs are closer to human cognition than traditional computer science. And they are being asked to do the equivalent of asking a human to hold thousands of things in their working memory while they are reasoning.”

The more things there are in working memory simultaneously, the massively more expensive things become, and that’s the context problem, he said, adding, “solve the context problem and you solve the cost problem.”

Carmi Levy, an independent technology analyst, said that he has long been uncomfortable with the industry’s “arms race-like mentality toward AI dominance,” noting, “Lovelace’s benchmarks suggest the industry may have been focusing on the wrong thing all along.”

Efficiency, he pointed out, has been almost invisible in the industry’s rush toward an AI-enabled future: “Bigger, ever more capable models have grabbed the headlines as vendors fight for bragging rights. And while size certainly matters in terms of any AI model’s ability to effectively crunch massive workloads, we seem to have ignored the costs of all that capability, and whether those costs are even worth it.”

Levy pointed out that someone would not use a sledgehammer to tighten a loose fitting on the front porch. “Instead, we’d choose a smaller, more effective tool to do the job,” he said. “The same logic applies in AI, and while the first few years of the AI era have been almost uniquely focused on the biggest, most powerful tools, we’ve failed to match the costs of all the capability to the underlying business issues that are being addressed.”

Enterprises bringing sledgehammers to every engagement, he said, “are probably significantly overspending relative to organizations that use tools specifically sized to a given business need. As metered AI use becomes a more mainstream reality in the enterprise, efficiency will need to become a priority.”

All of this, Levy added, “is as important for individual enterprises looking to control runaway AI compute costs as it is for vendors building the necessary data center and energy infrastructure to power it all. It’s also critical for governments to ask about efficiency before green-lighting an endless lineup of massively scaled infrastructure.”

Time to redesign AI models

Sanchit Vir Gogia, chief analyst at Greyhound Research, described the benchmark as being “meaningful, but not in the way the market will read it. It is not a clean win for small models over large ones. The defensible reading is narrower: for bounded, evidence-heavy research, the architecture around a model can compress the cost of a good answer by two orders of magnitude without degrading it.”

The industry, he said, “has spent three years acting as though intelligence lived inside the model, reaching for a bigger one whenever quality disappointed. That reflex is now meeting enterprise economics with all the grace of a grand piano pushed down a staircase. A brilliant model fed poor grounding is still a very expensive guesser.”

But financial research, said Gogia, “runs on filings and entities that behave like a graph. It is a graph-shaped problem wearing a research suit. The first question is no longer which model is most capable, but which system answers reliably at a defensible cost. Capability, in the enterprise, is now a property of the system, not the model.”

CIOs and CTOs, he added, “should treat the claim as a prompt to redesign their AI operating model, not as an instruction to buy a product. AI value is now determined by four connected disciplines: the quality of the context supplied, the routing of work to the appropriate model, the governance of the workflow, and the observability of what the system costs and does.”

He pointed out that an agent given poor context does not merely return a weak answer; it takes weak action, which is an operational hazard.

“Buyers should demand the cost of a completed workflow, and ask how portable the architecture is, since context lock-in is still lock-in,” he said. “The CIO’s task is to design the safest path from evidence to outcome.”

Distribution Release: RELIANOID 7.10.0

Mon, 08 Jun 2026 20:45:55 +0200

The DistroWatch news feed is brought to you by TUXEDO COMPUTERS. RELIANOID, a Debian-based Linux distribution featuring an open-source load-balancer, has reached version 7.10.0: "We are glad to present both RELIANOID 7.10.0 Community edition and RELIANOID 8.6 Enterprise edition, delivering significant improvements in security, system stability, observability, and load balancing capabilities. Both versions share a modernized Debian 12.14 base....

It’s safe to close your laptop now: Hosting coding agents on Amazon Bedrock AgentCore

Mon, 08 Jun 2026 18:48:12 +0200

Amazon Bedrock AgentCore Runtime gives each agent session its own isolated microVM with a persistent workspace, secure tool access through Gateway, and built-in observability—so you can run Claude Code, Codex, Kiro, and Cursor in parallel without sharing secrets, ports, or filesystems. Close the lid, go to dinner, and pick up where you left off tomorrow.

New Relic expands observability into AI-assisted software development

Mon, 08 Jun 2026 15:38:18 +0200

New Relic has announced AI Coding Observability, an open-source tool for monitoring AI-assisted software development workflows. As organizations adopt AI coding assistants, these tools often operate outside existing observability systems, limiting visibility into their use. AI Coding Observability extends monitoring into the software development process, enabling organizations to track, analyze, and audit AI-assisted coding activities. “You can’t manage what you can’t see. AI coding assistants are having a measurable impact on businesses, but without real-time … More →

The post New Relic expands observability into AI-assisted software development appeared first on Help Net Security.

New Relic expands observability into AI-assisted software development

Mon, 08 Jun 2026 15:38:15 +0200

The post New Relic expands observability into AI-assisted software development appeared first on IT Security News.

CIOs are being held accountable for AI they don’t fully control, IBM study finds

Mon, 08 Jun 2026 14:17:45 +0200

As enterprises race to deploy AI across business functions, many CIOs and CTOs are finding themselves responsible for systems they may not fully oversee, creating a new governance challenge for technology leaders.

A new IBM Institute for Business Value survey of 2,000 technology executives found that two-thirds of CIOs and CTOs are being held accountable for AI systems they do not fully control. The survey also found that 70% of respondents said technology is being deployed across the business faster than IT can track it, while 77% said AI adoption is already outpacing governance capabilities.

Surveyed executives expect the number of AI agents deployed within their organizations to increase by 38% by 2027, yet only 11% said they are fully prepared for the scale of AI-agent deployment they expect over the next year. According to IBM, 80% of respondents also reported CEO-driven mandates to accelerate AI transformation efforts.

“For CIOs and CTOs, the challenge now is scaling AI systems that operate continuously and autonomously, often within governance models and architectures designed for a far slower, more predictable environment,” Matt Lyteson, CIO at IBM, said in a statement accompanying the report.

Accountability does not move with control

The findings resonated with analysts who said the accountability gap highlighted by IBM is becoming increasingly common as AI adoption expands across business functions.

“AI capability is now embedded in SaaS, cloud, and business-led projects, so adoption happens at the edges of the organization while accountability stays at the top,” said Deepika Giri, AVP for Big Data and AI Research Lead at IDC Asia/Pacific. IDC research shows that only about 16% of organizations have a unified AI governance model, so the CIO owns risk for systems they don’t directly operate.

“Enterprises have decentralised experimentation far faster than they have decentralised accountability,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. “Control becomes shared the moment AI touches several platforms at once. Accountability does not move with it.”

According to analysts, AI is increasingly being embedded into enterprise applications, SaaS platforms, cloud services, developer tools, and business workflows that sit outside traditional IT governance structures.

“AI adoption is business-led, embedded in SaaS, cloud platforms, and developer tools, bypassing central IT with growing shadow AI,” said Charlie Dai, principal analyst at Forrester. “CIOs retain accountability for risk and cost but lack control due to federated models and hyperscaler-led abstraction.”

The result is that technology leaders often remain responsible for risk, compliance, and business outcomes even when critical aspects of deployment sit outside their direct control.

Rajesh Ranjan, managing partner at Everest Group, said many organizations now expect CIOs to deliver AI-driven business outcomes even though success frequently depends on process redesign, workforce changes, and operating model shifts that extend beyond IT’s direct remit.

Ranjan said AI adoption is advancing faster than enterprises’ ability to establish governance and accountability frameworks, creating “a growing disconnect between responsibility and control.”

Shadow AI raises the stakes

The analysts said the accountability challenge becomes more acute as AI adoption spreads through tools and services that business teams can access without significant IT involvement.

“Traditional shadow IT introduced unmanaged software. Shadow AI introduces unmanaged judgment,” Gogia said.

Businesses can now access AI capabilities through embedded SaaS functionality, external tools, APIs, copilots, and agent frameworks with little IT involvement, analysts said, expanding the challenge beyond traditional technology governance.

Dai said the risks extend beyond security and compliance to include unmanaged costs, regulatory exposure, prompt injection attacks, and vulnerabilities at the agent layer.

The challenge grows further as organizations move from AI assistants toward AI agents capable of making decisions, invoking tools, interacting with enterprise systems, and carrying out multistep tasks with limited human intervention.

“Agentic AI introduces dynamic, non-deterministic behavior and external interactions, breaking traditional governance models,” Dai said. “Enterprises lack real-time traceability into decisions, creating misalignment between accountability and actual system behavior.”

AI agents bring new operational risks

The survey suggests those governance challenges are already translating into operational consequences.

“By 2027, enterprises expect to deploy an average of 1,661 AI agents—a 38% increase from today,” the report said. “At that rate, tech leaders are tasked with managing hundreds of thousands of autonomous decisions daily. And manual governance can’t keep up with that math.”

Surveyed organizations reported an average of 54 AI-agent incidents during the past year that required human intervention or correction. Seventeen percent of those incidents were classified as high severity.

Among high-severity incidents, 37% resulted in data exposure or security breaches, 33% caused cascading system failures, and 17% triggered compliance issues, according to IBM.

The study also found that 59% of respondents view security and compliance concerns as among the biggest barriers to scaling AI agents. Organizations that embed governance directly into AI systems reported 25% fewer AI-related incidents than those relying primarily on manual oversight.

“This is why visibility now matters more than authority,” Gogia said. “Technology leaders do not need to approve every deployment. They need to know what is running, what it can reach, and how to stop it.”

Building governance into AI operations

The analysts said enterprises will need to move beyond governance models designed for periodic reviews and traditional software deployments.

“As AI becomes embedded in core business processes, governance can no longer be a periodic review exercise; it must become an operational capability,” Ranjan said.

Dai said enterprises should also prioritize centralized observability, policy controls, governed decentralization, and stronger data and context governance as AI adoption scales.

Enterprise network teams are falling behind as AI raises the stakes

Mon, 08 Jun 2026 12:23:55 +0200

Enterprise network operations teams are struggling to keep pace with the demands placed on them, and the challenge is growing as enterprises prepare their networks and observability tools for AI workloads.

Roughly 31% of IT professionals surveyed for an Enterprise Management Associates (EMA) benchmarking study said their organization’s network operations strategy is completely successful, a figure that decreased from 42% two years ago. That is one of the findings of EMA’s Network Management Megatrends 2026 report, based on a survey of 352 IT professionals across North America and Europe. The report confirms that network teams today face multiple pressures: a talent shortage, tool sprawl, hybrid and multi-cloud complexity, and AI workloads on networks that weren’t built to manage them.

“Network operators clearly know they need to do better, but they aren’t getting the support they need,” said Shamus McGillicuddy, EMA’s vice president of research for network infrastructure and operations, in a statement. “They need budget to fill empty seats on their teams. They need better tools. They need more automation. They need more influence over modern architectures, like hybrid and multi-cloud networks. CIOs need to step up and give network operators the support they deserve, especially if those CIOs want to succeed with AI transformation. Networks will make or break those projects.”

The state of the NOC

Tool sprawl remains a chronic condition for network operations teams. The typical IT organization uses four to ten monitoring and troubleshooting tools to manage its network, a number that EMA said has barely moved in more than a decade. Yet EMA found no significant correlation between the size of a toolset and operational success.

The data shows how much room for improvement exists, regardless of how many tools a team has:

58% of network problems are detected proactively before users experience their impact
Only 37% of alerts generated by network monitoring tools are indicative of a real problem
Manual administrative errors cause 28% of network problems
29% of the average network professional’s day is spent troubleshooting

“IT pros believe that 53% of the network problems that they are dealing with on a day-to-day basis could be prevented with better tools, so that gives you some color around why only 31% of the people we surveyed felt like they are completely successful with network operations strategy,” McGillicuddy explained on a webinar about the study results. “Tool replacement is widespread. Seventy-three percent of the people we surveyed said they are likely to replace, at least somewhat likely to replace, a network observability or network monitoring tool within the next two years.”

Megatrend #1: The talent crisis is getting worse

The share of organizations that find it somewhat or very difficult to hire network technology experts has risen from 26% in 2022 to 41% in 2024 to 52% today. According to EMA, the shortage is most apparent at the senior and mid-career levels, where cloud, security, and automation skills are most needed.

“We’re being asked to do more with less,” a monitoring architect with a Fortune 500 entertainment company said in the EMA report. “What used to be done by a 25-person team, management now wants us to do with a ten-person team.”

The talent gap is also driving the urgency to successfully deploy automation. Short-staffed teams need tools that handle more routine work automatically, so that the engineers they do have on staff can operate at a higher level, according to EMA. The skills gap itself can be the biggest barrier to achieving that automation, according to EMA. Teams often lack the people who know how to build and maintain the automation pipelines. Network teams shared their top barriers to automation, including:

Skills gaps within the team: 46%
Tool limitations or lack of integration: 36.4%
Insufficient data quality or visibility: 31.8%
Risk aversion or governance constraints: 31.8%
Budget constraints: 29.8%
Organizational resistance to change: 27.3%
Lack of trust in automation: 25%

Megatrend #2: The push to automate day-two operations

Network automation has meant provisioning and configuration, considered day-zero and day-one work. The new priority is day-two operations: the ongoing detection, triage, diagnosis, and remediation of network problems in production. Seventy-nine percent of respondents rate automating these tasks as a high or very high priority, according to the EMA report.

Organizations are looking for AI-driven, agentic automation: tools capable of reasoning about network conditions and taking autonomous or semi-autonomous action. The report found that 55% of respondents say AI features are a requirement when evaluating new tools, and AI-driven insights and automation is the top reason they would replace an incumbent. The day-two tasks organizations most want to automate:

Security response and containment: 54.3%
Capacity and performance optimization: 49.7%
Incident remediation and self-healing: 44.3%
Configuration optimization: 40.3%
Event correlation/alert noise reduction: 37.5%
Change validation and rollback: 26.4%

EMA found that an emerging enabler is Model Context Protocol (MCP) support, which gives AI agents a standard interface to interact with multiple network management tools. Successful NetOps organizations were more likely to prioritize MCP support for agentic AI access to tools, according to EMA.

“The MCP access points become like an abstraction layer across your tool sprawl,” McGillicuddy said.

Megatrend #3: Hybrid and multi-cloud networks remain ungoverned

Nearly seven in ten (69%) surveyed organizations operate hybrid cloud environments, and 66% are multi-cloud. Yet only 36% say they are completely effective at managing their cloud networks, a gap that reflects both technical complexity and cultural friction between network teams and cloud engineering groups.

EMA found the core challenges are familiar: proprietary networking constructs that vary across providers, inconsistent telemetry, skills gaps on the network team, and limited end-to-end visibility across cloud and on-premises environments.

“I still talk to network observability vendors that haven’t got feature parity across the big three cloud providers yet,” McGillicuddy said. “They might be good at collecting and analyzing data from AWS, but they’re still kind of far behind on things with Google Cloud Platform, and they haven’t even thought about some of the secondary ones yet.”

Organizations that have managed to integrate IP address management and extend network observability tools across hybrid environments report better overall outcomes, EMA said, but both remain works in progress for most.

Megatrend #4: AI networks need managing, and few tools are ready

Nearly half of respondents (47.7%) said AI training or inference workloads are already deployed on their networks. Most of the rest expect to deploy within the next two years. But only 35% say their current network observability tools are completely ready to manage those workloads.

The performance concerns are specific to AI infrastructure: isolating problems across networks, applications, and GPU clusters simultaneously; managing inference tail latency; and gaining visibility into GPU utilization as a network signal. The tool enhancements teams most want to close the gap:

AI-powered troubleshooting and remediation: 51.3%
Proactive alerting for AI-related performance risks: 49.3%
AI workload awareness via real-time packet analysis: 46.9%
Real-time streaming telemetry to replace polling intervals: 40.2%
Correlation of GPU, application, and network performance metrics: 34.3%

What successful teams are doing differently

EMA’s research also identified the practices separating successful organizations from those falling short.

The research firm found that successful teams hold network observability data to a strict accuracy standard. They have moved beyond scripts and runbooks to AI-driven and agentic management tools, and they prioritize integration over consolidation, focusing on security insights, workflow integration, and data sharing across their toolset rather than trying to reduce its size. And the successful organizations are building unified visibility and security controls that span both on-premises and cloud infrastructure, according to EMA.

“AI networking, or networks for AI, is going to require some retooling. I recommend you talk to your vendors about whether they’re thinking about this. Most of them aren’t, probably because they’re not hearing from you,” McGillicuddy said.

KI-Agenten zwischen Hype und Realität

Mon, 08 Jun 2026 09:01:39 +0200

KI-Agenten versprechen autonome Abläufe in IT, Entwicklung und Security. Doch echte Agentik entsteht erst, wenn Observability den nötigen Kontext liefert und Ziele, Tool-Zugriff, Feedbackschleifen und Automatisierung klar kontrolliert sind.

Tags: #Agentic AI | #KI-Agent | #Künstliche Intelligenz | #Observability

6 kritische Sicherheitslücken, die CISOs angehen müssen

Mon, 08 Jun 2026 06:06:18 +0200

width="1024" height="683" sizes="auto, (max-width: 1024px) 100vw, 1024px">

Zwischen dem Ist-Zustand in der IT-Sicherheit und den Anforderungen an moderne Bedrohungslagen, klaffen laut Experten einige Lücken. CISOs sollten diese Gaps überbrücken.

Golden Dayz / Shutterstock

CISOs räumen meist ein, dass kein Unternehmen vollkommen sicher ist. Viele geben jedoch auch zu, dass ihre Sicherheitsmaßnahmen noch nicht den gewünschten Standard erreichen.

Ein Drittel der für den „2025 Voice of the CISO Report“ (Download gegen Daten) von Proofpoint befragten CISOs gab an, dass die Daten in ihrem Unternehmen nicht ausreichend geschützt seien. 58 Prozent sagten, ihre Betriebe seien nicht darauf vorbereitet, auf einen Cyberangriff zu reagieren. Gleichzeitig waren nur zwei Drittel (67 Prozent) der Meinung, dass ihre Unternehmen über ausreichende Budgets, Personal und Tools verfügten, um ihre Cybersicherheitsziele zu erreichen.

Diese Zahlen deuten darauf hin, dass in vielen, wenn nicht sogar den meisten Betrieben nach wie vor kritische Sicherheitslücken bestehen. Da Angreifer zunehmend auf Automatisierung und Künstliche Intelligenz setzen, wächst der Druck, diese offenen Flanken zu schließen. Es folgen sechs kritische Gaps, die die Aufmerksamkeit der CISOs erfordern.

Die Wahrnehmungslücke

Obwohl CISOs in den letzten Jahren Business-orientierter geworden sind, sehen viele ihre Hauptaufgabe immer noch im Schutz digitaler Systeme. Diese sollten, laut Errol Weiss, CSO bei Health-ISAC, jedoch als Gewährleistung der Geschäftsresilienz betrachten werden.

„CISOs betrachten einen ‚schlechten Tag‘ immer noch aus der IT-Perspektive; sie sehen Sicherheit nach wie vor als ein IT-Problem“, bemerkt Weiss. Sie müssten ihren Fokus verlagern: weg vom Schutz der Systeme um jeden Preis hin zum Aufbau von Resilienz mit Augenmerkt auf Folgewirkungen, wenn etwas ausfällt.

Weiss merkt an, dass diese Lücke in vielen Unternehmen unter anderem deshalb weiterhin besteht, weil die Geschäftskontinuität, die das Herzstück der Resilienz bildet, in der Regel in den Zuständigkeitsbereich anderer Führungskräfte als der CISOs fällt. „Die Geschäftskontinuität war traditionell das Problem anderer, doch nun muss sie zu einem Schwerpunkt für die Sicherheitsorganisation werden“, sagt er.

Wenn CISOs sich umfassend damit auseinandersetzen, wie sich digitale Bedrohungen auf das Unternehmen auswirken könnten, anstatt damit, wie sich Angriffe auf die IT-Umgebung auswirken, erhalten sie ein genaueres Bild der größten Risiken und können das Ausmaß eines Vorfalls besser einschätzen, erklärt Weiss. Dies wiederum ermöglicht es CISOs, Abwehr- und Abhilfemaßnahmen effektiver zu priorisieren, wodurch ein Vorfall wahrscheinlicher eingedämmt werden kann und keine unerwarteten Folgen auftreten, die den Geschäftsbetrieb beeinträchtigen.

Der Speed-Gap zwischen Angreifern und Verteidigern

Der Jahresrückblick 2025 des Threat-Intelligence-Anbieters Cisco Talos stellte fest, dass „die Bedrohungslandschaft 2025 durch eine beispiellose Beschleunigung bei der Ausnutzung von Schwachstellen geprägt war, wobei Angreifer neue Sicherheitslücken wie React2Shell und ToolShell fast unmittelbar nach ihrer Offenlegung als Waffen einsetzten.“

Die meisten Sicherheitsteams agieren nicht so schnell, was zu einer Agilitätslücke zwischen ihnen und den Angreifern führt, sagt Buck Bell, Director of Security Strategy beim IT-Dienstleister CDW. „Die meisten Lücken, die wir heute sehen, sind Lücken in der Umsetzung“, fügt er hinzu.

Viele Sicherheitsprogramme basieren nach wie vor auf veralteten Denkweisen, darunter „statische Sicherheitsmaßnahmen in einer Welt, die Anpassungen in Echtzeit erfordert“, sagt er. Monatliche Penetrationstests und Patch-Dienstage beispielsweise sind Relikte einer vergangenen Ära, die in einigen Sicherheitsabteilungen jedoch nach wie vor bestehen. „Die Realität ist, dass Unternehmen heute schneller handeln müssen“, fügt er hinzu.

Bell sagt, dass zeitgemäße CISOs ihre Abläufe beschleunigen, indem sie KI, Automatisierung und Praktiken wie Continuous Threat Exposure Management (CTEM) einsetzen.

Der Speed-Gap zwischen Geschäft und Sicherheit

Ebenso müssen einige CISOs schneller und agiler werden, damit die Sicherheit genauso schnell voranschreiten kann wie das Geschäft. Wie das Beratungsunternehmen PwC in seinem „2026 CISO Outlook“ feststellt: „Die Rolle des CISOs befindet sich an einem entscheidenden Wendepunkt. Angesichts der technologischen Beschleunigung und neuer Bedrohungen wird von Ihnen erwartet, dass Sie im Tempo des Wandels vorangehen. KI, Quantencomputing und eine hypervernetzte Welt gestalten Risiken neu – und Ihr Unternehmen beobachtet das genau.“

Chirag Shah, Global Information Security Officer und Datenschutzbeauftragter beim Softwareunternehmen Model N, weiß: „Das Geschäft will schneller laufen und wenn es schneller laufen will, bedeutet das, dass wir in den Bereichen Sicherheit und Compliance mit ihm Schritt halten müssen.“ Aber er weiß auch, dass die Sicherheit Mühe hat, Schritt zu halten. „Wir spielen immer ein Aufholspiel“, fügt er hinzu.

Shah hat Maßnahmen ergriffen, um den Prozess zu beschleunigen, beispielsweise durch die Weiterbildung des Sicherheitspersonals im Bereich KI, damit sie gemeinsam mit dem Unternehmen an dessen vorrangigen Projekten arbeiten können.

Chris Cochran, Field CISO und Vizepräsident für KI-Sicherheit am SANS Institute, erklärt, dass CISOs, die Rahmenwerke und Standards einführen und mit ihren Sicherheitskollegen zusammenarbeiten, ebenfalls Geschwindigkeit aufnehmen können, indem sie sich bewährte Strategien zu eigen machen und umsetzen, die sich im Zuge von Veränderungen im Business schnell erweitern und skalieren lassen.

Die Skill-Kluft

CISOs haben seit langem Schwierigkeiten, die benötigten Fachkräfte zu finden. Früher ging es vor allem darum, genügend Personal zu finden, um Stellen zu besetzen. Heute sind sie eher besorgt, dass Sicherheitsexperten nicht über die aktuellen Kompetenzen verfügen, die sie für den Erfolg benötigen.

Laut dem „SANS 2026 Cybersecurity Workforce Research Report“ (Download gegen Daten) „durchläuft die Belegschaft im Bereich Cybersicherheit einen grundlegenden Wandel. Unternehmen bauen ihre Teams top-down neu auf, da künstliche Intelligenz traditionelle Einstiegspunkte verdrängt. Zugleich schaffen regulatorische Compliance-Anforderungen neue Rahmenbedingungen für die Validierung von Kompetenzen. Diese Konvergenz führt zu einer breiter werdenden Qualifikationslücke, die Unternehmen nur schwer schließen können, obwohl sie zunehmend erkennen, dass die richtigen Fähigkeiten wichtiger sind, als einfach den Personalbestand aufzustocken.“

Weiter heißt es: „Der Bedarf an Spezialisten in neuen Rollen hat sich im Jahresvergleich fast verdoppelt, während die zusätzliche Einstellung von Mitarbeitern mit bestehenden Kompetenzen erheblich zugenommen hat.“

Das treibt CISOs zunehmend Sorgenfalten auf die Stirn: 60 Prozent der Sicherheitsverantwortlichen bezeichnen diese Qualifikationslücke als ihre größte Herausforderung im Personalbereich für das Jahr 2026 (gegenüber 52 Prozent im Vorjahr). 40 Prozent gaben an, Personalmangel sei ihr Hauptproblem.

Beth Miller, Global Field CISO beim Softwarehersteller Mimecast, sagt, dass es nicht nur eine Qualifikationslücke im Sicherheitsbereich ist, die CISOs zu schaffen macht. Die Kluft bestehe bei den benötigten Sicherheitskompetenzen im gesamten Unternehmen. „Man kann ein hochqualifiziertes Sicherheitsteam haben, aber wenn man nicht auch im gesamten Betrieb über Sicherheits-Skills verfügt, bleibt dennoch eine Lücke“, sagt sie. Um diese Lücke zu schließen, müsse man „in die menschliche Komponente im gesamten Unternehmen investieren“, fügt sie hinzu.

Cochran vom SANS Institute machte ähnliche Beobachtungen und erklärte, dass CISOs eine Kultur des kontinuierlichen Lernens und der Weiterbildung aufbauen müssen.

Lücken bei der Absicherung von KI

CISOs hinken bei der Absicherung von KI-Implementierungen aus mehreren Gründen hinterher.

Zunächst einmal, so Miller von Mimecast, „entwickelt sich der KI-Bereich schneller, als CISOs darauf vorbereitet sind. Das Muster, das wir in unserem und anderen Unternehmen beobachten, ist, dass die Führungsebene eine Initiative ankündigt, um KI einzuführen – das läuft top-down und ist oft mit Wettbewerbsdruck oder den Erwartungen des Vorstands verbunden. Dann entwickeln die Geschäftsbereiche innerhalb weniger Wochen KI-Tools, verbinden diese mit Daten und integrieren KI in bestehende Systeme, während die CISOs erst während oder nach der Implementierung von diesen [Initiativen] erfahren.“

Es gibt auch KI-Deployments, die von bottom-up erfolgen, oft ohne jegliche Beteiligung oder Kenntnis der Führungsebene. „Schatten-KI findet in der gesamten Branche statt“, sagt Shah von Model N. Während die Sicherheits- oder IT-Abteilung diese Implementierungen vielleicht nachträglich entdeckt, beseitigt das Sicherheitslücke nicht von selbst.

Experten verweisen zudem auf zwei weitere Herausforderungen: Erstens gilt es, die richtigen Sicherheitskontrollen für KI zu entwickeln, während sich die Technologie weiterentwickelt. Zweitens müssen alle Beteiligten davon überzeugt werden, diese Kontrollen und Governance-Rahmenwerke zu akzeptieren und einzuhalten, während sie sich mit der Technologie weiterentwickeln. Diese Dynamik führt unweigerlich zu einer Kluft zwischen dem, was zur Sicherung der KI erforderlich ist, und den tatsächlich umgesetzten Kontrollen. „Es handelt sich um eine Governance-Lücke, die sich als IT-Problem tarnt“, fügt Miller hinzu.

Der SANS-Bericht ergab, dass nur 54 Prozent der befragten Unternehmen über KI-Sicherheitsrichtlinien verfügten und nur ein Fünftel (20 Prozent) über umfassende Governance-Rahmenwerke. Währenddessen implementieren etwa 75 Prozent entweder Governance-Strukturen oder noch dabei waren, diese aufzubauen.

SANS kam zu dem Schluss, dass „die KI-Sicherheits-Governance noch in den Kinderschuhen steckt“. Andere Experten bestätigten dies und erklärten, dass CISOs sich auf

Observability-Tools,
die Fähigkeit, Einfluss auf die Führungsebene zu nehmen,
KI-bezogene Sicherheitssensibilisierung und -schulungen,
neue Best Practices für KI-Sicherheit sowie
neue KI-Governance-Rahmenwerke

stützen müssen, um die in vielen Unternehmen offenbar klaffende Lücke zu schließen.

Die Legacy-Lücke

Laut Jason Lish, Global CISO bei Cisco, legen viele Führungskräfte im Business in Bezug auf Technologie eine „Set-it-and-forget-it-Mentalität“ an den Tag. Sie sträuben sich gegen Modernisierungsmaßnahmen der IT, solange die Systeme funktionieren und keine Wettbewerbsvorteile bieten.

Dies stellt nicht nur CIOs vor Herausforderungen, wenn sie versuchen, KI und andere neue Technologien in Altsysteme zu integrieren, sondern auch CISOs, die moderne Sicherheitspraktiken und -technologien implementieren wollen, erklärt Lish. Dase wird zu einem immer drängenderen Sicherheitsproblem, da Angreifer KI immer geschickter nutzen, um Altsysteme und solche ohne Support, in denen moderne Sicherheitskontrollen nicht implementiert werden können, auszunutzen.

Eine Studie aus dem Jahr 2026 der National Association of State CIOs sowie Deloitte & Touche ergab, dass CISOs die Legacy-Infrastruktur als eines der drei größten Hindernisse bei der Bewältigung von Cybersicherheitsherausforderungen nannten. Daneben nannten sie immer geschicktere Angriffe und unzureichende Finanzmittel für Cybersicherheit.

„CISOs sollten hier über einen risikobasierten Ansatz nachdenken“, sagt Lish, „sich an den Vorstand oder die Führungsetage wenden und sagen: ‚Dies sind die kritischsten Teile der veralteten Geräte, die wir ersetzen müssen‘, und ihnen helfen, das Risiko zu verstehen, das entsteht, wenn dies nicht geschieht. Der CISO muss derjenige sein, der diese Priorisierung vornimmt.“ (jd)

Microsoft's AI Futurist explains how he uses Copilot — and the real-world problems enterprises are solving with agents

Fri, 05 Jun 2026 22:17:26 +0200

Microsoft used its Build 2026 conference this week to push a clear message: agents are rapidly moving into production throughout enterprise systems, and the winning platform will be the one that gives them reliable context, governance, identity, memory — and secure access to enterprise data.

The company announced Microsoft IQ as a context layer across GitHub Copilot, Microsoft Foundry and Copilot Studio; Work IQ APIs coming June 16; Fabric IQ for structured business data; Foundry IQ for retrieval across enterprise knowledge and the live web; and Web IQ as a new agent-facing web search stack.

Microsoft also introduced Scout, a personal work agent, and a whopping seven new in-house AI models in its growing MAI family across modalities and use cases, including MAI-Thinking-1.

Those announcements sit directly in Marco Casalaina’s lane. Casalaina is Microsoft’s VP Products, Core AI and AI Futurist. He leads Microsoft’s AI Futures team and previously led teams across Azure AI, including Azure OpenAI, Vision, Speech, Decision, Language, Responsible AI and AI Studio.

Before Microsoft, he led Salesforce’s Einstein AI team and earned a computer science degree from Cornell University. CRN reported that he joined Microsoft in early 2022 as vice president of products for Azure Cognitive Services, meaning he has now been at the company for more than four years.

VentureBeat spoke with Casalaina ahead of Build about Microsoft’s agent strategy, the company’s model-choice philosophy, how Microsoft IQ fits with MCP, and why he believes enterprises need far more than just access to powerful models. The interview below has been edited for clarity and condensed from the transcript.

VentureBeat (VB): To start, can you explain your role at Microsoft and what “AI Futurist” means in practice?

Marco Casalaina (MC): I am VP Products of what we call Core AI. Core AI is our set of tools for AI developers, and that includes Foundry, Visual Studio, VS Code, GitHub and GitHub Copilot. That’s our overall group.

My Silicon Valley title is AI Futurist, and that has a very concrete meaning here. I’ve worked with other folks who are considered futurists, like Peter Schwartz, and that can be a little bit more fuzzy. For me, what it means concretely is that I am the first person to try anything new here.

I am constantly getting things from all over Microsoft, not even just Foundry, because I work with really everybody across the company. Pretty much everybody sends me the new things at all times. Even today, I got something brand new just before this call. I’m usually the first person to try anything new here, which is pretty cool. I get to see a lot of really cool stuff.

A friend of mine, who is head of AI at Intuit, calls me an “adjacent possiblist.” I consider my futurist concept to be about a year out from now — the immediate future of what’s about to happen next. That’s what I focus on.

VB: Where are you looking at the agentic state of things, and in particular Microsoft’s position as enterprises and individuals rush to adopt agentic AI?

MC: We can look at it from bottom to top. At the very base of the stack is our commitment to model choice. All along, we’ve had the OpenAI GPT frontier models. Now we have a really solid partnership with Anthropic, where we’re offering the Claude models. We just launched Claude Opus 4.8 on Azure — on Foundry, I should say — and at Build, we are introducing our new MAI model.

The MAI models are a set of frontier models that we’re building in-house. They are made for token efficiency, optimization and customization. We are specifically making them for our customers to customize on their own data sets.

One level above that, we are announcing hosted agents in Foundry. That is our managed agent capability in Foundry. It automatically handles scaling, containerization and those kinds of things. It is an environment where you can manage agents.

One level above that is the Foundry control plane. At least for the agents you build, you want to have control over them. This gives you observability into their cost, tokens and correctness. You can do continuous evaluations and sample interactions with those agents, run evals and make sure they are continuing to work and not drifting.

The big news is going to be the GA of what we call the IQs here at Microsoft. There are currently three, and there will be four. There is Foundry IQ, which is basically for knowledge — largely unstructured knowledge. There is Fabric IQ. We have a ton of customers who have entrusted a lot of data to the Microsoft Cloud in Fabric, Power BI and related technologies. Fabric IQ is about making an agent-facing interface for this data, so agents can get to it without literally going through a Power BI report. That’s ridiculous.

Work IQ is about the Microsoft ecosystem. You can look at Work IQ as the agentic face of all the Microsoft apps: Outlook, Teams, Word, SharePoint and all those kinds of things. How does an agent interact with those things? That is Work IQ.

And finally, the fourth IQ is Web IQ. We are releasing our new agent-facing web search capability. It can search the web, search through videos and even do some kinds of browsing tasks automatically. It is super fast, and it kind of has no face. It’s headless. The interface is intended for agents.

We will also be announcing Agent Optimizer. That includes a new type of evaluation that allows you to evaluate much more granularly whether an agent is actually working and working correctly. The optimization step can go back in and make modifications to the prompt, obviously with your consent, and modify your agent so it works more correctly going forward. Effectively, it creates a feedback loop to make agents work better.

VB: Microsoft has sometimes been criticized for murky and clunky product naming. Where do these IQ products sit? Are enterprise users supposed to go to IQ first, or is IQ more for developers to connect to?

MC: All of the IQs are headless. The concept of IQ is that each one provides a different type of context to an agent specifically. Largely, it will be developers interacting with the various IQs — developers and the agents they build.

The IQ brand is really about agent context. End users largely won’t interact with the IQs. It is true that if you use Microsoft 365 Copilot today, you’ll notice a little thing that says it is using Work IQ. So it is a little bit visible, but the customer or end user doesn’t have to go find the IQ. Their system or developers hook that up.

VB: Is the IQ family essentially Microsoft’s version of MCP? Is it using MCP, or is it something different?

MC: All of the IQs are indeed exposed as MCP servers. You have correctly characterized MCP as basically an agent-facing or self-describing API. It’s not that fancy. That’s really what it is, with some authentication layers and capabilities built in, which is super useful.

Something like Work IQ — really all the IQs — have to be authenticated. In order for Work IQ to see my email, Teams messages, documents and stuff like that, I have to be able to authenticate it on behalf of me.

That gets us to another core differentiator that we will be announcing at Build, which is agent identity. We have this Entra system, and Entra is, I believe, the world’s largest used identity system for human users. For some time now, you have been able to declare an agent to have an identity in there. Now, agents will be able to have their own identity, their own Teams box, their own email inbox and stuff like that.

These agents will use Work IQ to check their own email, check their own documents and that sort of thing.

VB: Enterprises are not one-size-fits-all on models. Microsoft supports many leading models through Foundry and Azure, while also building its own. Is Microsoft a model company, an infrastructure company or a connector between models and work products?

MC: The answer is yes. We are obviously the hyperscaler. We are absolutely committed to model choice, and we will continue to offer the frontier models from all of the major players: OpenAI, Anthropic, Mistral, Black Forest, xAI — you name it. They are all going to be represented in there.

At the same time, we have what is now called our Microsoft AI Superintelligence Team, formed by Mustafa Suleyman, and we are building our own frontier models as well. Like I said earlier, we are really gearing these models toward optimization — token efficiency, bang for the buck and customization.

These are things our customers have been asking for: the ability to more finely customize models, whether that is fine-tuning or continued pre-training. Continued pre-training is literally changing the weights of the model, whereas fine-tuning is adding a little layer on top.

We have these capabilities in Foundry: fine-tuning, distillation and those kinds of things. I would note, by the way, that our MAI models are not distilled. Some model providers, especially some of the less scrupulous ones, will distill other models into theirs, and that can have unusual effects. We don’t do that. The data provenance of our models is of primary importance to us.

When we come out with these models, we want our customers to know that the data provenance is clean in terms of the rights to the data, where it came from and all that kind of stuff.

The choice thing also goes above the model layer. When we talk about Foundry hosted agents, we have the Microsoft Agent Framework. You talk about agent orchestration — how you make agents work together when you have multiple agents — and Microsoft Agent Framework is an excellent framework for that.

However, I can make a LangGraph or LangChain Foundry hosted agent. I can make a CrewAI Foundry hosted agent. I can use any number of orchestration frameworks and put that up as a Foundry hosted agent, and it becomes a first-class Foundry agent.

That means I get the observability. It shows up in the Foundry control plane. I can do evaluations on it. I can do traces on it. I can get all those things from the Foundry control plane with an agent built in really any framework I choose.

VB: Some companies are interested in Chinese and open-source models. How much of Microsoft offering its own models is about giving customers an American version of that?

MC: I can’t speak to that exactly. Of course, we offer DeepSeek models and Qwen models in Foundry, so we offer all of these choices today, and our customers can make that choice.

The MAI models are really focused on token efficiency and customizability. That is what our customers are demanding, and that is the gap we are filling.

VB: As agents take on longer tasks and more specialized work, will enterprises keep expanding the number of models they use, or will there be a winnowing?

MC: I do see it expanding. We are not just focused on tokens per se. A token is not a token is not a token. One token is not necessarily equivalent across these things. It is all about what you are doing with each token and the efficiency of that. It comes back to what kind of value you are getting for the cost. That is a lot of the rationale behind why we are developing our own MAI models.

Part of my job is to travel all around the world. I’ve been all over the place. For example, I’ve been working with Bayer. One of the things we are measuring is not just token usage, but number of users — monthly active users and daily active users — because we have a lot of first-party capabilities like Microsoft 365 Copilot. Over the last year, we’ve seen a 6x increase in monthly active users. We have over 20 million users of Microsoft 365 Copilot alone.

That is on the agents you use. In terms of the agents you build, Bayer put up its own agent system on Foundry, and now it has 20,000 of its own employees on it.

A few weeks ago, I was in Sydney, Australia, hanging out with AEMO, the Australian Energy Market Operator. They operate the electrical grid of Australia. They showed me that they had built agents to manage grid operations.

This is a human-centered thing. They have grid operators sitting in centers in West Sydney, Brisbane and places like that, and they are bombarded with alerts. I wouldn’t believe it if I hadn’t seen it myself. The alerts are constant. They built a system to triage those alerts. Is this alert a super major thing, or is it just that a transformer is getting a little hot? It also says, here is when we had this problem last time, and here is how we resolved it last time. Maybe now we need to replace this component, or whatever.

Ultimately, it is the grid operators making the choice. A lot of our philosophy here is human empowerment. These human-centered agents are the ones that are working best among our customers. What I saw at AEMO and Bayer is this notion of human empowerment: taking away some of the grunt work, or in the case of AEMO, taking billions of alerts and reducing them to something much more manageable and actionable for the people involved.

We are moving past the era where agents are just answering questions. AI in general is moving past that. We are not just answering questions anymore. We are moving toward a place where AI can really meaningfully help you do your work.

VB: How do observability, tokenomics, ROI analysis and agent governance fit into Microsoft Foundry?

MC: That is what the Foundry control plane is all about. We introduced it in November of last year. If you looked at my own Foundry control plane — I’ve built a ton of these agents, and I am a developer by background — you would see all of my agents that are running and the ones that are paused.

I can see how many tokens they’ve used over the last day, week or month. I can look at trends. I can look at costs, because the cost will be different depending on what underlying model I’m using. If I’m using our model router, it can route to different models depending on the complexity of the inbound prompt.

We also have Azure cost management overall. Azure has had cost management for over a decade, before the AI thing even happened. This integrates with overall Azure cost management.

It is not just narrowly about what your AI is doing. Your AI will be using storage resources, data resources and other compute resources around that AI. You can get a complete picture of not just the cost and token usage of the AI itself, but everything around it.

When you think about governance, that also extends to evaluation. One of the things we are releasing in preview is rubric-based evaluation. Rubric-based evaluation is much more granular.

Let’s say you have built a restaurant reservation agent. The things you want to test about that agent are not really groundedness. Groundedness is the opposite of hallucination, and that is very question-answering. For a restaurant reservation agent, you want to test very granular things. If you say, “Make me a table for two tomorrow,” did it come back and ask, “What time would you like the table?” Before it gave you a table for two tomorrow at 6 p.m., did it actually check that the table was available, or did it randomly give you a table without checking first?

There are very granular things you want to test about that specific use case. You don’t just want to test whether the agent works. You want to test whether the agent works right.

That is what we are approaching with our new rubric-based evaluation system. You will see that in Satya’s keynote. I have been using it myself lately, and I’m very happy about it. I’ve been waiting for this.

VB: Microsoft is also partnering with companies like Anthropic and allowing Claude to work with Microsoft 365. How important is Copilot to this story? Why would someone turn to Copilot over other options?

MC: Microsoft 365 Copilot is a huge advantage for us. As I mentioned, we crossed the 20 million user mark on Copilot relatively recently.

The great thing about that is that it is the face. When you go into Foundry and make an agent, there is a button that says “publish to Copilot” — actually, it says “publish to Copilot in Teams,” because you can put it in Teams too.

The idea is that you want to put these agents where your users are. A lot of people who use the Microsoft ecosystem are in Teams, or they are using Copilot. I can create a custom agent, as many of my colleagues have, and now it is in Copilot, which I use maybe 50 times a day.

Since January, Copilot has become more and more capable. I now use it to draft my email. I am not just using it for question answering. I’m starting to use it to manage my calendar and draft emails. I really do this every day now.

When I want to use a custom agent — for example, to file my expenses, because we have a custom agent for that now — I can access that agent not in some random standalone interface, but in Copilot or Teams, where I already am.

That surface area that people are already engaging with is a major advantage.

VB: As people offload more repetitive work to AI, what are they able to spend more time doing?

MC: Let’s consider something I did yesterday. I got an email from a customer named Frankie, and he asked me a question about Foundry hosted agents. I knew the answer because I had talked to my colleague Jeff Holland, who is the head of our hosted agents product management. I had asked Jeff the same question two weeks ago.

Where or how I asked him, I don’t remember. Was it in Teams? Was it email? Was it a meeting? I don’t really remember. But I knew the answer to the question Frankie was asking.

So I went into Copilot and said, “Answer Frankie’s question about how hosted agents scale, and reference the conversation I had with Jeff a couple of weeks ago on this same topic.” And it did it. It drafted the email.

Over time, I have taught Copilot my style. I don’t do the bold-print thing. I tell it: don’t use em dashes and that kind of stuff. I have a certain style in the way I write emails. It’s a little terse, to be perfectly honest, but I want it to be the way I write.

It drafted this thing. It searched through my Teams messages, my emails and the transcripts of my meetings with Jeff. It used Work IQ, as a matter of fact. It found the answer, drafted the email and provided a link to the documentation that specifically covered the question Frankie was asking.

I looked at the draft and thought, yep, that’s it.

Yes, I could have composed this email myself. I knew the answer to the question. I could have looked up the documentation. If I dug around, I’m sure I could have found the conversation I had with Jeff in whatever medium that was. I could have done that stuff. It probably would have taken me, I don’t know, an hour to find all the information and compose it.

Instead, I did it in about a minute. I had a draft, I looked at it, I was happy with it, I pressed send, and that was the end of that.

It really is about giving people time back. It is not even just grunt work. It is all this time you spend looking things up and finding things. Now, I can make it take an action. It didn’t just answer the question. It fully drafted the email and copied Jeff.

VB: Do you fear for your job? How has AI changed your own work?

MC: I don’t fear for my job. My job has changed. For one thing, I do a lot more now, both in my business life and personal life.

This weekend I was using Web IQ, the new Web IQ. I’ve been car shopping. My car’s lease is coming up, and there is a very specific car I’m trying to find, which is hard to find. It’s a Hyundai Ioniq 6, which Hyundai, for whatever reason, has stopped offering in the United States. I’m going to get one, though.

I set my agent to the task, using Web IQ, of finding all the Hyundai Ioniq 6s available in the entire Bay Area — everywhere, all the way out to Sacramento, all the way as far south as Gilroy. I set it to this task, and then I went on a hike.

When I got back, I had a big long list of all the Hyundai Ioniq 6s, at least the 2024 and 2025 models, available in the entire Bay Area. From that, I started calling down these dealers.

Even in my personal life, I’m using it constantly. It saves me a ton of time. That would have taken me hours, to go through every single dealer’s inventory like this. But Web IQ could do that, and it was super quick.

VB: Any final thought for developers around this news?

MC: Foundry is really the place. This is the place where you can build your agents, scale your agents, test your agents and improve your agents. That’s what it’s all about, and it’s happening.

Multi-cloud doesn’t need another tool

Fri, 05 Jun 2026 16:03:01 +0200

Multi-cloud is now the operating reality of every serious enterprise. Governing it requires four disciplines – not another tool. A field-tested framework for the CIOs running it.

Tata Communications

Walk into almost any large enterprise today and ask the CIO how their multi-cloud is going. The answer is rarely a single sentence. It’s a list of qualifications: two strategic hyperscalers, a third for a regulated workload, a sovereign cloud for one geography, a colocation footprint for latency-sensitive systems, an on-premises estate that hasn’t gone anywhere, and a long tail of SaaS that quietly behaves like infrastructure when it fails.

This is not a failure of strategy. It is the strategy. Multi-cloud is the operating reality of every serious enterprise, driven by acquisition history, regulatory geography, AI workload economics, and the simple fact that no single provider is best at everything. The question has shifted from whether to run multi-cloud to how to govern what we already have.

And on that question, most enterprises are still trying to buy their way out. Another observability tool. Another policy engine. Another connectivity overlay. The result, predictably, is a stack with more dashboards than the people watching them have hours in the day, and a complexity tax that compounds in the seams between every tool the procurement team has signed off on.

The CIOs I work with – increasingly – have stopped asking what to buy next. They’ve started asking a different question: what would it take to run multi-cloud the way we already run finance, or security, or supply chain? As an operating discipline. Not a project. Not a stack. A continuous loop, with clear ownership and a clear cycle.

That is the case I want to make. Multi-cloud has matured past the point where it can be governed by tools alone. It needs an operating model with four disciplines, each of which the next three years will judge every CIO on: Measure, Route, Comply, Recover (Figure 1).

These aren’t sequential phases. They’re a closed loop. And the platforms that close it – disclosure: my team at Tata Communications is building one called IZO+ Multi Cloud Network (MCN) – are about to redefine what good multi-cloud looks like. The platforms that don’t will, eventually, be remembered as dashboards bolted onto point tools.

Tata Communications

Figure 1. The four disciplines of a multi-cloud operating model, arranged as a closed cycle.

PILLAR 1

Measure: Quantify what your bill never will

Of all the line items on the enterprise technology balance sheet, the largest one is the one no system reports: the cost of complexity itself. CFOs receive a cloud bill every month. CIOs receive an uptime dashboard every morning. Neither captures the cost of the routine policy change that needs three tickets across two teams, or the configuration drift in one region that surfaces as a customer outage in another, or the senior-engineer time spent reconciling things that should never have diverged.

The first discipline of a multi-cloud operating model is to make this cost legible. That means a complexity index – a quantified score, not a qualitative survey – that decomposes into the dimensions actually driving it: base connectivity, cross-domain coupling, governance gap, toolchain fragmentation, and geographic dispersion. (My team has built and patented one called the Enterprise Multi-Cloud Complexity Index. The framework matters more than the brand.)

A good index does three things a one-off assessment cannot: it is continuous (the score moves with reality, not with the audit cycle), decomposable (it tells you which dimension is driving the number, so remediation can be prioritised), and peer-benchmarked (it tells you whether your number is normal for your industry and your scale).

The CIO insight is simple: a one-off complexity score is a slide. A live one is an operating signal. And once you have an operating signal, you can do something with it. That something is the next three disciplines.

PILLAR 2

Route: Make applications self-networking

Once you can see complexity, the next discipline is to stop accumulating more of it. That is what routing – done right – does.

The traditional multi-cloud network is defined by infrastructure topology: VPCs, VLANs, transit gateways, peering connections, the long tail of NATs and firewalls in between. Every new application inherits that topology. Every new region multiplies it. Every team learns it differently. The result is what most enterprises now have: a network that can technically reach everywhere but can’t be reasoned about anywhere.

The shift that matters is from infrastructure-defined to intent-defined routing. The right unit of design is no longer the VPC; it is the application – or, more precisely, an Application Connectivity Domain (ACD): a logical boundary that spans clouds, regions, and on-premises footprints, and within which an application’s reachability, identity, and policy travel together. The infrastructure underneath becomes a substrate to be orchestrated, not a topology to be hand-stitched.

For AI workloads in particular, this matters more than most CIOs realise. All-reduce performance, inference latency, and data-gravity economics are all functions of physical fabric layout – GPU placement, interconnect topology, regional data residency. A network that doesn’t know where the GPUs are will route AI traffic the way it routes everything else, and the training run will pay for it.

The CIO question to ask: can my network be defined by what my applications need, or only by where my infrastructure happens to sit?

PILLAR 3

Comply: Move sovereignty into the data plane

For most enterprises, compliance is still something that happens after a routing decision is made. A packet flows; an audit later confirms whether it should have done so. A workload runs in a region; a quarterly review checks whether the data residency clause was honoured.

That model has expired. Between GDPR Article 44, India’s DPDP Act, the EU AI Act, the patchwork of GCC sovereignty mandates, and a growing list of sectoral regulations, jurisdictional rules now change faster than annual audits can catch up with them. Treating sovereignty as an after-the-fact check guarantees one of two outcomes: a compliance violation, or a chilling effect that slows every cloud decision into paralysis.

The discipline I’d urge every CIO to adopt is pre-flight compliance: jurisdictional assurance built into the routing decision itself, not bolted on afterwards. Before a workload is placed, before a packet leaves a region, before a failover target is chosen, the platform should already know which jurisdictions are eligible – and silently exclude the ones that aren’t. Compliance becomes a property of the data plane, not a clause in a policy deck.

The shift in CIO conversation is unmistakable when this works. The board no longer asks “Are we compliant?” They ask “What would it cost to add another jurisdiction?” – and the answer is a configuration change, not a programme.

PILLAR 4

Recover: Score yourself against your weakest layer

The February 2026 AWS UAE infrastructure incident was, for many of the CIOs I work with, the moment the recover discipline stopped being theoretical. Enterprises that had spent years building “multi-region” architectures discovered that being multi-region and being recoverable are not the same thing. Their compute had a backup region. Their data didn’t. Or their data did, but their identity layer was tied to the failed region’s IAM. Or every layer was technically replicated, but no one had ever tested the failover end-to-end under load.

The most useful framing I’ve seen is the Failover Readiness Score (FRS): a single number scored as the weakest of five layers – Infrastructure-as-Code, Network, Data, Workload, and Sovereignty. The weakest-link formulation is the entire point. Your real recovery time objective is governed by your worst-prepared layer, not your average. An IaC pipeline that can spin up a region in ninety seconds means nothing if the database promotion takes four hours, or if the failover target turns out to be sovereignty-ineligible for the data you’re moving to it.

Pre-flight failover simulation – running the failover continuously in shadow mode against multiple targets and reporting which are viable – is the discipline that separates resilience theatre from actual recoverability. The CIO question: if I had to fail over right now, against my second-best target, would my weakest layer let me?

THE SYNTHESIS

The loop

The four disciplines look like a stack. They are actually a feedback cycle.

Measure identifies the highest-complexity surfaces in your estate. Route lets you bypass or absorb them without rebuilding applications. Comply ensures every routing and failover decision is jurisdictionally clean by construction. Recover validates, continuously, that your weakest layer can carry the load when something goes down – and feeds the result back to Measure, which updates the complexity score and the cycle starts again.

The reason the loop matters more than any single pillar is that it eliminates the place where complexity wins today: the seam between teams. Today, measurement lives with the FinOps and architecture teams; routing lives with networking; compliance lives with risk; recovery lives with SRE. Each owns its piece. Nobody owns the seam. The complexity tax compounds in the seam.

A platform that closes the loop collapses the seams. That is the structural change underway in our category, and it is the change CIOs should be evaluating vendors against.

A four-question test for your next vendor conversation

Before the next multi-cloud purchase, ask:

Can I measure complexity continuously, not just survey it? A score that doesn’t move with reality is a slide, not a signal.
Can I route around complexity without rebuilding applications? If every new connectivity decision means new infrastructure, you’ve bought a tool, not a fabric.
Is compliance enforced in the data plane, or only in policy decks? If the answer involves a quarterly review, your sovereignty posture is a hope, not a guarantee.
Is my failover readiness scored against my weakest layer? Average preparedness is the wrong number. The weakest-link score is the only honest one.

If your current stack can’t answer all four with a straight yes, the right next move isn’t another point tool. It’s the loop. That, more than any individual product capability, is what separates the CIOs who will spend the next three years firefighting multi-cloud from the ones who will spend it compounding it.

To learn more, visit us here.

————————————————————

>About the author. The author leads product and strategy for IZO+ MCN, a multi-cloud overlay networking platform developed by Tata Communications. The Enterprise Multi-Cloud Complexity Index (EMCI) referenced in this article is a patent-pending framework. Views are the author’s own.

How Cisco IT cut observability costs by 86% and eliminated major network outages

Fri, 05 Jun 2026 15:08:37 +0200

When several database clusters started failing simultaneously, Cisco IT had all the data it needed to diagnose the problem. The signals were there. Engineers saw them. The issue was that those signals were landing in separate systems that did not talk to each other, and the team had no way to correlate them in real time.

What followed was three hours of war-room calls across three separate bridges. Engineers were on one call, debating ownership of the problem. Application owners were on another, waiting on the database to recover. Executives were on a third, trying to explain to business partners why users could not place orders. The root cause was eventually found, but the outage had already hit.

That incident became the impetus for a consolidation project that Anusha Nataraj, product manager in Cisco IT’s observability team, detailed in a session at Cisco Live.

The project has since reduced major incidents by 25% and produced zero major network outages over the last six quarters. The environment spans more than 1,500 applications, more than 71 of them externally facing, across more than 100,000 endpoints, processing more than 15,000 changes per month. The platform at the center of that consolidation is Splunk, which Cisco acquired in 2024. Cisco IT is now running its own product across its global infrastructure.

“We had the data, we had all the data, but [it’s] just that it was not stitched together, and we couldn’t see it all holistically,” Nataraj said.

The tool sprawl that made it worse

The pre-consolidation observability environment at Cisco IT was not a single gap. It was a collection of them. Logs were split across a partial Splunk deployment and Elastic instances. Metrics ran across Prometheus stacks, Grafana stacks and homegrown solutions. Event management ran on a separate homegrown platform. None of these systems fed into each other.

The team had considered staying with the existing mix, including Datadog and Elastic, and evaluated stitched-together open source alternatives. Three factors drove the decision against them. They could not scale to Cisco IT’s operational requirements, they lacked the AI capabilities the team needed, and they offered no roadmap that Cisco IT could shape as a customer.

“They worked at our department level, but they couldn’t scale to our IT needs, and they didn’t have the maturity of AI that we were expecting,” Nataraj said.

Nataraj was clear that the decision was not driven by the 2024 acquisition. The team evaluated Splunk against their requirements and selected it on fit, scale and AI roadmap.

The three-pillar consolidation

The consolidation followed a defined three-step sequence.

Log consolidation: All logs were moved to Splunk Cloud, retiring Elastic and other logging instances in the process.
Metrics consolidation: Currently in progress, with Prometheus, Grafana and homegrown stacks being retired as the work completes.
Business context via ITSI: The team is implementing IT Service Intelligence (ITSI) to add business context on top of the unified log and metrics data.

The 86% reduction in total cost of ownership for observability came out of that first phase. More than 400 on-premises servers were decommissioned along with their associated storage. Licenses across multiple platforms were consolidated. The contractor headcount assigned to monitoring those servers was reduced.

“We decommissioned a lot of servers that were on prem, which was more than 400 servers, and associated storage elements were all turned off, and that was a major savings for us,” Nataraj said.

What incident response looks like now

The operational change is most visible in how the team handles incidents. A video shown during the session walked through the current workflow.

When an alert fires in ITSI, one click launches a custom-built AI agent that queries logs, metrics, traces, topology data, and recent change requests in real time. The agent returns a plain-language summary of what broke, why it broke and how to fix it. Role-specific actions are included for DevOps, application and SRE teams. If escalation is needed, the agent drafts a handoff for the on-call engineer. The whole investigation happens in a single screen before an incident ticket is even created.

The result is a measurable shift in outcome. When issues do occur, the three-bridge war room is gone. Teams can see where the problem is and the response is contained to the people who need to act on it. “We have actually brought down our incident count by 25%, and in the last six quarters there have been no major network outages,” Nataraj said.

Lessons learned

Nataraj laid out a practical set of takeaways from the project for IT operations teams running at similar scale.

Unify data before applying AI. Without a unified data platform, AI has nothing reliable to work with. Getting all data into a single architecture has to come first.
Share visibility across teams. Correlating data is only useful if the teams who need it can access it. The team built cross-domain data sharing from the start.
Bring change and release data into observability. Tying change management records to observability data lets the team trace failures back to the specific change that caused them and maintain a rollback plan.
Treat cost savings as the budget for innovation. The TCO reduction funded the team’s shift away from routine monitoring. Engineers who were previously managing capacity and watching servers are now building AI agents on top of Splunk’s MCP tools, participating in alpha and beta testing for new Splunk tooling, and feeding product feedback directly to Cisco’s Splunk teams.

“They were purely ticket closers before,” Nataraj said. “They’re innovators, they wear product managers’ hats, and they are really happy about the work that they do.”

Job satisfaction, retention, and contractor reduction are all outcomes Nataraj cited as measurable ROI from the project. “Keeping the team motivated and having them feel happy is a real ROI for every single organization,” she said.

The real cost of agentic AI

Fri, 05 Jun 2026 11:18:51 +0200

Agentic AI has moved from conference hype to a budget line item. This is where the conversation gets more interesting and more uncomfortable. Unlike traditional AI systems that respond to a single prompt, classify a document, recommend an action, or generate a summary, agentic AI systems are designed to pursue goals. They plan, call tools, inspect results, retry failed steps, consult memory, hand off tasks to other agents, and sometimes critique their own work before producing an answer or taking an action.

That extra autonomy is the value proposition. It also introduces the cost problem.

A single chatbot interaction may consume a few thousand tokens. A useful agentic workflow can consume hundreds of thousands or millions of tokens per day because it does more than answer a question. It decomposes the problem, retrieves context, reasons through options, invokes APIs, checks the output, and often runs multiple passes before reaching a result. Therefore, the economics need to be understood at the level of “agent instances,” not just model calls.

For the estimates below, I am using a blended token cost of $3 dollars per million tokens. This is not intended to reflect a single vendor’s list price. It is a blended planning figure that assumes a mix of input and output tokens, reasoning steps, retrieval-augmented generation, summarization, tool calls, memory updates, and occasional use of larger context windows. Some enterprises will pay less through volume discounts or by routing work to smaller models. Others will pay more by using premium models, long-context prompts, web browsing, large document ingestion, and repeated reasoning loops.

The basic formula is straightforward. If an agent consumes 2 million tokens per day, it consumes 730 million tokens per year. At $3 per million tokens, that single agent costs about $2,190 per year in token burn. That number sounds surprisingly low until you multiply it by the number of agents, workflows, and users, plus the surrounding infrastructure required to run these systems safely.

What an agent really costs

In the model used here, the annual token-only cost per agent ranges from about $1,095 to $3,833, depending on the use case.

A lightweight HR recruiting or onboarding agent that consumes one million tokens per day costs about $1,095 per year.
A more demanding software engineering agent that consumes 3.5 million tokens per day costs about $3,833 per year.
Customer support agents are roughly $2,190 per year.
Legal contract agents cost about $2,409 per year.
Security triage agents run about $2,738 per year.
Research agents are around $3,066 per year.

These figures are useful but incomplete. They include only LLM token consumption and exclude orchestration platforms, vector databases, observability, model evaluation, security controls, workflow monitoring, human review, enterprise application integration, data pipelines, audit logging, prompt management, and the engineers needed to build and maintain the systems. In real deployments, I would expect the all-in operating cost to be two to five times the raw token cost. For regulated or mission-critical environments, the multiplier can be even higher.

This is where many agentic AI business cases become less clear. The model call may be inexpensive, but the system around the model is not. An agent that can update a customer relationship management system, approve a refund, generate a purchase order, or recommend a security containment action needs guardrails, permissions, logging, rollback mechanisms, and human escalation paths. These are not optional features. They are the difference between a demo and an enterprise system.

Use cases that make economic sense

Customer support is one of the more obvious use cases. A typical support automation deployment may use eight agents: an intake classifier, a knowledge retrieval agent, a response drafting agent, an escalation agent, a quality review agent, a CRM update agent, a sentiment detection agent, and an analytics agent. At two million tokens per agent per day, each agent costs about $2,190 per year in token burn, bringing the annual total to roughly $17,520. If that system deflects even a modest number of tickets or improves agent productivity, the economics can be attractive.

Sales development is another practical example. A five-agent system for account research, lead enrichment, email personalization, CRM updates, and follow-up scheduling may consume 1.2 million tokens per agent per day. That results in an annual cost of about $1,314 per agent, or $6,570 for the full agent team. This can be compelling if it improves pipeline quality, but it can also be wasteful if agents generate low-quality outreach at scale. The cost of brand damage is not measured in tokens.

Software engineering is more expensive but potentially more valuable. A 12-agent system covering requirements analysis, architecture, code generation, testing, review, security checks, documentation, CI debugging, refactoring, release notes, dependency analysis, and hot-fix support may consume 3.5 million tokens per agent per day. That works out to about $3,833 per agent annually or roughly $45,990 for the full system. Compared with engineering salaries, the token cost is small. The real question is whether the system reliably improves throughput without increasing defects, security vulnerabilities, or maintenance complexity.

Security operations also fit the agentic model because the work is repetitive, time-sensitive, and context-intensive. A 10-agent security triage system could include agents for alert triage, log analysis, threat intelligence, endpoint investigation, network investigation, incident summarization, ticketing, compliance evidence, escalation, and post-mortem. At 2.5 million tokens per agent per day, the annual token cost is about $2,738 per agent or $27,375 for the system. This is easy to justify if it reduces alert fatigue and accelerates response, but risky if the agents hallucinate causality or bury critical signals in confident summaries.

Finance, legal, healthcare administration, market research, HR, and supply chain are also viable:

A six-agent finance close system may cost about $9,855 per year in token burn.
A four-agent legal contract review system may cost about $9,636.
A seven-agent healthcare administrative workflow may cost about $13,797.
Competitive intelligence using six agents may cost $18,396.
HR recruiting and onboarding using five agents may cost $5,475.
Supply chain planning and exception management using eight agents may cost $21,024.

Across all 10 example use cases I’ve mentioned in this section, the model assumes 71 agents and a total annual token burn of about $175,638.

The comparison with traditional AI

The economics of agentic AI should always be compared with simpler approaches. Traditional AI, workflow automation, rule engines, robotic process automation, and non-agentic LLM calls are often cheaper, easier to govern, and more predictable. Agentic AI is usually overkill for tasks like classification, extraction, summarization, routing, or drafting within a narrow context. A deterministic workflow with a single model call can do the job at a fraction of the cost and risk.

Agentic systems make sense when the process requires judgment across multiple steps, dynamic planning, tool use, exception handling, and adaptation to incomplete information. They are valuable when the path to the answer cannot be fully scripted in advance. They are less valuable when enterprises use them as a trendy substitute for basic automation.

The best architecture is usually hybrid. Use traditional automation where the process is stable. Use non-agentic AI where the task is bounded. Use agentic AI only where autonomy creates measurable leverage. That means fewer agents, tighter scopes, explicit budgets, model routing, token monitoring, and human checkpoints for high-impact decisions.

The financial mistake many organizations will make is to treat agents as digital employees with near-zero marginal cost. They are not. They are probabilistic software components that consume tokens, trigger tools, create operational dependencies, and require supervision. The token bill may be manageable. The governance bill may not be.

Agentic AI can absolutely be worth the money. In many cases, the annual token burn for a useful agent team is less than the loaded cost of a single employee. But that is not the same as saying it is cheap. Companies must measure agent cost per completed business outcome, not cost per prompt or cost per model call. In the end, the question is not how much an agent costs. Ask yourself the right question: Does the autonomy an agent provides outweigh the complexity it introduces?

Embedding pipelines are the new ETL

Fri, 05 Jun 2026 11:18:50 +0200

I’ve seen a lot of promising AI prototypes fall apart after launch. And it’s rarely because the model was bad. More often, the problem starts much earlier; teams treat the data layer like something they can figure out later.

They’ll spend weeks fine-tuning prompts, testing models and debating evaluation scores, then throw together the retrieval pipeline over a weekend and move on. At first, everything looks great in demos. But a few months later, the system gives outdated answers; the embeddings no longer match the source documents, and nobody fully understands what changed.

What started as an impressive prototype slowly becomes difficult to trust in production. The teams that avoid this tend to realize one thing early: Embedding pipelines are fundamentally a data engineering problem, not an entirely new AI discipline. It’s still ETL (Extract, Load, Transform) at its core, but with embeddings and vector stores as the destination instead of a warehouse.

Once you start looking at it that way, a lot of things become clearer. Problems like versioning, data freshness, lineage and retries stop feeling “AI-specific.” They’re data infrastructure problems we’ve already spent years learning how to solve.

Why do we need embedding pipelines?

Large language models are extraordinary reasoners trapped inside a time capsule. When training ends, the model’s knowledge is sealed. It does not know what your team decided in last quarter’s strategy review. It has never read the support ticket that came in this morning. It cannot find the clause buried on page 47 of your master service agreement. It’s brilliant, but blind to anything specific to your organization.

Layer on top of that a hard context window limit, a ceiling on how much text the model can process in a single interaction, and you have a clear problem: you cannot just hand it everything you own.

The answer the industry converged on is retrieval-augmented generation, or RAG. Instead of stuffing everything into the context window, you build a retrieval layer that fetches only the most relevant pieces of information at the moment a question is asked and passes just those to the model. That retrieval layer is powered by a vector database, and the process that populates it, which is taking raw documents and transforming them into searchable semantic representations, is what I mean when I say embedding pipeline.

Every team building an internal AI assistant, a smarter enterprise search tool, an automated customer support agent or a document Q&A system needs one. The question is not whether to build it. The question is whether you build it like a prototype or like infrastructure.

How an embedding pipeline works

An embedding pipeline has three stages: ingestion, chunking and indexing. Here is what each one means and how I relate them to a typical ETL process.

Ingestion is extraction

Getting your raw content, PDFs, wiki pages, Word documents, database records, transcripts, out of wherever it lives and into the pipeline. This is ETL’s extract stage, almost verbatim.

I see teams cut corners here more than anywhere else, and it’s often where production systems first start to fail. A document gets updated, but the pipeline doesn’t pick it up. A file gets deleted, but its chunks remain in the index, still returning outdated answers months later. And because there’s no obvious error, no one reports it.

The fix is Change Data Capture (CDC). This maintains a manifest of every document you have ingested, a content hash and a timestamp. On each run, we compare sources against that manifest, re-ingest what changed, delete what is gone and treat your document the way you would treat any source table you are syncing incrementally.

Chunking is transformation

Once your documents are in the pipeline, you cannot embed them whole. A 30-page technical report is too long to represent meaningfully as a single vector, and even if it were not, returning the entire report in response to a narrow question would bury the model in irrelevant context.

Chunking is the process of breaking each document into smaller pieces that are focused enough to embed accurately and retrieve precisely. This is ETL’s transform stage, and it deserves the same level of design discipline.

The most common mistake I see is treating chunk size as a default configuration option rather than a product decision. It is not. The right chunk size depends entirely on the nature of your content and the nature of your queries. Dense technical documentation needs finer granularity than a collection of FAQs. A legal contract with clause-level logic needs different treatment than a set of onboarding emails. What works for one document will actively degrade retrieval quality on another.

My strong preference is to treat your chunking configuration as a versioned pipeline parameter, not hardcoded logic. When you change it, and trust me, you will. You need to re-chunk in a controlled, observable way, compare retrieval quality before and after, and roll back if it degrades. That is just good transform-layer hygiene. It is no different from versioning a data cleaning rule or a field mapping.

Indexing is the load

The final stage is where chunked text gets converted into vectors and stored in a vector database where it can be searched by semantic similarity rather than keyword match.

In the conversion step, embedding is handled by a model specifically trained to turn text into dense numerical representations that encode meaning. Two chunks expressing the same idea in different words will produce vectors that cluster close together in that mathematical space. Two chunks discussing entirely different topics will sit far apart. When a user asks a question, the system embeds that question the same way, finds the chunks whose vectors are nearest, and returns them as context for the model to reason over.

That is a genuinely new capability. But the discipline around indexing is not. One data engineering principle I keep coming back to is versioning.

In embedding pipelines, every chunk in your index should be tagged with the embedding model name and version used to generate it, this is non-negotiable. Embedding models evolve, and vectors produced by different versions are not comparable in a reliable way. You cannot safely search across them as if they are interchangeable.

This exact problem shows up when teams upgrade embedding models mid-pipeline without a proper migration plan. You end up mixing vectors from different generations in the same index, and retrieval starts to degrade in ways that are hard to detect. The system just quietly begins returning subtly wrong answers.

I treat an embedding model upgrade the same way I treat a schema migration: Plan it explicitly, execute it in full and validate retrieval quality on a representative query set. The stakes are the same as any breaking change to your data model.

Pipeline observability is not optional

Once an embedding pipeline is running in production, the question shifts from “did it run” to “did it run correctly.” That distinction matters more here than in most pipelines, because failures are rarely loud because the index looks fine, queries return without errors and the system quietly surfaces wrong answers until someone notices the AI has stopped being useful.

The same observability discipline that makes any data pipeline trustworthy applies directly here. Once you treat embedding pipelines as production systems, you stop thinking in isolated steps and start thinking in signals. For example, chunk counts per document become a simple but powerful health check, a sudden drop is usually not a model issue, but a sign of broken ingestion or upstream parsing failures.

You also need a “golden set” of queries with known-good outputs. This runs after every pipeline change, much like data quality checks after a transformation. This is how you catch regressions that don’t show up as explicit failures.

On top of that, you can track lineage: Which embedding model version produced which chunks, and when each document was last ingested. That makes it possible to trace retrieval issues back to specific changes instead of guessing.

And finally, freshness becomes a first-class signal. If documents start going stale beyond an acceptable threshold, that should surface in monitoring long before users experience degraded results.

The metric that ties it all together is retrieval quality over time. Treat it like any other pipeline SLA, measured, tracked and owned.

Summary

Embedding pipelines definitely come with a lot of new language, new tools and a genuinely different capability in the semantic layer. But the funny thing is, the principles that actually make them reliable in production are not new at all.

We have versioning, freshness, quality checks and monitoring. These are problems data engineering has already spent years solving.

The real work is taking that same discipline and applying it to a pipeline that just happens to output vectors instead of rows in a table. Once you start seeing it that way, a lot of the chaos around AI systems becomes much easier to reason about.

That’s the difference between building a cool AI demo and building something people can actually depend on. One is a prototype, whereas the other is infrastructure.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

CompTIA debuts AutoOps+ certification

Thu, 04 Jun 2026 15:55:44 +0200

CompTIA has launched AutoOps+, a new certification and training program that the organization says will validate the automation, scripting, infrastructure management, and DevOps skills required in today’s IT operations environments.

The vendor-neutral certification is targeted at IT professionals responsible for automating workflows, managing infrastructure, and supporting software delivery pipelines across cloud, hybrid, and on-premises environments. It focuses on expertise in coding, scripting, orchestrating end-to-end workflows, and other skills that combine traditional IT operations with DevOps practices.

According to CompTIA, the certification was developed in response to growing demand for automation expertise as organizations adopt infrastructure-as-code, continuous integration and continuous delivery (CI/CD), and other automated operational processes.

“The ability to lead digital transformation, simplify complex environments, and operationalize automation is essential for today’s technology workforce,” said Katie Hoenicke, chief product officer, CompTIA, in a statement. “We’re addressing this skills need with vendor-neutral training and certifications to help IT professionals boost efficiency, strengthen security, and deliver impact across cloud and hybrid ecosystems.”

The certification covers automation fundamentals, scripting, version control, infrastructure-as-code, CI/CD pipelines, observability, and DevOps practices. Candidates are expected to demonstrate the ability to automate operational tasks, manage system configurations, and support automated deployment workflows, according to CompTIA.

CompTIA detailed the skills candidates will gain from the AutoOps+ program:

Use scripting and automation to streamline IT workflows and manage enterprise systems efficiently
Automate configuration, provisioning, and maintenance using infrastructure-as-code and modern toolchains
Build and manage CI pipelines to automate testing, ensure quality, and improve collaboration between teams
Implement secure, compliant delivery pipelines that enable rapid, reliable deployment and operational efficiency

AutoOps+ is intended for systems administrators, cloud administrators, infrastructure engineers, DevOps professionals, site reliability engineers, and other IT operations specialists looking to validate automation-focused skills. The organization recommends that candidates have foundational IT knowledge and two to three years in a core IT operations role, as well as hands-on experience with systems administration, cloud technologies, networking, and scripting, before pursuing the certification. The exam is available now.

Cisco Cloud Control: Eine Managementebene für Netzwerk, Security und Compute - Heise

Thu, 04 Jun 2026 15:09:03 +0200

Cisco bündelt Netzwerk, Security, Compute und Observability in einer KI-gestützten Managementebene: Cloud Control soll IT-Infrastrukturen agentisch ...

AI 에이전트가 IT 인프라 지킨다…시스코, 머신 속도 보안·에이전틱옵스 비전 구체화

Thu, 04 Jun 2026 14:07:29 +0200

이날 시스코는 네트워크, 보안, 데이터, 운영을 통합하는 플랫폼인 ‘시스코 클라우드 컨트롤(Cisco Cloud Control)’을 중심으로 AI 시대 인프라 청사진을 제시했다. 아울러 AI 확산에 따른 새로운 보안 위협에 대응하고 기업의 회복탄력성을 높이기 위한 기술과 서비스도 주요 화두로 다뤘다.

시스코의 인프라·보안 그룹 수석부사장 겸 총괄 매니저 톰 길리스(Tom Gillis)는 “과거에는 인프라를 강화하고 취약점을 보완한 뒤 가능한 한 오랫동안 변경하지 않는 방식으로 운영해 왔다”며 “많은 기업이 장비를 수년간 운영하고, 일부는 10년 이상 사용하는 경우도 있다”고 말했다. 이어 “최신 모델은 이제 취약점을 발견하는 데 그치지 않고 이를 악용하는 것까지 가능해졌다”며 “취약점이 발견·악용되는 시점과 실제 패치가 배포되는 시점 사이에는 여전히 큰 격차가 존재한다”고 지적했다.

패치 주기의 공백을 메우는 ‘라이브 프로텍트’

시스코가 이 간극에 대한 해법으로 제시한 것이 ‘라이브 프로텍트(Live Protect)’다. 시스템을 오프라인으로 내리거나 재부팅, 변경 관리 절차를 거치지 않고도 가동 중인 장비에 정밀한 보완 통제를 적용하는 기능이다. 예컨대 “이 프로세스가 이 파일에 접근하지 못하게 하라”는 수준까지 구체적으로 통제를 건다.

길리스는 “성능에 측정 가능한 영향이 없을 만큼 정밀하고, 광범위한 테스트를 거쳐 오탐률도 매우 낮다”며 “라이브 프로텍트는 가상 패치가 아니라, 정기 점검과 패치 주기 사이에 생기는 구멍을 막는 임시 방어선”이라고 설명했다. 이 기능은 이번에 캠퍼스 스위치로 확대 적용된다.

시스코는 AI가 취약점 탐지와 공격을 자동화하면서 기존의 ‘발견-패치-유지’ 중심 운영 방식이 한계에 이르렀다고 진단했다. 보안 운영은 정기 패치 주기에 의존하는 사후 대응 모델에서 벗어나, 취약점 노출 시점부터 지속적으로 위험을 통제하는 연속적 운영 모델로 전환되고 있다는 설명이다.

통합 플랫폼이 곧 ‘명령 센터’

시스코는 이러한 보안 모델을 운영 차원에서 묶는 통합 플랫폼으로 ‘시스코 클라우드 컨트롤(Cisco Cloud Control)’을 내세웠다. 네트워킹·보안·AI 인프라·관측가능성·협업을 단일 진입점으로 통합한 AI 네이티브 플랫폼으로, 시스코는 이를 “포스트 미토스 세계의 명령 센터(command center)”로 표현했다.

시스코의 보안사업부 AI 소프트웨어&플랫폼 수석부사장 DJ 삼파스(DJ Sampath)는 “프런티어 모델은 IT 운영뿐 아니라 보안의 판도 자체를 바꾸고 있다”며 “기업은 클라우드 컨트롤을 통해 인프라를 근본적으로 재구상하게 될 것”이라고 말했다. 이 플랫폼은 사용자·기기·애플리케이션·네트워크·위협을 가로지르는 교차 도메인 텔레메트리와, 40여 년간 축적한 시스코 데이터로 학습한 목적 특화 모델을 결합한다. 보안용 파운데이션 모델과 시계열 분석 모델을 포함해, 작업 성격에 맞는 모델을 선택적으로 적용하는 구조다.

운영자 관점에서 의미 있는 대목은 ‘액션(Actions)’ 모드다. 에이전트가 문제를 감지·분석하고 해결 방안을 제안하더라도 최종 판단은 인간이 내리는 구조다. 시스코는 이를 “에이전트가 무거운 업무를 수행하고 인간은 중요한 사안을 통제하는 협업형 운영 모델”로 설명했다.

에이전트 보안의 세 기둥: 보호·식별·통제

에이전트가 ‘디지털 동료’로 업무에 투입되면서, 보안의 대상도 사람에서 비인간 주체로 확장됐다. 길리스는 에이전트 보안을 세 축으로 정리했다. ▲외부 세계의 조작으로부터 에이전트를 보호하고 ▲악의적으로 행동할 수 있는 에이전트로부터 실제 자산을 보호하며 ▲이 모든 것을 기계 속도로 수행한다는 것이다.

첫째, 에이전트 보호는 ‘AI 디펜스(AI Defense)’가 맡는다. 에이전트를 탐지하고 레드팀 방식으로 검증하며, 공급망까지 들여다보고 맞춤형 가드레일을 적용한다. 시스코는 이 역량을 전 세계 2억 대 이상 배포된 시스코 시큐어 클라이언트에 내장해, 에이전트를 수정하지 않고도 보안을 입힐 수 있게 했다.

둘째는 식별이다. 시스코는 기기에서 실행되는 프로세스를 분석해 사람이 직접 수행하는 작업인지, 사람을 대신한 AI 에이전트가 수행하는 작업인지를 구분하고, 에이전트에는 별도의 ‘비인간 정체성(Non-Human Identity·NHI)’을 부여한다. 시스코는 최근 AI 에이전트 식별과 비인간 정체성 관리 역량을 강화하기 위해 아스트릭스 시큐리티(Astrix Security)를 인수하기도 했다.

셋째, 통제다. 길리스는 접근 통제를 단순 ‘온·오프’ 방식에서 ‘액션 통제(action control)’로 전환한다고 강조했다. 특정 작업 수행에 필요한 시점에만(Just in Time), 필요한 범위만큼만(Just Enough Access), 필요한 기간 동안만(Just Long Enough) 접근 권한을 부여하는 방식이다. 그는 “이 모델에서는 네트워크를 통과하는 모든 접근이 사실상 특권 접근이 되며, 별도 전용 솔루션 없이 시스코 플랫폼(시큐어 액세스, 하이브리드 메시 방화벽)만으로 정밀 통제를 제공한다”고 말했다.

이와 별개로 탐지와 대응 자동화 전략의 중심에는 스플렁크가 있다. 스플렁크 SVP 겸 GM 카말 하티(Kamal Hathi)는 “머신 속도로 탐지하고 대응하는” 운영 모델을 제시하며 에이전틱 SOC와 에이전틱 SRE를 공개했다. 두 서비스는 AI 에이전트를 활용해 위협 탐지와 분석, 대응 과정을 자동화하고, 기존에 며칠 또는 수시간이 걸리던 보안 운영을 수분·수초 단위로 단축하는 것을 목표로 한다. 하티는 이를 AI를 활용해 보안 위협에 대응하는, 이른바 “AI로 AI에 맞서는(fight fire with fire)” 접근법이라고 설명했다.

스플렁크는 데이터를 이동하지 않고 여러 환경에 직접 질의할 수 있는 페더레이티드 서치(Federated Search), AI가 원시 데이터를 자동으로 정형화하는 머신 데이터 레이크(Machine Data Lake), 범용 LLM보다 빠르고 비용 효율적인 도메인 특화 AI 모델을 제공한다. 또한 최근 인수한 갈릴레오(Galileo Technologies)의 기술을 기반으로 에이전트 관측가능성(Agent Observability)을 지원하고, AI 비용과 토큰 사용량을 추적하는 ‘토크노믹스(Tokenomics)’ 기능도 함께 선보였다.

시스코는 고객 지원 조직 역시 회복탄력성 강화에 초점을 맞추고 있다고 강조했다. 시스코의 고객경험 엔지니어링 SVP 바스카르 자야크리슈난(Bhaskar Jayakrishnan)는 “미토스가 모든 것을 영구히 바꿔놓았고, 공격이 무기화됐다”며 노출 평가, 인프라 현대화, 구조적 회복탄력성 확보의 3단계로 구성된 ‘회복탄력적 인프라 서비스’를 소개했다. 여기에는 양자 준비도 평가, 익명화 데이터 기반의 동종업계 벤치마킹이 포함된다. 시스코 IQ(Cisco IQ)는 4월 24일 SaaS형으로 정식 출시됐으며, 온프레미스 버전은 2026년 7월 제공된다.

데이터센터와 네트워크 전반에서는 포스트 양자 암호(PQC) 적용이 라우터·스위치에 이어 SD-WAN으로 확대된다. ‘지금 수집해 나중에 해독’하는 공격에 대비한 조치다. 넥서스(Nexus) 9000에는 포스트 양자 암호 라이브러리가 내장되며, 아이소발런트(Isovalent) 기술을 넥서스 대시보드에 통합해 쿠버네티스 워크로드 내부의 개별 컨테이너 단위로 정책을 적용할 수 있게 됐다.

“AI 보안도 결국 기본기”

AI 보안 경쟁이 새로운 국면에 접어든 가운데, 시스코는 CIO들이 주목해야 할 경쟁력의 본질에 대해서도 의견을 내놨다. 시스코 SVP 겸 CISO 제이슨 리시(Jason Lish)는 “AI 군비 경쟁이 사실상 진입 장벽을 낮춰, 공격자들이 기계 속도로 취약점을 무기화할 수 있게 됐다”고 짚었다.

리시는 CIO에게 진정한 경쟁 우위는 프런티어 모델 자체가 아니라 수많은 정보 속에서 실제 위협을 식별하고 대응할 수 있도록 돕는 운영 체계에 있다고 강조했다. 그는 시스코가 파운드리(Foundry) 보안 사양을 오픈소스로 공개하고 방어를 “협업 팀 스포츠”로 다루며 이러한 전환을 가속하고 있다고 설명했다.

동시에 “제로 트러스트, 다중 인증(MFA), 철저한 레거시 패치 같은 ‘후회 없는(no-regrets) 기본기’가 여전히 중요하다”며, AI 기반 보안 인텔리전스와 이러한 기본기를 결합해 사후 대응 중심의 보안 운영에서 벗어나 지속적으로 위험을 점검하고 관리하는 체계로 전환하고 있다고 덧붙였다.

이 외에도 이날 행사에서는 시스코 엔터프라이즈 커넥티비티 및 협업 부문 수석부사장 겸 총괄 매니저 아누라그 딩그라(Anurag Dhingra)가 AI 애플리케이션 확산에 대응하기 위한 멀티클라우드 패브릭과 디지털 트윈 기반 네트워크 운영 자동화 전략을 소개했다. 시스코 APJC 지역 총괄 사장 벤 도슨(Ben Dawson)는 “향후 AI 관련 논의는 CIO 중심에서 CFO 중심으로 이동할 것”이라며 기업들이 AI 역량 구축을 넘어 실질적인 투자수익률(ROI)을 증명해야 하는 단계에 진입하고 있다고 평가했다.
jihyun.lee@foundryco.com

Cisco Cloud Control: Eine Managementebene für Netzwerk, Security und Compute

Thu, 04 Jun 2026 07:47:33 +0200

Cisco bündelt Netzwerk, Security, Compute und Observability in einer KI-gestützten Managementebene: Cloud Control soll IT-Infrastrukturen agentisch steuern.

10 MCP-Server für DevOps

Thu, 04 Jun 2026 06:06:56 +0200

DevOps ist mit Aufwand und Kosten verbunden. Mit MCP aufzurüsten, macht deshalb Sinn.

PeopleImages | shutterstock.com

KI-Agenten für Programmierer haben sich zu einem beeindruckenden Hilfsmittel entwickelt. Allerdings sind diese Agenten nur begrenzt einsetzbar, wenn sie nicht auch mit modernen DevOps-Tools kompatibel sind. An dieser Stelle kommt das Model Context Protocol (MCP) ins Spiel. Der von Anthropic Ende 2024 veröffentlichte Standard verbindet KI-Systeme mit externen Tools und Daten.

Mit Blick auf DevOps stehen KI-Agenten damit neue Fähigkeiten offen – etwa:

Versionskontrollen mit Git,
Continuous Integration & Deployment (CI/CD),
Infrastructure as Code (IaC),
Observability, oder
Zugriff auf Dokumentationen.

Im Folgenden werfen wir einen Blick auf zehn offizielle MCP-Server, die populären DevOps-Tools und -Plattformen entsprungen sind und jeweils unterschiedliche Funktionalitäten abdecken. Diese lassen sich innerhalb MCP-kompatibler KI-Entwicklungs-Tools relativ einfach konfigurieren und mit Berechtigungen ausstatten. Offizielle MCP-Server zu nutzen, hat zudem den Vorteil, dass deren Lebensdauer sehr wahrscheinlich länger ist – und sie durchgängig gewartet und aktualisiert werden.

1. GitHub MCP-Server

Kaum ein Entwickler nutzt GitHub nicht in irgendeiner Form. Deshalb entwickelt sich der offizielle MCP-Server der Plattform zu einer immer beliebteren Methode, um KI-Agenten zu befähigen, mit Code-Repositories zu interagieren – etwa, indem sie Issues erstellen und kommentieren oder Pull Requests zusammenführen.

Außerdem enthält dieser MCP-Server auch Endpunkte für das CI/CD-Management über GitHub Actions. So könnte etwa ein natürlichsprachlicher Befehl wie “Aktuelle Aktion abbrechen” das cancel_workflow_run-Tool innerhalb von GitHub Actions aufrufen.

Der offizielle MCP-Server von GitHub bietet vergleichsweise umfangreiche Funktionen, die die APIs der Plattform widerspiegeln. Damit dabei die Sicherheit nicht zu kurz kommt und KI-Agenten keine Mutationen durchführen, lassen sich jederzeit --read-only-Flags konfigurieren.

2. Notion MCP-Server

Notion ist eher ein KI-Collaboration- als ein DevOps-Tool und hat sich mittlerweile fachbereichsübergreifend etabliert, wenn es darum geht, teamintern Transparenz zu schaffen. Der offizielle MCP-Server von Notion ist jedoch auch aus DevOps-Perspektive nützlich. Damit lassen sich Agenten beispielsweise anweisen, interne Stilrichtlinien oder Betriebshandbücher zu konsultieren, die in Notion gespeichert sind.

Der Remote-MCP-Server von Notion ist über eine IDE abrufbar – kann aber mit dem offiziellen Docker-Image auch lokal aufgesetzt und ausgeführt werden. Dieser MCP-Server ist als risikoarm zu betrachten, da er über konfigurierbare Scopes und Tokens verfügt, um Notion-Seiten und -Blöcke zu managen.

3. Atlassian Remote MCP-Server

Atlassians Remote MCP-Server verbindet IDEs oder Agentic-AI-Plattformen mit den Cloud-Produkten des Unternehmens. Beispielsweise dem Projektmanagement-Tool Jira. Anzumerken ist dabei, dass sich dieser MCP-Server derzeit in der Beta-Phase befindet und Atlassian-Cloud-Kunden vorbehalten ist.

Damit ist es denkbar, einen Agenten anzuweisen, ein Jira-Issue zum Benutzertesting für eine BezahlApp auf der Grundlage eines aktuellen Bug Report zu aktualisieren – und dabei auf die relevanten Protokolle zu verweisen. Die Aktualisierung von Jira läuft anschließend über den MCP-Server.

Der MCP-Server von Atlassian unterstützt diverse Clients und gewährleistet mit Oauth-2.1-Support auch sicheren Zugriff.

4. Argo CD MCP-Server

Auch die Entwickler des populären Open-Source-Tools Argo CD stellen einen MCP-Server zur Verfügung. Dieser fasst Calls an die Argo-CD-API zusammen und enthält Tools, mit denen die Benutzer über natürliche Sprache mit Argo CD interagieren können:

Mit dem Application-Management-Tool können KI-Agenten Anwendungsinformationen abrufen, Anwendungen erstellen und löschen sowie weitere Prozesse ausführen.
Über das Resource-Management-Tool rufen KI-Agenten Ressourceninformationen, Protokolle und Ereignisse für bestimmte Anwendungen ab und führen spezifische Aktionen für bestimmte Ressourcen aus.

Mit Hilfe dieses MCP-Servers lassen sich viele Tasks “natürlichsprachlich” ausführen, die auch über das User Interface oder das CLI-Tool von Argo CD verfügbar sind. Eine Staging-App zu synchronisieren, geht so beispielsweise flotter von der Hand. Damit das auch funktioniert, muss der MCP-Server von Argo CD aber auch ordentlich integriert werden – und benötigt Zugriff auf eine laufende Argo-CD-Instanz inklusive korrekt konfigurierter Anmeldedaten.

5. Grafana MCP-Server

Das Datenvisualisierungs- und Monitoring-Tool Grafana gehört für viele DevOps- und SRE-Teams zum Standardrepertoire. Der offizielle MCP-Server für Grafana befähigt KI-Agenten dazu, Observability-Daten bereitzustellen, um Entwicklungs- oder Betriebsprozesse zu optimieren.

Über diesen MCP-Server können Agenten außerdem vollständige oder teilweise Details aus Dashboards abfragen, die Metriken zur Systemleistung und Health-Daten aus verschiedenen Quellen kombinieren. Darüber hinaus lassen sich über den Grafana MCP-Server auch Informationen zu Datenquellen abrufen, weitere Monitoring-Systeme oder Details zu spezifischen Vorfällen abfragen.

Das Toolset ist dabei konfigurierbar, die Berechtigungen der Agenten können durch den Benutzer definiert werden. Darüber hinaus hat Grafana auch die Antwortstruktur seines MCP-Servers optimiert. Das soll die Nutzung des Kontextfensters minimieren und die Kosten für Token senken. Beispielsweise kann ein MCP-Client das get_dashboard_property-Tool aufrufen, um einen bestimmten Part eines Dashboards anhand seiner UID abzurufen.

6. Terraform MCP-Server

HashiCorp Terraform ist – Alternativen zum Trotz – weiterhin die erste Adresse, wenn es um Infrastructure as Code (IaC) geht. Entsprechend ist der offizielle MCP-Server eine interessante Option, um Terraform-Konfigurationen über KI-Agenten zu generieren und zu managen. Der MCP-Server lässt sich dabei sowohl in die Registry APIs als auch in die Enterprise/HCP-Services von Terraform integrieren. Das ermöglicht KI-Agenten etwa:

Modul- und Anbieter-Metadaten abzufragen,
den Status von Workspaces zu überprüfen, und
Tasks (mit menschlicher Genehmigung) auszulösen.

Ein Befehl wie “Generiere Terraform-Code für einen neuen Run” könnte so die create_run-Operation aufrufen, woraufhin der KI-Agent die Konfiguration validiert und plant, bevor er sie anwendet.

Der Terraform MCP-Server wird mit der Readme-Datei AGENTS.md ausgeliefert. Diese erleichtert es Agenten, Tools zu interpretieren. Aktuell (Stand Dezember 2025) ist der Terraform MCP-Server ausschließlich für die lokale Nutzung verfügbar. Er ist ausdrücklich nicht für Remote- oder gehostete Deployments vorgesehen.

7. GitLab MCP-Server

Auch die GitLab-Plattform stellt – ihren Premium- und Ultimate-Kunden – einen MCP-Server bereit. Dieser befindet sich aktuell in der Beta-Phase und befähigt KI-Agenten dazu, Projetinformationen zu sammeln und Operationen über GitLab-APIs sicher auszuführen.

Der GitLab MCP-Server erlaubt einige Statusänderungen, etwa Issues zu erstellen oder Merge Requests. Die anderen Funktionen dienen hauptsächlich der Datenabfrage – also etwa Informationen zu Issues, Merge-Anfragen, Commits, Diffs und Pipelines abzufragen. Enthalten ist zudem ein allgemeines Suchwerkzeug.

Die Dokumentation des GitLab MCP-Servers ist sehr ausführlich und enthält zahlreiche Beispiele für natürlichsprachliche Ausdrücke, die verarbeiten werden können. Der Server unterstützt zudem die dynamische Client-Registrierung über OAuth 2.0.

8. Snyk MCP-Server

Snyk bietet eine Security-Plattform für Entwickler an – und einen MCP-Server. Dieser kann dazu genutzt werden, mit Hilfe von KI-Agenten (IaC-)Code, Open-Source-Abhängigkeiten, Container sowie SBOMs oder auch AIBOMs auf Schwachstellen zu scannen und diese zu beheben. Den Snyk MCP-Server zu integrieren, ist also dazu geeignet, Sicherheitsscans automatisch im Rahmen eines CI/CD-Workflows mit KI-Agenten durchzuführen. Diese Scans lassen sich sogar über andere MCP-Server hinweg koordinieren, beispielsweise indem Repository-Details über den GitHub MCP-Server abgerufen werden, bevor ein Snyk-Scan gestartet wird.

Ein Prompt wie “Scanne das Authentication-Microservice-Repo auf Sicherheitslücken” könnte einen Agenten anweisen, das Repository mit GitHub MCP zu lokalisieren und dann Snyk-Tools wie snyk_sca_scan oder snyk_code_scan nutzen, um bekannte Schwachstellen, geleakte Anmeldedaten und andere Risiken zu identifizieren.

Dieser MCP-Server wird lokal ausgeführt und verwendet die Snyk-CLI, um Befehle wie diese über authentifizierte API-Calls auszuführen. Das Unternehmen bietet keine gehostete Remote-Version seines MCP-Servers an.

9. AWS MCP-Server

Die Cloud-Hyperscaler haben besonders eifrig daran gearbeitet, schnell MCP-Server auf die Beine zu stellen, die sich in ihre Ökosysteme integrieren lassen. Amazon Web Services (AWS) hat beispielsweise Dutzende spezialisierter MCP-Server eingeführt, die KI-Agenten ermöglichen, mit sämtlichen Arten von AWS-Services zu interagieren. Einige davon werden als vollständig gemanagte Dienste angeboten, andere können hingegen nur lokal ausgeführt werden.

So können KI-Agenten über den Lambda Tool MCP-Server beispielsweise Lambda-Funktionen auflisten und aufrufen.
Der AWS S3 Tables MCP-Server lässt sich hingegen von einem Agenten nutzen, um S3-Buckets abzufragen oder neue Tabellen aus CSV-Dateien zu erstellen.
Der AWS Knowledge MCP-Server verbindet Agenten mit den neuesten AWS-Dokumentationen, API-Referenzen und Architekturleitfäden.

Eine Query an letztgenannten Knowledge-Server könnte etwa die Anweisung beinhalten, eine API-Referenz für das von AWS gemanagte Prometheus-Tool aufzurufen. Das würde die richtigen aktuellen Informationen liefern – optimiert für die Nutzung durch KI-Agenten.

10. Pulumi MCP-Server

Pulumi ist eine weitere beliebte IaC-Option – und hat ebenfalls einen offiziellen MCP-Server eingeführt. Dieser ermöglicht es KI-Agenten,

Pulumi-Registries abzufragen,
auf Cloud-Ressourcen und -Infrastruktur zuzugreifen, und
Pulumi-Befehle auszuführen.

Wie Entwickler diesen MCP-Server nutzen können, um einen Azure Kubernetes Service (AKS)-Cluster bereitzustellen, erklärt Pulumi beispielhaft in einer ausführlichen Schritt-für-Schritt-Anleitung. (fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.

AI observability platform Coralogix raises $200 million in a Series F round.

Wed, 03 Jun 2026 22:08:25 +0200

Dragos has acquired Nashville-based embedded device security company Phosphorus.

Coralogix Raises $200M at $1.6B Valuation to Scale AI Observability Platform

Wed, 03 Jun 2026 20:05:36 +0200

Coralogix offers a full-stack observability platform that unifies logs, metrics, traces, security, and AI observability. The post Coralogix Raises $200M at $1.6B Valuation to Scale AI Observability Platform appeared first on SecurityWeek. This article has been indexed from SecurityWeek Read…

The post Coralogix Raises $200M at $1.6B Valuation to Scale AI Observability Platform appeared first on IT Security News.

Coralogix Raises $200M at $1.6B Valuation to Scale AI Observability Platform

Wed, 03 Jun 2026 19:38:08 +0200

Coralogix offers a full-stack observability platform that unifies logs, metrics, traces, security, and AI observability.

The post Coralogix Raises $200M at $1.6B Valuation to Scale AI Observability Platform appeared first on SecurityWeek.

Building the foundation for the agentic enterprise

Wed, 03 Jun 2026 18:50:14 +0200

Enterprise IT teams, the invisible force driving our modern work world, are struggling to manage environments that have become staggeringly complex, spanning thousands of devices, multiple security domains, and a patchwork of disconnected management tools.

This fragmentation runs across networking, security, infrastructure, observability, and collaboration systems and creates significant operational risk. When teams must act and defend infrastructure at machine speed and scale, yet manually stitch together context across siloed workflows, visibility suffers, response times slow, and the burden on already-stretched staff compounds, making it increasingly difficult to scale both human expertise and agentic automation.

These challenges are becoming more urgent as enterprises increasingly adopt AI and seek to gain the value of agentic operations. For human operators and AI agents to work together effectively, they need more than access to the same environment; they need a shared operational foundation that gives access to the same context, the same signals, and the same system of action across domains.

That foundation ensures that AI is no longer constrained by the fragmentation that limits scale and innovation, said Munish Mehta, senior director of networking at AMD, in this interview during Cisco Live:

https://youtube.com/watch?v=qc1YPrERGuU%3Fsi%3DLV4LsUrxuZ1Q8G0a

Cisco Cloud Control is that foundation. It’s a unified platform built to give both human operators and AI agents shared operational context across every IT domain. It consolidates identity, governance, and administration so that networking, security, and observability share a common management experience rather than separate consoles.

Cisco Cloud Control is built for an open ecosystem, extending to more than 50 platforms and tools such as AWS, Google Cloud, Linear, Microsoft and ServiceNow. New capabilities like App Builder, leveraging built-in agentic coding assistant OpenAI Codex, further expands what teams can create and manage over time. Designed to evolve with an organization’s operational maturity, Cisco Cloud Control becomes more valuable as teams adopt more of its capabilities, said DJ Sampath, senior vice president and general manager of Cisco AI Platform and Software, in this interview during Cisco Live:

https://youtube.com/watch?v=n9ZAOGONfyk%3Fsi%3Du2T35La8Em3mkshl

Central to Cisco Cloud Control is an operating model called AgenticOps, which is built on the premise that AI agents and human operators are most effective when they work together in a shared workspace rather than in parallel silos. That collaboration environment is called AI Canvas, and it surfaces cross-domain telemetry, connects teams and brings agents into a shared view so that investigations, remediations, and approvals happen in one place rather than across a chain of handoffs.

For example, new agentic loop automation can identify root causes and propose actions, while human operators retain oversight and approval authority before anything is executed. Anurag Dhingra, senior vice president and general manager of enterprise connectivity and collaboration at Cisco, offered further context during this interview at Cisco Live:

https://youtube.com/watch?v=ohcrPV7yl0c%3Fsi%3DEkbvU5iQ_oVm9N-k

As AI moves from experimentation to operational reality, the organizations that will capture the most value are those that invest in the foundational layer that makes coordinated, trustworthy automation possible. Cisco Cloud Control’s unified platform approach, AgenticOps framework, and open integration architecture give enterprise IT teams and AI agents the shared context they need to operate as genuine partners rather than disconnected actors working in adjacent silos.

And for CIOs navigating the growing complexity of their IT environments with finite resources, this unified foundation lays the groundwork for enabling current and future AI innovation. Unified operations reduces the overhead associated with managing fragmented systems, and ensures that security and networking teams are working from the same operational picture.

Taken together, Cisco Cloud Control allows organizations to move from isolated automation and AI efforts to repeatable, scalable AI-powered operations.

Cisco is continually innovating and collaborating with its partners to help customers seamlessly transform to agentic operations. Delve into all the action that was announced at Cisco Live 2026.

What is Cisco Cloud Control and why should customers care?

Wed, 03 Jun 2026 18:23:50 +0200

As is typical of Cisco, the company made several product announcements at its flagship event, Cisco Live. The most significant product announcement is Cisco Cloud Control, which recognizes that customers do not run separate Cisco products; they run one sprawling, interconnected environment that must be monitored, secured, and increasingly operated with AI at machine speed.

That is what Cisco Cloud Control is supposed to be: a single management plane with one login, one view, and one operational model spanning networking, security, compute, observability, and collaboration. Cisco is positioning it as the foundation for its broader AgenticOps vision, in which human operators and AI agents work from the same data and in the same workspace, with humans still in control. For Cisco customers, this matters because the company is finally trying to turn its massive product portfolio into an actual platform.

More than another console

On paper, Cloud Control sounds simple enough. It provides a unified environment, a shared data layer, and a common system of action, while also giving customers access to capabilities such as unified inventory, topology, policy, identity, and event correlation across the Cisco estate. During the keynote demos, Cisco showed single sign-on, all assets in one place, a single topology view, and direct access to products such as Meraki, Splunk, Security Cloud Control, Intersight, Control Hub, and Cisco IQ.

That alone would be useful. Cisco’s biggest enterprise customers have spent years dealing with product silos that made perfect sense inside the org chart but far less sense in an actual IT environment. Networking had its console, security had its console, observability had its tools, collaboration had its dashboard, and the poor operator in the middle had to stitch it all together manually. Cloud Control is Cisco’s admission that this model no longer scales.

Why the single dashboard matters now

The timing here is not accidental. In the AI era, operations are no longer just about watching dashboards and opening tickets. Infrastructure teams are being asked to diagnose and fix problems faster, while the threat landscape is compressing the time between vulnerability disclosure and exploitation from weeks to minutes. Cisco’s argument is that if customers are going to operate and defend infrastructure at machine speed, they cannot keep jumping from console to console and trying to correlate everything by hand.

That is why the single dashboard is more strategic than it sounds. Cisco is not just aggregating links to existing products. It is trying to create a common operational context so people and agents can work from the same inventory, topology, telemetry, and policies. If the old model was “visibility first, action later,” the new model is supposed to be visibility, reasoning, and action, all within the same environment.

The break from Cisco’s past

At Cisco Live 2024, Chief Product Officer Jeetu Patel declared that within two years, Cisco would be unrecognizable in a positive way. Cisco Live 2026 marks that two-year milestone, and Patel (pictured at top) has indeed made Cisco unrecognizable, with Cloud Control the most recent example. Historically, Cisco has rolled out one “single pane of glass” after another. In the past, I’ve said that if there were a Magic Quadrant for single panes of glass, Cisco would be the runaway leader because it had so many.

This is what makes Cloud Control so interesting. Cisco explicitly says this is not a “single pane of glass,” and the company is right to make that distinction. In its own words, glass is passive; Cloud Control is designed to enable active execution, with policy and identity built directly into the control path. That is a sharp departure from the old enterprise management philosophy, in which the dashboard’s job was mostly to display information and leave the operator to figure out the rest.

Cisco is also changing the abstraction layer.

For years, the company sold management in product-sized chunks. Now it is talking about a secure harness for agentic infrastructure, complete with trusted access, normalized APIs, Model Context Protocol connectivity, telemetry, enforcement points, and governance to ensure actions are bounded, auditable, and reversible. That is a much more ambitious framing, and frankly, it has to be. In a world of AI agents, the real value is not in prettier user interfaces. It is in creating a trusted operating environment where agents can do useful work without breaking things. At Cisco Live, all product demonstrations have been delivered from within Cisco Cloud Control, showcasing the product’s breadth and depth.

AI Canvas is where the story gets real

One of the strongest parts of the announcement is AI Canvas, which Cisco is moving into controlled availability as part of Cloud Control, rather than keeping it locked inside individual products. Cisco describes AI Canvas as a multiplayer workspace where human operators and AI agents investigate and resolve issues together, using the same live evidence, with context persisting across handoffs, shift changes, and escalations.

That is important because enterprise IT does not need more AI window dressing. It needs help with the messy middle of operations, where a single performance issue can become a network, policy, application, and security question all at once. Cisco says AI Canvas can take a natural-language prompt, build a multi-agent investigation plan, gather evidence across domains, and return a sourced answer, with the operator still approving the path forward. If that works as advertised, Cisco is not just simplifying operations. It’s changing how infrastructure work gets done.

The marketplace makes this bigger than Cisco

The other notable component of the announcement is the Marketplace, which is central to whether Cloud Control becomes a platform or just a better Cisco front end.

The Marketplace is a catalog of apps, agents, and integrations built by Cisco, customers, and partners, and it already includes integrations from more than 50 ecosystem partners. The partner list includes AWS, Google Cloud, Linear, Microsoft, Okta, PagerDuty, ServiceNow, Slack, Snowflake, Tenable, and Wiz, among others.

That matters because no enterprise is all-Cisco. The company acknowledges that customers operate multivendor environments and need to customize workflows beyond what Cisco ships out of the box. With Agent Builder, App Builder, and Marketplace, Cisco is also enabling customers to connect third-party tools, build their own agents, and create custom apps on top of Cisco’s control plane rather than waiting for a roadmap. That is a big deal because it moves Cisco from a product vendor to a platform operator.

After the keynote, I caught up with Evan Mintzer, director of production infrastructure at Customers Bank. While he appreciates having a single dashboard for their Cisco products, it’s the ecosystem partnerships that truly caught his attention. “When Cisco displayed the slide of supported vendors, I recognized several we already use and a few others we’re considering,” Mintzer shared. “That ecosystem will make integrating them into our environment much easier.”

Why every Cisco customer should care

During his keynote, Patel made a comment that I think succinctly captures the value of Cisco Cloud Control: “Cloud Control is at its core simplicity without losing the sophistication of Cisco, and so what we’ve tried to do is say all the products that you know from Cisco and love will be managed from it.”

Historically, customers had to choose between the ease of use of a dashboard and the CLI for more complex tasks. Now they can do both through a natural language interface.

It’s also about capturing more value from the Cisco investment many companies have already made. The more Cisco infrastructure a customer runs, the more value the platform should deliver by connecting inventory, topology, policy, security, and AI-driven workflows in one place. Cisco has always had broad reach across the stack, but breadth alone is not enough. Without a unifying control layer, breadth becomes portfolio sprawl. Cloud Control is Cisco’s best attempt yet to turn that sprawl into an advantage.

There is also a defensive reason to care. Cisco is positioning Cloud Control as the command center for a post-Mythos world, tying it to Live Protect, unified security policy, asset visibility, vulnerability posture, and broader agentic security controls. In other words, this is not just an operations console. Cisco wants it to become the place where customers defend infrastructure in real time.

My advice to Cisco customers

Customers should approach Cloud Control with both enthusiasm and discipline. If you are a Cisco-heavy shop, this could become the operational layer that finally ties your environment together. But do not accept the vision based on branding alone.

First, test how Cloud Control reduces cross-domain complexity. A single pane of links is not the same as a single operating model.

Second, rigorously evaluate the AI governance model. Cisco wisely emphasizes human approval, auditability and bounded actions, but customers should validate this in real workflows before letting agents take any consequential actions.

Third, take the Marketplace seriously from day one. The ability to manage the Cisco domain from a single dashboard has obvious appeal, but extending it across a large percentage of the overall environment can significantly simplify operations and troubleshooting.

Cisco has had the pieces for years: leadership positions in networking, security, observability, collaboration, and infrastructure, plus one of the deepest installed bases in enterprise IT. What it has lacked is the control plane to bind them all together. Cloud Control shows that the company understands the future will not be won by having the most dashboards. It will be won by having the operating layer where humans and AI agents can work.

And that is why this launch matters. Cisco Cloud Control is not just another product announcement. It is Cisco’s effort to become the system through which its customers run the agentic enterprise. It’s positioned itself as “Mission Critical Infrastructure for the AI era” — but with Cloud Control, it’s that plus the operational environment.

Cisco bringt Agentic-Ops-Plattform und umfassende Sicherheitsmaßnahmen

Wed, 03 Jun 2026 15:38:48 +0200

Die aktuellen Ankündigungen von Cisco zielen auf die neuen Anforderungen an Netzwerke, Sicherheit und Observability im KI-Zeitalter ab.

CryptoFX /Shutterstock

Cisco hat die Netzwerkinfrastruktur aufgebaut, auf der das Internet und die Cloud basieren. Auf der Cisco Live machte das Unternehmen deutlich, dass es diese Position auch weiterhin einnehmen will, während Unternehmen von KI-Chatbots zu autonomen Agenten übergehen. Während Chatbots Fragen beantworten, ergreifen Agenten Maßnahmen: Sie führen Aufgaben aus, rufen Tools auf, nehmen Änderungen vor und arbeiten kontinuierlich mit maschineller Geschwindigkeit. Dadurch ändern sich die Anforderungen an Netzwerke, Sicherheit und Observability – und genau darauf zielen die aktuellen Ankündigungen ab.

Zu den wichtigsten Ankündigungen der Veranstaltung in Las Vegas gehören:

Cisco Cloud Control: Eine einheitliche Verwaltungsplattform, die Meraki, Nexus, Intersight, Splunk und Collaboration umfasst.
Agentic Actions für Netzwerke: Geschlossene, autonome Fehlerbehebung für Campus- und Zweigstellennetzwerke.
Cisco Multicloud Fabric: Ein Cloud-basierter Dienst, der Zweigstellen, Rechenzentren und Cloud-Workloads über AWS, Azure, Google Cloud und Neoclouds hinweg verbindet.
Erweiterung von Live Protect: Schutz vor Schwachstellen während des Betriebs ohne Neustarts oder Wartungsfenster, erweitert auf Smart Switches in Campus- und Zweigstellen.
Agentic IAM: Temporäre, aufgabenbezogene Zugriffskontrollen für KI-Agenten, bereitgestellt über Cisco Secure Access.
Cisco Data Fabric powered by Splunk: Federated Search, ein schlüsselfertiger Machine Data Lake, ein KI-Toolkit und ein Agentic SOC mit sechs speziell entwickelten Sicherheitsagenten.
Neue Hardware: C9550 Core-Switch, 8100/8200/8300/8600 Secure Router, Outdoor-Wi-Fi 7, der IR1000-Industrierouter und das Cisco Board Pro G3.

„Es geht nicht mehr darum, dass Menschen sich durch eine Vielzahl von Dashboards klicken und versuchen, den Überblick über die Aktivitäten der Agenten zu behalten“, erklärte DJ Sampath, Senior Vice President und General Manager für KI-Software und -Plattformen, während einer Pressekonferenz. „Ein echtes kollaboratives Betriebsmodell beginnt dann, wenn die Agenten die Hauptarbeit übernehmen und die Menschen stets die Kontrolle über das Wesentliche behalten.“

Cisco Cloud Control

Cloud Control soll die Vielzahl separater Verwaltungsoberflächen für Netzwerk, Sicherheit, Compute, Observability und Collaboration in einer einzigen Umgebung zusammenführen. Dort arbeiten Menschen und KI-Agenten mit denselben Daten und derselben Benutzeroberfläche.

„Mit Cloud Control erhalten Sie ein Maß an Sicherheit, das Ihnen ermöglicht, Ihre Infrastruktur wirklich effektiv zu verwalten“, betonte Sampath. „Es bietet Ihnen Kontrollmöglichkeiten zur Observability, es bietet Ihnen ein sicheres KI-Gateway sowie Leitplanken für diese Agenten. All das ist im Lieferumfang von Cloud Control enthalten.“

Zu den Kernfunktionen von Cloud Control gehören:

Domänenübergreifende Telemetrie: Cloud Control aggregiert Daten aus den Bereichen Netzwerk, Sicherheit, Observability, KI-Infrastruktur und Zusammenarbeit in einer gemeinsamen Datenstruktur, auf die sowohl Betreiber als auch Agenten gleichzeitig zugreifen.
Speziell entwickelte Modelle: Eingehende Aufgaben werden an das am besten geeignete KI-Modell weitergeleitet, anstatt durch ein einziges großes Sprachmodell geleitet zu werden. Zu den Cisco-eigenen Modellen gehören das Deep Network Model, das mit vier Jahrzehnten an operativen Netzwerkdaten trainiert wurde, ein Foundation Security Model sowie ein Zeitreihenmodell für die Telemetrieanalyse. Für allgemeine Aufgaben, die logisches Schlussfolgern erfordern, stehen Frontier-Modelle zur Verfügung.
Vertrauenswürdige Agenten: Agenten basieren auf Live-Telemetriedaten, unterliegen unternehmensweiten Sicherheitsrichtlinien und sind bereit, Aufgaben mit maschineller Geschwindigkeit auszuführen.
Cloud Control Studio: Das für Ende 2026 geplante Studio bietet einen „Agent Builder“ zur Erstellung benutzerdefinierter Agenten mit Anbindung an mehr als 50 Plattformen von Drittanbietern über native Konnektoren oder das Model Context Protocol sowie einen „App Builder“, der OpenAI’s Codex in die Plattform integriert. Alle in Cloud Control erstellten Komponenten übernehmen automatisch dessen Observability- und Sicherheitskontrollen.
Cloud Control Marketplace: Das Angebot startet mit Integrationen unter anderem in den Bereichen IT-Service-Management (ServiceNow, Atlassian, BMC), Identitätsmanagement (Okta, Ping Identity, Microsoft Entra ID, Jamf), Netzwerküberwachung (LiveAction, Panduit), Infrastrukturwissen (NetBox Labs, Device42, Vertiv) und KI-native Plattformen (Anthropic, OpenAI, NVIDIA, Collibra).

Agentic Networking und Multicloud Fabric

Mit Agentic Actions führt Cisco einen autonomen Ablauf für den Netzwerkbetrieb ein. Die Funktion folgt einem fünfstufigen Zyklus: Erkennen, Diagnostizieren, Beheben, Validieren, Bereitstellen.

Dabei wandelt „Experience Metrics“ rohe Telemetriedaten in Echtzeit in Messwerte zur Benutzererfahrung um. „Deep Reasoning“ wendet die speziell von Cisco entwickelten Modelle auf eine mehrstufige Ursachenanalyse an. „Digital Twin“ wiederum betreibt eine emulierte Nachbildung des Produktionsnetzwerks unter Verwendung realer Software-Images anstelle eines mathematischen Modells, sodass Agenten Änderungen vor der Bereitstellung testen können. Die Beta von Agentic Action startet im Juni 2026 über Meraki, der Digital Twin geht im Juli 2026 in die Alpha-Phase.

Die zweite Ankündigung in diesem Bereich betrifft Cisco Multicloud Fabric. Sie verbindet Niederlassungen, Rechenzentren und Cloud-Workloads über AWS, Azure, Google Cloud und Neocloud-Anbieter hinweg mittels eines von Cisco verwalteten Overlays, ohne dass kundenseitige Hardware erforderlich ist. Die Fabric umfasst Zero-Trust-Routing, Cloud-Firewall-Service-Chaining sowie integrierte Observability von ThousandEyes und Splunk.

„Cisco entwickelt und betreibt den Cloud-basierten Dienst, sodass der Kunde nichts installieren oder bereitstellen muss“, führt Anurag Dhingra, Senior Vice President und General Manager für Enterprise Connectivity and Collaboration bei Cisco, aus. „Er ist sofort verfügbar, lässt sich nahtlos mit einem Klick in Cisco Cloud Control konfigurieren und verbindet all diese Verbindungen innerhalb von Minuten.“

Sicherheit: Live Protect und Agentic IAM

Frontier-KI-Modelle haben das Zeitfenster zwischen der Entdeckung einer Schwachstelle und deren Ausnutzung von Monaten auf Minuten verkürzt. Cisco reagiert darauf mit Laufzeit-Abwehrmaßnahmen, die auf der Infrastrukturebene wirken, sowie einem neuen Zugriffskontrollmodell, das speziell für KI-Agenten entwickelt wurde.

Live Protect: Bietet Laufzeitschutz direkt auf Netzwerkgeräten, ohne Neustarts oder Wartungsfenster. Schutzmaßnahmen können gezielt auf einzelne Prozess- oder Dateiinteraktionen angewendet werden.

Agentic IAM: Anstelle einer rollenbasierten Zugriffsregelung erhalten Agenten nur kurzfristige Berechtigungen, die auf eine konkrete Aufgabe beschränkt sind und über Cisco Secure Access mittels mehrstufiger LLM-, API- und MCP-Richtliniendurchsetzung bereitgestellt werden.

„Wir bewegen uns von Zugriffskontrolle hin zu Aktionskontrolle“, erläutert Tom Gillis, Senior Vice President und General Manager für Infrastruktur und Sicherheit. „Der Zugriff erfolgt genau zum richtigen Zeitpunkt, mit genau den erforderlichen Rechten und nur so lange wie nötig.“

Schutz nicht-menschlicher Identitäten: Um die Sicherheit agentischer KI zu verbessern, integriert Cisco Technologie, die das Unternehmen durch die Übernahme von Astrix Security erworben hat. Die Technologie nutzt die Überprüfung auf Prozessebene, um Agentenaktivitäten von menschlichen Aktivitäten zu unterscheiden. Zudem wird DefenseClaw, Ciscos Open-Source-Framework für Laufzeit-Sicherheit bei KI-Agenten, in Cisco Secure Client integriert. Da Secure Client auf mehr als 200 Millionen Unternehmensgeräten im Einsatz ist, bedeutet dies, dass Agentenschutz auf Endpunkt-Ebene unternehmensweit angewendet werden kann, ohne dass Entwickler jeden Agenten einzeln instrumentieren müssen.

Cisco Data Fabric und das Agentic SOC

Cisco Data Fabric, das im September 2025 eingeführt wurde, erhielt auf der Cisco Live ein umfangreiches Update. Basierend auf Splunk konsolidiert die Lösung Telemetriedaten aus Netzwerk-, Anwendungs-, Sicherheits- und Drittanbieterquellen in einer gemeinsamen Ebene, auf die sowohl menschliche Analysten als auch automatisierte Agenten zurückgreifen können, und dient als Datengrundlage für Cloud Control und das Agentic SOC.

Zu den Verbesserungen gehört eine optimierte Funktion für die föderierte Suche. „Anstatt Daten in Splunk zu verschieben, bringen wir Splunk zu den Daten und können diese Daten über verschiedene Umgebungen hinweg abfragen, ohne sie zu kopieren oder zu verschieben“, erklärt Kamal Hathi, Senior Vice President und General Manager bei Splunk.

Außerdem gibt es einen AI Toolkit Agent Builder, der domänenspezifische Modelle für den Umgang mit Maschinendaten bereitstellt, sowie das, was Cisco als „Turnkey Machine Data Lake“ bezeichnet – eine Lösung, die das Schemamanagement für Rohdaten mithilfe von KI automatisiert.

Aufbauend auf der Data Fabric setzt Cisco zudem ein Agentic SOC mit speziell entwickelten Agenten ein, die den gesamten Lebenszyklus von Erkennung und Reaktion abdecken.

„Wir reduzieren den Zeit- und Aufwandsaufwand für Sicherheitsoperationen von Tage oder Stunden auf Minuten und Sekunden“, so Hathi.

Cisco geht noch einen Schritt weiter und integriert eine KI-gestützte SRE-Funktion (Site Reliability Engineering), die eine autonome Ursachenanalyse für Leistungsprobleme bei Anwendungen und der Infrastruktur durchführt. Die durch die Übernahme von Galileo Anfang dieses Jahres gewonnene Technologie erweitert die Observability auf Trace-Ebene bei der Agentenausführung und deckt dabei Tool-Aufrufe, LLM-Interaktionen und die Erkennung von Prompt-Injektionen ab.

„Splunk bietet uns dann vollständige Transparenz über alle Aspekte der Nutzung von KI- und agentenbasierten Lösungen und ermöglicht all dies wirklich in großem Maßstab auf vertrauenswürdige Weise“, erklärt Hathi. (mb)

The Agentic Reckoning: Enterprise AI organizations have a runtime problem, not a model problem — and most are building the wrong solution

Tue, 02 Jun 2026 22:17:10 +0200

In Q1 2026, VentureBeat's Pulse Research surfaced the “Governance Mirage”: the gap between the governance org charts enterprises had drawn and the control layers they had actually built. Forty-three percent said a central team owned AI governance; 23% couldn't agree on who owned it at all; and 31% named vendor opacity as the single biggest obstacle.

This new wave of research asks the next question: Once you've admitted the governance problem, what breaks first when you try to fix it? The answer from our respondents is unambiguous. The failure point is not the model. It's the runtime.

Enterprises are discovering that AI agents built on stateless infrastructure — Python scripts, LangChain chains, ad hoc orchestration — cannot survive the operational realities of production. Container restarts erase context. Token costs breach business cases. Hallucinations in Step 3 compound into catastrophic failures by Step 12. And the majority of engineering teams are spending more time managing this "plumbing" than building the intelligence that was supposed to justify the investment.

What emerges from this survey is a picture of an industry at a critical fork. The organizations that survive the Agentic Reckoning will be those that treat runtime durability as a first-class engineering concern — not an afterthought to be patched with retries and prompting. The ones that don't will find themselves back where RPA left enterprises a decade ago: a graveyard of clever pilots that couldn't survive Day Two.

Methodology

VentureBeat conducted this survey in May 2026 as part of its ongoing Pulse Research series on agentic AI adoption in the enterprise. Respondents were filtered to organizations with 100 or more employees. The final qualified sample consists of 132 verified, highly qualified technology leaders at the forefront of enterprise AI agent deployment.

They span:

Directors of AI/Analytics (8%)	Directors of Engineering/IT (16%)
VP of Data/AI/Analytics (5%)	VP of Engineering/IT (5%)
CIOs/CTOs/CISOs (15%)	Product and Program Managers (13%)
Consultants (9%)	Software and ML Engineers (9%)
Enterprise Architects (8%)	Other (12%)

Industries represented include Technology/Software (42%), Financial Services (20%), Professional Services (8%), Healthcare/Life Sciences (7%), Retail/Consumer (6%), Education (4%), and others.

Given our strict filtering criteria, this cohort provides a robust and authoritative look at emerging agentic infrastructure trends.

Respondent demographics by company size:

Large enterprise (10,000+ employees): 35% of the sample
Mid-to-large enterprise (500–9,999 employees): 48% of the sample
Growth enterprise (100–499 employees): 17% of the sample

These quantitative findings capture a critical moment in infrastructure evolution and are best synthesized alongside VentureBeat’s Q1 2026 governance reports and our deep-dive practitioner conversations conducted throughout the quarter.

Finding 1: The runtime is the problem

The "spine vs. brain" debate is over

The foundational question of enterprise AI in 2026 is whether agent failures trace back to the model's reasoning capability — the Brain — or to the runtime infrastructure's inability to manage state, survive failures, and coordinate execution — the Spine. We asked our respondents directly.

Integration/governance challenges were the biggest problem. But Spine issues were close behind.

However, 17% still say the Brain is the primary failure mode. That’s not a rounding error — it’s a signal. The organizations in this cohort are not disputing the infrastructure problem; they are telling us that the models themselves are not yet reliable enough for the edge cases their workflows are generating. The model-versus-runtime debate is genuinely three-sided. Read together, these three answers are not fully in conflict. The Spine and Gap camps are struggling with infrastructure and governance respectively. The Brain cohort is struggling with something upstream: reasoning reliability at scale.

This is a significant finding. The frontier model wars — GPT-5 vs. Claude 4.7 vs. Grok — are consuming enormous mindshare in the enterprise technology press. Our respondents are telling us that war is, for now, beside the point. The models are smart enough, but the infrastructure around them is not.

"The models are smart enough, but our stateless infrastructure is too fragile to manage long-running, multi-step agentic processes." — Director of Engineering / IT, Financial Services, 10,000–49,999 employees

Finding 2: The DIY tax is eating teams alive

Engineering capacity is being consumed by plumbing, not intelligence

If the Spine is a primary failure mode, what does that cost in practice? We asked respondents what percentage of their team's weekly engineering capacity is consumed by building and maintaining custom "plumbing" — manual retries, state-persistence, checkpointing — rather than actual agentic logic.

The results reveal a market in two distinct camps, with a dangerous middle.

The arithmetic is stark. Seventy-seven percent of respondents are spending meaningful engineering time on infrastructure overhead. Just 23% — those whose frameworks are handling reliability — have escaped the tax. The distribution is notably flat: the Crisis and Efficiency poles are the same sizes as the middle categories (Trap and Maintenance Tax). This is the signature of a market that has partially addressed the worst failures but has not yet escaped the structural overhead.

The Efficiency Zone respondents are not necessarily in a more sophisticated position. In many cases, they may be on managed platforms that abstract away the durability problem — or they may simply not yet have hit the scale at which stateless architectures begin to fail. The Complexity Trap is often where the Efficiency Zone ends.

There’s a direct business consequence for organizations in the Crisis zone. Every engineering hour spent writing retry logic or debugging a "ghost failure" — a silent API timeout that leaves an agent hanging without a traceback — is an hour not spent on the differentiated logic that was supposed to justify the AI investment in the first place.

Finding 3: State amnesia is the production killer

The No. 1 technical obstacle has shifted: Cost and hallucination now lead state failures

When AI agents fail to reach production or scale, what is the primary technical obstacle? We named five candidates, ranging from model hallucination to cost overruns to latency failures.

Hallucination Propagation at 24% compounds silently — reasoning errors in early steps become catastrophic by Step 10. Ghost Failures at 20% are invisible by definition, which means their real prevalence is likely higher than this number suggests.

Finding 4: The observability tax falls heaviest on Microsoft

Platform visibility costs are not equally distributed

Our Q1 2026 research identified vendor opacity as the single biggest obstacle to AI governance — ahead of talent gaps, tooling, and budget. That finding pointed to this question: Which vendor ecosystem, in practice, imposes the highest cost to achieve basic production visibility?

We asked respondents which platform requires the most custom telemetry, manual instrumentation, and "logging glue" to achieve visibility into agentic failures.

Microsoft's position at the top of this ranking is not noise. It is a structural characteristic of the Microsoft agentic ecosystem — the same Azure/Copilot stack that dominates enterprise AI adoption requires the most instrumentation overhead to see inside.

It also reinforces the warning that Brian Gracely, Senior Director at Red Hat, made at VentureBeat’s Boston event in March: that building your control system entirely inside one cloud provider's toolset means "renting a cage." The organizations paying the highest observability tax are precisely those most locked into provider-native tooling.

The implication for teams currently evaluating orchestration architecture is direct: observability cost is a real budget item that should appear in any build-vs-buy analysis. A platform that appears cheaper at the API layer may impose substantially higher engineering costs at the telemetry layer.

Finding 5: The hype-reality gap belongs to OpenAI and Microsoft

Agentic coding marketing is significantly ahead of production reliability.

We asked respondents a pointed question: Which major platform's Agentic Coding marketing is the most disconnected from the actual technical reliability and fault-tolerance of their product? Thirty-two percent said they didn't know — a figure that has held roughly constant across all three waves, suggesting persistent uncertainty is structural, not a sample artifact. Cursor also registered 6% in this wave. Among those with enough production experience to have a view.

Microsoft leads at 45%; OpenAI is second at 22%. The gap is too large to attribute solely to deployment footprint. It suggests that GitHub Copilot Workspaces and AutoGen are generating a specific category of disappointment — probably around the reliability of multi-agent orchestration in production — that accumulates with use. A platform that fewer enterprises are running in production will accumulate fewer credible disappointed practitioners.

The more significant observation is what this gap means for decision-makers evaluating new agentic tooling. The marketing around all major platforms describes agentic autonomy and reliability at a level that production deployments are not yet delivering. The organizations in our survey who have moved beyond pilots are encountering the difference firsthand.

Finding 6: The security mesh is being built from first principles

Enterprises are not waiting for vendors to solve agent security

How are enterprises protecting proprietary research data from AI leakage and prompt-driven exfiltration? The security architecture question is one of the most consequential in agentic AI, because agents — unlike static models — can actively call APIs, traverse file systems, and execute code. The blast radius of a security failure is qualitatively different.

Policy-as-Code is a leading security mechanism, but not by much.

The NHI and Policy-as-Code approaches are meaningfully different in their security philosophy. NHI is identity-centric: The question it answers is "who is this agent and what is it allowed to touch?" Policy-as-Code is rule-centric: The question it answers is "regardless of what the model decides to do, what hard stops exist at the infrastructure level?"

Rough parity across all four mechanisms is the headline finding. This is what market convergence looks like in early motion: No dominant pattern has emerged. Notably, though, Egress-Locked Sandboxing is a relatively new trend in agentic AI deployments, yet it’s already at 22%. As more agents gain terminal-level access to enterprise systems, the cost-benefit of sandboxing is improving. This is notable given the maturity of the identity management and policy-as-code disciplines in traditional IT security. The AI security layer is, for now, being built largely from scratch.

The Egress-Locked Sandboxing number deserves attention despite its smaller share. Sandboxing untrusted code execution is the most technically intensive of the four approaches, but it is also the most direct defense against prompt injection attacks that try to execute malicious code through agent tooling. As agentic systems gain more terminal-level access — a trend our survey confirms is accelerating — this approach may prove more important than its current adoption rate suggests.

"How do we audit agentic tools that have terminal-level access to our proprietary repos?"
— Composite concern expressed by multiple respondents

Finding 7: The complexity cliff is real, and most are climbing it

The migration away from stateless architectures is underway — but fragmented

The central thesis of the Agentic Reckoning is that stateless Python/LangChain architectures cannot survive the complexity cliff — the point at which multi-step, long-running agent workflows begin failing at rates that make production deployment untenable. We asked respondents directly: are you migrating toward durable execution frameworks to solve for state loss?

The answers reveal a market in transition, with meaningful disagreement about the right destination.

The 20% committed to stateless architectures — attempting to solve a structural durability problem through better prompting — are the cohort most likely to encounter State Amnesia and Ghost Failures as their workloads scale. It’s essentially the same trap that RPA teams fell into a decade ago, when brittle process automations were patched with increasingly elaborate rule sets rather than re-architected on more resilient foundations.

The Stateless Commitment cohort deserves a reinterpretation. These teams are not all naive: some are building on managed platforms that genuinely abstract state management. But a portion is patching structural fragility with prompting improvements, and the Ghost Failures data in Finding 3 suggests this approach may be encountering its ceiling.

The combined 59% who are either in Active Migration or in Governance-First Evaluation represent the market's leading edge — organizations that have recognized the architectural problem and are investing to solve it structurally.

Finding 8: The “polyglot orchestration” lead is narrow — the field is fragmented

Architectural conviction is spread across multiple bets

What is the longterm architectural philosophy winning enterprises' strategic investment? We offered four options representing the major bets available in the current market.

The Polyglot Bet's lead suggests that enterprises are seeing advantages of using a flexible approach: Using model-driven architectures where non-deterministic reasoning works well, but using deterministic structures and pipelines where accuracy and mission-critical execution is at stake.

This has direct competitive implications for the frontier labs and cloud providers. The cohort saying the use a Cloud-Native Managed Stack is significant. This likely reflects the enterprise reality that Azure OpenAI Service and AWS Bedrock deployments come with built-in organizational gravity — procurement relationships, security approvals, and existing data pipelines. The Independent Durable Runtime bet at 16% signals that a cohort of teams have rejected both cloud lock-in and frontier lab dependency in favor of full architectural sovereignty.

The Polyglot result also helps explain why the observability and governance problems described in this survey are so persistent. When your architecture deliberately spans multiple orchestration layers and multiple providers, no single vendor's telemetry gives you the full picture. The "Dynatrace for AI" — the unified observability platform called for by Mass General Brigham's CTO Nallan Sriraman at the VentureBeat Boston event — becomes not just desirable but structurally necessary.

"Enterprises trust no single provider enough to give them full control, yet they lack the engineering capacity to build entirely from scratch."
— Survey respondent

Finding 9: User acceptance rate is the emerging production standard

The market is settling on a human-trust metric as its primary A-SLA

What metrics are enterprises actually using to determine whether an AI agent is ready for production? We asked respondents to identify their primary Agentic SLA (A-SLA) indicator — the number that, above all others, tells them whether an agent can ship.

User Acceptance Rate as the dominant production metric is significant because it is a human-trust measure, not a technical performance measure. It does not ask whether the agent ran fast or maintained state. It asks whether a human who reviewed its output chose to accept it. This is, in effect, a field-level Turing test applied at the action level.

The persistence of UAR as the leading metric reflects the reality of where most enterprise agentic deployments still sit: in a human-in-the-loop posture, where agent actions require human review before execution. That is a rational response to the Hallucination Propagation and Ghost Failures described earlier in this survey. Organizations that have not yet solved runtime durability are, sensibly, keeping humans in the loop — and at 132 respondents, there is no evidence this is changing.

Context Fidelity's position at 30% is the most significant finding. It tracks directly with the Active Migration data in Finding 7: As more teams move into durable execution frameworks, the 48-hour+ memory problem becomes their primary production concern. Teams that have solved State Amnesia are now focused on whether their agent can remember what it was doing yesterday. Latency Jitter's collapse from 25% to 11% tells the complementary story: raw speed is no longer the primary anxiety. Correctness and durability have taken its place.

The bottom line: The reckoning is runtime, not reasoning

The data tells a consistent story: There’s a runtime deficit for agents. Enterprises are spending more time on infrastructure plumbing than on agent intelligence, and State Amnesia is still claiming production deployments. But fault lines are visible. The ROI Ceiling has overtaken State Amnesia as the leading production killer — which means the infrastructure problem is no longer purely a technical one. Token economics and orchestration overhead are now consuming enough business value that project sponsors are making the kill decision before engineering teams can solve the durability problem. Hallucination Propagation remains a big problem. The Brain vote in Finding 1 remains significant. And the Polyglot lead is fragile, with varied architectures well represented.

The models are, by most respondents' own assessment, smart enough — but 17% disagree. What is not yet smart enough is the infrastructure surrounding them: the state management, the fault-tolerance, the observability, the identity governance, and the deterministic execution layer that turns a model's judgment into something an enterprise can stake its operations on.

The 39% making the Polyglot Bet represent the current leading edge of enterprise architectural thinking. They are building systems where the model's intelligence is preserved and leveraged, but where the execution layer — the Spine — is deterministic, auditable, and durable by design. They are not waiting for a frontier lab to solve this for them. They are not betting that better prompting will patch infrastructure fragility. They are building the control plane.

The organizations still committed to stateless architectures — still trusting that manual retries and clever prompting can substitute for durable execution — are the ones most likely to contribute to the next wave of this data. Ghost Failures are a primary obstacle. The pattern is familiar: Early adopters diagnose the problem architecturally, migrate to durable runtimes, and escape the failure mode. Late movers inherit it. The Complexity Cliff is not theoretical. It is the wall that most current agentic architectures are already climbing toward.

The reckoning is runtime and economics, not reasoning.

Based on survey responses from 132 qualified enterprise respondents (100+ employees). Sample size is small; data should be treated as directional. Respondents include Directors, VPs, CIOs, CTOs, and Enterprise Architects across Technology, Financial Services, Retail, Healthcare, and other sectors.

Cisco brings agentic ops platform and security overhaul to Cisco Live

Tue, 02 Jun 2026 15:20:44 +0200

Cisco built the networking infrastructure that underpins the internet and the cloud. At Cisco Live this week, the company is making its case to hold that same position as enterprises shift from AI chatbots to autonomous agents. Where chatbots answer questions, agents take actions: They execute tasks, call tools, make changes, and operate continuously at machine speed. That changes the requirements for networking, security, and observability, and it is the frame for a series of announcements.

Among the key announcements from the Las Vegas event are:

Cisco Cloud Control: A unified management platform spanning Meraki, Nexus, Intersight, Splunk, and Collaboration.
Agentic Actions for networking: Closed-loop autonomous remediation for campus and branch networks.
Cisco Multicloud Fabric: A cloud-delivered service connecting branches, data centers, and cloud workloads across AWS, Azure, Google Cloud, and neoclouds.
Live Protect expansion: Runtime vulnerability shielding without reboots or maintenance windows, expanding to campus and branch Smart Switches.
Agentic IAM: Ephemeral, task-scoped access controls for AI agents delivered through Cisco Secure Access.
Cisco Data Fabric powered by Splunk: Federated Search, a Turnkey Machine Data Lake, an AI Toolkit, and an Agentic SOC with six purpose-built security agents.
New hardware: C9550 Core switch, 8100/8200/8300/8600 Secure Routers, outdoor Wi-Fi 7, the IR1000 industrial router, and the Cisco Board Pro G3.

“It’s no longer about humans clicking through dashboards, in a multitude of dashboards, trying to keep up with what the agents are doing,” DJ Sampath, senior vice president and general manager for AI software and platform, said during a press briefing. “A true collaborative operating model starts when agents are doing the heavy lifting and humans are constantly staying in control of what matters.”

Cisco Cloud Control

Managing enterprise infrastructure today means logging into separate dashboards for networking, security, compute, observability, and collaboration. Cloud Control replaces that with a single environment where humans and agents work from the same data and the same interface.

“With Cloud Control, what you’re getting is a secureness that allows you to be able to manage your infrastructure really, you know, effectively,” Sampath said. “It provides you with observability controls, it provides you with, you know, a safe AI gateway, guardrails for these agents. All of these come bundled along with Cloud Control.”

Core capabilities in Cloud Control include:

Cross-domain telemetry: Cloud Control aggregates data across networking, security, observability, AI infrastructure and collaboration into a shared data fabric that both operators and agents draw from simultaneously.
Purpose-built models: Incoming tasks are routed to the most appropriate model rather than sent through a single large language model. Cisco’s own models include the Deep Network Model, trained on four decades of operational networking data, a Foundation Security Model, and a time-series model for telemetry analysis. Frontier models are available for broad reasoning tasks.
Trusted agents: Agents are grounded in live telemetry, governed with enterprise guardrails and action-ready to execute at machine speed. The Cisco AI Canvas is the multiplayer workspace where operators and agents investigate and resolve incidents from shared live data. An Actions queue surfaces recommendations, root cause analyses and confidence scores for human review before any change is deployed.
Cloud Control Studio: Targeted for late 2026, Studio adds an Agent Builder for creating custom agents with connectivity to more than 50 third-party platforms via native connectors or the Model Context Protocol, and an App Builder that embeds OpenAI’s Codex into the platform. Anything built inside Cloud Control inherits its observability and security controls automatically.
Cloud Control Marketplace: Launches with integrations across IT service management (ServiceNow, Atlassian, BMC), identity (Okta, Ping Identity, Microsoft Entra ID, Jamf), network monitoring (LiveAction, Panduit), infrastructure knowledge (NetBox Labs, Device42, Vertiv) and AI-native platforms (Anthropic, OpenAI, NVIDIA, Collibra), among others.

Agentic networking and Multicloud Fabric

Network operations teams still rely on manual processes to detect problems and push fixes, while enterprise AI applications are increasingly split across multiple clouds. Cisco is addressing both with announcements this week.

First up is Agentic Actions for networking. Entering beta in June 2026 via Meraki, the feature follows a five-stage loop: sense, diagnose, remediate, validate, deploy. Experience Metrics converts raw device telemetry into user-experience measurements in real time. Deep Reasoning applies Cisco’s purpose-built models to multi-step root cause analysis. Digital Twin runs an emulated replica of the production network using actual software images rather than a mathematical model, allowing agents to test changes before deployment. Digital Twin enters alpha in July 2026.

The second announcement in this area is Cisco Multicloud Fabric. It connects branches, data centers, and cloud workloads across AWS, Azure, Google Cloud, and neocloud providers through a managed overlay with no customer-side hardware required. The fabric includes zero trust routing, cloud firewall service chaining and built-in ThousandEyes and Splunk observability.

“This is a cloud-delivered service that Cisco builds and operates, so there’s nothing for the customer to install or deploy,” said Anurag Dhingra, senior vice president and general manager for enterprise connectivity and collaboration. “It’s instantly available, configured seamlessly with one button in Cisco Cloud Control, and it stitches all of this connectivity in minutes.”

Security: Live Protect and Agentic IAM

Frontier AI models have compressed the window between vulnerability discovery and exploitation from months to minutes. Cisco is responding with runtime defenses that operate at the infrastructure layer and a new access control model built specifically for AI agents.

Live Protect: Applies runtime compensating controls to network devices without reboots or maintenance windows, precise enough to target a specific process-to-file interaction on a running device.

Agentic IAM: Rather than standing role-based access, agents receive ephemeral permissions scoped to a specific task, delivered through Cisco Secure Access via multi-turn LLM, API and MCP policy enforcement.

“So instead of access control, we start to move to action control,” said Tom Gillis, senior vice president and general manager for infrastructure and security. “It’s just in time, it’s just enough access, and it’s just long enough, meaning it’s ephemeral. So you don’t get six months or a year’s worth of access, you get the access that you need to be able to do and perform a task and no more.”

Non-human identity and agent protection: Cisco is building on technology it gained via the acquisition of Astrix Security to improve agentic AI security. The technology uses process-level inspection to distinguish agent activity from human activity. DefenseClaw, Cisco’s open-source runtime security framework for AI agents, is being embedded into Cisco Secure Client. With Secure Client deployed on more than 200 million enterprise devices, that means endpoint-level agent protections can be applied across the enterprise without requiring developers to instrument each agent individually.

Cisco Data Fabric and the Agentic SOC

Cisco Data Fabric, which debuted in September 2025, is getting a big update at Cisco Live. Powered by Splunk, it consolidates telemetry across network, application, security and third-party sources into a common layer that both human analysts and automated agents draw from, and serves as the data foundation for Cloud Control and the Agentic SOC.

Among the enhancements is an improved federated search capability. “Instead of having to move data into Splunk, we bring Splunk to the data and we can query this data across different environments without copying, without moving it,” Kamal Hathi, sernior vice president and general manager for Splunk, said.

There is also an AI Toolkit Agent Builder that provides domain-specific models for machine data operations as well as what Cisco is calling a Turnkey Machine Data Lake which automates schema management for raw machine data using AI.

On top of the data fabric, Cisco is deploying an Agentic SOC with purpose-built agents covering the full detection and response lifecycle.

“We’re reducing the time and sophistication required for security operations,” Hathi said. “We’re driving down from what used to take maybe days and hours down to minutes and seconds.”

Going a step further Cisco is integrating an AI SRE capability that performs autonomous root cause analysis for application and infrastructure performance issues. Technology gained by the acquisition of Galileo earlier this year, adds trace-level observability into agent execution covering tool calls, LLM interactions and prompt injection detection.

“Splunk then provides us full visibility into all aspects of the use of AI and agentic solutions and really makes all of this possible at scale in a trusted manner,” Hathi said.

What Snowflake Summit 2026 signals about enterprise AI

Tue, 02 Jun 2026 15:03:08 +0200

Most enterprises already have access to AI models, so that is no longer the differentiator. The real challenge begins after the demo ends. Organizations are now trying to determine how AI agents interact with ERP systems, supply chains, approvals, security policies, customer records, and operational environments that were never designed for autonomous systems. The reality is that ERP remains the system of record for many business decisions. If AI agents cannot operate within ERP governance, approval, and transaction frameworks, they remain assistants rather than operational participants.

What makes this interesting is that Snowflake is not positioning itself as another AI platform vendor. The company is positioning itself to be the governance and orchestration layer that enterprises will build agentic AI around. Horizon Context, Semantic Studio, Cortex Sense, Coco, Cowork, Apache Iceberg interoperability, Model Context Protocol (MCP) connectivity, and the company’s broader AI security strategy all point toward the same objective. The core message is that metadata, lineage, identity, policy enforcement, and business context should travel with the agent, not stay locked up in the platform it started in.

Enterprise AI is becoming an operational discipline problem

Most enterprises already operate in fragmented environments where ERP platforms sit separately from analytics environments, manufacturing operates independently from finance, and supply chain data spans multiple systems. AI accelerates those existing issues because autonomous systems can amplify inconsistencies faster than human users.

In my recent Forbes article, I noted that modernization efforts often begin to break down when organizations lose consistency in governance, ownership, and operational definitions as data moves across systems. A technically correct AI-generated answer can still become operationally wrong if finance, operations, manufacturing and supply chain teams all define the same metric differently. AI readiness is forcing enterprises to confront inconsistencies that existed long before generative AI arrived.

Why Horizon Context and Semantic Studio matter

Many enterprises were already trying to solve these problems themselves through governance platforms, semantic layers, lineage tools, catalogs, ETL pipelines, security frameworks, and custom integrations. The problem was rarely a lack of tooling. The challenge was aligning business definitions, ownership models, and operational controls across environments that evolved independently over time.

Snowflake is consolidating more of that governance into a centralized operating layer closer to where AI systems operate. Horizon Context matters if it can consistently carry governance, lineage, security, and business meaning across environments that already contain multiple policy engines, metadata systems, and operational platforms. Semantic Studio matters because enterprises cannot realistically operationalize agentic AI if every department defines the business differently. Those inconsistencies become operational risks once AI systems begin to automate workflows or interact across environments.

The importance of the Iceberg strategy

The interoperability strategy, based on Apache Iceberg, is important because it is one of the biggest operational concerns across enterprise technology environments right now. Snowflake already has zero-copy capabilities, but zero copy alone does not address broader enterprise concerns around governance consistency, duplicated architectures, lock-in, or multi-engine execution. What stands out heading into Snowflake Summit is Snowflake-managed Apache Iceberg interoperability through Horizon Catalog and open APIs.

This reflects where many enterprise buyers want the market to go, as customers increasingly seek architectures that reduce dependency on any single platform. Enterprises want data platforms, cloud environments, ERP systems, analytics tools, and operational systems working together without rebuilding governance and integration layers every time AI strategy changes. Enterprise environments have become too distributed for one platform to realistically control everything anymore.

The data platform competitive landscape has become crowded

Almost every major enterprise platform vendor now pursues the same enterprise AI control-layer opportunity. Databricks, Microsoft, SAP, and others want to be the control layer that governs enterprise data, AI workflows, and business context. The approaches differ, but the destination is the same.

From here, success depends on execution and operational simplicity, and on reducing complexity rather than adding to it. Snowflake still needs to prove that its interoperability strategy works consistently in real enterprise environments, because operational integration across fragmented systems is significantly harder than the architecture often suggests in controlled product demonstrations.

The logic behind the Natoma acquisition

Snowflake’s planned acquisition of Natoma is an important move connected to Snowflake Summit. It shows the company understands that AI agents need more than access to enterprise data. They need governed access to APIs, workflows, collaboration systems, operational systems, emails, databases, applications, and tickets where enterprise work happens.

That is where MCP becomes operationally important. Anthropic accelerated the conversation around MCP, but Microsoft, Google Cloud, Databricks, and Snowflake are now all moving aggressively toward MCP-enabled enterprise architectures. Enterprises should not assume MCP solves operational trust problems. It does not. MCP standardizes connectivity, but connectivity alone does not create accountability, approval structures, ownership models, or business controls. Poorly governed MCP environments could standardize risk just as effectively as they standardize interoperability.

That is the logic behind the Natoma deal. If agents are going to act across systems rather than simply generate responses, then policy enforcement, identity controls, and business accountability must move with them. Otherwise enterprises invite shadow AI, uncontrolled automation, and data exposure.

Why security is becoming the real enterprise AI conversation

Security is becoming significantly more important to the enterprise AI discussion than many organizations expected even a year ago. Snowflake’s announcements around Data Exfiltration Policies, AI Security Posture Management, Multi-Party Authorization, Cortex Guard, Trust Center remediation, and model-level RBAC (role-based access control) all point toward environments where non-human actors increasingly operate independently inside business systems.

Traditional security models were built around users. Enterprise AI breaks that assumption, since software agents may trigger workflows, move data, access systems, and make decisions without direct human involvement. The bigger risk is not necessarily a bad AI-generated answer. The risk is that autonomous systems act in the wrong operational environment, with an incomplete business context or excessive permissions.

The advantage for Snowflake is that it already operates close to critical enterprise data workloads for many organizations, creating a strong opportunity if enterprises decide to integrate governance, orchestration, security, and AI operations around centralized data platforms.

What Snowflake still needs to prove

The biggest challenge Snowflake still faces is proving it can simplify enterprise execution rather than simply centralize visibility, since the two are very different in large organizations. One of the risks I continue to see for CIOs is governance sprawl. Most enterprises already operate overlapping policy engines, catalogs, semantic layers, lineage platforms, security frameworks, and observability tools. The issue lies in adding another orchestration layer without simplifying the operational environment beneath it.

Enterprises should also be realistic about the broader “single, governed, live copy” vision vendors continue to promote. The market is moving in that direction, but the transition will take years. Snowflake cannot automatically fix poor ERP data quality, disconnected ownership models, inconsistent process definitions, or decades of accumulated operational debt sitting underneath enterprise environments.

The hard part is not interoperability itself but alignment across governance, systems, processes, and people, especially across manufacturing, supply chain, health care, telecom, retail, and financial services organizations, where operational complexity is already high and disconnected AI environments create meaningful business risk.

Snowflake is moving in a direction that aligns with what many enterprises are trying to achieve, as AI readiness increasingly forces organizations to rethink ERP, data, analytics, security, and operational execution as interconnected business capabilities rather than isolated technology projects. The organizations moving fastest are not the ones chasing AI headlines. They are the ones cleaning up governance, aligning operational processes, improving interoperability, and figuring out how AI fits into production environments without disrupting operations underneath them.

Once agents move from generating content to executing work, the advantage shifts from model access to operational trust. The winners will be the platforms and enterprises that can hold governance, security, ERP process integrity, and business accountability together under that pressure.

Sweden’s Hexagon takes a measuring tape to the industrial world… and its virtual counterpart

Tue, 02 Jun 2026 13:17:44 +0200

Stockholm-headquartered company is applying precision observability and digital twins to make a safer, more sustainable and efficient world