One of the first questions I ask devops organizations is to walk me through their development and operations standards. What are the non-negotiable devops practices? What are the data governance first principles? What observability standards are in place? How is security embedded in devops? This is the starting point. From there, we might review standards on how functional requirements are written. For businesses developing AI agents, I’ll ask about their non-functional requirements (NFRs) and how testing is performed.

Now that many devops organizations are using AI code generators, vibe coding, and applying spec-driven development practices, the questions increase. How does the AI know your organization’s standards? What processes monitor and enforce these standards? What are the developer responsibilities for owning the outcomes?

“Generative AI will happily hand you the movie set of an app with looks of a house from the street. The doors and windows open, and the demo runs clean,” says Mike Toole, director of security and IT at Blumira. “Behind the facade, there’s no plumbing and no wiring: no input validation, no auth boundaries, nothing actually holding it up. If your only gate is ‘does it run and look right,’ you’re shipping a set, not a building.”

One report shows that 92% of developers use AI coding tools daily in 2026 and that 41% of all global code is now AI-generated. Will all that code deliver value, operational issues, or mounting AI debt? I spoke to several experts about how to keep AI-generated code aligned with organizational standards and how to define an AI code generator’s context beyond just functional requirements.

Document like a construction specification

A general contractor in the construction industry will review building information models that provide a view of what they are developing. But many of the details are in the construction specifications, including component stipulations and performance requirements. Devops teams without equivalent documentation for their organization, architectures, and applications may have gotten away with this omission in the pre-AI era. But institutional knowledge and compliance requirements are the context AI code generators need before you share the first functional prompts with them. 

“AI-generated code stays aligned with engineering standards only when those standards are explicit, available, and difficult to bypass,” says Eddie Zhou, founding engineer at Glean. “Put architecture, approved libraries, data-handling rules, security controls, naming conventions, observability, test expectations, and non-functional requirements into specs and automated checks. Then, ensure you give the model that context but treat its output as untrusted until it passes the same reviews, tests, scans, and production monitoring as human-written code.”

Overcoming tribal knowledge was always challenging as devops teams had too much pressure to push features and little incentive to maintain documentation. Two of my top AI leadership skills are change management and agile collaborative leadership, because devops teams need practice alignment while introducing AI capabilities.  

Zhou adds, “AI amplifies ambiguity and weak governance as efficiently as good engineering. If standards live only in tribal knowledge, AI will expose that problem, not solve it.”

Encode non-functional requirements as automated tests

The problem with requirement documents and reference architectures is they aren’t directly enforceable with human or AI developers. Once a devops team agrees on standards and documents them, the next step is to develop approaches to encode them as automated acceptance criteria in CI/CD pipelines.

“AI code generators and human developers optimize for functional correctness—making the feature work—and quietly skip the non-functional requirements where most of your real standards live, including performance, security posture, error handling, observability, and auditability,” says Michael Bevilacqua, vice president of AI product management at Adeptia. “Encode your NFRs as executable acceptance criteria that generated code must pass before it merges, so ‘aligned with our standards’ becomes a gate the pipeline enforces on every change.”

An example: Performance requirements stating that all web pages should have a total page weight under 2MB can be validated during the pull request, and requiring the time to first byte (TTFB) to be under 800ms can be automated in CI/CD in a staging environment.

Requirements for stakeholders and AI

Architecture and automated non-functional requirements covering performance, security, and other organization-level compliance requirements should become the base-level context standards shared with AI-code generators. The next set of considerations for setting accurate contexts starts with application- and agent-specific requirements, their intended use cases, and specific compliance guardrails.

“CIOs are mandating AI to build apps faster, but many are realizing speed isn’t the bottleneck because more code doesn’t automatically create business value,” says Matt Healy, senior director of product strategy and marketing at Pegasystems. “Before developers write any code, organizations must understand customer needs, assess legacy systems, stay current with regulations and best practices, map enterprise architectures and integrations, and align business and IT.”

Consider three stages of understanding requirements. Once stakeholders set business value and intent, developers must first align on an implementation strategy and discuss performance, cost, and other trade-offs. Then, developers should reconvene with stakeholders and review implementation trade-offs. Healy adds, “On large projects, defining the solution and success metrics can take as much time as building it. Leaders aren’t just using AI to accelerate development, but to help executives, business analysts, product owners, and IT teams collaborate more effectively.”

The third stage is gathering the goals, user requirements, and implementation approach into a development-specific context. But we’re not done yet, because data requirements and operations considerations must also be included in the context fed to AI code generators. 

Build governance into the specs

How the application or AI agent being developed can use the data it has access to requires clear specifications. Data governance programs should have standards based on data sets, defined roles, entitlements, and usage specifications.

Kash Mehdi, vice president and field CTO at Reltio, says the teams that are pulling ahead treat data governance as an input to AI, not an audit after it. “They ground their tools in trusted, semantically consistent data models, approved specs, and security policies, so the AI inherits the organization’s standards instead of inventing its own. Without that governed context layer, you don’t scale from a handful of AI-assisted workflows to thousands; you just accumulate inconsistent code faster,” Mehdi says.

Here are two options to consider in creating standards: First, establish repurposable data sets as data products with defined integrations and usage rules. Organizations with many data sets and integration points should consider data fabrics. The second (and key requirement) is to standardize the format of data contracts, using human- and machine-readable formats so that data owners, users, and AI code generators operate from a consistent set of principles.  

“AI writes code that compiles and passes tests but quietly ignores your data contracts, so the failures show up in production as corrupted state, not build errors,” says Ed Huang, cofounder and CEO of TiDB. “The fix is to make governance machine-checkable, including schema constraints, access policies, and data-quality rules enforced at the database layer where the AI can’t route around them, not documented in a wiki the model never reads. Treat the database as the enforcement point for your standards, and it stops mattering whether a human or an agent wrote the query.”

Observability and testing first

When AI generates the code, a best practice is to use static application security testing (SAST) and other code analysis tools to perform automated code reviews. Another best practice is to put applications through penetration testing and other application security validations. But many of these tools are outside in view of what the AI developed. To get an inside view, observability and testing requirements must be included as a standard, with specific requirements around the key transactions you’re asking the AI to develop.

Sanjay Gidwani, CEO and founder at Kosmos, says, “More code volume just means more time spent investigating, and the fix isn’t reading the code more carefully before it ships. It’s connecting the observability signal, the thing that broke, back to the specific change that caused it. Without that link, you’re doing the same manual investigation as before, just with a bigger haystack.”

Testing requirements must go beyond generating automated tests, using synthetic data to expand the test patterns, and implementing continuous testing. “Instead of testing one input against one output, test whether an invariant holds across a wide range of generated inputs, which is a good fit for AI’s unbounded input space and non-deterministic outputs,” says Lior Gavish, cofounder and CTO at Monte Carlo. “I treat it as one layer in a stack with evals mapping the input space, property-based testing stress-testing it for edge cases and brittleness, and observability on live traffic checking whether production is drifting from the properties you defined as non-negotiable.”

Package and evolve the standards

Ed Frederici, CTO at Appfire, recommends codifying standards as machine-readable rules, including linters, formatters, and type checks. Merge the organizational and application standards into one context shared with the AI code-generating tool. His other recommendations:

• Enforce standards in continuous integration so violations block merges.
• Give the AI persistent context, such as CLAUDE.md, style guides, and architecture docs.
• Keep changes small and reviewable.
• Require human review of every pull request because AI-generated code must get the same scrutiny as any contributor’s. No exceptions.
• Back this approach with solid test coverage to catch regressions.
• Periodically audit for drift as your standards evolve.

It’s also important to remember that as code must be extended and maintained, so must the underlying development standards. “AI-generated code only stays aligned with your standards when it’s powered by a context engine that keeps learning, not a static snapshot of your rules,” says Itamar Friedman, CEO and cofounder at Qodo. “That means an engine that continuously adapts to your codebase’s evolving standards, your team’s PR history, and the prior decisions your engineers have already made, so the AI isn’t just following instructions but actually understands how your team works.”

As more devops organizations rely on AI code-generating tools, developers have an important opportunity to develop the standards and automated validations required to ensure what is built meets engineering and compliance requirements.

Cockroach Labs, the company behind distributed SQL database CockroachDB, is betting that the rise of agentic applications will make traditional database provisioning, where systems are sized for peak demand, increasingly difficult to justify as agents create highly concurrent, unpredictable and often short-lived database workloads that can leave provisioned compute idle between bursts.

Its solution to that problem is Cockroach Continuum, a database fleet management platform that pools compute and storage across isolated CockroachDB databases in an enterprise to allow capacity to be shared across workloads rather than reserved for individual systems.

That shared model can help enterprises accommodate sudden bursts of agent activity without maintaining dedicated infrastructure for every database, while paying only for consumption rather than peak capacity, the company said Tuesday.

Continuum does this by combining database virtualization with Cockroach Plenum, a feature that separates compute from storage so that the two capacities can scale independently.

It also draws on Cockroach Aegis, which uses an AI-assisted operations layer to diagnose issues and recommend actions across an enterprise’s database estate to help database administrators (DBAs) reduce the manual work involved in monitoring, troubleshooting and tuning databases while retaining control through policies, the company said.

What Continuum could mean for CIOs

That reduction in manual work for DBAs is likely to benefit CIOs in terms of operational cost.

“Enterprises don’t just pay for database capacity. They pay people to provision, monitor, tune, troubleshoot and scale these environments. If Cockroach can automate a meaningful portion of that work, there is value there and a chance to offset costs,” said Ashish Chaturvedi, executive research leader at HFS Research.

For more direct infrastructure-related cost savings via Continuum, though, CIOs will need to look at how their database estates are provisioned.

Stephanie Walter, practice lead of AI stack at HyperFrame Research, said the greatest savings will come from large fleets of independently provisioned databases that spend much of their time underused: “Sharing capacity across workloads with different demand patterns could substantially improve utilization,” she said.

Not all enterprises will benefit: “Cost savings will be less meaningful for databases that already run near capacity or require tightly dedicated resources,” she said.

One caveat is that, because Continuum shifts the calculation of database costs from provisioned capacity to consumption, unexpected bursts of activity could make it harder for CIOs to forecast database costs.

CIOs will therefore need to assess their own workload patterns and test whether the higher utilization and reduced idle capacity actually translate into lower overall database costs, rather than assuming that consumption-based pricing will automatically deliver savings, Walter said.

While Continuum may simplify database management, it could also deepen dependence on CockroachDB and make workloads harder to move elsewhere, she said — with the added risk that, by coupling independent databases together onto one platform, it creates a new single point of failure.

What Continuum could mean for developers

For developers though, the shift to Continuum could reduce the time and effort required to build applications, especially agentic ones.

Development teams using Continuum can design applications without having to worry as much about the database compute and storage capacity those applications will need, when that capacity needs to scale, or the operational work required to provision and manage it, said HFS’s Chaturvedi.

But, said Walter, those advantages don’t come without challenges.

“Pooling infrastructure as Continuum does is more likely to create questions around workload isolation, performance predictability, and debugging,” she said. “Enterprise teams will want to know whether one demanding workload can affect others and whether they can trace a performance problem through the shared environment.”

Who is likely to adopt Continuum

Existing CockroachDB customers with large fleets of distributed transactional databases are likely to be among the earliest adopters of Continuum, Walter said.

SaaS companies, financial services firms, digital platforms and AI-native businesses could also be strong candidates, particularly where applications generate unpredictable demand and database capacity needs to scale quickly, she said.

For those enterprises, though, one of the capabilities that could make Continuum most useful for unpredictable workloads is yet to arrive.

Automatic compute scaling, which will help scale compute up or down as necessary to maximize cost savings without compromising availability, is “coming soon,” the company said.

For CIOs and CDOs heading into Microsoft Fabric and SQL Community Conference Europe, the main question is not which data technology sits at the center. It is whether the data platform improves revenue, productivity, and decision speed while creating a trusted foundation for AI at scale. That should drive the data strategy.

Enterprise AI is forcing companies to tackle a familiar problem, with data spread across ERP, CRM, operational systems, databases, applications, warehouses, and analytics platforms built over years. That was manageable for reporting and point-to-point integration. Copilots and agents raise the stakes because they need to reason across customers, orders, inventory, financial implications, operating constraints, permissions, and business rules at the same time.

That moves the discussion from architecture into CIO and CDO strategy. What outcomes are we trying to improve? What data and context are required? What needs to move versus connect? Where do Microsoft Fabric, Azure Databases, and other platforms fit? How will governance and authority follow the data? Where should the data be stored and what sovereignty or regulatory restrictions apply? And how will we measure results?

Microsoft is positioning its broader data platform around AI business value. That framing is useful when it translates into an operating strategy. As I wrote in Forbes about Microsoft Build in June, the next phase of AI depends less on the model and more on data readiness, governance, interoperability, and operational execution. The conference should give customers a closer view of how those pieces come together. The question for CIOs and CDOs is how that direction fits their existing data estate.

The AI problem is usually a data problem

Many AI initiatives stall on data readiness rather than the model itself. The issue is not one statistic. It is the combination of fragmented data, inconsistent definitions, and the effort needed to prepare and govern information before AI can use it reliably.

Copilots and agents need trusted context around customers, financials, inventory, operations, permissions, and business rules. AI exposes existing weaknesses. Duplicate customers, poor product data, and inaccurate inventory become more consequential when AI is recommending or taking action. AI does not create the data quality problem; it makes the operating cost harder to ignore.

The goal is to make more of the existing data estate useful for AI without turning modernization into a wholesale rebuild.

Microsoft Fabric and Azure Databases play different roles

For customers, the question is how Microsoft’s broad portfolio translates into architectural choices, including what should move, what should connect, and what can stay in place without limiting the result the business is trying to achieve.

Azure Databases support transactional and operational workloads, each with distinct performance and application requirements. Fabric provides a unified SaaS experience across data integration, engineering, analytics, real-time intelligence, data science, and business intelligence. Fabric IQ adds a semantic intelligence layer that provides shared business context for Copilot and agents. Some workloads may belong in Fabric, others in Azure Databases, and some on third-party platforms; moving them adds cost without creating enough business value.

The architecture should follow workload, data maturity, economics, and business value, not a single destination.

Connected data has to improve the decision

Microsoft’s broader data platform can connect systems of record and operational applications with analytics and AI. Azure Databases, Fabric, OneLake, Power BI, and governance can play different roles. What matters is whether those connections shorten the path from operational data to a decision, not how neatly the products line up.

A customer record may live in CRM, orders in ERP, inventory in operational databases, and demand models in an analytical environment. Fabric Real-Time Intelligence can add live events to that picture. A manufacturer can stream equipment events or production events, detect a developing issue, and alert teams while there is still time to change the outcome. The value comes from reasoning across that context so the business can understand what is happening, why it matters, and what action makes sense next.

Trusted context turns data into AI business value

I recently wrote in InfoWorld that trusted context is becoming the currency for enterprise AI. That is especially relevant here because once copilots and agents rely on enterprise data, then quality, permissions, lineage, and security become operating requirements, not background data issues.

Knowing inventory is 8,000 units is data. Knowing whether those units are available, committed elsewhere, in the wrong distribution center, or on quality hold is business context. As AI moves from answering questions to taking action, that context determines whether the result can be trusted.

Microsoft frames AI business value around growth, insight, and scale. Each needs an operating definition. Growth can mean new revenue, better customer responsiveness, or growing without adding cost at the same rate. Insight means combining context across Microsoft 365, Fabric, and operational systems to make better decisions faster. Scale means expanding AI without rebuilding governance for every use case.

A reusable data foundation can also reduce pipeline and management effort while improving decisions around pricing, inventory, customers, supply chain, and finance. Microsoft cites coverage of more than 100 standards. The practical question is whether AI can scale without risk and complexity growing at the same pace. For multinational or regulated organizations, that also includes where data is stored and processed and which sovereignty requirements apply.

Agentic workloads raise the bar. Organizations need to know what information informed a decision, who or what had authority to act, which policies applied, and how a wrong action can be reviewed or reversed.

That is where the data platform becomes part of what I describe as decision architecture. Context explains what is happening. Decision logic determines what should happen next. Authority defines what a person or agent can do. Orchestration coordinates systems and people. Execution completes the action and provides a path to review or reverse it. Trusted data feeds that architecture. Without trusted data, automation will be difficult to trust at scale.

Microsoft’s breadth is most useful when it reduces complexity

Microsoft’s advantage may be its enterprise footprint. Azure Databases, Fabric, OneLake, Power BI, Microsoft 365, business applications, developer tools, identity, security, and partners touch many of the places where information is created and work gets done.

Most customers will keep data across multiple systems. Microsoft’s opportunity is to use that breadth to create a simpler path from data to workflow to business outcome without requiring everything to live in one place.

Customer proof points matter because data strategies can get abstract. The KPMG Australia example is useful because KymChat moved beyond an internal productivity tool into a client-facing offering, creating a path from internal AI investment to new business. Microsoft also reports that improvements to the data foundation increased KymChat search quality from 50% to 91%, with results delivered in under a second.

BMW Group provides a more recognizable operating example. Microsoft says Azure helped BMW make vehicle data delivery and analysis 10 times faster, cutting the lead time for engineering insights from days to hours or minutes. Audi adds an AI deployment example. It used Azure AI Foundry, Azure App Service, and Azure Cosmos DB to launch a secure HR assistant in two weeks and is extending the same framework to eight additional agents across the enterprise. Levi Strauss & Co. offers another angle. It consolidated nine ERP systems on Azure, reported a twofold improvement in latency and a 60% improvement in IOPS and now uses Fabric IQ for companywide cost reporting. These are the kinds of proof points that connect platform architecture to time, cost, productivity, and decision quality.

Interoperability matters across the enterprise estate

Microsoft sits in a market with Snowflake, AWS, Google Cloud, Oracle, and others, each with different strengths across infrastructure, databases, analytics, openness, and AI. Databricks also plays an important role, but the connection is different because Azure Databricks is provided as a first-party service directly on Azure. Most large enterprises will remain heterogeneous, making interoperability, cross-platform governance, and incremental modernization central to strategy.

The opportunity is to make Microsoft’s data platform useful across the mix of systems that customers already run. Most enterprises are not starting from a blank sheet, so the value is in helping them connect, govern, and modernize over time without forcing everything into one place.

CIO and CDO strategy should start with the business outcome

This is where the conversation becomes most useful at the Microsoft Fabric and SQL Community Conference Europe. For CIOs and CDOs, an architecture diagram matters more when it is backed by a decision model. A useful data and AI strategy should work backward from the business outcome through five decisions.

1. Start with the business outcome. Define what needs to improve, including revenue, margin, productivity, customer experience, decision speed, working capital, or time to value. Let the technology choice follow the objective.
2. Map the data and context required. Identify the operational, transactional, and analytical information, semantics, and business rules that influence the outcome.
3. Decide what moves and what connects. Determine where Fabric, Azure Databases, and non-Microsoft platforms fit. Let workload, economics, and value drive modernization rather than a single destination.
4. Design governance, authority, and economics together. Define how security, permissions, lineage, and controls span operational, analytical, and AI workloads, and identify opportunities to simplify pipeline, integration, and management efforts.
5. Measure the operating result. Set KPIs before scaling. Technology adoption is not the outcome. CIOs and CDOs should know which business measures should change, by how much, and over what period.

That is how the data platform becomes enterprise strategy, tying architecture, governance, AI, and economics to operating outcomes and bringing business leaders into the discussion before the architecture is set.

What customers will still want to understand

Microsoft has many of the pieces required to connect enterprise data, analytics, and AI. Customers will keep looking for guidance on the roles of Azure Databases, Fabric, and the broader data platform, along with cost, licensing, migration, and governance across heterogeneous environments. They will also want more proof points from KPMG, BMW Group, Audi, and Levi Strauss & Co. that start with a business result.

That is where Microsoft’s positioning around a data platform for AI business value comes together. The value is in helping customers connect platform choices to better decisions, faster action, and measurable operating results.

After three decades in enterprise technology, I keep coming back to the same point. The technology is only part of the answer. For CIOs and CDOs, the harder part is deciding how the data platform fits into the way the business operates, how decisions get made, and where AI can improve the outcome. That is really the question behind how Microsoft connects your data across the enterprise. The conference should give customers a useful view of how Microsoft is bringing those pieces together and where that can create better business outcomes.

Postgres just turned 30. Over those three decades, I’ve watched it pick up hot standby replication, logical replication, asynchronous IO, just-in-time compilation, and dozens of other features built for enterprise workloads. Every one of them solved a real problem and raised the floor on what a DBA needs to know just to do the job well.

I don’t think most people outside this world fully register how much that floor has risen. In the early days, improvements were small and mostly about stability. Now, 30 years in, the focus is squarely on enterprise functionality, and that functionality comes with complexity attached. The more you build, the more there is to understand and manage, and that increases every year.

Hiring more people doesn’t solve this

Most organizations treat a scaling database problem as a staffing problem. Hire enough DBAs and you’re covered. I think that’s the wrong way to look at it entirely.

It’s not far off from the old “too many cooks spoil the broth” problem. You don’t make better soup by adding cooks. You make better soup with a better chef. A 100-terabyte database with serious performance issues doesn’t get fixed by putting 10 DBAs on it instead of one. It gets fixed by someone who has seen that failure before and knows exactly where to look.

Experienced DBAs are expensive and hard to find, and the problem is only getting worse. A few years ago, it was IoT driving demand for time series expertise at scale. Now it’s AI, and organizations are building enormous databases to support retrieval pipelines and large language model (LLM) training, often without the experience on hand to run them safely.

Where human error comes from

Humans are unpredictable. We make assumptions. Sometimes, we think the process is getting in the way, so we take a shortcut around it. And we make mistakes because that’s simply human nature.

I don’t think that’s something we’re ever going to fully engineer away as long as a person is in the loop, and honestly, we want a person in the loop making the real decisions. So it becomes a balancing act. You have to understand the mistakes people tend to make, build the discipline to follow good processes consistently, and still know when a situation calls for judgment rather than a checklist.

Why AI helps more than people expect

I think this is where AI has earned its place. It’s not as a replacement for the DBA, but as something that follows a process more consistently than a person under pressure tends to.

Modern AI systems still have problems with hallucination and getting the full picture right. However, with the right guardrails, auditing, and tracking in place, they are able to follow the process very well. It is much easier for me to say, “Forget it, I know a shortcut, I’ll just push this through,” than it is for a well-constrained model to deviate from its instructions. As long as the instructions are clearly defined, LLMs tend to stick to them.

Another advantage worth naming is if an LLM is doing the diagnostic work, you can put much stronger gating around its ability to actually make changes. You can let it follow a tight, well-defined process to diagnose a problem while still requiring a human to approve anything that touches the live system, whether that’s creating an index, dropping one, or changing a configuration value.

That combination gets you to a solution far faster than the old way, using the model’s training plus whatever supplemental knowledge you feed it through retrieval-augmented generation (RAG), while keeping a person at the one point where it actually matters. Did the model get the diagnosis right? Does the proposed fix line up with the actual problem? That’s the question a human needs to answer before anything gets applied.

The industry hasn’t figured out the limits yet

I am not sure we are far enough along the path as an industry to really know what we’re getting wrong. I am working through these questions myself right now, looking at autonomous agents for Postgres operations and where the real risk is.

What’s clear to me already is that strong guardrails matter in two places, not one. You need guardrails on the prompts so the model verifies its findings and doesn’t hallucinate into a bad recommendation. And you also need guardrails on what the model is actually allowed to do. Letting an agent create an index carries a manageable risk. Letting it truncate your orders table does not. Auditing matters just as much; when something does go wrong, you need to see exactly what happened and undo it. The fallback needs to stay in place until the industry broadly trusts these systems more than it trusts a human.

Picture a load spike that hits overnight, the kind where batch processing that normally runs fine suddenly does not. The old way means spending hours trawling logs, index stats, table stats, and query performance before you land on a likely cause and you can apply a fix.

Put an LLM on that same problem and the hours-long process compresses into minutes. It’s the same productivity shift we’ve already seen in software development, where an experienced user with the right skills and guardrails can get LLM output that matches or beats a junior developer’s work. The quality comes down to this process: Structure the work, define a clear spec, build the implementation plan, then verify each stage before moving on.

The same discipline applies to database operations. The worst thing you can do is rush in and say to the model, “This happened, go fix it.” You need to guide the tools properly to get good results from them. When it’s done right, it works.

Where this goes from here

A few things need to be true for this to scale across the enterprise. Frontier models already understand Postgres well, but they don’t know everything, so you need to feed them supplemental knowledge alongside that training. Full documentation matters here, so do internal runbooks. The process has to require the model to actually consult that material rather than coast on what it already knows.

I expect the same kind of structured skills that are common in AI-assisted development, the step-by-step approach to planning and verification, to show up specifically for Postgres operations. That will make the job easier for DBAs, and easier is what matters.

We’re probably not far from agents that sit and watch a Postgres instance around the clock and rarely need a human to step in. The slower part is trust. For example, look at how long it took people to actually believe AI-written code was any good. I would guess it is the same pattern here, but I don’t doubt for a second that we will get there.

In the meantime, you do not need to hand an LLM the keys to your database tomorrow. Start smaller and begin with read access to your monitoring data. It’s a low-risk place to start.

An agent watching constantly can catch the kind of slow, compounding anomaly that threshold-based alerting tends to miss, a gradual rise in IO alongside a gradual rise in memory, and flag it before it becomes the kind of outage that costs real money every hour it runs.

That’s not a small thing. The DBA shortage is not going away on its own, and waiting for the industry to fully trust autonomous agents before using AI at all is the same as falling behind. The teams that figure out where the human belongs in this process are the ones who’ll be ready when the rest of the industry catches up.

—

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.

Entrusting mission-critical workloads in the cloud puts a lot of pressure on IT operations to build resilience into data infrastructure they don’t even own — to make sure that when an incident happens elsewhere, the lights stay on at home. Fortunately, savvy CIOs are learning they can architect their systems for resilience and high availability to keep mission-critical cloud workloads running when disaster strikes.

When designing for resilient, highly available cloud workloads it is critical to understand the details of your cloud provider’s service level agreement (SLA) and recognize that providers operate on a shared responsibility model. That means there are many things the provider is responsible for, but the workloads you’ve got running on their infrastructure are not among them. With that in mind, we’ll need to focus on three core goals essential to building and maintaining highly available, resilient cloud workloads:

1. Identify and eliminate single points of failure
2. Close or mitigate conditions leading to recovery gaps, and
3. Overcome operational complexity.

Remember, everything fails

Designing for application-level resilience and high availability is predicated on recognizing that everything fails. That’s not pessimism, but realism, and embracing this fact gives you a leg up in architecting resilient IT. Hardware breaks down, disasters occur, mistakes are made, software incompatibilities are common, and limits are exceeded that result in loss of service. There are four categories of failure that need to be taken into consideration when designing for resilience and high availability:

1. Single point of failure: As the term suggests, this describes a non-redundant device, route, or point of connectivity that results in zero fault tolerance in the event of an incident involving that choke point.
2. Excessive load: Exceeding the throughput or memory limits of a device or service can result in latency, service degradation, or failure affecting service level agreements (SLA) and service level objectives (SLO).
3. Misconfigurations and bugs: Perhaps the most common source of failure, these breakdowns often occur during installation, maintenance, and patching leading to the incorrect execution of code.
4. Shared fate: This type of failure is like non-redundant connectivity. When you rely on third-party services and there is an incident beyond your control affecting a partner, it can result in downtime or service degradation.

Having identified the primary challenges to maintaining service uptime and continuity, let’s explore an approach to achieving resilience through high availability, disaster recovery, and the process of continuous improvement.

Working toward continuous improvement

High availability is often thought of as measured by “X Nines,” representing the percentage of time a service is operational over the course of a specified time frame, usually a year. Six nines of availability, for example, means that a service can be expected to run 99.9999% of the time, or 8759.99 hours out of 8760 in a year. That sounds good until a disaster happens. Then we shift to disaster recovery, or the ability to restore a service and its associated data quickly and correctly when things go wrong. Disaster recovery is often measured and evaluated by a recovery point objective (RPO), which is the maximum acceptable amount of data loss, and a recovery time objective (RTO), which is the maximum acceptable amount of time a service can be down.

By learning from our mistakes, incidents, and the ongoing process of testing, observing, and evaluating IT operations, we apply new information in the goal of continuous improvement to get peak performance out of our investments in IT. But because we’re addressing resilience and high availability in the context of workloads operating in the cloud, we should understand the shared responsibility model that most cloud service providers use. Details may differ from provider to provider, but the shared responsibility model of cloud services is your vendor’s statement of responsibility for maintaining its infrastructure and ability to deliver storage and compute capacity in a region and availability zone where you have a need. In return, you accept responsibility for the configuration, maintenance, availability and operation of the workloads you choose to run on your vendor’s cloud.

A cloud service provider will typically operate and maintain physical infrastructure in different areas around the world, with multiple availability zones in each area. Each availability zone will have one or more data centers with its own power, cooling, and other operational support. Data centers are typically located far enough from each other to minimize the chance that a natural or regional disaster will affect multiple data centers, but close enough that they can operate as a single, logical data center — thereby maximizing bandwidth and throughput, while minimizing latency. This is redundancy at scale that eliminates a single point of data center failure.

Designing for application high availability and disaster recovery

To build out or retrofit your infrastructure for application-level resilience and high availability, there are four things you must have: clustering, data replication, failover, and disaster recovery. Let’s look at each and how to architect for them.

Clustering

Clustering is the practice of connecting like and complementary systems to improve availability and reliability. Think of it as putting into practice the maxim “the whole is greater than the sum of its parts.” Traditionally, clustering was achieved using hardware, specifically storage area networks (SAN), to connect and support systems in a physical data center. However, in the cloud age, hardware-based clustering has proven to be expensive and inflexible. Software-based SANless clustering with products such as SIOS LifeKeeper delivers all the benefits of the traditional approach while also working better in cloud and hybrid environments.

SANless clusters enable the configuration of nodes based on the organization’s operational priorities and work easily for enterprises running geographically distributed data centers or cloud availability zones. Because SIOS LifeKeeper supports single-site, multi-site, cloud, or mixed environments, and affords real-time access to operational data during incidents requiring failover, it is ideal when mission-critical workloads are distributed across multiple providers. LifeKeeper clusters create redundancy and eliminate single points of failure, both of which are necessary for achieving high availability. For enterprises operating hybrid or multi-cloud infrastructure, this enables you to shift to secondary resources should your primary service experience an outage.

Data replication

IT operations and your mission-critical applications rely on data, so it’s vital to keep data in sync between nodes in real time, whether synchronously or asynchronously, depending on the application. When working to achieve high availability, it’s important to monitor the health of infrastructure elements and the applications you’re running. This ensures that downtime affecting the application and any downstream dependencies is detected so that failover and recovery to a standby node can occur automatically. When everything is in sync and data replication is happening, this ensures complete readiness; there’s no need to rebuild a database or for any manual operations. And with SANless clusters using SIOS DataKeeper, this will happen across availability zones, regions, and to or from on-premises, cloud, or multi-cloud resources in hybrid environments.

What’s important here is that the software you use for SANless clustering be application aware. That’s SIOS LifeKeeper. Because high availability and resilience mean not just failing over to standby infrastructure resources, but for properly failing over mission-critical workloads (think SQL Server, SAP, Postgres, or industry-specific applications like Meditech), the software needs to understand how those applications work so that they can recover and restart cleanly. Otherwise, when failover occurs, there’s a good chance that workload is not going to be available, or it could be out of sync. When your software is application-aware, failover and recovery is fast and predictable with no API dependencies or last-minute provisioning.

Failover

With SIOS SANless application-aware clustering and replication in place, you can automate real-time failover and achieve the goal of high availability and resilience. Because we’ve chosen a software-based approach, failover occurs in the data plane, so there’s no need to spin up a new instance following an incident. Everything is already running, in sync, and ready. Furthermore, failover is immediate and it’s predictable. That is what you need when dealing with mission-critical workloads. Consider that many of the mission-critical applications you use were not designed to operate in the cloud, so even if your infrastructure is resilient, the application itself represents a single point of failure. Without replication, application monitoring, and real-time failover automation, you risk loss of revenue, security degradation, or worse.

Depending on the size of your enterprise and the industry in which it operates, an hour of downtime can cost $1 million or more, and 90% of organizations report costs of at least $300,000 per hour. Beyond that simple loss of revenue are soft costs associated with reputation damage, lost productivity, missed transactions, and more. Revenue protection is only part of the equation; it is about protecting the business.

Disaster recovery

Any design for high availability and resilience must also take into consideration the risk of a non-IT disaster that disrupts operations. Natural disasters like fires, earthquakes, and floods, or disasters caused by humans like the accidental severing of a trunkline or an act of sabotage conspire to bring operations to a sudden halt. Clustering, replication, and failover all play into disaster recovery, but there are additional considerations that must be addressed. For disaster recovery (DR), you’re going to want geographic distance between your primary site and your DR site to minimize the risk that a regional event doesn’t affect both. That means you’re going to want asynchronous (or near real-time) data replication.

Asynchronous replication is typically only a second or less behind synchronous replication, so it is de facto real-time, but that delay allows you to replicate across higher-latency networks and across longer distances. And because replication is happening continuously, even if you have a local failover between node one and node two, replication to the DR node doesn’t stop. Instead, when node two comes online it becomes the source of the mirror replicating to the DR site and back to node one once it is restored.

Patching and planned maintenance

Beyond the simplicity and cost advantages that come from taking a software-based approach to designing your cloud and hybrid infrastructure for high availability there is another big benefit. You are also better prepared to respond to the increased pressure on rapid implementation of software updates and security patches. No one wants to be the person responsible for taking too long to patch for a vulnerability, but every time you touch a system, you’re introducing the risk of error. That risk is greater when dealing with the cloud where you have less control over the underlying infrastructure, more abstraction, and a lot more moving parts.

In short, patches can break things as well as fix them. They have thus become a significant contributing factor as a cause of downtime. With SANless clusters you’re able to minimize that risk by enabling rolling updates, meaning you can patch a secondary server, verify that the patch didn’t break anything, and then patch the original server where the primary application is still running. If something does break on the secondary server, the primary is unaffected and you can quickly recover to the previous state while you figure out what went wrong. This simplifies the process of executing ad hoc patches and performing planned maintenance, mitigating the associated risks.

An investment in cloud and hybrid infrastructure and services doesn’t have to put IT operations at the mercy of a third party. With the right approach, you can design for high availability and resilience and keep your mission-critical workloads running in the cloud even when things outside of your control go wrong.

—

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.

My current model-selection strategy is embarrassingly simple… and wrong: I choose the most capable (expensive) model because I’m worried the cheaper one might get something wrong. That makes me spend too much, of course, which is why I (like you, perhaps?) continue to struggle with one of the most fundamental challenges in AI: How can I know when a cheaper model is sufficient for a task? Or, really, which model should I use at all?

I asked a friend, Leo Zheng, who leads marketing for Fireworks AI, an AI infrastructure company that runs and improves open-weight models. Surely it was his job to know? His answer surprised me. I thought the answer would come down to models, but it doesn’t. Fireworks, he said, wants to “enable every company to own the continual learning loop within their four walls.” The idea is to abstract away model updates while companies feed the system new signals as customer behavior changes.

That’s when it clicked. I was asking how to automate model choice, but the harder problem is building a feedback loop that tells a company what worked. Model choice then becomes simply one important action the system can take, not the be-all and end-all decision a developer must get right in advance. Arguably, the more important component is integrating enterprise data into that continual learning loop that Zheng describes.

I’ve made that argument before, and I was right. Sort of. Proprietary data doesn’t automatically guarantee AI success. Neither does dumping that data into a retrieval-augmented generation (RAG) system. Your competitors can do the same. The more durable advantage comes from outcome data: traces that connect what the system saw, what it did, and whether the business result was acceptable. Those traces become valuable when a company uses them to improve the system and carry the learning to the next model.

Make the data earn its keep

Public benchmarks are useful, but they only tell you how a model performed on someone else’s test. They can’t tell a bank whether a fraud alert was correct, inform a retailer whether an AI agent resolved a return, or tell a software company whether AI-generated code survived review. Enterprises already have pieces of those answers buried in support transcripts, accepted patches, abandoned carts, etc. The trick is turning that mess into something a system can learn from.

Think about a software company. It already collects product analytics to improve its product. AI can extend that flywheel. Application signals can improve the system powering the product. How? By capturing user intent, engagement, and preferences.

This isn’t foolproof, however. A fast learning loop built on a weak proxy is simply a fast way to make the system worse. For example, suppose Toni in customer support accepts a suggested response. Was it good? Maybe. But what if Toni was rushing (as she is prone to do) and the customer reopened the ticket the next day? It’s not enough to act on inputs alone; a company needs to connect the suggestion to the eventual outcome or risk rewarding the wrong behavior.

Acceptable or ideal outcomes must be defined by the enterprise. A platform like Fireworks can optimize through learning loops, but only if desired outcomes are defined. This changes the cost calculation. After all, the cheapest model by token can be the most expensive model by outcome if people must review, retry, and repair its work. A company can be hemorrhaging money on AI failures while congratulating itself for lowering inference costs.

Open weights get useful

None of this requires open weights, of course. A company can own its evaluations, improve prompts and retrieval, and route among closed APIs and open models without changing a single parameter. For many workloads, that will be enough.

This generally won’t start with reinforcement learning, either. It starts by picking one workflow with an observable outcome and logging the request, model, cost, answer, and what happened next. Do that for a quarter and patterns should emerge. A cheaper model will be good enough for some work, while a proprietary frontier model will earn its price elsewhere. However, in a third category, every model may fail in the same repeatable way, and it’s this last category that makes the serious case for changing the weights.

A few years ago, I argued that open source succeeds when it makes developers’ lives easier, not when it wins an ideological purity contest. The same applies to open weights. The importance of open weights isn’t that they’re a cheaper facsimile of whatever OpenAI and Anthropic are shipping. Instead, they matter because they shift leverage away from the models and toward users with proprietary outcome data. They let enterprises turn what they learn into something they can shape, keep, and carry forward as models change.

Open weights turn model renters into model owners. That’s a very big deal.

For Cursor’s Composer 2, the company started with the open-weight Kimi K2.5 model, then specialized it through continued pretraining and reinforcement learning in environments built to resemble Cursor itself. The interesting thing isn’t that Cursor picked the “right” model, but rather that Cursor can use what it learns from developers to keep making that model more “right” for them. In this case, Fireworks ran the reinforcement learning inference, while Cursor supplied what only Cursor could: its product environment and definition of good. Cursor subsequently built Composer 2.5 on the same Kimi K2.5 checkpoint and says 85% of its compute went into additional training and reinforcement learning.

The base model was the starting point, not the finished product.

This is why open weights matter. They turn the model from a finished product into raw material. The foundation labs have broad knowledge, far more than any normal company could hope to collect. What they don’t know is whether your patch shipped, your fraud was stopped, your customer stayed, or Toni’s response made matters worse. You do.

RAG lets a model consult your data. A learning loop lets the system learn from it. One helps answer today’s question, but the other helps the company answer tomorrow’s question better.

Control must be convenient

Raw weights alone won’t deliver that control. Open source didn’t take over the enterprise because CIOs wanted tarballs. It won because Red Hat, and especially cloud providers, turned theoretical control into everyday convenience. Open-weight AI needs the same translation.

Enterprises want the convenience of a closed API without surrendering control over the intelligence their data creates. That’s the real Fireworks opportunity. Not faster tokens, but a shorter distance between learning something about your customers and making the product smarter because of it. Fireworks CEO Lin Qiao calls this “application-specific intelligence,” and that’s exactly right. Enterprises don’t need to outbuild OpenAI or Anthropic. Even if they wanted to, they couldn’t. Instead, they need to turn what they know about their customers and workflows into intelligence those labs can’t supply.

Fireworks isn’t alone. Together AI also spans training, evaluation, and serving, while Baseten now talks about connecting production feedback to model training. This is becoming a category, not simply a Fireworks feature. Fireworks’ particular bet is that the entire learning loop should belong to the customer.

So, back to the question I was asking Zheng: How do I pick the right model in advance? By now it’s clear: I can’t. Neither can you, and that’s fine, because it’s not really the right question.

Once the enterprise owns the test, it no longer has to trust a vendor’s benchmark or brand. New models must prove themselves against the work that matters to that company, then be promoted, specialized, or discarded accordingly. Model choice becomes a consequence of learning, not an act of faith. In effect, the models audition for the enterprise, not the other way around.

No one can predict whether OpenAI, Anthropic, Google, or the open-weight community will lead six months from now. The sensible response is to stop making that prediction central to the strategy. The enterprise’s own data should decide which model to pick. That’s the bet I find compelling in Fireworks: Make open-weight models as easy to improve as APIs are to call, so enterprises can stop treating their data as context for somebody else’s model and start using it to build intelligence they control.

Microsoft is betting that the integration of HorizonDB, the cloud-native PostgreSQL alternative it is developing, with Azure will attract more enterprise AI and agentic workloads to its cloud services.

Enterprises may not be willing to take that bet.

It’s been nine months since Microsoft unveiled HorizonDB, but the service remains in public preview with no announced general availability date. Why put AI projects on hold waiting for HorizonDB to arrive, when AWS, Google, Databricks, Snowflake, and others already have production-ready PostgreSQL services positioned for the same AI workloads that Microsoft says it is building HorizonDB to handle?

AWS has had the longest head start. Aurora PostgreSQL became generally available in 2017 and has since evolved from a cloud-native PostgreSQL database into an AI-ready service with vector search and integrations with Amazon Bedrock. Similarly, Google’s AlloyDB, which followed in 2022, now includes AlloyDB AI with vector search, embeddings and model interaction for generative AI and agentic applications.

Databricks and Snowflake, too, have their own platform-centric services in the form of Lakebase, which became generally available on AWS and Azure this year, and Snowflake Postgres, which was made generally available in February 2026.

As the latecomer, when Microsoft pitched HorizonDB at Ignite in November 2025 it talked up its new architectural approach to cloud-native PostgreSQL, built around disaggregated compute and storage and a database-as-log design. The hyperscaler also positioned native vector search and deep integration with Foundry and Fabric as key differentiators for AI-heavy workloads.

No reason to wait

Those architectural differences may not be compelling enough for CIOs to wait for HorizonDB to become generally available, though.

“Most enterprises with urgent needs will not wait. A long preview window creates uncertainty around SLAs, pricing, operational maturity, and roadmap confidence,” said David Linthicum, an independent cloud consultant.

And, said Stephanie Walter, practice lead of AI stack at Hyperframe Research, enterprises cannot build mission-critical production plans around an undefined GA date, regional footprint or support commitment.

Given the difficulty of unwinding a poor database choice, enterprises will approach unknown quantities with caution.

“Database platforms eventually become sticky control points. Once the database is connected to the rest of the application, analytics, AI, and governance stack, switching becomes a business transformation rather than just an infrastructure swap,” said Michael Ni, principal analyst at Constellation Research.

In the case of a cloud database, there’s also the unwelcome possibility of “huge egress fees” in case of change, said Bradley Shimmin, lead of the data and analytics practice at The Futurum Group.

All that uncertainty is likely to lead enterprises to restrict HorizonDB to experimental use cases for now, Shimmin added.

Performance anxiety

Analysts also questioned whether HorizonDB’s technical differences will show up in performance benchmarks.

Microsoft has said HorizonDB can deliver up to three times the throughput of open-source PostgreSQL, but makes no comparisons with rival offerings such as Aurora or AlloyDB that it will compete with, Walter said.

The bigger question, according to Igor Ikonnikov, advisory fellow at Info-Tech Research Group, is whether those performance advantages, still largely on paper, translate into a meaningful difference in production.

“A database with a better compute benchmark can still be more expensive once resilience and ecosystem costs are included,” Ikonnikov said.

The economics also point to another HorizonDB limitation, particularly for workloads that are not continuously running, said Advait Patel, senior site reliability engineer at Broadcom.

HorizonDB currently uses provisioned compute rather than a serverless, scale-to-zero model, meaning customers continue to incur compute charges while an instance is provisioned, even if its workload is intermittent or idle, Patel said.

There are developer considerations too.

HorizonDB’s PostgreSQL compatibility does not necessarily mean every existing PostgreSQL application will move cleanly as in its current form the database supports only an approved set of PostgreSQL extensions rather than arbitrary ones, Walter said.

Who should wait?

For enterprises already deeply invested in Microsoft’s Azure ecosystem, those limitations may not be enough to rule out waiting for HorizonDB, Patel said: The chance to integrate the database with AI services and the wider Microsoft stack may outweigh immediate availability, he added.

That calculus also reflects how enterprises typically make database decisions in the first place: not by comparing databases in isolation, but by weighing how well they fit into the broader technology stack, including the cloud platform they have standardized on, Ikonnikov said.

For Azure shops, the choice may therefore be less about moving an existing workload away from Aurora or AlloyDB and more about whether a new Azure workload should start on Azure Database for PostgreSQL today or wait for HorizonDB when it becomes available, he said.

That may be an open question for some enterprises, said Devin Pratt, research director at IDC. “Plenty of organizations are still mid-decision, not locked in,” he said.

Microsoft finally offers a timeframe

Microsoft still won’t say exactly when HorizonDB will launch, with Shireesh Thota, corporate vice president for Azure Databases at Microsoft, saying only, “General availability for Azure HorizonDB is currently targeted for the second half of 2026.”

That narrows it down to a period of a little over four months, including Microsoft’s FabCon and Ignite conferences — an eternity in AI.

For years, AI progress was measured by scale: more data, larger models, and more compute. That formula produced real breakthroughs, but autonomous mobility was one of the first industries to discover its limits.

On the road, AI does not fail quietly. A misread scene, an ambiguous gesture from a pedestrian, or a construction zone that does not match prior examples can create immediate and visible risk. That pressure forced autonomous mobility teams to confront a reality the rest of enterprise AI is now beginning to face: the hardest problem is not access to models. It is reliable ground truth.

As AI moves from pilots into production systems, organizations are discovering that performance depends not only on model capability but on the quality, consistency, and defensibility of the data used to train, evaluate, and improve those systems.

The scaling myth is breaking in production

Early autonomous vehicle development followed a familiar playbook: collect more data, train larger models, and improve performance over time. That approach worked to a point. But real-world driving data does not behave like benchmark data. Road environments are messy and unpredictable. Human behavior is inconsistent. Context changes quickly. Many situations are ambiguous even to trained human observers.

As datasets grew, teams often discovered that they were not simply collecting more signal. They were also collecting more contradictions. Different teams interpreted the same scenes differently. Edge cases accumulated, and ambiguity multiplied. Instead of producing clarity, scale sometimes introduced confusion.

The same pattern is now repeating across enterprise AI. Organizations have access to increasingly capable foundation models, but many AI initiatives still struggle when deployed into production environments. Production exposes weaknesses that benchmarks rarely capture: inconsistent data, ambiguous edge cases, shifting context, and gaps between model behavior and human expectations.

The result is a growing gap between model access and operational reliability. More data is still valuable, but only when it is curated, consistently interpreted, and tied to clear operational definitions. In many production settings, low-quality or inconsistently interpreted data introduces noise faster than models can resolve it.

Real-world AI is multimodal by nature

Autonomous mobility also exposed another reality that is now spreading across AI: real-world intelligence is multimodal. A vehicle does not understand the road through images alone. It must reconcile camera feeds, LiDAR, radar, maps, localization signals, motion history, weather conditions, and human behavior into one coherent interpretation of the scene.

The same requirement is emerging across other high-consequence AI domains. In healthcare, systems may need to connect medical imaging, clinical notes, lab results, and patient history. In agriculture, models may combine satellite imagery, drone footage, soil data, weather patterns, and field observations. In manufacturing and robotics, AI systems increasingly need to reason across video, sensor telemetry, 3D spatial data, maintenance logs, and human instructions.

This raises the standard for ground truth. The question is no longer simply whether an object is correctly labeled in an image or whether a text response is accurate. The harder question is whether the system correctly understands a situation across multiple signals, some of which may be incomplete, noisy, contradictory, or changing over time.

Multimodal AI does not just need aligned datasets. It needs aligned interpretation, and that cannot be engineered into the model after the fact.

Edge cases are not the exception

One of the most important lessons from autonomy is that edge cases are not a small part of the problem. In high-stakes AI, they are the problem.

AI systems often perform well on averages, but real-world systems fail on exceptions. In autonomy, those exceptions may include a pedestrian behaving unpredictably, a construction zone that does not match prior examples, a partially occluded object, unusual road geometry, or an interaction where human intent is unclear. These situations represent a small fraction of total driving events, but they dominate risk.

The same principle applies beyond mobility. In healthcare, it may be a rare presentation of disease. In finance, it may be an unusual transaction pattern. In manufacturing, it may be a combination of operating conditions never previously encountered. In robotics, it may be a physical interaction that looks simple in simulation but behaves differently in the real world.

Organizations often discover that the final increments of reliability require dramatically more effort than the first 90% of performance improvement. This final gap is why many teams find themselves stuck in “hill climbing” — expending enormous effort for increasingly marginal gains.

In multimodal systems, this effect compounds. Each additional sensor stream introduces new edge-case permutations, and reconciling conflicting signals requires expert judgment.

Ground truth must be defensible, not just labeled

Autonomous-vehicle programs that got this right learned that ground truth cannot be treated as static input: a label, a bounding box, or a classification. In the scenarios that mattered, the correct interpretation of a scene had to be reasoned about, reconciled across sensor streams, and defended against alternative readings.

The same standard now applies in other critical settings. A medical annotation may require reconciling imaging findings with clinical context. A financial model’s training data may need to account for regulatory intent, not just transactional patterns. A robotics system operating in an unstructured environment may need ground truth that captures not just what happened, but the chain of causation leading to that moment.

In these cases, ground truth is not simply data that has been labeled. It is data that has been structured, reviewed, and validated through expert judgment. It needs to explain not only what the correct answer is, but why that answer is correct.

This distinction matters because AI systems increasingly operate in environments where being approximately right is not enough. The more consequential the use case, the more important it becomes to create ground truth that is consistent, auditable, and operationally meaningful.

The shift from annotation to judgment

Perhaps the most significant transformation happening in AI today is the evolution of human involvement. The data labeling industry is moving away from simple, crowd-sourced annotation toward more specialized work: scenario design, failure analysis, model evaluation, red teaming, reasoning validation, and edge-case identification.

This work requires people who understand context, ambiguity, intent, and risk. In high-stakes environments, the key questions are not simply whether a system reached the correct answer. Organizations also need to understand why the system behaved the way it did, whether that behavior can be explained, and how to prevent similar failures in the future.

Trust cannot be added through marketing, interface design, or post-hoc explanation alone. It needs to be engineered upstream, embedded throughout the life cycle from data creation to training, evaluation, monitoring, and auditing.

The difference between a model that looks correct and a model that behaves reliably often comes down to whether expert judgment has been systematically incorporated into development.

Software provides scale, and expertise provides judgment. Reliable AI needs both.

What autonomous mobility teaches the rest of AI

Autonomous mobility is often treated as a specialized vertical. It should be treated as an early warning system.

It showed what happens when AI enters environments where the cost of error is high, edge cases dominate risk, multimodal evidence must be interpreted correctly, and opaque decisions are unacceptable. That is exactly where enterprise AI is now heading in healthcare, finance, critical infrastructure, robotics, agriculture, and other high-consequence domains.

The lesson from autonomy is not limited to vehicles. It is that real-world AI must handle ambiguity, edge cases, and multimodal evidence at the same time. Models can generate outputs, but defining what is acceptable remains a human and operational decision.

The next major leap in applied AI will not come from model size alone. It will come from the systems that create, validate, and continuously refine defensible ground truth.

Those systems depend on three things: high-quality data, expert human judgment, and disciplined operational processes. The organizations that recognize this early will have a significant advantage as AI moves from impressive demonstrations to dependable real-world systems.

Autonomous mobility learned this first.

—

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.

Agents have turned up just about everywhere in software this past year, with one conspicuous exception: data. That’s a little odd, because querying data is exactly the kind of structured, checkable task that agents excel at. The likeliest culprit is timing. Large language models have only been reliably good at writing SQL for the last six to nine months, and the field hasn’t caught up to what that unlocks. It’s worth separating two flavors of the idea: agents that do analytics, and agents that help you run the data plumbing. Both turn out to be more useful than they first look.

Data engineering is hard mostly because you’re at the mercy of systems you don’t control. Schemas change without warning. Sources go offline. The API you pull from ships a new version. A column that only ever holds integers starts returning decimals. A field you assumed was unique sprouts duplicates, and the next join detonates into a Cartesian explosion. Records go missing, or come back wrong for an hour and then quietly fix themselves. If nothing ever changed, data engineering would be easy. But as they say, the only constant is change.

The boring work is where agents thrive

Unglamorous maintenance is something agents are genuinely good at. Every data model is a stack of assumptions: this is unique, that’s always populated, these two tables join cleanly. An agent can read those assumptions out of your code and turn them into tests that check whether they still hold. A lot of the fixes are mechanical anyway: a table got renamed, a type got widened, a column moved. An agent can often patch those on its own, and when it can’t, it can still do the legwork, tracing what changed and handing a human a diagnosis and a proposed fix instead of just a 3am stack trace.

Context is the other half of the story, and the context landscape is honestly a mess. Vendors are working hard to convince you that only their semantic modeling language can save you, while it is not entirely clear whether these are necessary or even sufficient. Whether you keep your business logic in a semantic layer like MetricFlow or Malloy, or just in plain Markdown, the goal is the same: get that logic into a form an LLM can use. Context is almost always created by hand, and like all hand-written documentation, it starts drifting the moment it gets written down.

This highlights an opportunity, namely that agents are good at precisely the parts of context that are mechanical and bad at precisely the parts that aren’t. An agent can infer which tables join to which, what values a column tends to hold, what your sales regions are, and which tables people actually query. What it can’t infer is the stuff that was never really a data question: the right way to calculate revenue, what counts as a “customer,” when the fiscal year starts. Those aren’t facts hiding in the warehouse waiting to be found. They’re decisions, often business ones, that a person has to make. What an agent can do is flag the moment one of them quietly stops being true.

Automated agent insights remain a fantasy

The flashier pitch, where agents surface insights you never asked for, is the one I’d bet on last. It sounds wonderful to have hands-free analytics. An agent will keep watch over your data, notice what matters, and drop a dashboard tailored to whatever is happening today. But the bar is high for relevance and false positives can make human users lose confidence.

Deterministic alerting systems have the same problem. People end up turning off alarms because they are too hard to tune. But if humans writing pre-canned triggers have a hard time getting it right, it is going to be hard for agents to do better (at least not before we get some form of super-intelligence). While I’d expect proactive insights to be part of the future, they are still a research prototype at this point.

Here are three concrete things a data team should do to get their stack ready for agents:

1. Lay the groundwork first. Agent use cases that are compelling sit on top of groundwork most teams haven’t laid yet. You don’t need an agent to curate your context until you’ve decided how your context is going to work in the first place.
2. Then go after context. Write a handful of evals, automate them, and then wait to see what breaks. Evals are the load-bearing part. They’re what makes it safe to let an agent near your pipeline at all, because they tell you the instant it gets something wrong.
3. Run on infrastructure that fits how agents behave. An agent goes from zero to a flood of queries in an instant, so you want something that scales up and back down quickly. Agents also fan out, chasing several threads at once, so you need both the headroom and the tenant isolation to absorb a burst. One agent’s curiosity shouldn’t take down everyone else’s ability to run queries.

Latency is a bigger deal than it looks

Latency matters more than you’d expect when you’re using agents. While you might be waiting seconds or minutes for Claude Code to do its thing, it is often running a bunch of tasks. Part of the time that the agent spends is waiting for the LLM, but an increasing amount of time is using other tools, like querying a database. Over time, you can expect LLMs to get a lot faster; you can use smaller models, smarter models, local models, or fancier GPUs. As that happens the tools that an agent uses become the bottleneck.

Picture two engines: one answers in 10 milliseconds, the other in 100. A person won’t notice the difference because both feel near instantaneous, and a person will spend far longer thinking up the next question than either engine spends answering it. What feels instantaneous to an agent is very different, and it doesn’t need to stop and think. When its next query depends on the last result, that 10x gap compounds straight into 10x more work per minute.

One of the ways to make an agent go faster is to take more of their work and run it in parallel. But this also increases load on the systems. You’d want to make sure you have enough parallel capacity and isolation to be able to scale to all of the parallel agent queries at once. Engines tuned for human patience and engines tuned for agent throughput are not the same engines.

The agentic wave is coming whether or not any given team is ready, and the best time to start preparing yourself and your stack is now, before the queries start pouring in. This isn’t just future proofing. The teams that move early are the ones who work out the patterns everyone else ends up copying. A little curiosity now buys a real head start later.

—

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.

Microsoft has unveiled a suite of IQ products over the last few months. Work IQ, Fabric IQ, and Foundry IQ build on what Microsoft used to call its “Graphs,” the underlying data architecture that underpins its cloud services. These graphs provided a way to query the data your business uses, treating that data as nodes in a graph database and using the GraphQL API model to extract that data — for example, to pull data related to a specific individual held across the various Microsoft 365 applications.

The IQ suite follows a similar approach, using the same data, but treating it as the sparse vector store needed to provide grounding data for LLM-based applications. By treating the data as a set of embedding vectors, and integrating it with Model Context Protocol (MCP) servers, Microsoft is giving you the necessary tools to tie LLM output to your data, reducing the risk of hallucination and improving accuracy. Using your own data is a key part of delivering effective agents, ensuring they work within your constraints.

Extending IQ to the web

Web IQ, the latest member of the IQ suite, was unveiled at Build 2026. A modernization of the retired Bing Search APIs, Web IQ is an agent-focused web search tool that builds on the massive Bing search index to provide up-to-date general information for use in your applications.

It may seem a little odd to be talking about a web-wide source of grounding data in the context of a suite of tools that exist to improve the accuracy of your AI applications by providing access to your Microsoft-hosted data. However, in many cases you want to link your agent not only to your data but also to related information from the wider world. For example, an agent powering an ecommerce service could use Web IQ and web-based data sources to provide product comparisons. An agent managing stock levels for a product that is weather-sensitive could use Web IQ as a source of weather data, using Bing’s multiple weather feeds and forecasts.

Just as Google Gemini drew on Google Search, Microsoft Copilot began by using Bing search data to provide grounding for consumer chatbots. It’s easy to take a service like Bing and use it with a LLM, as the nearest neighbor search algorithms use semantic vector similarity techniques to find results that look like your query, ranking them according to their proximity to your search terms.

Microsoft has been tuning its search vector index and the underlying technology stack to work with agents, as agents operate much differently than humans searching the web or querying a chatbot. Providing web search capabilities to agents means having to deal with persistent queries, as the agent hunts for the information it needs, refining queries and applying reasoning algorithms to develop the response it needs. LLM inferencing requires quick responses that deliver large amounts of data, working with queries that go far beyond the one-word or two-word requests that are typical of humans.

More than the training weights

Using Web IQ gives you access to up-to-date information, beyond the training data used to build and weight an LLM. Bing’s crawler works within the standards developed by the search engine industry, obeying meta tags and using its own algorithms to crawl regularly updated websites more often. Bing’s crawler ensures that data is both fresh and being used appropriately, with a focus on quality rather than quantity.

Providing access to web data is only part of Web IQ. Microsoft is using Web IQ to host its own models to manage embeddings, ranking, and content extraction, all running on the company’s global hyperscale platform. The intent here is to use only a limited number of models, to keep the system performance high while aiming to deliver accurate results. The Web IQ models are different from those used to deliver search results to humans, as they’re designed to deliver responses that are suitable for LLMs to use for reasoning.

The underlying search system is based on the DiskANN algorithm developed by Microsoft Research, which allows fast search without requiring enormous amounts of in-memory data access. This approach has been extended to manage information retrieval at scale, building on Microsoft’s distributed systems architectures, to support the demands Microsoft is seeing from agent-based systems. At the same time, it must respond to the rapidly changing economics of inference, where token costs now demand the best possible output from the fewest tokens.

To meet those economic demands, the Web IQ platform doesn’t deliver whole documents to querying agents. Whole documents can lead to expensive inference further down the chain, as LLMs process results repeatedly to drive the agent workflow. Instead, Web IQ structures the information retrieved from the underlying search engine data, delivering what Microsoft calls “structured evidence objects” as well as passage-level information from unstructured text documents. This should result in a much higher signal-to-noise ratio than simply querying a search engine, with a focus on delivering information that lets agents work using fewer tokens.

Using Web IQ in your agent code

The API for Web IQ is a standard REST call, delivering a request object to the Web IQ endpoint. Along with your API authorization key, you will send a query, a set of parameters that control the number of results returned, the language and region used, and the maximum size of the responses and the format used. Responses can be returned in text, HTML, or markdown formats, as well as extracted passages that are selected for context. All other options return the full document, so can be more expensive to use. Markdown is an interesting alternative, as it can be used as the basis for giving agents semantic memories.

Results include important contextual and citation information, including web page titles and URLs, as well as data about when the site was last crawled and how stale the underlying information is. This can be used to improve grounding and provide more information that can be included in formatted responses — much in the same way as Bing’s Copilot displays context in the form of footnotes in its responses.

Responses to video searches include text descriptions. If these aren’t provided as part of the original web content, they will be generated by an LLM. The same approach is used for image searches, with both offering the same contextual cues as the web search API. If you don’t care about the type of data being returned, you can choose a “classic search,” which will return text, images, video, and news.

Supporting autonomous agents

Microsoft provides LLM-ready documentation for the Web IQ service, with an llms.txt file and an OpenAPI description. These allow AI tools to discover Web IQ capabilities and include them in workflows as part of autonomous operations, so that agents and other AI applications can implement grounding calls to Web IQ whenever user interactions require them. The API descriptions include errors as well as the structure of a standard 200 response.

As Web IQ is designed for use by modern agent frameworks, the Web IQ API is available through an MCP server. The Web IQ MCP server exposes tools that map to API calls: web, videos, news, and images. They also include a browse option, which lets you pull content from a target URL. The service can be configured with a standard JSON file and requires an API key to control access and manage billing. If your account doesn’t have access to a specific tool, then it won’t be available from inside the MCP server.

If you’re building an agent and you want to evaluate the Web IQ MCP server, it can be added to common coding agents, such as the GitHub Copilot CLI. You can then test it out using familiar tools and generate code that can be dropped into applications via your choice of development tooling. Queries sent to the Web IQ MCP server use the same syntax as REST calls, without having to construct the calls yourself. Working with the MCP server allows you to connect Web IQ to your choice of agent framework, relying on its built-in MCP methods to reduce the code and maintenance overhead.

Web IQ is not for human interactions; Microsoft provides an alternative “Grounding with Bing” service for chatbots. Instead, Web IQ is a tool for agents, providing necessary background information that helps keep results fresh and relevant. It’s easy to use, fast, and, above all, cheap, which makes it an ideal tool for modern inference platforms built around Microsoft Azure’s AI tooling.

AWS is finally adding native vector search to its managed NoSQL database DynamoDB, which is typically used to store high-volume operational and transactional data.

The update, according to analysts, removes complexity for development teams that are trying to maintain separate vector databases for a rapidly growing class of AI and agentic applications that rely on real-time access to operational and transactional data to improve the accuracy and relevance of their responses.

“This collapses a common two-database architecture into one operational data layer. Developers can update an item and its vector representation together, use familiar DynamoDB APIs, and avoid building a separate synchronization pipeline. That should materially shorten time-to-market for AI features built around existing DynamoDB data,” said Stephanie Walter, practice lead of the AI stack at HyperFRAME Research.

Prior to the update, enterprises using DynamoDB typically had to copy data into OpenSearch or another vector database, such as Pinecone and Weaviate, often using DynamoDB Streams or custom pipelines, which meant operating two data layers and managing embedding generation, backfills, retries, schema changes, security policies, and synchronization, Walter noted.

That dependence on two separate data layers, Walter pointed out, added to query latency and increased the risk of the vector index lagging behind the operational record.

Such delays, according to Ashish Chaturvedi, executive research leader at HFS Research, can have real consequences for AI agents: “If an agent is acting on what it retrieves, a synced-five-minutes-ago copy can mean a confident wrong action.”

Beyond improving data freshness, eliminating a separate vector database could also lower cloud and operational costs, Chaturvedi said: “Maintaining a second database meant paying at least $700 a month for a second database regardless of usage.”

For CIOs, those benefits combined could translate into lower total cost of ownership and simpler governance as enterprises scale AI applications, Chaturvedi added.

“It is a real consolidation for CIOs: fewer systems to secure, no pipelines to maintain, fresh data. Add to it usage-based cost, which means no standing minimums for idle infrastructure, even at trillion-vector scale,” Chaturvedi noted.

The architectural simplification could also make AI adoption easier for business leaders by eliminating the need to staff and govern a second data platform, said Michael Leone, principal analyst at Moor Insights & Strategy.

Native vector search capabilities have been gaining popularity over the past few years. Over the last three years, AWS has steadily expanded vector search across its database portfolio, adding support to Aurora PostgreSQL through pgvector, Amazon MemoryDB for Redis and Amazon DocumentDB as enterprise demand for generative AI applications has grown.

Rivals have followed a similar path, with MongoDB, Microsoft, Google Cloud, Oracle and Couchbase integrating native vector search into their databases to support retrieval-augmented generation (RAG), AI agents and other generative AI workloads.

These announcements themselves reflect a broader convergence in the database market since the rise of generative AI. While specialized vector databases have expanded beyond similarity search by adding SQL, NoSQL and operational database capabilities, mainstream operational databases have been embedding vector search and RAG capabilities into their core platforms, allowing enterprises to consolidate AI and transactional workloads on fewer data platforms.

AWS has not shared details on the rollout of DynamoDB’s native vector search capability, including its availability timeline or the AWS Regions where it will initially be offered.

AI agent orchestration platforms coordinate role-based and task-based AI agents, along with the tools, data, and people they depend on, into multistep workflows. These platforms are highly important for organizations scaling from handfuls to thousands of AI agents running in production.  

Two open standards do the connective work: MCP (Model Context Protocol) gives agents governed access to tools and data, while A2A (Agent2Agent) lets agents discover and delegate to one another, including agents built on other platforms. The orchestration layer sits on top, adding the routing, shared state, guardrails, governance, security, and observability needed to run workflows that range from fully autonomous to human-in-the-loop.

AI orchestration platforms may be the hottest AI technology of the year. In researching this article, I identified more than 60 commercial and open source platforms that businesses can use as a control plane to manage work between AI agents, people, and automations.

Like data fabrics and automation platforms, I suspect enterprises will utilize more than one AI agent orchestration platform. Platforms are being released by hyperscalers and solution providers in enterprise SaaS, process automation, customer experience, data management, AIops, and IT infrastructure. Development-centric platforms include open source, commercial, and no-code integration solution providers.

Here are five considerations when reviewing AI agent orchestration platforms.

1. Observable control, oversight, and trust

AI agent orchestration platforms are non-deterministic and leverage AI capabilities to coordinate responses and actions across AI agents. One area to evaluate is how administrators implement controls and guardrails over which AI agents can coordinate with others and under what circumstances. Additionally, platforms should also have controls on when and where people should be involved before taking action.

“CIOs should focus on how the AI orchestration platform clearly applies controls over autonomous decision-making,” says Heather Richards, global vice president of go-to-market strategy at Verint. “Ideally, the platform makes it easy to define who or what can take actions, how decisions are approved, and where accountability sits when something goes wrong. If orchestration doesn’t have built-in governance, visibility, and human override, it will scale risk faster than it scales value.”

Observable AI agents are primary capabilities for tracing how they interact and where decisions are made. But even more important is to review how platforms govern access to the context layer, which can include retrieval-augmented generation (RAG) for language models, knowledge graphs, and semantic layers.

“When evaluating an AI orchestration platform, organizations should consider whether governance and observability were built into the architecture from day one,” says Caitlin Schuman, director of AI strategy and customer innovation at Presidio. “A strong platform should make it clear what context is being used and should have a control layer that routes work across systems, agents, and humans.”

Deploying trustworthy AI agents is important for gaining employee adoption. Charles Crouchman, chief product officer at Redwood Software, suggests evaluating how an AI agent orchestration platform establishes trustworthy operations with enterprise resources. He recommends asking these five questions:

• Can it connect to the systems actually running your business?
• Can it be trusted to execute mission-critical logic across your ERP, supply chain, and finance platforms?
• Does it provide deterministic guardrails for non-deterministic AI, so agents can’t go rogue in production?
• Is it model-agnostic, so you’re not locked into a single LLM or agent framework as the landscape shifts?
• Can you govern at scale with full audit trails, observability, and accountability?

“Validating these answers moves you from disconnected AI  reasoning to real execution, empowering you to take the next step towards an autonomous enterprise,” says Crouchman.

2. Secure and resilient operations

AI agent orchestration platforms centralize a growing number of operational workflows, so it’s important to evaluate whether their security, performance, reliability, and resiliency meet compliance and non-functional requirements.  

“Deploying agents is the easy part; the hard part is ensuring they operate safely, consistently, and in coordination with the people and systems around them,” says Daniel Meyer, CTO at Camunda. “Orchestration platforms should enforce controls between an agent’s decision and its action, handle long-running processes without losing state, and maintain a full audit trail natively.”

Organizations should also consider how platforms support agentic ops practices for identity management, monitoring, AI agent accuracy, and incident management.

“Don’t just seek solutions that coordinate workflow or handle the life cycle of an agent; also seek solutions that get the answers agents need faster, with more accuracy, all while meeting essential security and compliance requirements,” says James Urquhart, field CTO and technology evangelist at Kamiwaza. “A platform that securely coordinates context gathering and result formulation across widely disparate infrastructures and data sources is essential, not only to the performance of AI in the enterprise, but also to its agility.”

3. Integrated testing and feedback

Testing AI agents requires validating changes before deployment, just as with continuous testing for applications and APIs. But it also requires evaluating prompts, responses, and actions in production and ensuring that agents aren’t drifting from expected parameters or going rogue. One area in which AI agent orchestration platforms differ is how they support testing AI agents, monitoring them in production, and providing a centralized source of feedback to support accuracy improvements.

“When selecting an AI orchestration platform, don’t overlook where the software it produces actually gets tested and validated,” says Jean-Philippe LeBlanc, senior vice president of engineering at CircleCI. “AI can accelerate every stage of development, but without rigorous, automated validation integrated into the delivery pipeline, you’re compounding risk at the same rate you’re compounding velocity.”

Armando Franco, senior director of cloud and platform modernization at TEKsystems Global Services, says, “The criterion that actually matters is whether continuous outcome evaluation is a first-class capability of the platform itself, because without it, iteration speed collapses and the program stalls.”

4. Interoperability and open standards

MCP and A2A are two ways AI agent orchestration platforms support open standards and enable connecting to an ecosystem of agents. Many platforms also allow developers to select and replace the underlying AI models and to choose from a range of AI code-generation tools. These flexibilities ensure teams can optimize around performance, accuracy, compliance, costs, and other future considerations.

“When evaluating an AI orchestration platform, we look first at composability and interoperability,” says Rajesh Arora, chief data and analytics officer at Principal. “The real test is not how many features it offers today, but whether it can connect models, data sources, agentic solutions, and workflows in a way that adapts to our AI strategy, tech stack, and changing business needs.”

Other interoperability criteria to review include the platform’s AI agent cataloging capabilities, how permissions are configured dynamically, and whether prebuilt connectors are available for the required integrations.

5. Vendor viability and road map

Leaders recognize that AI is currently reshaping business more than driving transformation. To be successful, organizations require AI governance that keeps up with strategy and doesn’t lag too far behind. The same is true for AI agent orchestration platforms, so it’s important to review their release notes and road maps to see whether providers strike a reasonable balance between innovation and governance.

“The right orchestration platform provides a unified policy layer that follows work across agents, workflows, and AI tools, enabling your teams to build freely while IT and security maintain full visibility at the action and output levels,” says Brandon Sammut, chief people and AI transformation officer at Zapier. “If your governance can’t keep pace with how fast your people are building, you’ll either slow them down or lose sight of what they’re building.”

Since AI agent orchestration platforms are a new category, technology leaders should partner with their financial, legal, and compliance colleagues to assess vendor viability risks. In addition, reviewing customer adoption and support capabilities is important as top solution providers will continue to evolve their platforms.   

“A mature provider offers both a stable platform and the customer support you’ll need, and with a large customer base, they’ve already hit countless edge cases that can smooth your own implementation,” says Hannes Hapke, director of the 575 Lab at Dataiku. “Assess maturity by looking at funding and financial backing, the clarity and consistency of their public road map, and the size and activity of their community. An engaged user base, active forums, and a healthy ecosystem of integrations all signal a provider that will still be standing when you scale.”

Many organizations are still early in adopting AI agents and transitioning proofs of concept into production. But for those deploying a growing number of AI agents across many platforms, selecting an AI agent orchestration platform enables scaling workflows, operations, and governance. 

SnapLogic has introduced its new SnapGPT, an agentic assistant that helps enterprise teams plan, build, understand, and operate integrations through natural language.

Unveiled July 28 and described as the company’s most-significant advancement in SnapGPT since 2023, the new SnapGPT evolves from an AI-powered integration copilot into an agentic assistant for the integration life cycle, combining platform intelligence, integration-specific reasoning, and operational guidance to help teams move from business intent to production faster, according to SnapLogic. SnapGPT combines agentic planning, integration-specific reasoning, pipeline execution validation, and more than 15 years of enterprise integration expertise built into the SnapLogic Agentic Integration Platform, including platform intelligence, operational context, and proven integration patterns, the company said.

SnapGPT now helps teams across the entire integration life cycle:

• Plan – Plan Mode helps teams validate requirements, explore implementation approaches, refine workflows, and identify potential issues before development begins.
• Build – Generate high-quality, production-ready integrations through integration-specific reasoning and pipeline execution validation, while accelerating development with multi-pipeline generation, intelligent pipeline refactoring, reusable expression libraries, and natural-language generation of SnapLogic MCP Servers.
• Understand – Analyze existing integration assets, explain pipeline logic, and surface contextual insights to help teams better understand and improve complex integrations.
• Operate – SnapGPT Activity Log provides administrators with visibility into AI-assisted development activity, while SnapGPT Monitor Insights extends AI assistance into production operations with diagnostic intelligence and AI-powered troubleshooting.

The new SnapGPT is available as part of the SnapLogic Agent Integration Platform. In June SnapLogic introduced the SnapLogic MCP Builder, a template-based tool that generates Model Context Protocol servers from existing integrations.

Microsoft has had a narrow escape from total embarrassment: A security company uncovered a critical vulnerability that could have compromised all Azure Cosmos DB databases — both those of customers and Microsoft’s own.

Google subsidiary Wiz found a flaw in the database’s Gremlin API, usually used for storing and managing property graph data.

If bad actors had discovered it first, they could have exploited it to acquire what Wiz called the Cosmos Master Key, which would have enabled them to use the primary key of any Cosmos database, resulting in read and write access to any account. They would also have had access to a list of every database on the service, with identifiers such as subscription and tenant IDs.

Azure Cosmos DB is a NoSQL database that underpins Microsoft’s cloud services. It can be accessed through SDKs for framework such as Python, Node.js, Java, and .NET.

Wiz described how it discovered the vulnerability in a blog post. It disclosed details of the flaw to Microsoft in November 2025.

Microsoft deployed a hot fix within two days, but it took another eight months to re-engineer the infrastructure, removing the Cosmos Master Key and introducing new guardrails to Cosmos DB to prevent similar attacks.

It is not the first time Cosmos DB customers’ primary keys have been under threat: In 2021, Wiz found a flaw in data exploration tool Jupyter Notebook that could be exploited to access the database keys and other secrets.

This article first appeared on CSO.

Oracle on Tuesday described new EBCDIC character set compatibility features in Oracle AI Database for customers transitioning from legacy databases on IBM mainframes.

In its post, Oracle noted that EBCDIC compatibility has historically been one of the top technical challenges for enterprises re-platforming to use newer, ASCII-based databases while continuing to use proven legacy applications.  

“Achieving this goal requires more than simply moving data. It requires preserving the EBCDIC compatibility on which existing applications depend,” wrote Michael Yau, VP for Oracle Database Globalization Engineering. The feature rollout “addresses two fundamental challenges of preserving EBCDIC compatibility: accurate character encoding conversion and preservation of EBCDIC binary ordering.”

He added: “These client character sets implement IBM Character Data Representation Architecture (CDRA) code page definitions, providing source-to-target character mappings that are compatible with IBM’s published standards. This enables accurate and predictable character encoding conversion during data migration and subsequent database client/server communication.”

Yao observed that this is important because these mainframe migrations can be very complex.

“Many legacy EBCDIC applications, such as those written in COBOL, implicitly rely on the EBCDIC binary ordering defined by IBM EBCDIC code pages. SQL predicates that compare character values, perform range searches, or sort query results often assume this ordering,” he wrote. “After migration to an ASCII-based Oracle AI Database character set, these same SQL statements can produce different results, not because the data changed, but because the database’s default binary ordering follows that of the ASCII-based database character set rather than the source EBCDIC code page.” 

Compatibility repair, not modernization

While consultants generally applauded the new features, some questioned whether this will simply shift enterprise dependency on IBM to dependency on Oracle. 

Sanchit Vir Gogia, chief analyst at Greyhound Research, is one of the fans.

“Oracle has repaired one of the oldest silent faults in mainframe migration: EBCDIC ordering, the muscle memory of the legacy estate. Preserve the data and lose the ordering, and a query returns the wrong record while every dashboard stays green,” he said. “The application runs and the query completes. The answer is simply wrong.”

Gogia noted that the new feature is “not a modernization suite. It is a compatibility repair, narrow and genuinely useful, which CIOs who have bled on past migrations will read with equal parts relief and suspicion.”

AJ Thompson, CCO at UK IT consulting firm Northdoor, agreed that the Oracle announcement addresses a genuine technical barrier rather than just being a marketing gimmick, so it is worth taking seriously as a re-platforming enabler. “The two problems it solves, EBCDIC to ASCII character conversion and preserving EBCDIC binary sort ordering, have historically been real blockers for allowing COBOL to move away,” he said.

But, he cautioned, CIOs must also take resiliency challenges seriously. “Mainframes are not chosen primarily for character encoding, they are chosen for benefits like decades of proven uptime, IBM Z’s redundancy architecture, and workload isolation,” he pointed out.

“Oracle’s announcement solves a data compatibility problem, not a resilience or availability one. A client with genuinely mission-critical, zero-downtime workloads will still need convincing on the availability and disaster recovery side before moving [to the cloud], and Oracle’s own resilience claims would need scrutiny on their own merits, quite separate from this EBCDIC work.”

Leverages IT desperation

Mike Wilkes, enterprise CISO at Aikido Security, added that Oracle is leveraging IT desperation to squeeze long-term value from legacy systems. 

“I have always believed that Oracle will own the very last white-knuckle-grip workloads that migrate from on-premises data centers into the cloud,” he said. “This announcement certainly demonstrates that they understand their position in the world of cloud service providers. They are not the biggest, they are not the oldest, and they are not the most technically advanced. But they do own the market share for the trailing edge of cloud adoption.”

He pointed out that the greatest barrier to cloud migration is not containerizing modern applications, it is the decades of business logic buried inside COBOL applications and EBCDIC-encoded data.

“Oracle’s EBCDIC compatibility features acknowledge a practical reality: organizations are not rewriting these systems from scratch,” he said. “If Oracle can reduce the cost, risk, and operational disruption associated with moving those workloads, the announcement represents meaningful value for IT teams that have been delaying modernization because the migration path was simply too complex or too expensive.”

Could cause vendor lock-in

Then again, Wilkes noted, there is the potential for increasing vendor lock-in.

“Compatibility layers almost always increase long-term dependence on the platform providing them,” he said. “Rather than eliminating legacy technology, they abstract it behind Oracle’s database and cloud ecosystem, making future migrations potentially more difficult. Enterprises should view these tools as transition accelerators rather than permanent architecture.”

Thus, he said, if they use the opportunity to gradually modernize applications and data models, there is substantial value, but if they simply relocate technical debt into Oracle Cloud, they may find that they have exchanged one form of legacy lock-in for another.

Easier, but not easy

Matt Kimball, VP and principal analyst with Moor Insights & Strategy, also saw the Oracle move as a good one, but stressed that while it should make things easier for organizations, re-platforming still won’t be easy because EBCDIC migration isn’t just a character-conversion exercise. However, “Oracle’s built-in character-set support and EBCDIC collations move part of that compatibility burden into the database, making it easier to preserve existing application behavior,” he said.

Ishraq Khan, CEO of coding productivity tool vendor Kodezi, agreed. 

“One of the biggest obstacles to leaving mainframes is decades of applications built around EBCDIC encoding and legacy data formats. If these compatibility features reduce the amount of code that needs to be rewritten, they can lower migration risk, cost, and implementation time,” Khan said. But, he added, organizations should also consider whether these features simply make migration easier, or make future moves more difficult.

This article originally appeared on CIO.com.

For years, the public cloud was the default for new workloads because its convenience, elasticity, and breadth of services made sense. However, as AI’s strategic importance grows, its economics and infrastructure are changing. Tesla is one of the clearest examples of a company deciding that AI is too important, too expensive, and too central to its business to leave largely in the hands of a third-party cloud provider.

 At the center of Tesla’s strategy is a simple idea. If AI is key to how you build your products, run your business, and define your future, the infrastructure that powers AI becomes a strategic asset. It is no longer just plumbing but part of the product itself. Tesla’s models, databases, applications, and workflows increasingly rely on infrastructure that is built, hosted, and managed by Tesla. That means the company has direct control over the hardware, the software stack, data movement, performance tuning, and security posture. For a company that depends on AI to support autonomy, robotics, manufacturing intelligence, and future product direction, that control matters.

This is the real heart of the matter. Tesla is not treating AI as a side project or a feature layer added on top of an existing business. AI is central to Tesla now and into the future. It is a force multiplier, but more than that, it is an essential aspect of product development, operational efficiency, automation, and competitive differentiation. Once a company reaches that level of dependence on AI, the conversation around infrastructure changes very quickly.

Public cloud is attractive because it provides a complete AI ecosystem on demand. You can provision compute, storage, training environments, managed services, orchestration tools, and deployment pipelines without building much yourself. That is why I often call public cloud “the easy button” for AI. It is fast, convenient, and feature-rich. But convenience comes with a premium, and for many companies moving deeply into AI, that premium is becoming very hard to justify.

Cost is driving AI out of the cloud

One of the biggest forces driving this shift is price. Many enterprises moving into AI are shocked by what public cloud providers charge for AI infrastructure. Training clusters, inference engines, storage, networking, observability, and support services all add up quickly. What begins as a convenient path to experimentation can become an extremely expensive operating model when AI moves into production at scale.

In my experience during the past 15 years, public cloud is often at least twice as expensive as comparable private infrastructure for sustained workloads. That is not true in every case, and it depends heavily on utilization patterns, architecture, and operational maturity. However, for large, predictable, always-on AI workloads, public cloud economics often become difficult to defend. The markup associated with convenience, elasticity, and managed ecosystems is substantial.

In response, companies are increasingly exploring alternatives. Some are moving toward neoclouds that specialize in AI infrastructure. Others are evaluating sovereign cloud options for control, locality, or compliance reasons. Many are revisiting private cloud infrastructure for the most strategic and cost-intensive workloads. Tesla is becoming the poster child for how successful that approach can be when a company has the scale, the sophistication, and the long-term commitment to execute it well.

Control, governance, and security

Cost is only one part of the equation. Control is the other major driver. When Tesla runs its AI infrastructure on equipment it owns and operates, it gains much tighter control over performance, data handling, workload placement, governance models, and operational priorities. That matters a great deal when the workloads involved are mission-critical and directly connected to the future of the company.

A privately controlled AI environment can provide better security because the organization has direct oversight of the infrastructure stack. It can provide better governance because data, models, and workflows remain inside systems the enterprise fully controls. It can also improve reliability and performance tuning because engineering teams can optimize specifically for their own AI pipelines rather than adapting to the generalized patterns of a shared cloud environment.

Of course, many people are quick to point out that running your own private infrastructure comes with significant labor and cost. They are not wrong. Building and operating private AI infrastructure requires capital, engineering skill, facilities, procurement discipline, operational excellence, and long-term commitment. This is not a shortcut, nor is it easier than public cloud. In many ways, it is harder.

However, the point is that for sophisticated companies with large-scale, steady-state AI needs, it can be worth it. Better control, better governance, better security, and ultimately lower cost can justify the additional operational burden.

The future of AI infrastructure

What makes Tesla so important in this discussion is that the company chose this route because AI is inseparable from its business strategy. Many other enterprises are heading in this same direction. As AI becomes less experimental and more operational, the infrastructure conversation shifts from convenience to economics, control, and differentiation.

Not every company should follow Tesla’s path. Many enterprises are not ready to build, host, and manage their own AI environments. Many lack the scale to justify it. Many still benefit tremendously from the agility of public cloud. But for organizations where AI is becoming central to products, services, and competitive advantage, Tesla’s strategy is increasingly relevant.

There are three things every enterprise should think about when considering ownership of its own AI infrastructure:

• First, understand the operational burden in full. Private AI infrastructure requires teams, processes, facilities, and discipline that many organizations underestimate.
• Second, know the economics of your workload patterns. If AI demand is large, steady, and strategic, the cost advantages of ownership may be compelling.
• Third, think beyond cost alone and focus on control. If AI is core to your future, owning the infrastructure may offer strategic benefits in governance, security, optimization, and long-term independence that public cloud cannot easily match.

Tesla’s strategy is not for everyone, but it is a persuasive example of what happens when a company decides that AI is too important to rent forever. Public cloud remains the easy button, and for many organizations, that will be enough. But for companies that see AI as fundamental to how they will compete, private infrastructure may turn out to be the smarter choice.

Oracle’s July 2026 Critical Patch Update, its largest ever, contains 1,449 new security patches spanning 32 product families, from Oracle Database and E-Business Suite to PeopleSoft, GoldenGate, Java SE, and Fusion Middleware.

Fusion Middleware was particularly hard hit, with new security patches for 355 security vulnerabilities, 219 of them remotely exploitable without authentication, meaning they can be exploited over a network without requiring user credentials. Ten of them scored a “perfect” 10.0 on the Common Vulnerability Scoring System (CVSS).

These included easily exploitable vulnerabilities allowing unauthenticated attackers with network access via HTTP to compromise Oracle Data Integrator, Oracle Access Manager, Oracle HTTP Server, Oracle Platform Security for Java, Oracle WebCenter Content, Service Delivery Platform, or Oracle Weblogic Server Proxy Plug-in,

No other products were found to have quite such extreme vulnerabilities, but there were plenty of others scoring almost as badly.

Two critical flaws in Oracle Database Server

The most severe flaw Oracle patched in its flagship database product is CVE-2026-61211, a vulnerability in the RDBMS component’s DBMS_CLOUD package with a CVSS score of 9.9.

This easily exploitable vulnerability allows a low-privileged attacker having Execute DBMS_CLOUD privilege with network access via Oracle Net to compromise the RDBMS, Oracle said in the patch update statement. “While the vulnerability is in RDBMS, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of RDBMS,” it warned.

The flaw affects Database Server versions 19.3 through 19.31 and 23.4.0 through 23.26.2.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said the 9.9 score should be read as serious but conditional. Exposure depends on configuration, he said: On customer-managed databases, DBMS_CLOUD is absent until installed, and grants and network access lists determine the radius from there. “Where DBMS_CLOUD is broadly granted and reachable, the emergency is real and the window is seventy-two hours; where it is absent, the accelerated database wave will do.”

Vibhum Dubey, a cybersecurity researcher and red teamer, said the flaw stood out to him because it checks several boxes that concern defenders.

“Database servers often hold an organization’s most valuable data, so even if exploitation is not publicly observed yet, I don’t think this is the kind of issue you leave until the next routine maintenance window if your environment is exposed,” Dubey said.

A second Database Server flaw, CVE-2026-47040, affects Connection Manager in Oracle Net Services, is remotely exploitable without credentials. Oracle’s risk matrix lists six Database Product vulnerabilities in this cycle as reachable over a network with no authentication required, the statement added.

CVE-2026-7383, an OpenSSL-related TLS vulnerability, affects two products, Database Server and Autonomous Health Framework, since both bundle the same third-party component. Oracle’s advisory notes the Database Server patch for that CVE also resolves 19 related OpenSSL CVEs bundled into the same fix.

Oracle GoldenGate received 27 new patches, nine of which do not require authentication to exploit, including CVE-2026-2332, a flaw in the Big Data and Application Adapters component tied to Eclipse Jetty, the statement added.

There were also two critical flaws in Oracle’s TimesTen in-memory database.

The remainder of the release spans E-Business Suite, WebLogic Server, PeopleSoft, Siebel, JD Edwards, Communications, Retail Applications, Utilities Applications, MySQL, Solaris and VM VirtualBox.

Volume repair

Gogia said the volume itself marks a shift.

“At 1,449 patches, against 481 in April 2026 and 309 a year earlier, patch load has outgrown the queue built to hold it,” he said. He recommended a tiered response: “The reachable and the reported inside seventy-two hours, the trusted core inside ten days, the rest by risk before the October release.”

He also flagged a specific risk in how organizations might triage E-Business Suite. “Oracle’s advisory concedes that E-Business Suite exposure sits partly in underlying Database and Fusion Middleware versions outside the E-Business Suite matrix. The fastest way to mis-prioritise this release is to patch by product logo instead of trust boundary.”

Third Tuesday, quarterly cycle

The July release is the third quarterly Critical Patch Update of 2026, and the first since the introduction in May of the monthly Critical Security Patch Update program.

Gogia said Oracle has effectively layered a second cadence on top of the existing one rather than replacing it.

“Quarterly Critical Patch Updates remain and stay cumulative; monthly Critical Security Patch Updates now sit on top,” he said, adding that enterprise adoption of the new rhythm remains low because of “certification obligations, regression exposure and scarce specialist hours.”

Dubey made a similar point about organizational readiness: “In large enterprises, patching is rarely a technical problem. It is an operational one. Database administrators, application owners, infrastructure teams, business stakeholders, and change advisory boards all have to align.”

Niyati Daftary, principal analyst at Gartner, said the release underscores a broader shift in how patching is approached.

“Patching is no longer a race to remediate every vulnerability. It is a discipline of identifying the exposures that matter most and reducing business risk as efficiently as possible,” she said, adding that organizations should prioritize based on exposure, business impact and exploitability, starting with internet-facing assets and mission-critical systems.

Daftary pointed to continuous threat exposure management and adversarial exposure validation as increasingly relevant frameworks, since CVSS scores “measure theoretical severity rather than actual enterprise risk.” Patching alone will not be sufficient, Daftary said, and organizations should continue investing in defense in depth, including behavioral threat detection and incident response.

Oracle’s next cumulative Critical Patch Update will come on Oct. 20, 2026, with smaller Critical Security Patch Updates on Aug. 18 and Sept. 15.

This article first appeared on CSO.

Oracle is expanding its Cloud@Customer on-premises portfolio with a managed database offering that it says will enable enterprises to run databases, applications, and AI agents in their own data centers, helping CIOs modernize mid-sized workloads while meeting data residency, regulatory, and low-latency requirements.

The hybrid cloud offering, Base Database Cloud@Customer, combines existing database and infrastructure services such as the Base Database Service and Data Infrastructure Cloud@Customer X11 platform. It is designed for enterprises that do not need the scale of Exadata Cloud@Customer but still want their infrastructure and AI capabilities on-premises, managed by Oracle, the company said.

The Cloud@Customer X11 platform itself consists of two Oracle X11 compute servers and shared all-flash storage, offering up to 60 usable processor cores and 660 GB of memory per server, 47.2 TB of storage, and 10/25 GbE networking.

For regulated industries or restricted connectivity

Analysts see the new offering filling a gap for enterprises that want the operational and economic benefits of the cloud but cannot send their data to a public cloud because of legal restrictions or technology limitations.

These enterprises, according to Ashish Chaturvedi, executive research leader at HFS Research, are likely to be in regulated industries such as financial services, healthcare, government, and defense that must comply with data residency requirements, or needing low-latency access from remote sites to operational databases.

The offering could also appeal to enterprises modernizing mid-sized workloads at remote locations or within individual business units that could never justify the investment in a full Exadata rack, said Amit Chandak, chief analytics officer at IT consulting firm Kanerika.

In all cases, Chaturvedi said, the appeal of the offering is its managed nature, which takes away the burden of looking after the underlying infrastructure.

Deployment and maintenance becomes easier too, said Michael Leone, principal analyst at Moor Strategy and Insights: “They get automation that mid-size teams rarely have the staff to build. Clustering, patching, standby databases, and backups arrive configured instead of hand-assembled because the offering is managed.”

The economics are equally compelling, Chaturvedi said. The pay-as-you-go pricing model, combined with online compute scaling, helps enterprises avoid overprovisioning and paying license fees for idle cores, which is a “classic waste” of fixed on-premises systems, he said.

Private AI behind the firewall

Beyond the operational and economic benefits, the architecture of the new offering enables databases, applications, VMs, and AI agents to be collocated on the same platform, removing what Chaturvedi called “the single biggest blocker” to AI adoption in regulated environments: the need to keep private data behind the firewall.

“For a CIO in a regulated sector who wants to deploy AI agents but can’t let regulated data touch an external model API, that’s a real unlock,” Chaturvedi said.

More so because most AI offerings, at least in their present form and state, cannot guarantee sensitive data protection, said Igor Ikonnikov, advisory fellow at Info-Tech Research Group.

Even if Base Database Cloud@Customer turns out more expensive than fully cloud-based options, “It’s still attractive as it eliminates reputational and economic risk caused by possible AI-induced data leakage,” Ikonnikov said.

The offering’s consolidation of databases, applications, and AI agents will also simplify deployment of AI-based workflows, said Forrester principal analyst Noel Yuhanna. “It reduces stack complexity and helps accelerate development cycles, deliver real-time data, and eliminate data movement challenges.”

Despite those advantages, Chandak cautioned that the offering is unlikely to see broad adoption outside Oracle’s existing customer base: “If a company isn’t already on Oracle, the pull is weak. You don’t buy into Oracle’s database just to get this.”

Enterprises seeking similar hybrid cloud capabilities have no shortage of alternatives: AWS, Microsoft, Google Cloud, IBM, Dell Technologies, and HPE all offer combinations of on-premises infrastructure, cloud management, and AI services.

However, those alternatives typically require customers to integrate multiple software and hardware components rather than consume them as a single managed offering.

Oracle’s differentiation, although narrow, is hard to match, Chaturvedi said: “The vertical integration of database, engineered hardware, cloud management, high-availability architecture, and now private AI, all engineered together and delivered as a managed on-prem subscription should be genuinely convenient and attractive.”

The offering is compatible with Oracle AI Database 26ai and Oracle Database 19c in Enterprise Edition and Standard Edition configurations. It also supports Oracle Real Application Clusters, Oracle Data Guard, and Zero Data Loss Recovery Appliance through Oracle-managed cloud automation for high availability and disaster recovery, the company said.

Base Database Cloud@Customer is now generally available, Oracle said. It did not provide pricing.

This article first appeared on CIO.

Separating transactional databases from analytical systems was, until recently, considered good architecture. Now, as enterprises adopt AI agents that continuously read, reason over, and act on business data, data warehouse and database vendors are increasingly deciding that separation has become a liability.

Just weeks after Databricks unveiled its Lakehouse Transaction and Analytical Processing (LTAP) offering based on Neon Postgres to bring operational (OLTP) and analytical (OLAP) processing closer together, EnterpriseDB (EDB) has introduced converged analytics capabilities for its managed EDB Postgres AI database service with the same intent.

Both vendors are responding to the same pressure of enabling AI agents for enterprises to operate on fresh operational data without waiting for pipelines and replicas, but EDB argues its approach starts from a fundamentally different place.

“Databricks is building from the lakehouse outward, trying to pull transactional capability in through Lakebase,” said Max Romanenko, chief engineering officer at EDB, while “we’re building from the operational layer with Postgres, which is where enterprises already run their most critical workloads, and expanding from there.”

In contrast to Databricks’ lakehouse-centric LTAP, EDB keeps Postgres as the operational source of truth and uses Apache Iceberg as a shared catalog layer connecting Postgres with ClickHouse, WarehousePG, and Spark compute engines, Romanenko said.

In this way, operational data remains in Postgres while historical and tiered data is stored in Iceberg-managed object storage, allowing analytical engines to query the same data through a common catalog without requiring separate copies or ETL pipelines, he said.

That architectural distinction matters to EDB, according to Romanenko, because the vendor is targeting enterprises that want AI and analytics capabilities without moving sensitive data into a cloud-managed platform: “For us, it’s always been about the data sitting on infrastructure the customer owns and controls.”

Focus on data sovereignty and predictable economics

EDB’s promotion of control “will resonate with CIOs focusing on sovereignty, regulated data, and hybrid deployment,” said Stephanie Walter, practice leader of AI stack at HyperFrame Research. “This should enable them to run AI and analytics closer to the data, on infrastructure that their enterprise controls, without creating yet another proprietary data estate.”

For Ashish Chaturvedi, leader of executive research at HFS Research, EDB’s approach in converged analytics will offer more predictable costs than Databricks LTAP for CIOs already struggling to manage their analytics and AI budgets.

EDB’s per-core pricing model can make costs easier to forecast than consumption-based cloud data platforms, where query volumes, AI workloads, and data processing demands can cause bills to fluctuate, Chaturvedi said.

But predictable bills are not necessarily lower bills, warned, Igor Ikonnikov, advisory fellow at Info-Tech Research Group. “The hardware requirements for high-speed operational data processing are higher and relatively more expensive compared to cheap lakehouse storage,” he said.

EDB’s architecture could also simplify data governance by reducing the number of platforms enterprises need to manage. Since operational, analytical, and AI workloads can access data through a common Postgres-Iceberg foundation, enterprises may be able to avoid deploying and governing multiple specialized data stores, and so have fewer systems to license and secure, according to Devin Pratt, research director at IDC.

Reducing architectural tax for engineering teams

EDB’s converged analytics could also simplify operations for developers and data engineering teams.

Its architecture reduces the number of systems developers must integrate and maintain, while eliminating much of the pipeline work traditionally required to move data between transactional and analytical systems, according to Walter.

And, said Pratt, “Zero-ETL means far less plumbing to build and break, so engineers spend their time creating value.”

EDB and Databricks are not the only ones pursuing converged analytics to support agentic systems and other applications needing immediate access to operational data, historical context, and governance controls.

Snowflake has been expanding support for operational workloads by embracing open table formats,and Microsoft has combined transactional and analytical services under a broader data architecture via its Fabric platform.

Evolution of autonomous databases?

Converged analytics, though, was only one part of EDB’s update to its Postgres AI platform.

It has also made generally available what it calls an “agentic database” feature, designed to automate routine database administration tasks.

The system continuously monitors hundreds of operational and performance metrics, detects anomalies, recommends corrective actions, and, where enterprise policies permit, can automatically apply fixes, the company said.

These automated agents can help enterprises optimize and tune their databases up to 10 times faster, it said.

Walter remained skeptical: “It is more an evolution of autonomous database concepts than a wholly new category. Oracle and other database vendors have offered autonomous database capabilities for years.” Where EDB can differentiate itself, she said, is in extending those autonomous capabilities with AI-driven reasoning, automated remediation, and governance controls that allow enterprises to determine how much authority the system receives.

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