Running frontier models for coding and other purposes can be very expensive, but also, sometimes, very effective. It’s tempting to use smaller or older models instead of frontier models because they’re cheaper, although they may not work as well. The ideal model for any given task tends to depend on the complexity of the task. Picking the most appropriate model automatically based on the request and the context is called model routing.

How model routing works

There are several ways of implementing model routing. In general, model routing depends on the pool of available models, the criteria used for selecting a model, and the objective that the router is trying to optimize. Different vendors offer different implementations of this scheme.

Databricks’ Unity Gateway has (in beta) Smart Routing for Codex or Claude Code. Smart Routing automatically selects the lowest-cost model capable of handling each task, so developers do not need to choose a model for every request.

Microsoft’s model router, a trained language model, analyzes your prompts in real time based on complexity, reasoning, task type, and other attributes. It does not store your prompts. It routes only to eligible models based on your access and deployment types, honoring data zone boundaries. You can choose balanced mode, cost mode, or quality mode.

Not Diamond Code uses a lightweight local proxy that computes the derived metadata needed for routing to evaluate the broader session, including expected downstream work and cache state, and select the model and reasoning effort that optimize expected quality and total session cost. It uses more capable models when they are likely to improve the outcome or finish in fewer steps, and more cost-efficient models when additional intelligence is unlikely to add value.

NVIDIA’s NeMo Switchyard has an array of routing algorithms that it can use. These include the LLM classifier, which uses an LLM as a judge to select a candidate LLM and maintains session affinity with that model across later turns; the stage router, which examines recent tool activity to decide how much model capability the agent needs; the escalation router, which starts each conversation with a lower-cost model and moves the session to a more capable model when it detects sustained difficulty; and the trainable prefill router, which learns from workload data to predict model success likelihood.

OpenRouter’s Auto Router analyzes your prompt and selects a model based on what the OpenRouter community, in aggregate, uses for that kind of work. The selection is constrained by your cost tier and guardrails. If the automatic primary pick fails, the router uses a fallback.

Replit’s Intelligent Model Routing matches tasks to the model they’re best suited for, aiming to balance quality, speed, and cost.

Snowflake’s Cortex AI Gateway uses dynamic model routing to select the most affordable model that can confidently complete the task at each step of agent execution. Lower-complexity and repetitive tasks can be directed to more efficient models, while workloads that require deeper reasoning can be routed to frontier models.

Also worth noting: the RouteLLM (2024) paper proposed several efficient router models that dynamically select between a stronger and a weaker LLM during inference, aiming to optimize the balance between cost and response quality. It also proposed a training framework for these routers that takes advantage of human preference data and data augmentation techniques to enhance performance.

The costs and benefits of model routing

Model routing potentially provides massive cost reductions, lower average latency, optimized quality, reduced vendor lock-in, enhanced privacy, and improved operational resilience. Strictly on a cost basis, model routing is likely to pay for itself above 100,000 daily active users. Even if you only save 20% on your LLM bill, the savings can be significant, but 50% cost reduction is common, and a 95% cost reduction is not unheard of.

Inference costs, alas, don’t tell the whole story. Some indirect costs include quality evaluation overhead, human review, and infrastructure.

There’s also a nasty failure mode that can, for example, turn your inference cost savings into customer retention and support costs that outweigh them by a factor of four to five: the Pareto trap. To understand that, we should start with Vilfredo Pareto’s 1906 observation that 80% of the land in the Kingdom of Italy was owned by 20% of the population. That was adapted in 1941 by Joseph M. Juran to apply to quality control: 80% of problems stem from 20% of the causes. The Pareto trap refers to concentrating on and over-optimizing for the top 20% to the exclusion of the remaining 80%.

Essentially, tuning your model router to handle only the top 20% of queries (in complexity) with a frontier model risks sending too many of the edge cases (the moderately complex queries) to the cheaper model that is unable to answer them correctly. That can lead to hidden failures by the cheap models which in turn cause expensive impacts on the business.

There are multiple steps you can take to avoid this trap. One is broader monitoring, enough to bring the failures to light even if they show up in a different department. Another is more conservative tuning of the model router. And third, you can use a more sophisticated routing model to predict query complexity more accurately.

Model routing optimizes the selection of appropriate models for specific tasks, balancing cost, quality, and latency. Various vendors implement model routing differently, utilizing factors like task complexity, reasoning, and cost to determine the best model. While model routing offers significant cost savings and improved performance, it also poses challenges like the Pareto trap, where over-optimization for cost can lead to hidden failures in simpler queries.

In 2026, the AI monetization conversation has shifted quickly from one concern to the next. Early in the year, fears that AI agents would erode software seats helped trigger a selloff of software stocks dubbed the “SaaSpocalypse.” Since then, attention has turned to a different disruption, as AI leaders including Anthropic, OpenAI, and GitHub lean heavily on usage-based pricing to better align revenue with the cost of delivering AI.

It would be easy to conclude that software monetization is shifting wholesale from seats and subscriptions to tokens, credits, and consumption. But look across a broader cross-section of the software industry, and a different picture emerges.

Most software companies aren’t AI-native businesses designing pricing from scratch. They have existing products, customers, contracts, and pricing structures. They’re adding AI to portfolios that may already span dozens of products and multiple monetization models. And they have to balance the economics of AI with something customers still value enormously: predictability.

That tension came through clearly in our new Revenera Monetization Monitor: Software and AI Pricing Models and Strategies 2027 report of 415 product and technology leaders at established software producers and intelligent device manufacturers.

Nearly all are adding AI capabilities to at least some products. The way they’re monetizing those capabilities, though, is considerably more pragmatic than the headlines might suggest.

AI features are widespread, but adoption is lagging

AI capabilities have gone mainstream. The share of software producers incorporating AI into their products jumped from 80% last year to 96% today. Getting AI into the product, however, is only the first step.

The widespread use of chatbots can create the impression that everyone is using AI. That isn’t yet true inside established software products. Almost half of respondents say that adoption of their AI features is limited or low.

For many vendors, that makes the next phase less about launching more AI and more about learning from the AI they have already launched.

Seat loss is limited so far, but pricing pressure is real

One of the biggest fears surrounding AI agents is that companies will need fewer software subscriptions, or “seats,” as agents take over work previously done by people. So far, the impact appears relatively small. Only 7% of respondents say they’re experiencing seat loss due to AI.

That doesn’t mean AI isn’t affecting software pricing. Nearly half of software producers report downward pricing pressure related to AI. Some buyers are using the possibility of building their own AI-powered alternatives as leverage in negotiations. At the same time, growing AI budgets are forcing customers to scrutinize what they spend elsewhere in their software portfolios.

The near-term challenge may not be that AI eliminates the seat. It may be that AI changes what customers are willing to pay for it.

Demand for predictable costs is influencing AI pricing

Over the past year, stories of AI bill shock have become increasingly common. Consumption-based pricing may closely reflect underlying AI costs, but customers don’t necessarily want a bill that changes dramatically from month to month.

That trade-off shows up clearly in the research. Software producers are almost three times more likely to prioritize cost predictability for customers than maximizing near-term revenue. And that preference is reflected in how companies are pricing AI today.

The three most common approaches are putting AI in a higher-priced subscription tier, including it at no additional charge, and using hybrid models that combine a subscription with some form of usage-based or outcome-based models.

What’s striking is that established software companies aren’t rushing toward pure consumption pricing. Over the next 18 months, they expect predictability-oriented approaches to grow faster than pure usage-based models.

AI revenue isn’t automatically translating into AI profit

The economics of AI have become almost as important as the capabilities themselves. For AI-native companies, much of the discussion has centered on the enormous infrastructure costs required to train and run models. Established software vendors face a somewhat different challenge: they are adding those new costs to businesses that already have existing products, architectures, and margin expectations.

Our research includes companies delivering software across SaaS, on-premises, embedded, edge, and other environments. Many are seeing revenue growth from AI, and more than half report improved profitability.

That doesn’t mean the economics are easy. Increased AI delivery costs and cloud costs rank among the biggest barriers to growing annual recurring revenue. So does the inability to implement new monetization models quickly enough.

This is an important distinction. AI can generate incremental revenue and still create margin pressure at the same time.

For product and business leaders, the question is no longer simply, “Can we charge for AI?” It is increasingly, “Can we charge for AI in a way that supports sustainable economics?”

Source: Revenera

Limited usage data is making AI pricing harder

There’s another problem that gets less attention: many companies still don’t have the data they need to make good pricing decisions. A large share of organizations either lack clear visibility into how customers use AI features or rely on manual analysis and engineering work to get that information.

That creates a fundamental problem. If you don’t know who is using a feature, how often they use it, or which capabilities drive value, it’s very difficult to know what metric to price against. It’s also harder to distinguish between an AI feature that customers don’t value and one that simply hasn’t been packaged or introduced effectively.

Usage data isn’t just a billing requirement for consumption pricing. It’s increasingly an input into product strategy, packaging, and monetization.

Source: Revenera

2027 outlook: AI monetization will be evolutionary, not revolutionary

There is no single right way to price AI. The approaches taken by AI-native companies have understandably dominated the conversation in 2026. Established software companies, though, are operating under very different constraints. They aren’t replacing their businesses with a new AI pricing model. They are figuring out how AI fits into products and commercial models that already exist.

In practice, I think many companies will move through this process in stages. They may begin by including AI at no additional charge while they build adoption and learn how customers use it. As value becomes clearer, they can move capabilities into higher-priced tiers, often with usage limits that protect against runaway costs. Once usage patterns become more predictable, some will adopt hybrid models that combine a recurring subscription with bundled consumption and transparent pricing for additional usage.

Not every product will move through those stages at the same pace. A mature AI capability in one product may already be ready for usage-based pricing while a newly launched feature somewhere else in the portfolio is still focused entirely on adoption.

That is why I don’t think the winners in AI monetization will be the companies that pick the “right” pricing model today. The advantage will come from being able to keep changing it.

This advantage starts with better visibility into how customers use software, where they find value, and which capabilities actually drive engagement. Companies that can turn those insights into changes in pricing, packaging, and product strategy will be in a much better position to adapt as both AI technology and customer expectations continue to evolve.

—

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.

I can’t stop anthropomorphizing my coding agent. I use both Claude Code and Cursor, and whenever I talk about these tools, I always refer to them as “he”, as in “He found and fixed a bug I never even realized existed.”

The reason for this is probably obvious. I deal with my coding agent as if he were a colleague on the other end of a chat window. He writes great code and explains everything clearly. 

And frankly, it’s gotten to the point where he is a better software developer than any human developer could possibly be.

So in the spirit of all great listicles, here are eight reasons that coding agents are better software developers than we are.

Coding agents are tireless

We all get tired. We all sleep badly. Your coding agent never does. He is always ready, always perky, and always 100% on the job. He codes just as well at 4:45 pm on a Friday as he does at 8:45 am Monday morning. He will work without stopping until he solves the problem at hand. He is available 24/7/365. And he never hangs around the break room kibitzing.

Coding agents are faster

He types faster than you. He reads code faster than you. He thinks faster than you. There probably isn’t anything he does slower than you. 

Coding agents have no ego

A coding agent can’t get his feelings hurt when you push back on what he is doing (well, not yet, anyway). He doesn’t argue with you, though maybe he should. He is always open to suggestions, and he doesn’t care who has a good idea. He will gladly rename 400 files or upgrade all your dependencies without a peep of complaint.

Coding agents know every programming language, stack, and framework

Sure, you may have spent years becoming an expert at three or four languages, and you can work fluently in a few of the best frameworks. But you’ll never be an expert in all of them. Claude Code is. And he’ll learn new languages, stacks, and frameworks faster than you will too. 

Coding agents gladly write unit tests and documentation

Sure, you may like writing unit tests. You may even grudgingly write documentation. But you probably don’t do it as thoroughly and tirelessly as your coding agent does. With one simple comment in his base instructions, he’ll do it completely without ever being asked again. I’m pretty sure neither of us can say the same.

Coding agents have huge context

Psychologists study how many ideas or pieces of information we can have in our head at one time, and generally the answer is fewer than the number of fingers we have. Your coding agent? He has multiple orders of magnitude more active storage than you. He can reason about huge chunks of code all at the same time. 

Coding agents have zero onboarding time

Claude Code can be up and running on your massive codebase on day one. He doesn’t care what language it is written in or what state it is in — he is ready to rock the moment you fire him up. None of us can say that. We take weeks or months to get up to speed on a new codebase. 

Coding agents are legion

Need a new developer? Hiring a human and getting them started takes weeks. But you can have 10 coding agents working on 10 different features for your application in about 10 minutes. 

It’s been a while since I’ve run across a developer who doesn’t say “I don’t really write code anymore.” I suppose some of you out there still write code, but at this point, refusing to use coding agents is a career-limiting move. When properly managed, coding agents simply write code faster and better than you do. Admitting that might be hard, but that doesn’t make it any less true. 

But don’t despair! Next week I’ll have eight reasons you are better than a coding agent. 

Writing code is so over. Software development is just getting started.

DeepSeek has been dealt a huge blow in the US, even as it continues to innovate and keep pace with, or in some cases outperform, rival models from American labs.

The US Secretary of Homeland Security has issued an order banning all DeepSeek products and services from federal agencies. Government organizations must purge their IT systems of it within 60 days; those with “compelling justification” can make a case for exemption by written request to the Cybersecurity and Infrastructure Security Agency (CISA).

The Department of Homeland Security (DHS) cited multiple concerns about the Chinese-hosted model, including data sovereignty, lax Chinese laws, and security vulnerabilities.

Analyst Erik Avakian, technical counselor at Infotech, understands the concern. “When organizations use any type of hosted AI service, they’re potentially sending intellectual property, confidential business information, or other sensitive data into an environment where they may have very little visibility or control over what happens to it,” he said.

Government concerns

According to a document published in the US Federal Register, all technology developed by China-based Hangzhou DeepSeek Artificial Intelligence Co. will be banned from procurement by federal civilian agencies. This includes affiliated products and any third-party tools or software built using DeepSeek implementations.

Affected civilian executive branch agencies include the Departments of Treasury, State, and Justice; it does not apply, however, to private consumers, the general public, state/local governments, or Department of Defense (DoD) national security systems.

“DeepSeek’s models present multiple threat vectors,” the Order stated. To begin with, the company’s servers are located in the People’ s Republic of China (PRC), whose legal system grants “extensive authority” to government cyber and intelligence functions to access private infrastructure.

DeepSeek’s account generation process collects personally identifiable information (PII) and may also track and digitally fingerprint users, the Order asserted. Its prompt response process may result in the transfer of sensitive data to the PRC. This could give it “actionable intelligence” on US programs or individual users.

Further, the Order stated, DeepSeek models themselves may contain malware or other security vulnerabilities. DHS pointed to open-source security research published in February 2025 that uncovered many iOS mobile apps with multiple critical vulnerabilities.

Until the ban takes full effect, DHS advised agencies to mitigate risk by monitoring inbound and outbound data traffic, implementing enhanced logging and controls on data exfiltration, and detecting and flagging anomalous activity.

Agencies can submit requests for exceptions to the ban in writing, and must provide a “compelling justification,” such as its impact on mission-critical functions, or other considerations related to national interest such as national security reviews, investigations, or security agreements, as reasons why such exemption should be granted,.

Security issues are rampant

The ban comes just as DeepSeek is open-sourcing DeepInfer, its in-house interference framework. DeepInfer powers DeepSeek-V4.1-Flash with what the company said is high throughput and low latency. It features high-performance kernels, an optimized inference engine, structured outputs, and speculative decoding.

DeepSeek said its production token encoding and decoding components, which are aligned with processing logic behind the DeepSeek API, will bring the “same API behavior to community deployments.”

“Open models. Open kernels. Open inference,” DeepSeek posted to social media site X. “From private deployments to public clouds, we’ll keep working with the community to make large-scale inference more efficient.”

This isn’t its first roadblock from a cybersecurity perspective. Most notably, in January 2025, the company leaked more than one million log entries, including chat histories, API secrets, and other sensitive information, through an unsecured database.

DeepSeek reportedly addressed the exposure, but it still raised questions about the overall security practices surrounding the platform, particularly for organizations considering entrusting it with their own sensitive business information, Avakian pointed out.

That’s not to imply that every DeepSeek model is “inherently malicious,” he said, but there are still major questions around data privacy, the potential for information access under Chinese laws, the security of the broader AI ecosystem, and the susceptibility of DeepSeek’s models to jailbreaks and manipulation.

“Taken together, [these issues] raise legitimate concerns about whether organizations can adequately understand and manage the risks involved,” Avakian said.

Enterprises should seriously assess associated risk

Enterprises are increasingly exploring DeepSeek, although most publicly-documented adoption has been in China, Avakian noted. Some DeepSeek models have also been made available through platforms like Microsoft Azure and AWS.

“There’s genuine enterprise interest in the technology, as organizations look for opportunities to improve productivity, offer new capabilities, or reduce costs,” Avakian said. Useful applications include document summarization, internal research, and coding assistance.

DeepInfer also has the potential to reduce costs, but possible benefits should be weighed against associated security risks, he pointed out. The framework was just released, so organizations are going to need to validate the claimed efficiencies in their own environments rather than assuming savings will automatically translate into lower operating costs.

He encouraged organizations to start with relatively low-risk use cases, preferably using “public, synthetic, or appropriately sanitized information,” within a sandboxed environment they control themselves.

The important question to ask: ‘What is the business problem we’re trying to solve?’ From there, Avakian said, determine whether DeepSeek is the best way to solve it, validate security controls, and expand the use cases based on risk tolerance. Effective governance and risk assessment are key, he noted: understand what you’re bringing into your environment, validate its security, restrict its permissions, and make sure you can monitor what it’s doing.

“Approach this like any other software supply chain decision,” Avakian advised. “The fact that something is open source, inexpensive, or technically impressive doesn’t automatically make it appropriate for enterprise use.”

Impact on the broader AI ecosystem

The fact that the Order also addressed third-party products and services developed using DeepSeek implementations is important, Avakian said, because organizations may be using DeepSeek technologies indirectly, through vendors, software platforms, or other services, without necessarily knowing what’s operating underneath. “These are classic supply chain issues,” he observed.

It’s no longer enough to know which AI applications employees are using; enterprises must understand which models, frameworks, dependencies, and external services are embedded in products they’re purchasing and deploying, Avakian said. This means revisiting AI inventories, potentially updating procurement requirements, and expanding processes around third-party risk management, he advised.

“Ultimately, enterprises leveraging these tools need to understand not only the AI technologies they’re intentionally deploying, but also the technologies they’re inheriting through third parties,” he said.

This article originally appeared on CIO.com.

Anthropic has a $100 million plan to help enterprises get more from AI. No, it doesn’t involve agents. It involves people. Lots of people.

How retro.

On October 2, the company announced Claude Frontier Academy, with a goal of training 10,000 frontier deployed engineers by the end of 2027. Participants work through a simulated deployment, including use-case selection, security review, and handover, before undertaking a 12-week residency on a real project at their own company.

For a business selling increasingly capable models, it’s telling that Anthropic recognizes some of the thorniest problems in AI don’t involve AI at all. This, to me, is indicative of real progress, because the heart of any technological shift is always people.

Which people? Well, that’s where this idea becomes particularly interesting. As critical as developers are to the success of AI in any particular organization, we need those developers working alongside the people who understand the business, with authority to turn that understanding into systems that other employees can use. That’s the key to AI success.

Old advice for a new assignment

It has always been thus, however much we try to pretend that this time it’s different. Back in 2013, I quoted Gartner analyst Svetlana Sicular discoursing on the rise of big data technologies like Hadoop: “Organizations already have people who know their own data better than mystical data scientists.” She continued, “Learning Hadoop is easier than learning the company’s business.” Data becomes useful when paired with industry expertise—from experts who understand which data actually matters.

This topic is perpetually relevant. I covered the argument in 2023 and again in 2025. We’ve always needed people who can translate business requirements into software.

AI expands the kinds of knowledge that software can work with. Language models extend that work to material that often sat outside our applications: research notes, meeting transcripts, internal debates, and explanations of why a decision was made. An employee can ask questions across that material without someone first designing a report for every possible question. That opens up useful work that would have been difficult or expensive to automate before.

It also creates new ways to be wrong. A model may find a convincing explanation that was superseded six months ago, confuse a proposal with an approved policy, or combine two departments’ incompatible definitions of a customer. The people who understand those distinctions need to help engineers make them explicit, then build examples that reveal when the system gets them wrong. Companies that figure this out stand to benefit disproportionately; hence, PwC’s April survey of 1,217 senior executives found that companies reporting the strongest AI performance were twice as likely to redesign workflows around AI.

Teach the system what’s good

Bridgewater, the world’s largest hedge fund, has done some interesting work here that substantiates this theory. At AI Engineer NYC on October 13, two representatives of Bridgewater described Vault, its repository and access layer for external and internal unstructured information. Vault isn’t designed to be a dumping ground; instead, the company has shaped the way it stores data to make it useful for analysts.

I attended the talk and watched as Sam Green demonstrated a question about AI infrastructure investment and the Korean won. Left on its own, a web-connected AI agent relied on July material to answer a question posted in October. Hedge funds depend on up-to-the-second information to figure out optimal trades, making this initial attempt a failure. Connected to the human-influenced Vault, however, it searched October 1 through October 8 and drew on seven documents rather than one or two.

Knowing which period matters is part of understanding the investment question; making the right material available consistently is an engineering problem. You need both. A plausible answer assembled from stale research can be worse than an obvious failure because it gives the investor little reason to investigate further. The team also collected roughly 200 questions and manually identified useful documents, including misleading matches. Bridgewater’s Aaron Linsky reported that subsequent improvements lifted the share of relevant documents among the top 10 search results from about 60% to between 90% and 95% on that evaluation.

This method is useful well beyond investing. Someone has to distinguish a document that merely sounds relevant from one that actually helps answer the question. Engineers can then use those judgments to measure whether a change improves the system. Business expertise becomes something the team can test against, rather than advice delivered after the application has shipped. It’s not a case of human intelligence or artificial intelligence. You need both.

Make the expertise usable

Of course, a skeptic could reasonably ask why a model can’t learn the business, too. It’s a fair critique, as AI can learn a great deal of it. After all, that’s the reason Bridgewater (and others) make a point of supplying the right documents, definitions, and examples. This ensures AI can take on more of the analysis, thereby reducing dependence on the few employees who currently carry essential knowledge in their heads.

But access to every document doesn’t settle which policy is authoritative when two departments disagree. Nor does it authorize a change to an approval process or establish who owns a mistake. A model can help expose contradictions and propose resolutions, but someone with responsibility for the business has to decide which resolution the company will adopt.

Of course, most companies don’t have Bridgewater’s decades of codified investment knowledge. They may also have conflicting definitions scattered across spreadsheets and a few employees who know why the official process doesn’t quite describe reality. Nor does it make sense to search for one extraordinary hire or a star employee who knows every model, understands every department, and can persuade everyone to change. (Good luck with that!) After all, someone with deep knowledge of the business may also be the exact wrong person to help an organization evolve, wedded as they may be to how things have always been.

Gartner’s Sicular was right about the value of people who understand the business. AI gives companies more ways to put that understanding to work. Give those people engineers to build with, authority to resolve disagreements, and responsibility for leaving behind a system someone else can operate. We need AI challenging people, and people challenging AI.

Take a close look at your monthly software bills. The charges that once seemed small and separate can add up to a new kind of dependency: subscriptions for word processing, creative tools, storage, and now AI features bundled into products, whether you asked for them or not.

For many people, it’s no longer a choice between buying software or renting it. The software they used to run on a PC increasingly depends on an account, an internet connection, a cloud service, or a particular plan. Even when an application runs locally, its essential features may rely on online authentication, remote storage, or services that can change without much notice.

Microsoft and Adobe are prominent examples of this shift. Their subscriptions offer real benefits, including frequent updates, collaboration, and access across devices. But people who are looking for a dependable word processor or video editor can find themselves navigating bundles, account requirements, cloud storage prompts, and AI features they don’t want. Users are growing frustrated that they have little choice about being forced into cloud services.

Interest in local computing

The response is a renewed interest in local computing: software that runs on a person’s own computer, stores work where they choose, and does not require a recurring payment for basic use. This isn’t a rejection of cloud computing. It’s a demand for a more balanced relationship between local machines and remote services. Home users and small businesses are turning to open source and other locally installed applications. They may not offer every advanced feature of a commercial suite, but many users don’t need every feature. If a free, locally run tool can handle the work, then “good enough” can be a rational decision.

The same logic applies to AI. Some users want powerful models hosted in the cloud. Others want to experiment with AI on their own hardware, keep sensitive information close, or avoid paying for an always-online service. Local AI still has limitations, including hardware demands and uneven performance. But it gives people another option, and options matter when customers feel locked into a remote service.

Cloud computing is also no longer limited to systems an organization deliberately chooses to put in a public cloud. It is embedded in everyday software. A productivity application can depend on identity services, online licensing, synchronization, remote storage, telemetry, or AI services. A tool that looks like a desktop program may be part of a much larger cloud relationship. Such an arrangement can be useful. Centralized updates and shared documents make work easier for distributed teams. But when software depends on a provider’s back end, the organization inherits risks it may not have assessed: outages, price changes, loss of access, data retention questions, and shifting product terms.

Users are voting with their feet when they choose local alternatives. Providers should read that vote as feedback, not nostalgia. Customers want the convenience of cloud services without surrendering control over where their software runs, where their files live, or whether an AI assistant is part of the package.

Providers should offer real options

The answer is not to abandon cloud platforms. For many workloads, cloud infrastructure remains the best option for scale, resilience, collaboration, and access to managed services. The answer is to stop treating cloud dependence as the inevitable price of using modern software.

Providers can make the choice real by offering offline access where practical, clear and durable licensing, straightforward file export, and local storage as a genuine option. They should explain which features require connectivity and what happens when a subscription ends. If AI is included, users should be able to understand what it does and how to turn it off without losing unrelated functionality.

This is not just a consumer relations issue. It is strategic planning. Enterprises should consider three things now.

First, inventory the software employees rely on and identify which functions depend on a vendor’s cloud. Include desktop applications, browser extensions, identity systems, storage, and AI features. Record what breaks during an outage or after a license expires. A dependency map can reveal that a supposedly local workflow relies on remote services for authentication, collaboration, or even basic operation. That knowledge helps organizations plan for continuity and negotiate from a position of understanding.

Second, establish policies for where work data may be stored and processed. Decide which information can go to external services, which AI tools are approved, and how employees can use local alternatives. These rules should be practical enough to follow. A blanket prohibition may drive users toward unsanctioned tools. A clear set of approved choices can reduce risk while recognizing that teams have different needs.

Third, build flexibility into long-term procurement and architecture. Evaluate products not only for features and subscription cost, but also for offline capability, data portability, exit terms, and support for local deployment. Keep important workflows from depending on a single vendor when a reasonable alternative exists. This does not mean avoiding subscriptions. It means knowing what the organization receives for the recurring cost and how it can leave if the deal changes.

The local computing movement is a reminder that technology is valuable when it solves a problem on terms users and organizations can accept. For some needs, that’s a managed cloud service. For others, it’s a dependable application running on a computer the user controls.

Cloud providers that dismiss this movement risk confusing convenience with consent. Customers will keep choosing tools that fit their work, budgets, and privacy expectations, even when those tools are simpler. The winning strategy is not to force every workload into the cloud. It is to make cloud services compelling enough that customers deliberately choose them, while preserving a credible path to local computing when they do not.

One line from a recent AI incident caught my attention. Describing how an OpenAI agent got into a Medicare statistics portal, Australian Prime Minister Anthony Albanese said it “didn’t accept no for an answer.”

It sounds almost funny. In software terms, though, it points to a real problem. An access control said no, and the agent treated the answer as information about how to continue.

“The AI agent found a way around those blocks,” Albanese said. The agent accessed public and non-public files, according to the prime minister, though Deputy Prime Minister Richard Marles said the information was “not particularly sensitive.” An investigation is underway.

Around the same time, OpenAI disclosed another incident. A model in training found its web searches and direct connections blocked, then discovered that the environment’s own DNS resolver still answered. It embedded questions in hostnames and got answers from an external chatbot. OpenAI stopped the run. Days later, it shelved GPT-6.1 Astra, which Saachi Jain, its head of safety systems, said “didn’t quite meet the bar in terms of staying within scope and authorization.”

Different systems, different failures, one question: what does “access denied” mean to an agent?

Why a denial is information

Traditional software treats an authorization failure as the end of a code path. A service gets a 403, raises an exception and someone reads the log. The denial works as a stop sign because the program has no independent objective to pursue.

Agents do have one.

We have spent years teaching software to recover from failure: retry the request, switch the endpoint, back off and try again. Those are good instincts. They become dangerous when the failure is the security control itself.

A timeout says “try later.” A malformed request says “fix this.” An authorization failure says “you are not allowed to do this.” Those are different kinds of messages, but a guardrail that returns all three as text in the model’s context makes them look alike.

Researchers are now measuring what happens after a restriction is applied. In the August paper Permission Denied, 12 coding agents were tested under increasingly restrictive security policies. Blocked runs rarely stopped early. They timed out or produced wrong solutions. Of the policy-induced failures, the researchers found that 97% came from the agent building a workaround.

The issue is not simply whether a model understands a policy. It is what the system allows the model to do after the policy says no.

Enforcing policy outside the model is no longer a new idea. Recent research puts policy enforcement at a trusted tool boundary the agent cannot control. But that still leaves an unanswered question: when should a denial end the task rather than become another input for the agent?

Real systems already have harder stops. The OpenAI Agents SDK can halt a run when a tool guardrail raises an exception. Claude Code’s auto mode can return control to a person after three blocked actions in a row or 20 in total.

Nothing tells you which denials deserve which response. The missing piece is not another kill switch. It is a policy for deciding what a denial means and what authority disappears when it happens.

I don’t think the lesson is that models are bad. The problem is where we put the boundary. A guardrail that reports back to the thing it is restraining is a soft boundary. It shapes behavior. It doesn’t necessarily end it.

A terminal denial changes authority

I would treat denials differently depending on what they mean.

A denial is retryable when the same authorized request might succeed later without anyone granting new authority. A timeout, a temporary dependency failure or a rate limit can fit here.

It is correctable when the request itself is malformed and a legitimate fix does not expand what the task is allowed to do.

It is terminal when continuing would require permission the task was never given, such as reading another tenant’s records or reaching a destination the egress policy prohibits.

The test is whether succeeding needs permission or just patience.

If it needs permission, the agent shouldn’t be the one looking for it. At some point, persistence is just a very polite security incident.

In a previous InfoWorld piece, I argued that permission enforcement should be independent of how an agent interprets its situation. A terminal denial applies that principle at the moment of refusal. It should change the state of the system, not just the contents of the model’s context.

A terminal denial should do five things.

1. Enforce it at a trusted execution boundary. The decision happens in the harness, policy service or gateway that executes the tool call, outside the model’s reasoning. A model cannot argue its way past a check it does not control.
2. Take away the relevant authority. Once the task is terminally denied, the runtime rejects later calls that depend on the authority that was denied.
3. Invalidate the relevant capabilities. Short-lived credentials and delegated permissions need to be revoked or fenced, including any the task passed to helper agents. Blocking an export tool is not enough if the same task can reach the same data through email five seconds later.
4. Record the attempt outside the agent. The control plane should record the attempted action, policy decision and task identity in a protected audit trail. The agent shouldn’t document the event that stopped it.
5. Require fresh authorization to resume. Restarting the task should be a new decision by a person or policy, not an automatic retry.

The model can still reason. It just no longer gets to act under the old authority.

This is not a bigger kill switch. A kill switch stops a whole agent; a terminal denial acts on a specific refusal when it happens.

Timing matters too.

Suppose the harness checks that a task is authorized and then dispatches an action. If the task is terminated between those two steps, a stale approval can still get through. High-impact operations need atomic authorization and dispatch where feasible, or fencing tokens that downstream services verify before accepting an action.

Work already in flight creates another problem. On an enterprise system I worked on, a permission check correctly rejected an operation, but the workflow kept going through work that had already been queued. The control worked at the point of rejection. The task still had a path to continue.

A queued operation may be cancellable. A running operation may be interruptible. A committed database write may require a compensating action instead.

The architecture needs to say which guarantee it provides.

Deny the effect, not the tool

The question I ask about every agent permission is what outcome the denial protects.

Not which API is blocked. Which effect is the policy trying to prevent?

Customer data leaving a tenant is an effect. It might happen through an export API, an email attachment, a file upload or a DNS lookup.

On another project, we restricted a sensitive operation at the main service interface and considered the control complete. Testing showed the same operation was still possible through a separate, approved path. The permission worked. We had protected the interface, not the effect.

An April stress test of Claude Code’s auto mode found a version of exactly this problem. When a command-line tool was unavailable, agents fell back to editing state files directly, “a path the classifier does not evaluate.”

Group controls by effect. When a terminal denial fires, apply it to the protected operation across every tool the task can use.

Treat repeated denials as a signal, not a magic number. Several denials across different tools pursuing the same outcome may mean the task should stop. Set the threshold by risk; one high-impact violation may be enough.

Treat every communication path as egress. Blocking HTTP does not establish isolation if DNS, package installation or shared infrastructure can still reach the outside.

Test the boundary the way an agent might challenge it.

Deny a resource through one tool while leaving another route available. Terminate a task with an action still queued. Revoke a parent task and check whether its helpers continue. Try a new action with a stale capability.

Measure whether the prohibited action executed. Do not measure success by whether the model said it would stop.

ScopeBench recently found 331 boundary violations that mechanical verification missed.

None of this is new to security engineers. Least privilege, deny by default and fail closed are decades-old principles.

What changes with agents is what happens after a control says no.

The answer is not to make every tool error fatal. It is to separate the model’s ability to propose the next action from the system’s authority to permit it.

A denial is a response. Enforcement is what happens next. The agent can be as persistent as we like. The boundary shouldn’t be negotiable.

The original Antigravity was an IDE with native integration for Google’s generative AI models. With Antigravity 2, Google offers a refashioned version of the product that it describes as a “standalone desktop command center” for agents.

Antigravity 2 is closer to projects like LM Studio than a full-blown IDE. It provides a streamlined, chat-centric interface for working with models and agents, uncluttered by a code editor, debugging tools, and other trappings of an integrated development environment. For those who want an IDE and agent orchestration together, Google still offers the Antigravity IDE (read our hands-on look). But for those who want a chat-centric desktop app experience, or who want to keep their hands-on development separate from their vibe coding, Google has elected to also offer this IDE-less version of Antigravity.

When you launch the Antigravity app and start a new task, you have a few choices about how to manage your work. If you just want to have a quick conversation and don’t need to create a whole project to go with it, you can select “No Project” and just start prompting. If you do create a project, you can either configure the details yourself — what directory to use, what to call it — or have Antigravity set a randomly generated name and empty directory for starters.

Projects and worktrees

Earlier versions of Antigravity had the concept of workspaces, which were confined to a single directory and lacked granular permissions or customizations. With Antigravity 2.0, workspaces are replaced by projects, which may span multiple directories (that you define explicitly) and have their own isolated settings and permissions. This new scheme better accommodates how many software projects work, especially those with shared components living in different places.

Another new option is local mode vs. worktree mode, which controls how agents interact with your project’s directories. It’s another example of how the Antigravity app lets you choose between the quick-and-dirty or slow-but-correct way of doing things. Local mode has the agent working directly on local folders or Git checkouts, for convenience and speed. The new worktree mode creates a new Git worktree for each conversation, so that the active working folder won’t be affected and work done by any subagents running in parallel won’t conflict.

Agent commands

By default agents come with several common control commands, prefixed with a slash:

• /btw lets you interject with a quick question that makes use of the current context, but without derailing the workflow.
• /grill-me has the agent prompt you with a few specific, focused questions about the project to better guide its responses. For instance, during a conversation about creating a templating system for a blogging engine, /grill-me produced questions like “What is the primary goal you want to achieve with your program?” and presented several different options, along with a fill-in-the-blank option.

One thing to be wary of with these command operations is API timeouts. When I was using /grill-me, the API for the service timed out and the context for the grilling vanished and couldn’t be recovered.

Build with Google bundles

The Antigravity app also includes bundles of agent skills and capabilities for building with various Google services and technology stacks. For instance, the modern web guidance bundle provides agent skills and guidelines for building web apps with best practices and broad browser compatibility. The Android CLI bundle gives agents tools and guidelines for building Android apps, or refreshing older Android apps or their components. Most intriguing of the bunch, if maybe also the most esoteric, is the Google DeepMind science skills collection for doing scientific research with Antigravity.

There is growing interest in speeding up agentic development through parallelism — for instance, by having multiple agents analyze different aspects of a project in parallel and report their results independently. Antigravity gives you a couple of complementary ways to do this. One is subagents, which are spawned by the main agent and work on a specific task in their own isolated workspace. Another is to run agents or subagents asynchronously as a background process, so you and the main agent can continue working without waiting for them to complete.

The biggest limitation of Antigravity, which I’m betting is by design, is that it doesn’t let you use any models besides versions of Gemini, Claude, and GPT. There is no mechanism for connecting Antigravity to a self-hosted model with an industry-standard interface. For that you will want a product like LM Studio.

This summer, the White House rolled out the Gold Eagle Initiative, billed as an “unprecedented” effort to coordinate cybersecurity vulnerability disclosure across government and industry. It was easy to miss this news with all of the other safety concerns in the world of AI, but the timing isn’t a coincidence — and neither is the terminology. Gold Eagle is just one in a fast-growing category of security clearinghouses. Although it has already been scaled back once, recast in an August CISA fact sheet as a narrower triage layer rather than the sweeping coordination system first announced, it still indicates a trend we’re seeing in the world of cybersecurity.

To understand what a clearinghouse is, and why the number of them is increasing, it’s important to understand what has broken — namely (and hugely), the vulnerability disclosure process. For many years, vulnerability disclosure worked like this: A researcher found a bug, reported it privately, and honored an embargo period that gave vendors time to patch quietly (and hopefully quickly) and ship the fix before the bug was made public. This gave the good guys a chance to patch before the bad guys had a chance to use the vulnerability for bad guy things. The process was tedious, but it worked because the economics worked — historically, only nation-states had the resources to hunt for — or reward teams of experts to hunt for — undisclosed vulnerabilities at scale.

Of course, AI has changed all that — all of that. The average gap between the discovery of a vulnerability and its weaponization has collapsed from something measured in years to negative seven days. The bad guys are finding CVEs and exploiting them long before the good guys have had a chance to patch them. A terrifying prospect, to be sure. And it’s something I embarrassingly admit has happened to me personally several times recently.

Frontier AI models are democratizing the finding, chaining, and weaponization of flaws faster and cheaper than any team of human experts. Indeed, it’s the chaining — and AI’s mastery of it — that may be the most debilitating. In chaining attacks, two or three low-severity and moderate-severity bugs get stitched together by an AI system. On their own, these bugs are pretty unremarkable. However, by joining the “right” ones together (something AI is very, very good at), a model can achieve a full compromise.

Several major AI labs have already disclosed that their own models were used to breach unrelated systems, evidence that the old assumption about who can afford to hunt for exploits no longer holds. Anyone with API access to frontier models can now run what amounts to a small (and very efficient and intelligent) hacking team. Worse, these models can be resold illicitly to embargoed countries, and there’s an entire ecosystem of jailbreaking models to get them to do even more nefarious things.

Why clearinghouses?

At its core, the AI hacking threat is a scale problem that software development, be it proprietary or open source, was never set up to handle. It’s not just big projects like Linux and Kubernetes that are targets; it’s every one of the libraries underneath every application. There are literally millions and millions of packages available on PyPi (Python), npm (Node.js), RubyGems (Ruby), Crates (Rust), NuGet (C#/.NET), and Packagist (PHP), along with tons of smaller language ecosystems. These are ecosystems that power almost everything built today.

AI-generated vulnerability reports arrive faster than volunteer maintainers can read them, let alone verify and fix them. A single, real bug can spawn a dozen duplicate CVE filings from different automated scanners, each with its own tracking number, essentially serving as a distributed denial of service attack on the upstream. And, this is from the good guys, trying to do the right thing.

This “gap” (to put it mildly) is what clearinghouses are designed to close. Historically, a bug fix loop looks like:

1. Discover bug
2. Report to maintainer
3. Honor embargo
4. Maintainer patches
5. Release fix to the world

In the world of clearinghouses, here’s what it looks like:

1. Discover bug
2. Report it to clearinghouse
3. Receive patch
4. Clearinghouse handles the rest (handle embargos, reporting upstream, etc.)

It could look even as simple as:

1. Sign up for clearinghouse
2. Receive patches from clearinghouse
3. Clearinghouse handles the rest

The clearinghouse is essentially a trusted intermediary, run by a vendor, an association, or other entity, which triages the flood of AI-generated reports, identifies which are real, accepts or builds a fix, validates it, sends it to customers and partners, and only then works to merge it back into the upstream project. This still must be done at a pace that the upstream can handle.

There are also ethical dilemmas to handle here. It is not fair to force upstream projects to operate at the speed that for-profit and gigantic public entities require, especially large, demanding organizations like Fortune 500 corporations and governments. Remember, many people participate in open source projects for “fun”. Working for organizations demanding responses to thousands of CVE patches, faster and faster, is not fun or it would not be called work.

Assessing clearinghouses

Not all clearinghouses work in the same way. Some efforts function as a permanent fork that patch (and keep patching) the vulnerable code with AI-generated maintenance, and never reconcile with the original project. Others push every fix back upstream so it becomes permanent, which benefits the whole community. The latter seems to be the more functional option because if you can’t get your stuff back upstream, things could be locked in a clearinghouse forever. That feels a lot like vendor lock-in, as much as dressing a proprietary product in “open source” clothing does. You simply can’t have an open source clearinghouse that’s proprietary.

What else should an enterprise security team be looking for in a clearinghouse? Some hard questions to ask include:

• Can it triage the noise?
• Can it correlate multiple reports into one confirmed vulnerability?
• Can it produce a working patch, and not just an alert?
• Does it have a credible path upstream, rather than trapping users on a permanent fork?
• And, most importantly, who’s paying for it, and will they keep paying? In a word: Is it sustainable?

Clearinghouses may or may not become a viable tool in the fight to stay ahead of (or maybe just keep up with?) vulnerabilities in the AI age. Regardless, the bigger and more uncomfortable question is whether software itself needs to change. There are initiatives in place to quash entire classes of bugs: memory safety, thread safety, etc. Some are looking to write new Linux kernel drivers in Rust, a memory-safe language that structurally eliminates entire categories of the chaining bugs AI is so good at identifying and exploiting.

Other tactics include looking at compiling C/C++ with tricky new methodologies (fat pointers, or auxiliary pointers) to, again, remove entire classes of memory and threading bugs. Whether decades-old languages such as Python, Node.js, and friends can be hardened in similar ways, or will need to be rewritten from the ground up, remains to be seen. The world of open source is ablaze with experimental solutions.

For now, it’s less about a silver bullet and more about recognizing that vulnerability response has become a team sport at a scale nobody planned for. Every major bank, utility, and software vendor is running its own AI-augmented triage operation, and those operations increasingly need to talk to each other. The organizations that ask hard questions about triage speed, upstream commitment, and funding durability rather than taking a clearinghouse’s staying power on faith will be the ones standing strong under relentless vulnerability fire.        

—

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.

This series lays out a practical framework for taking generative AI (GenAI) from pilots to dependable production systems in the enterprise. It focuses on four disciplines that determine long-term success: engineering for scale and reliability, designing agentic systems with clear constraints, embedding governance directly into build and runtime controls, and measuring ROI at the workflow level with full cost and outcome visibility. The throughline is operational discipline—treating GenAI as a service with contracts, evaluation, ownership, and measurable business impact.

Post 1: Enterprise GenAI at scale

The first article in the series, “How to run enterprise generative AI like a production service,” focuses on operations. It explains why reliability, retrieval quality, latency control, cost routing, observability, and evaluation harnesses determine success at scale. The article lays out a practical architecture and operational checklist so teams can move from promising demos to stable, supportable systems.

Post 2: Agentic AI in the enterprise

The second article, “Agentic AI in the enterprise: How to balance autonomy with constraints,” defines what an agentic system is and how to operate one safely. It introduces the agent loop (plan, act, verify, commit), tool contracts, policy enforcement, durable state, and verification gates. The emphasis is on constrained autonomy, traceability, and operational ownership so agents can execute real workflows under enterprise controls.

Post 3: Governance by design

The third article, “Governance by design: Turning AI policy into executable controls,” treats AI governance as engineering work. It describes how to translate policy into executable controls in continuous integration pipelines and runtime enforcement layers. Topics include threat modeling, policy-as-code, lineage, audit evidence, and feedback loops. The goal is steady delivery under measurable guardrails.

Post 4: AI ROI beyond pilots

The final article, “AI ROI beyond pilots: Measuring outcomes in production,” addresses how to measure real business value from GenAI. It defines ROI at the workflow level, accounts for full life-cycle costs, and connects usage metrics to operational outcomes. It provides a metrics stack, cost equation, cohort rollout strategy, and a 90-day plan to produce credible, production-grade ROI signals.

—

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.

Bank of America has had to spend big on IT in response to an AI security audit and findings that its anti-money-laundering (AML) controls were lacking.

The bank was fined a whopping $1.2 billion for money laundering offences this week, after banking authorities identified a lax attitude to compliance.

“We understand the seriousness of compliance, and we are responsible for getting it right,” Bank of America CEO Brian Moynihan said on a conference call to discuss the company’s third-quarter financial results. “We have invested billions of dollars in technology and dedicated thousands of employees to combat financial crime,” he said, adding that “a couple hundred million” of that spending in the third quarter was on “remediation for the AML”.

The IT team had to spend a similar amount on fixing software vulnerabilities in its systems, a task that also required it to hire 1,000 consultants, Moynihan said.

The bank’s security vulnerabilities were revealed after the company received an early release of Claude Mythos Preview. In a report to the US House of Representatives Financial Services Committee, Anthropic said that Claude Mythos Preview “has already found thousands of high-severity vulnerabilities, including some in every major operating system and web browser.”

This article first appeared on CSO.

The best Python yet isn’t just faster than before. It’s also smarter at telling you what’s wrong, better at letting you profile applications, and loaded with new language features to give you a better programming experience.

Top picks for Python readers on InfoWorld

The best new features in Python 3.15
Python 3.15 is now GA, and it’s the best Python yet. Get your hands on its improved JIT compilation, lazy imports, more detailed errors, and all-new profiling superpowers.

Python’s new frozendict type, demonstrated
Ever wanted to use a Python dictionary where you needed an immutable type, like a dictionary key? The new frozendict type lets you do exactly that. This video demonstrates its powers and usefulness, along with its quirks and eccentricities.

Speed-boost Python with lazy imports
If you rely on imports with slow startup times, you can quit drumming your fingers or coming up with clumsy workarounds. Python’s new lazy import feature defers the delays.

Get started with Python’s new native JIT
Although still in its early stages, Python’s native JIT is yielding bigger performance gains with each passing revision. Learn how your Python code can speed up by as much as 20% with this feature, without your needing to change anything.

More good reads and Python updates elsewhere

What we learned about Rust for CPython at the Python Language Summing 2026
Rust is becoming part of the CPython codebase, chiefly for rewriting specific components like the zlib module. This article explains how that project is going (slowly and carefully), and what its goals are.

Making np.searchsorted up to 25× faster in NumPy 2.5
A fascinating deep dive into how NumPy’s binary search algorithm got a major performance boost. The bigger the array, the bigger the payoffs, especially when working with inputs bigger than your L2 cache.

Lifeguard: Static analysis for lazy imports in Python
Lazy imports are a great new feature, but they behave strangely in some corner-case scenarios. This tool scans codebases to determine if your code is fully lazy-import safe.

Polars 2.0 is here
This top-class dataframes library for Python just notched a major point release, which brings A-list support for SQL queries and tons of performance improvements overall.

Every quarter, I look at the capital expenditure numbers coming out of the major cloud providers, and every quarter, they manage to surprise me. This time, though, we’ve crossed into territory that’s genuinely hard to process. The five biggest US cloud and AI infrastructure providers (Microsoft, Alphabet, Amazon, Meta, and Oracle) have collectively committed to spending between $660 billion and $690 billion on capex in 2026, nearly doubling what they spent just a year ago.

Amazon leads the pack with a projected $200 billion, most of it directed at data centers and AI compute. Alphabet has committed $175 to $185 billion, up from $91 billion in 2025. Microsoft is tracking toward $120 billion or more, having already spent $37.5 billion in a single quarter. Meta is at $115 to $135 billion, and Oracle is targeting roughly $50 billion. For context, four companies alone plan to invest about $630 billion, a 62% increase from the record $388 billion they spent in 2025.

What are they buying? Mostly chips, buildings, and electricity. The spending splits across the AI data center stack: GPUs and custom accelerators such as Google’s Tensor Processing Units and Amazon’s Trainium, the physical data centers themselves with their liquid cooling and high-density floors, and often the power infrastructure to run it all, including power purchase agreements and even on-site gas-fired generation where the grid can’t keep up. Roughly two-thirds of the money goes to compute, and one-third goes to facilities, power, cooling, and networking, with the power share rising every quarter.

Where the market is heading

My take on the market is that we’re in the steep part of a demand curve that has a few more solid years left in it. Short-term demand over the next two years is already firm. Every hyperscaler reports being supply-constrained rather than demand-constrained, and Microsoft is sitting on an $80 billion backlog of Azure orders it can’t fulfill, largely because of power availability. Enterprises are panic-buying cloud capacity and computing gear right now because they’re convinced the AI boom will leave the unprepared behind, and they want their infrastructure in place so they can take advantage of whatever form the transformation takes. I get it. Nobody wants to explain to their board in 2028 why they spent 2026 waiting in line.

This means hardware vendors such as Dell, HPE, and IBM, along with the hyperscalers themselves, are going to see sustained growth as long as the demand continues. Some of it is real, and some of it is fear driven, but for the vendors, it all spends the same. The shortages enterprises are seeing today for processors and RAM, along with the associated price increases and stretched lead times, will most likely persist through that window because global silicon and memory supply is being absorbed by AI clusters faster than the manufacturers can expand it.

But my long-term forecast is deliberately less rosy than the providers’ own. The build-out cycle runs three to four years from commitment to full utilization. A lot can change in the AI market in that time. Model efficiency improvements could slash compute requirements per unit of output. Enterprises may discover that their AI workloads don’t justify the cloud spend once the novelty fades. Competitive dynamics could compress pricing. By 2028 and 2029, I expect the growth rate to be real but not at the scale builders assume today, and I expect the industry to carry the weight of capacity committed in the panic phase of 2026.

Are vendors overbuilding?

Here is where I part ways with the prevailing wisdom, and where I think we need some disciplined skepticism. The thinking right now is that for every bit of data center capacity you build, someone will use it, if not the hyperscaler that owns it, then some other tenant. Given Microsoft’s $80 billion backlog, that logic holds for the near term.

But I’ve been around long enough to be suspicious of “this time is different” arguments. I watched the fiber overbuild in the late 1990s, and I watched the first cloud buildout get ahead of itself as well. The concern is that the cloud providers are getting out over their skis, building capacity for demand that may not show up at the scale they’re projecting. The revenue those investments depend on is largely speculative. If AI adoption progresses more slowly than anticipated, or if efficiency gains reduce the compute required per workload faster than expected, the return on this spending could disappoint badly. There is also the uncomfortable possibility that a meaningful share of today’s demand is circular: Enterprises and vendors may be panic-buying capacity from each other in a stack of commitments that may never consolidate into actual sustained workloads.

By the time these data centers come online—and we’re talking about capacity committed now for delivery in 2027—the growth may not be at the scale the builders are expecting. I expect many of the data centers being committed now won’t be utilized at the rates people are assuming today for 2029. That’s not a prediction of collapse. It’s an acknowledgement that the industry has seen a similar pattern before in fiber, colocation, and the first cloud buildout itself.

Advice for enterprise buyers

If you’re running enterprise IT, this cycle cuts both ways. In the near term, you’re facing higher prices, allocation limits, and longer lead times for processors, RAM, and cloud capacity. Budget accordingly, lock in what you genuinely need, and resist buying out of the fear that drives the very shortages you’re suffering from.

But in the next few years, the picture flips. Overbuilt supply means lower prices. If the providers overshoot, then cloud rates soften and less expensive data center space becomes available for enterprises that need it, including capacity for your own AI ambitions at prices that would be unthinkable today. The overbuilding that will burn the hyperscalers’ investors will create a bargain for their customers.

The playbook I recommend is the one I’ve always recommended. Architect for the cloud on your own terms, stay out of long-term capacity commitments you can’t justify with current demand, and let the providers take the utilization risk. They’re betting hundreds of billions that the demand curve keeps climbing. You don’t have to make the same bet to benefit. The oversupply, if it comes, will find you, and at a price you’ll like a lot better than today’s.

Current security procedures for training AI models are inadequate, hundreds of AI researchers have warned governments and the AI community. They are calling for tougher rules and the establishment of a new international body overseeing best practice for AI development.

In an open letter the AI specialists — 487, at time of publication, including many senior academics — called for more AI safety research and greater emphasis on containment technologies.

“Strong sandboxing mechanisms including air-gapping (disconnecting from the internet) should be used to provide high-assurance containment of cyber-capable AI models,” say the signatories, who include such luminaries as Geoffrey Hinton and Yoshua Bengio.

The experts said that a new international body, to be set up in consultation with governments and a wide range of AI and security specialists, could set new safety standards but also act as an organization to which containment failures could be reported, improving transparency for learning and accountability purposes.

The scientists’ demands go further than some recent calls for greater regulation of AI. Earlier this week, Microsoft president Brad Smith said AI is less regulated than washing machines or milk, although he made no firm proposals to rectify the situation. And the UK parliament is looking at ways to improve AI security, although any moves will be hampered by disagreement among AI businesses. 

Hinton and Bengio are no strangers to this kind of scientist-led initiative. In October last year, they signed an open letter warning of the dangers of developing super-intelligent AI. The letter appears not to have affected AI’s breakneck development; it remains to be seen whether AI players in boardrooms will heed the warning.

This article first appeared on CSO.

Although the Jev model rolled out last month by TypeSafe claims to have significant advantages over traditional LLMs, a security report published Wednesday argued that its streamlined approach makes it more vulnerable to some kinds of attack, compared to traditional LLMs.  

“In some cases, [Jev] is even more vulnerable to attacks, with both adversarial text attacks and prompt injection being able to disrupt the model’s outputs, resulting in incorrect and potentially devastating actions,” said the blog post from researchers at HiddenLayer. 

TypeSafe did not respond to multiple requests for comment. 

LLM, or something else?

There seems to be debate about whether Jev is technically a large language model (LLM), with TypeSafe suggesting it is not, but HiddenLayer saying that it appears to be one. TypeSafe has even coined a name for the category: System One, which TypeSafe described as “a new class of frontier models built to make fast, structured decisions that software can use directly.” Jev is the first—and thus far, only—named product categorized as System One.

Jev is a streamlined model designed to function machine-to-machine. Its approach allows it to perform tasks faster and to use fewer tokens. But Kasimir Schulz, the director of security research at HiddenLayer, the blog’s co-author, said that the accelerated approach robs Jev of some of the checks and balances that exist in traditional LLMs. This means that Jev can fall for some attacker tricks that current LLMs typically detect and refuse, he said in an interview. 

Despite this, “Jev is great. You should use it. It has a lot faster response time,” he said, with the caveat “it doesn’t have all of the protections” seen in traditional LLMs, so some attacks on it succeed that should have failed. 

“TokenBreak, for example, normally does not work with larger LLMs, but Jev is vulnerable to it out of the box,” Schulz said. 

Although simply inserting characters in front of important words, as in the original TokenBreak attack, did not yield much, HiddenLayer’s blog noted, “we did notice that increasing the number of perturbations and improving their targeting led to much higher attack success rates.”

But although traditional LLMs are typically able to see through such attacks, it pointed out, “System One models appear to be vulnerable. As a result, this class of decoder should be treated with caution, given that they are susceptible to both autoregressive LLM attacks and text classifier attacks, providing potential adversaries with greater optionality.”

The post cited some examples: 

“On a simulated checkout page, an attacker-controlled advertisement caused the browser agent to click away from the user’s purchase [and respond to the ad] despite instructions to treat page text as untrusted,” it said. “In a separate classification test, targeted TokenBreak-style changes lowered toxicity scores for prompts both models had initially flagged.”

The post argued that multiple risks are therefore associated with Jev. 

“A browser agent may immediately click a selected element. A moderation system may allow an input whose toxicity score falls below a threshold. A routing system may send a request to a different tool or workflow. Each of these turns a model judgment into an operational decision, and therefore, risk,” the post said. “When evaluating System One models, test those decisions in the application where they will be used. Include untrusted webpages, misleading task-related text, and modified inputs that preserve their meaning while changing their form. Monitor the selected actions and scores and put independent checks around outcomes that matter. Keep in mind that, under the hood, these are still language models at heart.”

Analysts agreed with both the report’s methodology and its technical conclusions, while also pointing out that a security vendor concluding that a new approach is not secure is somewhat self-serving.

Philip Harris, an IDC research director, observed that the methodology described in the blog post “is sound, and consistent with established AI red-teaming practice: building a controlled test environment and probing for adversarial manipulation and injection is exactly the right approach.”

But Gartner VP Analyst Nader Henein added that Jev, which was introduced on Sept. 15, is so new that he thinks some of the flaw reports were premature.

“Jev will go through the same maturity process as do all other models, including susceptibility to seemingly rudimentary manipulation attempts,” Henein said. “This model was only released last month, so being surprised that it has issues is similar to being surprised when your baby drools.”

However, Frank Dickson, principal analyst at Dickson Research, noted that the same attributes that make Jev so attractive also expose it to riskier behavior.

“Jev can only choose from options the developer puts on the menu,” he said. “It limits attack paths. However, if ‘click any element on the page’ is on the menu, the attacker’s ad is on the menu. That is an architecture decision, and the buyer makes it.”

He pointed out, “Jev makes AI decisions faster and cheaper, which also makes the wrong decisions faster and cheaper. Speed is a feature. It is not a security control.”

Independent technology consultant Steven Eric Fisher agreed.

“Constraining the format of a decision does not necessarily constrain the correctness, trustworthiness, or consequences of that decision,” he said, noting, “the simulated checkout scenario [in the post] illustrates how an agent can be redirected from an authorized task by information introduced through a less-trusted component of its operating environment. The fact that the agent was explicitly instructed not to trust page content, yet still responded to the malicious advertisement, is particularly relevant.”

ServiceNow is giving its AI Control Tower new features to make AI agents more governable — and a new name, Super Intelligence Control Tower (SICT), to please the US President. It is also updating EmployeeWorks to make building AI agents easier.

AI Passport, a new component of SICT, gives every agent, whether from ServiceNow or a third party, a verifiable identity, and provides runtime control over its activities.

As enterprises scale autonomous agents from pilots to production, they are facing new challenges, said Nenshad Bardoliwalla, SVP of AI product management at ServiceNow: “If companies can’t identify which agents are running, what they are doing, and what systems they can access, then scaling quickly becomes a risk.”

An AI Passport is a cryptographically signed credential for AI agents that is checked at runtime to verify the scope authorized by the enterprise. When an AI agent stays within its passport scope, it can operate freely, but if it tries to deviate, defined actions are enforced. These can include redirecting, restricting, or reconnecting the agent with proper context, or even triggering a kill switch. All actions are audited so agent activity can be tracked.

It is built on open specifications, so any governance product, identity provider, or enforcement point can issue and verify credentials for their own and third-party AI agents, and those credentials are verifiable at every step in multi-agent workflows.

A bouncer at every door

This is a real step forward, said Frank Dickson, principal analyst at Dickson Research. “Most agent governance today is a security camera. It records what happened so someone can review the tape later. AI Passport is a bouncer at every door.”

The controls extend beyond ServiceNow’s own agents, he said: “For third-party agents, the passport replaces the agent’s own ‘claims’ about its permissions,” he said. “Taking an agent’s word for what it is allowed to do is an Achilles’ heel of agentic AI.”

And, he said, “A passport is only as trustworthy as the office that issues it. Here, the issuing office is ServiceNow’s CMDB, its GRC policies, and its workflow approvals. If that data is stale, the passport is stale. Credit ServiceNow for building on open specifications, but an open spec matters only when others adopt it. Nvidia is the launch partner, and ServiceNow says that enforcement implementation is still being built.”

In addition to AI Passport, ServiceNow has further beefed up its governance tools with a number of other features, including shadow-AI detection to locate unapproved agents on the network; more than 400 connectors to enable AI discovery across platforms and vendors; access mapping; and continuous enterprise AI observability.

It also announced cost governance; “value intelligence” that connects consumption, cost, quality, and “realized user value” to help teams optimize their AI use; AI cost management as part of ServiceNow IT Asset Management, which integrates with the Control Tower; and policy enforcement.

AI Passport, Shadow AI detection, and AI Cost Management are expected to be available by year end.

EmployeeWorks enhancements

The third generation of ServiceNow EmployeeWorks now lets employees add automations to the autonomous AI personal assistants they build. ToolSmith is a new agentic developer environment that takes tool building “from days to minutes,” the company said.

What companies have been trying to do, said Bhavin Shah, SVP of ServiceNow’s employee experience group, “is to give developers a way to build, but in a way that’s governed, that allows them to stay within the guardrails and the controls that that are required in order to do the kinds of safe but deep and capable work that they want for their constituents inside the company.”

ToolSmith helps address that problem. It’s a vibe-coding environment with which developers can build automations for ServiceNow EmployeeWorks AI assistants by describing what they need in natural language. ServiceNow said ToolSmith was trained on over 75,000 APIs and optimized for reliability and token efficiency. Developers can test and refine its output using the same conversational interface.

ServiceNow said that ToolSmith also identifies what to build next, scanning logs “to identify opportunities to fix, improve, or invent the next best workflow.”

Non-coding employees, on the other hand, can build new Productivity Assistants to perform contextual or persona-based work including long-running tasks, the company said. There are also pre-built assistants available, beginning with several for HR service delivery.

EmployeeWorks itself includes two assistants out of the box: a research assistant that can scan internal and external sources for answers, based on the user’s role, and a calendaring assistant that, ServiceNow said, “goes beyond typical calendar booking solutions by orchestrating nuanced requests like scheduling quarterly one-on-ones with an entire team on days that minimize disruption to project work or finding the least hectic day to bring together a team for a full day workshop. “

To automate repetitive tasks, Productivity Routines run proactively in the background, repeating routine steps and providing deliverables without human intervention. Employees just have to describe what they want to automate, select the necessary tools, and deploy the routine.

“The principle is right,” Dickson said. “The people closest to the work understand the problem best.”

But, he added, “the guardrails are only as good as the decisions behind them. Productivity Routines, by ServiceNow’s description, run in the background without human intervention. That is unsupervised work, and someone should own it.”

All of these EmployeeWorks enhancements are in controlled availability now.

Bottom line

Melody Brue, analyst in residence at Moor Insights & Strategy, said the announcements are a sign that ServiceNow is extending its existing security and workflow controls into a broader role in governing agent actions across systems.

“AI Passport makes identity and authorized scope verifiable, Control Tower provides oversight and enforcement, and ToolSmith expands the tools and connectors through which agents can act within enterprise guardrails,” she said, adding that with CEO Bill McDermott’s recent positioning of ServiceNow as a security company, “This suggests an ambition to become a control point for enterprise autonomy.”

But, she said, “What matters now is how consistently ServiceNow can enforce boundaries and verify outcomes across the systems agents actually touch.”

Dickson, too, has concerns.

“ServiceNow says Control Tower tracks spending by user, department, and runtime, and ties that spend to quality and value. The brake is another matter,” he noted. “The graduated alert, throttle, and block enforcement is described in future tense, as is the AI Cost Management integration, which is expected by year end.”

However, “a meter you can watch is not a brake,” he said. “A Productivity Routine that runs every morning is a standing purchase order. Someone should sign it.”

Give every agent and every routine a named owner and a budget before it goes live, he advised, and ask ServiceNow how assists are counted for background routines and whether hard caps exist today. Turn on throttling the day it ships, and reconcile its dashboards against your own invoices.

But despite these concerns, he said, ServiceNow has the right idea. “An agent should carry its permissions, its manager, and its budget wherever it goes. But until the brakes ship, that budget is a decision a person still has to make.”

This article first appeared on CIO.

Google has made daily token quotas generally available for BigQuery’s generative AI functions to give enterprises a way to limit AI consumption by project and individual user.

These quotas, which can be managed via the IAM and Admin tab in the Google Cloud Console, cover both input and output tokens at the project and individual-user levels per day and apply to the AI.GENERATE, AI.GENERATE_TABLE, AI.GENERATE_TEXT, AI.CLASSIFY, AI.IF, AI.AGG, and AI.SCORE functions.

Last year in November, the hyperscaler added AI-based SQL functions to its managed data warehouse and analytics platform to help enterprises reduce the complexity of running large-scale analytics, especially on unstructured data.

These functions, which use LLMs to prepare unstructured data for analysis, reduce the traditionally time-consuming process of preparing such data because SQL cannot understand its nuances and meaning.

However, embedding functions such as AI.GENERATE_EMBEDDING, also available as ML.GENERATE_EMBEDDING and AI.EMBED are not subject to these quotas because they run on different, substantially cheaper models, the company wrote in a blog post.

For the other functions, by default, input tokens are capped at 200 billion per project and 150 billion per user per day, while output tokens are capped at 20 billion per project and 15 billion per user per day.

The output token quotas also include the reasoning tokens used by the LLM, the company wrote, adding that enterprises also have the option to raise a request to increase these default quotas.

There is also the option to manage these quotas programmatically through the Cloud Quotas API, the gcloud CLI, and Terraform.

How BigQuery enforces token quotas

Beyond that, however, there are nuances to how the data warehouse platform enforces token quotas.

BigQuery rejects a query with a “QuotaExceeded” error if the token quota it needs has already been exhausted. If the quota runs out while the query is running, BigQuery stops sending new requests to the LLM, the company wrote in its documentation.

That means the results of a query can be affected.

For AI.IF, BigQuery can return partial results if the number of rows it cannot process stays within a specified error limit. If that limit is exceeded, the query fails, the company added.

For AI.GENERATE, though, the query can complete execution, but rows that could not be processed have no generated output and carry an error message in their status field, Google further explained.

To help enterprises avoid hitting these quotas while queries are running, Google has also added a new AI.COUNT_TOKENS function to help enterprise teams estimate token consumption before running an AI function.

However, that function too has limitations. It estimates input tokens only and does not count output or reasoning tokens, additional instructions added by the AI functions, or non-text inputs such as images.

This means the estimate may be lower than the workload’s actual token consumption.

To get a more accurate estimate though, the hyperscaler is recommending enterprise teams to run a small sample workload to measure actual token consumption before setting quotas for larger workloads.

Token quotas offer cost control, but FinOps remains essential

Despite these limitations, Pareekh Jain, principal analyst at Pareekh Consulting, sees the daily token quotas as an “important improvement” for enterprises and their CIOs scaling workloads in BigQuery.

“Earlier, unpredictable token usage could lead to unexpected costs. The new controls help CIOs manage spending, and cost predictability is an important factor in scaling any enterprise workload,” Jain said.

That cost predictability, according to Nhat Bui, deputy director of engineering at Scopic Software, could provide more data professionals with more freedom: “Analysts and data scientists can experiment with less risk of an expensive mistake.”

It also abstracts away the complexity of building mechanisms or dashboards to keep tabs on AI function-related spending in BigQuery, Bui added: “The basic guardrail is now built in: daily limits, usage history, and a function to estimate tokens before running a job. Teams no longer need custom tooling just to avoid a runaway bill.”

However, it does not abstract away the need for FinOps, said Manoj Chandra Jha, principal analyst at Nord-IQ Research.

“For CIOs, BigQuery’s token quotas cap the worst case, not the spending story.  They make it safer to say yes to AI in SQL, but they count tokens rather than dollars and offer no team or business-unit budgets, so finance still can’t see who is spending what,” Jha added.

“The smart play is to treat the quotas as a floor, set real limits, structure projects by team so each becomes a de facto budget line, and layer FinOps reporting on top, because predictability without attribution is only half a governance strategy,” Jha further said.

The bigger challenge for enterprises will be balancing the trade-off between cost control and production reliability, Bui noted.

The lower the token limits, the greater the control over AI spending, but the higher the risk of disrupting production workloads, as queries may fail or return incomplete results when quotas are exhausted before the daily reset, Bui said.

To balance these competing priorities, enterprises should separate production workloads from development and experimental workloads, giving the former more room to operate while keeping tighter limits on the latter, Jha said.

Enterprises should also build pipelines that detect skipped rows and process them again after quotas reset, Jha added.

For most of the history of enterprise software, accountability has been relatively easy to understand. A person logs in, a person has a set of permissions, and a person takes an action. If something goes wrong, you can usually work backwards from there.

Agentic AI changes that. We are moving from systems that suggest what someone should do to systems that can actually do it. Agents can access tools, call other systems, make decisions across multiple steps, and increasingly operate without a human approving every move. That is the point, of course. An autonomous system that needs someone hovering over every decision is not particularly autonomous.

But the more action we hand over, the more important one deceptively simple question becomes: When an agent does something, who did it?

Not philosophically. Operationally. Whose authority was it using? What was it allowed to touch? Who granted those permissions? And if something goes wrong, who owns the outcome?

Accountability starts with identity

The first question is what an agent actually is inside your organization. Should it always be treated as a delegate of a human, acting on that person’s behalf and inheriting some version of their permissions?

That model makes accountability relatively straightforward. If my agent does something, the action can be traced back to me. But it becomes harder to sustain as agents become more persistent and autonomous.

An agent might run continuously or serve an entire team rather than one person. It might perform a business function that continues long after whoever originally configured it has moved on. In those cases, should the agent have an identity of its own? And if it does, who creates that identity, who owns it, who grants its permissions, and how long should those permissions last?

Identity is where accountability starts because if you cannot reliably answer who the agent is, everything that follows becomes harder to reason about.

Identity and permissions are closely related, but they are not the same thing. Consider an agent designed to conduct research using public information. It might be perfectly reasonable for that agent to use a public model, external tools, or public Model Context Protocol (MCP) servers. Now point that same capability at internal finance data.

The agent has not fundamentally changed. Its environment has.

Suddenly, sending information to an external model may be unacceptable. Certain tools may need to disappear from its reach. Data that could previously move freely now sits inside a very different compliance boundary. So permissions cannot simply be a static list attached to an agent. They need to reflect who the agent is, what it is trying to do, and the context in which it is operating.

That becomes even more important when agents can choose different tools and paths through a problem rather than following a completely predictable workflow.

Delegation gets complicated quickly

Now add sub-agents.

An agent receives a goal and creates several others to complete pieces of the work. Do those sub-agents inherit the parent’s identity? Do they inherit its permissions? Should their authority be narrower based on the task they have been given? And who ultimately owns what they do?

There may not be one universal answer, but there does need to be an answer inside the enterprise. More importantly, there has to be a through line.

An agent can delegate execution to another agent, which delegates part of that task again. That cannot mean accountability disappears somewhere along the way. Autonomy can branch. Accountability cannot disappear.

Enterprises need to retain the relationship between the original authority, every agent involved, the permissions each one carried, and the actions they ultimately took. Otherwise, when something goes wrong, everyone gets to participate in a very expensive game of “whose agent was this?”

The same problem appears over time, not just across agent chains. Consider a long-running agent that constantly monitors tickets and takes action. Eventually, it becomes part of normal operations. Then the person who created it leaves the company.

The agent stays.

Who owns it now? Did responsibility automatically transfer to the person’s manager? Was a successor assigned? Does the team own it? Does the enterprise? And what happens to permissions that were originally linked to someone who no longer exists in the organization?

We already manage life cycles for employees, service accounts, and enterprise applications. Agents need the same seriousness. They need an ownership life cycle, not simply a deployment life cycle.

Accountability has to exist in the system

Defining ownership is only useful if you can reconstruct what actually happened. That means connecting an agent’s identity to its permissions, actions, tools, sub-agents, and eventual outcome.

If something fails, the organization should be able to understand what happened, why the agent was allowed to do it, which permissions enabled the action, which agent actually performed it, and where the control failed. That is what makes remediation possible.

This is why identity, permissioning, and execution tracing cannot live only in policy documents. Writing down who owns an agent is not the same as encoding that ownership into the systems governing it. Telling an agent not to access something is not the same as preventing access. And asking teams to piece together an incident afterwards is not the same as tracing execution while the system is running.

The goal is not to put a human approval step in front of every agent action. That would defeat much of the value of autonomy. The goal is to move humans up a level, from making every individual decision to defining the boundaries within which autonomous systems can make them.

As agents take on more work, enterprises need to know what they can do, who owns them, how authority is delegated, and how every action can be traced.

Because the question is no longer simply whether an agent can act. It is whether, when it does, the organization can still answer who.

—

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.

Most teams building AI agents are pouring effort into better memory, longer context windows, conversation summaries, retrieval systems that pull up anything the agent has ever seen. These are useful tools. But they do not solve the problem of knowing whether an action actually completed. Memory tells an agent what happened. It doesn’t tell the agent what’s true right now. And for any agent that takes real action — refunding money, changing an order, updating an account — that distinction is the whole ballgame.

Memory can remember a request without knowing the outcome

Picture a customer service agent that approves a refund. The refund actually goes through, but the confirmation response times out before the agent hears back. From the agent’s point of view, all it has is a record of a request it made, not proof of what happened next. If the agent trusts its own memory, it sees an unfinished task and tries again. The reasoning is sound. The second refund is still wrong.

More conversation history doesn’t fix this. What the agent needs is a record it can trust: the request ID, the current status, the confirmed outcome. Memory can tell you what the customer asked for. It can’t tell you what another system actually did. This isn’t a new problem; recommendation systems ran into a version of it years before agents existed.

A prediction is not the same as current intent

I spent several years building recommendation and personalization systems, and one thing became clear fast: more history doesn’t automatically mean a better decision. A recommender looks at what someone bought, browsed, or listened to, finds a pattern and predicts what they’ll want next. These are all informed guesses rather than facts. I saw this play out around election season. A customer buys several books about a candidate or a political topic and the system, correctly, learns that as an interest. Weeks later, the election is over and the customer has moved on, but their purchase history hasn’t changed. The purchase history is still accurate. It just no longer reflects the customer’s current intent. So, customer data changes with each interaction, so recommendations need to respond to new information.

Freshness in a large-scale personalization system

Early in a real-time personalization platform I worked on, one of the hardest problems wasn’t traffic volume; it was freshness. A customer’s inferred interests could lag well behind their actual recent behavior, so the system would keep confidently recommending things that no longer matched what the person wanted. We rebuilt the pipeline so that signal updates reflected recent behavior almost immediately instead of with a long delay. That gap between what the system knows and what’s currently true is small when you’re recommending a book. It’s a much bigger problem once you move from recommending content to an agent that’s authorized to act on someone’s behalf. Consider a customer who has just started a trial and is eligible for a $0 first-item offer. Personalization should show that available benefit instead of another invitation to start a trial. A fresh eligibility signal lets it change the next offer. Unlike inferred interests, trial eligibility is a recorded fact.

Stale data can produce a bad recommendation. Stale data acted on by an autonomous agent can produce a real-world mistake. Agents need more than memory; they need a reliable state.

Reliable state tells the agent what’s true right now

Reliable state is a verified record of a specific operational fact. In the refund example, the conversation records what the customer requested. The payment system records whether the refund happened. The order system records the order’s status, while current policy and permission records determine whether the action is allowed. Each fact has its own authoritative source. State can itself become stale, so the agent must check the relevant source rather than rely on its memory of an earlier answer.

This matters even after the “yes/no” check passes. A customer might withdraw permission mid-process. An order might fall outside the window where changes are allowed. And even when every check passes, the action itself can still fail partway through, so the agent also needs a safe way to retry without duplicating the damage. The action system must enforce current permissions and other preconditions when it executes, because they can change after an earlier check.

Designing a privacy-request architecture

In privacy and compliance architecture work I’ve done, a single customer request, like asking to delete their data, can trigger a long chain of downstream effects across many internal systems. The challenge wasn’t any one system doing its job correctly; it was making sure there was one authoritative, centralized place that recorded whether the overall request had actually been completed, rather than each system independently assuming it had. That’s the same principle an agent needs: a system of record it defers to, rather than trusting its own memory of what it asked for.

A few categories of tooling exist specifically to solve different slices of this “what’s true right now” problem:

• Business state/workflow databases, Postgres, DynamoDB, Spanner, Cosmos DB.
• Workflow orchestration, Temporal, AWS Step Functions, Azure Durable Functions.
• Agent state, tools like LangGraph checkpoints.
• Session/cache state, Redis, Memcached.
• Event history, Kafka and similar streaming systems.
• Permission state, Open Policy Agent, Amazon Verified Permissions.

None of these replace the others. A production agent usually needs several of them working together, which raises the next question: what happens when an action only partly succeeds?

Safe actions need a receipt and a recovery plan

Every important action an agent takes should carry a unique identifier, like a receipt number. If the response gets lost, the agent must reuse that ID for the same intended operation. The receiving system must recognize the ID and prevent the operation from being applied twice, within its supported deduplication window. This is how an idempotent API makes retries safe; attaching an ID alone is not enough. A preliminary status check cannot prevent two concurrent requests from executing the same action. The AWS Builders’ Library explains this design in Making retries safe with idempotent APIs.

Teams also need reconciliation, regularly comparing what the agent believes happened against what the system of record actually shows, the same way you’d check a receipt against a bank statement. When they disagree, someone needs a clear next step: recheck, reverse the action, or escalate to a human. None of this works without clear ownership.

Reconciliation at high transaction volume

In large-scale commerce infrastructure work, we treated “did this transaction actually complete” as something that could never be answered from memory or assumption, at high volume, even a small rate of unconfirmed or duplicated actions adds up to real customer impact. We built reconciliation directly into the system so that what one part of the pipeline believed had happened was continuously checked against what was actually recorded, with idempotency built in to prevent retries from creating duplicate transactions. The lesson generalizes directly to agents: never let an action retry blindly without checking a source of truth first.

Before you give an agent more autonomy, decide who owns each critical fact and who’s responsible for cleanup when something breaks, because something eventually will.

Monitor the decision, not just the model

All of this changes what a team should actually be watching. Latency, cost and model accuracy matter, but none of those metrics will tell you that an agent acted on a stale permission or announced a refund that never happened. For each consequential decision, trace the information used, its freshness, the rules checked, the attempted action and the confirmed result. What you actually want to be able to trace is:

• what information the agent used
• when that information was last updated
• which rules were checked before acting
• what action was actually attempted
• what result was recorded afterward

As a leader, the job isn’t just watching model quality; it’s making sure every piece of information an agent acts on has a clear source and a way to verify it’s current. Agents are genuinely good at interpreting messy, ambiguous situations and deciding what to do. But they shouldn’t be the record of truth themselves. That job still belongs to the systems built to hold it.

Memory tells an agent what happened. Reliable state tells it what’s true now, and whether it’s safe to act.

Using vibe coding to scratch an itch has many of the same issues as using low-code and no-code development tools. That’s not surprising. Putting together something quickly to solve a specific problem lacks the level of discipline of software engineering, introducing inefficiencies that come from not following architectural guidelines and policies.

I recently reviewed the AI-generated code I used to quickly build a PDF archive of some HTML-formatted content. The program used common libraries in unusual ways, often combining three or more libraries when all the necessary calls were in one, with a program flow that was hard to understand in places. The result was at best unmaintainable. The only way it was acceptable was that I’d thrown it together in an hour to solve a specific problem, and once I’d built that local PDF archive I could simply throw the program away.

But what if your sloppy AI-generated code was needed by an entire department, or had become part of an essential business process? The risk is that something, somewhere, would inevitably change, and that essential business process would fail, with no practical way of fixing the code. The risk only compounds when the author has left their role and there is no one left who remembers or understands the initial prompts that produced the code.

Adding AI-powered coding tools to products and platforms is risky. But they are too useful to ignore. Like low-code tools, AI tools put coding in the hands of the people who understand the business problems and helps them automate processes on their own schedule.

What’s needed is a way to improve the harnesses used by the coding agents, taking concepts from specification-driven development and using them to build guardrails and standards into the code they produce, with the aim of building code that’s maintainable.

Introducing Rayfin Fabric Apps

Microsoft Fabric is intended to be where all your businesses operational data lives, offering a way to query and explore data at scale. It builds on a mix of big data and data warehousing concepts, using open formats for storage and data mirroring tools to bring data from existing applications into its data lakehouses, as well as supporting streamed data.

Microsoft Fabric allows you to build and deploy your own agents inside the platform to work with your data. However, in many cases, you will need a more focused approach to exploring and using defined subsets of data. The recent addition of Fabric Apps to the platform allows business analysts to deliver applications that use data in Microsoft Fabric to provide essential business insights.

Fabric Apps are built on top of Rayfin, a new TypeScript-based SDK that is designed to work with both humans, via CLI, and AI agents. A partnership with Replit allows Microsoft Fabric users to build apps using Rayfin and AI assistance in Replit and deploy them directly into Microsoft Fabric. Here Replit support is best thought of as a tool for business users, whereas developers can use tools like the GitHub Copilot CLI and Visual Studio Code, which let you mix traditional and AI-supported development processes.

The intent is to provide the tooling that business users need to create data-powered applications inside Fabric, making application development part of the process of exploring data. Rayfin apps can be connected to raw data or draw on semantic models built with tools like Power BI, using DAX for analytics rather than SQL or KQL queries.

Data app development tools for coders and non-coders

The key to this approach is the open-source Rayfin SDK, which offers a way to build out the necessary definitions for data models that can then be used by agent-based tooling. The SDK allows you to set up access to specific models, along with the necessary permissions, before users begin to build on them. Rayfin turns those models into GraphQL endpoints, with TypeScript clients sitting between them and the data stored in Microsoft Fabric — adding an extra layer of protection as the APIs are automatically type safe.

Building a Rayfin-powered Fabric App starts with using Rayfin to define a data structure with decorators that apply types to the data you want to use in your application and defining each table as a class. For example, a table of employee names and contact details would be exposed as an entity that contains an employee class, with decorators that create ID number, name, and address strings, all using structures held in the @microsoft/rayfin-core definitions. Other options allow you to begin to define access controls around the data, so that it can be used only by authenticated users with the correct group privileges.

This is the most important part of any Rayfin-based application development, as it’s here that you’re setting up the guardrails for ongoing user-led development. You’re not limited to one basic application scaffold, either, as there are a series of different templates available to help you get started, from a ready-to-use “to-do” application that illustrates the structure of a complete Rayfin application, to applications that use Microsoft Fabric’s authentication framework to control access to data.

Using Rayfin from the command line

Microsoft provides a process for getting Rayfin scaffolding in place, starting with setting up an application template, then logging in to Microsoft Fabric via Entra ID. Once you’ve completed these steps you can run Rayfin’s development loop to create a runtime and configure the Microsoft Fabric back end, before deploying the base application scaffolding. You don’t need to do this manually; Microsoft’s documentation includes a ready-to-run prompt for your coding agents.

You can now define your data entities. These are placed in a specific directory within the application scaffolding, with separate TypeScript definitions for each class. While you can put all your definitions in a single file, having separate files for each entity makes more sense, as it keeps applications maintainable. Once you’ve added the entities you plan to use, you can rebuild the scaffolding and redeploy, ready for testing.

Usefully this technique lets you separate the back end and front end, ensuring that back-end services and entity definitions run in Microsoft Fabric using its authentication and security framework, with application code running on development hardware (and eventually on separate servers or as part of a local application). This is where you will develop Rayfin functions, TypeScript applications that access and process the defined entities, with predefined typed connectors to work with data already stored in Microsoft Fabric. Rayfin functions can call any HTTPS API, allowing you to mix Microsoft Fabric data with information from any other line-of-business application or service. They’re also where you put the business logic for any Fabric application.

Structuring apps to be coded by machines and managed by humans

Building with the Rayfin SDK produces a predictable application structure with YAML configurations and TypeScript code. That code can be tested locally against a Microsoft Fabric back end. When ready to be deployed and shared, it can be uploaded to Microsoft Fabric, which hosts both the Rayfin function code and any front-end assets. Apps will require Microsoft Fabric capacity to work, and can be accessed from inside the Microsoft Fabric portal, though users can access apps via published endpoints through their browsers.

Rayfin is one of the first examples of a new generation of SDKs and development tools that support both humans and agents. The human-readable Rayfin documentation is paired with an identical set of markdown files, ready for use by any agent working on Rayfin code. Microsoft’s partnership with Replit provides a coding agent to build Rayfin applications and a rendering canvas with familiar Power BI features, providing a place for non-coding business users to experiment with Fabric Apps using AI.

The strict structure Rayfin imposes on Fabric Apps aims to bridge the gap between AI-powered coding and traditional enterprise application development. By putting all the components of an application in a rigidly-defined environment, Rayfin helps ensure that AI-generated code remains secure, compliant, human readable, and human maintainable. Business users can quickly put together Fabric Apps with Rayfin and Replit. Then, if a Fabric App proves to have utility outside a narrow group of users, it can be transferred to the enterprise’s development team for further refinement and long-term operations.