The debate over junior versus senior developers has taken on new urgency in the AI era. Large language models can generate code faster and cheaper than ever, prompting some executives to ask whether junior developers are still necessary. But that question misses a deeper point: younger developers, precisely because they are less invested in existing workflows, may be the ones who can rewrite the rules of software development. At the same time, experienced engineers bring judgment, security awareness, and architectural discipline that no model can replace. The most successful enterprises will need both.

Key Facts

• Enterprises are investing heavily in AI but seeing uneven returns.
• The industry debate often pits junior developers against senior developers, but both are needed.
• Historical examples show that many computing giants made their biggest contributions in their early twenties.
• The 'Dynamo and the Computer' analogy explains why swapping old tools for new ones rarely transforms productivity.
• Real AI gains require redesigning workflows, not just adding copilots or agents.
• Experience helps engineers see risk but can also make them overconfident in old methods.
• Junior developers can challenge outdated assumptions, while senior engineers provide guardrails.
• Leaders should mix teams, define golden paths, and reward deletion of obsolete processes.

Age and authority are not the same thing

History offers a useful corrective to the assumption that wisdom always arrives with gray hair. Many of computing's foundational contributions were made by people in their early twenties. Bill Joy wrote the vi editor at 22. John Carmack created Doom at 23. Linus Torvalds launched Linux at 22. These figures did not wait for decades of experience before changing the industry. Their relative inexperience may have helped them ignore assumptions that older experts took for granted.

None of this means young people are inherently smarter. They are not. Nor does it mean experienced developers should be sidelined. That would be foolish. The point is that during periods of major technological shift, experience can be a mixed blessing. It helps engineers see risk, but it can also make them overconfident in old methods. The challenge for enterprises is to balance youthful experimentation with seasoned guardrails.

The factory does not redesign itself

To understand why so many AI investments underdeliver, consider a classic historical parallel. In 1990, economist Paul David published a paper titled 'The Dynamo and the Computer.' His argument was simple but powerful: electricity did not immediately transform factories. For decades, factories simply replaced their central steam engine with a single large electric motor while keeping the same layout, the same workflows, and the same assumptions. Electricity was new, but its potential was stifled by force-fitting it into old factory systems.

The real productivity gains came later, when factories stopped treating electricity as a cleaner steam engine and started redesigning work around smaller motors distributed throughout the factory. Once each machine could have its own motor, the factory no longer had to organize itself around a single driveshaft. Work could be reorganized around the flow of production. The factory itself changed.

That is a decent description of where many enterprises are with AI today. Companies are buying copilot licenses by the thousands and wiring agents into existing applications. Then they wonder why results are uneven. This is the equivalent of swapping a steam engine for an electric one and declaring the modernization work done. It is not. Not even close. The real payoff will not come from asking AI to write the same tickets a bit faster. It will come from changing how teams define work and how—and what—developers build. The factory has to change.

So here is the uncomfortable question: Who is most likely to build the new factory?

Experience cuts both ways

There is an obvious danger in romanticizing youth. Plenty of bad software has been written by people with unlimited confidence and limited context. Enterprises need software that works, but 'works' also means it complies, scales, respects security boundaries, and survives contact with real users. This is where experienced developers matter—a lot.

In the agent era, engineering judgment becomes more important than ever. AI makes it easier to generate code, but easier code generation can become easier technical debt generation. The limiting factor shifts from 'Can we create something?' to 'Can we create the right thing, in the right place, with the right constraints?' That requires taste. Senior engineers often have that taste because their experience has taught them why a weird validation rule exists, which customer depends on undocumented behavior, and why a simple schema change can turn into a multi-week migration.

But experience also has a shadow side. It can make the current process feel inevitable. A senior engineer may see an AI assistant as a faster autocomplete because that is the easiest way to fit AI into an existing mental model. A junior developer, less invested in the old workflow, may ask more interesting questions: Why are we doing this ticket at all? Why isn't the spec executable? Why can't the agent generate the test harness first? It is not that experienced developers do not know these questions. They may simply lack the energy to rage against the machine.

The value of inexperience

The worst way to use junior developers in the AI era is to treat them as cheaper versions of senior developers. That was always a bad idea, but AI makes it worse. If the job is 'take this ticket, generate some code, and send it to a senior person for review,' the junior developer becomes a human wrapper around a coding assistant. That helps no one. The junior does not learn much. The senior gets buried in review. The enterprise ends up with more code, which is hardly a good thing.

Instead, junior developers should be given room to explore new workflows, with just enough oversight from experienced colleagues. That might mean giving newer developers interesting questions to answer, such as:

• How would we redesign onboarding if every internal API had an AI-readable contract and examples that actually worked?
• How would we change code review if the agent produced a change summary, test evidence, dependency risk, and rollback plan with every pull request?
• How would we build features if product requirements were written as executable acceptance tests rather than vague prose?
• How would we reduce toil if agents could safely perform routine migrations, dependency updates, or incident triage within clearly defined boundaries?

These are not toy problems. They are not 'junior work.' They are exactly the sort of process redesign that enterprises need but generally avoid because everyone is too busy running on the existing hamster wheel.

Finding the balance

So what should engineering leaders do? First, stop treating AI adoption as an individual productivity contest. The industry seems to be moving away from the idea that 'lots of tokens' equals 'great engineer,' but the fact that it flirted with that idea at all is damning. Measuring AI productivity in lines of code written is a mistake. The better question is: What part of our software delivery process no longer makes sense? AI's biggest gains will come when organizations change how they specify, test, review, and ship software.

Second, mix up AI workflow teams. Not committees or PowerPoint-producing centers of excellence, but small groups that combine two or three newer developers who are already fluent in AI-native tools with two or three senior engineers who understand production, security, architecture, and organizational constraints. Then give them a real workflow to redesign, such as dependency upgrades or test creation.

Third, make the senior engineer's job less about saying no and more about defining the guardrails within which others can say yes. Golden paths are key to using AI effectively. Good senior engineers should define the paved roads: approved patterns, test requirements, observability standards, and other boundaries. Then let junior developers and agents move quickly inside those boundaries.

Fourth, reward deletion. This may be the most important point. Going back to the factory electricity metaphor, AI modernization will fail if organizations simply add AI without removing outdated processes. Every new tool layered on top of an old workflow adds complexity. Teams need incentives to eliminate unnecessary approvals, obsolete documentation, redundant meetings, and legacy handoffs that no longer serve a purpose.

Bring everyone to the table

The future of software development will not belong to the young. It will not belong to the old, either. It will belong to teams that combine the talents of both.

Newer developers often bring impatience. They are less likely to accept the existing workflow as sacred. They are more likely to try weird tools, compose them in unexpected ways, and wonder why enterprise software development feels like a ritualized exercise in waiting for permission.

Experienced developers bring judgment. They know that software has users, auditors, attackers, budgets, latency, history, and consequences. They know that the right answer is often boring, and boring is good.

Enterprises need both. They need the developer who asks why the factory is still organized around the old driveshaft, and they need the developer who knows which machines will kill someone if moved casually. Every development team needs people who know why the old system exists—as well as those who do not.

Source: InfoWorld News

For the past several years, the technology industry has trained users to think of AI as a centralized service. People open an application, send a request over the network, and a hosted system in a remote facility returns the intelligence. Chatbots, image generators, coding assistants, and enterprise copilots have followed this pattern. The model lives elsewhere. The data often travels elsewhere. The user is a client. RTX Spark challenges that assumption by asking a simple question: what if the model, the agent, the data, and the application could all live on your own computer?

This is more than a faster PC. It is a new architectural premise for personal computing. Nvidia is not only selling hardware; it is selling a different way to distribute AI. The cloud remains powerful, but the default assumption that serious AI must be centralized begins to weaken when a local system can host persistent agents, run inference, and even fine-tune certain classes of language models.

Features, functions, and specifications

On paper, RTX Spark is designed to be a highly capable local AI system. Nvidia has described the platform as combining AI acceleration and RTX graphics on a single chip for thin laptops and small desktops. Public specifications indicate configurations with up to 6,144 Blackwell GPU cores, up to a 20-core CPU, up to 1 petaflop of FP4 AI performance, and up to 128GB of unified memory. These are not ordinary PC numbers. They are clearly intended to support serious local AI workloads, including model inference, agent orchestration, and lightweight model customization.

The unified memory approach is especially important. In traditional PC architecture, the CPU and GPU often use separate memory pools. That separation can become a bottleneck when running large models, because data must be copied between memory spaces. By contrast, RTX Spark’s design is intended to make it easier for the system to host and run AI models locally. Unified memory allows the CPU, GPU, and AI accelerators to share a single high-bandwidth pool, which can improve efficiency for large language models, computer vision systems, and multimodal applications.

Nvidia is also careful not to frame the system as only an AI box. The company is marketing RTX Spark for gaming, creative applications, AI development, and agentic workflows. This is a smart move. If the platform were positioned only as a developer experiment, it would remain niche. By presenting it as a capable computer first and an AI workstation second, Nvidia can appeal to a broader audience of creators, engineers, researchers, and technical professionals who want high-end graphics and local AI in the same machine.

Pricing and market positioning

Pricing remains uncertain because Nvidia has not published a universal price for every RTX Spark laptop or desktop. The platform will appear in products from different manufacturers, which means prices will vary by configuration, memory, storage, and thermal design. The best available indicator comes from the related DGX Spark desktop, which has been listed at about $4,699, though early estimates placed it between $2,999 and $3,999.

That range gives a useful way to think about the broader category. These are unlikely to be inexpensive mainstream PCs, at least not at launch. They are more likely to arrive as premium systems aimed at developers, technical professionals, creators, and early adopters willing to pay for high-end AI capabilities on the device. Over time, the category may broaden as manufacturing scales and competition increases. For now, however, this looks like a new high-value, high-cost category rather than a commodity PC refresh.

The premium positioning matters because local AI is not free. Running models on a laptop or desktop requires powerful hardware, efficient cooling, and significant memory bandwidth. The cost of that hardware is passed to the buyer. In exchange, the buyer gets privacy, lower latency, offline capability, and control over the AI stack. For some users, that trade-off is worth it. For others, cloud subscriptions and API calls will remain cheaper and more capable.

What is the real purpose?

The most important thing about RTX Spark is not the chip. It is the purpose behind the chip. This machine is ultimately built to run AI agents locally, and that is a bigger deal than it may seem at first glance. An AI agent is more than a chatbot. It persists state, accesses tools, works across applications, remembers context, automates tasks, and increasingly acts as a software-based worker. Nvidia is explicitly positioning Spark systems to run personal AI agents directly on the local machine, potentially around the clock. That creates a very different computing model from what most people use today.

There is another important layer to this story. These systems are also being positioned as platforms on which users can build and run smaller, more limited, locally tuned versions of large language model systems. Put plainly, a user may be able to create a model-based assistant that runs directly on the RTX Spark. It will not be as broadly capable as a frontier model operated by a hyperscaler. It is likely to be less generally capable, narrower in its expertise, and more constrained by local hardware limits. But it will be local, private, and responsive without relying on a remote API call to a hosted AI service hundreds or thousands of miles away.

Such a shift is conceptually significant. For years, the AI industry has conditioned the market to believe that serious intelligence must be centralized. RTX Spark suggests a future in which at least some intelligence becomes personal, portable, and self-contained. That does not mean every task will move to the edge. It means the edge becomes a legitimate place to run meaningful AI workloads.

Welcome to the revolution

The breakthrough here is not that local models will instantly outperform remote models. They will not. Frontier models trained on massive datasets with enormous compute budgets will continue to lead in general capability. But the architecture of AI use may begin to diversify. Today, the default assumption is centralization. The model, the knowledge base, and the application stack live in the cloud, and the user is simply a client. With systems like RTX Spark, that assumption starts to weaken. The model can run on the local machine. The agent can run on the local machine. Sensitive data can remain on the local machine. The application logic can be executed on the local machine. This changes latency, privacy, resiliency, and cost models. It also changes who controls the AI.

That does not mean the cloud goes away. Far from it. Enterprise use cases that benefit from centralized models and data will continue to exist. Businesses want the same knowledge base, business rules, database consistency, and governance model available to everyone. Centralization remains powerful because it reduces fragmentation and keeps systems aligned. A single-tenant, RTX Spark-based AI environment can be useful for certain projects, but it can also create islands of intelligence that do not easily share knowledge across teams and systems.

Possible use cases

The strongest potential use cases are in disconnected or semi-disconnected environments. Consider physicians doing diagnostic support in privacy-sensitive contexts, field engineers collecting and interpreting data in remote areas, military and public sector users operating at the edge, or professionals who need highly private, self-contained AI assistance without relying on constant connectivity. In those scenarios, the value proposition is very strong. Having the model, data, application, and agent all on one portable system is not a limitation. It is the point.

Other use cases include creative professionals who work with large media files and want AI tools that do not upload proprietary assets to a cloud service. Software developers building and testing AI features may prefer a local environment that mirrors production without incurring cloud costs during every iteration. Researchers working with sensitive datasets may need local inference to comply with data protection rules. Legal, financial, and healthcare organizations often face strict requirements about where data can be processed, and local AI can help meet those requirements.

The bigger question is whether mainstream enterprise AI will migrate in that direction. It is reasonable to remain skeptical that most organizations want hundreds or thousands of individually tuned, locally hosted models to replace centralized AI services. Local models can be harder to govern, update, and secure at scale. They can drift from corporate policy. They can duplicate effort. They can create shadow AI systems outside the visibility of IT departments.

That is why the more likely future is hybrid. Centralized AI will remain where shared knowledge, consistent governance, and massive scale matter. Local AI will grow where privacy, portability, latency, or disconnected operations matter more. RTX Spark does not need to replace the cloud to be important. It only needs to prove that a personal computer can be a serious AI platform in its own right. That alone would mark a significant shift in how the industry thinks about where intelligence lives.

Source: InfoWorld News

Key Facts

• Growing resistance to large AI data center construction is pushing some companies to explore distributed models, including small compute systems for residential settings.
• Pilot-stage discussions involve homebuilders, chip designers, and energy management firms, suggesting the idea has moved beyond hobbyist home labs.
• Housing affordability pressures are making homeowners more interested in monetizing underused spaces, from basements and utility rooms to detached structures.
• Several adjacent business models exist: controlled edge-host programs, decentralized compute marketplaces, and traditional infrastructure brokers.
• The main obstacles are residential power limits, inadequate broadband, heat, noise, security, insurance, zoning, liability, and customer trust.
• The realistic future is not mass residential data centers but selective, tightly managed micro-hosting in favorable locations.

As artificial intelligence accelerates demand for processing capacity, the data center industry faces a dual challenge: build enormous facilities fast enough to meet demand, or distribute compute closer to where it is needed. Large-scale data center projects have encountered local opposition over land use, energy consumption, water usage, and noise. That resistance is encouraging some companies to consider a more distributed model. The idea is no longer confined to hobbyist home labs or fringe edge-computing experiments. It is now credible enough to be discussed by experts in housing, energy management, and economic infrastructure. It is not mainstream, but it deserves serious examination.

Economic Forces at Work

The timing is not accidental. Homes are expensive, especially for buyers who purchased at elevated prices and interest rates. Mortgage payments weigh heavily on household budgets, while insurance and property taxes continue to climb. In this environment, homeowners are increasingly interested in turning underutilized parts of their properties into sources of recurring income. Spare rooms have become short-term rentals. Garages have become workshops or accessory dwelling units. Rooftops have become solar assets. Now, major players in housing and technology are considering basements, utility rooms, and detached structures as potential spaces for small-scale server infrastructure.

At the same time, businesses are under pressure to rethink where compute lives. AI is increasing demand for processing capacity. Edge workloads continue to grow. Not every application needs to run in a hyperscale facility, and not every business wants to pay hyperscale economics. There is strategic appeal in pushing workloads closer to users or into lower-cost, more widely distributed locations. Residential hosting becomes one possible answer to a question the industry is already asking: How much infrastructure can be decentralized without losing economic and operational control?

There is also a cultural shift. More technically capable homeowners now understand racks, uninterruptible power supply systems, network monitoring, remote access, and even local power upgrades. The old gap between enterprise infrastructure knowledge and prosumer infrastructure knowledge has narrowed. That makes the idea feel more achievable, even if the barriers to doing it commercially remain substantial.

Business Models Taking Shape

The most important point to understand is that there is not yet a large, polished market in which random homeowners openly host random third-party servers the way people list rooms on short-term rental platforms. What exists are several adjacent business models that point in that direction without fully embracing residential colocation.

One model is the controlled edge-host program. In this arrangement, a company places or manages compute equipment in selected distributed locations, often with strict standards for connectivity, power, and maintenance. The homeowner or site operator is not acting as an open colocation provider. Instead, they participate in a curated hosting network where the provider controls the service architecture.

Another model is the decentralized compute marketplace. These platforms allow individuals or smaller operators to sell spare compute capacity from their own hardware. This is closer to the economics of monetizing residential infrastructure. Still, it is not the same as taking custody of someone else’s physical server and being responsible for the environment in which it runs. Selling compute cycles is one thing. Housing enterprise hardware is another.

A third model is the traditional infrastructure broker or marketplace. These companies already match buyers and sellers for colocation, bare-metal, and related services. They are proof that brokering infrastructure relationships is a viable business. But those relationships generally connect enterprises to professional facilities, not to homeowners willing to make room for a small server farm next to a furnace or water heater.

In other words, the components of a market are visible. Distributed demand exists. Brokering exists. Willing hosts likely exist. But the residential version remains incomplete because the trust, standardization, and liability models are still underdeveloped.

The Upside Is Obvious

The strongest positive component of this potential market is its financial aspect. If a homeowner can generate enough monthly income to offset part of a mortgage payment, the idea will always attract attention, especially in newer housing markets where monthly carrying costs are high and people are seeking durable sources of supplemental income. Hosting infrastructure sounds like, at least in theory, a more stable and less socially intrusive way to monetize a property than opening a home to a constant stream of short-term tenants.

There is also an argument for asset utilization. Many homes contain underused spaces that could produce some economic return. A basement corner, a detached workshop, or a dedicated utility room may be worthless from a revenue perspective until someone turns it into something productive. If infrastructure providers are willing to pay for access to space, power, and connectivity, the home begins to function as part of the digital economy rather than simply as shelter.

For businesses, the appeal is equally straightforward. Residential locations may offer lower real estate costs, faster deployment, and better geographic distribution for select workloads. In regions with relatively inexpensive electricity and strong connectivity, a modest amount of residential hosting could fill gaps that do not warrant full commercial data center expansion. Homes will not replace data centers; rather, they might, in a very narrow set of circumstances, complement them.

The Downsides Are Everything Else

The problem with the whole idea is that the negatives are significant. Residential power is not data center power. Residential broadband is not enterprise-grade networking. A private home is not a secure, redundant, environmentally controlled facility, no matter how carefully a rack is installed.

Power is the first issue. Most homes are not designed to handle sustained commercial server loads without electrical upgrades. These upgrades can be expensive, heavily regulated, and dependent on local utility cooperation. Once backup batteries, uninterruptible power supply systems, cooling equipment, and dedicated circuits are added, the project starts to look less like a side hustle and more like a facilities operation.

Heat and noise follow quickly. Commercial hardware generates both continuously, which affects the comfort of the house, the cost of climate control, and the long-term reliability of the equipment. It also transforms residential life. Maintenance becomes routine. Monitoring becomes constant. The house begins to absorb the rhythm of an always-on machine room.

Then come the risks that stall many otherwise creative ideas. Fire hazards. Water damage. Physical theft. Tampering. Insurance complications. Zoning restrictions. Homeowner association objections. Lease restrictions for tenants. Questions about who can access the equipment and when. Liability if a customer’s hardware is damaged. Compliance concerns if sensitive data or regulated workloads are involved. All of these factors are manageable in theory, but they are precisely why professional facilities exist.

Customer trust may be the biggest obstacle of all. Most businesses are comfortable buying compute from a recognized provider because they assume a predictable operating environment. That assumption weakens significantly when the infrastructure sits in a private residence. Who is responsible during an outage? What happens if there is a storm, a flood, or a neighborhood power event? How is physical access controlled? How are incidents documented? Those questions are not edge cases. They determine the model’s viability.

Where Residential Hosting Could Work

Residential data hosting is unlikely to become the next mainstream large-scale hosting model. The economics of professional data centers still win in most situations because those facilities were built to solve exactly the problems that home models will struggle to address. Reliability, security, redundancy, and customer assurance are difficult and expensive to achieve. Purpose-built environments handle them better.

Still, the concept should not be dismissed outright. In some parts of the country, there may be a path forward. Cheap power. Upgradeable electrical service. Strong broadband. Detached or isolated space. Favorable local rules. Workloads that benefit from geographic distribution and do not require pristine enterprise conditions. In those scenarios, carefully managed micro-hosting could make sense.

That is probably the realistic future. Not a short-term rental marketplace for random servers. Not whole neighborhoods converted into basement data centers. Instead, a selective market where curated providers match specific homeowners or small properties with specific infrastructure needs under tightly controlled terms. What will start as a niche could still be enough to matter.

Source: InfoWorld News

For more than a decade, cloud economics rewarded abstraction. Enterprises moved workloads to rented capacity to escape capital expenditure, and providers competed on developer experience, elasticity, and service breadth. AI has inverted part of that logic. The scarce resources are now gigawatts of available power, high-bandwidth memory, advanced packaging capacity, and the interconnect fabric that allows thousands of accelerators to behave like a single machine. Those constraints have pushed infrastructure strategy back onto the executive agenda, where it now competes with product roadmap and hiring for leadership attention.

Key facts at a glance

• Major US technology companies, including Alphabet, Amazon, Meta, and Microsoft, are expected to spend roughly $650 billion on AI-related infrastructure in 2026, up from about $410 billion in 2025, according to analyst projections and company guidance.
• Nvidia has announced plans to invest $2 billion each in photonics suppliers Lumentum and Coherent, a signal that data movement rather than raw compute alone is a primary bottleneck.
• First-generation enterprise AI workloads still overwhelmingly begin in public clouds, because managed services and instant access to GPUs reduce friction.
• Persistent, production-scale inference can cost far more than a pilot, prompting repatriation to on-premises systems or to specialized AI-optimized providers.
• Workload placement is becoming fluid, with experimentation, training bursts, and steady-state inference increasingly landing in different environments.

The infrastructure arms race defines the cycle

The numbers are difficult to ignore. Major technology companies are expected to spend in the neighborhood of $650 billion on AI-related infrastructure in 2026, up sharply from roughly $410 billion in 2025, based on guidance and analyst estimates. Growth of that magnitude tells us something structural: AI is not simply another software wave resting neatly on top of the existing cloud stack. It is forcing a redesign of that stack from the silicon upward.

That redesign reaches deep into networking and data movement. Nvidia's recently announced plan to invest $2 billion each in photonics suppliers Lumentum and Coherent underscores where the pressure points are emerging. The challenge is no longer only raw compute. It is also how quickly data can move between processors, racks, and clusters without creating unacceptable bottlenecks or power inefficiencies. Optical interconnects, co-packaged optics, and advanced switching have moved from niche technical topics to board-level concerns, because latency, throughput, and energy consumption have become first-order economic variables rather than secondary engineering details.

Power availability may be the binding constraint of all. Utilities, grid operators, and local governments are being asked to accommodate load profiles that traditional planning cycles never anticipated. Siting decisions now hinge on interconnection queues, substation capacity, water availability for cooling, and community approval as much as on land cost or fiber routes. This is why some operators are signing long-duration power agreements, exploring small modular reactors, and in some cases building generation assets outright. When electricity becomes the limiting factor, the cloud market starts to resemble an industrial market as much as a software one.

The capital intensity also changes competitive dynamics. Companies that can pre-commit to multiyear semiconductor orders, finance gigawatt-scale campuses, and absorb the depreciation that follows have an advantage that smaller providers cannot easily replicate. That concentration of spending is one reason the largest hyperscalers remain so dominant in the near term, even as the economics of individual AI workloads become less obviously favorable to them.

Most AI still starts in the public cloud

When enterprises are experimenting, speed matters more than optimization. Public clouds provide immediate access to GPUs, foundation model APIs, vector databases, orchestration frameworks, security controls, and integration services. They also let teams launch pilots without waiting on procurement cycles, data center expansion, or specialized infrastructure hires.

Given the high level of uncertainty in early AI programs, the public cloud is often the right choice for first-generation systems. Enterprises do not yet know which use cases will deliver measurable value, how much inference traffic they will see, or which architecture will survive contact with production. At this stage, the ability to try many things quickly matters more than extracting every dollar of efficiency from the underlying hardware. Managed services reduce friction, and friction is the enemy of early adoption.

This is why initial AI demand is landing so heavily in public cloud environments. Organizations are building chatbots, copilots, knowledge assistants, document automation pipelines, and code generation tools there, because the cloud lowers the barrier to entry dramatically. It supplies compute alongside a complete operating environment for experimentation, including the observability and governance tooling that enterprise deployments require.

Second-generation AI systems force a rethink

The second generation of enterprise AI looks different. Once a use case proves its value and usage becomes persistent, the financial model changes. A workload that seemed inexpensive during a proof of concept can become shockingly costly at production scale, especially when it depends on premium GPU instances, high-performance storage, continuous network traffic, and multiple layers of managed services stacked on top of one another.

That is where repatriation enters the conversation. A recognizable pattern is emerging: enterprises build first-generation AI on public clouds, learn what actually works, and then move selected workloads back on-premises or onto specialized providers that offer AI-optimized infrastructure at a lower cost per unit of sustained throughput.

On-premises deployment becomes attractive when utilization is steady, data gravity is high, governance requirements are strict, and the organization has enough scale to justify owning or directly controlling the hardware. Specialized AI clouds become attractive when enterprises still want an external provider but do not want to pay the full premium typically associated with the largest hyperscalers. These providers increasingly position themselves around dense GPU capacity, simplified pricing, and architectures designed specifically for AI rather than for general-purpose enterprise IT.

This pattern matters because it dispels the old assumption that cloud migration is a one-way street. In the AI era, workload placement is becoming fluid. Enterprises are learning that the best place to experiment may not be the best place to run steady-state production, and that AI economics can punish architectural laziness far faster than traditional enterprise applications ever did. A design decision that saves a week during a pilot can add millions to an annual run rate.

How much demand will AI actually drive?

The honest answer is: a great deal, especially in the near term. Nearly every significant enterprise AI initiative will engage the public cloud in some meaningful way, whether for model development, training bursts, integration services, security tooling, or global deployment. But it would be a mistake to assume all of that demand remains locked inside traditional hyperscalers indefinitely.

Some workloads will stay in the public cloud permanently because they are bursty, globally distributed, difficult to predict, or tightly coupled to cloud-native services. Others, particularly those with stable usage patterns and heavy inference volume, become candidates for relocation. Economics will drive those decisions more reliably than ideology, vendor loyalty, or architectural fashion.

The likely outcome is a more segmented market. Public clouds will dominate the front end of AI adoption and continue to play a major role in hybrid operations. On-premises environments will regain relevance for cost-sensitive, steady-state, and compliance-heavy workloads. Specialized AI providers will grow as a middle option for enterprises that want external capacity without paying full hyperscaler prices. In short, AI will increase public cloud demand while simultaneously intensifying scrutiny of which environment fits each workload over the long term.

Three factors to weigh

First: speed and cost are distinct metrics. The public cloud is usually the fastest way to get an AI initiative off the ground, and that speed carries genuine business value. But the architecture that wins a pilot may destroy a production budget. Enterprises need a placement strategy from day one, even if every workload starts in the cloud. That means documenting assumptions about growth, utilization, and data flows before the first invoice arrives.

Second: AI workload economics differ from those of traditional applications. Training, inference, data movement, storage, and model serving interact in ways that quickly produce cost surprises. Organizations should model not only compute consumption but also utilization patterns, network flows, and the cost of the managed services surrounding the core AI stack. A model that runs at 15 percent utilization on premium accelerators is a very different financial proposition from one that runs at 70 percent on commodity capacity. Without that discipline, teams risk designing systems that are technically elegant but financially unsustainable.

Third: future flexibility matters more than short-term convenience. Enterprises should avoid binding AI systems so tightly to a single provider's proprietary stack that migration becomes painful or impossible. Abstraction layers, containerized serving frameworks, open model formats, and portable data pipelines all preserve optionality. The organizations that fare best will be those able to shift workloads across public clouds, on-premises environments, and emerging AI-focused platforms as economics, regulations, and business requirements evolve.

The real question is not whether the cloud benefits from AI, but how long each AI workload stays there. AI will unquestionably generate substantial new demand for public cloud computing. For most enterprises, those workloads will remain in the cloud long enough to enable rapid innovation, rapid learning, and rapid iteration. Whether they remain there permanently is a decision that will be made workload by workload, invoice by invoice, and architecture by architecture.

Source: InfoWorld News

The conference arrives at a pivotal moment. The first wave of AI-assisted coding gave developers code completion, predicting lines, functions, and boilerplate based on what they had already typed. The second wave brought code suggestions and code generation, allowing AI to write new code or improve existing code from a natural language prompt. Today, coding agents can inspect a codebase, suggest improvements, compile and test the improved code, and iterate toward something better, faster, and safer. They can plan, write, test, review, and debug code. They can chat with developers about all of those steps. They can tackle complex development workflows on their own.

Key Facts at a Glance

• The conference runs October 13-15, 2026, at Moscone West Convention Center in San Francisco.
• More than 200 conference sessions will be held across six stages.
• More than 250 technology leaders will speak.
• Topics include AI agents, generative AI, software engineering, developer tools, enterprise software, and information security.
• Sessions will examine how AI is reshaping SaaS, cloud infrastructure, and industries such as finance, healthcare, and manufacturing.
• A featured session from Anthropic technical staff members Steve Androulakis and Sachin Malhotra will cover how the company behind Claude Code uses fleets of coding agents in its own software engineering work.
• The session will offer practical patterns for delegating agents, reviewing their output, and recovering when they get things wrong.
• The speaker lineup includes leaders from Amazon, Anthropic, Atlassian, Databricks, Flock, Glean, Google, NVIDIA, Okta, OpenAI, Replit, Runware, Together AI, and other companies.

From Autocomplete to Autonomous Agents

The evolution of AI in software development has been rapid and cumulative. Early tools were essentially sophisticated autocomplete engines. They learned from the code already present in an editor and predicted the next token, line, or block. That alone reduced boilerplate fatigue and helped developers stay in flow. But the interaction remained narrow: the human wrote most of the logic, and the machine filled in gaps.

Code suggestions and code generation expanded the relationship. Developers could describe a desired function, component, or test in plain language, and the model would produce a draft. The human still reviewed, edited, and integrated the result. The machine became a collaborative drafter rather than a simple predictor. This shift introduced new questions about correctness, licensing, and maintainability, but it also demonstrated that large language models could reason about code structure and intent.

Coding agents represent a more profound change. Instead of waiting for a prompt and returning a single block of text, an agent can operate within a repository. It can read files, search for relevant symbols, run tests, interpret failures, edit code, and repeat the cycle. It can maintain a plan across multiple steps. It can use tools such as compilers, linters, test runners, and debuggers. In some workflows, it can open a pull request, respond to review comments, and refine its work. The developer moves from writing every line to specifying goals, constraints, and acceptance criteria.

Inside the Agentic Workflow

A coding agent typically begins with a task description. That description might be a bug report, a feature request, a performance objective, or a refactoring goal. The agent explores the codebase to locate relevant files and dependencies. It forms a plan, often breaking the task into smaller steps. It writes or modifies code, then runs tests or static analysis to check its work. If something fails, it reads the error, adjusts its approach, and tries again. It may also summarize its changes for human review.

This loop is powerful because it compresses the edit-test-debug cycle. Developers often spend significant time switching contexts: reading documentation, searching for usages, running commands, and interpreting output. An agent can handle much of that mechanical work. It can also work in parallel. Multiple agents can explore different solutions or cover different parts of a codebase. That parallelism introduces new coordination costs, but it also opens the door to faster iteration on large projects.

Yet agentic coding is not magic. Agents can misunderstand requirements, introduce subtle bugs, duplicate existing logic, or make changes that pass tests but violate architectural principles. They can be overconfident. They can struggle with ambiguous tasks or unfamiliar codebases. The most effective teams treat agents as capable but fallible collaborators. They define clear boundaries, require tests, and review output carefully. They also track costs, because agentic workflows can consume significant compute and token budgets.

Conference Agenda and Themes

The upcoming conference is designed to address these practical realities. Over three days, attendees will choose from more than 200 sessions across six stages. The programming spans beginner-friendly introductions, deep technical dives, and strategic discussions for engineering leaders. The central theme is not simply what AI can do, but how organizations can use it responsibly and effectively.

Sessions will cover how AI agents and generative AI are changing software engineering, developer tools, enterprise software, and information security. Speakers will examine how AI is reshaping SaaS and cloud infrastructure. They will discuss how companies are building and deploying AI systems in production. They will also explore how AI is driving innovation in finance, healthcare, manufacturing, and other industries where reliability, compliance, and data privacy are critical.

For developers, the event offers a chance to compare tools, frameworks, and workflows. For founders and investors, it provides a view of where the startup ecosystem is placing its bets. For engineering leaders, it offers case studies and cautionary tales about adoption, governance, and return on investment. The breadth of topics reflects the fact that AI is no longer a standalone category. It is becoming embedded in the entire software lifecycle.

Anthropic Session on Delegating Agents

One of the most anticipated sessions will come from Anthropic technical staff members Steve Androulakis and Sachin Malhotra. Anthropic is the company behind Claude Code, an AI coding tool that has gained attention for its ability to work with large codebases and multi-step tasks. The session will explain how Anthropic uses fleets of coding agents in its own software engineering work.

According to the session description, attendees will learn practical patterns for delegating agents, reviewing their output, and recovering when they get things wrong. That framing is notable because it treats failure as normal. In real-world software development, agents will sometimes produce incorrect or incomplete work. The question is not whether errors will occur, but how quickly teams can detect, contain, and correct them. The session promises to move beyond demos and into the operational details that matter for production use.

Delegation patterns might include assigning agents to well-scoped tasks, providing them with repository context, limiting their permissions, and requiring them to run tests before submitting changes. Review patterns might involve using one agent to critique another, or using human reviewers to focus on high-risk areas. Recovery patterns might include rollback strategies, automated checks, and clear escalation paths. These patterns are likely to be valuable for teams that are moving from experimentation to systematic adoption.

Speaker Lineup and Industry Representation

The speaker roster includes technology leaders from Amazon, Anthropic, Atlassian, Databricks, Flock, Glean, Google, NVIDIA, Okta, OpenAI, Replit, Runware, Together AI, and many other companies at the cutting edge of AI and software technology. The presence of cloud providers, model developers, developer-tool companies, security firms, and enterprise software vendors reflects the full stack of the AI ecosystem.

This mix matters because the future of AI in software development will not be determined by a single product or platform. It will emerge from the interaction of models, tools, infrastructure, data, security, and human workflows. A coding agent may rely on a foundation model from one company, run on cloud infrastructure from another, integrate with an IDE from a third, and connect to security tooling from a fourth. The conference provides a rare opportunity to see how these pieces are coming together.

Attendees will also have the chance to connect with peers, exchange ideas, and explore the latest innovations. The event is expected to draw a broad audience, from early-stage founders to engineers at large enterprises. Networking is not a side activity; it is part of how the industry shares knowledge and forms partnerships in a field that is changing month by month.

Why This Moment Matters for Enterprise Software

Enterprise software teams face unique pressures. They maintain large, long-lived codebases. They must satisfy regulatory requirements, protect sensitive data, and ensure uptime. They cannot adopt every new tool without considering security, compliance, and integration. At the same time, they are under pressure to deliver features faster and reduce costs.

AI coding agents offer a potential path to both speed and efficiency, but they also raise governance questions. Who is accountable when an agent introduces a vulnerability? How should intellectual property be handled? What logging and audit trails are needed? How can teams prevent agents from accessing secrets or production systems? These questions do not have easy answers, but they are exactly the kind of issues that enterprise leaders will discuss at the conference.

The event will also examine how AI is reshaping SaaS and cloud infrastructure. As AI models become more capable, they are changing how applications are built, deployed, and scaled. Some companies are embedding AI features directly into their products. Others are using AI to optimize cloud costs, automate operations, and improve customer support. The line between traditional software and AI-powered software is blurring.

Security, Governance, and Trust

Information security is another major theme. Coding agents can introduce new attack surfaces. They may generate code that uses insecure libraries, mishandle input, or expose credentials. They may also be vulnerable to prompt injection or data poisoning. Security teams need to understand how agents interact with source code, dependency graphs, build systems, and deployment pipelines.

At the same time, AI can be part of the defense. Agents can scan for vulnerabilities, suggest patches, and help developers respond to incidents. They can analyze logs, correlate alerts, and recommend mitigations. The conference will likely feature sessions on securing AI systems, using AI for security, and managing the risks that come with autonomous code generation.

Trust is the underlying issue. Developers need to trust that an agent's output is correct, secure, and maintainable. Engineering leaders need to trust that adoption will not create unacceptable risk. Customers need to trust that AI-generated software meets the same standards as human-written software. Building that trust requires transparency, testing, and a willingness to treat AI as a component of a larger socio-technical system.

SaaS, Cloud, and Industry Adoption

The conference will explore how AI is driving innovation beyond the technology sector. In finance, AI is used for fraud detection, risk modeling, and customer service. In healthcare, it supports diagnostics, drug discovery, and administrative automation. In manufacturing, it improves quality control, predictive maintenance, and supply chain optimization. Each of these industries has its own constraints, but they share a need for reliable, explainable, and secure AI.

For software developers, the practical implications are broad. They may be asked to integrate AI models into existing applications, build agentic workflows, or create tools that help non-technical users harness AI. They may need to learn new skills in prompt engineering, evaluation, and AI operations. They may also need to rethink career paths as routine coding tasks become more automated.

The conference's focus on developer tools reflects this shift. Toolmakers are racing to add agentic capabilities to IDEs, code review platforms, CI/CD systems, and observability tools. The goal is to make AI assistance seamless, context-aware, and safe. The sessions will likely showcase how these tools are being used in real projects, including their limitations.

Practical Patterns for Agent Delegation

The featured session on delegating agents is likely to resonate because it addresses a gap between hype and practice. Many teams have experimented with AI coding tools, but fewer have established repeatable processes for using them at scale. The session promises to share patterns that Anthropic has learned from its own engineering work.

Attendees can expect to hear about task decomposition, context management, and evaluation. They may learn how to write prompts that include acceptance criteria and constraints. They may see examples of agent fleets working on parallel tasks, with human oversight at critical checkpoints. They may also hear about failure modes and how to design systems that fail safely.

These patterns are not limited to one vendor or model. They reflect a broader maturation of agentic AI. As agents become more capable, the competitive advantage will shift from simply having access to an agent to knowing how to orchestrate many agents effectively. That orchestration includes tool use, memory, permissions, testing, and human review.

The conference will also provide opportunities to compare approaches. Some teams prefer a single powerful agent. Others use specialized agents for planning, coding, testing, and reviewing. Some rely heavily on human review, while others automate more of the pipeline. There is no universal answer, but the exchange of ideas can help teams find what works for their context.

For developers, the most important takeaway may be that agentic coding is a skill. It requires learning how to communicate intent, define boundaries, and evaluate output. It requires understanding when to delegate and when to take over. It requires a healthy skepticism toward confident-sounding suggestions. The conference will offer a concentrated dose of that skill-building.

The event's timing is also significant. It comes as AI coding agents move from research labs into mainstream development teams. The next twelve months will likely see wider adoption, more sophisticated tooling, and new best practices. The sessions, workshops, and conversations at the conference will help shape how that adoption unfolds. For anyone building software today, understanding the trajectory of AI and software development is no longer optional. It is part of the job. The conference offers a front-row seat to that future, with practical guidance from the people building it.

Source: InfoWorld News

Attackers are exploiting the booming interest in artificial intelligence and cryptocurrency trading with a fake AI trading agent that installs a credential-stealing malware family known as Needle Stealer. The campaign, observed between April and June 2026, targets people who search for AI agents and download them from search results or advertisements. The lure is a website that promises an automated agent capable of trading crypto around the clock. Instead of a functional trading bot, the download contains a ZIP archive with a file named Trading Agent.exe. That executable is not a trading program at all. It is a legitimate, Microsoft-signed utility called OLEView. Because it carries a valid digital signature, Windows SmartScreen treats it as trustworthy. Its only purpose in this attack is to pass that reputation check. Once launched, OLEView loads a malicious library named iviewers.dll from the same folder. This technique, known as DLL side-loading, allows the attacker to run code inside a trusted process. The DLL then executes Needle Stealer through process hollowing, a method that starts a legitimate process in a suspended state and replaces its memory with malicious code. The result is a stealthy infection that is difficult for traditional security tools to spot.

Needle Stealer is designed specifically for browser-based cryptocurrency wallets. It searches for seven different wallet extensions, including MetaMask, Coinbase Wallet, and Phantom. When it finds one, it kills the browser, unpacks a malicious copy into the extension folder, and waits. The next time the victim opens the browser and unlocks the wallet, the fake extension contacts the attacker’s command server and sends the password. With the wallet identifier and password, the attacker can control the funds. The victim may see a familiar unlock screen and assume everything is normal. However, a familiar interface does not prove that the extension is the one originally installed. The campaign shows how AI-themed lures can be combined with established malware techniques to target high-value crypto assets. It also highlights the importance of keeping wallet passwords and payment activity away from agent apps that cannot be verified.

How the Attack Chain Works

The attack chain begins with a promise. The fake site offers an AI agent that will trade crypto continuously. Users who download the agent receive a ZIP file. Inside is the signed OLEView executable and a malicious DLL. When the user runs the executable, Windows sees a trusted signature and allows it to start. The executable then loads the DLL from the same directory. This is a classic DLL side-loading attack. The DLL uses process hollowing to inject Needle Stealer into a legitimate process. Once running, Needle Stealer scans for the targeted browser wallet extensions. It terminates the browser, replaces the wallet extension with a malicious version, and waits for the user to type the wallet password. The malicious extension then exfiltrates the password to a remote server. With that password and the wallet ID, the attacker can drain the wallet.

Each stage is designed to evade detection. The signed executable bypasses SmartScreen reputation checks. DLL side-loading hides the malicious code inside a trusted process. Process hollowing makes the malicious code appear to be part of a legitimate program. The wallet extension replacement is especially dangerous because it does not require a separate phishing page. The user continues to interact with what looks like their normal wallet. The only difference is that the password is being copied and sent to an attacker. This type of attack is difficult to detect with signature-based antivirus alone. It requires behavioral monitoring, application control, and user awareness.

Defenders should treat downloads of AI agents with the same caution as any other executable. A website that promises automated crypto profits is a red flag, especially when the download is a ZIP file containing an executable. Users should verify the publisher, use official app stores where possible, and avoid running unsigned or unfamiliar binaries. For crypto holders, hardware wallets provide a stronger boundary because the private keys never leave the device. Browser wallets are convenient but they are also a high-value target. Keeping large balances in a browser extension is risky. Separating trading activity from long-term storage reduces the impact of a successful compromise.

QR Code Phishing Pushes Victims to Less Protected Phones

While the fake AI agent campaign targets desktop browsers, another set of campaigns uses QR codes to move victims onto their phones. Researchers identified emails containing PDF invoices. The PDF shows a blurred document behind a QR code and a note telling the recipient to scan the code with a smartphone. This technique is known as quishing, or QR code phishing. The scan passes through several redirects, including a fake email security scanner and a Cloudflare Turnstile check that confirms a human is loading the page. The victim then lands on a page that resembles OneDrive and is asked to enter Microsoft credentials.

The move to a phone is deliberate. A work PC often has email gateways, browser protections, and endpoint detection that may already block a known phishing domain. A phone usually carries fewer defenses. A link that would be stopped on a desktop may load without warning on a mobile device. The small screen also makes it harder to inspect the full URL. Users may not notice that the address is not the real service. The QR code itself can bypass email security because it is an image, not a clickable link. The email gateway cannot easily scan the destination behind the QR code. The user becomes the bridge between the email and the malicious site. This cross-device attack path is becoming more common as attackers look for gaps in enterprise security. Organizations need to protect mobile devices as rigorously as desktops. That includes mobile threat defense, phishing-resistant authentication, and user training that covers QR codes.

Phantom Stealer Sold With Customer Support

A separate malware family called Phantom Stealer is sold openly on the web as a penetration testing tool. The product comes with a crypter that encrypts it against analysis, regular feature updates, and 24/7 customer support. Buyers must agree not to use it for malicious purposes, but the tool is clearly marketed to a criminal audience. Researchers isolated several email campaigns delivering Phantom Stealer. In each campaign, a VBScript built a PowerShell command that fetched an ordinary-looking image. The image contained a hidden .NET loader, extracted using steganography. A component named Phantom Gate, built into the PowerShell script, started that loader. The loader then downloaded the stealer, decoded it, and injected it into RegAsm, a legitimate .NET Framework process. This delivery chain is similar to the Needle campaign. The shared naming and the use of process injection suggest that one threat actor may be behind both tools.

The sale of malware with support services reflects the professionalization of cybercrime. Criminal groups operate like software vendors, offering updates, compatibility fixes, and help desks. The crypter helps the malware evade detection. The support ensures that buyers can keep using the tool even as security products improve. The use of legitimate .NET processes for injection makes detection harder. RegAsm is a normal part of Windows, so security tools may not immediately flag its activity. The loader can also change its payload, making it harder for defenders to block by file hash. This combination of commercial support, encryption, and living-off-the-land techniques makes Phantom Stealer a persistent threat.

Users move constantly between devices and applications, like browsers or new AI tools, and attackers are quick to follow. Security needs to work across all of those interactions, without getting in people’s way. That means organizations need a zero-trust approach built around isolation and containment, so untrusted clicks and downloads do not become a risk.

That perspective underscores why the fake AI agent, QR phishing, and Phantom Stealer campaigns are not isolated incidents. They are part of a broader pattern in which attackers follow users across browsers, phones, and new AI tools. A zero-trust approach treats every device and interaction as potentially untrusted. Isolation and containment can prevent a single click from turning into a full compromise. For individuals, the lesson is to slow down before installing new agents or scanning QR codes. For organizations, the lesson is to extend security controls beyond the traditional desktop perimeter.

Invoice Campaigns Deliver XWorm, PureLogs and Formbook

Other invoice-themed campaigns arrived in two ways. Some used HTML smuggling, a technique that assembles the malicious file on the victim’s machine. Because the file is built locally, it can slip past email gateway scanners that only inspect attachments. Others relied on search results leading to lookalike domains. Both routes ended with loaders that decoded payloads hidden in images and installed XWorm, PureLogs Stealer, or Formbook. These malware families steal credentials, browser data, and system information. A perceptual-hash search of VirusTotal, which matches images by how they look rather than by exact file hash, turned up about 400 distinct images tied to these campaigns over three months. That number indicates a large and active operation. Attackers are reusing image templates and changing small details to avoid detection. Perceptual hashing helps defenders find related samples even when the file hash changes. It also shows how important it is to monitor for visual similarities across campaigns, not just known indicators of compromise.

HTML smuggling is effective because it splits the malicious payload into pieces that are assembled in the browser. The email may contain no suspicious attachment. The payload is encoded in the HTML or downloaded in chunks. Once assembled, it runs on the victim’s machine. Lookalike domains are equally effective because users often trust search results. A domain that resembles a legitimate service can appear at the top of search rankings through ads or search engine optimization poisoning. The combination of HTML smuggling and lookalike domains gives attackers multiple paths to the same goal. The loaders then hide their payloads in images, a form of steganography. This makes the malicious code harder to detect because the image looks harmless. The final payloads, XWorm, PureLogs Stealer, and Formbook, are all capable of stealing sensitive data. Formbook, for example, has been used for years to log keystrokes, capture screenshots, and steal credentials from browsers. PureLogs Stealer focuses on credentials and crypto wallets. XWorm is a remote access trojan that can download additional modules. Together, they represent a broad threat to both individuals and organizations.

Fake Installers and Search Hijacking

Researchers also traced a Russian-language imitation of a Microsoft site. The site offered an installer that bundled other products for affiliate payouts and never installed the promised word processor. The bundled security product eventually flagged the installer as dangerous and deleted it. That unusual sequence shows how affiliate-driven installers can turn against their own creators. More importantly, two signed installers, UltraZip and AllFiles, were found to hijack the default search engine and keep the change even after uninstall. This persistence is a common feature of unwanted software. Even if the installer does not steal crypto wallet passwords, it can redirect searches, inject ads, and expose users to further malicious content. Signed installers are especially problematic because users and security tools may trust them. A valid signature does not guarantee that the software is safe. It only means that the file has not been modified since it was signed. The publisher may still bundle unwanted programs or engage in deceptive practices.

The fake installer trend fits the same theme as the AI trading agent. Attackers use trusted brands, signed files, and search results to reach victims. They promise a useful tool, then deliver something else. In the AI trading agent case, the payload is a wallet stealer. In the fake installer case, the payload is adware, search hijacking, and bundled software. The common thread is deception. Users are tricked into running a file that appears legitimate. Once executed, the file can install additional payloads, change browser settings, or steal credentials. Defenders should monitor for changes to browser search settings and extension folders. They should also restrict the execution of unsigned or newly signed binaries. Application allowlisting can prevent many of these attacks because only approved programs are allowed to run. For home users, the best defense is to download software only from official sources and to read installation screens carefully. Unchecking bundled offers is not always enough, because some installers hide the opt-out or ignore it. A clean virtual machine or sandbox can help when testing unfamiliar software.

The broader lesson from these campaigns is that attackers are constantly adapting their lures to current interests. AI is the latest hook. Crypto remains a high-value target. QR codes and mobile devices open new paths around desktop defenses. Malware is sold with customer support, and payloads are hidden in images to evade detection. The attack surface now includes browsers, phones, AI tools, and software installers. Security controls must cover all of them. Isolation, containment, and zero-trust principles can reduce the risk that a single untrusted click or download becomes a full breach. The persistence of search hijacking after uninstall shows that even low-level unwanted installers can leave lasting changes that affect user privacy and security.

Source: Help Net Security News

• A field guide dedicated to AI adoption in IT and security has been withdrawn and is no longer available for download.
• The guide was designed to help teams move past polished demos and evaluate AI tools for real production environments.
• It argued that many AI deployments increase complexity, erode trust, and add new risks and oversight burdens instead of reducing workload.
• Promised material included a practical evaluation framework, a step-by-step selection process, vendor pressure-test questions, and human-in-the-loop best practices.
• It also promised real examples of teams using AI to reduce workload and improve consistency, including organizations in online learning, design, device management, and video.

The Promise and the Disappearance

A field guide that promised to help IT and security teams navigate artificial intelligence adoption has been pulled from circulation. The resource, which was offered as a download for technology leaders, is no longer available. Its removal leaves a gap for organizations that were hoping for a structured, operational playbook rather than another vendor pitch. The guide had been positioned as a practical counterweight to the hype cycle that surrounds enterprise AI. It acknowledged that security and IT teams are under intense pressure to adopt AI, but that many are seeing the opposite of what was promised.

That tension is familiar. Executives want faster response times, lower costs, and more consistent operations. Vendors promise that AI will deliver all three. Yet in practice, tools that look impressive in a demonstration often struggle when they are connected to real data, real workflows, and real threat models. The guide was meant to address that gap. It set out to explain why AI adoption fails in practice and to give teams a clearer path forward, from evaluation to implementation, with humans in the loop.

The Demo-to-Production Gap

One of the guide's central observations was that AI tools which demo well frequently do not hold up in real workflows. This is not a minor inconvenience. It is a structural problem in how AI is bought, deployed, and measured. A demonstration is usually controlled. The data is clean. The use case is narrow. The presenter knows what questions will be asked. Production is the opposite. Data arrives late, incomplete, or inconsistent. Users behave unpredictably. Integrations fail. Edge cases multiply. A tool that seemed to reduce workload in a sandbox can quickly become another system to manage, monitor, and defend.

The guide warned that complexity increases when AI is layered onto existing processes without a clear operating model. Trust breaks down when outputs are inconsistent or unexplainable. And instead of reducing workload, AI can introduce new risks and oversight burdens. Security teams, in particular, cannot simply accept an AI recommendation without understanding how it was reached, what data it used, and whether an attacker could manipulate it. The same qualities that make AI useful, such as flexibility and probabilistic reasoning, also make it harder to control.

This is why the guide's withdrawal matters. It was not a generic introduction to AI. It was aimed at the people who must make AI safe, reliable, and governable inside complex organizations. Its promised contents included a practical framework for evaluating tools beyond the demo, a step-by-step approach to selecting tools that hold up in production, and key questions to pressure-test vendors before committing. Those are precisely the resources that many teams lack.

What the Guide Promised to Cover

According to the original description, the guide was organized around several practical outcomes. It promised readers a framework for evaluating AI tools beyond a scripted demonstration. That framework would have helped teams compare vendors on the basis of integration depth, data handling, model transparency, and operational fit rather than on the polish of a sales presentation. It also promised a step-by-step approach to selecting tools that hold up in production. That is a different exercise from choosing a tool that works in a pilot. Production selection requires evidence of reliability, scalability, security, and maintainability.

The guide also said it would provide key questions to pressure-test vendors before committing. Such questions might cover data retention, model training practices, access controls, audit logging, incident response, and the ability to roll back automated actions. They might also probe how a vendor handles false positives, adversarial inputs, and changes in underlying models. For security teams, these questions are not optional. They are part of due diligence.

Another promised element was human-in-the-loop best practices for safe, scalable AI. This is a critical theme. Human oversight is often treated as a temporary safeguard that can be removed once a system matures. The guide's framing suggests a different view: human-in-the-loop design is a control, not a fallback. It must be engineered into workflows, with clear escalation paths, review thresholds, and accountability. Without that design, automation bias can set in. Operators may defer to AI outputs even when those outputs are wrong. The result is not efficiency but a new category of risk.

The guide also promised real examples of how teams are using AI to reduce workload and improve consistency. It referenced organizations in online learning, design, device management, and video. Those examples would have been valuable because they move the conversation beyond theory. They show what actually works when AI is applied to specific tasks with measurable outcomes. In many successful cases, the pattern is similar: a narrow use case, a clear baseline, human review, and continuous measurement.

Why AI Adoption Fails in Practice

AI adoption fails for reasons that are rarely about the model alone. It fails when the problem is poorly defined. It fails when data quality is ignored. It fails when workflows are not redesigned around the new capability. It fails when success metrics are vague or when no one owns the outcome. The guide's premise was that these failures are predictable and avoidable. Yet many organizations continue to repeat them because the pressure to adopt AI outpaces the discipline required to deploy it well.

Security and IT teams face additional constraints. They are often the last to be consulted and the first to be blamed. They must protect sensitive data while enabling experimentation. They must support new tools without expanding the attack surface beyond what they can monitor. They must respond to incidents that may involve AI systems they did not build and do not fully understand. The guide's focus on evaluation, vendor scrutiny, and human oversight speaks directly to those constraints.

There is also the workload paradox. AI is sold as a way to reduce toil. In reality, it often shifts work rather than eliminating it. Someone must prepare data, tune prompts, review outputs, correct errors, maintain integrations, and update policies. If those tasks are not resourced, the promised productivity gains never materialize. Instead, teams accumulate technical debt and operational risk. The guide's emphasis on production readiness suggests an awareness of this paradox. It is not enough to automate a task. The surrounding system must be able to absorb the change.

Vendor Pressure-Testing and Procurement

Procurement is where many AI projects are won or lost. A vendor that cannot answer detailed questions about data governance, security, and reliability should not be trusted with critical workflows. The guide promised key questions to pressure-test vendors before committing. Those questions matter because AI vendors often operate across multiple layers: the model, the application, the integration, and the support model. A weakness in any layer can create risk.

Teams should ask where data is stored, how long it is retained, and whether it is used for training. They should ask how access is controlled and how activity is logged. They should ask what happens when the model is updated and whether behavior can change without notice. They should ask how the vendor handles prompt injection, data poisoning, and other adversarial techniques. They should ask about service-level agreements, support escalation, and exit strategies. These are not hypothetical concerns. They are the practical details that determine whether an AI tool can be safely operated at scale.

The guide's step-by-step approach to selection would have been useful here. A production-ready AI tool must be evaluated against real workflows, not just benchmarks. It must be tested with representative data, including messy and adversarial inputs. It must be reviewed by the people who will use it and the people who will secure it. It must have clear ownership and measurable success criteria. Without these steps, organizations risk buying a demo that becomes a liability.

Human-in-the-Loop as an Operating Model

Human-in-the-loop is often misunderstood. It is not simply having a person click approve on every AI action. That approach does not scale and can create its own bottlenecks. A well-designed human-in-the-loop model defines which decisions require review, which can be automated, and how exceptions are handled. It assigns accountability. It provides feedback loops so that errors are corrected and models improve. It also protects against automation bias by making it clear when human judgment is expected to override machine output.

For security teams, human oversight is essential in areas such as alert triage, phishing analysis, vulnerability prioritization, and incident response. AI can accelerate these tasks, but it can also produce convincing false positives or miss subtle indicators. The guide's promise of human-in-the-loop best practices would have helped teams design workflows that combine machine speed with human judgment. That combination is not a compromise. It is the only realistic path to safe, scalable AI in high-stakes environments.

The Road Ahead

The field guide is no longer available, but the problems it described have not gone away. IT and security teams continue to face pressure to adopt AI. Vendors continue to promise transformation. The gap between demo and production remains wide. The need for rigorous evaluation, vendor scrutiny, and human oversight is as urgent as ever. Organizations that treat AI adoption as a procurement exercise alone will struggle. Those that treat it as an operational discipline, with clear ownership, measurable outcomes, and strong controls, will be better positioned to capture real value.

The withdrawal of the guide also serves as a reminder that resources can disappear, but the underlying challenges persist. Teams cannot rely on a single playbook. They must build their own evaluation criteria, their own governance models, and their own evidence base. They must learn from both successes and failures. They must be willing to slow down in order to deploy safely. The pressure to move fast will not subside. Neither will the consequences of moving carelessly.

Until teams can test AI against their own workflows, data, and threat models, the gap between demo and production will remain the defining challenge of enterprise AI adoption.

Source: Help Net Security News

Key Facts

• Leaders frequently ask what data an AI model was trained on, but the better question is how to maintain authority and integrity of that data.
• Least privilege, authentication, and access controls remain essential for AI agents.
• Session-based RBAC via OIDC/OBO and context-appropriate permission scoping help prevent AI from exceeding expected capabilities.
• Agent-to-agent communication increases the need for strict human-in-the-loop architectures.
• AI has not just made attacks faster; it has eroded the asymmetry of ability between attackers and defenders.
• Vulnerability reporting has surged, leaving many reports unclassified.
• One security team handled just over nine times the vulnerabilities with the same staffing, reducing time to remediate by just over 5% using LLMs and supporting harnesses.
• Hiring now favors experienced operators who can catch confident but wrong AI output and understand compliance and governance.
• AI-generated inputs raise concerns about model collapse and the need for human-curated diversity.
• AI is moving application security earlier in the software development life cycle, enabling real-time guidance and reducing review bottlenecks.

The Question Behind the Question

When security leaders gather, one AI-related question dominates: “What data was this model trained on?” The concern is confidentiality. Companies fear intellectual property will become part of an AI’s general knowledge. That concern is valid. But stopping there leaves gaps in a layered security approach. A far less frequently asked question is: “How do you maintain authority and integrity of the data in question?” The answer lies in principles that predate generative AI: least privilege, authentication, and access controls.

For decades, least privilege has been the bedrock of enterprise security. It ensures users and systems have only the access needed to perform their tasks. The same principle applies to AI agents. If an AI agent can read, write, or execute beyond its intended scope, the model’s training data becomes less relevant. The damage is done through excessive permissions. Technologies such as session-based role-based access control (RBAC) via OpenID Connect (OIDC) and on-behalf-of (OBO) flows, combined with appropriate permission scoping for the context, help ensure AI does not exceed the capabilities expected of it.

As agent-to-agent communications become more prevalent, these strategies provide stricter human-in-the-loop architectures. Operators can recognize and correct issues before damage occurs. The goal is not to block AI but to bound it. Integrity and authority over data are maintained through identity, session context, and scoped permissions—not just through model provenance.

How the Attacker Toolkit Has Changed

The attacker toolkit looks different than it did three years ago. Speed is part of the story. State actors and criminal groups race to find and exploit flaws before others discover them. Vulnerability reporting has increased sharply. The National Vulnerability Database (NVD) has had to reprioritize classifications, leaving many reported vulnerabilities unclassified. The volume is simply too high for manual triage.

But the deeper change is the erosion of the asymmetry of ability that the security industry has historically enjoyed. Finding the conditions for an exploit, designing and testing it, and deploying it once required significant expertise. AI has brought that asymmetry closer to even. Exploitable contexts can be found more quickly, and the method to leverage them can be devised and implemented by people who otherwise lack the ability. Increasingly, they can do it faster than those with the ability.

As the contextual data AIs receive grows and models become better at recognizing patterns, this factor will become more significant. Discounting external factors such as government controls, it is possible that symmetry is achieved. At that point, the question becomes one of human nature: how large is the red team compared to the blue team? The side with more automated capability and more persistent exploration may gain the advantage. Defenders must assume that the barrier to entry for sophisticated attacks will continue to fall.

Staffing, AI, and the Vulnerability Flood

Security teams are famously understaffed. Has AI closed the gap or changed its shape? According to the security officer, headcount is not the answer to AI-driven risks. In one organization, the team processed just over nine times the number of vulnerabilities over the last year compared with the previous year, while maintaining the same staffing levels. That created a real gap in process. Using AI tools—largely large language models and supporting harnesses—they handled the increase without additional headcount and simultaneously reduced time to remediate (TTR) by just over 5%.

Achieving that throughput was not trivial. The volume increase was large, and the team had to react in a relatively short time. Experienced human engineers designed the system to leverage what LLMs provide and to stay current as those systems evolve. By embracing the same tools adversaries were using and investing in infrastructure around those tools, the team saw success. The lesson is not that AI replaces staff. It is that AI can augment experienced staff when workflows are redesigned around it.

Still, the pressure remains. Vulnerability management is only one part of security. Incident response, threat hunting, architecture review, and compliance all compete for attention. AI can help automate triage, summarize findings, and draft remediation guidance. But it cannot take responsibility. The human role shifts from doing every task manually to designing, supervising, and validating AI-assisted processes.

Hiring for Judgment, Not Just Output

AI is changing what organizations look for when hiring security talent. Current AI systems are quite capable of producing work on par with many entry-level analysts and engineers. More often than not, they need an experienced operator to recognize confidently wrong outputs and correct them. That takes a broad range of knowledge and experience—not just with diverse technical systems, but with the compliance and governance requirements that drive many security programs.

This raises the bar for all talent. It also creates a gap: it is increasingly difficult for new talent to gain the experience needed to operate these AI systems effectively. If AI handles the entry-level tasks that once served as training grounds, where do junior professionals learn to spot subtle errors? Organizations may need to rethink apprenticeship, mentorship, and review practices. The ability to question AI output, verify sources, and understand business context becomes more valuable than the ability to produce routine work quickly.

Five years ago, hiring might have emphasized tool-specific skills or the ability to execute known procedures. Today, judgment matters more. Security professionals must understand why a control exists, how it can fail, and what an attacker might do to bypass it. They must also understand how AI systems can be manipulated, over-permissioned, or fed misleading data. The best candidates combine technical depth with skepticism and governance awareness.

The Model Collapse Concern

There is an overarching concern about generational processing and the potential for model collapse when the majority—or all—inputs into AI systems are themselves generated by AI systems. Similar to the need for genetic diversity in a population, LLMs need input diversity that today requires human curation. Currently, many organizations think of this as two separate problems: a labor problem and a data problem. But historically, labor was how fresh inputs were provided to the systems. As organizations minimize human involvement, they may be reducing the very diversity that keeps models useful.

For security teams, this has practical implications. If AI-generated content floods training pipelines, models may become less accurate, more biased, or more prone to confident errors. Security controls that rely on AI for anomaly detection or vulnerability triage could degrade. Human curation, red teaming, and diverse data sources become not just nice-to-have but necessary for maintaining model integrity. The same principle of least privilege applies to data: not every data source should be trusted equally, and not every AI output should be fed back without review.

Application Security Moves Left

One of the most exciting developments in AI security is its impact on application-level security. AI allows security concerns to move much earlier in the software development life cycle (SDLC). By evaluating code against a curated list of criteria and policies, AI can surface concerns and give guidance in real time, rather than at a bottlenecked review period. This allows developers to propose and implement solutions with review from specialists, often avoiding the need for additional architecture and design requirements to filter back down the pipeline.

Security teams no longer feel like they are playing a catch-up game to stay current with changes. Many basic tasks that previously depended on external development teams are now internal side projects because, with explicit review, teams know the LLM can do the work. That makes a significant difference in cadence. The shift does not eliminate the need for security expertise. It changes where that expertise is applied: from manual review of every change to designing guardrails, curating policy, and validating AI-generated recommendations.

As AI agents become more autonomous, the principles of least privilege, session-based RBAC, and human-in-the-loop review will remain essential. The question is not only what data trained the model, but who or what can act on that data, under what authority, and with what integrity. Leaders who ask that question will be better positioned to adopt AI without outsourcing their security judgment to it.

Source: Help Net Security News

A flat cybersecurity budget does not have to mean weaker coverage. It does mean that security leaders must become more deliberate about where each dollar goes, what risk it reduces, and whether the business would notice if the spending disappeared. The most effective response is not across-the-board cuts. It is a structured review that separates essential controls from waste, duplication, and activity that never delivered operational value.

Key Facts

• A flat budget or a 12% cut is a common ask from finance teams, especially when revenue growth slows or economic uncertainty rises.
• Trimming every security expense by the same percentage can degrade protection because not every control contributes equally to risk reduction.
• Security spending can be sorted into four buckets: what works and protects something the business cares about; what could add value but was never operationalized; what duplicates a tool another team already bought; and what exists only for compliance theater.
• Waste is common. Organizations may run three or four governance, risk, and compliance tools that each perform only part of the job.
• Cheap security choices often cost more later through incidents, rework, emergency purchases, and audit findings.
• Security leaders who speak in risk and dollars, support estimates with due diligence, and tie spending to revenue can change the conversation with finance.

Why Across-the-Board Cuts Fail

An across-the-board cut assumes that every security investment has the same relationship to business risk. That assumption is almost always false. A small reduction in an endpoint detection platform may leave a gap in visibility across thousands of devices. A similar reduction in a duplicated reporting tool may cause no operational loss at all. The difference is not the size of the line item. It is the function the spending performs.

Security budgets often grow in layers. A tool is purchased to solve an immediate problem. Later, another team buys a similar capability because it did not know the first tool existed. A compliance deadline prompts the purchase of a reporting module. A consultant recommends a framework. Over time, the stack becomes a collection of overlapping capabilities, unused licenses, and processes that are followed only during audits.

When finance asks for savings, the security leader who cuts uniformly protects the status quo. The security leader who cuts strategically protects the business. The difference is a matter of categorization. Each expense should be evaluated against a simple question: if this spending went away tomorrow, what business risk would increase, and who would feel the impact?

The Four-Bucket Framework

A practical way to answer that question is to sort every security expense into four buckets. The first bucket contains controls that work and protect something the business cares about. These are the investments tied to critical services, customer data, revenue-generating systems, regulatory obligations, or safety. They may not be glamorous, but they reduce a risk that the board, the CEO, or the CFO has already identified as material.

The second bucket contains spending that could add value but was never operationalized. This is common with advanced tools that were purchased but not fully deployed, threat intelligence feeds that no one reads, or automation platforms that sit idle because the team lacked the skills or time to integrate them. The answer here is not necessarily to cut. It may be to assign ownership, complete the rollout, or renegotiate the contract if the value cannot be realized.

The third bucket contains tools that duplicate something another team already bought. This is where consolidation produces the fastest savings without reducing coverage. A security team may have a vulnerability scanner, while the IT operations team has another. A cloud team may have a cloud security posture management tool, while the security team has a separate one. Each tool may do part of the job, but the overlap creates cost, complexity, and conflicting data.

The fourth bucket contains spending that exists only for compliance theater. These are controls that check a box but do not meaningfully reduce risk. They may be reports that no one uses, policies that are not enforced, or audits that repeat work already covered elsewhere. Removing them does not weaken security. It frees resources for the first bucket, where real risk reduction happens.

Tool Sprawl and the GRC Example

Governance, risk, and compliance platforms offer a clear example of how duplication accumulates. A large organization may have three or four GRC tools. One handles policy management. Another tracks vendor risk. A third manages audit findings. A fourth supports business continuity. Each tool was bought by a different leader at a different time for a different purpose. Each performs part of the job, but none provides a complete view.

The cost is not only licensing. It is the time spent moving data between systems, reconciling conflicting reports, training staff on multiple interfaces, and preparing for audits in separate repositories. When a flat budget forces a review, the organization can often consolidate to a single platform or a smaller set of integrated tools. The result is lower cost and better visibility.

This pattern repeats across security categories. Endpoint detection, network monitoring, identity management, cloud security, and data loss prevention all have overlapping capabilities. The goal is not to eliminate every overlap. Some redundancy is intentional and necessary for resilience. The goal is to identify accidental duplication that consumes budget without adding protection.

The Hidden Cost of Cheap Security Choices

Budget pressure can push leaders toward the cheapest available option. That choice often looks good in the current quarter, but it can create larger costs later. A low-cost tool may lack the integration, support, or scalability needed to protect a growing environment. A short-term consultant may deliver a report but leave no lasting capability. A delayed upgrade may save money now but increase the chance of a costly incident.

Security incidents have direct and indirect costs. Direct costs include incident response, legal fees, customer notification, credit monitoring, and regulatory penalties. Indirect costs include downtime, lost productivity, reputational damage, customer churn, and higher insurance premiums. When those costs are compared with the savings from a cheap control, the inexpensive choice often becomes the more expensive one.

This is why security leaders must do more than present a list of tools. They must show what happens when a control is removed or underfunded. A risk register that quantifies likelihood and impact in financial terms is more persuasive than a technical argument. It allows finance to compare the cost of prevention with the cost of a potential event.

Speaking Finance’s Language: Risk and Dollars

Security leaders who want a different conversation with finance must speak in risk and dollars. Technical jargon can obscure the business impact. A discussion about coverage gaps, detection latency, and control efficacy is useful for security teams, but it may not resonate with a CFO who is focused on cash flow, margin, and shareholder value.

The alternative is to frame security spending as a portfolio of investments. Each investment should have an expected return in the form of reduced risk. The return may not be revenue, but it can be expressed as avoided loss. For example, a control that prevents a specific type of fraud can be compared with the average loss from that fraud. A control that reduces downtime can be compared with the revenue lost per hour of outage.

This approach requires data. Security leaders should back their estimates with due diligence. That means using incident data, industry benchmarks, internal audit findings, threat intelligence, and control performance metrics. It also means being honest about uncertainty. Finance professionals understand ranges and probabilities. They are more likely to trust an estimate that includes assumptions than a single number presented without context.

Tying Security Spending to Revenue

The strongest case for a security investment is often its connection to revenue. Security enables digital commerce, customer trust, regulatory approval, and partner integration. When a security control protects a revenue-generating system, it is not just a cost center. It is part of the infrastructure that allows the business to operate and grow.

For example, an identity and access management platform may be presented as a security tool. But it also enables faster onboarding for customers, partners,

Source: Help Net Security News

The issue reaches far beyond the developers who manage repositories. Open-source code sits inside phones, cars, cloud systems, and AI platforms. A Harvard Business School paper cited in a recent policy analysis estimated that firms would spend 3.5 times more on software without open-source components. That figure captures the value of shared code, but it also captures the risk. When a widely used project lacks resources, deferred maintenance can leave security holes in every product built on top of it.

Key Facts

• AI coding tools are adding to the review load on open-source projects.
• Human maintainers still must decide what enters an official codebase.
• Open-source components are embedded in phones, cars, cloud systems, and AI platforms.
• Firms would spend an estimated 3.5 times more on software without open source, according to a cited Harvard Business School paper.
• Most open-source projects lack reliable revenue, and deferred maintenance can create security gaps.
• AI makes code submission easier, including poor-quality contributions that require human assessment.
• Shared code means a single flaw can affect a huge number of users and systems.
• Attackers increasingly plant malicious packages and code in popular repositories.
• Google’s CodeMender agent contributed 72 security fixes to open-source projects between April and October 2025, including changes to codebases as large as 4.5 million lines.
• AI models that find and patch flaws can also be used to build attacks.
• Restricting top security models to trusted users is unlikely to help because general-purpose models keep improving.
• AI-found flaws push organizations to patch sooner, but applications built from many components require sequential patches and re-releases.
• The Linux Foundation brought in $292,217,236 in 2024; the Apache Software Foundation brought in $2,379,402, less than 1 percent of that.
• Most open-source users never pay, a pattern known as the free-rider problem.
• A software bill of materials, or SBOM, is a machine-readable list of components inside an application.
• Despite US and EU mandates, the vast majority of open-source applications do not generate or ship an SBOM.
• An SBOM shows what is present, not whether each component is maintained, funded, secure, or abandoned.
• Open source is governed project by project, making ecosystem-wide numbers on AI’s effects hard to collect.
• Policy authors want more resources for documentation, packaging, fundraising, and requirements gathering.
• Institutions face a major challenge in learning the governance, maintenance, and security state of their software so they can spot critical dependencies before failure.

The Human Bottleneck in an AI-Accelerated Workflow

Most open-source projects accept outside contributions. They typically rely on a vetted group of trusted contributors to decide what gets committed, meaning accepted into the official codebase. AI has made writing and submitting code easy. Some of what arrives is poor. The authors of a policy analysis allow that quality may improve as models do, but a human still has to assess the added volume. That is the core problem: automation can generate more candidate code, but it cannot absorb the accountability for what ships.

Reviewing code is not a passive task. It requires understanding a project’s design, its compatibility promises, its security posture, and its long-term maintenance plan. A maintainer must ask whether a contribution solves a real problem, whether it introduces new dependencies, whether it follows project conventions, and whether it can be maintained after the original contributor moves on. AI can help draft tests or suggest fixes, but it does not remove the need for judgment. In many projects, the same small group of volunteers handles those decisions after their day jobs.

Why Shared Code Creates Outsized Risk

So much of the world runs the same code that a flaw found in it can have an outsized impact. A single vulnerable library can affect thousands of applications, from banking systems to medical devices to consumer gadgets. A growing number of attackers plant malicious packages and code in popular repositories. These attacks exploit the trust that developers place in package managers and open-source communities. When a project is underfunded, its maintainers may not have the time or tools to detect every malicious contribution.

The review burden therefore has a security dimension. AI can help find flaws, but it also lowers the cost of producing attacks. Models that find and patch vulnerabilities can be repurposed to build exploits. The policy authors doubt that restricting top security models to trusted users will help, since general-purpose models keep getting stronger. Even if the most capable security-focused systems were limited, attackers could use widely available models to probe code, generate malicious packages, or automate social engineering against maintainers.

Faster Fixes, Faster Attacks

Between April and October 2025, Google’s CodeMender agent contributed 72 security fixes to open-source projects, including some as large as 4.5 million lines of code, according to Google. That example shows the potential of AI to reduce the time between discovery and repair. It also shows the scale of the review problem. A fix for a 4.5-million-line codebase is not a simple patch. It must be evaluated for correctness, regressions, and compatibility. If the fix arrives faster than maintainers can review it, the benefit may be delayed or lost.

AI-found flaws push organizations to patch sooner. That is hard for applications built from many open-source components, because every one of those components needs its own patch and re-release, in sequence. A modern application may include hundreds of direct and transitive dependencies. Each dependency has its own maintainers, release cadence, and compatibility constraints. Patching one component can require updating another, and the process can cascade across an entire software supply chain. For institutions with legacy systems or limited engineering staff, that sequence can be daunting.

The Economics of Maintenance: A Widening Funding Gap

The money in open source is lopsided. The Linux Foundation brought in $292,217,236 in 2024. The Apache Software Foundation, which the policy authors cite as an example of projects that run on volunteer labor and sponsorships, brought in $2,379,402, less than 1 percent of that. Across open source, most users never pay, a pattern known as the free-rider problem. Companies build products on free components, but they often do not contribute back in proportion to the value they capture.

That imbalance matters more as AI increases the volume of code and the speed of vulnerability discovery. A project with one or two part-time maintainers cannot easily absorb a flood of AI-generated pull requests, security reports, and dependency updates. Even well-funded foundations struggle to coordinate across hundreds of projects. The result is a maintenance backlog that can persist for years, leaving known flaws unpatched and new contributions unreviewed.

Visibility Gaps: SBOMs and the Limits of Mandates

A software bill of materials, or SBOM, is a machine-readable list of the components inside an application. Despite US and EU mandates, the vast majority of open-source applications do not generate or ship one. That leaves organizations without a clear inventory of what they run. An SBOM would show what is present, not whether each piece is maintained, funded, secure, or abandoned. It is a starting point for visibility, not a complete risk assessment.

Without that visibility, institutions cannot easily answer basic questions. Which projects are critical to their operations? Which are maintained by a single person? Which have no recent security releases? Which rely on dependencies that have been abandoned? AI can help analyze code and dependencies, but it cannot replace governance. Someone still has to decide what levels of risk are acceptable, what resources to invest, and how to respond when a critical dependency fails.

Governance, Documentation, and the Long Road Ahead

Open source is governed project by project, so ecosystem-wide numbers on AI’s effects are hard to collect. The policy authors want projects to put more resources into documentation, packaging, fundraising, and gathering requirements. Deciding what a project needs and getting its community to agree still falls to people. Those activities are not glamorous, but they determine whether a project can survive an influx of AI-generated contributions and AI-discovered vulnerabilities.

Documentation helps new contributors understand how to participate without adding to maintainer overload. Packaging reduces the friction of distributing secure releases. Fundraising creates the capacity to pay for review, testing, and security response. Requirements gathering aligns contributors around a shared roadmap rather than a scatter of individual interests. None of these tasks are solved by better models alone. They require sustained human coordination and, in many cases, money.

Most institutions, the authors write, face perhaps their largest challenge in learning the governance, maintenance, and security state of their software, so they can spot critical dependencies before something fails. That challenge is both technical and organizational. It involves asking vendors for SBOMs, tracking the health of upstream projects, funding maintainers, and building internal processes for rapid patching. AI may accelerate parts of that work, but it also raises the stakes. The more code that is generated, the more review, maintenance, and governance capacity is needed to keep the software that the world depends on from becoming a liability. The task is to spot critical dependencies before something fails.

Source: Help Net Security News

• Max Junestrand is co-founder and CEO of Legora, a Stockholm-based company building AI tools for lawyers.
• He spoke at Wave by Vento in Turin on Thursday during a session titled The Compounding Bet.
• Junestrand said sovereignty in enterprise applications, consumer apps, or the software layer is an excuse for companies not bold enough to compete globally.
• He said sovereignty matters for energy, defence, and infrastructure, but enterprise software buyers have offices in Europe, the US, and Asia, so a sovereign product does not make sense for them.
• Jeannette zu Fürstenberg, president and managing director of General Catalyst, argued for sovereignty lower in the stack.
• Zu Fürstenberg said services make up 70% of Europe's GDP, AI is starting to replace some of that work, and Europe needs its own energy and compute clusters or value will leave.
• She described the goal as preventing an involuntary transfer of wealth from Europe to the US or elsewhere.
• At the same event on Wednesday, Alibaba's Joe Tsai said open source is Europe's only way to AI independence.
• In September, Junestrand said Europe should not build a frontier lab of its own.
• Junestrand said the top player in software tends to take about 90% of a market, and legal AI will have one worldwide winner rather than one winner per region.
• Legora's closest rival, Harvey, closed a $550m round at a $15.6bn valuation in September.
• Junestrand said lawyers give a product only one chance, and in mid-2024 Legora paused its sales push to make sure the product was good enough.
• Law firms are under pressure because work that took 10 hours now takes one, which hurts firms that bill by the hour.
• Legora uses several AI models because each is strong at different things; a Claude model is very good at drafting, and an OpenAI model is good at fact-checking.
• Legora had about $1m in revenue in October 2024, reached $100m in under 18 months, and reached $200m in under six more months.
• Junestrand said it will reach $300m after more than 50% growth each quarter for about two years.
• The company started the year with 200 people and 22 sales staff, and plans to have 300 sales staff by the end of the year.
• The median time people have been at the company is three to four months.
• Each hire needs sign-off from a culture carrier outside the hiring team, an idea Legora took from Amazon.
• Legora's new chief financial officer had seen a company grow from $30m to $300m in four years; Junestrand said Legora is doing that in four quarters.
• Junestrand ranks Legora's investors. Every two months, he sends them a leaderboard of how many customer introductions each has made.
• One investor that had put $150m into a round came second to last, then made 50 introductions in two weeks.
• Legora has just opened an office in Milan. Italy has more lawyers per person than anywhere else in Europe.

Software sovereignty as an excuse

Max Junestrand, co-founder and chief executive of Legora, used his appearance at Wave by Vento in Turin to push back against a phrase that has become common in European technology policy. He told the audience that sovereignty in enterprise applications, consumer apps, or the software layer is an excuse for companies that are not bold enough to compete globally. The enterprise layer and the software layer, he said, are the global market. That argument cuts against a growing political appetite for European alternatives in cloud computing, productivity software, and artificial intelligence. For Junestrand, the problem with sovereign software is not that Europe lacks talent or ambition. It is that the customers for enterprise software are already global. They have offices in Europe, the United States, and Asia. A product built only for one region would not serve them. A sovereign product, he said, does not really make any sense at all for such buyers.

The session, titled The Compounding Bet, was led by Jeannette zu Fürstenberg, president and managing director of General Catalyst, an investor in Legora. Legora is based in Stockholm and builds AI tools for lawyers. Junestrand said the company's market was global from day one. That decision was not an afterthought. It shaped the product, the sales motion, and the pace of hiring. While many European startups begin with a domestic base and then expand, Legora treated the world as its addressable market from the start. The approach reflects Junestrand's broader view that software companies should not use sovereignty as a reason to stay small. In his telling, the software layer is one of the few parts of the economy where the winner can come from anywhere, as long as the product is good enough and the company is willing to sell everywhere.

Where the value goes

Zu Fürstenberg offered a different emphasis. She made the case for sovereignty lower down the stack. Services make up 70% of Europe's GDP, she said, and AI is starting to replace some of that work. If Europe does not build its own energy and compute clusters, she warned, the value created by that transition will leave the continent. Her concern is not about apps or enterprise software interfaces. It is about the physical and computational foundations that make AI possible. Data centers, energy supply, and compute capacity are strategic assets. If they are owned or controlled elsewhere, Europe may find itself paying for its own productivity gains in ways that benefit other economies. Zu Fürstenberg described the goal as locking down part of what otherwise would look like an involuntary transfer of wealth from Europe to the US or elsewhere in the world. That phrase captures a central anxiety in European industrial policy: the fear that the continent will generate demand and talent but capture little of the

Source: TNW | Artificial-intelligence News

Artificial intelligence has made it easier than ever to launch and run a company from almost any location. Cloud infrastructure, remote collaboration tools, and AI-powered coding assistants have lowered the barriers to building software. Yet the founders behind many of the most promising startups are still choosing to sit together, according to Station F director Roxanne Varza and Anthropic’s Aiden Blake.

Speaking on a panel in Turin on Thursday, the two argued that physical proximity remains a powerful force in the startup world, even in an era when products can be built and sold online. The discussion, titled “The Power of Proximity,” examined why people, information, and chance encounters still shape company-building. The central message was simple: AI may remove distance as a technical obstacle, but it does not remove the human need for trust, momentum, and shared context.

“What’s really interesting is we’re seeing more and more people coming since the ‘AI boom.’ I think actually a lot of teams are really embracing physical presence,” Varza said. Her observation challenges the assumption that remote-first work and distributed teams have permanently replaced the office for early-stage companies. Instead, she suggested that the latest wave of AI startups is reinforcing the value of being in the same room.

Station F doubles down on physical presence

Station F, the large startup campus in Paris, always hosts around 1,000 early-stage companies on site, Varza said. That scale makes it one of Europe’s most visible experiments in clustering founders, investors, and operators. The campus is not simply a real estate project. It is designed to increase the frequency of interactions that can lead to hires, partnerships, customer introductions, and fundraising.

In February, Station F launched F/ai, a programme dedicated to AI startups. Its partners include Anthropic, OpenAI, Mistral AI, and Meta. The programme allows teams to work in hybrid ways, but participants must come to the campus for certain moments. Without those shared days, Varza said, teams do not get the momentum they need. That requirement reflects a broader belief that early-stage energy is difficult to replicate when everyone is scattered across time zones and calendars.

The international mix of the programme is notable. About two-thirds of the current batch is not French, according to Varza. Teams have come from Asia, Stockholm, the United Kingdom, and Poland. For many of them, Paris is not just a place to rent a desk. It is a gateway to European customers, investors, and talent. The presence of non-French teams also shows how AI has globalized startup formation, even as local ecosystems compete for attention.

Why Anthropic joined the startup campus

Blake said Anthropic joined the programme because it wants to be present in the startup community. The company, known for its AI models and safety research, does not only want to sell to enterprises. It also wants to understand how early-stage builders are using AI, what problems they face, and where the next wave of innovation is emerging. Being physically close to founders is one way to gather that intelligence.

Blake’s own career offers a lesson in the value of ecosystem proximity. He said his last three employers, Google, Notion, and Anthropic, have all been Station F partners. That pattern suggests that leading technology companies see startup campuses as more than marketing opportunities. They are places to recruit, learn, and build relationships with founders who may become long-term customers or partners.

Anthropic supports startups across Europe, the Middle East, and Africa from Dublin, where 150 people work across several teams, Blake said. Dublin offers a deep talent pool and a time zone that covers markets from South Africa to France and Germany. For a company selling to startups across EMEA, that geographic position matters. It allows teams to respond to customers and partners during a broad working day, while still staying connected to European headquarters and investors.

People, information, and serendipity

When asked whether proximity is mainly about people, information, or serendipity, Varza said it is all three. Many founders today are repeat founders with large networks, she noted. Being in the same room with them opens doors that are difficult to open through email or video calls. A casual introduction can lead to a pilot customer, an angel investment, or a key hire. Those outcomes are rarely the result of a formal process.

Varza also argued that relationships cannot be engineered, only influenced. Much of the value of a startup campus comes from leaving room for chance. A founder might meet an engineer at a coffee stand, a future co-founder at a demo day, or an investor at a late-night dinner. These encounters are inefficient by design, but they are often exactly what early-stage companies need. They create weak ties that later become strong partnerships.

Blake said founders at Anthropic’s events want to meet other builders with the same problems. They also want to hear from people who are further along. That desire for peer learning is one reason in-person gatherings remain popular even when online content is abundant. Founders can read blog posts, watch talks, or join webinars, but they cannot easily replicate the trust that forms when they share a room and compare notes.

Blake named access to capital as part of proximity too. He pointed to Stockholm and Warsaw as cities where new companies are emerging. On Wednesday at the same event, Bending Spoons’ Luca Ferrari said capital is no longer Europe’s big barrier. That shift matters. If funding is more available, then the advantage may come from other factors: talent density, customer access, speed of learning, and the ability to build trusted relationships.

Remote-first, then back together

Varza said a great company can now be built from anywhere, but coming together physically still matters. That may sound contradictory, but it reflects the hybrid reality of many modern startups. Teams can hire globally and work asynchronously for much of the week. Yet they still gather for planning sessions, customer meetings, onboarding, and moments that require high-bandwidth collaboration.

Blake offered an example. ElevenLabs started fully remote and opened offices as it grew. Last month it opened one in Brussels. The trajectory is familiar: a startup begins with distributed talent because that is the fastest way to assemble a team. As it scales, it adds physical hubs to improve coordination, culture, and customer proximity. The office becomes less about desks and more about density.

Many people who have worked remotely want to be back around teammates, Blake said, especially in go-to-market roles, where they learn from each other. Sales, marketing, and customer success often depend on overheard conversations, quick feedback, and informal coaching. Those interactions are hard to schedule. They happen in the gaps between meetings, when people can ask a question or watch a colleague handle a difficult call. Not every company agrees. In August, Dropbox’s new co-CEO said remote work is staying at the company. The debate is far from settled.

What will give startups an edge?

Asked what will give a startup its edge in five years, Varza said the technology stack matters. So will how fast founders build relationships, she said. In a world where AI tools are widely available, the technical playing field may become more level. The ability to find the right partner, hire the right person, and earn trust quickly could become a more durable advantage.

Blake said he finds it hard to predict even five days ahead. That humility reflects the pace of change in AI, where models, products, and markets shift quickly. The startups that succeed, he said, will be clear about the problem they solve and keep listening to what customers care about. That final point returns to the theme of proximity: the best way to understand what customers care about is often to be close enough to hear it directly, watch how they work, and respond in real time.

Source: TNW | Ecosystems News

Europe’s venture-backed companies are on course to be worth more than the continent’s traditional industrial base within five years, according to new industry data presented at a technology conference in Turin. The founder and chief executive of a European tech data platform said the venture capital ecosystem is approaching a historic threshold, and that the first trillion-dollar venture-backed company is likely to emerge from a business that is still early stage today.

‘I think that the VC-backed ecosystem is going to overtake our industrial base in terms of total value created within the next five years, if we play our cards right,’ he told an audience at the event. ‘And I think that also the first trillion-dollar VC-backed company is going to be created. And it’s a company that’s maybe still early stage today, so we have to think about that future and also prepare for it and have the conditions for that to really happen.’

The remarks came during a session on the state of the European technology ecosystem, followed by a conversation with a partner at a venture firm. The data paints a picture of an ecosystem that has grown rapidly in scale, but still faces structural gaps in late-stage capital, public markets, and pension investment.

Investment and valuation on the rise

European venture investment is running at $89bn a year and rising. Large rounds for companies such as Mistral, Helsing and Isomorphic Labs are driving the increase. Mistral raised €3bn in September, a signal that European AI companies can attract capital at scale.

Europe now has 56 venture-backed companies worth more than $10bn. Together, its venture-backed companies are worth $4.4tn, almost a quarter of the value of Europe’s stock market. Exits by venture-backed companies this year are larger than in previous years combined. They include Milan’s Bending Spoons, which raised $1.68bn in its US listing in July.

The figures show 54,771 European startups that have raised at least $100,000, against 79,432 in the US. The gap widens at each stage. Europe has 1,233 companies that have raised $100m or more, against 5,115 in the US. Four European companies are worth more than $100bn: Spotify, Arm, Booking.com and Revolut. The US has seven worth more than $1tn, and Europe has none.

Rounds of $100m or more show a fourfold gap with the US. But for the same amount of capital raised, European startups are as likely to become unicorns as American ones. That finding challenges the idea that European founders are less capable of building large companies. Instead, it suggests the difference lies in the amount of capital available to scale them.

Where the money goes—and where it leaves

US firms such as Sequoia, General Catalyst and Accel have almost doubled their investment in Europe year on year. As a result, overseas investors own most of the later-stage shares in Europe’s most successful startups. The gains from those companies then leave Europe. This dynamic means that even as European tech creates value, a large share of the financial return accrues to investors outside the continent.

Europeans save a lot, but most of it goes into bank accounts and housing, not into equity. Putting just 1% of Europe’s pension capital into venture capital would raise the money available to scale-ups by 50%. European pension funds and insurers hold about €15tn. Over the past decade, they put €15.5bn into venture capital. This year alone, about $50bn of European capital went into bonds issued by US hyperscalers. The contrast is stark: European savings are financing American technology giants rather than European scale-ups.

The same gap shows up in AI. A new AI report says four US hyperscalers expect about $733bn in capital spending this year. The EU’s initial contribution to AI gigafactories is €1bn, within a plan seeking up to €10bn in public money and at least €20bn from private investors. A data centre in Europe does not give Europe control of the models inside it. Without domestic compute, talent, and capital, Europe risks becoming a consumer of AI rather than a producer.

Not only a capital problem

More money will not be enough on its own. Countries where restructuring a company is costly, such as Spain, Italy and France, have fewer unicorns per person. In Denmark and the US, the cost is low. About 42% of European unicorn founders built their companies in the US. That statistic highlights how regulatory friction, labour market rules, and bankruptcy regimes can push founders to scale elsewhere.

There are calls for a single European capital market, an idea backed by prominent European policymakers. A proposed company form that would work across the EU, known as EU Inc, is also gaining support. Such reforms aim to reduce the fragmentation that forces startups to navigate 27 different legal and tax systems. A true single market for capital would allow pension funds to invest across borders more easily and give scale-ups access to a much larger pool of equity.

European governments spend about €2tn a year on public procurement, and only a tiny share reaches startups. Defence is the exception, where money has flowed to companies such as Helsing and Quantum Systems. Quantum Systems raised $1.2bn in July. The same approach is needed in space, energy and compute, according to industry observers. Public procurement can act as a catalyst for innovation if governments use their purchasing power to support young companies.

The road to a trillion-dollar company

The prospect of a first trillion-dollar venture-backed company in Europe depends on more than a few large funding rounds. It requires a deep pipeline of startups, a functioning exit market, and a regulatory environment that allows companies to scale without leaving the continent. Europe has shown it can create world-class technology: Spotify, Arm, Booking.com and Revolut are proof. But the next generation of giants will need later-stage capital that is currently scarce.

Pension reform is central. If European pension funds allocated even a small fraction of their assets to venture capital, the impact would be transformative. The €15tn held by pension funds and insurers represents a vast pool of long-term capital. Redirecting a sliver of that into European venture would help close the late-stage funding gap with the US. It would also keep more of the returns from European success stories within Europe.

At the same time, the ecosystem must address the exit gap. Europe’s public markets are less deep for technology companies, which pushes many startups to list in the US. Bending Spoons’ US listing is a recent example. Building stronger European Nasdaq-style exchanges and encouraging institutional investors to participate in IPOs could help retain more companies. The lack of $1tn companies in Europe is not due to a lack of talent or ideas, but to a lack of capital and market infrastructure to support them.

The AI race adds urgency. The US is spending hundreds of billions on compute infrastructure. Europe’s public contribution to AI gigafactories is smaller by orders of magnitude. Without a coordinated approach to compute, energy, and data, European AI companies may struggle to compete at the frontier. The report’s warning that a data centre in Europe does not give Europe control of the models inside it is a reminder that infrastructure alone is not enough. Sovereignty requires ownership of the technology stack.

Defence tech has shown what is possible when procurement and capital align. Helsing and Quantum Systems have attracted significant investment, partly because defence ministries have become customers. That model could be replicated in other strategic sectors. Space, energy, and compute are all areas where public procurement could de-risk early customers and attract private capital. The €2tn annual procurement budget is a powerful lever if used strategically.

Ultimately, the forecast that Europe’s venture-backed ecosystem could overtake its industrial base within five years is not guaranteed. It depends on policy choices, capital market reforms, and the willingness of European institutions to invest in their own technology. The first trillion-dollar venture-backed company may already exist as a small startup. Whether it scales in Europe or elsewhere will depend on the conditions Europe creates today.

Source: TNW | Ecosystems News

The headline number is large enough to dominate the morning. Nvidia is contributing $1 billion, AMD $500 million, OpenAI $200 million, and both Anthropic and Google $150 million. The companies are not handing over unrestricted cash. The commitments take the form of AI tools and compute credits, meaning access to specialised hardware, model APIs, and cloud instances rather than a simple transfer to the US Treasury. That structure matters because compute is the scarce input in modern AI research: without it, models cannot be trained, simulations cannot run, and data cannot be processed at scale.

Who Is Giving What

• Nvidia: $1 billion in AI tools and compute credits, with its own share spread over five years across university research, quantum computing, and cloud providers serving government.
• AMD: $500 million.
• OpenAI: $200 million.
• Anthropic: $150 million.
• Google: $150 million, the smallest share among the five donors.

Michael Kratsios, the White House science policy director, said the commitments would channel billions across the science ecosystem. The language is expansive, but the practical effect depends on how federal agencies, universities, and national laboratories can claim the credits. The Genesis Mission is intended to connect AI capabilities to problems in biology, materials science, energy, climate, and national security. If the credits are usable, they could lower the barrier for academic groups that cannot afford commercial rates for high-end GPUs or inference. If they are not, the announcement remains a headline without a reservation system.

A Summit With Medals and Education Money

The summit is not only about corporate pledges. It also carries more than $100 million for science and engineering education, according to the announcement. The White House is using the event to celebrate prominent figures in technology and science. Elon Musk, Jensen Huang, Sergey Brin, and Lisa Su are expected to receive the National Medal of Science. Michael Dell is set to receive the National Medal of Technology and Innovation. The presence of those names gives the event a broadened political and cultural weight: the administration is presenting AI and advanced computing as central to American scientific leadership.

The ceremony also underscores how closely the federal government's science agenda is now tied to the commercial AI industry. The same companies that build and sell AI infrastructure are being asked to underwrite a portion of public research. That model can move quickly, but it also raises governance questions. When private firms donate credits, they retain control over the underlying infrastructure, the terms of use, and the priority rules. Public scientists may gain access, but they do not necessarily gain ownership or long-term capacity.

Microsoft Suspension Shadows the Summit

One guest had a complicated morning. Satya Nadella, Microsoft's chief executive, is being honoured at the summit. Hours earlier, the vice president and the labour secretary suspended Microsoft from a programme that lets employers sponsor foreign staff for permanent residency. Adobe and six IT services firms were also suspended, with alleged fraud cited as the reason. Capgemini, the only European name on that list, was not invited to Washington. The timing creates an awkward split-screen: Microsoft is celebrated for technology leadership while facing restrictions on its ability to sponsor immigrant workers for permanent residency.

The immigration programme matters to the technology industry because software, AI, and semiconductor firms rely heavily on foreign-born engineers and researchers. A suspension can disrupt hiring, retention, and long-term research teams. For Microsoft, which has major research operations and a large AI partnership portfolio, the move adds uncertainty. For the summit, it introduces a contrast between the administration's push to accelerate AI research and its simultaneous crackdown on a visa route that many technology companies use to keep specialised talent in the United States.

Compute Credits Are Not Reserved Capacity

Nobody has explained how the compute gets reserved. Credits are not capacity. A credit represents a promise of purchasing power or access, but the companies issuing them are also selling the same machine time to customers paying commercial rates. If demand for AI accelerators remains high, federal scientists could find themselves competing with better-funded corporate labs for the same clusters. The pledge does not automatically create new data centres, new power supplies, or new chips. It redirects access to existing or planned infrastructure, and the details of that redirection remain unclear.

The distinction between credits and capacity is central to whether the $2.4 billion figure translates into scientific output. A researcher needs more than a voucher. She needs a reliable allocation of GPU hours, storage, networking, software support, and technical staff. She needs to know when the compute will be available, for how long, and under what conditions. Without a queue reserved for federal science, the credits may be used only when commercial demand allows. That could mean off-peak access, older hardware, or limited inference budgets rather than the large-scale training runs that drive frontier results.

There is also the question of valuation. Companies can count in-kind contributions at list prices, but the actual marginal cost to the donor may be lower. A cloud provider with spare capacity may value a credit differently than a research university that must buy time at market rates. The announcement does not resolve how the $2.4 billion will be audited, whether it can be rolled over, or what happens if a company changes its internal priorities. Those are not minor accounting details. They determine whether the programme becomes a durable piece of science infrastructure or a one-time marketing exercise.

Why Compute Allocation Matters

Advanced AI research is capital-intensive. Training frontier models can require thousands of specialised accelerators running for weeks or months. Scientific computing has similar demands: molecular dynamics, climate simulation, fusion modelling, and genomic analysis all need massive parallel processing. When compute is scarce, researchers queue. When it is expensive, smaller institutions drop out. The result is a concentration of scientific capability in a handful of well-funded labs and corporate research centres. A federal programme that promises credits is trying to counteract that concentration, but only if the credits come with priority access and technical support.

The US also faces physical constraints. Data centres need power, cooling, land, and transmission. The most advanced chips are produced by a small number of foundries, and export controls shape who can buy them. Federal science competes not only with commercial AI labs but also with allied governments building sovereign compute capacity. In that environment, a donation of credits can be politically useful, but it does not change the underlying supply chain. The government would need procurement authority, long-term contracts, or direct investment to guarantee capacity for public research.

Britain Moves on the Same Companies

Britain spent the same morning on the same companies. The Information Commissioner's Office named Google, OpenAI, and Anthropic among ten developers from which it had secured changes after two years of scrutiny. The regulator also opened a call for evidence on how organisations manage the risks from AI agents. Three of the five donors in Washington, in other words, were simultaneously facing regulatory attention in London. The overlap is striking. It shows that the same firms being courted for voluntary scientific contributions are also subjects of formal oversight in another major jurisdiction.

The UK action focuses on data protection, transparency, and agentic AI risks. AI agents are systems that can take actions, use tools, and pursue goals with limited human input. Their risks include unauthorised data access, unintended transactions, and opaque decision chains. The call for evidence suggests regulators are trying to understand how organisations deploy these systems before setting rules. For Google, OpenAI, and Anthropic, the changes secured by the commissioner may be modest, but the scrutiny signals that AI safety and accountability remain live issues even as the US administration promotes a lighter-touch approach.

No Mandatory Guardrails

Trump has called AI safety concerns a hoax. Last week he and a group of AI executives signed an accord with no mandatory guardrails. Under that agreement, companies would work with outside auditors and tighten their own internal controls. The arrangement is voluntary. It does not impose civil penalties, licensing requirements, or independent testing mandates. It relies on reputational incentives and corporate self-governance. Critics argue that voluntary commitments are insufficient for systems that can affect national security, elections, health care, and financial markets. Supporters argue that mandatory rules would slow innovation and push development overseas.

The contrast with the UK's approach is sharp. London is extracting changes from developers and asking for evidence on agent risks. Washington is celebrating donations and voluntary audits. Both approaches are active at the same time, and the same companies operate under both. That dual exposure may shape corporate behaviour: firms may accept voluntary commitments in the US while making binding adjustments in Europe. The result could be a patchwork of obligations rather than a coherent global standard.

The Genesis Mission Already Had Billions

The Genesis Mission already had money. Reporting in July indicated that it had more than $5 billion behind it across fifteen agencies. Those funds were spread across federal programmes, national laboratories, and research initiatives. What the mission did not have, and still does not, is a guaranteed place in the queue for machines. The new $2.4 billion pledge adds to the financial total, but it does not resolve the structural bottleneck. Compute allocation remains the missing piece. Without reserved capacity, the mission depends on the goodwill and spare cycles of private providers.

The federal government has explored this problem before. The National AI Research Resource pilot and other efforts have tried to broaden access to AI compute for academics, small companies, and public-interest researchers. Those programmes face the same challenge: the most advanced chips are concentrated in a few commercial clouds, and demand outstrips supply. Government agencies can buy time, but they often compete with private labs that can pay more and plan further ahead. A donation model can help at the margin, but it does not create a public compute utility.

For scientists, the practical questions are immediate. Can a university team apply for a block of GPU hours for a six-month project? Can a national laboratory reserve inference capacity for a real-time experiment? Can a graduate student get access without a corporate sponsor? The announcement does not answer these questions. It provides a number and a list of donors. The implementation details, allocation rules, and oversight mechanisms are still to come. Until those exist, the $2.4 billion is best understood as a promise of access rather than a guarantee of capacity. The central unresolved issue is not whether the money is large, but whether the machines will be there when federal scientists need them.

Source: TNW | Artificial-intelligence News

• SAP has committed more than €1bn over four years to Prior Labs, a German startup that builds tabular foundation models.
• Sean Kask, SAP’s chief AI strategy officer, says established software companies must rebuild their products around AI rather than add AI as a feature.
• Tabular models handle rows, columns, and spreadsheets that large language models cannot mathematically process.
• Prior Labs leads the TabArena benchmark and has applied its models to cancer diagnosis and bank transactions.
• SAP keeps Prior Labs as a separate lab with open-weight models, while using more than 100 models from other providers internally.
• SAP argues Europe should not compete directly on large language models but should build the data assets that make AI useful.

Why SAP made a €1bn bet on tabular AI

SAP’s decision to commit more than €1bn over four years to Prior Labs is not a bet on another large language model. It is a bet on the data layer that most AI companies have overlooked. Prior Labs, a German startup, builds tabular foundation models: AI systems designed for data held in tables, the rows and columns that underpin spreadsheets, ERP systems, financial ledgers, and operational databases. SAP completed the acquisition in July and has promised to grow Prior Labs into a frontier AI lab.

The strategic logic was laid out by Sean Kask, SAP’s chief AI strategy officer, during a session in Turin. Kask argued that established software companies cannot survive by treating AI as an add-on feature. They must rebuild their products around AI from the ground up. He extended a familiar idea: just as every company has become a software company, every software company now has to become an AI company, or it will perish. For SAP, that means rethinking interfaces, data models, and the way enterprise applications generate value.

The problem with tables and language models

Large language models learn by predicting the next word in a sequence of text. That makes them powerful for writing, summarising, coding, and conversation. But it also imposes a mathematical limitation. Tables are not sequences of words. They contain heterogeneous columns, numeric distributions, categorical values, missing entries, and relationships that span rows. A language model cannot natively perform the numerical predictions and classifications that a tabular model can.

Kask estimated that about 80% of business data is unstructured, including text, email, and images. Yet he argued that the remaining 20% held in tables generates about 80% of a company’s value. That inversion is easy to miss because the biggest AI labs focus on scaling language models. The most valuable enterprise data often sits quietly in spreadsheets, transaction logs, supply-chain tables, and customer records. Tabular foundation models are built for exactly that terrain.

Why Prior Labs stood out

SAP began building tabular models in-house a couple of years ago. It already uses its own model, SAP-RPT-1, in production. Prior Labs fitted because its model leads the TabArena benchmark, a public test of tabular AI performance. The startup was also already applying its technology to cancer diagnosis and bank transactions, and SAP had been doing research with it. That combination of benchmark leadership and real-world deployment made Prior Labs a natural acquisition target.

SAP promised to keep Prior Labs as a separate lab with room for its own research. Its model will remain open weight, so researchers and startups can build on it. That structure is unusual for a large enterprise acquisition. It suggests SAP wants Prior Labs to retain the speed and culture of a frontier research lab while giving it the data, distribution, and customer access of a global software company.

From one model per problem to one model for many

Kask described how machine learning used to work inside large companies. A team would build one model for each problem, a process that could take weeks or months. A company might train and tune 100 different models across its operations. With a tabular foundation model, one model can do that work in days, he said, and it beats established methods such as XGBoost on accuracy.

That shift matters because it changes the economics of enterprise AI. Instead of maintaining a sprawling portfolio of narrow models, companies can use a general tabular model that adapts across use cases. The model can handle forecasting, classification, anomaly detection, and scoring without a bespoke engineering project for every table. For SAP, whose software touches finance, procurement, supply chains, HR, and customer experience, that generality is valuable.

SAP’s model-agnostic approach

SAP does not build its own large language model. Kask said that would be costly and that the leading models are converging. Instead, customers can use models from Google, OpenAI, Anthropic, and Mistral. SAP itself uses more than 100 models internally, tests each use case against all of them, and picks the best one. This model-agnostic strategy lets SAP avoid betting on a single provider while giving customers choice.

For SAP, being AI-first also means rebuilding its interface. Users can ask questions in plain language, and the system generates the tables they need on screen. That may sound simple, but it reverses decades of enterprise software design. Instead of navigating menus, transactions, and reports, users describe an outcome. The software then assembles the data, calculations, and visual structure behind it. The interface becomes conversational, while the underlying tabular models do the numerical work.

Europe’s role in the AI race

Kask warned that Europe should not jump into the red ocean of large language models. Spending $10bn on a model that is outdated in six months does not set anyone apart, he said. Europe should instead build the assets that make those models useful. For SAP, that means the knowledge graph that links 500,000 tables and 7 million fields. That semantic layer makes AI agents accurate enough to use at work, because they can ground their answers in a company’s actual data structures and relationships.

Not every European company is taking that route. Mistral launched Large 4, a 1-trillion-parameter open-weight model, on Tuesday. That launch shows there is still appetite in Europe for competing at the frontier of large language models. But Kask’s argument is that the bigger European opportunity may lie in enterprise data, process knowledge, and the connective tissue that turns generic models into reliable business tools.

An ecosystem strategy, not just products

SAP’s approach extends beyond its own research. Kask said every dollar of SAP software sold generates $6 to $10 for its ecosystem of partners. SAP licenses startups’ technology into its products, resells partners through its store, and sometimes buys them. On Tuesday, it agreed to buy TechWolf, a Belgian AI workforce startup. That deal follows the same pattern: identify specialised AI companies, integrate their capabilities, and expose them to SAP’s enterprise customer base.

The Prior Labs acquisition sits at the centre of this strategy. It gives SAP control of a leading tabular model, an open-weight research lab, and a team focused on the data that drives most business value. It also gives SAP a counter-position to the language-model arms race. While others scale text prediction, SAP is scaling prediction and classification on the tables where enterprise decisions are made. The TechWolf deal, announced the same week as Mistral’s Large 4 launch, underscores how SAP is blending acquisitions, partner resale, and open-weight research as it tries to turn enterprise data into working AI systems.

Source: TNW | Artificial-intelligence News

Agentic AI describes systems that can plan, reason, and act on behalf of users or other systems. Unlike a simple chatbot that waits for a prompt, an AI agent can request data, call APIs, trigger workflows, and collaborate with other agents across distributed and multi-cloud environments. These agents operate continuously. They do not respect traditional peak-hour models. They create always-on traffic profiles with bursts that can appear in microseconds and spread across data centers, edge locations, and public clouds.

That shift changes the design criteria for enterprise and service provider networks. The old ways of planning for voice, video, and general internet traffic are not sufficient. Organizations need networks that can adapt dynamically as AI agents make decisions and exchange data at machine speed. The question is no longer whether the network can carry more bandwidth. It is whether the network can enforce policy, guarantee latency, maintain sovereignty, and assure service levels while AI workloads scale unpredictably.

Why Agentic AI Breaks Traditional Network Assumptions

Traditional traffic engineering was built around predictable patterns. Networks were sized for busy hours, with capacity planned for the busiest period of the day or week. That model worked well for human-driven applications: email, web browsing, video streaming, and voice calls. It assumed that demand would rise and fall with human activity. It also assumed that changes could be made over days or weeks, because new applications rarely required instant network reconfiguration.

Agentic AI upends those assumptions. AI agents can run around the clock. They can generate traffic that is highly variable, latency-sensitive, and difficult to predict. A single agent may query multiple data sources, invoke models in different clouds, and coordinate with other agents in real time. The network may need to shift paths in seconds, not weeks. Manual troubleshooting and static reports cannot keep up.

Consider a healthcare workflow in which an AI agent reviews patient data, checks for contraindications, and triggers a clinician alert. The agent may need to access electronic health records, imaging systems, pharmacy databases, and external registries. Some of that traffic must stay within a jurisdiction for privacy and sovereignty reasons. Other parts may need ultra-low latency to support real-time decisions. A network that cannot distinguish between these requirements, or that cannot route traffic according to policy, becomes a bottleneck and a compliance risk.

Financial services present similar demands. Fraud detection, algorithmic trading, risk modeling, and customer service agents all rely on rapid access to data and services. A delay of milliseconds can affect outcomes. An outage or misrouted flow can violate regulatory requirements. Networks must provide precise path control, deterministic performance, and strong security without creating operational complexity that overwhelms IT teams.

The Limits of Legacy IP Architectures

Many enterprise and service provider networks still rely on architectures that were designed for earlier eras of VPN and internet connectivity. These networks have served organizations well, but they are often bloated, rigid, and complex. They may use multiple protocol layers, manually engineered tunnels, and extensive state management. They can take weeks to reconfigure for new demands. They may lack the telemetry needed to understand what is happening in real time.

Legacy IP networks also tend to treat all traffic the same, or at least they rely on coarse classes of service. That approach is insufficient when different AI agents and workloads have different requirements. One workload may need the lowest possible latency. Another may need high available bandwidth. Another may need a path that avoids a specific country or region. Another may need maximum resiliency or disjoint paths. Static, one-size-fits-all rules cannot satisfy these varied needs.

Operators often fall back on reactive manual troubleshooting. When performance degrades, they inspect logs, run tests, and try to identify the cause. By the time they have an answer, the traffic pattern may have changed. Static reports are frequently outdated before they are used. This reactive mode is costly and slow, and it cannot support AI services that make decisions in microseconds.

Three Capabilities for the Agentic AI Era

To support agentic AI, networks need at least three foundational capabilities: real-time telemetry for visibility and automation, segment routing and EVPN for convergence and precise path control, and FlexAlgo for traffic-specific optimization. Security features such as MACsec are also becoming essential for protecting traffic in transit and meeting compliance requirements.

Real-Time Telemetry and Automated Intervention

AI workloads demand visibility at a granularity that traditional network monitoring cannot provide. Operators need real-time telemetry to understand traffic patterns, detect anomalies, and support automated intervention. Streaming telemetry and model-driven telemetry can provide continuous data about link utilization, latency, jitter, packet loss, and application performance. When combined with automation and AIOps, this data can trigger closed-loop responses: rerouting traffic, adjusting policies, or scaling capacity before users or agents are affected.

Without real-time telemetry, operators are left with reactive manual troubleshooting. They rely on static reports and after-the-fact analysis. That is not enough when AI agents are making decisions in microseconds and when service-level agreements carry financial and regulatory consequences. Real-time visibility is the foundation for dynamic control. It turns the network from a passive pipe into an active participant in service assurance.

Segment Routing and EVPN for Dynamic Path Control

Modern IP architectures based on segment routing and EVPN provide a more scalable and flexible foundation. Segment routing simplifies traffic engineering by allowing a source node to specify a path as a list of segments. It reduces state in the core, leverages existing network investments, and creates an evolutionary path toward greater agility. EVPN provides a unified control plane for Layer 2 and Layer 3 VPN services, supporting multi-tenancy, mobility, and efficient service delivery.

Together, segment routing and EVPN enable convergence and precise path control. They allow the network to route traffic dynamically as AI agents' connectivity needs change. Instead of waiting weeks to engineer new tunnels, operators can define intent and let the network compute and maintain the appropriate paths. This is essential when AI workloads move between clouds, data centers, and edge locations, and when performance requirements change from one moment to the next.

Segment routing also protects existing investments. It can be deployed incrementally, interoperating with legacy protocols while introducing new capabilities. That matters because most organizations cannot rip and replace their networks overnight. They need an evolutionary path that supports AI workloads while continuing to serve traditional applications.

FlexAlgo for Workload-Specific Optimization

FlexAlgo, short for flexible algorithm, lets the network calculate optimal paths for different traffic types. One class of traffic might be optimized for latency. Another might be optimized for available bandwidth. Another might be optimized for resiliency. Another might be optimized to satisfy data sovereignty requirements. The network can compute paths according to performance objectives and constraints, rather than forcing all traffic through the same static rules.

FlexAlgo delivers many of the traffic-engineering benefits that operators once sought with RSVP-TE, but without the massive complexity. RSVP-TE relied on manually engineered tunnels and extensive state management. It could be powerful, but it was also operationally heavy. FlexAlgo allows operators to define objectives and constraints, then lets the network automatically compute and maintain the appropriate paths. As networks support different SLAs for different AI agents and workloads, FlexAlgo ensures traffic is matched to performance requirements rather than constrained by one-size-fits-all rules.

MACsec and Security by Design

Security is not optional in the agentic AI era. AI agents may handle sensitive data, trigger critical actions, and cross trust boundaries. MACsec provides Layer 2 encryption and integrity protection for Ethernet links, helping organizations protect traffic in transit and meet compliance requirements. For healthcare, finance, government, and other regulated sectors, MACsec can be a practical way to secure high-speed connectivity without sacrificing performance.

How Enterprises Are Putting These Capabilities Together

Large enterprises in critical sectors are already incorporating these capabilities into their network architectures as part of broader digital transformation initiatives. They need to support a mix of AI and traditional workloads while ensuring that traffic adheres to strict policy, sovereignty, and SLA requirements. They may deploy and manage their own IP networks over leased optical services from providers. Alternatively, they may consume the same capabilities through a fully managed network service. Both models create opportunities for providers to deliver differentiated, value-added services.

The result is a network that automatically enforces business policies and performance objectives. It prevents connectivity bottlenecks and maintains service assurance as AI adoption and digital transformation efforts continue to scale. Instead of treating the network as an afterthought, organizations can use it as a control point for policy, performance, and compliance.

For service providers, this shift is both an opportunity and a challenge. AI creates demand for higher bandwidth, lower latency, and more dynamic connectivity. Providers that modernize their IP networks can monetize the next wave of AI services. They can offer differentiated SLAs, secure connectivity, and managed services that help enterprises focus on AI applications rather than network operations. Providers that stand still risk losing relevance as competitors embrace network evolution.

For enterprises, the calculus is similar. Modernizing the network can unlock new revenue from AI-driven services, improve customer experiences, and reduce operational risk. Delaying modernization can lead to performance bottlenecks, compliance gaps, and competitive disadvantage. The network is no longer just a cost center. It is a strategic asset for AI. The organizations that treat it as such will be better positioned to capture the value of agentic AI while managing its complexity. As

Source: Network World News

Software engineering addressed a similar trust problem years ago with version control, code review, and staged rollouts. A new set of tools from Selector applies that same discipline to AI agents in network operations. The technology, called Foundry, is a development and runtime environment that lets NetOps teams build, test, version, and govern their own AI agents inside Selector’s platform. Selector develops a NetOps platform that was updated earlier this year to provide a correlated view across branches, colocation facilities, on-premises data centers, and public cloud infrastructure.

“We told you what was wrong with the network, we told you how to find the data, we did all of that,” said the company’s co-founder and CEO. “But what to do, what to fix, how to do the fixing, that was still manual or still built into their playbooks. We believe that’s the next level of simplification we can bring in.”

How the platform works

Foundry treats an agent the same way a team would treat a piece of software, from framework choice through production rollout. That means agents are not opaque prompts hidden in a console. They are versioned assets with review gates, test evidence, and rollback paths.

Framework choice and deterministic design

Foundry agents run on Pydantic AI. The company avoided heavier agent frameworks such as CrewAI in favor of something simpler and more deterministic. Agents are defined as configuration, similar to infrastructure as code, and that configuration drives a common orchestrator with domain-specific code underneath it.

The design choice matters for network operations. Deterministic behavior is easier to audit, reproduce, and explain to change advisory boards. When an agent recommends a routing change or opens a ticket with a cloud provider, engineers need to know why. A configuration-driven agent can be inspected, diffed, and tested in the same way as a Terraform module or a Kubernetes manifest. That aligns with the broader GitOps movement in infrastructure management, where the desired state is stored in Git and automated controllers reconcile drift.

Review and rollback

Customers commit agents to their own Git repository. Changes go through the customer’s existing pull-request workflow. Before an agent reaches production, it is replayed against the customer’s historical incident data and compared against the recorded outcome of each past event. A failed promotion rolls back in a single step.

Incident replay is a particularly important capability. Network teams accumulate years of trouble tickets, postmortems, monitoring alerts, and change records. That data is often used for reporting, but rarely for validating automation. Foundry turns historical incidents into a test suite. If an agent is supposed to detect a circuit degradation, identify the affected provider, and open the right ticket, the replay can show whether it would have done so correctly on past events. If the agent would have misdiagnosed an outage or escalated to the wrong team, the promotion fails.

This approach borrows from software testing and from chaos engineering. It gives network engineers a safe way to evaluate agents against real-world scenarios without waiting for the next production outage. It also creates a feedback loop: as more incidents are recorded, the test suite becomes richer, and teams can measure whether each new agent version improves or regresses.

Guardrails

The company describes two kinds of limits on agent behavior. The first caps cost and token usage, limiting how many model calls an agent can make before it is treated as broken. The second constrains what an agent is allowed to conclude. For example, if an agent is reporting an outage at one cloud provider, it cannot blame a different provider. It cannot hallucinate a cause that contradicts the evidence.

Cost controls are increasingly important as AI agents move from demos to production. An agent that loops through model calls while trying to diagnose a flapping link can burn through a budget quickly. By treating excessive model calls as a failure condition, Foundry forces agents to escalate or stop rather than spin. The conclusion guardrails address a subtler problem: plausible but wrong explanations. In network operations, a wrong root cause can send engineers down the wrong path for hours. Constraining the space of allowed conclusions reduces that risk.

Autonomy

The company says full automation is the goal, but it does not expect that to be the reality yet. “The goal is to be completely non-human in the loop, but I don’t think that’s going to be reality,” the CEO said. “You will get to a state where things will just happen automatically, but it will be a very asymptotic conversion.”

That asymptotic path is familiar from other areas of operations. Teams often start with AI-assisted recommendations, then move to human-approved actions, then to automatic actions for low-risk scenarios. Each stage requires evidence that the agent is reliable. Foundry’s Git-based promotion process is designed to provide that evidence. It does not require a leap of faith; it requires a series of successful replays and controlled production rollouts.

The workflows agents handle

Foundry agents are built around infrastructure support workflows. Handling one today means working through several sequential steps by hand, waiting for each one to finish, and then closing or opening a ticket depending on the outcome. That is work the company describes as manual until now.

“If something happens, you need to be able to check if the underlying provider has maintenance going on,” the CEO explained. “If it’s not maintenance, you need to be able to file a ticket for the provider.”

When a cloud outage hits, an agent first has to determine whether the problem is real—for example, whether a cloud provider is actually down or the connection itself is fine. “This ability to troubleshoot an outage and what could be done, that’s the most common workflow that we expect,” the CEO said.

When an outage happens, an agent activates on its own and issues a plan of execution, followed by periodic status updates while the outage is ongoing. That plan might include checking provider status pages, querying internal telemetry, correlating alerts across regions, and opening or updating a ticket. The agent does not simply answer a question; it runs a process. In network operations, process discipline is often more valuable than raw model intelligence.

Consider a typical multi-cloud incident. An application team reports latency. The network team sees packet loss on a connection to a public cloud region. The cloud provider’s status page may or may not show an issue. An agent can check maintenance windows, compare latency baselines, inspect border gateway protocol metrics, and determine whether the problem is inside the provider’s network, in the enterprise’s own edge, or in the path between them. If the provider is at fault, the agent can open a support ticket with the right severity and include the evidence. If the problem is internal, it can route the incident to the appropriate team. That sequence is repetitive and time-sensitive, which makes it a good fit for automation.

What’s next

The company’s own answer for what comes next centers on agent interoperability. It expects that Selector will not be the only platform agents run on, and that the industry needs standard protocols, such as MCP and A2A, before agents built on different platforms can work with each other.

Interoperability is becoming a central theme in enterprise AI. Network operations teams rarely buy a single platform for everything. They have monitoring tools, ticketing systems, configuration management databases, observability pipelines, and cloud provider consoles. Agents that can communicate across platforms could coordinate handoffs and share context. Without standard protocols, each integration becomes a custom project. MCP and A2A are early attempts to define those protocols, and their adoption will determine how quickly multi-agent workflows become practical.

The company also points to an expansion already underway into monitoring neoclouds, building on a cloud product it recently launched to compete with established observability vendors. Existing data center monitoring tooling is not sufficient as that infrastructure gets built out, and the company expects to have customer results to share within six months.

Neoclouds—specialized cloud providers focused on AI training and inference—present new monitoring challenges. They often combine dense GPU compute, high-speed interconnects, and non-traditional cooling and power designs. Traditional data center monitoring tools may not capture the relevant metrics or may not scale to the pace at which these facilities are built. If agents are going to manage network operations in these environments, they will need data models and integrations that reflect how neoclouds actually work.

Selector’s main point of difference against established rivals, according to the CEO, is that customers can build their own agents instead of working from a fixed set the vendor provides.

“We called it Foundry for a specific reason: You can create things on your own because your data is yours, your workflows are yours,” the CEO said. “We can only guess what your workflows are, what you want to be doing, and we don’t want to curtail your innovation. We don’t want to artificially bound what you want to do.”

That philosophy reflects a broader tension in enterprise software. Vendors can package best practices into prebuilt agents, which are fast to deploy but may not match an organization’s processes. Or they can provide a platform for customers to build their own agents, which offers flexibility but requires more internal expertise. Foundry is a bet that network operations teams want the latter, especially for high-stakes workflows where the cost of a wrong action is measured in downtime and customer impact.

The Git-based workflow is central to that bet. It meets engineers where they already work. It uses pull requests, code review, and version history. It treats agents as infrastructure, not as magic. And it uses incident replay to answer the question that matters most: would this agent have made the right call last time? If the answer is yes across enough historical events, the agent earns the right to act in production.

For now, the company is positioning Foundry as a way to move beyond manual playbooks without abandoning governance. The next phase will depend on how quickly standard protocols mature, how well neocloud monitoring is built out, and whether customers can generate enough clean historical data to make incident replay meaningful. The platform’s success will be measured not by how many agents a team can create, but by how many it can safely promote.

Source: Network World News

The findings arrive at a moment when enterprise networks have become too complex for many human teams to manage manually. The forces driving that complexity include cloud adoption, security integration, application performance demands, endpoint sprawl, and, notably, the rapid growth of AI itself. As organizations deploy more AI workloads, network traffic patterns are shifting, data volumes are rising, and the pace of change is accelerating.

Key Facts From the Survey

• 80% of network professionals are comfortable giving AI a high or fully autonomous role in network operations.
• 51% already use agentic AI tools in production to take corrective action in real time.
• 84% expect to reach a fully AI-led operating model within 12 months.
• 75% use AI in some fashion for network operations today.
• 56% will allow autonomous action only with human approval; 24% are comfortable with AI acting without human oversight.
• 82% are comfortable allowing AI to make some production network changes on its own for certain categories.
• 99% say they would not trust AI to act without guardrails such as explainable actions, human approval, policy-based limits, emergency overrides, role-based access control, and immutable audit trails.
• 59% change production network environments at least daily, and 57% say their change processes cannot keep up.
• 92% say performance issues cross multiple domains, including cloud, security, applications, and endpoints.
• 95% say existing non-agentic AIOps tools fall short, often because they require too much human interpretation and lack cross-domain visibility.
• The average organization generates about 4,100 monitoring alerts and events per day; 46% of alerts are closed without investigation.
• Mean time to resolve a network incident is 88 hours, while the median is 12.5 hours.
• Organizations rely on an average of 10 tools for end-to-end visibility, but those tools tend to be siloed.

Why Networks Have Become Too Complex for Humans Alone

The survey paints a picture of network operations under severe strain. More than half of respondents, 59%, report making changes to their production network environments at least daily. Half of those organizations make multiple changes per day, and for a meaningful share, change happens multiple times per hour. As a result, 57% say their change processes cannot keep up with the pace of business demands.

Complexity is also crossing traditional boundaries. Ninety-two percent of respondents say performance issues tend to span multiple domains, including cloud, security, applications, and endpoints. That means a problem that begins in one area can quickly affect others, making diagnosis and resolution far more difficult. Existing non-agentic AIOps tools are not keeping pace. Ninety-five percent of respondents say those tools fall short in significant ways, mostly by requiring too much human interpretation and by lacking cross-domain visibility.

The generative AI boom is adding fuel to the fire. Two-thirds of respondents say the rise of generative AI has increased network complexity. Traffic analysis of direct-to-AI communications suggests average daily AI traffic is on a trajectory to double every six months. That acceleration is likely driven by the growing complexity of AI tasks, which demand more data exchange than a simple query. In other words, AI is both a solution to network complexity and a cause of it.

Alert volume tells a similar story. The average organization generates around 4,100 monitoring alerts and events per day, with 51% being network-related. A typical practitioner can review, investigate, and resolve about 21 network alerts a day, according to estimates from the research firm. That means it would take a team of about 100 specialists to handle the daily volume. Since few organizations have that much staff, nearly half of alerts, 46%, are closed without investigation.

Alert fatigue is a meaningful source of employee dissatisfaction for 65% of respondents, while 67% say alert volumes prevent teams from doing other critical work. The problem is not unique to networking. Similar research around security alerts has found that well under 50% of alerts are investigated. The common thread is a growing gap between the number of issues generated by modern infrastructure and the human capacity to address them.

The Push Toward Agentic Operations

The survey describes a transition from AIOps to agent-powered operations, or AgenticOps. Traditional AIOps tools mostly analyze data and offer recommendations. Agentic AI goes further: it can take corrective action in real time. Already, 51% of respondents use agentic AI tools in production for that purpose, rather than simply taking advice from them. Eighty-four percent expect to reach a fully AI-led operating model within 12 months.

Three-quarters of the 1,000 IT and network operations leaders surveyed say they use AI in some fashion for network operations. Eighty percent are comfortable granting AI a high or fully autonomous role. More than half, 56%, will do so only with a human approving those actions. But 24% are comfortable with AI taking network actions with no human oversight. The vast majority, 82%, are comfortable allowing AI to make some production network changes on its own for some categories.

Industry analysts who follow networking trends say the move toward agentic operations is inevitable. The combination of increasing network complexity and a decreasing number of humans with the right skills to solve networking problems, including cross-domain issues, is creating pressure that manual processes cannot relieve. One analyst compared the trust curve for agentic AI to autonomous vehicles, which get into far fewer accidents than cars with human drivers. The same logic suggests AI agents will make mistakes, but fewer than people will, and they will free human teams to focus on higher-value work.

Security operations may provide a preview. Faced with too many issues to handle manually, security professionals are increasingly automating response, even when that means shutting down a resource. The thinking is that the potential losses from inaction are greater than the potential impact to the business. Network teams appear to be moving in the same direction, albeit with more caution and more requirements for oversight.

Guardrails Are Non-Negotiable

The survey was released amid calls to slow AI adoption, partly in response to incidents in which autonomous AI agents have run amok. Yet hundreds of network professionals are willing to cede at least some control of their networks to AI agents. They will do so, however, only if strict guardrails are in place. Nearly every respondent, 99%, said they would not trust AI to act without such guardrails.

The guardrails respondents identified include:

• Explainable AI actions
• Human approval for actions
• Policy-based operational limits
• Emergency override mechanisms
• Role-based access control
• Immutable audit trails

Guardrails build trust in AI by letting users see the reasoning that leads an agent to a conclusion. At the same time, while AI agents can draw conclusions from the intelligence they examine, any actions they take map to predefined workflows based on the network team's standard operating procedures for how to respond in different situations.

Another key constraint is that agentic agents do not talk to other agents. That helps a great deal because when agents are constrained to figure things out themselves, they are less dangerous. Agents are also built around specific skills or knowledge and a defined scope of responsibility. When that approach is applied on a product basis, with tight integration and controlled boundaries, it gives enterprise network operations teams the confidence to leverage agentic AI to help them manage increasing complexity.

Alert Overload, Tool Sprawl, and Slow Incident Resolution

The operational data in the survey helps explain why so many network teams are willing to experiment with autonomy. Organizations rely on an average of 10 tools to try to maintain end-to-end visibility, but those tools tend to be siloed. That makes it difficult to diagnose problems that cross domains, as many do. The result shows up in resolution times.

The mean time to resolve a network incident is 88 hours, while the median is 12.5 hours. The mean is skewed by some organizations that take a week or longer to resolve issues, reflecting the degree of complexity. That gap between mean and median suggests a long tail of especially difficult incidents that consume disproportionate time and resources. It also points to an opportunity: having AI help with analysis and automate the root cause process could reduce both the frequency and the duration of major incidents.

One practical example is when an organization tends to take the same corrective action every time a situation occurs. If a team has done it 14 times, it can automate the response, but it should still notify humans that the action was taken. That kind of targeted automation preserves human oversight while eliminating repetitive work. It also builds a record of what AI did and why, which is essential for trust and auditability.

Vendor Response: A Unified AI-Powered Control Plane

In response to these pressures, at least one major networking vendor is proposing a new cloud control platform intended to provide a unified view and management plane for networking, security, compute, observability, and collaboration solutions. The platform also applies agentic AI to diagnose and resolve issues, including those that cross domains. It is, once again, the proverbial single pane of glass, this time with an AI twist.

It may seem somewhat ironic that a vendor that sells networking gear that has become too complex to manage is now also selling the solution intended to address that complexity. Analysts acknowledge that network vendors have been complicit in creating the problem. But they also say it is good to see vendors simplify things now. The network is being used in many more ways than ever before. It is more complex for a number of reasons, including that networks support orders of magnitude more devices and connect to pretty much everything.

The road to fully AI-led operations will not be instantaneous. Even among the 84% who expect to reach a fully AI-led operating model within 12 months, most will likely proceed in stages. Human approval will remain part of the process for many organizations, especially for high-impact changes. The survey suggests that the question is not whether AI will play a larger role in network operations, but how quickly organizations can put the right controls around it. For network teams facing relentless change, rising alert volumes, and cross-domain complexity, agentic AI is increasingly seen not as a luxury but as a necessary partner.

Source: Network World News

Lenovo has expanded its enterprise infrastructure portfolio with new systems, deployment services, and pre-validated configurations. The company said the offerings are designed to help businesses modernize virtualized environments while preparing their data centers for AI workloads. The updates are intended to give customers more flexibility in modernizing existing infrastructure rather than requiring organizations to totally replace their environments.

Scott Patti, vice president of Lenovo's Infrastructure Solutions Group, said organizations are focused on modernizing virtualized infrastructure to improve efficiency and resilience while maintaining flexibility in an increasingly complex IT landscape. He said Lenovo is helping customers modernize the infrastructure they rely on today with greater choice and control, while building an AI-ready foundation that can evolve as their requirements change.

Key Facts at a Glance

• Lenovo introduced the ThinkAgile VX850 V4, a hardware platform for highly virtualized environments and demanding in-memory workloads.
• The company expanded Lenovo Express Solutions and introduced new infrastructure deployment services.
• Deployment services are now organized around three levels: Standard Deploy, Premier Deploy, and Premier Deploy Plus.
• Premier Deploy Plus includes extended post-deployment assistance and a one-year infrastructure health assessment, excluding DE Storage Array.
• Lenovo expanded its Express Solutions portfolio through its Top Choice Express program, adding pre-validated configurations.
• New and expanded solutions include Microsoft Hyper-V Ready Solutions, Windows Server, Red Hat OpenShift Virtualization, Microsoft Azure Local with ThinkAgile MX V4, Nutanix Compute Cluster, and SUSE Virtualization on ThinkSystem V4.

ThinkAgile VX850 V4 Targets Demanding Virtualized Workloads

First up, Lenovo announced the ThinkAgile VX850 V4, a new hardware platform designed for highly virtualized environments and demanding in-memory workloads. The system expands Lenovo's virtualization portfolio with infrastructure aimed at highly virtualized enterprise environments and demanding workloads. It is designed to support both structured and unstructured data and to provide a foundation for consolidating and modernizing business-critical applications.

Lenovo is positioning the platform as a way for enterprises to upgrade the infrastructure supporting current applications while creating additional capacity for AI-enabled workloads. That positioning reflects a broader reality in enterprise IT: many organizations cannot pause existing operations to build an entirely new AI stack. They need to modernize the virtualization layer that already runs their core applications and then extend it toward AI use cases.

Virtualization remains a foundational technology in modern data centers. It allows multiple workloads to share compute, storage, and networking resources, improving utilization and simplifying management. Highly virtualized environments, however, place significant demands on memory, storage throughput, and network latency. In-memory workloads such as large databases, real-time analytics, enterprise resource planning, and customer relationship management systems can be especially sensitive to performance bottlenecks. A platform like the VX850 V4 is aimed at those demanding scenarios, where consolidation and reliability matter as much as raw speed.

AI workloads add another layer of complexity. Training and inference tasks often require accelerators, high-bandwidth memory, low-latency interconnects, and fast access to large data sets. Even when AI models run elsewhere, the data preparation, orchestration, and management layers often sit on virtualized infrastructure. By adding capacity for AI-enabled workloads, Lenovo is trying to bridge the gap between traditional virtualization and newer AI requirements without forcing a complete replacement cycle.

Three Deployment Service Tiers Match Complexity and Criticality

On the services front, Lenovo is restructuring its infrastructure deployment offerings around three defined service levels: Standard Deploy, Premier Deploy, and Premier Deploy Plus. The options are designed to allow customers to select a deployment model based on multiple factors, including project complexity, business criticality, internal IT capabilities, and the amount of assistance required after deployment.

All three services provide a structured readiness foundation and expert hardware installation. Premier Deploy and Premier Deploy Plus add implementation and operational handoff support, helping customers move from infrastructure delivery toward production-ready operations. Premier Deploy Plus also provides extended post-deployment assistance and a one-year infrastructure health assessment intended to help customers identify potential problems early. The health assessment excludes DE Storage Array.

Deployment services can be an overlooked part of infrastructure modernization, but they often determine whether a project meets its timeline and performance goals. Many IT teams face skills shortages, competing priorities, and increasing pressure to support hybrid cloud and AI initiatives. A tiered services model gives organizations a way to choose the level of vendor assistance that matches their internal capabilities. For a less complex project, Standard Deploy may be sufficient. For a business-critical rollout, Premier Deploy Plus offers a more hands-on path with post-deployment review.

The one-year health assessment is notable because it shifts some attention from initial installation to ongoing operations. Infrastructure problems can emerge months after deployment as workloads change, configurations drift, or capacity thresholds are reached. A structured assessment can help teams catch issues before they become outages. The exclusion of DE Storage Array also shows that the service has defined boundaries, which is important for customers evaluating scope and cost.

Express Solutions and Top Choice Express Reduce Integration Burden

Lenovo is also expanding its Lenovo Express Solutions portfolio through its Top Choice Express program. The pre-validated configurations combine Lenovo infrastructure with software from technology partners to reduce integration complexity and simplify deployment. The expanded lineup includes Microsoft Hyper-V Ready Solutions and Windows Server, providing a validated infrastructure foundation for organizations modernizing virtualized environments.

Pre-validated configurations are designed to remove some of the guesswork from infrastructure projects. Instead of assembling hardware, software, drivers, and management tools from scratch, customers can start with a combination that has already been tested for compatibility and performance. That can shorten evaluation cycles, reduce deployment risk, and provide a more predictable path from proof of concept to production.

The expansion also reflects the changing virtualization market. Organizations are more carefully evaluating their platform choices, especially as licensing models, support costs, and product roadmaps evolve. Offering validated options across multiple software ecosystems gives customers more ways to modernize without locking into a single approach. Lenovo said the pre-validated configurations are designed to reduce the integration burden on IT departments and provide a more predictable path from evaluation to deployment.

Red Hat OpenShift Virtualization and Linux Options

For Linux users, Lenovo is offering Red Hat OpenShift Virtualization Solutions, which allow virtual machines and containerized applications to run and be managed on a unified platform. That combination is increasingly important as enterprises look to support both traditional VM-based applications and cloud-native container workloads. A unified platform can simplify operations, improve resource utilization, and give development and operations teams a common environment for managing diverse applications.

Other offerings include Microsoft Azure Local with Lenovo ThinkAgile MX V4, supporting virtualized, AI, and cloud-native workloads across distributed and hybrid environments with Azure management and operations. Azure Local extends cloud management and services to on-premises and edge locations, which can be useful for organizations that need local processing, data residency, or low-latency response. Pairing that software with ThinkAgile MX V4 hardware gives customers a validated path for hybrid deployments.

Nutanix and SUSE Round Out the Portfolio

Lenovo is also offering ThinkSystem with Nutanix Compute Cluster, which provides independent compute scaling and workload flexibility, with Nutanix Cloud Platform simplifying virtualization management in a changing landscape. Independent compute scaling can be valuable because it allows organizations to add compute capacity without necessarily adding storage capacity at the same rate. That flexibility can help control costs and match resources to workload demands.

The company also offers SUSE Virtualization on Lenovo ThinkSystem V4, supporting virtual machines and containers on a common infrastructure foundation. SUSE Virtualization is an open-source approach to hyperconverged infrastructure, and running it on ThinkSystem V4 gives customers another option for consolidating VM and container workloads. Together, the Nutanix and SUSE offerings expand the range of deployment models available to enterprises that want alternatives to traditional virtualization stacks.

Why AI Readiness Starts with Virtualization Modernization

The push toward AI has created a temptation to treat existing infrastructure as obsolete. In practice, most enterprises need a gradual transition. AI initiatives depend on data pipelines, governance, orchestration, security, and management systems that often run on virtualized infrastructure. Modernizing that foundation can make AI projects more feasible because the underlying compute, storage, and networking layers are already more resilient, scalable, and easier to manage.

AI-ready infrastructure does not always mean replacing everything with purpose-built AI systems. It can mean adding capacity where it matters, validating configurations with trusted software partners, and choosing deployment services that reduce operational risk. Lenovo's expanded portfolio follows that approach by addressing virtualization modernization and AI readiness as connected efforts rather than separate projects.

The market context makes this balancing act more urgent. Virtualization platforms have been affected by licensing changes, vendor consolidation, and shifting support models. Many organizations are reassessing their long-term platform strategies while still depending on virtualization for business-critical applications. Having pre-validated options from Microsoft, Red Hat, Nutanix, SUSE, and Azure gives customers more ways to adjust their roadmaps without disrupting current operations.

The ThinkAgile VX850 V4, the three deployment service tiers, and the expanded Express Solutions portfolio all point to a similar theme: choice and control. Enterprises can modernize at their own pace, use validated combinations to reduce integration risk, and add AI capacity as needs evolve. Lenovo said the pre-validated configurations are designed to reduce the integration burden on IT departments and provide a more predictable path from evaluation to deployment.

Source: Network World News

The company frames the update as a response to a persistent obstacle in enterprise AI: the model is rarely the main bottleneck. The data is. Many organizations have spent years making data accessible through lakes, warehouses, databases, and cloud services. But accessibility is not the same as usability. Much of the most valuable corporate information sits in files, tables, documents, and systems that were never labeled, connected, or organized with a machine reader in mind. When an AI agent tries to answer a question, it often has to burn tokens piecing together relationships that should already be known. That means more steps, more computing, higher costs, and slower, less trustworthy results.

The context problem for enterprise AI agents

Enterprise AI agents are moving from experiments to production, but their effectiveness depends on context. An agent may be able to query a database or retrieve a document, yet it may not know that a customer identifier in one system refers to the same entity as a client code in another. It may not understand that a sales figure in a report depends on a specific definition of revenue, or that a policy document has been superseded by a newer version. Without a shared semantic and relationship layer, agents can generate plausible but incorrect answers.

Dell argues that data without context is just noise. The company says most enterprises have spent years making data accessible, but that is not the same as making it usable. The new platform capabilities are meant to close that gap by providing a common vocabulary, mapping relationships, and applying governance to how agents retrieve and use information.

The Unified Semantic Layer is the first piece. It establishes a common business vocabulary across both structured and unstructured data. That means terms such as customer, product, revenue, and region can be defined consistently, regardless of where the underlying data resides. A semantic layer can help bridge the gap between technical data schemas and business meaning. Dell also plans to incorporate Nvidia's open-source Auto-Ontology technology, which can help construct knowledge graphs from enterprise data. By automating some of the ontology creation, the platform aims to reduce the manual effort that often slows down data preparation for AI.

Enterprise Knowledge Graph maps relationships

The Enterprise Knowledge Graph goes beyond vocabulary. It maps relationships between data, including metadata, lineage, query history, and other information. This allows an AI agent to identify related information across tables, data products, multimodal data, and vector indexes. For example, an agent could trace how a particular metric was calculated, which source systems contributed to it, and which documents provide supporting context. That kind of lineage and relationship mapping is important for auditability, trust, and regulatory compliance.

Knowledge graphs have become a common approach for grounding AI systems in enterprise facts. They provide a structured representation of entities and their connections, which can be used to improve retrieval-augmented generation and agent reasoning. By combining a semantic layer with a knowledge graph, Dell is trying to give agents a map of the enterprise data landscape rather than a pile of disconnected files.

Knowledge Agents apply context to business tasks

The third component, Knowledge Agents, is designed to apply that context to specific business tasks. Customers can define what information an agent can access, what rules it must follow, what quality standards it must meet, and how much compute or other resources it can consume. This governance layer is intended to keep agents within boundaries while still allowing them to work across complex data environments. Nvidia Nemotron Retriever models will provide document retrieval, reasoning, and visual understanding capabilities for the agents.

By giving agents a controlled view of enterprise data, Dell aims to make them more reliable for tasks such as customer support, financial analysis, supply chain planning, and compliance review. Instead of relying solely on a general-purpose model's internal knowledge, agents can ground their responses in curated enterprise context. That can reduce hallucinations and make outputs easier to explain.

Deployment, sovereignty, and avoiding lock-in

Dell says the new semantic layer, knowledge graph, and agents will operate within the customer's environment. That design is meant to address data sovereignty and security requirements, which are critical for organizations in regulated industries or regions with strict data residency rules. The company also says the architecture is designed to avoid locking customers into a particular AI model, data platform, or storage provider. That flexibility could be appealing as enterprises adopt multi-model and multi-cloud strategies.

In addition to the three main components, Dell is introducing enhancements to PowerScale focused on security and multitenancy. It is also adding the Dell Storage Performance Tool and AI-ready data services. These additions are part of a broader effort to make storage infrastructure more suitable for AI workloads, where large datasets must be moved, processed, and served efficiently.

Nvidia acceleration in the data pipeline

Dell is also adding Nvidia-accelerated processing to its data pipeline. The Dell Data Processing Engine is being integrated with Nvidia cuDF, while Apache Arrow is being used to improve data movement between storage and processing. Dell says internal testing showed GPU-accelerated processing on a PowerEdge R770 system with Nvidia RTX PRO 4500 Blackwell Server Edition GPUs was 3.9 times faster on average than CPU-only processing, with a peak improvement of 20.4 times on a batch data-mining workload.

Those performance gains matter because AI data preparation can be just as demanding as model training or inference. Cleaning, transforming, and enriching data at scale often requires significant compute. By accelerating those steps, Dell hopes to shorten the time from raw data to AI-ready context. The use of Apache Arrow can also reduce serialization overhead and improve interoperability between different processing engines.

Availability and market implications

Dell plans to release the Unified Semantic Layer, Enterprise Knowledge Graph, and Knowledge Agents in the first half of 2027. Data Processing Engine enhancements using Nvidia acceleration are scheduled for December 2026, with additional Apache Arrow acceleration planned for the first half of 2027. PowerScale security and multitenancy enhancements are expected in November.

The announcement reflects a broader shift in enterprise AI. Early generative AI projects often focused on model selection and prompt engineering. As organizations move to agentic systems, the focus is expanding to data architecture, governance, and context management. An agent that can access data but cannot understand it will struggle to deliver value at scale. Vendors across the data and AI stack are racing to provide semantic layers, knowledge graphs, and retrieval services that make enterprise data more useful to machines.

Dell's approach combines infrastructure, data management, and AI orchestration. By embedding semantic and graph capabilities into its AI Data Platform, the company is positioning itself as a foundation for enterprise AI factories. The strategy also leans heavily on partnerships, particularly with Nvidia, whose accelerated computing and retrieval models are integrated into the stack. For enterprises, the appeal is a more complete platform that addresses data preparation, context, governance, and deployment in one architecture.

Still, challenges remain. Building and maintaining a semantic layer and knowledge graph requires ongoing effort. Business definitions change, data sources evolve, and governance policies must be updated. Organizations will need to decide who owns the semantic model and how to keep it aligned with changing business realities. The success of Dell's platform will depend not only on technology but also on how well customers can operationalize these capabilities.

Another consideration is competition. Major cloud providers, data platform vendors, and AI startups are all investing in similar capabilities. Snowflake, Databricks, Microsoft, Google, and IBM have each introduced semantic layers, knowledge graphs, or retrieval services aimed at grounding AI in enterprise data. Dell's differentiator may be its ability to deliver the full stack, from storage and compute to data processing and AI agents, especially for customers that prefer on-premises or hybrid deployments.

Data sovereignty is another factor. Many organizations are reluctant to move sensitive data to public cloud services, particularly in Europe, Asia, and the public sector. A platform that operates within the customer's environment can address those concerns while still providing advanced AI capabilities. Dell's emphasis on avoiding lock-in also resonates with enterprises that want to avoid dependence on a single model vendor or cloud provider.

The timing of the release is notable. The first half of 2027 is still more than a year away, and the data processing enhancements are expected sooner. That staggered schedule suggests Dell is building the platform in phases, starting with accelerated data processing and storage improvements before delivering the higher-level semantic and agent capabilities. Enterprises evaluating the roadmap will need to consider how these pieces fit with their existing data architectures and AI initiatives.

For AI agents to become trusted digital coworkers, they need more than raw data access. They need to know what data means, how it relates, who can use it, and under what conditions. Dell's new platform components are an attempt to provide that missing context layer. Whether they can deliver on the promise will depend on execution, ecosystem support, and the willingness of enterprises to invest in the unglamorous work of data governance and semantic modeling.

Source: Network World News