MUNICH — Nextcloud has integrated Euro-Office into its workplace application suite, one of several updates to Nextcloud Hub unveiled on Tuesday that include a new compliance app for large organizations and a program to support developers building for its platform.

The announcements came during the company’s Nextcloud Summit 2026 here.

Euro-Office, announced in March, is billed as an open source, sovereign alternative to Microsoft Office for European organizations keen to reduce their reliance on US tech providers. It consists of four browser-based applications: a document editor, spreadsheet program, presentation tool, and a PDF editor — each enabling collaborative editing. Euro-Office documents can also be opened directly from the Nextcloud Files mobile app.

Nextcloud is one of several European companies that support Euro-Office, which is built on the open-source code base of OnlyOffice and distributed under the GNU Affero General Public License v3 (AGPL v3).

The integraton means Nextcloud users can now choose between two options in Nextcloud Office: Euro-Office and the existing Collabora integration. 

“Euro-Office uses a different architectural approach that can result in a better performance in the browser, a different user experience…, so it’s important that this option is available,” Jos Poortvliet, Nextcloud co-founder and vice president of communications, said at the Tuesday event.

Other changes in the Nextcloud Hub 26 Spring release include updates to Nextcloud‘s Talk video and voice meeting app, including AI noise suppression and the ability to start a call from any Nextcloud Hub app – an addition that will make collaborative editing easier, said Poortvliet. 

For Nextcloud Assistant, there are new AI agent capabilities. In addition to existing capabilities such as managing calendars and tasks, AI agents can now create cards in Nextcloud’s Deck task management app and update information in the Forms app.

There are also improvements to the AI assistant’s interface, which can be moved around to avoid blocking other applications and allow users to copy and paste text more easily without opening another tab. To meet EU AI Act requirements, Nextcloud will make it easier to see which  provider supplies the large language model (LLM) the Assistant runs on.

Nextcloud will also integrate the AI assistant directly into its Nextcloud Office suites via a sidebar chat interface, allowing users to address problems such as errors in the spreadsheet app.

There’s also a new Governance app that helps large organizations — particularly governments and highly regulated industries — meet regulatory requirements with compliance tools to manage data held in Nextcloud Hub. It contains several features,  including sensitivity labels to control access rights; data retention and archive capabilities; and a legal hold option that preserves documents for legal purposes such as a court case.

The Governance app includes a Compliance Manager that provides a compliance score based on an organization’s regulatory requirements, and measures progress towards certain targets. Admins can also search and review documents shared by employees and generate audit reports for compliance. The Governance app is available to Nextcloud Enterprise customers.

Nextcloud also launched a program to support independent software providers interested in building apps on its platform. 

With AI making it easier for developers to build software that integrates with its platform, Nextcloud expects a 10-fold increase in the number of available apps — from 600 now to 6,000 over the next 12 months, according to Nextcloud CEO Frank Karlitschek.

Nextcloud promised to promote apps developed by partners in its App Store and sell subscriptions as part of the ISV program, as well as provide documentation and technical help to customers. In return, developers would provide guarantees to customers around security processes and long-term support.

“We can strengthen our ecosystem, the developers also make some money — because obviously we do a revenue share here — and we leverage the dynamics that we expect from AI coming very soon,” said Karlitschek.

Editor’s note: NextCloud paid for Matthew Finnegan’s travel and hotel costs for NextCloud Summit 2026, but had no editorial role in the creation of this story.

WWDC26 felt like a defining platform moment. Apple is no longer simply promising that AI will arrive eventually; it is arguing that Apple Intelligence and Siri AI should become central to the future of its ecosystem. If that works, the company will have turned AI from a perceived weakness into a new reason to stay inside Apple’s world.

Still, the bigger question is execution. Apple did not present AI as a lab experiment; it presented a polished, consumer-ready experience. That raises expectations. 

Apple must deliver this time

Users will not judge Apple Intelligence by model architecture or parameter counts. They will judge it by whether Siri understands them, whether actions work reliably, whether personal context feels useful rather than intrusive, and whether the experience is consistent across devices.

Since Monday’s announcements, we’ve learned that some features will not work on all devices — and there’s speculation Siri AI may not fully escape beta until 2027. “Until Apple puts a stake in the ground and says when the new Siri features will be available, the debate remains: Does Apple actually have the chops in personalized AI? The demo suggests yes. The lack of timing suggests maybe,” wrote analyst Gene Munster.

Optimists argue that Apple has regained momentum by presenting a coherent AI story, one built around privacy, integration and everyday utility rather than spectacle. Skeptics counter that many of the features resemble capabilities already available elsewhere, and say the company still needs to prove it can ship them at scale and make them a meaningful reason for consumers to upgrade.

What the analysts say

That balance is visible in analyst reaction. In a client note seen by Computerworld, Erik Woodring of Morgan Stanley described the keynote as clear progress on Apple’s AI roadmap and said it suggested monetization opportunities could arrive earlier than expected — even if the overall journey will be “a marathon, not a sprint.”

UBS, in contrast, said the privacy-focused AI additions are useful but unlikely to be a material driver of iPhone demand in the near term, while Barclays called the changes interesting but incremental, and not enough to drive an upgrade cycle.

Ben Wood, chief analyst at CCS Insight, argued that Apple had to answer concerns about its AI shortcomings and now has to prove that its privacy-led, integration-first approach translates into a meaningfully better everyday experience. “Consumers will not judge Apple Intelligence by model sizes, partnerships or technical architecture,” Wood told me. “They will judge it by whether Siri understands them, whether actions work, whether personal context feels useful rather than intrusive, and whether the experience is consistent across devices.”

Dipanjan Chatterjee, vice president principal analyst at Forrester, said Apple’s strength lies in shifting the focus from the underlying technology to outcomes such as usefulness, simplicity and trust, while warning that the company still has skeptics to win over after its stop-start AI rollout. “The lesson for brands is clear: market the value, not the ingredients,” said Chatterjee. “After stumbling with the Apple Intelligence roll-out, Apple’s success will hinge on delivering the new Siri experience quickly, and ensuring it works as promised for iPhone users at scale.”

What about Apple developers?

While many are infuriated about Europe’s inability to build compromise, Apple’s developer army otherwise seems positive about what the company has accomplished. 

“On the AI front, it never made sense to me for Apple to develop their own LLM, so focusing on powerful, fast and private for implementation of Apple Intelligence seems to be an effort that is progressing rather nicely.  In all, a pretty good Keynote, I’d say,” Rich Siegel, founder and CEO of Bare Bones Software, said in an interview.

“It’s great to see Apple continue to pursue a vision of AI that leverages local systems, preserves privacy, and integrates with third party tools,” said Ken Case, CEO of the Omni Group. “A lot of our work around the Apple Foundation Models and automation, App Intents, and adopting Swift look to be fruitful investments, but it’s clear there’s more to do starting this summer. It’s also welcome to see them refine Liquid Glass, giving customers more control and listening to feedback they’ve heard over the past year.”

“I expected that this year’s Siri revamp would be the biggest personal assistant update Apple has ever done, and that’s exactly what we got,” said Sergii Kryvoblotskyi, director of AI and research at MacPaw. “Since Apple acquired Siri back in 2010, it has lacked one thing: real intelligence. Behind the great speech recognition service it provided, the tech was not ready to provide real value to users.”

“Most notable for me was Siri AI and the push towards on-device and more capable models that can do more with user context,” Matt Vlasach, Jamf senior vice president, enterprise products and solutions engineering,” said in an interview. “While obvious for consumer use cases, as illustrated in the keynote, the opportunity to evolve this to the work context using a more advanced Apple Intelligence framework is an exciting evolution.”

“OS 27 feels like a deliberate reset, less about new features and more about polish and quality-of-life improvements, which most users will welcome,” said John Richards, general manager, IT products, at Iru. “The new capabilities are focused entirely on Apple Intelligence and Siri AI, and what’s encouraging is how much Apple leaned into privacy with the Gemini partnership. That combination of capability and privacy-first design is the right instinct.”

“The single biggest request I made at Apple’s Foundation Models workshop in Madrid was opening Private Cloud Compute to third-party developers,” said Serhii Popov, senior software Eengineer at CleanMyMac. “It’s here and free for apps under 2 million users. That’s a real breakthrough and a huge opportunity for a lot of great apps.”

How will integrated AI change things?

Joel Rennich, senior vice president for product management at JumpCloud, looked ay how on-device AI will transform other paradigms. For starters, it shifts identity from simple authentication to governing what actions an AI agent is allowed to take.v“Enterprises will need identity frameworks that govern both human and non-human actors consistently,” he said.

“iOS 27 and Apple Intelligence point toward an operating system that does not just launch apps, it executes intent,” Rennich said. “Instead of users navigating between tools, the OS increasingly mediates outcomes directly through AI. This changes how work is initiated and completed on devices.

“With Apple Intelligence integrated across core experiences like Siri, Safari, and system services, AI is no longer an overlay but infrastructure. The separation between where data lives and where it is used becomes increasingly invisible to the user. Intent becomes the primary input, not app selection.”

I also spoke with Hexnode CEO Apu Pavithran, who pointed to some of the concerns enterprise users might have following WWDC: “The keynote didn’t speak much to admins,” he said. “The features that matter most at the management layer, such as how Apple exposes Siri AI through MDM APIs, whether IT gets granular per-app controls for Apple Intelligence, how shared device deployments handle the new assistant — these will be answered in the developer documentation. This week, that’s where IT teams should be looking.”

“Admins should dig in immediately and see what’s changed. Watch the developer docs, audit how Apple Intelligence interacts with existing device policies, and remember that the keynote is only a part of the story for enterprises,” he said.

Making AI great again

“Rebuilt from the ground up, Apple is trying to make AI feel native, useful and invisible across the devices people already use every day,” Francisco Jeronimo, vice president for client devices at IDC, said in an interview. “This matters, because the winning AI experience for consumers will not be the loudest or most technically complex. It will be the one that understands context, respects privacy, works reliably across apps, and reduces friction without forcing users to change behavior.”

“[Apple] is also clearly seeking to differentiate through its privacy promises,” said CCS Insight’s Wood. “This looks like a step in the right direction, but there is no room for complacency, and Apple still has a long AI journey ahead.”

Pavithran reflected on something more. “Overall, it’s hard not to think of this year as a deliberately measured keynote, one that’s intentionally playing it safe and seeking to rewrite the AI narrative,” he said. “I won’t be surprised if this ends up setting the stage for a much bigger installment next year with incoming CEO John Ternus hitting the ground running with some ‘wow’ features like new hardware or agentic AI at scale.”

That we can now seriously consider that possibility shows the extent to which Apple has regained momentum in AI on its platforms.

You can follow me on social media! Join me on BlueSky,  LinkedIn, Mastodon and The Core.

Enterprises are moving aggressively into generative AI. On the surface, that seems like the right call. The technology is powerful, accessible, and increasingly embedded in how businesses build applications, automate processes, and support decision-making. A development team can connect an application to a large language model in days. A product team can add AI features in weeks. Business leaders see quick wins, faster innovation, and a path to modernizing nearly every part of the company.

These are the upsides everyone is talking about. The part we don’t discuss enough is the economic trap forming underneath all this convenience.

Most enterprises think of tokens as a technical billing detail. They are not. Tokens are the unit of economic dependency in generative AI. Every prompt, response, summarization, retrieval step, workflow action, and agent decision is measured and monetized through tokens. Tokens are not just part of the plumbing. They are the tollbooth between your enterprise and a provider’s intelligence platform. The more AI becomes central to your operations, the more power that tollbooth holds over your future costs.

Tokens are not just a pricing unit

A token is usually described as a chunk of text processed by a model. That is accurate enough for developers, but it misses the bigger issue for CIOs, architects, and corporate boards. In the enterprise, tokens are the mechanism by which AI capabilities are rented. They are the meter attached to the intelligence itself.

That distinction matters because token usage grows faster than most companies anticipate. A simple user prompt rarely remains simple in production systems. It can trigger retrieval from internal knowledge stores, multiple model calls, tool use, post-processing, policy checks, and agent loops. What appears to be a single transaction to the user may involve several layers of token consumption behind the scenes. As a result, enterprises often underestimate the true operating cost of AI-enabled systems, especially as those systems mature and spread across departments.

Today, those costs still feel manageable. In many cases, they feel surprisingly low. That is exactly why the trap is so dangerous.

The market is in a subsidy phase

Current token pricing is giving enterprises a false sense of comfort. Many remote LLM providers are aggressively competing for market share. They want developers building on their APIs. They want enterprise applications tightly coupled to their platforms. They want AI agents, copilots, workflows, and customer experiences to depend on their models. To make that happen, pricing remains highly attractive relative to the value delivered.

That does not mean the economics of generative AI are stable. It means the market is still being shaped by investor capital, strategic pricing, and growth expectations. Providers are racing to establish position, and enterprises are benefiting from that race. But no market stays in that phase forever. At some point, investors will expect durable profitability. At some point, weaker providers will disappear, consolidate, or retreat. At some point, the survivors will have more leverage and much less reason to price primarily for adoption.

That’s when the token trap closes.

Enterprises that build deep dependence on remote models during the subsidy phase may find that what seemed inexpensive at pilot scale becomes punishing at enterprise scale. The application that costs $1,000 per month today may cost 10 or 20 times that amount a few years from now, not only because usage has increased, but also because the market has repriced the dependency.

Easy to adopt, expensive to exit

Cloud computing followed a similar path, with many enterprises mistaking short-term convenience for long-term economics. In the early years, the case was compelling and largely accurate. Move faster, reduce friction, avoid capital spending, and scale with ease. Those benefits were real. Many organizations made architectural decisions that prioritized speed over leverage. They became dependent on managed services, provider-specific tools, and operating models that were easy to adopt but expensive to unwind.

Years later, many enterprises discovered that their cloud bills were much higher than expected and their exit options much narrower than advertised. That was not because the cloud failed. Architectural dependency eventually became financial dependency.

Generative AI is repeating that pattern, only faster. The integration barrier is lower, the pressure to adopt is higher, and the pace of enterprise experimentation is far greater. As a result, companies are wiring remote LLMs into applications, workflows, and agentic systems with very little thought about how these costs will behave in the next five to 10 years.

Agentic AI makes things worse

The more enterprises move from simple prompt-response systems to agentic architectures, the more dangerous the token trap becomes. Agents are not single-call systems. They plan, deliberate, retrieve information, invoke tools, evaluate results, retry steps, and often coordinate with other agents. Each of those actions consumes tokens. Costs no longer rise in a neat linear fashion. They compound.

This matters because agentic AI is increasingly being presented as the future of enterprise automation. It’s true in many cases. But if an enterprise builds agentic systems primarily on remotely hosted intelligence, it is also building future business processes on top of someone else’s pricing model. That is a major strategic risk. The more successful those systems become, the harder they are to replace. The harder they are to replace, the more pricing power shifts to the provider.

This is how businesses end up operationally dependent on a cost structure they do not control.

The appeal of AI sovereignty

The answer is not to reject public models or pretend that external providers play no role. They clearly do. There will always be cases where renting frontier AI capabilities makes sense. But enterprises need to stop assuming that renting is the default for every workload.

AI sovereignty is the alternative that deserves much more attention. That means building, tuning, deploying, and governing models inside the enterprise for use cases where long-term control matters more than access to the absolute frontier. Enterprises need to recognize that most business applications do not need a world-class general-purpose model. They need a model that is good enough for a specific purpose, aligned to the enterprise’s data, governed by the enterprise’s rules, and operated at a predictable cost.

It’s a very different way of thinking.

A self-hosted or enterprise-controlled model may not match the rich feature set of the largest public offerings. It may lack the same breadth, polish, or marketing appeal. But for many internal business tasks, those factors do not matter.

Here’s the most critical question to guide your architectural direction: Can a sovereign AI model solve the problem reliably, securely, and economically over time? If the answer is yes, owning that capability may be far more strategic than forever renting something with more power than you need. In effect, the enterprise becomes its own provider for the workloads that matter most.

Prepare for changing markets

Too many companies still treat generative AI architecture as a tactical IT issue. It is not. These decisions directly affect cost structure, operating flexibility, data control, and long-term competitiveness. If AI becomes a force multiplier across the business, the economics of AI become strategic to the business itself.

The companies that get this right will not necessarily be the fastest adopters. They will understand the difference between experimentation and dependency. They will use external models when it makes sense, but they will also invest in sovereign capabilities where ownership matters. They will think like architects, not consumers.

Here’s the takeaway: Cheap tokens come with strings. They are a gateway to a dependency model that will typically look very different once providers stop pricing for growth and start pricing for leverage. Enterprises cannot keep mistaking today’s bargain for tomorrow’s reality. Boards and executive teams need to act now to get ahead of this issue. The key question is not whether generative AI creates value. It clearly does. The real question is whether the enterprise can still afford and control the value it creates once the market matures.

Years ago, right-wingers coined the phrase “Trump Derangement Syndrome” (TDS) to describe people who hate US President Donald J. Trump. (I think it better describes the president’s outlandish, truth-challenged statements and the followers who think he can do no wrong.) What’s really deranged is his recent AI executive order.

First, a little history. As you may recall, Trump often (and loudly) trashed his predecessor’s Executive Order 14110, which had demanded “safe, secure, and trustworthy” AI. That Biden Administration order was replaced last year by Trump’s own “Removing Barriers to American Leadership in Artificial Intelligence” directive; it basically let US AI companies do whatever they wanted in the name of innovation.

Then, a little thing called Anthropic Mythos came along — and scared the pants off even AI’s biggest fans. Seemingly in response, someone in the federal government decided that letting AI companies do whatever they want might not be the brightest policy. 

Or, did they?

True, the new order creates a process under which AI companies can give US  government access to “covered frontier models” for up to 30 days before public release so experts can probe for vulnerabilities and test how the systems could be abused. It also directs agencies to set evaluation standards, establish an “AI cybersecurity clearinghouse,” and harden federal networks against rapidly advancing AI‑enabled attacks. 

Some people, like Graham Brookie, vice president for technology programs and strategy at the Atlantic Council, think the order is great. “The administration’s executive order on Advanced AI Innovation and Security is a serious policy with support from necessary stakeholders across party lines and industry to ensure the government is evaluating the cybersecurity risks posed by frontier AI models. It’s a policy that can be built on.”

Really? I’m not sure Brookie read the same document I did — if, indeed, he read it at all.

I quote:

“Nothing in this section shall be construed to authorize the creation of a mandatory governmental licensing, preclearance, or permitting requirement for the development, publication, release, or distribution of new AI models, including frontier models.

“In addition, ‘This order is not intended to, and does not, create any right or benefit, substantive or procedural, enforceable at law or in equity by any party against the United States, its departments, agencies, or entities, its officers, employees, or agents, or any other person.’”

In other words, AI companies won’t be required to do much of anything. And if they do  submit a project for review, get the government’s blessing for it, and something goes badly wrong, it’s not the government’s fault. 

So, exactly why would AI companies even mess with this performative AI security theater?

Beyond those concerns, who exactly will be judging AI projects in 30 days? In theory, it would be a cybersecurity clearinghouse made up of people from the National Security Agency, the US Treasury Department, and the Cybersecurity and Infrastructure Security Agency (CISA). Most likely, CISA would do the bulk of the heavy-lifting — it’s their job, after all. But there’s this wee problem; Trump’s so-called Department of Government Efficiency (DOGE) last year gutted CISA. There’s virtually no one left to do the work, and certainly not in 30 days.

There’s also the question of funding for the new initiative.  According to the order, “The Director of OMB, in coordination with the National Cyber Director and the Director of CISA, shall determine whether any Federal grant programs have available and relevant funding that can be directed toward applicants developing advanced AI vulnerability detection.”

Spoiler: There’s no money set aside for this purpose.

Leaving aside whether the Executive Order has any teeth at all — the Brennan Center for Justice argued that under the Constitution, it doesn’t; the closer you look at the document, the less substance you’ll find.

Besides, in an industry where success is all about releasing the latest Large Language Model (LLM) as fast as possible to garner attention and investor dollars, who exactly would want to put their AI models on ice for even 30 days? (Short answer: No one.) These companies are always going to be focused first on getting the word out about their latest model as fast as humanly — Uh, AI-ly — possible. 

Still, some people seem to think this executive order really will make a difference. For example, Paul Benda, the American Bankers Association executive vice president for risk, fraud, and cybersecurity, sees it “as a constructive step toward strengthening the nation’s approach to managing the cybersecurity risks and opportunities associated with advanced artificial intelligence [because it ] can help better protect critical infrastructure, including the financial sector.”

Oh, please. I’m so tired of people who skim the titles of Trump’s executive orders and then assume there’s anything real about them. 

This AI order is meaningless garbage, and anyone telling you otherwise is either lying or wants to be on the Trump regime’s good (?) side. Or, both — it could always be both. 

Model Context Protocol (MCP) has gained considerable momentum as a standard connector between LLM-powered tools and local systems, internal and external APIs, and data sources. From major clouds to devops tools, MCP servers are enabling powerful, AI-powered development and operations capabilities through natural language commands.

Nowhere is this more true than in the world of databases. Most major database platforms now support agentic access through MCP servers. Using an MCP server for databases, you and your AI agent proxies can perform lookups, create and update data, and perform administrative tasks without you having to write SQL by hand.

The MCP server could also guide your LLMs to write new code or build automations that align with your database schema, like its tables, structure, and fields, as well as embeddings, indexes, and metadata. It could also aid debugging by enabling faster queries to surface data issues or misconfigurations, along with plenty of other possible use cases.

Below, we’ll cover official MCP servers from some of the top platform options across major database styles. Though maturity varies, the MCP servers discussed below represent some of the best vendor-backed offerings available today across relational SQL, NoSQL, graph, vector, and data warehouse systems.

These servers can be used by any MCP-compatible tool, IDE, or agent, whether it’s Claude Code, Codex, Cursor, Gemini CLI, Google Antigravity, VS Code, Windsurf, or something else. Adding them is typically simple, often involving a lightweight JSON addition to your MCP configuration file.

Amazon Aurora MCP Servers

MySQL and PostgreSQL are the world’s most widely-used open source databases. However, in both cases, there is no canonical MCP server—what we see are different MCP servers emerging across vendors. One of these vendors is Amazon Web Services (AWS), which offers official MCP servers for Amazon Aurora, its managed relational database service compatible with both MySQL and PostgreSQL.

According to the documentation on GitHub, the Amazon Aurora MySQL MCP Server can be used to convert natural language commands into MySQL-compatible SQL queries, which can then be executed against Aurora MySQL databases. Similarly, the Aurora Postgres MCP Server provides MCP tools for working on PostgreSQL databases. The Aurora DSQL MCP Server does the same for distributed Postgres databases.

AWS provides a growing portfolio of official MCP servers across its product line, including MCP servers for other Amazon database platforms like DynamoDB, ElastiCache, and Redshift. If you’re a heavy AWS shop and you want to enable LLM interactions with your data, these are sensible choices.

BigQuery MCP Server

BigQuery is Google’s cloud-based data analytics platform, and a popular data source for AI applications. BigQuery users with API access configured can also utilize the BigQuery MCP Server to interact with the platform using MCP-compatible AI clients.

Using the remote BigQuery MCP Server, engineers can generate and execute queries on data sources, or return metadata on datasets, tables, and schema. This can be done with a simple natural language prompt like “List the datasets in project PROJECT_ID.” Results are filterable by region, data set ID, column name, and more.

As part of Google’s fully-managed, remote-hosted MCP portfolio, the BigQuery MCP Server provides some peace of mind regarding security, maintenance, and ease of use for distributed teams. The MCP tools are subject to some limitations, however, in terms of query result size, processing time, and other factors. If you’re using BigQuery and you want more agentic control, you’ll want to check this one out.

Elastic Agent Builder

Another important database category includes platforms designed for keyword and semantic search. In this space, Elasticsearch is commonly deployed. Instead of providing a single MCP server, Elasticsearch provides the Elastic Agent Builder, which is a more comprehensive framework aimed at agentic workflows.

Using Elastic Agent Builder, you can chat with an agent to retrieve data context from Elasticsearch data and extend it into various environments. The Agent Builder itself includes an MCP server endpoint for programmability and exposing the agent to other clients.

Unlike others on this list, this is not a direct MCP interface to raw Elasticsearch APIs. Instead, it’s an interface that exposes skills from the agent platform. This should also not be confused with the Elasticsearch MCP Server, released in mid-2025, which has since been deprecated.

A possible downside of using this utility is that it includes an additional layer between your IDE or agent and the data you’re searching. The agent setup requires a higher subscription and takes additional steps to configure compared to other MCP servers.

That said, if you want an extensible common layer to interact with both Elasticsearch and external MCP servers, while centralizing responsibilities like permissions, this is an interesting proposition.

MCP servers for Neo4j

Graph databases are another key NoSQL database type these days, specializing in using nodes and edges to accelerate queries of highly interconnected data. Of these, Neo4j is a popular graph database option.

The Official MCP Server for Neo4j works with all kinds of Neo4j deployment (desktop, sandbox, self-managed, and the managed Neo4j Aura cloud service), and allows LLM-based clients to retrieve graph schema, execute read and write statements, execute graph algorithms, and more.

In addition, several other MCP servers for Neo4j are available from Neo4j Labs. These have specialized uses, such as generating Cypher queries from natural language, maintaining an in-memory graph database, modeling and visualizing graph, and interacting with the Neo4j Aura API.

The first MCP server for Neo4j was developed in December 2024. If you’re an avid Neo4j user and want to experiment with interacting with your graph databases in a chat-infused way, these stand as an interesting platform of servers.

MCP Toolbox for Databases

Google’s MCP Toolbox for Databases is a notable MCP server because it’s a popular catch-all for various database types. Unlike the other entries on this list, this server connects LLMs not to a single managed database, but unifies LLM access to multiple systems. The open source utility ships with pre-built configurations for nearly 30 databases including PostgreSQL, MySQL, SQL Server, Oracle Database, MongoDB, Redis, Neo4j, and Snowflake, as well as the databases in Google Cloud.

Once you define data sources in a tools.yaml file, you can use MCP Toolbox to perform structured queries or semantic searches against databases directly from within an IDE or agentic client using plain English. MCP tools translate commands into actions like list_tables and execute_sql.

MCP Toolbox for Databases is mature, originally built as a generative AI utility and later re-worked for MCP-style workflows. It offers numerous download, configuration, and interaction methods.

If you’re using a variety of databases on Google Cloud and elsewhere and you want an “all-in-one” MCP server, MCP Toolbox for Databases is a great place to start.

MongoDB MCP Server

MongoDB is the popular NoSQL document-oriented database. The creators of MongoDB have released an official MCP server that works with the open-source database as well as the company’s cloud-hosted MongoDB Atlas database platform.

The MongoDB MCP Server provides a number of tools to interact with MongoDB. You can query the database, return information on collections, create or remove collections or indexes, gather statistics on database usage, and more. Other tools enable MongoDB Atlas operations, like creating users or clusters, returning cluster data, and other functions.

The server’s tools are read-only by default but can be switched to allow write capabilities. It can be used locally, but also supports Streamable HTTP transport for remote servers, although that comes with greater security concerns.

For those using MongoDB and wanting to hook their AI-enabled IDE or CLI up with more automated powers, the official MongoDB MCP Server is worth checking out.

Pinecone MCP server

Among vector-native databases, Pinecone stands as a strong, widely used option with a well-designed API and comprehensive SDKs. The Pinecone MCP server extends this experience, allowing users to query its documentation and execute functionality via AI agents and AI-enabled IDEs.

To date, the Pinecone MCP server consists of nine MCP tools. These cover read-only actions, like knowledge gathering via the Pinecone official documentation and querying vector records, index metadata, configurations, and statistics. It also allows for write operations like updating records and creating new indexes.

Released in mid-2025, the Pinecone MCP server is one of the more complete early implementations, with easy configuration and installation.

For those using Pinecone who want to test new LLM-assisted workflows for creating indexes with embeddings, performing reranking, or testing results using natural language commands, the Pinecone MCP server is worth trying out.

Redis MCP

An ultra-fast in-memory database, Redis is commonly used for caching, real-time analytics, and other latency-sensitive use cases. And as you might have guessed, the company behind the Redis database provides an official MCP server. The server allows read, query, and write capabilities.

Developers can use Redis MCP from an LLM client to perform high-level actions to analyze, reference, or embed Redis data and interact with the Redis server within their prompts. The documentation suggests some example prompts for common use cases, such as “Cache this item,” “How many keys does my database have?,” and “What is user:1’s email?”

Unlike other MCP servers, which only allow a slice of platform capabilities, Redis MCP offers full Redis support. This enables working with Redis constructs such as hashes, lists, sets, sorted sets, streams, and more, according to the GitHub repository.

One possible drawback is that Redis MCP has yet to support Streamable HTTP transport. Until this is developed, the server is constrained to local deployment. But for those seeking a local MCP server to work with Redis data, this is the best choice.

Snowflake MCP Server

Snowflake is a cloud-hosted, AI-enabled data platform widely used in enterprise contexts for data warehousing, data analytics, and data engineering purposes. Compared to other data storage systems, Snowflake is unique in that it’s more fully managed and combines structured and non-structured data types.

The Snowflake MCP Server, available on GitHub, can be used to perform many of the standard Snowflake platform operations. This includes a “fuzzy” search of all records via Snowflake’s Cortex Search and structured data semantic lookups using Cortex Analyst.

Other abilities include object management operations like creating, updating, and deleting records. The server also can invoke other agentic-designed capabilities, like the ability to generate and execute SQL statements against back-end databases.

Snowflake MCP Server is well-thought-out and well-documented, with walkthroughs for various agent and deployment patterns. Those already building with Snowflake should find it complements the mechanics they already employ.

Supabase MCP Server

A longtime open-source favorite, PostgreSQL is one of the most popular and trusted object-relational SQL-based database systems. With an active open source community, Postgres has been maturing for decades. Given its open source nature, there isn’t a single “official” MCP server for the platform. Anthropic built an original reference implementation, but it’s now archived.

Instead, database platforms built on PostgreSQL provide different flavors of MCP servers, with a range of vendor neutrality and specificity. One notable option is the Supabase MCP Server, provided by Supabase, a cloud-based “back end as a service” and Postgres development platform.

Supabase MCP Server connects AI agents with Supabase projects, allowing engineers to issue natural language commands to manage tables, query data, get logs, fetch configuration information, and more. The Supabase MCP Server is pre-1.0 release and some features are still experimental.

If you’re an engineer using Supabase and looking for an MCP server to connect your AI assistant with your Postgres databases, this is a good tool to test out.

Other MCP servers for databases to consider

So far, we’ve reviewed official, vendor-backed MCP servers from some of the most-adopted managed databases. However, numerous MCP servers exist across other database platforms and types.

One MCP server that aggregates LLM access across various database types is DBHub, which works with MySQL, PostgreSQL, SQL Server, MariaDB, and SQLite. Developed by Bytebase, DBHub is described as a zero-dependency, token-efficient MCP server.

For SQL, the options are nearly endless. Official servers exist for Microsoft Azure SQL and DuckDB. PulseMCP catalogs more than 100 MCP servers for MySQL, although most are unofficial, solo-creator open source projects. Of these, one of the most starred is MCP Server for MySQL, developed by full-stack developer Ben Borla and optimized for Claude Code.

For Postgres, notable alternatives to Supabase include pgEdge Postgres MCP, Neon MCP server, and Postgres MCP Pro. For vector databases, others beyond Pinecone have been quick to adopt MCP as well, including Weaviate and Milvus.

Using MCP for databases: what to watch out for

Before diving into MCP servers for enterprise databases, it’s important to understand the security risks. For instance, prompt injection remains an unsolved problem, so it’s recommended to limit permissions for SQL statements.

To mitigate this, Supabase recommends enabling AI client settings that require manual approval for each tool call before execution. Experts also recommend assigning only the minimum permissions required and avoiding exposure of sensitive data like API credentials. Due diligence around authentication and authorization is especially important when hosting remote servers.

Lastly, to avoid shadow IT, it’s becoming common practice to catalog the internal MCP servers you use, even for experimental projects. For this, experts recommend an MCP registry that documents approved servers. An MCP registry improves both MCP server discovery and security awareness.

Anyone can build an app now. But nobody seems to care.

Well, not nobody. VCs keep funding startups that add AI to, well, everything. But users aren’t buying the massive influx of new apps. In a chart shared by Jen Zhu Scott based on the new National Bureau of Economic Research’s working paper “Writing Code vs. Shipping Code,” iOS app releases have exploded since the advent of agentic AI. That would perhaps be cause for celebration had app reviews not declined during this same period, and apps with significant usage have stayed essentially flat.

In other words, more apps but almost nobody new showing up to use them.

For those of us that grew up in open source, it’s a familiar problem. The greater the abundance of code, the greater the need to help would-be customers navigate it through marketing (including branding), sales, etc. AI is creating so much noise, in terms of new code, new products, etc., that the real work has shifted to taste-making.

Getting more but not using more

I’ve been saying for a while that developer productivity isn’t about producing more code faster. Or at least it shouldn’t be. Productivity is about producing well-architected, secure, maintainable code that solves a problem someone actually has.

That’s a very different thing. It’s not something AI can fix; at least, not yet.

Charity Majors put it more bluntly in a post I wrote in 2024: “Writing code is the easiest part of software engineering,” she said. The harder parts are figuring out what to build, integrating it into a larger system, validating that it works, maintaining it over time, and getting humans to trust it enough to use it.

Turns out the harder parts are really hard. Mert Demirer, Leon Musolff, and Liyuan Yang tracked more than 100,000 GitHub developers alongside their AI usage telemetry. Autocomplete, interactive agents, and autonomous agents each ramped raw coding activity, with cumulative effects on commits of 40%, 140%, and 180%. That sounds great until you look how the gains attenuate the closer you get to actual users. For example, that 180% jump in commits became roughly 50% more projects and just 30% more actual releases. The report’s authors call this the weak-link problem: The strong link (writing code) got much stronger, while the weak links (everything else humans have to do) didn’t. The estimated elasticity of substitution between AI and human effort is 0.25, which is economist for “these complement each other, but they don’t replace each other.”

When the authors checked four major app marketplaces, they found a bump in new apps but no increase in total usage. In other words, we’re getting better at creating things with AI’s help; apparently we’re not good at turning that into user interest. User attention (and budget) is finite. The hard part is to figure out how to get users to care enough to pay (with their time or their money).

Learning to love marketing

So what’s actually scarce in a world of near-infinite software? Not code, for sure. No, what’s scarce is attention, trust, and a reason to switch.

That means the durable advantages in software increasingly live in the parts of the business developers often undervalue, like a recognizable brand (something that Red Hat figured out early on in open source) or a channel they already use. Or it could be in areas that developers appreciate but don’t pay for, like good documentation or a welcoming community.

This isn’t a new idea; it’s just newly unavoidable. We’re watching something similar inside enterprises, where AI adoption is wildly uneven, not because the technology has no value, but because the organizational plumbing around it often hasn’t been built. This is why a new kind of speed is important. I once argued that speed was the killer app, and that was mostly true. Today the more interesting speed is how quickly you can earn trust, fit into a workflow, answer objections, and get adopted.

Years ago I wrote that RethinkDB was dead and MongoDB wasn’t what killed it. RethinkDB was at the time, by many technical measures, a better database, built around “correctness, simplicity, and consistency.” It still lost—and badly. Its founder’s own postmortem was unsparing: They had picked a brutal market and tuned the product to the wrong definition of good. Being technically right turned out to have almost nothing to do with getting adopted.

With AI we’re generating a thousand smaller “RethinkDBs,” only faster and with nicer landing pages generated by the same model that wrote the code. These aren’t going to win, any more than RethinkDB was able to unseat MongoDB. It’s not just about the tech, but rather about making that tech fit within a user’s or enterprise’s world and making it easy to adopt. AI makes this harder, not easier.

It’s a cliché that developers don’t like marketing. It’s also false in my inexperience. What developers don’t like is traditional marketing. During my time at MongoDB and now at Oracle, my developer relations teams have focused on offering developers deep, hands-on enablement, and the response has been fantastic. Is a technical tutorial marketing? Of course it is. So is a forward-deployed engineer working side by side with an enterprise’s engineers to help them effectively use your tech. Just because it’s not a 30-second Super Bowl ad doesn’t mean it’s not marketing.

Years ago the Dilbert cartoon captured developers’ disdain for marketing. It was funny then, and it’s funny now, but it has never been true.

Years ago Matt Klein, creator of the open source Envoy project, once talked me through all the non-development work that goes into making an open source project thrive. As he reflected, “If you look at what I did in 2016 and early 2017 to [introduce] and grow the project, it was not technical.” So what was it, if not core engineering? “It was all leadership, public relations, marketing, documentation, etc., and I did it all myself and I nearly killed myself [doing it].” As he summed it up for me, it was a “f—ing lot of work,” and much (most?) of it wasn’t about code. It was about helping users appreciate the value of that code.

TL;DR? The boring but essential go-to-market grind has always been the real job. It’s what will separate winners from losers in AI.

The boring work wins

None of this is an argument against AI coding tools. Developers should absolutely use them. I use them constantly.

But AI can’t compensate for the hard work that goes into making a product successful in the market. In a world drowning in AI-generated sameness, taste becomes a competitive advantage. For me, “taste” translates into knowing what not to build, or what not to publish. It’s also all about knowing how to market one’s product, which might include ads but definitely needs to incorporate technical training that helps developers make sense of your code.

In short, there’s no Field of Dreams “build it and they will come.” There’s just a lot of hard, human work to help real people find and use your code.

Agentic AI has moved from conference hype to a budget line item. This is where the conversation gets more interesting and more uncomfortable. Unlike traditional AI systems that respond to a single prompt, classify a document, recommend an action, or generate a summary, agentic AI systems are designed to pursue goals. They plan, call tools, inspect results, retry failed steps, consult memory, hand off tasks to other agents, and sometimes critique their own work before producing an answer or taking an action.

That extra autonomy is the value proposition. It also introduces the cost problem.

A single chatbot interaction may consume a few thousand tokens. A useful agentic workflow can consume hundreds of thousands or millions of tokens per day because it does more than answer a question. It decomposes the problem, retrieves context, reasons through options, invokes APIs, checks the output, and often runs multiple passes before reaching a result. Therefore, the economics need to be understood at the level of “agent instances,” not just model calls.

For the estimates below, I am using a blended token cost of $3 dollars per million tokens. This is not intended to reflect a single vendor’s list price. It is a blended planning figure that assumes a mix of input and output tokens, reasoning steps, retrieval-augmented generation, summarization, tool calls, memory updates, and occasional use of larger context windows. Some enterprises will pay less through volume discounts or by routing work to smaller models. Others will pay more by using premium models, long-context prompts, web browsing, large document ingestion, and repeated reasoning loops.

The basic formula is straightforward. If an agent consumes 2 million tokens per day, it consumes 730 million tokens per year. At $3 per million tokens, that single agent costs about $2,190 per year in token burn. That number sounds surprisingly low until you multiply it by the number of agents, workflows, and users, plus the surrounding infrastructure required to run these systems safely.

What an agent really costs

In the model used here, the annual token-only cost per agent ranges from about $1,095 to $3,833, depending on the use case.

• A lightweight HR recruiting or onboarding agent that consumes one million tokens per day costs about $1,095 per year.
• A more demanding software engineering agent that consumes 3.5 million tokens per day costs about $3,833 per year.
• Customer support agents are roughly $2,190 per year.
• Legal contract agents cost about $2,409 per year.
• Security triage agents run about $2,738 per year.
• Research agents are around $3,066 per year.

These figures are useful but incomplete. They include only LLM token consumption and exclude orchestration platforms, vector databases, observability, model evaluation, security controls, workflow monitoring, human review, enterprise application integration, data pipelines, audit logging, prompt management, and the engineers needed to build and maintain the systems. In real deployments, I would expect the all-in operating cost to be two to five times the raw token cost. For regulated or mission-critical environments, the multiplier can be even higher.

This is where many agentic AI business cases become less clear. The model call may be inexpensive, but the system around the model is not. An agent that can update a customer relationship management system, approve a refund, generate a purchase order, or recommend a security containment action needs guardrails, permissions, logging, rollback mechanisms, and human escalation paths. These are not optional features. They are the difference between a demo and an enterprise system.

Use cases that make economic sense

Customer support is one of the more obvious use cases. A typical support automation deployment may use eight agents: an intake classifier, a knowledge retrieval agent, a response drafting agent, an escalation agent, a quality review agent, a CRM update agent, a sentiment detection agent, and an analytics agent. At two million tokens per agent per day, each agent costs about $2,190 per year in token burn, bringing the annual total to roughly $17,520. If that system deflects even a modest number of tickets or improves agent productivity, the economics can be attractive.

Sales development is another practical example. A five-agent system for account research, lead enrichment, email personalization, CRM updates, and follow-up scheduling may consume 1.2 million tokens per agent per day. That results in an annual cost of about $1,314 per agent, or $6,570 for the full agent team. This can be compelling if it improves pipeline quality, but it can also be wasteful if agents generate low-quality outreach at scale. The cost of brand damage is not measured in tokens.

Software engineering is more expensive but potentially more valuable. A 12-agent system covering requirements analysis, architecture, code generation, testing, review, security checks, documentation, CI debugging, refactoring, release notes, dependency analysis, and hot-fix support may consume 3.5 million tokens per agent per day. That works out to about $3,833 per agent annually or roughly $45,990 for the full system. Compared with engineering salaries, the token cost is small. The real question is whether the system reliably improves throughput without increasing defects, security vulnerabilities, or maintenance complexity.

Security operations also fit the agentic model because the work is repetitive, time-sensitive, and context-intensive. A 10-agent security triage system could include agents for alert triage, log analysis, threat intelligence, endpoint investigation, network investigation, incident summarization, ticketing, compliance evidence, escalation, and post-mortem. At 2.5 million tokens per agent per day, the annual token cost is about $2,738 per agent or $27,375 for the system. This is easy to justify if it reduces alert fatigue and accelerates response, but risky if the agents hallucinate causality or bury critical signals in confident summaries.

Finance, legal, healthcare administration, market research, HR, and supply chain are also viable:

• A six-agent finance close system may cost about $9,855 per year in token burn.
• A four-agent legal contract review system may cost about $9,636.
• A seven-agent healthcare administrative workflow may cost about $13,797.
• Competitive intelligence using six agents may cost $18,396.
• HR recruiting and onboarding using five agents may cost $5,475.
• Supply chain planning and exception management using eight agents may cost $21,024.

Across all 10 example use cases I’ve mentioned in this section, the model assumes 71 agents and a total annual token burn of about $175,638.

The comparison with traditional AI

The economics of agentic AI should always be compared with simpler approaches. Traditional AI, workflow automation, rule engines, robotic process automation, and non-agentic LLM calls are often cheaper, easier to govern, and more predictable. Agentic AI is usually overkill for tasks like classification, extraction, summarization, routing, or drafting within a narrow context. A deterministic workflow with a single model call can do the job at a fraction of the cost and risk.

Agentic systems make sense when the process requires judgment across multiple steps, dynamic planning, tool use, exception handling, and adaptation to incomplete information. They are valuable when the path to the answer cannot be fully scripted in advance. They are less valuable when enterprises use them as a trendy substitute for basic automation.

The best architecture is usually hybrid. Use traditional automation where the process is stable. Use non-agentic AI where the task is bounded. Use agentic AI only where autonomy creates measurable leverage. That means fewer agents, tighter scopes, explicit budgets, model routing, token monitoring, and human checkpoints for high-impact decisions.

The financial mistake many organizations will make is to treat agents as digital employees with near-zero marginal cost. They are not. They are probabilistic software components that consume tokens, trigger tools, create operational dependencies, and require supervision. The token bill may be manageable. The governance bill may not be.

Agentic AI can absolutely be worth the money. In many cases, the annual token burn for a useful agent team is less than the loaded cost of a single employee. But that is not the same as saying it is cheap. Companies must measure agent cost per completed business outcome, not cost per prompt or cost per model call. In the end, the question is not how much an agent costs. Ask yourself the right question: Does the autonomy an agent provides outweigh the complexity it introduces?

For the past two years, enterprises have focused on grounding AI systems in internal documents, databases and knowledge repositories. Microsoft now contends that the next challenge is giving those systems reliable access to the outside world as they move into production.

At its ongoing annual Build conference, Microsoft unveiled Web IQ, a new suite of AI-native APIs designed to connect AI agents and applications to real-time information from across the web, including web pages, news, images and videos.

The goal is to help developers build more accurate and context-aware AI systems while reducing the complexity of integrating web search, retrieval and grounding capabilities into enterprise applications, the company wrote in a blog post.

The APIs already underpins grounding for Microsoft Copilot and ChatGPT, and unlike traditional search APIs are designed to retrieve highly relevant information while minimizing token consumption, helping reduce both inference costs and response latency, Microsoft said.

Reducing the cost and complexity of web grounding

That focus on reducing inference costs and response latency to deliver Web IQ’s search capabilities will be valuable for CIOs and developers, said Phil Fersht, chief analyst at HFS Research.

“Developers have typically stitched this together themselves using search APIs, web scraping, retrieval-augmented generation, vector databases, custom ranking logic, crawling tools and separate orchestration layers. That works, but it is messy, brittle and expensive to maintain,” he said.

“The hard part is not just finding a web page. It is retrieving the right evidence, ranking it, selecting useful passages, reducing token waste, respecting publisher controls and doing all this fast enough for multi-step agents,” he added.

An agent running in production will typically run at least five or ten retrieval steps and in such scenarios latency and cost can become “ugly,” said Moor Insights and Strategy principal analyst Mike Leone.

“I’ve watched plenty of teams handle this by gluing a search API onto a model and hoping the model can sort through whatever HTML comes back, which isn’t ideal,” he said.

Simplifying development of applications

Beyond the infrastructure and cost advantages, Web IQ could also simplify the AI application building process developers, said Stephanie Walter, practice lead of the AI stack at HyperFrame Research.

“The value of Web IQ is that Microsoft is trying to make web grounding a reusable, agent-native service rather than a bespoke integration,” Walter said.

That reusability, Fersht said, will matter to CIOs as most enterprises do not want every development team rebuilding its own web grounding stack: “They need a common capability that is governed, scalable, low-latency and economically efficient.”

Still, Microsoft is not entering an untapped market and there are several offerings already available, including OpenAI web search, Google grounding, Perplexity APIs, Bing Search APIs, Azure AI Search, vector databases, and custom RAG pipelines.

However, Microsoft might have an advantage with IQ, despite Google’s strength in search and web-scale knowledge, OpenAI’s tooling push, and AWS’ Bedrock-data-service-partner integrations combo, Fersht said.

“Microsoft’s differentiation is that it can combine Bing’s global web index with Azure AI, Copilot, Foundry, Microsoft 365 and enterprise developer channels,” he said.

The other advantage is the existence of existing IQ offerings, such as Work IQ, Fabric IQ, and Foundry IQ, all of which are targeted towards adding more business context for agentic systems, Fersht added.

But uptake, Walter said, will depend on whether these integrations translate into better production outcomes.

Web IQ is currently available in limited access for select Azure customers. Enterprises can request access to Web IQ via their Microsoft account team or submit a form.

Beyond direct API access, developers can also configure the model-agnostic Web IQ as an MCP tool within Foundry IQ, a Microsoft spokesperson said.

Google has released new tools that allow developers to run agentic AI workflows locally using Gemma 4 12B, a 12-billion-parameter model from Google DeepMind.

In a blog post, the company said the model, combined with the Google AI Edge stack, can be used to build and test applications on everyday machines. The model-runtime combination supports capabilities such as autonomous data processing, visual insight generation, webpage creation, and tool use.

The release includes Google AI Edge Gallery for macOS, where developers can use Gemma 4 12B to generate and run scripts for tasks such as data analysis. Google also said its Eloquent voice dictation and editing app now runs fully on-device on macOS, with support for local transcription and voice-driven text editing.

Google has also expanded LiteRT-LM, its lightweight command-line tool for running language models locally, with a new serve command. The company said this allows the CLI to act as a local LLM server and lets developers connect Gemma 4 12B to standard tools, SDKs, and frameworks through a local endpoint.

“Your data stays on your device while maintaining reliable responsiveness, utility, and cost efficiency,” the company said in the blog post.

The announcement comes as enterprises are looking beyond large, general-purpose models for some AI workloads. Gartner predicted that by 2027, organizations will use small, task-specific AI models at least three times more than general-purpose large language models, citing demand for more contextualized and cost-effective AI systems.

Challenges to overcome

But running agents on employee devices brings a number of problems. Companies must work within the limits of endpoint hardware, which can restrict the size of models that run effectively and the number of model instances that can operate at one time.

“While the AI can now fit on a laptop, enterprise IT infrastructure is largely unprepared to manage it,” said Rishi Padhi, Principal Analyst at Gartner. “Even highly optimized models like the Gemma 4 12B require around 16GB of unified memory or VRAM to run alongside standard applications. Many standard-issue enterprise laptops lack the memory bandwidth and NPUs/GPUs required for fluid, multi-turn agentic execution.”

Anand Joshi, AI analyst at TechInsights, said local deployment also changes the nature of the workloads. On a PC, search may mean finding information across internal folders and files. In a data center, the same function could involve searching the internet or querying a large database such as SQL.

“The framework for local deployment of agentic AI is different from that of a data center,” Joshi said. “The models are smaller; you can run only one instance of a large model at a time. You are limited by memory, CPU, and so on.”

Security and governance are also likely to become bigger concerns as AI agents move closer to enterprise endpoints. Agentic AI is designed to take actions, creating new security risks when local models are given access to employee files or allowed to interact directly with applications and scripts.

“Sandboxing these agents without breaking their utility is still a major operational challenge,” Padhi added. “And all this while enterprises need to audit AI usage for compliance and security. When inference happens entirely offline, capturing logs, tracking model drift, and ensuring employees are using the approved, compliant ways for a model becomes incredibly difficult.”

The cost tradeoff

Running AI agents locally could reduce some cloud inference costs, but the savings may be offset in the near term by higher spending on endpoint hardware and management.

“First and foremost, it is an OpEx-to-CapEx shift, as it shifts that financial burden by forcing accelerated hardware refresh cycles for premium PCs or edge devices,” Padhi said. “It would require buying expensive, high-memory laptops for employees at a time when memflation in the hardware industry is already driving up end-user average selling prices for laptops.”

Many enterprises refreshed PCs in 2025 to support Windows 11, but at that point most AI inference still ran in the cloud, and the case for on-device AI remained unclear, Padhi said.

Enterprises may therefore move cautiously, buying AI-capable PCs only where local inference has a clear business case.

Over time, however, on-device AI could make enterprise AI spending more predictable by reducing exposure to variable cloud inference bills. The tradeoff is that companies may face a higher baseline cost for equipping and managing employees’ devices.

Complementing cloud AI

For enterprises, local AI is unlikely to replace cloud-based AI outright. Analysts said local AI is more likely to be used for workloads that benefit from endpoint processing, especially when applications must operate offline or when privacy and response times are critical.

“For local agentic AI to proliferate, the use cases on edge will have to complement data center/cloud use cases,” Joshi said. “I don’t expect local agentic AI to replace cloud AI, but it has potential to take a slice away from the cloud, and models like Gemma are significant steps towards enabling that.”

The market, Joshi added, is still determining where local AI fits best. “I estimate that use cases that require privacy or have strict latency needs will move to local node first, with further migration of others in the next 2-3 years,” he said.

Padhi said model placement will depend on the privacy requirements of a workload, the computing power it needs, and where the relevant data resides. Tasks such as code generation or analysis of local files could increasingly run on employee devices, while enterprise-wide RAG systems and more complex AI workflows are likely to remain cloud-based.

Artificial intelligence does not advance at the same pace across industries. It presses forward in some directions while lagging behind in others.

Spend time with today’s most advanced AI applications, and this contrast becomes obvious. In software development, AI is quickly becoming ubiquitous. It writes production-ready code, explains obscure libraries, and iterates at a pace human teams have difficulty matching.

But place that same AI model inside a complex customer support workflow or ask it to reason through a nuanced clinical scenario, and the cracks begin to show. Multi-step reasoning falters. Context gets lost. Performance drops in ways that can seem inconsistent with the model’s strengths elsewhere.

These AI models are often similar. They run on similar hardware and are often trained in similar ways. So why the mismatch in performance across tasks? The simplest explanation is also the most overlooked: data.

Software engineering benefits from an immense, structured, and highly visible digital record. Code is written in standardized languages, benefits from robust documentation, is reviewed in public forums, and is discussed at scale. That ecosystem has generated a robust and massively useful pool of training material.

Other fields often do not. For example, healthcare data is scattered across institutions, wrapped in privacy constraints, expressed in multiple modalities, and rarely ready out-of-the-box for AI training. Enterprise workflows are captured in internal systems that were never designed for training AI. Multilingual speech data varies widely in quality and representation.

This imbalance creates what I describe as “the data gap.” This is the distance between what models are capable of in theory and what they can achieve in practice, because the right data does not yet exist in usable form. Closing this data gap may be the most important—and least glamorous—challenge in AI today.

The missing pillar of AI progress

Three forces are driving the recent advances in AI: the models, the chips, and the data.

On the AI models, the field has invested heavily. Major research organizations employ thousands of researchers and scientists who are actively refining architectures, training techniques, and evaluation methods. Breakthroughs are measured in benchmark scores, conference papers, and model performance on human tasks. On the computing chips, the investment has been equally intense. Hardware manufacturers and infrastructure providers are pouring billions of dollars into building and supporting data centers that deliver faster results via large-scale training.

Yet data has not received the same institutional focus for AI development. Conversations with researchers at frontier AI labs share a similar frustration that today’s model capabilities in key use cases, such as healthcare, are limited less by architectural imagination and more by the availability of high-quality, domain-specific data. The bottleneck is not always a lack of ideas, but a lack of reliable inputs.

We are long past scraping the internet for useful data, and this path does not scale. Progress depends on building and curating datasets that reflect the complexity of true lived experience and organizational processes. That work requires both scientific rigor and research specialization in the field of data for AI.

The dataset behind every leap

The history of AI reinforces a consistent lesson: major leaps in model capability follow major leaps in the availability of quality data. From early vision systems that relied on clearly labeled images to today’s language models trained on massive text collections, each major leap has depended on access to more high-quality data.

Architectural innovation alone is rarely enough. The value of these new approaches only emerges when paired with large, structured, and representative datasets that reveal what the models can actually do in practice. Whether in vision or language, progress has depended on the painstaking work of collecting, organizing, and validating the underlying data.

Large language models illustrate this clearly. Their emergence was not just the result of better training techniques, but of access to an unprecedented volume of data. The models did not generate that data. They relied on it. That pattern raises a pressing question for the present: who is building the next generation of foundational datasets?

Across domains ranging from healthcare to audio to agentic task performance, there is no widely accepted blueprint. What constitutes a gold-standard dataset for training an AI agent to handle complex enterprise tasks? What does a clinically meaningful evaluation look like for a model that will assist in medical decision-making? How should multilingual speech data be curated to ensure broad representation and reliable performance?

These are not simple sourcing problems. They are fundamental research challenges that need to be solved.

When data is treated as a commodity

Too often, consequential data decisions are handled like procurement exercises. An organization requests “medical conversations” or “wildlife scenes,” and the request is routed to internal procurement or data sourcing teams, or to external data vendors, who assemble data that appears to match the description. The implicit assumption is that data is interchangeable, that one dataset is as good as another so long as it meets a basic specification.

Actual application suggests otherwise. Seemingly small choices about factors such as inclusion criteria, annotation standards, filtering rules, and validation protocols can dramatically alter downstream performance. Data design shapes model behavior as much as architecture does.

Three structural issues compound the problem:

• Capacity: There are relatively few specialized teams dedicated to building domain-specific datasets at the highest level of rigor. Talent and funding have gravitated toward model development and hardware innovation. Data work often operates in the background, even though it underpins both.
• Design: Constructing a dataset is a distinct discipline from designing a neural network. It requires expertise in experimental design, domain knowledge, and statistical validation. Expecting model researchers to simultaneously shoulder the full burden of data research, while also training and evaluating the models, overlooks the complexity of the upstream task.
• Translation: The researchers who are requesting specific data sources to improve the models are often not the same people responsible for sourcing that data. As a result, nuances and research-backed expertise can often be missing or diluted as requests pass through layers of procurement and vendor relationships. The result can be data that meets the specification sheet, but in fact fails to advance model performance.

The rise of annotation providers and reinforcement learning services has addressed part of the need. Rating model outputs, labeling text, and evaluating structured information are essential for many optimization tasks. But these activities generate data that is carefully constructed for specific, bounded purposes.

The frontier challenges in AI require more. They demand datasets derived from real human activity and organic organizational processes. Such data is complex, multimodal, and sensitive. It is rarely AI-ready by default. And converting it into reliable training and evaluation material is a scientific undertaking.

The need for scientific rigor for the AI data layer

If high-quality data is a central bottleneck, then scientific rigor is part of the solution. Just as leading model-builders have dedicated research labs and hardware has dedicated development ecosystems, the data layer for AI requires focused, scientifically-grounded institutions.

This means engaging directly with core questions like dataset design, evaluation methodology, and quality control. The conversation cannot end at volume; it must address data structure, representativeness, and expert validation.

Dataset construction must be approached as experimental design. Protocols must be documented and validated. Evaluation frameworks must test whether the dataset truly reflects the intended applications.

The field also requires standards and benchmarks that reflect real-world complexity, not simplified proxies. In healthcare, for instance, evaluating a system intended for clinical assistance with generic question-and-answer tests is insufficient. Real-world clinical environments involve multimodal inputs and contextual judgment. Benchmarks must reflect that reality if they are to function as meaningful gates before deployment.

Quality measurement is another crucial frontier. Finance relies on standardized metrics such as credit scores to assess risk. AI lacks an equivalent for datasets and benchmarks. Developing clear methodology to quantify dataset quality and evaluation reliability brings clarity to model assessment.

The criteria for evaluating a multilingual audio library will differ from those of a multimodal oncology dataset. Yet the underlying principle remains constant. Better models require better-defined, better-measured data.

The risks of getting it wrong

As AI systems move closer to high-stakes deployment, weak data practices carry tangible risks.

Benchmarks cannot be created with the same data that is used for training—that’s giving the test answers to the model ahead of time. Scaling data volume without prioritizing data quality and selection diminishes model performance gains, and can even bias against or omit underrepresented populations. These are methodological challenges, and ones that must be solved.

The rigor required at the data layer may not attract headlines. It does not typically lend itself to dramatic product launches. Yet the data layer for AI is foundational to trust, safety, and sustained progress for all AI progress.

An ecosystem for the data era

No single organization can resolve the data gap alone. What is needed is an ecosystem of AI data labs and research groups, each focused on different domains and challenges but united by a commitment to scientific discipline. These institutions would collaborate with model researchers and domain experts who would tackle challenges such as dataset contamination, factuality, groundedness, de-identification, international representation, and bias. They would design benchmarks that mirror real-world complexity rather than simplified abstractions.

AI’s trajectory will not be determined solely by larger models or faster chips. It will be shaped by the datasets we construct, the standards we adopt, and the rigor we apply at the foundation. The uneven frontier we see today reflects an uneven data landscape. Bridging the gap requires deliberate, research-driven dataset design.

If we want AI systems capable of operating reliably in clinical contexts, navigating enterprise workflows, and functioning responsibly across languages and cultures, we must treat data for AI as a first-class scientific endeavor.

AI models have their research labs. AI chip-builders have their fabrication plants. AI data needs institutions of equal seriousness and ambition.

—

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.

Cloud computing has reached a crossroads. The high cost and data sensitivity of AI workloads are raising the appeal of private clouds, even as neoclouds and sovereign clouds shake up the cloud provider landscape. New cyberthreats, shifting compute requirements, and management complexity are adding to cloud complications.

Download the June 2026 issue of the Enterprise Spotlight from the editors of CIO, Computerworld, CSO, InfoWorld, and Network World, and learn how to navigate the latest cloud strategy developments.

When I was a kid, we all marveled at the notion of the Star Trek computer that you’d just talk to and that would answer all your questions. It seemed impossibly fantastic and categorically impossible. Well, we have that now. In one episode, Captain Kirk used a universal translator to communicate with an alien (never mind that the aliens always seemed to speak English..). Today, everyone’s phone can do real-time translations between all the most commonly spoken languages on the planet. 

If you haven’t figured it out by now, I’m bullish on agentic coding. I think it’s marvelous, I think it will bring about an increase in software development jobs, and I think it will bring about unprecedented growth in the production of software. It’s that last point I want to explore a bit more deeply, because I think an explosion of software is coming.

Thomas Watson, the legendary IBM CEO, is often misquoted as saying, “I think there is a world market for maybe five computers.”  The true story is that he went out to talk to 20 customers, hoping to sell five IBM 701 computers, and ended up with 18 orders. Of course, today, computer sales are measured in the hundreds of millions. 

We are currently in the “loving the thought of getting 18 orders after expecting five” stage of software. We are just getting started.

Mr. Watson probably couldn’t envision everyone walking around with a computer in their pocket that is a 100 million times more powerful than that IBM 701. And though I’m going to try, I’ll certainly come up way short of imagining a volume of software output that is eight orders of magnitude beyond what we are producing today. 

Ready for takeoff

The first chunk of this blitz will be software that looks familiar and isn’t that surprising. It will be the software sitting in our backlogs — things we’ve wanted to do for years but haven’t had the time for. All software development houses have these projects, and now they will get done. This software will be an expansion of the software we currently have. 

The second chunk will come when companies without development teams realize they can build the software they need using consultancies that can deliver quickly and at minimal cost. They will develop software tools that fit their unique business needs. Instead of using off-the-shelf solutions that they adapt to their needs, they will build custom software that works exactly the way their companies do.

The third chunk will come when those companies figure out that they can build the software they need themselves. Agentic coding tools will soon be powerful enough for non-developers to create the custom software a company needs, and they’ll be able to do these things in-house. 

The fourth wave is the one that really excites me — the wave of things we haven’t yet conceived of. I’d love to be able to tell you what that will be all about, but of course I can’t. It would be like someone telling you in 1988 about Google Maps, Wikipedia, ChatGPT, and Spotify.

The cost of developing software is about to drop through the floor, causing the demand for software to shoot through the roof. Software has no real physical limitations, like bridges do — the only limitation is our imaginations, and that has proven to be boundless.  

Asana has launched an AI personal assistant that can track various data sources to alerts users when a work project runs into problems and recommends next actions.

It’s one of a range of product announcements made Thursday at the company’s Work Innovation Summit in London, including updates to its existing AI teammates product. These follow Asana’s recent acquisition of AI workflow automation software vendor StackAI for $75 million.

Asana Dash is described as an “AI chief of staff” that can help users stay up to date on work projects by accessing information in Asana as well as across email, calendar and team messaging apps, said Arnab Bose, Asana’s chief product officer. “Keeping people in their ‘zone of genius’ and hooking up all of these unstructured signals to the structure of Asana — that’s what Dash does best,” said Bose.

The AI assistant can access the same Asana project information as the user, and can flag when problems occur that could push a project off-track. Asana Dash can then act to address problems, such as posting messages within Asana on behalf of the user or directing an AI teammate to take action. (Asana Dash will ask the user before making any changes.)

“Asana is building on recent acquisitions, and earlier investment in a graph database focused on human connections — the Asana Work Graph — and its position within a well-integrated flow of work to deliver to each worker an executive assistant rooted in the context of their job,” said Wayne Kurtzman, IDC research vice president.    

The Asana Dash personal assistant is enabled by an expanded Asana work graph — the data model related to work carried out by teams in the application. Asana has in the past been more focused on tasks, projects, portfolios, and goals, said Bose, but the work graph now includes new sources of data, linking to employee calendars and accessing meeting transcripts, for instance, alongside other documents and databases.

There are also updates to the AI teammates feature — collaborative AI agents that multiple human coworkers can interact with — which are now more powerful, said Bose. This includes additional skills and integrations with third-party apps such as Gmail, Slack, Outlook, Figma, and Canva.

As for the StackAI acquisition, Bose said it allows Asana to extend the reach of AI agents into a variety of business apps more easily and reliably, building ] on Asana’s “system of action” function. The latter tracks work carried out across an organization, he said, and can automate the complex processes that make up many enterprise workflows. 

“If you look at StackAI’s website, the thing that they are really, really great at is building these complex, multi-step processes,” said Bose. The aim is to combine StackAI’s agent builder with integration expertise agents already available in Asana. 

“So, the idea is when an AI teammate or Dash recommends the next best action, they will be able to choose downstream actions based on the portfolio of approved workflows that you’ve built out in StackAI.”

Overall, the announcements help Asana provide a platform that combines agents and workflow automation with AI assistance that aids humans to work more effectively, said Bose.

“Our terminology for this is a ‘human-agent operating system,’ because automation, I feel, is a little reductive in the sense that there are some things that are fully automated, but a lot that you’d want a human being and an AI agent to coordinate on and align on,” he said.

Asana did not immediately respond to a request for pricing and availability details for Asana Dash.

Microsoft has developed a new AI agent that can run autonomously around the clock to complete tasks across Microsoft 365 applications.

Microsoft Scout, unveiled at the company’s Build event Tuesday, is a new type of always-on agent based on the OpenClaw agent framework that Microsoft calls “autopilots.”

These act on a user’s behalf with their own governed Entra identity, Omar Shahine, corporate vice president at Microsoft, said in a blog post.

“Autopilots stay active in the background, understand how work gets done across your apps and systems, and take action without needing to be prompted each time,” said Shahine, a Microsoft veteran who recently announced he is leading a new team to bring OpenClaw-based personal assistants to Microsoft 365 apps.

Microsoft Scout connects to apps such as Teams, Outlook, OneDrive, and SharePoint, and accesses data from chat, email, calendar, and contacts. Accessed via Teams, it can also interact with a user’s browser and with external apps via model context protocol (MCP). The tool functions across cloud, desktop, and the web.

Shahine said Scout can reduce mundane tasks that office workers face, such as coordinating and scheduling meeting times with colleagues, or blocking times in a user’s calendar based on upcoming work commitments. “It can also spot risks, like stalled decisions, so you can address them before they become blockers,” he said.

It’s available as an “experimental release” to customers of the company’s Frontier program, Microsoft said, and will require Intune policy configuration and “opt-in attestation.”

Scout is the latest in a range of agentic tools available in Microsoft 365 apps, including Agent Mode, where users can interact with Microsoft 365 Copilot inside apps such as Word and Excel to create content, and Copilot Cowork — Microsoft’s version of Anthropic’s Claude Cowork agent that can complete tasks independently.

Despite the company’s big AI push, Microsoft has struggled to convince businesses that Microsoft 365 Copilot is worth the additional cost; it’s advertised at $30 per user each month for large businesses. Around 3% of Microsoft 365 customers pay for the add-on subscription, the company said in January, with 15 million paid users. (Microsoft announced last month that that figure has now risen to 20 million.)

It’s not clear whether Scout will be included in Microsoft 365 Copilot subscriptions or charged separately. Microsoft did not immediately provide additional details about pricing.

The launch follows Google’s recent announcement of Spark, an autonomous agent that runs within the Google Workspace application suite. Spark can also be considered a response to the launch of OpenClaw last year, initially under the name “Clawdbot.”

OpenClaw has drawn scrutiny due to apparent security flaws, but Microsoft promises Scout is built with “enterprise-grade security and controls, so it can be trusted in your organization from day one.”

For organizations that have already deployed Microsoft 365 Copilot, Scout doesn’t introduce entirely new data risks, said Jeff Pollard, vice president and principal analyst at Forrester. But it “amplifies whatever data governance problems already exist. The difference this time: instead of surfacing sensitive data to users, it can potentially act on it.

“That makes it an active risk in terms of day to day operations,” Pollard said.

Potential security concerns echo those for AI agents and are exacerbated with personal agents such as Scout: amplified data exposure (since agents can interact with data and use tools autonomously); agent manipulation or prompt injection; unexpected actions, such as using tools or acting in ways that aren’t supposed to be allowed; and observability gaps related to understanding user and agent intent and the explainability of actions.

“However, these tools exist because they make AI far more useful for individuals, so security leaders can’t draw a line in the sand and say “no.” They have to adapt and figure out how to secure them,” said Pollard.

As with most new workplace technologies, Pollard expects adoption to start with “power users” who design and develop the use cases for the agent that can then expand more widely across users.

He warned that the accuracy of tools such as Microsoft Scout can fall short of user expectations. “LLM agents still struggle with goal alignment, multi-step reasoning drifts, and tool misuse,” he said. “Users aren’t always great at explaining what they want and LLM agents aren’t always great at providing what was requested. That’s a continuing problem.”

Enterprise IT leaders have always struggled with AI pricing, especially the need to pay for AI in a way that delivers ROI. But the typical IT exec may not be right person to decide how a company uses AI — and how it tries to deliver ROI — because so many line-of-business workers and partners are now experimenting with the technology on their own.

And if IT leaders don’t have a grip on how they want to use AI over the next year or two, it’s impossible to figure out how they want to pay for it. They likely hate the current method of paying per token. And other options, such as SAP’s push to charge per AI task completed, aren’t any better. 

To use a sales analogy, IT doesn’t want to pay a lot of money for leads, because there’s no way to know if those leads will generate any revenue — let alone how much. What IT leaders want is the tech equivalent of paying commission, where they only pay when a lead converts into a paying customer. And even then, they only pay a percentage of the final sale. That guarantees ROI for the enterprise.

The problem: no AI vendor would ever go for it because that approach puts too much risk on them. 

Finding a pricing model that works for both enterprise IT and AI vendors is all but impossible as long as IT is trying to deliver ROI.

Irfan Khan, president of SAP Data & Analytics, said the problem is challenging for both sides. “Everyone is scrambling to justify their investments,” and “the day one cost is not necessarily the day one value,” he said.

The problem is one of sequence. Pricing has to be negotiated and locked in long before a project starts. But with technology as new and experimental as agentic AI, there’s almost no solid information about what benefits it will (or will not) actually deliver. 

Beyond that, generative AI (genAI) and agentic AI systems might well deliver benefits that are harder to jot down in a spreadsheet. Let’s say the CFO wants to see a sharp rise in order fulfillment. But what if AI “manages to fulfill those orders more efficiently,” Khan said. “And what are the likely ripple effects of bringing more efficiencies into the process?”

Justin Greis, CEO of consulting firm Acceligence, frames the AI pricing disconnect in terms of market economics:

“The market is trying to force-fit AI into infrastructure-era pricing models, when AI is fundamentally closer to labor augmentation and business process transformation than compute consumption,” Greis said. “The core disconnect is: Enterprise IT buyers want pricing aligned to realized business value. AI vendors want pricing aligned to resource consumption and platform utilization. Those are very different economic models. 

“Token pricing is attractive to vendors because it is measurable, scalable, and predictable. But from the enterprise perspective, tokens are almost meaningless as a business metric. Nobody on the CFO side cares how many tokens were consumed if the process improvement never materialized.”

The competing pricing strategies overwhelmingly rely on just two factors: what delivers the most profit and which is the easiest to execute. Given human nature, the latter is usually the path most often taken.

It’s like one of my favorite jokes. A guy is heading to his car when he sees a man with a flashlight intently looking at the ground right next to a streetlight pole. 

“Can I help you? Are you looking for something?” the guy asks.

“Yes, I lost my car keys.”

“Silly question, but where do you last remember having them?”

“I was standing over there in that dark alley up the street. A cat screeched and I dropped my keys.”

“Wait a second — if you lost your keys over there, why are you looking here?”

“The light’s better over here.”

The lesson: taking the easy route usually beats realizing the actual objective.

Greis argued that not only would it be hard to persuade AI vendors to accept ROI pricing, but if they did  somehow agree, the unintended results could prove disastrous. 

“AI vendors cannot realistically absorb unlimited downstream business risk tied to variables they don’t control — poor internal adoption, broken processes, bad data, organizational politics, weak change management, or unclear KPIs. But the moment vendors are compensated primarily on outcomes, you create strong incentives for increasingly autonomous optimization behavior. That sounds great until organizations realize that AI systems may pursue the metric rather than the intent behind the metric,” Greis said. 

“We’ve already seen versions of this in recommendation engines, ad targeting systems, and engagement algorithms. The system learns to maximize the measurable outcome even if the methods become operationally risky, ethically questionable, reputationally damaging, or strategically misaligned. In enterprise environments, that could become dangerous very quickly. An AI system incentivized around reducing service costs might aggressively deflect legitimate customer issues. A model rewarded for sales conversion could push manipulative messaging or optimize for short-term wins at the expense of customer trust. A procurement optimization engine might lower costs while quietly increasing supplier concentration risk or degrading operational resilience.

“The more autonomous these systems become, the harder it is to separate ‘successful outcome’ from ‘acceptable behavior.’”

The best way to resolve this is potentially the most difficult. Every AI project must be approved by an AI committee whose members must ask the hard questions. What are you hoping to accomplish? If it works, specify and quantify your best-case scenario benefits. What are the most likely ways it could fail? What are the costs and disruptions most likely to happen if it fails in that way? Quantify those. 

The committee should have at least a couple of members who know exactly what these models can and cannot do to serve as a reality check. 

Next, require the LOB chief, or whoever the most senior exec involved in the project is, to share in the pain. Tie gains or losses to executive bonuses. Give those execs a reason to make sure their people are honestly and creatively thinking the project all of the way through. 

Only once that happens can a CIO know how to negotiate a fair and reasonable AI pricing deal.

It’s hard for people to tell the difference between AI-generated advertising and writing. So why do they respond better to the human-made stuff?

AI vs. Mad Men

Ipsos, along with faculty members from Syracuse University’s S.I. Newhouse School of Public Communications, just published a unique advertising study. They took 20 real ads from major brands, including Cheerios, Chewy, Febreze, Fiat, H&M, Old Navy, Herbal Essences, Ray-Ban Meta, TurboTax and Visa. They fed the same creative briefs used by the human ad creatives into Google Gemini, then used OpenAI’s Sora to generate fully AI-produced counterparts with no human intervention. 

They showed the ads to 3,000 consumers. Only 25% of AI ad viewers were at least somewhat confident the spot was AI-made, and 40% of all viewers were uncertain either way — suggesting the public isn’t great at spotting ads that are AI generated. 

But here’s the interesting part: While most people didn’t register that ads were AI-generated, they also didn’t respond to them like they did with human-generated ads. They consistently rated human-made work as more eye-catching and more imaginative. 

In other words, people assumed AI ads were made by people, but didn’t particularly like them compared to human-generated ads. And that means human-generated ads performed much better. 

Ads made by people without AI were 14% stronger on short-term sales impact and 17% stronger on long-term brand health.

To me, the data here suggests that while people can’t easily discern the difference between AI- and human-generated content, the AI stuff hits wrong on a subconscious level. And I think that’s happening with AI social posts, AI blog posts and AI slop in general. 

In fact, I’ve noticed it strongly in my own response to AI-generated content. It often looks perfect but bothers me for reasons that aren’t immediately obvious. 

The researchers explained AI’s inability to match human ad creativity by pointing out that AI draws from what already exists, while great advertising breaks new ground. AI can replicate the conventions of advertising, but it can’t transcend them, make a creative leap or engender emotion like people can. 

A broad range of research beyond the Ipsos study suggests that skillful people working with AI tools will always outperform AI alone, and often outperform people not using AI tools. Ipsos’ advice? Ad agencies should keep people at the center of brand storytelling and emotive assets. 

Can AI write right?

Another recent study looked at written web content and compared how human-written articles “performed” on search engines compared to AI-generated content. Semrush analyzed 42,000 blog pages across 20,000 keywords, ran every single one through GPTZero’s AI detector, and cross-referenced the results with actual Google Search results. It also surveyed 224 search-engine optimization (SEO) professionals about their AI habits and beliefs.

They found a disconcerting disconnect between what SEO people believe and what is actually true. Some 72% of SEO professionals who use AI content say it performs just as well or better than human-written content in search rankings. But it turns out that human-generated posts strongly outperform AI-generated. 

Content classified as purely AI-generated appeared in the top spot in search result just 9% of the time. Content classified as human-written was there 80% of the time.” That’s a roughly 8-to-1 advantage. (Note that the coveted top link in search results typically gets around one-third of the clicks.)

For lower page-one positions — from the fifth position down (which get relatively few clicks) — AI- and human-generated posts perform more similarly. (The researchers also found that when people write posts with a little help from AI, their posts rank better much than AI-only content.)

Those Semrush results are consistent with previous research. 

• NP Digital conducted an oft-cited study two years ago that found that human-written content ranked higher 94.12% of the time on Google than AI content. 
• A Graphite/Common Crawl analysis found that 86% of articles ranking high on Google Search are human-written (only 14% AI-generated), and ChatGPT and Perplexity cite human-written articles 82% of the time (only 18% AI). 
• On LinkedIn, more than half of site’s long-form content in 2025 was classified as “Likely AI” by Originality.ai. Engagement on verified human content was 61% higher than the AI-marked posts. 

Note that engagement performance varied by industry; that 61% result is an aggregate average across all industries. Ironically, in the category of “Leadership & Inspiration,” AI posts outperformed human posts by 75%. 

The absurd lesson here: If you want to be a thought leader on LinkedIn, don’t lead with your own thoughts. 

Quantity vs. quality

What all this research boils down to is that human-generated content (with or without help from AI) attracts far more traffic and higher engagement than AI-generated content. AI content is essentially invisible in high-value channels and while it might be high in quantity, it’s low in quality where it really matters — with reach and influence. 

As with the ad creative study by Ipsos, the conclusion of all this research is the same: People (and search engines) respond much better to creative content produced by people compared with AI-generated content. 

In short, AI is great at “flooding the zone” at high speed and low cost — and there’s a ton of AI-generated content out there. A quick check reveals that: 

• More than half of all written content on websites is now AI-written.
• Almost half of all music uploaded is now AI-generated.
• Nearly one-quarter of all videos uploaded are AI-generated or manipulated.
• Around 40% of all podcast episode uploads are AI-generated.
• More than 70% of all images uploaded to social media may be AI-generated or manipulated.
• And wll over half of all social posts are AI-generated

The specific numbers are my best estimates, and they’re changing fast each month. The takeaway is that AI-generated content is exploding in volume. 

But it isn’t reaching people the way human-generated content does. Take podcasts, for example. While roughly 40% of new podcast episode uploads are AI-generated, that 40% captures less than 1% of the listening hours. Of the top 100 podcasts, zero are AI-generated.

A clear picture is emerging about the use of AI for content generation. AI is great for churning out a lot of content at low cost. It can be good for some kinds of content — if a skillful person directs it. And AI can be a helpful tool for content creators. 

But when it comes to direct comparisons between people and AI, it’s clear that the winning content — the stuff with the best “performance” on search, best reception by people and the most engaging — is always human-generated. 

T

All of the big AI models violate EU rules on AI and data protection to varying degrees, according to the nonprofit research foundation Aithos.

Aithos tested the models using its own tool, LARA (Legal Assessment for Real-world Agents), which simulates real-world situations where AI assistants may find themselves in legally questionable situations, according to The Register. The tests measure compliance with the GDPR and the EU’s AI Regulation, among other things and found the models collected user data without proper consent, attempted to manipulate vulnerable individuals, or created psychological profiles of users.

According to the results, all major language models failed to meet EU legal requirements; some violated the rules in up to 93% of cases. The best result was achieved by the Anthropic model Claude Opus 4.7, which was in compliance about 54% of the time.

Aithos warned that responsibility for the shortcomings does not lie solely with AI companies. Companies that build their own AI agents on top of these models could also be held legally liable.

The rise of generative AI (genAI) technology has prompted a growing debate about the future of software-as-a-service (SaaS) business models. 

Some of the fears are overblown: enterprises are unlikely to vibe-code their own applications to replace their SaaS suppliers anytime soon, while software vendors have yet to see per-seat sales fall off due to mass automation of white-collar jobs. (In fact, some now predict the opposite will happen.)

At the same time, AI has the potential to change the way work is carried out, with AI agents empowered to interact with software applications on behalf of users. For software vendors, that could mean a future where applications are accessed less through traditional user interfaces as AI agents connect via APIs. 

It’s an inevitable shift, says Box CEO Aaron Levie, and one that requires software vendors to adapt their existing products and business models to prepare for agent workflows. 

Computerworld recently spoke with Levie about how Box — and other SaaS vendors — can adapt as agentic AI threatens to upend existing business models. (This interview has been edited for clarity.)

Discussion about a “SaaS-pocalypse” has died down recently, and software stocks have rebounded. At the same time, it seems clear the adoption of AI agents could change how workers interact with software. How can companies like Box adapt to this new environment? If AI increasingly becomes the interface users interact with, where does the long-term value lie? “People are realizing that you’re not going to rebuild a lot of the systems that people were kind of claiming you would [with vibe-coding]; it just doesn’t make sense. So, that part is sort of dissipating. However, headless software and the ability to use your systems via AI is obviously going to happen, there’s no question. 

“So, I think the conversation is shifting from ‘AI disrupts software’ to ‘AI is going to be the biggest consumer and user of software going forward.’ And for that, the main thing is: can you have a business model that allows you to actually monetize the consumption of those agents using your underlying tools? We’re fortunately built for that; we’ve had an API business model basically forever, so we’re well prepared.

“There’ll be some companies that have to pivot a little bit more significantly over time — there’s no question that will happen in a bunch of organizations. We’re big believers that AI will be the biggest user and interface for the future of software.”

How important is it for Box to retain that interaction with human workers, rather than becoming more of the underlying layer AI agents interact with? “I would say that we’re totally comfortable with that shift. When you have AI agents, you still need a place to be able to secure the data — you need to protect it, you need to govern it, you need to make sure you know who’s accessing it. None of that changes in the world of AI. In fact, if anything, it actually increases. 

“We don’t really care if it’s an agent using the data, an application using the data, a person using the data — we want to be the best content management system that connects your information to all of those applications.”

How does that perspective feed into your product development and roadmap “It basically means that we need to be a headless platform. That means customers need to be able to access their data via MCP inside of ChatGPT, inside of Claude, inside of all these systems. It means that we care as much about our APIs and access to those APIs as we now do our user experience. We have to make sure that both of those environments are as simple and clean as possible, and as usable as possible.

“It’s basically as if there’s another constituent now in our ecosystem that we have to go and pay attention to.

“We need to be the best place to manage your content, and then wherever you want to work with it from, we’re totally fine. So, if you want to work with your files from your desktop, from Claude Cowork, from ChatGPT Codex — we just want to make sure we are universally accessible across every single place that people want to work with their data.”

Could that mean changes around how you price access to your software? Do you expect a shift to usage-based pricing? “Not as much as is probably being talked about online, because seats still make sense for the employee and the end user. Even when an agent is doing work on your data, it’s still you invoking that agent. It sort of makes sense that the seat is still attached to the underlying end user employee, even though an agent is going to be doing work on your data.

“We think the seat model will be quite durable over time. What this does is just add another business model, where you have agent-only interactions; those will be primarily coming through the API, and then that will be a consumption model.”

What are your thoughts on outcome-based pricing? Is that something you look at? “We do one thing that’s close to that — we have the Box Agent that does things like data extraction. It extracts your data and we charge based on the number of pages that you want to extract data from. So there are some things that approximate outcomes, but not at the level of resolving a customer service ticket or something like that, that maybe has been talked about. We’re probably going to be more aligned to…the amount of compute that that is used.”

What are your conversations with customers around moving to a usage-based model? A lot of organizations are used to fixed monthly subscriptions — can metered AI agents become problematic? “I think it definitely can be. This is sort of a common tension in general.… We saw this with cloud computing, for instance. The difference with cloud computing is that cloud was relatively centralized, versus the use of AI and tokens are much more diffuse. That’s a big difference that companies have to think about.

“There’s always this tension: you can pre-buy and have a subscription, but then you might be overpaying for periods where you’re not using it as much. Or you can only pay for what you use, in which case you might have some volatility in the pricing of what happens.”

How are customers progressing in adopting AI agents — particularly, the move from pilot projects to production. What are some of the biggest barriers to wider deployment of agents? “We’re very much moving from coding agents to the rest of knowledge work: this is the jump that’s starting to occur. In that, one of the big questions and challenges is how companies get agents the right context and information to work with — how do they enable agents with the right level of constraints in their organization from a security and compliance standpoint? This is our kind of reason to exist, and what we’re helping our customers on.

“Overall, it’s just a transformational moment in the enterprise. Every customer that I talk to, every dinner that we have with customers, every CIO meeting I’m in, every CEO meeting I’m in, it’s all about agents.

“Agents have thrown the whole world into this kind of dynamic period of, ‘What does the shape of your organization look like? What’s the future of a manager versus an individual contributor? What are the workflows that you can go and execute on?’ There are so many different ways that this is starting to change.”

You were part of another major industry transition with the adoption of cloud computing. Are there similarities you see or major differences that customers can learn from? “The big difference between [them] is that, with cloud, you could centralize the deployment of and management of.Cloud really only affected 3% of your organization that was moving from the data center to the cloud, and then every employee got better products and experience as a result of that. The change was really kind of fairly concentrated. AI affects every single employee in the company. It’s a radically different type of transformation of what work looks like.

“There are only so many analogies you can make to cloud before quickly you realize, no, this is actually a different transformation. Maybe it’s even closer to the PC, in the sense of every single worker has to change what they’re doing to be productive. It’s not a technology delivery shift, it’s a fundamental reworking of every workflow in the enterprise. And so that’s I think what most companies are going through right now.”