GitHub is expanding Copilot beyond the IDE with a new desktop application and a new collaborative work surface called canvas as part of its broader efforts to pitch the AI-assisted coding tool as the control center for agent-native software development.

The desktop application announced at Microsoft’s annual Build conference this week is designed to give developers a dedicated environment for working with AI agents throughout the software development lifecycle, rather than limiting those interactions to code-generation tasks inside an editor, the company wrote in a blog post.

The application includes a collaborative workspace called canvas where developers can brainstorm ideas, refine requirements, generate plans, and iterate on projects alongside AI, it said.

It also has new Agent Merge and code review features that enable developers to automate Copilot to combine tasks of different agents to complete a specific goal or conduct autonomous code reviews according to set standards, it said.

These new features could reduce context switching, increase engineering efficiency, and accelerate delivery cycles, said Phil Fersht, CEO of HFS Research.

Shift in pricing justified?

However, despite the new features, much of the conversation among developers in recent weeks has centered on a different topic: this week’s shift to a usage-based billing model for GitHub Copilot that it announced in April.

The changes were met with a wave of criticism on the GitHub community forum, where some users accused the company of a “bait and switch,” while others requested refunds or announced plans to cancel their subscriptions.

For analysts, though, the pricing change was, at least from GitHub’s point of view, necessary and justified.

“The pricing change is justified by where GitHub is going, not by where the product is today. Running multiple agents in parallel with sandboxes, canvas reviews, and Agent Merge looping through CI is closer to cloud compute than an IDE plugin, and you cannot price compute on a flat seat fee. So metered billing is the right call structurally,” said Advait Patel, a senior reliability engineer at Broadcom.

Fersht said developers and CIOs need to focus on Copilot’s metamorphosis from being a coding assistant into a platform for orchestrating software-development agents and workflows.

“That changes the ROI conversation significantly. CIOs should stop thinking about Copilot as a seat-license productivity tool and instead evaluate it as an AI-powered software delivery platform,” he said. “The metrics shift from ‘lines of code generated’ to broader operational outcomes such as release velocity, code quality, defect reduction and engineering efficiency.”

GitHub is not the first company offering vibe-coding tools to rethink its pricing strategy as AI agents proliferate across enterprises and evolve to take on more complex software-development tasks that are computationally more intensive.

Over the past year, platforms such as Claude Code, Replit, Cursor, and Kiro have repeatedly adjusted their pricing structures to account for mounting infrastructure costs, limited GPU availability, and the expense of serving increasingly sophisticated AI models and agents, despite furor among their users.

For CIOs, the challenge is proving ROI

That common pressure across AI coding vendors is why Amit Chandak, chief analytics officer at IT consulting firm Kanerika, thinks developers and CIOs should focus less on GitHub’s pricing mechanics and more on whether these increasingly capable tools are delivering measurable business value.

“The new features that GitHub announced can act as productivity multipliers as well as features that increase consumption without delivering proportional business value. Without productivity baselines established before adoption, enterprises risk absorbing higher costs with no clear line back to delivered value,” Chandak said.

For Fersht, developers and CIOs will need to focus on governance, monitoring and financial controls as the pricing model is changing.

“The governance challenge is very real. Autonomous agents can continuously reason, test, revise and interact with multiple systems in ways that create far less predictable consumption patterns than traditional SaaS tools,” he said.

Patel, however, advised users and decision-makers to be more skeptical, especially since the new features are currently in technical preview.

“Customers are being asked to pay variable rates now for value that has not been validated in production. Do not assume new capabilities justify higher spend,” he said. “Instead, run a 90 day pilot, measure PRs merged per dollar before and after, and let the data decide. If the ratio improves, the pricing is fair. If it does not, you are paying for promise, not delivery,” Patel added.

Microsoft has identified seven new failure modes in agentic AI systems, in addition to those it identified last year in its first Taxonomy of Failure Modes in Agentic AI Systems.

Four things contributed to the growing list of ways agentic AI can go wrong: the speed at which the technology went mainstream, the growing maturity of the Model Context Protocol (MCP) ecosystem, the rise of computer-use agents, and finally the gathering of more empirical evidence as researchers obtained more real-life findings.

The seven new failure modes it has identified are:

• Agentic Supply Chain Compromise —agent behavior can be affected by natural language rather than malicious code;
• Goal Hijacking — adversarial instructions appear aligned with legitimate task completion, while silently redirecting the agent’s terminal goal;
• Inter-Agent Trust Escalation —a compromised agent asserts false identity or inflates claimed permissions to an orchestrator;
• Computer Use Agent (CUA) Visual Attack — agents operating through graphical interfaces can be manipulated through content that carries adversarial instructions for the agent;
• Session Context Contamination —an adversary introduces data that biases the agent’s reasoning in subsequent steps, without triggering safety controls at any individual step;
• MCP / Plugin Abuse — an update on the original taxonomy’s coverage of function compromise around MCP and plugin protocols, specifically attack surfaces specific to those protocols;
• Capability / Architecture Disclosure —an agent reveals internal implementation details such as tool names and schemas, system-prompt structure, memory interfaces, or consent/human-in-the-loop trigger logic.

Microsoft advises security teams using these definitions to influence their planning to inventory their your supply chain, generating a software bill of materials (SBOM) for every deployed agent, to verify agent identity cryptographically, not positionally, by issuing attestable credentials at provisioning, to add the seven new failure modes to their red-team coverage matrix, and to audit the human-in-the-loop user experience as a security control.

Projection, much? Microsoft’s head of AI has accused a rival’s AI service of being too pricey, just as the introduction of usage-based pricing for GitHub Copilot begins to hit developers using its own services.

“Anthropic is extremely expensive and I think many people are urgently looking for alternatives,” Mustafa Suleyman, CEO of Microsoft AI, told Bloomberg News.

The spotlight is on the cost of AI services at the moment, with so many different parts of the business using the technology while at the same time many businesses are finding it hard to report any meaningful ROI.

This week, Microsoft at its annual Build conference looked to fight back against this when it announced seven new AI models, emphasizing the lower cost. The company hopes that cheaper AI models will mean more enterprises find that AI projects are viable. In 2025, Gartner reported that many such endeavors would be cancelled by 2027: cheaper implementations could be the way forward.

Microsoft clearly sees its own AI developer tools as a better deal than those of Anthropic: Last month it was reported that Microsoft would cancel most of its Claude Code licenses at the end of the half-year period in June, moving engineers to its own CoPilot tool.

This article first appeared on CIO.

I’ve seen a lot of promising AI prototypes fall apart after launch. And it’s rarely because the model was bad. More often, the problem starts much earlier; teams treat the data layer like something they can figure out later.

They’ll spend weeks fine-tuning prompts, testing models and debating evaluation scores, then throw together the retrieval pipeline over a weekend and move on. At first, everything looks great in demos. But a few months later, the system gives outdated answers; the embeddings no longer match the source documents, and nobody fully understands what changed.

What started as an impressive prototype slowly becomes difficult to trust in production. The teams that avoid this tend to realize one thing early: Embedding pipelines are fundamentally a data engineering problem, not an entirely new AI discipline. It’s still ETL (Extract, Load, Transform) at its core, but with embeddings and vector stores as the destination instead of a warehouse.

Once you start looking at it that way, a lot of things become clearer. Problems like versioning, data freshness, lineage and retries stop feeling “AI-specific.” They’re data infrastructure problems we’ve already spent years learning how to solve.

Why do we need embedding pipelines?

Large language models are extraordinary reasoners trapped inside a time capsule. When training ends, the model’s knowledge is sealed. It does not know what your team decided in last quarter’s strategy review. It has never read the support ticket that came in this morning. It cannot find the clause buried on page 47 of your master service agreement. It’s brilliant, but blind to anything specific to your organization.

Layer on top of that a hard context window limit, a ceiling on how much text the model can process in a single interaction, and you have a clear problem: you cannot just hand it everything you own.

The answer the industry converged on is retrieval-augmented generation, or RAG. Instead of stuffing everything into the context window, you build a retrieval layer that fetches only the most relevant pieces of information at the moment a question is asked and passes just those to the model. That retrieval layer is powered by a vector database, and the process that populates it, which is taking raw documents and transforming them into searchable semantic representations, is what I mean when I say embedding pipeline.

Every team building an internal AI assistant, a smarter enterprise search tool, an automated customer support agent or a document Q&A system needs one. The question is not whether to build it. The question is whether you build it like a prototype or like infrastructure.

How an embedding pipeline works

An embedding pipeline has three stages: ingestion, chunking and indexing. Here is what each one means and how I relate them to a typical ETL process.

Ingestion is extraction

Getting your raw content, PDFs, wiki pages, Word documents, database records, transcripts, out of wherever it lives and into the pipeline. This is ETL’s extract stage, almost verbatim.

I see teams cut corners here more than anywhere else, and it’s often where production systems first start to fail. A document gets updated, but the pipeline doesn’t pick it up. A file gets deleted, but its chunks remain in the index, still returning outdated answers months later. And because there’s no obvious error, no one reports it.

The fix is Change Data Capture (CDC). This maintains a manifest of every document you have ingested, a content hash and a timestamp. On each run, we compare sources against that manifest, re-ingest what changed, delete what is gone and treat your document the way you would treat any source table you are syncing incrementally.

Chunking is transformation

Once your documents are in the pipeline, you cannot embed them whole. A 30-page technical report is too long to represent meaningfully as a single vector, and even if it were not, returning the entire report in response to a narrow question would bury the model in irrelevant context.

Chunking is the process of breaking each document into smaller pieces that are focused enough to embed accurately and retrieve precisely. This is ETL’s transform stage, and it deserves the same level of design discipline.

The most common mistake I see is treating chunk size as a default configuration option rather than a product decision. It is not. The right chunk size depends entirely on the nature of your content and the nature of your queries. Dense technical documentation needs finer granularity than a collection of FAQs. A legal contract with clause-level logic needs different treatment than a set of onboarding emails. What works for one document will actively degrade retrieval quality on another.

My strong preference is to treat your chunking configuration as a versioned pipeline parameter, not hardcoded logic. When you change it, and trust me, you will. You need to re-chunk in a controlled, observable way, compare retrieval quality before and after, and roll back if it degrades. That is just good transform-layer hygiene. It is no different from versioning a data cleaning rule or a field mapping.

Indexing is the load

The final stage is where chunked text gets converted into vectors and stored in a vector database where it can be searched by semantic similarity rather than keyword match.

In the conversion step, embedding is handled by a model specifically trained to turn text into dense numerical representations that encode meaning. Two chunks expressing the same idea in different words will produce vectors that cluster close together in that mathematical space. Two chunks discussing entirely different topics will sit far apart. When a user asks a question, the system embeds that question the same way, finds the chunks whose vectors are nearest, and returns them as context for the model to reason over.

That is a genuinely new capability. But the discipline around indexing is not. One data engineering principle I keep coming back to is versioning.

In embedding pipelines, every chunk in your index should be tagged with the embedding model name and version used to generate it, this is non-negotiable. Embedding models evolve, and vectors produced by different versions are not comparable in a reliable way. You cannot safely search across them as if they are interchangeable.

This exact problem shows up when teams upgrade embedding models mid-pipeline without a proper migration plan. You end up mixing vectors from different generations in the same index, and retrieval starts to degrade in ways that are hard to detect. The system just quietly begins returning subtly wrong answers.

I treat an embedding model upgrade the same way I treat a schema migration: Plan it explicitly, execute it in full and validate retrieval quality on a representative query set. The stakes are the same as any breaking change to your data model.

Pipeline observability is not optional

Once an embedding pipeline is running in production, the question shifts from “did it run” to “did it run correctly.” That distinction matters more here than in most pipelines, because failures are rarely loud because the index looks fine, queries return without errors and the system quietly surfaces wrong answers until someone notices the AI has stopped being useful.

The same observability discipline that makes any data pipeline trustworthy applies directly here. Once you treat embedding pipelines as production systems, you stop thinking in isolated steps and start thinking in signals. For example, chunk counts per document become a simple but powerful health check, a sudden drop is usually not a model issue, but a sign of broken ingestion or upstream parsing failures.

You also need a “golden set” of queries with known-good outputs. This runs after every pipeline change, much like data quality checks after a transformation. This is how you catch regressions that don’t show up as explicit failures.

On top of that, you can track lineage: Which embedding model version produced which chunks, and when each document was last ingested. That makes it possible to trace retrieval issues back to specific changes instead of guessing.

And finally, freshness becomes a first-class signal. If documents start going stale beyond an acceptable threshold, that should surface in monitoring long before users experience degraded results.

The metric that ties it all together is retrieval quality over time. Treat it like any other pipeline SLA, measured, tracked and owned.

Summary

Embedding pipelines definitely come with a lot of new language, new tools and a genuinely different capability in the semantic layer. But the funny thing is, the principles that actually make them reliable in production are not new at all.

We have versioning, freshness, quality checks and monitoring. These are problems data engineering has already spent years solving.

The real work is taking that same discipline and applying it to a pipeline that just happens to output vectors instead of rows in a table. Once you start seeing it that way, a lot of the chaos around AI systems becomes much easier to reason about.

That’s the difference between building a cool AI demo and building something people can actually depend on. One is a prototype, whereas the other is infrastructure.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

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.

For enterprises embracing AI-assisted development, writing code is no longer the hardest part. Operationalizing it is. Microsoft is targeting that challenge with Rayfin, a new open-source SDK and CLI unveiled at Build 2026.

“Rayfin turns backend development into a code-first workflow. Developers and coding agents can define a full application backend in code, including databases, business logic, APIs, identity, and access policies, and deploy it to Microsoft Fabric for a fully managed, enterprise-grade backend,” Shireesh Thota, CVP of databases at Microsoft, wrote in a blog post.

In effect, Thota added, this approach cuts down the manual integration work and time typically required to connect backend systems once an application front-end is built.

Explaining further, how Rayfin works, the top executive said that developers or coding agents working on their behalf define the entire backend using the SDK, and then that definition is deployed directly to Fabric using the CLI.

Governance, not productivity, may be the bigger draw

According to independent consultant David Linthicum, Rayfin increases developer productivity, reduces integration overhead, and platform sprawl: “Instead of standing up separate app runtimes, data services, governance layers, and custom integration code, they can push more of that into one managed environment. It also keeps application data closer to the analytics estate.”

However, the rise in developer productivity is just the hook, according to Stewart Bond, research vice president at IDC.

“For CIOs, the more compelling value proposition is governance and operational control. It is governance by default — inherited security, compliance, and access policies from day one — that addresses the risks CIOs most frequently cite when AI-generated code and agent-authored applications enter production environments,” Bon said.

“IDC research indicates that AI data readiness is not owned by a single team but by a coordinated network of stakeholders across all four planes of the enterprise intelligence architecture, and Rayfin’s architecture reflects that by ensuring that application data lands directly in a governed data estate, making it immediately available for reporting, analytics, and AI workloads without additional pipeline work,” Bond added.

For Ashish Chaturvedi, leader of executive research at HFS Research, Rayfin should help CIOs tackle another facet of non-governance: shadow IT.

“Coding agents have democratized app creation. Today, anyone with a prompt and a browser can spin up a working application in minutes. Every one of those ungoverned apps is a potential data silo, a security gap, and a compliance liability waiting to land on someone’s desk. Rayfin is the governed on-ramp,” Chaturvedi said.

Platforms like Rayfin are set to gain traction

Analysts say platforms like Rayfin are becoming increasingly common as enterprises discover that AI applications are difficult to govern and operationalize when data, models, policies, and runtimes are spread across separate systems.

Enterprises moving beyond isolated AI experiments, according to Bond, increasingly need automated governance, real-time processing, and tighter feedback loops between AI systems and enterprise data — capabilities that are harder to deliver when application and data layers remain separate.

More so because the economics, too, becomes harder to argue, Chaturvedi said.

“When apps run inside the data platform, you eliminate data movement costs, reduce governance surface area, and shrink the attack surface. Within three to five years, converged platforms will be the default for new agentic applications,” the analyst added.

However, Stephanie Walter, practice lead of the AI stack at HyperFRAME Research, pointed out that enterprises will not move every application onto one platform.

“The likely future is a hybrid model: some agentic applications will run inside governed data platforms like Fabric, Snowflake, or Databricks, while others will continue to run on general-purpose cloud runtimes. The architectural question will be where the application’s most sensitive data, context, and control plane should live,” Walter said.

Making Fabric the runtime for AI applications

Beyond the immediate benefits around governance and operational control, Walter sees Rayfin as a strategic move in Microsoft’s broader effort to expand Fabric’s role within the enterprise technology stack.

Rayfin’s release, Walter said, is less about a new developer tool and more about Microsoft’s attempt to reposition Fabric as a platform for building and running AI-native applications.

“Rayfin positions Fabric as a runtime environment for a new class of AI-native applications. That is strategically important because the next phase of enterprise AI will not be won only at the model layer. It will be won by the platforms that can turn governed enterprise data into safe, operational applications,” Walter added.

However, she remained skeptical about whether developers will accept Fabric as an application runtime and not just a data platform: “Rayfin lowers the barrier, but Microsoft still has to prove the developer experience is lightweight enough, the deployment model is flexible enough, and the governance benefits are strong enough to justify building inside Fabric rather than around it.”

Microsoft is making Rayfin available in preview, and enterprises can try the service through a 60-day Microsoft Fabric trial. The SDK and CLI-combo can also be accessed via Replit, the company said.

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.

AI governance is an ongoing game of catch-up for enterprises. Model updates and iterations are rolling out at a rapid clip, often making governance frameworks obsolete before they’re battle-tested.

To evolve beyond this paradigm, OpenAI is introducing Active sessions. This new ChatGPT security feature allows users to review and log out of one or more sessions through a simple interface. The feature is now available across all ChatGPT accounts and workspace types, including personal and managed workspaces. Experts call it an important development for the model provider, which currently has 1 billion monthly active users.

Previously, organizations often had limited visibility into where users were logged in, and simply relied on password resets or broad account actions to force re-authentication, noted Ensar Seker, CISO at SOCRadar. “Granular session control is a more efficient and less disruptive approach. From a governance perspective, session transparency improves accountability and supports investigations,” he explained.

A holistic view across session activity

Active sessions allows admins to see known browser and app sessions across ChatGPT, Codex, and API Platform. Specifically, they are able to view device and browser information, approximate location, sign-in date and time, whether a device is trusted, and whether the session is current.

To access the feature, users can go to ‘Settings’ > ‘Security’ > ‘Active sessions.’ They can then log out of specific sessions and remove devices from trusted services. They also have the ability to log out of all sessions (thus ending sessions across devices), however, this action can take up to 30 minutes to complete.

However, OpenAI emphasizes that session details may be “approximate or incomplete,” and that the feature has limits. It does not show or manage connected apps or third-party app sessions, sign-ins through third-party services, Codex CLI sessions, or recently signed-out sessions.

Further, Active sessions cannot be used with accounts linked to an enterprise’s single sign-on (SSO), including security assertion markup language (SAML) and OpenID Connect (OIDC).

Better late than never

While Active sessions is an important security and governance development, experts note that the feature is basic, and was a long time coming.

“The reality of OpenAI offering the ability to end active sessions on ChatGPT by administrators is that it’s something that exists in lots of platforms,” said David Shipley of Beauceron Security. “They should’ve had it sooner, but better late than never.”

From a security standpoint, he noted, OpenAI could do a better job policing ChatGPT to prevent it being used by threat actors to host malware, which is the latest threat to enterprises.

SOCRadar’s Seker also pointed out that this type of visibility and oversight is something that enterprises have expected from SaaS platforms for years. “It allows administrators and users to quickly identify unauthorized access, terminate stale sessions, and reduce the risk of account compromise persisting undetected.”

Iterative upgrades disrupt governance

Last week, OpenAI updated GPT-5.5 Instant in both the ChatGPT app and API to “improve response style and quality,” the company said. It had rolled out GPT-5.5 Instant earlier in May as a successor to GPT‑5.3 Instant, calling it “generally smarter” and prone to fewer hallucinations.

According to OpenAI, the update makes GPT-5.5 Instant “easier to read, more natural in everyday conversations, and better paced in practical help tasks, with fewer overly long or bullet-heavy responses.”

But even with tools like Active sessions, enterprises continue to struggle with governance amidst seemingly continuous iterative model updates. It’s simply not sustainable, said Beauceron’s Shipley: “How do you build an appropriate testing plan with a nondeterministic system?”

SOCRadar’s Seker pointed out that many organizations perform security, compliance, and business validation testing before approving a model for production use. But, “when model behavior changes under the same version family, previously documented assumptions may no longer fully reflect actual performance,” he noted.

“The biggest governance challenge in AI is not model adoption, it’s model change,” Seker said. “Most organizations can evaluate a model once. Far fewer are prepared to continuously evaluate how that model evolves over time.”

This particularly creates challenges for regulated industries where auditability, repeatability, and change management are critical, he said. Even beneficial improvements can introduce governance concerns if organizations are not clearly informed about what changed and when.

Valence Howden, advisory fellow at Info-Tech Research Group, noted that organizations often can’t assess the implications of model iterations against their boundaries, and, worse, are often unaware of them.

While the biggest enterprise challenge was initially tied to which AI model was being used, what that model did, and who owned it, iterative updates can muddy those waters and increase reliance on third party practices and tools that organizations often don’t have the resources for, he noted. 

“Without the ability to opt out [of an update] before it’s incorporated, [enterprises] are basically red-teaming the updates with their clients,” said Howden.

The ongoing game

Security teams today are pushed to their limits because they are expected to manage rapidly evolving models, new features, and changing behaviors, while maintaining compliance, risk management, and business continuity, said SOCRadar’s Seker.

“Governance is difficult because organizations are no longer evaluating a static product,” he said. Rather, they are managing a “continuously evolving service” where capabilities, integrations, and user behaviors can change far faster than can traditional security review cycles.

Info-Tech’s Howden agreed, saying that enterprises’ existing governance practices, especially accountability, are poor, as are their risk practices.

“It’s hard to suddenly become good at things they’re already poor at doing,” he said. “They are also incentivized for speed and innovation, so they ignore governance as a constraint, or don’t want to do it at all.”

How enterprises should respond

Seker advised that, ultimately, organizations should treat AI models as living systems rather than fixed software releases.

Security and governance programs should include continuous validation, monitoring, and periodic re-assessment instead of sole reliance on one-time approval processes, he said. Enterprises should also establish clear vendor change management expectations, including requiring transparency around model updates, behavioral changes, and potential impacts to existing workflows.

“Effective AI governance increasingly depends on visibility into change, not just visibility into risk,” Seker said.

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.  

As enterprises move from AI experimentation to production deployments, one challenge is becoming increasingly apparent: AI systems are only as reliable as the business context they operate in.

Snowflake is attempting to address that problem with Horizon Context, a new set of semantic and metadata-management capabilities, currently in preview, that it unveiled Tuesday at its annual Snowflake Summit conference.

Artin Avanes, head of core data platform at Snowflake, said that the offering, launched as part of Horizon Catalog, the company’s existing data discovery, management and governance suite, collects metadata from across an enterprise’s data estate, enriches it with business definitions, relationships, lineage, and governance information, and makes that context available across AI and analytics systems.

These capabilities, according to Avanes, build on Snowflake’s acquisition last year of Select Star, a metadata management startup known for its integrations with database systems such as PostgreSQL and MySQL, business intelligence tools like Tableau and Power BI, and data pipeline/orchestration tools such as dbt and Airflow.

Reducing operational complexity of agentic workflows

For CIOs, Horizon Context should reduce operational complexity because it will provide a governed map of their organization’s data estate, said Stephanie Walter, practice lead of the AI Stack at HyperFRAME Research.

“The value is not simply cataloging where data lives; it is giving AI systems the metadata, lineage, permissions, and business context needed to retrieve the right data safely,” Walter said.

In fact, according to Robert Kramer, managing partner at KramerERP, the challenge of missing context for analytics and reporting is not new for enterprises.

“Most enterprises were stitching together catalogs, BI semantic layers, governance tools, lineage, access controls, dbt models, security policies, and custom integrations. The issue was not that these pieces did not exist. The issue was that they were fragmented,” he said.

That duct-taping together of different pieces, said Mike Leone, principal analyst at Moor Insights & Strategy, is the actual reason why most teams in an enterprise would end up with slightly different versions of a business metric, such as monthly active users, resulting in AI agents also being inconsistent downstream.

But, said Walter, the stitching together of different catalogs and semantic layers only works for semi-autonomous workflows. “What changed with AI agents is that those systems increasingly need access to context at runtime rather than through documentation and human interpretation,” she said. “Snowflake is trying to pull those pieces closer to the data platform, so context, semantics, access control, and execution are part of the same operating environment”

Automatically maintaining business context for AI agents

To supplement Horizon Context, Snowflake is also adding Semantic Studio, currently in private preview, to help enterprises reduce the effort required to build and maintain business context for agents and agentic workflows.

“Semantic Studio is a core part of the Enrich layer of Horizon Context, providing the AI-assisted workspace where teams define, test, and publish that business logic,” Avanes said.

The Enrich layer itself, which consists of companion capabilities like the Semantic View Autopilot, automatically layers intelligence on data assets, providing insights such as which assets are most trusted, how they connect, what they mean, and how to correctly calculate metrics, Avanes added.

According to Leone, Semantic Studio solves a critical challenge: “It will reduce the burden of SQL-savvy data engineers and let business owners author the shared definitions. That’s where most semantic-layer projects die today.”

For Walter though, there is still a caveat to these offerings.

“While these offerings reduce complexity, they do not remove the work. Someone still has to decide which metrics are authoritative, which data products are trusted, and who owns the business definitions,” she said.

Addressing security and governance concerns

Alongside these updates, Snowflake is also trying to address security concerns around agentic workflows with new capabilities inside Horizon Catalog’s Trust Center.

These capabilities, which are focused on AI Security Posture Management (SPM), include a new agent identity capability that enables enterprises to distinguish between human activity within a session and actions taken by an AI agent operating on a user’s behalf, Avanes said.

“This should provide greater transparency and auditability for agents, while also enabling enterprises to apply existing data access controls, such as dynamic masking and row access policies, on an agent-by-agent basis,” he said.

Another new capability, data exfiltration policies, currently in private preview, will help enterprises prevent unauthorized movement of sensitive data. These policies are part of Horizon Catalog’s broader governance framework, and will allow enterprises to define controls around how data can be accessed, shared, and moved across systems, Avanes said.

For enterprises, Walter noted, these capabilities could help address one of the biggest barriers to deploying AI agents in production: governance.

“Data exfiltration controls, AI Security Posture Management, and other centralized AI controls help CIOs move from experimentation to production by giving security teams a way to see and govern how AI workloads interact with enterprise data,” she said.

Echoing Walter, Leone pointed out that the “security story” is the gating issue for almost every agent deployment that Moor Insights & Strategy is currently tracking.

“Features such as data exfiltration policies and AI SPM are what convert a CISO from a ‘no’ to a ‘yes’ on moving an agent deployment into production,” he added.

This article originally appeared on CIO.com.

Workday is aiming to help customers to develop and deploy agentic systems without compromising corporate security or compliance, unveiling a series of AI tools at its DevCon event this week.

Chief among them is Agent Passport, which validates an agent’s safety and compliance both before it is deployed, and continuously during its operation. When an agent attempts a task, Agent Passport can allow, block, or route the action appropriately, and problem agents can be stopped or restricted, based on company policy.

Agents will be vetted for a series of risks, including prompt injection, jailbreak and goal hijacking, system prompt extraction, leaks of employee data, and unsafe outputs. Those tests will be tied to public standards such as Mitre ATLAS, and will be performed by security partners, not by Workday. Security teams can view those attestations, receiving a signed, auditable record of who tested the agent, and what it was tested for.

Because every check is tied to a public standard, security teams can compare agents from different vendors, tested by different partners, on the same terms.

The sole testing partner at launch is Cisco.

“It’s difficult to really get ramped up in a standard with a lot of partners in the mix, so we want to get this right with just ourselves and Cisco,” said Workday CTO Gabe Monroy. “We’ll be rolling it out more broadly soon.”

No-one to blame

There are still questions to be worked out. For example, if an agent that has been tested and received its compliance stamps from a tester misbehaves, who’s on the hook? That, said Monroy, is something “we’re still wrestling with with our partners.”

Agent Passport will be available in early access in the third quarter, with general availability expected before year end.

DevCon also saw the launch of Developer Agent, which enables developers to easily build AI apps and agents, and Agent-Ready Tools, a new class of enterprise connectors created for autonomous agents.

Agent-Ready Tools provide agents with precise, easy-to-navigate business logic and context while reducing hallucination and latency, Workday said. They connect to act across Workday through open standards such as MCP. For agents that need to work beyond Workday, developers can use pre-built Pipedream connectors to create custom agent actions and expose them as Agent-Ready Tools.

Developer Agent plugs into a dev’s agentic development tool of choice, be it Claude Code, Cline, Codex, Cursor, or Google Antigravity, and can also be used to create and deploy custom agents for the Workday platform with the open AgentSkills standard (OASS). Using it, a developer can simply type a request such as “Build an agent that alerts finance when a department is trending to go over budget this quarter,” and Developer Agent will choose the appropriate Agent-Ready Tools, connect to the necessary data and services, and pull in any required documentation and examples to complete the task.

Developer Agent and Agent-Ready Tools are available to early access customers through Workday Extend Professional, with general availability planned for the second half of 2026.

This article first appeared on CIO.

Technology companies announced 38,242 job cuts in the US in May 2026, the highest monthly total for the sector since August 2024, according to research by employment placement company Challenger, Gray & Christmas. So far this year the company has observed 123,653 US technology job cuts, a rise of 66 percent from the same period in 2025.

These figures represent the third successive month that there has been an increase in job layoffs across all sectors, the company said.

“The labor market is being reshaped by technology in real time. AI is now the leading reason companies give for cutting jobs and the primary industry citing it is technology,” said Andy Challenger, chief revenue office at Challenger, Gray and Christmas.”

AI was blamed for 38,579 of the 97,006 job cuts announced across all industries tracked by the company. It accounted for 40% of the cuts observed in May, up from 7% in January.

This year has already seen some major layoffs in technology. In March, HPE slashed 2,500 jobs from its wage bill, while Oracle announced plans to shed an unspecified number of developers. And the cuts keep on coming, just last month, Meta shed 8,000 employees.