When SpaceX on Tuesday officially announced its plan to purchase AI coding startup Cursor for $60 billion in stock, as it had predicted it would do in April, it presented CIOs and developers with a little good news, a little bad news and a massive pile of uncertainty. 

The details of the proposed acquisition were virtually identical to the terms announced in April, even retaining the $10 billion consolation prize for Cursor should SpaceX back out of the deal.  

But for CIOs and developers, the increasing probability of the deal happening is forcing them to make long-term decisions without many long-term answers about what is likely to happen to Cursor, which says its coding agents are used by 64% of Fortune 500 companies.

But whether the deal is good news for Cursor’s customers, or even those of its rivals, is an open question.

Arnal Dayaratna, research VP for software development at IDC, is firmly in the good news camp. He argued that the main element holding back the company, which he estimated brings in about $2 billion in annual revenue, was access to GPUs. And, he said, SpaceX’s xAI has the ability to resolve that problem.

It’s all about the GPUs

“The implication is that Cursor can get better because it will get better access to more compute, in the form of GPUs. That was what Cursor was struggling to obtain,” Dayaratna said, adding that Cursor joins both Anthropic and Google in aligning with xAI. 

“It is bad news for Anthropic,” he said, pointing out, “[Elon] Musk figured out that GPUs were the limiters, the bottleneck. Not human talent: compute. And it’s not only about GPUs. It’s about the data centers,” as well as the mechanisms needed to support data centers, including electricity access, cooling apparatus, and zoning rights.

“Zoning rights are very difficult to obtain in the United States, and Elon has been able to leverage his political capital” to obtain those rights, Dayaratna said.

Dayaratna also commented on the highly unusual tactic of a company pre-announcing an acquisition and then announcing it “officially” two months later. The reason, he suggested, is that Musk didn’t want the acquisition to delay the SpaceX IPO, but he did want potential investors to know about it. “It gave the IPO more legs, even though it was not formally a part of the IPO. He wanted to socialize it before it happened,” he said.

Jason Andersen, principal analyst at Moor Insights & Strategy, took a far more cautious approach and predicted, “enterprise customers will be very concerned.”

Time for CIO due diligence

“xAI’s models and treatment of guardrails are very different than what Cursor has stood for,” Andersen said, and the key issue involves model choice. “Will Cursor be able to point at models other than Grok? If that is the case, it could go towards helping customers be OK with things for a while,” he said. 

But Andersen stressed the words “for a while.” He argued that Cursor rivals have gotten more sophisticated, which could give enterprise CIOs more alternatives.

“The tooling options from the classic enterprise vendors have gotten really good, and also have a number of features that enable better governance and teaming. For example, Kiro from AWS is already a worthy competitor to Cursor, but there have also been major improvements from Google and Microsoft this year,” Andersen said. “I’d venture to say that Cursor was already facing a substantial competitive challenge in the enterprise, especially as the vibe coding movement lost some steam towards agents that enable so much more developer capability.”

Andersen added, “A lot of SpaceX’s valuation is pinned to xAI and there wasn’t enough IP there for it to be long-term competitive with Anthropic or OpenAI without rapidly injecting new technology.”

Shashi Bellamkonda, principal research director at Info-Tech Research Group, said the current period of due diligence gives CIOs opportunities to ask difficult questions.

“I do believe that enterprise customers will start to ask harder questions now, especially if more of the processing starts moving through Grok or xAI infrastructure,” Bellamkonda said, but he stressed that he does see a SpaceX deal helping Cursor.

“Cursor is already carrying a lot of LLM cost and if SpaceX and xAI can give it access to more compute and a faster, improved Grok model, customers could eventually get better performance at a lower cost. Grok is getting faster and more accurate, and under SpaceX there may be more enterprise appetite for xAI than xAI had on its own,” Bellamkonda said.

Questions about data privacy

But Bellamkonda also pointed to the trust issue, specifically asking whether Cursor would be allowed to continue its zero-data-retention policy under the new ownership.

“Enterprise users with sensitive codebases will want to understand exactly where their data is going, who has access to it, and whether any prompts, code, metadata, or embeddings are touching SpaceX or xAI systems,” Bellamkonda said. “Zero data retention is only valuable if customers believe the controls still apply across the new infrastructure. If they can preserve Cursor’s privacy posture while using xAI and SpaceX compute to improve the product, this could be a very strong outcome for customers. If the data governance is unclear, enterprise buyers will hesitate.”

Justin Greis, CEO of consulting firm Acceligence, echoed Bellamkonda’s concerns.

“For many enterprise customers, Cursor’s zero-data-retention policy was not simply a security feature. It was a foundational part of the procurement and approval process,” Greis said, pointing out that security teams, legal departments, compliance officers, and executive leadership all became more comfortable adopting AI-assisted development because they believed their source code, prompts, and proprietary intellectual property would not be retained, stored, or repurposed.

“Whenever ownership changes, customers naturally revisit those assumptions,” he said. “I would expect enterprise customers to immediately seek clarity on whether existing zero-data-retention commitments remain unchanged, whether those commitments continue to be contractually enforceable, and whether any future modifications could be introduced through changes to terms of service or product strategy.”

Reassessing platform risk

Another concern is whether the move will create greater vendor concentration, and whether that will increase risk exposure. 

“Many organizations are already concerned about becoming overly dependent on a small number of AI providers. If Cursor becomes more tightly integrated into a broader SpaceX technology ecosystem, some enterprises may worry about reduced flexibility and fewer alternatives. I suspect this will be a continued question with SpaceX’s recent IPO and growth plans,” Greis said.

Additionally, he pointed out, “AI coding platforms are rapidly becoming part of critical software delivery infrastructure. When organizations standardize on these tools, they are making a long-term platform decision that influences developer productivity, software quality, security processes, and engineering workflows. A change in ownership naturally prompts a reassessment of platform risk, roadmap alignment, and long-term strategic direction.”

As well, Sanchit Vir Gogia, chief analyst at Greyhound Research, noted, “zero data retention survives only where it stays contractual, auditable, enforceable and fenced from affiliate use. The deeper point is what Cursor has become. It is no longer a developer convenience. It sits inside the act of software creation, close to the intellectual-property bloodstream of the enterprise. That is a control plane, and control planes change hands rarely and consequentially.”

Gogia added that even before an acquisition, Cursor was already weakening its data guarantee. “Even now the promise is layered. Cursor’s own disclosures show that standard Privacy Mode still permits some code data to be stored for product features, while only the stricter legacy setting retains nothing. Zero is the exception, not the default.”

As enterprises rush to build AI agents that can reason over business data and take action, Databricks argues that the long-standing practice of separating operational and analytical data systems is turning into a liability.

That separation, the cloud-based data warehouse provider says, is becoming increasingly strained as AI agents require simultaneous access to live operational data and historical context to make decisions and take actions in real time, unlike humans, who traditionally can work with data that is minutes or hours old.

At its annual Data + AI Summit, the data warehouse provider introduced Lake Transactional and Analytical Processing (LTAP), a new architecture designed to unify transactional and analytical data on a single storage layer.

The new approach, according to Databricks, differs from traditional online transaction processing (OLTP) and online analytical processing (OLAP) architectures, which typically store operational and analytical data in separate systems.

Traditionally, OLTP databases are optimized for running day-to-day business operations such as order processing, payments, and inventory updates, while OLAP systems are designed for large-scale analytical queries and reporting.

As a result, enterprises often need to rely on ETL pipelines, data replication, and separate infrastructure to move information between the two environments.

LTAP, Databricks said, seeks to eliminate the reliance on ETL pipelines, replicated databases or separate data copies by storing data once in a shared lakehouse layer while allowing dedicated compute engines to handle transactional and analytical workloads independently.

This approach, the company argued, provides AI-driven agents and applications access to both live operational data and historical analytical context without requiring data movement or duplicate copies.

Developer simplicity in the agentic era

Analysts, too, agree with Databricks’ contention that AI agents place new demands on enterprise data architectures.

“Agents don’t behave like people, or even like the apps we built for people. They read for context, loop, try things, then write something back, thousands of times over in ways you can’t fully predict. At that volume, the constant bouncing between production and analytics systems starts becoming the bottleneck. The pressure to collapse that gap is real, and LTAP is one way to approach it,” said Michael Leone, principal analyst at Moor Insights and Strategy.

Bhupendra Chopra, cofounder and CRO at IT consulting firm Kanerika, pointed out that an autonomous agent’s data access pattern makes the traditional architectures brittle: “We’re seeing this directly with clients deploying multi-agent systems, the pipeline layer becomes the ceiling almost immediately as an agent runs hundreds of times per task.”

The analysts also pointed out that the ability to collapse the gap between OLAP and OLTP is likely to help developers design more robust AI agents or applications that enterprises are currently targeting to deploy.

“The most interesting workflow or application patterns are real-time, context-aware applications that combine transactions, analytics, and AI in one flow,” said Stephanie Walter, practice leader of AI stack at HyperFRAME Research.

“Examples include AI agents that update customer workflows while seeing historical account context and fraud systems that act on live transactions and long-term behavioral patterns,” Walter added.

Designing such applications today, however, according to Leone, would require developers to pull together data from transactional systems, data warehouses, vector databases, and other sources through custom integrations, creating significant engineering complexity and maintenance overhead.

Operational simplicity and governance gains for CIOs

For CIOs,  LTAP’s ability to reduce that engineering complexity, according to Ashish Chaturvedi, leader of executive research at HFS Research, will result in operational simplicity as well as cost savings.

“Most prominent advantage would be fewer data pipelines and everything that cascades from eliminating them. Most enterprises don’t realize how much of their data engineering budget is pure plumbing maintenance,” Chaturvedi said.

Kanerika’s Chopra pointed out that a substantial portion of data engineering capacity in mid-to-large enterprises today is consumed by maintaining synchronization between transactional and analytical systems.

The implications, however, Chaturvedi noted, are not limited to developer productivity, architectural simplicity, or cost savings: “The strategic prize is simplified governance. When you have one copy of data under one governance model instead of the same data scattered across operational stores, replicas, warehouses, and vector databases, you’ve solved the governance fragmentation problem.”

That simplification, according to Chopra, will matter operationally for enterprises deploying multiple AI agents, as these workflows can amplify governance gaps at a speed and scale that no human workflow ever did.

LTAP versus HTAP

Despite all its benefits, though, LTAP isn’t the first effort to unify operational and analytical workloads under a single architecture and for years.

The industry has pursued a similar goal through Hybrid Transactional and Analytical Processing (HTAP) architecture, which sought to combine operational and analytical workloads on tightly coupled infrastructure to serve both workload types from the same system.

LTAP, in contrast, separates storage from compute, allowing different engines to access a common data layer while remaining independently scalable, Databricks said.

That separation of compute engines is why analysts think that LTAP might be a better bet than HTAP.

“HTAP never took off because asking one tightly bound system to be great at transactions and great at analytics usually left it mediocre at both, so customers ended up paying a premium for that compromise,” Leone said.

“I think separating storage from compute is the right instinct, and it’s the same move that made the modern cloud data world work in the first place. It matters because the thing that sank HTAP was one workload starving the other, and giving each side its own dedicated engine is exactly how you keep that from happening,” Leone added.

Another reason for HTAP’s failure, according to David Menninger, executive director of software research at ISG, was its requirement for enterprises to replace existing data platforms with a new architecture.

LTAP, by contrast, builds on the now-common practice of separating compute and storage, making the addition of an operational layer less of an architectural transformation and potentially lowering the barrier to adoption, Menninger added.

Not yet the default architecture for AI agents

However, despite the enthusiasm around LTAP, analysts warned CIOs against viewing this as the inevitable successor to existing data architectures.

“CIOs will still need to choose their data architecture based on latency, reliability, ecosystem fit, cost, compliance, and developer experience,” Walter said.

Echoing Walter, Chaturvedi pointed out that for LTAP to become the de facto standard for the industry, Databricks will need more than architectural elegance: “The architecture looks sound on paper. The proof will be in the commit-to-query latency numbers under real load.”

LTAP, Databricks said, is expected to be released soon as part of Lakebase, without providing any specific timelines.

Developers are caught between the joy — or pressure — of using agents to ship 10x faster today and the dread of how they will maintain that code tomorrow. The gap between “vibe” code and code that can be deployed to millions of users is vast and easy to underestimate. Closing the gap requires care, expertise, and effort, with the payoff coming later. Agents are able to complete increasingly complex programming tasks but without the quality we need. What’s missing, and how can we fill the gap?

Why agent-generated code degrades: the bloat problem

Enterprise code has to clear three bars: it must be maintainable, reliable, and secure. Out-of-the-box AI agents can miss all three. Let’s focus on the biggest and most visible maintainability issue, which is bloat: redundant validation, defensive checks that cannot fire, near-duplicate functions, dead code that nothing removes. A None check on a parameter typed as dict. A try/except around a call that never throws. Two functions, identical except for the negation in their return statement.

Bloat varies dramatically by model. Sonar’s LLM Leaderboard runs every frontier model through 4,400+ Java tasks and analyses the code generated. To complete the benchmark, GPT-5.4 High generated 1,159,000 lines of code at an 81.05% pass rate, while Claude Opus 4.7 Thinking generated only 336,000 lines of code to return a better than 82.52% pass rate. Different models generate dramatically different code to achieve similar outcomes.

Bloat is not just messy. Carnegie Mellon researchers studied 807 open-source projects that had adopted Cursor, matched against 1,380 controls, measured by SonarQube. A short-term velocity gain disappeared by month three, while static analysis warnings rose 30% and code complexity rose 41% — both persistent. The harder it became to change the codebase and the more bugs it contained, the more the velocity was dragged down. Any experienced developer will know how this goes: quality problems compound until the code feels impossible to change and the only option is the dreaded rewrite.

Three forces produce bloat once a model is in use:

1. Agents do not feel the maintenance burden. Armin Ronacher, the creator of Flask, made the point on the Pragmatic Engineer podcast in late April. Humans feel the cost of bad code over time, and as Ronacher put it, “if the pain gets too big, you as a human are incentivized to fix the cause of your pain” — so we refactor. Agents do not. They obliviously extend bad structure indefinitely. A senior engineer’s job is to say no to unnecessary abstraction. The agent has no equivalent reflex.
2. Training rewards apparent completeness. Pretraining corpora are full of explanatory material — Stack Overflow answers, tutorials, README snippets — deliberately self-contained and verbose. Post-training compounds the effect: human raters prefer outputs that look thorough, so models learn that “comprehensive” reads as better. When uncertain which edge case matters, the safe move is to handle all of them. Each guard is locally defensible. The aggregate is bloat.
3. Iterative generation has no deletion pressure. Agents add but rarely delete. Removing dead code does not make any test go green, so superseded functions accumulate alongside their replacements. SlopCodeBench, a March 2026 benchmark across 11 coding models, found rising structural complexity in 80% of trajectories and rising verbosity in 89.8%. Agents continue to patch bad code, treating every task as if it’s their last.

AC/DC: the loop that compensates

What closes the gap is a loop around each iteration of agent work. The agent does what it is good at — generating code — and our job is to wrap that with three steps the agent cannot reliably do on its own. At Sonar we call this the Agent Centric Development Cycle, or AC/DC: guide, verify, solve.

Guide

Many teams overcorrect on context. They paste the style guide, three years of architectural decisions, and the entire onboarding doc into the agent’s instructions and expect output to improve. ETH Zurich researchers tested this and found the opposite: large context files often reduced task success against no context at all, and added 20% or more to inference cost.

Keep agent-facing context short — under 200 lines is a useful heuristic — and restrict it to fundamentals that can’t easily be inferred from the code: naming conventions, architectural invariants, what has been tried and failed. However, this will only get you so far, so make sure to provide specific context for each task. If you have architectural expectations, don’t expect the agent to guess them. Software architecture tools can be used to provide additional context in the guide phase.

Task shape matters too. Break the work into steps and agree on a plan; ask the agent to provide three solutions and evaluate the impact on quality of each. There is no perfect software architecture, and you understand the trade-offs in your codebase best, so think critically about the changes before they happen. Without this, the agent will confidently pick an option, seemingly at random, and the further it goes the harder it is to “unpick.” If you want to test this, ask three instances of your preferred agent to complete a task that involves some polymorphism and watch each one confidently suggest a different solution.

Verify

The most expensive verification mistake is doing it last. Reviewing 200-line pull requests (PRs) after the agent is done is the dynamic behind the Faros/DORA figures Addy Osmani highlighted: 98% more PRs merged in high-adoption teams, review times up 91%. Verification inside the loop is different. Unit test runs, static analysis, and security scanners produce output the agent can act on. This is where AI-native tooling belongs: purpose-built for the agent to invoke, not just for humans to consult through a UI.

Human reviewers cannot keep up. When agents merge twice as many PRs per week and each one takes nearly twice as long to review, doubling the review staff still leaves you behind. Automated verification is the only response that scales. Fast feedback has always been a fundamental tenet of good software engineering. Feeding it directly back to the agent protects the developer from simple mistakes and leaves them headroom to work on the harder ones.

Solve

If verification happens within the agentic loop, the agent can fix any issues whilst the code is being generated without expensive remediation steps. Static analysis tools can guide the agent on how to resolve the issue quickly. Some cases need human judgment — a None check at a system boundary may document a real precondition. But most of the work is mechanical. Automate the obvious fixes and let engineers spend their attention on the cases that are not.

The investment that compounds

Better models will keep arriving. They may not change the mechanism of bloat or the dynamics of compounding decay. The loop is what does — bounded tasks, sharp context, in-loop verification, and a deliberate “solve” step to clear bloat before it accumulates.

The same logic governs how autonomy should expand. Reduce human interventions only when the agent’s guide, verify, and solve cycle is making them redundant. Our biases can sting us here: an agent’s ability to write code can lead us to agree with it more than we should. Don’t trust blindly; wait for the evidence.

The teams that will be shipping enterprise-quality code with AI agents in 18 months are not the ones running the “best model.” They are the ones treating workflow as the engineering investment, with the seriousness once given to build systems and CI. The model is the tool, the workflow is the discipline. That is where the durable advantage compounds.

—

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

Every organization has data scattered across data warehouses, data lakes, SaaS platforms, cloud drives, and data centers. Data fabrics enable organizations to centralize and control data access, making it easier for users, such as data scientists and citizen data analysts, to find and use trusted and governed data sources. 

Data fabrics, data meshes, and distributed data clouds are all platforms to help IT and data teams put some order to the chaos around the myriad of data sources they support. Large companies need data fabrics due to the volume and variety of their data sources.

“A data fabric can be thought of as the connective tissue that ensures consistent accessibility, availability, and understanding of data across an organization,” says Dominic Wellington, data and AI expert at SnapLogic. “Individual siloed platforms may have their own internal data transfer systems, and particular teams or departments may adopt interchanges that work for that domain, but a data fabric operates at a higher level, ensuring that unified data policies are applied end-to-end across the entire enterprise.”

Types of data fabrics

When reviewing data fabrics, it’s important to consider their primary use cases, supported data types, data processing capabilities, data management structures, and governance functions. Below are some considerations when reviewing data fabrics as features, platforms, and stand-alone products.

• Some data fabrics are optimized for analytics and machine learning use cases and may have limited support for unstructured data.
• Other data fabrics extend the functionality of data governance platforms beyond data cataloging and metadata management and now include persistent data management, data quality, and dataops capabilities.
• Many data integration and API connectivity platforms go beyond proxying, pipelining, and transforming data to include search, governance, and other capabilities from data centralization.
• Some SaaS platforms are extending their connectivity and data integration capabilities, enabling multicloud portability and persistent data.
• The more advanced data fabrics support features needed for AI agents and AI model training. These platforms create a semantic context layer for structured and unstructured data sources, support Model Context Protocol (MCP) integrations, have real-time query capabilities, centralize policy-driven governance, and track data lineage.    

Why data fabrics are needed for AI

Data fabrics are not just for enterprises, and today, even smaller companies need them as part of their AI democratization programs. Here are a few reasons why:

• AI agents in enterprise SaaS solutions need access to broader data sets than those core to their workflows. Platforms such as Adobe, Appian, Oracle, Salesforce, ServiceNow, SAP, and Workday offer data fabric capabilities to bring data outside of the business processes they manage into scope for their AI agents.
• Unstructured data is important for setting the context for AI agents, and data fabrics are now used to provide access to documents, emails, transcripts, and other media formats.
• Data fabrics provide data access standards for the devops teams experimenting with AI code generators, vibe coding tools, and spec-driven development approaches to develop applications and AI agents. 
• As companies use MCP servers to connect AI agents, data fabrics provide a standardized way for the agents to access governed, trusted data sources.

“As AI agents move from generating insights to taking action, the data fabric becomes foundational in the agentic era,” says Irfan Kahn, president and chief product officer of SAP Data & Analytics. “Most enterprises operate across scattered data sources and diverse data landscapes, and what’s needed is shared business context, governed access, and clear accountability for how data is used in decision-making. Without that context, agents can’t fully understand or coordinate across the enterprise to deliver meaningful value.”

Sanjay Koppikar, chief product officer and cofounder of EvoluteIQ, adds, “Multi-agent architectures become untrustworthy when a unifying data fabric architecture is missing, since agents will often work against each other in the service of their own objectives.”

Delivering context to AI agents

AI agents need a combination of real-time data, user information, problem details, and historical context to guide their decision-making. Vishal Sood, president of research and development at Typeface, says, “MCP and data fabrics give agents access, but the harder problem is contextualizing data across multiple sources and ensuring the underlying content, media, and unstructured data are trustworthy.”

Data fabrics are the foundational elements for providing current information and long-term memory to AI agents. They simplify the many-to-many problem of connecting multiple AI models, AI agents, and MCP server integrations to multiple structured and unstructured data sources.

“The data fabric does a beautiful job of encompassing three concepts needed to create applications and processes: the data catalog, the data model, and data access,” says Sanat Joshi, executive vice president of product and innovations at Appian. “But now add business rules, process models, APIs, security groups, the organizational model, and their interrelationships into one unified view of the enterprise, and that becomes your context layer.” 

Integrations with data fabrics

Devops teams just getting started on an AI agent proof of concept may want to connect directly to the optimal data sources and APIs. Michel Tricot, CEO and cofounder at Airbyte, says connecting agents to live APIs is a great start, but it creates two big problems: APIs only return data that an agent already knows to ask for, and every query is an expensive API call chain that, with overhead, can overwhelm infrastructure in production volumes.

Tricot says the data fabric for AI use cases must be dynamic, leveraging discovery of available information from replicated data, fetching live contextual information, and writing the data back to business applications to update records.

Moving data in and out of the data fabric requires an integration strategy. Zero-ETL (extract, transform, load) is one low-cost, efficient approach for connecting to structured data sourced without replicating information. Once information is accessed centrally, it also enables streamlined security and governance.

“The promise of AI agents breaks down when they’re stuck waiting on brittle ETL, dealing with poor data quality, and lacking the right context to perform analysis,” says Preston Wood, chief security and strategy officer at Databahn. “Generating AI-ready data within a data fabric gives agents real-time access to operational data without the latency and drift that undermine decision quality. A well-architected data fabric provides the governance and lineage controls that let you deploy agents confidently, knowing exactly what data they’re touching and why.”

Centralizing AI-ready data

Data fabrics centralize AI-ready data and help data governance teams address data quality issues, biased data concerns, privacy compliance, and other data governance non-negotiables. Data fabrics also help address integration issues, monitor for data pipeline errors, and report on performance latencies. The result is that AI agents, models, and other analytics capabilities can then connect to trusted data sources with consistency.

“As AI agents and MCP architectures increasingly rely on data fabrics as their golden source of truth, data quality stops being a hygiene problem and becomes a trust problem, as we all know that trust is foundational to autonomous decision-making,” says Kellyn Gorman, database and AI advocate and engineer at Redgate Software. “Organizations that invest now in semantic consistency, lineage tracking, and observable data contracts across data fabrics will be the ones whose AI agents can be trusted to act without constant human correction.”

Data fabrics that support zero-ETL and other bidirectional integrations with sources thus become an organizational knowledge base, the data source for training AI models, and a foundation for producing data metrics.

“AI agents are only as reliable as the data they’re built on, and most organizations underestimate how much implicit tribal knowledge lives in their transformation logic rather than their source systems,” says Tobias Ostwald, director of analytics at NMI. “If you’re exposing a data fabric to agents or MCP integrations, you need lineage, testing, and metric definitions baked into the layer itself, not just documented somewhere, because the agent can’t call a colleague to gut-check a number.”

Streamlining security and governance

With a data fabric in place, governance, security, and other risk management leaders have a central location to manage data security, centralize access controls, and fulfill other governance responsibilities. Miles Ward, CTO of AI in Solution Lines at Insight, says, “We have to move past security by isolation to a governance model where the fabric itself enforces the pavement and walls of compliance.”

The data fabric also governs entitlements for AI agents and their users. Centralizing these business rules can help organizations avoid creating AI debt, a risk if controls are implemented directly in data sources or consumers.

“The convergence of AI-generated code sprawl and autonomous MCP connectivity creates a ‘perfect storm’ of architectural drift and toxic permission combinations,” says Karen Cohen, vice president of product at Apiiro. “Effective governance requires a security data fabric that monitors these autonomous connections in real time to enforce intent-based policies and strictly limit agent scope to its specific purpose. By integrating guardrails that align AI-assisted development with secure architecture principles, enterprises can proactively secure their expanding attack surface without sacrificing developer velocity.”

Future considerations for data fabrics

Expect vendors to expand the scope of their data fabrics beyond text and documents. Some will include specialized document processing for common formats such as invoices, contracts, and product documentation. There will be skills and tools to support industry-specific documents such as health records and construction documents. Others will support multimedia file types and provide metadata extraction and search capabilities. 

“Enterprises are asking agents to reason across contracts, images, PDFs, and video, and this is where most data fabrics break,” says Dave Shuman, chief data officer at Precisely. “Multimodal data must be chunked, embedded, and governed with the same rigor as structured data, including lineage and access controls.”

Several other emerging capabilities include:

• Extended support for AI agent interfaces to aid in data discovery, and with greater contextual controls on where and when AI agents can access sensitive data
• Business ontologies, semantic layers, and knowledge graph capabilities, with management tools or integrations with third-party platforms
• Support for data contracts, service-level agreements, centralized data observability, auditing, and other functions that will enhance explainable AI capabilities
• Finops functions to track costs for data owners and consumers

As more companies depend on AI agents in their operations, expect top data fabric platforms to release capabilities to expand scope, scale, use cases, and governance.  

Nvidia’s new RTX Spark is one of the most interesting personal computing announcements in years. That’s because it’s not just another PC platform, but tries to redefine the role of the personal computer in the age of AI. Announced at Computex 2026, RTX Spark is Nvidia’s new platform for slim Windows laptops and compact desktops, designed to combine an Arm-based CPU, Blackwell-based RTX graphics, and a large, unified memory architecture into a single AI-first computing system.

We have all grown accustomed to a cloud-centric AI model over the past few years. We open an application, send a request over the network, and a hosted service in a distant data center provides the intelligence. ChatGPT, Grok, Gemini, and similar systems have trained the market to think of AI as something that lives elsewhere. RTX Spark proposes a different model. It asks a simple yet disruptive question: What if the model, the agent, the data, and the application could all live on your own machine? Nvidia is not just selling a faster PC. It is selling a new architectural premise.

Features, functions, and prices

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 for the platform 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.

The unified memory approach is especially important. In traditional PC architecture, the CPU and GPU often use separate memory pools, which can become a bottleneck when running large models. By contrast, RTX Spark’s design is intended to make it easier for the system to host and run AI models locally. This enables Nvidia to position the machine as capable of hosting persistent AI agents, supporting local inference, and even allowing users to customize or fine-tune certain classes of language models.

Nvidia is also careful not to frame the system as only an AI box. In a smart move, the company is marketing RTX Spark for gaming, creative applications, AI development, and agentic workflows. This has been designed not as a one-trick pony, but as a capable computer first and an AI workstation second. Otherwise, it remains a niche developer experiment.

Pricing remains uncertain because Nvidia hasn’t 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. The best indicator comes from the related DGX Spark desktop, listed at about $4,699, though early estimates placed it between $2,999 and $3,999.

That probably gives us the right way to think about pricing for this 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, that may broaden. For now, however, this looks like a new high-value, high-cost category rather than a commodity PC refresh.

What is its 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 of us 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, you may be able to create your own model-based assistant that runs directly on the RTX Spark. It will not be as broadly capable as a frontier model operated by OpenAI or another hyperscaler. It is likely to be less generally capable, narrower in its expertise, and more constrained by local hardware limits. But it will be yours, it will be local, and it will respond 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 us 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.

Welcome to the revolution

The breakthrough here is not that local models will instantly outperform remote models. They will not. But the architecture of AI use may begin to diversify. Today, the default assumption is centralization. We assume the model, the knowledge base, and the application stack will all 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. Yes, 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

I see the strongest potential use cases in disconnected or semi-disconnected environments. Think about physicians doing diagnostics 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.

The bigger question is whether mainstream enterprise AI will migrate in that direction. I remain skeptical that most organizations want hundreds or thousands of individually tuned, locally hosted models to replace centralized AI services. I predict that this category will complement the cloud rather than displace it. The more likely future is hybrid: centralized AI where shared knowledge and governance matter, and local AI where privacy, portability, latency, or disconnected operations matter more.

AIs struggle to understand documents designed for humans; the DocLang working group seeks to flip that imbalance with its specification for machine-readable business documents “built from the ground up for LLM tokenizers.”

The working group, founded by IBM, Nvidia, and Red Hat and hosted by the Linux Foundation’s LF AI & Data project, aims to create an open, universal, AI-native document format designed to improve how enterprises prepare, exchange, and govern document data for AI systems. ABBYY and Human Signal will also be involved in its development, and other contributors are welcome.

“Enterprises today work across a fragmented landscape of document formats, including PDFs, JPEGs, and other file types built primarily for human consumption rather than AI interpretation,” the group said in its launch announcement.

“This disconnect can introduce complexity, raise costs, and reduce reliability when extracting meaning from business documents,” as organizations increasingly rely on generative AI and agentic systems, it said.

Mark Collier, executive director of LF AI & Data, said the goal of the DocLang Specification Working Group is to “develop a vendor-neutral, interoperable standard that helps organizations prepare document data for AI more reliably, transparently, and at scale.”

DocLang defines a structured, machine-readable format for documents of any type, like JSON for data, that any tool can implement and any pipeline can consume. It builds on DocLing, a document processing toolkit hosted by LF AI & Data that can transform human-readable PDFs, word processor documents or spreadsheets into structured data.

Standards must evolve for AI

Something like DocLang is needed, said independent technology analyst Carmi Levy. “Existing document standards have done an admirable job allowing global stakeholders to confidently collaborate for decades, but it’s becoming increasingly clear that they are in desperate need of an update as AI reshapes the rules around how work gets done,” he explained.

Largely static document types, he said, “can be somewhat limiting when AI is redefining the very word, ‘document.’ In many ways. AI-age documents are far more iterative and dynamic than what they once were, and the definitions need to evolve with the times. The documents we currently live with simply weren’t designed for the AI age.”

Within that context, Levy said, “DocLang represents an early, best hope of achieving some kind of foundational baseline for document standards, one that will hopefully allow more intelligent, more efficient, lower-risk workflows than is currently the case.”

Taking an open-source, vendor-agnostic approach to the process ensures the collective will take precedence over the needs of specific vendors, he said, adding, “earlier standards-setting efforts around networking, documentation, the web, and the cloud powered the free-flowing digital landscape that defines modern life.”

An AI-centric documentation standard will carry that reality into the next generation of technology, said Levy.

A question of governance

The entire concept of LLMs, Jason Andersen, principal analyst at Moor Insights & Strategy said, “involves using natural human languages. The computer is supposed to understand us without us changing our syntax or language. Forcing a syntax on users is exactly what we have today with SEO and more advanced programming languages.”

With something like DocLang, where the standard can be applied to content ingestion, he said, “I would be OK with that being automated, which seems to be the intent. The use case I envision is that when I upload a document to an agent, a skill can be run to preprocess the document into the DocLang standard format, saving tokens.”

That makes sense, he said, adding that he thinks it’s good “if it can help generate outputs, like a visualization, that can be shared outside an AI tool. On that front, that is also why I am liking Web MCP, since you are just adding some code to the page, like CSS or JavaScript, and the consumer, in this case, an AI browser or skill, is better equipped to handle the site.”

The point, he said, is, “these standards need to preserve the fact that humans can still do what they want, and do not need to know any coding to be proficient. In terms of governance, I am not sure if it matters.”

But one analyst did foresee governance problems arising from DocLang’s use.

Yaz Palanichamy, senior research analyst at Info-Tech Research Group, said DocLang adoption will require organizations to implement and review controls in order to scale its use accountably and securely.

This article first appeared on CIO, on June 10, 2026.