A growing divide among leading AI companies over how to secure increasingly powerful models is beginning to translate into challenges for enterprise IT, with implications for how organizations access, deploy, and govern AI systems.

The latest flashpoint came after Meta CEO Mark Zuckerberg called for neutral evaluators to independently test AI models, pushing back on calls from rivals to slow development or tighten coordination.

“trust and alignment are quickly becoming the most important capabilities that will differentiate agents and models. Any lab that doesn’t focus on alignment will fall behind,” Zuckerberg wrote in a post on X.

“Engaging independent evaluators and advisors is industry best practice,” he added, noting that Meta already does this in several areas.

His comments follow a series of public proposals from AI industry leaders including Dario Amodei, who argued for a more cautious pace of development, and Sam Altman, who called for collaboration on safety standards.

The debate has intensified amid disclosures from AI labs and policymakers on potential misuse of advanced systems. Anthropic has said it restricted attempts to use its Claude models in sensitive domains, while OpenAI has engaged with policymakers on AI-related risks, according to company statements and reports.

Enterprise concerns

While the debate is often framed as a choice between slowing innovation and strengthening oversight, analysts said enterprises should focus less on which approach prevails and more on the operational consequences already taking shape.

“Divergent safety approaches will make access to advanced AI models less predictable, rather than producing an industrywide slowdown,” said Sushovan Mukhopadhyay, director analyst at Gartner. Vendors are likely to apply different release schedules, regional availability, access tiers, and usage restrictions, he said, meaning enterprises could encounter similar capabilities “at different times and under materially different conditions.”

Mukhopadhyay said enterprises should plan for variability in access rather than assuming consistent availability across providers or geographies.

“I read this week as the point where frontier AI became a managed supply,” said Bhupendra Chopra, chief revenue officer at Kanerika. “For three years CIOs could assume the next model would simply show up. A frontier model now behaves more like a critical component from a supplier whose delivery dates depend partly on outside reviewers and export rules.”

Chopra added that “any AI roadmap built on a specific model arriving on a specific date is carrying supply risk it hasn’t priced.”

Security pressure builds regardless of slowdown

Analysts said slowing development alone is unlikely to materially change enterprise risk, particularly as open-source models proliferate.

“The biggest point isn’t the pause itself. It’s that the leaders of AI companies are agreeing on something,” said Nikhil Gupta, founder and CEO of ArmorCode.

Gupta said the threat landscape has already shifted. “Even if companies hit pause, open-source AI models are already out there,” he said. “I’m not convinced slowing down some companies meaningfully changes what adversaries can do.”

“Even if AI development slows down tomorrow, security must accelerate,” Gupta added. “The job of securing these systems has effectively gotten ten times harder.”

A new ‘AI assurance’ layer emerges

The focus on evaluation is driving what analysts described as an emerging “AI assurance” layer, where third parties assess models for safety and compliance.

“A distinct AI assurance layer is likely to emerge, but enterprises should not expect a single certification to establish that an AI system is safe,” Mukhopadhyay said. “Enterprise risk also depends on data, system instructions, tools, agents and deployment controls.”

Chopra said enterprises risk misinterpreting such evaluations. “Procurement teams may see a third-party evaluation and treat the model as vetted,” he said. “Within a year it becomes a checkbox.”

Instead, he said, enterprises will need to run their own validation. “CIOs who get ahead will test each model against their own data before it touches production.”

Fragmentation complicates multi-model strategies

For CIOs pursuing multi-vendor strategies, differing approaches across providers could introduce additional complexity.

“Fragmentation was already the default. Safety divergence deepens it,” Chopra said.

He said risk is most acute during transitions. “For an enterprise running several models, the exposure sits in the handoff,” he said. “When a model is delayed or replaced, the system can behave differently.”

“I’d rank untested model substitution above vendor lock-in,” Chopra said.

Gupta said open architectures will be important. “The framework needs to be open, not locked to any single vendor,” he said.

Mukhopadhyay added that enterprises should prepare for models becoming unavailable or restricted.

CIOs urged to build resilience

Analysts said enterprises will need to design AI strategies that can adapt to changes in availability, pricing, and governance.

“For critical applications, CIOs should separate application controls and business logic from the underlying model,” Mukhopadhyay said.

Chopra emphasized flexibility. “A routing layer between applications and model providers turns switching into configuration work,” he said, adding that contracts should cover deprecation timelines.

He also pointed to pricing implications. “Scarce access to the frontier starts to carry a premium,” Chopra said.

The newest member of the corporate workforce never sleeps, never asks for a raise, and can be cloned before lunch. It can also confidently make the wrong decision thousands of times before anyone notices.

That helps explain why some technology leaders have started talking about AI agents as employees, co-workers, or interns rather than software. Once an agent can update records, issue refunds, send communications, or act across multiple enterprise systems, deploying it no longer looks much like installing another application.

Recent Harvard Business Review articles have pushed that analogy further. One argues that agents should be treated like a new workforce, with defined roles, authority, sources of truth, supervision, and audit trails. Another recommends giving agents names and job descriptions, onboarding them, evaluating their performance, and increasing their responsibilities after they prove themselves.

But there is a catch: People may start believing the metaphor.

A separate HBR study of 1,261 managers found that when AI was framed as an employee rather than a tool, managers with experience working around AI agents took less personal responsibility for results and assigned more responsibility to the AI. They also escalated more problems and caught fewer errors. In the study, 31% of respondents said their companies already framed AI as a teammate or employee, while 23% said agents appeared on organizational or work charts.

For IT leaders, the answer may therefore be to borrow freely from the employee-management playbook — without extending the metaphor too far.

Don’t put software on the org chart

Amy Loomis, group vice president at IDC, draws a hard line around one word: responsibility.

Humans, she says, have obligations to their companies and to one another, and they bring an understanding of corporate culture and values that an agent can mimic linguistically without possessing.

That makes calling an agent a co-worker potentially more than harmless anthropomorphism. The label suggests a peer relationship and can encourage people to cede judgment to a system that’s very good at giving what was requested, Loomis says, but not necessarily at recognizing what was actually needed.

“Accountability is something that has qualities associated with it that are uniquely human,” she says. “Agents may be given permission to access data, but the accountability for what they do with that access lies with the person who gave the agent access, not the agent itself.”

That distinction still leaves plenty to borrow from employee management. It makes sense to give an agent traceable access and tightly scoped permissions — and to institute a kill switch to prevent the agent from having continued access. But Loomis finds it more effective to think in terms of giving an agent an operations charter rather than a human identity: define what the system does, what it may access, and what humans remain responsible for.

In other words, give the agent a security badge. Just don’t put its picture on it.

The employee metaphor has a job to do

Raja Iqbal, founder of agentic AI governance company Ejento AI and co-author of the HBR article “To Scale AI Agents Successfully, Think of Them Like Team Members,” is closer to Loomis than the headline suggests.

Iqbal says the metaphor is intended to put CIOs, CISOs, and other technology leaders into the right “cognitive posture.” Thinking about an agent as a team member, he argues, can remind an enterprise to impose familiar management disciplines: a unique identity, clear human oversight, defined authority, spending limits, approved information sources, and an audit trail.

If another term produces the same discipline, he’s fine with that too.

In fact, Iqbal explicitly rejects synthetic employees with human personas and seats on the org chart. That creates exactly the accountability problem critics worry about: “Bob did it” becomes an excuse even though Bob is software.

“The metaphor is dangerous when it’s decorative,” Iqbal says. By that, he means companies get into trouble when they adopt the human trappings — names, personas, or the language of colleagues — without also imposing the supervision, limits, and accountability that make the analogy useful.

His preferred distinction is simpler: the agent needs a technical identity so the enterprise can reconstruct what it did, while a human must remain responsible for those actions. “The identity is the audit primitive, and the human owner is the accountability primitive,” he says. Put more plainly, the agent identity answers what acted; the human owner answers who is accountable.

The employee analogy becomes more useful again when deciding how much freedom an agent should receive. Iqbal recommends graduated autonomy. An agent might begin with a human approving every action, progress to performing low-risk actions independently, and eventually receive bounded autonomy if its observed performance justifies it. A serious error can send it back down the ladder — or out the door entirely.

That sounds a lot like a probation period for a new employee. It’s also simply good software governance for a probabilistic system.

At DXC, professional agents are software

Russell Jukes has had plenty of opportunity to test that distinction. As chief digital and information officer at DXC Technology, he oversees AI in an IT services organization with roughly 115,000 employees.

“We think about [an AI agent] as a superpower, not as a person,” he says.

DXC separates agents into two categories. Personal agents work for individual employees and generally operate using the employee’s identity and access. Professional agents are enterprise systems built for broader workflows. On one of DXC’s major AI platforms, employees have so far created roughly 8,000 personal agents, compared with about 100 professional agents.

The professional variety receives much stricter oversight. It can have its own nonhuman identity, credentials, permissions, and authority boundaries. Activity passes through control planes that allow DXC to see what agents are doing and, when necessary, shut them down.

Jukes thinks many of these agents will eventually disappear from users’ view altogether. An agent might scan internal resource requirements overnight and recommend employees for projects. Nobody needs to greet it in the morning or consider it a colleague; they simply receive the result.

That’s where he parts company with the worker metaphor.

Jukes says he learned early on that AI cannot be deployed like conventional SaaS. His first attempt followed the familiar software model: make the application available, let employees use it within the prescribed workflow, and expect adoption to follow. “I did that, and nobody used it,” he says. The experience convinced him that AI requires a different approach, and he vowed to “never deploy AI like it’s SaaS again.”

Conventional SaaS is largely deterministic: the software constrains users to a defined workflow and produces predictable outputs. Agentic AI is different. It can interpret a goal, choose among tools and data sources, and decide how to get to an outcome. For Jukes, that means CIOs have to design the policies, permissions, data access, guardrails, and authority around the agent rather than simply deploy another application.

That also creates a clearer chain of responsibility. If a person approves the agent’s action, Jukes says that person owns the decision. If an autonomous agent behaves according to a business policy, accountability belongs with the people responsible for that policy. If the technology fails to operate as designed, responsibility moves to IT.

The agent itself never gets handed the blame.

Maybe treat it like an intern after all

Nina Tatsiy, global CIO of Quadient, an automation technology company, takes a position somewhere between Iqbal and Jukes. She calls agents interns, but deliberately uses the term as an analogy, not an organizational designation.

Agents must be managed as software, with security, governance, and technical controls, while recognizing that their probabilistic behavior requires additional supervision. “You have to do both,” Tatsiy says.

An intern does not receive every password and authorization on the first morning. Neither should an agent. It has to be onboarded, trained, watched, retrained when its environment changes, and eventually retired when it’s obsolete.

Quadient generally avoids giving agents human names. Tatsiy worries that doing so encourages people to see them as real colleagues capable of judgment.

“Overtrust is a problem,” she says, particularly because AI tends to state conclusions with such assurance. Tatsiy prefers using AI to challenge a hypothesis or surface questions people haven’t considered rather than allowing it to make the conclusion for them.

Yet the intern analogy has proved useful operationally.

In one accounts-payable deployment, Quadient had an agent effectively shadow human workers and learn from their feedback across different scenarios. Only after its performance had been tested across increasing levels of complexity did it begin providing recommendations. Humans still made the final decision.

The agent, in other words, earned more trust. It didn’t earn accountability.

Borrow from HR, but keep humans in charge

The emerging divide may therefore be less about whether agents are employees or software than about which parts of each management model IT leaders should retain.

Agents need individual technical identities, but not human identities. They need defined responsibilities, but not jobs in the human sense. They need monitoring and evaluation, but not annual performance reviews. They can receive progressively greater authority, but not progressively greater accountability.

And the stronger they become, the more important that distinction becomes.

Treating an autonomous agent like ordinary SaaS ignores the fact that it can interpret, choose, and act in ways conventional software cannot. Treating it like Steve from Accounting creates a different problem: sooner or later somebody may start assuming “Steve” knows what he’s doing.

IT leaders may indeed need to borrow heavily from HR as agentic AI spreads across the enterprise. They just shouldn’t start issuing employee badges.

Related reading:

• 6 ways to make AI accountability stick
• From chatbots to colleagues: How agentic AI is redefining enterprise automation
• Why AI adoption keeps outrunning governance — and what to do about it
• AI is spreading decision-making, but not accountability

A year and a half ago I sat in a conference in Silicon Valley and watched an AI agent write production-quality code in real time. I knew our engineering model was going to change, and within a few weeks my team was past the question of whether to adopt AI. The real debate was how far we were willing to go in redesigning how we build legal software around it.

Since then, output per engineer across our R&D organization has roughly tripled. We ship nearly twice as many releases per quarter, deployments have grown from 82 to more than 155, and customer reported defects are down 65% per million lines of code across the last 18 months. We track all of this with DORA metrics, cycle time, pull requests merged per developer, and lines changed per developer against a fixed baseline, and the improvement holds up on every measure.

Getting there had less to do with the tools than with how the organization works. Every CTO I talk to is running some kind of AI coding pilot and seeing decent results: faster prototyping, better test coverage, quicker first drafts. Almost none of them have changed the development life cycle itself, and that is where the real gains were for us.

We spent the past 18 months rebuilding our product development life cycle around AI. Requirements, development, testing, security, deployment, and governance all changed, some beyond recognition. We got plenty wrong along the way, and a few of the lessons would have saved us months if someone had handed them to me at the start.

The biggest gains came from removing handoffs

We assumed most of the productivity gain would come from AI writing code faster. It didn’t. The biggest gains came from getting rid of the handoffs between stages.

In the old model, a feature passed through at least four handoffs on its way out the door: product to development, development to QA, QA to security, and security to deployment operations. Each of those queues cost us time and context. A feature could be code complete in a day and then sit for two weeks waiting on teams that each had their own backlog and their own priorities.

So, we restructured. A team now carries a feature end to end, and AI agents handle the rote work at each stage. A feature that used to take 15 days to go from spec to a working pull request now takes about four hours.

If you take one thing from this article, measure the total time from idea to deployment rather than lines of code generated, and go find where the work sits idle. That is where the gains are hiding.

Governance accelerated adoption

Most engineering organizations add governance after the innovation has proven itself. We flipped that order. We build software for lawyers, where a wrong answer on high-stakes work can cost a client dearly, so moving fast and cleaning up later was never on the table.

Before we scaled past the first pilot teams, we set standards for code review, security scanning, and quality on anything AI produced. Confidence scoring lets routine approvals pass through automatically while anything below threshold goes to a human. Security and quality gates run inside the pipeline itself rather than as a checkpoint at the end.

What we didn’t expect was how much this sped up adoption. Engineers trusted the system, so nobody had to wonder whether code from an agent would pass review, introduce a vulnerability, or get them blamed when the model got something wrong. Eighteen months ago, about 3% of our pull requests had any AI assistance. Today it’s 68%, every engineer in the organization uses AI, and vulnerability density has fallen 76% over the same period. Governance came first and adoption followed, which is the opposite of the sequence most people assume.

Pick your tools and get good at them

A better model or agent ships almost every week, and early on we burned real energy evaluating them. At some point we stopped and standardized on a small set of coding agents.

Going deep paid off more than staying current. We learned the strengths and failure modes of our coding agents and tuned our workflows around how they actually behave, which matters more than whatever the next release promises. Teams that chase every new model spend all their time evaluating, and every switch resets the muscle memory and the trust they built with the last tool. They end up with a lot of pilots and not much change.

Automate the entire life cycle

The obvious place to point AI coding tools is at the coding. Some of our biggest wins came from the edges of the life cycle.

We built or deployed dedicated agents for every stage: requirements, sprint planning, code generation, test authorship, security scanning, deployment, and site reliability. Each one owns a single job and gets measured on a single outcome. What makes it work is a centralized knowledge repository that product and engineering maintain together, a curated and structured knowledge base with retrieval-augmented generation on top. Every agent pulls product context, domain rules, and prior decisions from that same source of truth, so what comes out of one stage is clean input for the next. Without it we would have a set of fast agents that lose the thread at every handoff.

Requirements definition was the most dramatic early win. It used to take weeks. We built an agent that grills a raw product idea the way a tough stakeholder would, pushing on gaps until the spec is ready for development, and that phase now finishes in an afternoon.

Testing moved even faster as quality engineers shifted their focus to optimizing and improving the agents that build tests. AI now generates 99% of our new tests, up from 47% a year ago, with more than 39,000 AI-developed tests in the suite, a number we could never have staffed our way to. Each test is generated directly against the code change it covers and checked against the functional requirements defined in the product requirements document, so growth in volume doesn’t come at the cost of traceability. Engineers spend their time reviewing, refining, and hardening what the system produces rather than writing first drafts, and that shift, from authoring tests to curating and strengthening them, is a big part of why quality improved while we sped up.

We started with one area of the product development life cycle, got it right, then expanded. I would recommend that sequence to anyone. The key is to develop a model that can be expanded to the rest of the phases after experimenting on what works rather than trying to roll it out to every area and having to rebuild the framework later.  

Design for the velocity you’re about to create

We set a public and very specific goal: double R&D productivity in 12 months. It was uncomfortable, and there were stretches where I wasn’t sure we would make it. But a number that aggressive forced everyone to accept that incremental improvement wasn’t going to get us there, and we had to take apart old ways of working while the technology underneath was still maturing. We hit the goal inside the year, and output has kept climbing ever since.

What I underestimated was how fast the bottleneck would move downstream. Once engineering sped up, the constraint moved to go to market. Every release still needs documentation, enablement content, briefings for customer success, and customers who are ready for what’s coming, and for a while we were shipping faster than any of that could keep up. We now treat go to market as its own automated phase of the life cycle, with the same agent-driven approach we applied to code and testing, and a simple rule that nothing ships until the rest of the organization can support it. If I were starting over, I would build that capacity from day one instead of finding out about it the hard way.

The real transformation is organizational

The tools matter, but everyone can buy the same tools. What we actually did over these 18 months was redesign the system around AI: the way work flows between teams, the governance that lets people trust the output, the small set of tools we committed to, and a target aggressive enough to force all of it. Any one of those alone would have produced another interesting pilot. Together they produced a different engineering organization.

None of this is finished. The models keep improving and the life cycle will keep changing with them. The organizational groundwork is what lets us absorb each improvement as it arrives, and for any technology leader still stuck at the pilot stage, that groundwork is where I would start.

—

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.

The consulting firms told us this would be different. They arrived with slick slide decks, expensive vendor packages, and promises to revolutionize how we do business. Their message was clear: Digital transformation was no longer optional; it was existential. Companies that failed to adapt would be left behind and crushed by more agile competitors with cloud-native architecture and data-driven strategies.

That was back in 2020, when Boston Consulting Group released research showing that 70% of digital transformations failed to meet their objectives. The consulting industry rushed to publish its frameworks, maturity models, and proprietary methodologies. Enterprise IT organizations spent millions on these programs, hoping to finally bridge the gap between technological capability and business value.

Several years on, I can say that little has changed. If anything, the issue has worsened.

The damage that was done

Most digital transformations didn’t just fail to deliver ROI; they actively damaged the organizations that undertook them. Technical debt accumulated as companies deployed monolithic cloud platforms that were neither modular nor scalable. Business misalignment became endemic as transformations focused on technology for its own sake rather than on solving actual business problems. Organizations found themselves locked into expensive vendor relationships that failed to deliver on their promises.

I’ve spoken with dozens of enterprise CIOs and CTOs over the past several years, and the stories are remarkably consistent. Transformations that were supposed to take six months stretched to two years. Budgets estimated at a few million exploded to six, eight, even twelve times the original projection. The consulting firms had excellent PowerPoint skills, but when it came to implementation, the results were consistently disappointing.

The damage wasn’t just financial. Organizations lost confidence in their IT capabilities. Talented people left because they were tired of being managed by consultants who couldn’t code their way out of a paper bag. Business stakeholders grew cynical about technology initiatives, having been burned too often by projects that promised transformation but delivered chaos.

Why the consulting models failed

Let’s be direct about what happened. The consulting industry discovered that digital transformation was highly profitable. They could sell their methodologies, vendor partnerships, and “best practices” frameworks, and charge premium fees for implementation support. The problem was that these frameworks were largely one-size-fits-all approaches disguised as bespoke solutions.

A major global bank doesn’t have the same requirements as a regional healthcare provider, yet both were sold the same transformation playbook. The consulting firms had invested too heavily in their methodologies to admit that the real answer might be to start with business requirements and work backward toward technology. Instead, they assembled prepackaged solutions optimized for vendor partnerships rather than clients’ actual needs.

The talent problem was equally severe. The consulting firms could certainly talk about digital transformation; they had excellent slides and compelling narratives. But when it came to implementation, the skill gaps were glaring. These organizations assembled solutions by following playbooks rather than understanding how the technology components actually fit together. The result was systems that were overengineered, overprovisioned, and ultimately underperforming.

Cloud computing was supposed to be the great enabler, but many organizations misunderstood and misapplied it. Organizations lifted and shifted their existing problems along with their existing architecture. Monolithic applications running on expensive virtual machines became the new normal, with organizations paying cloud costs that far exceeded their on-premises expenses, yet achieving none of the scalability benefits the cloud was supposed to deliver.

What we still need to learn

As we grapple with the next wave of technology transformation—this time centered on artificial intelligence—the lessons from digital transformation failures should be front and center. The first and most important lesson is brutally simple: Focus on business needs first. I know this sounds obvious, but I guarantee you that every failed digital transformation project lost sight of its core business requirements. They built technology for technology’s sake without understanding the problems they were trying to solve.

Too many transformations focused on individual business units rather than enterprisewide strategies. The result was a collection of systems that couldn’t work together cohesively. Isolated solutions felt like progress but actually made integration harder and created new dependencies that hadn’t existed before.

Organizations also need to invest in serious training for their people. I’m not talking about sending IT staff to vendor certification programs that teach them to pass tests on proprietary platforms. I mean fundamental architectural education that helps people understand how to assemble technology effectively.

We face a massive shortage of AI, cloud, and security architects, as well as other technical leaders who can design solutions that work. Rather than addressing this gap, organizations are placing unqualified people in these roles and hoping for the best. It’s past time to invest in education.

The case for simplicity

Here’s something that also should be obvious but clearly isn’t: You can solve the same business problem with $1 million or $20 million, depending on the sophistication of the IT organization building the solution. Both designs will work reasonably well, but one solution costs 20 times more because it is overbuilt and overengineered.

Organizations are adding AI to everything under the sun, even when simpler solutions would work just as well. They’re overprovisioning cloud resources because they lack the architectural discipline to rightsize their infrastructure. They’re building systems designed for scale they’ll never reach, complexity they don’t need, and features no one requested.

The path forward requires a minimalist approach. Build systems that are good enough for their intended purpose. Focus on requirements rather than capabilities. Resist the temptation to adopt every new technology just because it’s available.

Digital transformation didn’t fail because the technology was flawed. It failed because we forgot that technology exists to serve the business, not the other way around. To succeed with AI, we need to remember that fundamental truth. And remember the consulting industry’s tendency to sell us expensive solutions to problems we don’t have.

Meta won’t judge employees by how much they use AI when it comes to annual performance reviews, despite early efforts to drive AI adoption focusing on so-called token maxing.

The company has told employees that it “will not use AI adoption dashboards or token counts to evaluate impact,” according to  a report by The Information.

The announcement came in an internal memo from executives Maher Saba and Santosh Janardhan, which said that instead of measuring AI usage, “managers should look at output quality, velocity, problem complexity and scope taken on.”

This marks a culture change for Meta, where engineers had previously competed to consume the most AI tokens, displaying their scores on a leaderboard. Meta then discovered that its employees were being diverted from regular work because they were using AI to carry out additional tasks to boost their scores.

Amazon had similar results when it implemented a leaderboard to track AI use; it also found that some employees were trying to game the system by using AI to complete unnecessary tasks, and it has now deleted it.

The company, however, does also monitor employees’ use of AI for training purposes, in a program introduced in April, but this is information was not used to measure employee performance.

Meta had already started to look askance at the concept of using AI metrics as a tool to assess employees. Earlier this year, Chief Technology Officer Andrew Bosworth told employees in a memo that “nobody should be using AI tools just for the sake of using them,” adding that “token usage alone is not a measure of impact of any kind.”

Meta rolled out a new 30-billion-parameter AI model optimized to run on a PC or Mac with a single GPU on Monday, offering a way to run always-on agentic workflows locally rather than relying on the cloud.

The company has dubbed it Muse Glimmer. However, its hardware demands, including a GPU with a minimum of 24GB of VRAM, could make it difficult to justify for deployment at scale.

Although analysts and consultants agree that there is a tremendous enterprise appetite for running models locally, determining whether switching more systems from cloud to local makes fiscal sense is much more complex. 

The hardware costs are tricky to calculate even today, with the VRAM needed depending on the particular applications to be run. But the far bigger consideration is that there is no way to determine what RAM costs will look like over the next 12-18 months, and there is an identical lack of visibility into how cloud prices might increase during the same timeframe. 

That makes determining the better financial choice impossible.

Agents become capex, not opex

Noah Kenney, principal consultant at Digital 520, noted that since RAM costs have increased “exponentially” over the last 12 months, cloud AI providers are also going to have to increase their prices. Beyond that, IT needs to anticipate logistical issues; key questions to ask are, “How quickly can you scale? Can you even get the hardware?”

“Meta just made agents a capital expense instead of an operating one,” Kenney said. “For two years, enterprises have been trained to rent intelligence by the token from someone else’s data center. Muse Glimmer runs the agent on a GPU you own, on the desk, with the meter switched off. That is a direct shot at the business model that cloud AI vendors are built on, and it comes from the one player with no cloud API revenue to protect.”

In its post announcing the new model, Meta pointed out that it has aggressively slimmed it down to try to make it efficient and cost-effective. 

“At full precision, a 30-billion parameter model would require over 55 GB of memory — far more than any consumer GPU offers,” Meta said. “We use quantization techniques to compress the model’s weights to approximately 4-bit precision, shrinking the language model to under 20 GB. This leaves enough headroom for the model’s working memory, its KV cache, the perception encoder for image understanding, and the speculative decoding drafter to run simultaneously within a 24 GB or 32 GB envelope. We validated that this compression introduces minimal to no degradation on agentic tasks.”

More options for enterprises

Mike Wilkes, enterprise CISO at Aikido Security, said that Meta’s move is significant in that it starts to give enterprises more options. 

“The most important thing about Muse Glimmer is not that Meta has produced another capable model, it is that the economics and architecture of AI are beginning to move back toward the edge,” he said. “The financial comparison therefore becomes capital expenditure that can be amortized over several years versus an effectively perpetual per-token or per-request cloud operating expense.”

That means, he said, that an enterprise may rationally pay somewhat more for hardware if doing so gives it predictable AI costs, offline availability, control over model versions, freedom from sudden API pricing or access changes.

Independent cybersecurity and risk advisor Steven Eric Fisher also noted that the specs published by Meta don’t tell the full story.

The problem is that running locally versus in the cloud can generate a lengthy list of related expenses. 

“Agentic workloads [in the cloud] can amplify consumption through reasoning, retries, tool calls, context growth, and evaluation, while local deployment [also] introduces hardware, power, lifecycle, support, and utilization costs,” he said, adding that even the RAM requirements need a lot of context.

“Meta’s stated 24GB and 32GB memory targets demonstrate that Glimmer can be loaded and executed on comparatively accessible hardware, but that is not the same as having sufficient capacity for meaningful agentic workloads,” Fisher said, pointing out that once other factors are considered, practical memory requirements can move beyond the 32 GB available on an Nvidia RTX 5090 GPU.

“In enterprise terms, this still places Glimmer primarily in high-end developer, data science, or dedicated AI workstations rather than the standard corporate desktop or laptop,” he said.

Better ROI not guaranteed

Justin Greis, CEO of consulting firm Acceligence, agreed. 

“I wouldn’t assume that moving inference from the cloud to the endpoint automatically produces a lower total cost of ownership,” he said, noting that variable cloud costs would be traded for the price of  deployment, endpoint management, support, security, model updates, and potentially accelerated hardware refresh cycles for the local devices.

“Muse Glimmer is an important milestone because it makes local agentic AI technically viable. But technical viability and enterprise ROI are two different milestones,” Greis said. “I think Meta has crossed the first one. I do not think they have fully crossed the second one yet.”

However, Kenney argued that there are also other elements of the Meta rollout that make meaningful comparisons difficult. 

“It is worth remembering that the local model is quantized, compressed to roughly 4-bit precision, while the cloud APIs you are comparing against typically serve full-precision models, so this is not a pure apples-to-apples cost comparison,” he said. “The ROI question is not local versus cloud on price alone. It is also a question of whether a company is willing to use a quantized model for the specific task. A cheaper agent that needs more retries or human correction can erase its savings fast.”

In addition, a local model often neglects to include every service that a cloud provider typically delivers. 

“The cloud vendor was quietly handling updates, scaling, reliability, and security patching across your whole footprint. Bring the model in-house and every one of those becomes your problem, multiplied by every machine running it,” Kenney noted. “Most enterprises that consume AI as a service have no muscle for operating a fleet of local models, and that cost rarely gets adequate consideration in ROI conversations. The GPU is cheap. Patching a thousand of them is not.”

Sanchit Vir Gogia, chief analyst at Greyhound Research, also stressed that it can be difficult for IT to comprehensively anticipate the different cost variables. 

“Finance leaders are right to feel skeptical. An engine bought for one employee burns capital whether or not it runs. Meta has shown that a thirty-billion-parameter agent can run on a single machine, and that is a real engineering result. What it has not shown is that such an agent works reliably at enterprise scale, or that a fleet of them can be operated safely. Model fit and production fit are different claims. A laptop must still run the employee’s actual job,” Gogia said. “The economics turn on the incremental hardware premium, refresh timing and actual utilization, measured against the price of the remote inference being displaced.”

On the other hand, Arun Chandrasekaran, a distinguished VP analyst with Gartner, said that he found it “very interesting that they have decided to release a smaller model that operates on the edge” and especially liked Meta’s use of the popular Apache license. But he would have preferred that they had released more than just a model.

“Enterprise customers are asking for a car and Meta is delivering an engine,” Chandrasekaran said. “They should have built something more like a platform solution.”

Every cloud architect, every financial services executive, and frankly every enterprise CTO should be paying attention to what is going on in the United Kingdom right now. Britain has formally designated Microsoft, Google, Amazon Web Services, and Oracle as “critical third parties” to the financial sector, meaning they are now subject to direct oversight by UK financial regulators rather than being treated as distant infrastructure suppliers outside the regulatory perimeter.

The designations took effect on July 13, 2026, and the oversight will be carried out by the Bank of England, the Prudential Regulation Authority, and the Financial Conduct Authority. The point is straightforward. If these platforms underpin critical banking and financial operations, then their resilience is no longer just a procurement issue. It is now a matter of financial stability.

This is a bigger deal than many people understand. For years, enterprises have treated cloud platforms as outsourced technology providers. Regulators are now making a different argument. They are saying that when enough banks, insurers, payment firms, and market infrastructures depend on the same small group of cloud providers, those providers become systemic infrastructure whether they like the label or not. Reuters reported that the UK’s framework will bring requirements such as resilience testing, self-assessments, and incident reporting directly to these providers. In other words, this is not just more policy language. It is operational oversight aimed at the platforms themselves.

The first thing to understand is that this move is not anti-cloud. It is the opposite. It is an acknowledgment that cloud has become too important to remain lightly touched when it comes to systemic risk. Regulators are not trying to unwind cloud adoption in financial services. They are accepting the reality that core financial operations now depend on a concentrated set of external platforms. When that happens, the conversation changes from vendor management to infrastructure resilience.

Systemic cloud concentration

The market has spent years talking about cloud concentration risk as if it were some vague future concern. It is no longer abstract. The UK is acting because concentration at this level means that a disruption at one major provider can ripple across multiple institutions simultaneously. That is the core issue. It is not whether Microsoft, Google, Amazon, or Oracle are competent operators. In many cases, they are exceptionally good at what they do. The problem is that too much critical activity depends on too few shared platforms.

This is a concept many business and technology leaders still struggle to internalize. A single bank can do a fine job managing its own vendor exposure and still be part of a broader systemic vulnerability if every other bank is relying on the same provider, the same region, the same identity layer, or the same operational dependencies. Regulators are stepping in because the risk is collective, not just institutional. That is why this matters well beyond the UK. It provides a framework for thinking about cloud not as outsourced capacity, but as part of the plumbing of the financial system itself.

Regulators expand their reach

Traditionally, regulators focused on the bank, insurer, or market institution and expected that entity to manage the risks created by outside suppliers. That approach still exists, and financial institutions remain accountable for their own resilience. However, the UK now says that, in some cases, this indirect model is not enough. If a third party becomes critical enough, regulators want direct line of sight into that provider’s resilience posture as well. This is probably the most important architectural and policy signal in the entire move.

That changes the relationship between the financial sector and the cloud providers in a meaningful way. Direct oversight means cloud providers are increasingly being treated less like optional technology partners and more like essential utilities that support national economic confidence. Once that happens, architecture decisions start to carry a different weight. Decisions about control planes, failover models, identity dependencies, regional design, observability, and incident response are no longer just internal engineering choices. They become part of a broader resilience conversation that may now include regulators.

A lot of enterprises have been behind the curve. They built architectures under the assumption that the cloud was simply a faster and cheaper hosting model. It is not. At scale, cloud is shared critical infrastructure. The UK has now made that point explicit.

More scrutiny isn’t more safety

It’s tempting to read this and assume the problem has now been solved. It has not. Direct oversight of hyperscalers does not remove the responsibility of banks or other enterprises to architect well. In fact, it should push them to architect better. A regulated provider can still be a concentration point. A resilient platform can still be used in a fragile way. And a well-run cloud service can still become part of a badly designed dependency chain.

If you are in a regulated or highly sensitive industry, you should take this as a warning that resilience can no longer be treated as a side topic. You need to know exactly which services are business-critical, which control planes are shared, which identity systems create cross-platform dependencies, and how your recovery assumptions actually work in the real world. Most organizations are much weaker here than they believe.

The UK’s move should also force a hard conversation about operational transparency. If regulators are requiring incident reporting and resilience evidence from major providers, enterprises should be demanding clearer dependency mapping and better architectural visibility inside their own environments. You cannot build true resilience on top of assumptions and vendor slide decks.

The start of a much larger shift

The deeper message is that cloud is crossing a line from enterprise technology choice into national and sector-level infrastructure policy. Once a few governments and central regulators start treating cloud this way, the rest of the world tends to follow in some form. We have already seen comparable concern in Europe, and now the UK has made its own move with direct designations and direct oversight.

Architects, CIOs, and boards need to mature their thinking quickly. The conversation is no longer limited to feature depth, discounts, migration speed, or which provider has the best AI story this quarter. The conversation is now about resilience, concentration, transparency, control, and systemic dependency. Those are bigger issues, and they are not going away.

The UK is telling the market something very clearly. Microsoft, Google, Amazon, and Oracle are not just selling cloud services into the financial sector. They are becoming part of the infrastructure on which that sector depends. Once you understand that, everything changes, including how we architect for the future.

A few years ago, I sat in a postmortem that I still think about. We’d had a production incident where a routine deploy had quietly shipped with the wrong configuration, and it took us longer to notice and roll back than anyone was comfortable admitting. But when we traced the root cause, almost none of it was the feature code. It was the scaffolding around it: a Kubernetes manifest no longer matched our cluster, a CI pipeline whose green checkmark didn’t actually verify the thing we assumed it did, and a secrets-management step that three different services each did three different ways. The code itself had been fine for a week. Everything around the code is what failed us.

I have seen some version of that retro at nearly every company I’ve worked at over the last 15 years across a large IT services firm, a medical-device maker, a healthcare-technology company, a cloud-migration startup, and now a large SaaS platform. The names and the tech stacks changed. The pattern didn’t. Smart engineers spending a startling share of their week not on the problem they were hired to solve, but on the accidental complexity of shipping it.

For a long time, I assumed the answer was better documentation, or a stricter DevOps culture, or just hiring people who were more comfortable with YAML. I was wrong on all three counts. What actually changed my mind was reframing the problem entirely: the friction wasn’t a knowledge gap or a discipline gap. It was a product gap. Nobody owned the developer’s experience of shipping software the way a product manager owns a customer’s experience of using an app. And the discipline that closes that gap now has a name: platform engineering, which Gartner describes as having “emerged in response to this increasing cognitive load resulting from the complexity of modern software tools and architectures.” Gartner isn’t shy about how fast it’s spreading, either: the firm predicts that “by 2026, 80% of large software engineering organizations will establish platform engineering teams,” up from 45% in 2022. If that number is even close to right, the interesting question is no longer whether to build a platform team but whether you’ll build a good one.

The moment “DevOps” quietly stopped scaling

I want to be careful here, because “DevOps is dead” is a lazy headline and I don’t believe it. The principles behind DevOps include shared ownership, automation, and tight feedback loops. These are as right today as they were when the movement started.

What broke, in my experience, was the operating model. The original promise was “you build it, you run it.” Every team owns its own deployment, its own observability, its own on call. That works beautifully when you have a handful of teams and a shared oral tradition. It falls apart when you have 50 teams, because now you have 50 slightly different ways of doing the same undifferentiated work. 50 ways to define a service. 50 subtly wrong Kubernetes configurations. 50 on-call rotations paging fifty engineers about the same class of problem at 3 a.m.

The cognitive load of “run it yourself” grew faster than most teams could absorb. That framing of cognitive load as the thing you’re actually optimizing for comes from “Team Topologies,” a book that reshaped how I think about org design more than any purely technical text I’ve read. Its fourth principle is blunt about the limit: “Teams can only handle so much complexity before breaking down,” and “competent teams become ineffective when leaders keep adding to their plate without taking anything away.” That last line described my own teams so precisely it stung. “Team Topologies” also gave me the vocabulary I’d been missing. It names four fundamental team types, and it defines a platform team as “a grouping of other team types that provide a compelling internal product to accelerate delivery by stream-aligned teams”. Read that definition again: a compelling internal product. Not a shared-services desk, not a Terraform repo with a wiki. A product. That single word is the whole argument.

Treating the platform as a product changes everything

Here’s the shift that took me embarrassingly long to internalize: if the platform is a product, then developers are its customers, and you don’t get to tell your customers they’re holding it wrong.

That one reframing has downstream consequences that surprised me.

The first is that adoption has to be earned, not mandated. Early in my time working on internal tooling, I helped build a platform capability that we were quite proud of, and then we did what infrastructure teams love to do: we announced it, and assumed people would come. They didn’t. Teams routed around it, because the golden path we’d paved was, frankly, gravel. The lesson landed hard. A platform that developers have to be forced onto is not a platform, it’s a tax. When we went back and rebuilt it so that the paved path was genuinely the easiest path. This is the same instinct behind Backstage, the developer portal that was built at Spotify and is now a CNCF project; its own pitch is that it “restores order to your microservices and infrastructure” so product teams can ship quickly. Order you have to opt into isn’t order. The tool wins when choosing it is the lazy option.

The second consequence is that “self-service” has to mean what it says. It’s an overused word, so I hold it to the CNCF’s definition from its platforms white paper: “A platform should be self-serviceable. Users must be able to request and receive capabilities autonomously and automatically.” Autonomously and automatically. If a developer has to file a ticket and wait on my team to provision a database, I haven’t built a platform instead I’ve built a slower version of the help desk. The same white paper states the north star plainly: “An essential goal of a platform is to reduce the cognitive load on product teams.” I’ve started using that sentence as a litmus test. For any capability we’re tempted to add, I ask whether it removes load from a product team or quietly adds some. A surprising number of well-meaning platform features fail that test.

The third consequence is that you have to measure the platform the way you’d measure any product and resist measuring the things that only flatter the platform team. “How many clusters are we running” is an output my team cares about and nobody else does. The metrics that matter describe the developer’s lived experience, and the most durable set I know of comes from DORA, the long-running research program into software delivery performance. Its metrics have evolved from the original “four keys” have grown to five. The core throughput measures still ask exactly the right questions: change lead time (“the amount of time it takes for a change to go from committed to version control to deployed in production”), deployment frequency, and failed deployment recovery time, balanced against a change fail rate. I’ve found those double as a remarkably honest scorecard for a platform team, precisely because they refuse to reward busywork. You cannot game your way to a good lead time by shipping more internal tools nobody uses.

The fourth consequence is the hardest culturally: a platform product needs a roadmap, user research, and the willingness to say no. I’ve watched platform efforts collapse into a junk drawer of one-off requests, each reasonable on its own, that together add up to an incoherent pile of tools nobody can hold in their head. Saying no to a well-intentioned request is a product-management skill, and platform teams that never develop it end up rebuilding the very sprawl they were created to eliminate. The best platform leads I’ve worked with spend as much time talking to their internal users as any consumer-facing PM does.

What I’d tell my younger self

If I could go back to that retro years ago, I’d say a few things to the version of me who thought this was a documentation problem.

Start with the paved road, not the platform. You don’t need to build an internal developer portal in quarter one. You need to find the single most painful, most repeated piece of undifferentiated work is the distance between “here is my container” and “it is running safely in production”. Earn the next piece of scope by delivering that one well. Platforms that begin as grand architectures tend to die as grand architectures; the ones that survive start as one genuinely useful paved road that people choose on their own.

Resist the urge to abstract away everything. The goal of a good platform is not to hide Kubernetes so completely that no one understands what’s happening beneath them; that just trades one kind of fragility for another. The goal is to remove the toil while leaving the understanding intact. When the abstraction leaks you want engineers who can reason about what’s underneath, not a room full of people who only ever knew the buttons. I’ve paid for both mistakes: platforms too thin to help, and platforms so thick that an incident turned into an archaeology dig.

And treat “developer experience” as a first-class business metric, not a morale nicety. Every hour an engineer spends fighting the delivery pipeline is an hour not spent on the thing your customers actually pay you for. When I frame platform investment that way to leadership as reclaiming a meaningful fraction of my most expensive people’s time that’s when the conversation stops being about cost and starts being about leverage. It is genuinely one of the highest-return investments an engineering organization can make, and it almost never shows up as a line item that looks like one.

The platform team is not the group that keeps the lights on. It’s the group that decides how fast everyone else can move. Once I started treating it as the most important product my organization ships internally, almost every other decision got easier. I just wish it hadn’t taken me a missed release and a room full of frustrated engineers to see it.

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

China has created an international organization to set standards and introduce regulation for AI, inviting 28 other countries to join — but the US, a leading AI powerhouse is not part it.

The World Artificial Intelligence Cooperation Organization (WAICO) was established by 29 countries, including China, Russia and Brazil, at a ceremony in Shanghai, China, on July 16. Notably absent are the US, the European Union and its member states, the UK, Japan and South Korea.

Chinese AI companies have made a concerted effort to provide an alternative to US dominance. While the US is clearly ahead, Chinese enterprises are looking to narrow the gap in various areas: the open-weight model market, AI cyber protection and open source AI.

WAICO has been some years in development and has been designed to set some universal guidelines in AI. Researchers say WAICO differs in three ways from other initiatives to create global AI organizations: membership open to any sovereign state, there is no regime-type test for entry, and its agenda is built around development and the global capability divide.

The signing ceremony to create WAICO comes just days after Demis Hassabis, CEO of Google DeepMind, called on the US to take a lead in global AI regulation. “The US is well-positioned to take the first step in developing such a framework. It could establish a new Standards Body modelled on a federally overseen public-private partnership or self-regulatory organization, much like the Financial Industry Regulatory Authority (FINRA), with a board that includes independent leading technical experts and open-source representatives,” Hassabis wrote.

Microsoft’s big lead over AI competitors like Google and others has vanished, and the company is now playing catch-up. As a result, Microsoft’s stock has tanked in the last year — down roughly 23% compared to a year ago, due mainly to its massive AI spending and an inability to monetize Copilot. 

The company clearly needs to do something. And last week it did, though not what you might expect. It laid off 4,800 people, a little more than 2% of its worldwide workforce, with its Xbox division hit hardest. And it’s not reducing its massive spending on AI data centers or other AI-related costs.

The New York Times explained the cuts this way: “It is Microsoft’s latest employee culling as it plows tens of billions of dollars into the infrastructure for building artificial intelligence.”

Was cutting back on gaming (while still going all-in on AI) the right move for Microsoft? To answer that, let’s take a look at the details of the company’s July layoffs.

A year of layoffs

The recent cuts come in the wake of larger Microsoft workforce reductions over the last year or so. In May 2025, the company laid off 6,000 employees, about 3% of its workforce. Then a few months later, it laid off 9,000 more, about 4% of its workers. In both rounds of cuts, the company’s gaming division was hit — though it wasn’t the primary target.

This year, in April and May, the company rolled out its first voluntary retirement program for US employees. Approximately 3,000 people took the money and ran.

Then came last week, when Microsoft primarily targeted gaming. When the cuts take full effect over the next year, 2,850 gaming employees will be let go. In addition, Microsoft is cutting loose several of its gaming studio brands, which will become independent companies or be sold to buyers.

The layoffs hit the two remaining gaming studios, Activision Blizzard, which makes the big-selling games Call of Duty and Candy Crush, and ZeniMax Media, which publishes series including Fallout and The Elder Scrolls. Three years ago, in 2023, Microsoft bought Activision Blizzard for $69 billion. That followed its purchase of ZeniMax Media in 2020 for $7.5 billion. Both seemed like sizable acquisitions at the time. 

Compared to Microsoft’s AI spending now, they’re chump change.

Follow the money

A memo sent to employees about the July layoffs by Amy Coleman, Microsoft executive vice president and chief people officer, made clear the layoffs were more about AI than they were about gaming. 

Of the cuts, she wrote: “The “why” is this: our business is changing because the world around it is changing. The way technology is built, deployed, and used is transforming faster than at any point in my time here. Our customers’ needs are shifting, the business models that serve them are shifting, and that means the work itself — what we do, where we focus, and how we’re organized — has to transform, too.

“Our customers are navigating this same shift, and they’re counting on us to help them through it.”

That last sentence is an oblique reference to the early July launch of the Microsoft Frontier Company, which will embed 6,000 engineers inside customers’ businesses to help them more effectively deploy AI. The cost: $2.5 billion.

That sounds like a substantial amount of money. But it’s only a drop in the bucket of how much money the company plans to spend on AI. In April, Microsoft told investors it would spend $190 billion on data centers and other AI infrastructure this year, a 60% increase over what it spent last year. At the same time, Microsoft said it would shrink its workforce.

Its latest layoffs are clear-cut evidence of that. It’s also evidence that the company recognizes how badly Xbox has performed, and that it needed to do something about it. 

In early June, Microsoft sent a memo to everyone in its Xbox division entitled “Next 100 Days: XBOX Reset.” The memo laid out the problems with its ailing game business and pulled no punches. It noted that beyond the $69 billion the company spent three years ago to buy Activision, “Over the past five years, we have spent over $20 billion on ongoing investments in our content, platform, and hardware subsidy, but our annual revenue has declined nearly half a billion during that time. Going forward, this cannot continue.” 

The layoffs and spinoffs were the first steps. They won’t be the last.

There’s no doubt this is just the beginning of Microsoft’s disinvestment in gaming. The issue isn’t just that the company’s investments haven’t paid off. It’s that Microsoft’s AI ambitions are so large and expensive that it can no longer afford to seriously fund gaming.

Ultimately, it was the right thing to do, at least from a business perspective. The future is AI. It’s not in gaming.

So, for the foreseeable future at Microsoft, when it comes to AI — the sky’s the limit. But when it comes to gaming, things look much less rosy.

It’s been several years since generative AI and large language models (LLMs) took the world by storm. LLMs surpassed earlier natural-language systems at generating text, while diffusion models enabled generating images, music, and videos.

These generative AI models work well in the digital world, but on their own, they have limited capabilities to comprehend the three-dimensional physical world and other spaces. This includes the objects occupying an area, how they relate to each other, tracking movement, and answering complex questions requiring an understanding of dimensions, distances, motion, and collisions.

Spatial intelligence is an AI capability that allows models to reason about three-dimensional space. These models can generate 3D scenes of the world and other spaces. This content can then be displayed through traditional renderers, game engines, or AR/VR systems that use spatial computing techniques. But it’s the spatial intelligence model’s ability to connect natural language with 3D models that has the most applications in robotics, manufacturing, construction, and other physical environments.   

Dr. Fei-Fei Li, often called the godmother of AI, published a manifesto on how spatial intelligence is AI’s next frontier, contrasting it with LLMs. “While current state-of-the-art AI can excel at reading, writing, research, and pattern recognition in data, these same models bear fundamental limitations when representing or interacting with the physical world,” wrote Dr. Li. “Our view of the world is holistic—not just what we’re looking at, but how everything relates spatially, what it means, and why it matters. Understanding this through imagination, reasoning, creation, and interaction—not just descriptions—is the power of spatial intelligence.”

The concept of spatial intelligence isn’t new and was described in Howard Gardner’s book, Frames of Mind, in 1983. Recent breakthroughs, including the launch of World Labs’ Marble and its $1 billion funding round, and competing approaches from Google’s Genie 3 and Nvidia Cosmos, should put spatial intelligence and world models on more R&D road maps.

What are spatial intelligence models?

It’s important to develop AI literacy and understand the terminology and concepts related to the physical world and 3D AI technologies: 

• Spatial intelligence encompasses specialized approaches such as geospatial models for mapping the physical world and building information modeling (BIM) for modeling physical structures. It also extends to generative 3D, robotics, and physical reasoning applications.
• World models are a class of neural network architectures and are currently a prominent approach to building spatial intelligence.
• Digital twins are live, virtual replicas of physical assets that combine 3D models with real-time sensor data. Spatial intelligence, an emerging capability of digital twins, adds natural-language prompting, generative scenario exploration, and physics-aware reasoning.
• Spatial computing refers to digital content anchored in and interacting with physical space, sensed and rendered in three dimensions and delivered through AR/VR and mixed-reality systems.

“Spatial intelligence models go beyond pixels to understand the 3D structure of the world—how objects are positioned, how they move, and how they interact,” says David Fattal, founder and CTO at Leia. “This enables applications like more realistic video generation, spatial computing interfaces, and AI systems that can reason about physical environments. As real-world 3D data becomes more available, these models will become foundational to the next generation of visual AI.”

Monitoring the built environment

To better understand spatial intelligence, let’s consider physical infrastructure such as bridges and buildings. The American Society of Civil Engineers estimates a $9.1 trillion investment is needed from 2024 through 2033 to achieve a state of good repair. When maintenance and monitoring lag, it can lead to major failures such as the 2022 collapse of the Fern Hollow Bridge in Pittsburgh.

Spatial intelligence and the development of digital twins may help identify issues earlier and prioritize where investments are needed. “Spatial intelligence models serve as the 4D digital blueprints for our built environment, allowing us to visualize and predict the complex interactions between aging assets and the shifting ground beneath them,” says Patrick Cozzi, chief platform officer at Bentley Systems. “By synthesizing disparate geospatial data into a living digital twin, these models provide the foresight necessary to mitigate the hidden risks of structural fatigue and subsurface instability.”

There’s a significant challenge in bridge health monitoring and transitioning from manual, infrequent structural inspections to leveraging sensors, digital twins, and spatial intelligence. Cozzi adds, “This integration of continuous field data moves beyond static documentation, empowering agencies to evolve from reactive repairs to proactive, resilient asset management that safeguards the long-term integrity of our most critical public systems.”

Avoiding collisions

Bridges are largely static, but the real world is increasingly being occupied by autonomous systems such as self-driving cars, robots, and drones. And where there are moving systems, there is a risk of collisions.

“Spatial intelligence models are AI systems that reason about the physical world by combining vision, sensor data, and contextual cues to understand space, motion, and object relationships,” says Sudeep George, CTO at iMerit. “The value of spatial intelligence models lies not just in perceiving an environment, but in enabling machines to act within it safely and in real time. That is especially important in robotics and autonomous systems, where decisions must be made in complex, multimodal, fast-changing settings.”

To see one example, this tutorial for simulating robotic environments combines Nvidia Isaac Sim, an open source robotics reference framework, with spatial intelligence in Marble from World Labs. 

Today’s collision detection systems, such as those used in autonomous vehicles, typically rely on modules for sensing, perception, planning, and control. Spatial intelligence models may offer improvements by assessing the collision risks of unidentified objects or by tracking objects that move out of sensor view. For example, Waymo’s World Model, built on Genie 3, is a simulator that generates complex weather conditions and other critical safety events.

For an out-of-this-world example, James Urquhart, field CTO and technology evangelist at Kamiwaza, has delivered several examples of spatial intelligence applications, including one for satellite collision detection and conflict analysis. Urquhart says, “Models that specialize in these types of data sets, as well as the physics and geography of the real world, enable faster and more accurate decision-making for tasks that depend on them.”

Applying spatial intelligence

Recent spatial intelligence announcements include creating 3D worlds from image or text prompts with Marble and simulating water physics, lighting, weather, and animal behavior with Genie 3. But difficulties remain in bringing spatial intelligence to physical-world use cases.

“Spatial intelligence and world models are laying the groundwork for future AI agents that will be able to interact in and with our physical world,” says Jason Corso, cofounder and chief scientist at Voxel51. “These models are significantly more challenging to develop and test, largely because the data underlying their development is complex, and it’s hard to handle all of the combinatorics involved in the physical world.”

In addition to learning the models and prototyping with them, development and data leaders need to review the data assets that will feed spatial intelligence models. “Spatial intelligence models translate location signals into a structured understanding of the real world, but they’re only as reliable as the data beneath them,” says Dan Adams, executive vice president and general manager of Enrich at Precisely. “The real unlock isn’t the model—it’s the reference layer with persistent identifiers, confidence metadata, and source lineage that lets AI reason about places, not just match strings.”

Even once applications are developed, there will be infrastructure challenges in deploying them at the edge. Ali Kayyam, principal research scientist at BrainChip, says, “The key to unlocking spatial intelligence at scale is having the low-power, event-driven hardware that can run it at the sensor in real time where it matters most.”

Where to get started

My suggestions for developers looking to get hands-on with spatial intelligence and world models:

• To try out Marble, review their API documentation and case studies, and then experiment with a developer-focused React application.
• Review the Nvidia Cosmos developer hub, documentation, and cookbook of case studies and learning paths.
• You can get an overview of Genie 3, but access is currently restricted through Project Genie, which requires a Google AI Ultra subscription.

The model of the forward deployed engineer is sweeping through enterprise IT like a gold rush, and I’m concerned that many companies don’t understand what they’re signing up for.

Let’s start with the headline numbers. AWS announced a $1 billion investment in a new Forward Deployed Engineering organization. Google Cloud committed $750 million to expand similar programs. Microsoft has been running Azure-focused embedded engineering teams for years, including partnerships with Accenture to scale forward deployed engineering practices. All three are pitching the same story: We’ll send engineers to work directly with your teams, help you deploy AI, and accelerate your digital transformation. You get top-tier technical talent for free, and we get to partner with you on your journey.

It sounds reasonable on the surface. It sounds collaborative, even generous. But I’ve been in this industry long enough to know that when a multi-billion-dollar company offers you something for free, they’re sure to get much more than they give.

What you actually get

The forward deployed engineer model isn’t new. The consulting industry has been doing some version of it for decades. What makes this different is the scale and the direct financial incentive behind it.

These engineers work for the cloud provider. They’re not your employees. They’re not independent consultants. They’re technically excellent professionals who are being paid to solve your immediate problems while simultaneously building relationships and architectures that favor their employer’s ecosystem. Think about it from their perspective. Those forward engineers are evaluated on whether customers succeed with their employer’s platform. They’re rewarded when enterprises adopt more services from that platform. Their career advancement depends on making AWS, Google Cloud, or Microsoft Azure the obvious choice for all of your technical decisions.

This isn’t a criticism of the individual engineers. Many of them are genuinely talented and genuinely want to help. But they’re operating within a system that rewards specific outcomes, and those outcomes align with the vendor’s financial interests, not necessarily yours.

The problem no one talks about

Here’s what I see happening at enterprises right now. A company decides they need help deploying AI. A cloud provider offers to embed engineers at no additional cost. Those engineers work alongside internal teams, make architectural recommendations, and help build out systems. Six months later, the company has a production AI system running on a single cloud platform, built by people with deep expertise in that specific platform.

The problem? Nobody evaluated whether that platform was actually the best choice for the business. Nobody looked at alternatives. Nobody asked whether a multicloud architecture or best-of-breed approach might deliver better results at lower cost.

The engineers embedded in these programs are not going to recommend that you split your workloads across providers. They’re not going to suggest you use open source tools where they make sense. They’re not going to point you toward a competitor when their employer’s solution will work well enough. That’s not how these programs are designed to function. What you’re getting is optimized architecture for a single cloud brand, not optimized architecture for your business.

The financial reality will hit

The bills are going to come due, and they’re going to be painful. I’ve watched this pattern play out before. When enterprises lock into a single cloud provider through these embedded engineering programs, they often discover two or three years later that they’re paying premiums that their more independent-thinking competitors avoided.

The reasons are straightforward. When you’re architecting systems around a single platform, you naturally fall into usage patterns that favor that platform’s pricing structures. You use their managed databases instead of portable alternatives. You adopt their AI services instead of evaluating third-party options. You build workflows that only work within their ecosystem. And when it comes time to renegotiate or benchmark against alternatives, you find that migrating would cost more than accepting whatever pricing they offer.

I’ve spent the past decade helping companies untangle from these situations. I’ve seen organizations with cloud bills 15 to 20 times higher than they should be, unable to migrate because their entire AI infrastructure is built on proprietary services that only work on one platform. The forward deployed engineer programs are accelerating this problem. They’re making it easier to get into these situations and harder to get out.

Think before you commit

Before you accept one of these programs, consider these three recommendations.

First, require independent architecture oversight from day one. Hire or engage architects who work for your company, not for your cloud provider. They should evaluate every recommendation made by embedded engineers against business requirements and compare options across providers. This isn’t about being suspicious of the engineers. It’s about ensuring that decisions are made with your interests in mind.

Second, demand a clear exit strategy before you begin. Ask the cloud provider to document which proprietary services you’re using, what migration paths exist, and what the cost would be to move to an alternative platform. If they can’t provide that information, or if the migration costs seem impossibly high, that’s a sign that you’re building technical debt that will be very expensive to service later.

Third, benchmark your costs continuously. Set up internal processes to compare your cloud spending against industry benchmarks and against what your competitors might be paying for similar workloads. Don’t wait until your contract renewal to discover that you’re paying premium prices. Monitor expenses from the beginning, and be willing to challenge your cloud provider if you’re not getting value that justifies the cost.

The bottom line

The forward deployed engineers are solving real problems. Enterprises genuinely struggle with AI deployment, and having experienced engineers available to help is valuable. I’m not suggesting these programs are fundamentally bad. However, they’re being marketed as neutral partnerships when they’re actually strategic sales programs designed to lock enterprises into specific platforms. The helpful engineers showing up at your office are building dependencies that will be very difficult to break. The “free” technical assistance is being funded by margins on services you’ll be buying for years.

Go in with your eyes open. Use these programs but add your own independent oversight. Build architectures that you could leave if you needed to. And don’t let the immediate satisfaction of having problems solved today blind you to the financial consequences that will arrive tomorrow.

For all its potential, generative AI, on the whole, churns out a lot of junk.

Yet employees are becoming ever more reliant on this “workslop” masquerading as high-quality material, says a recent Harvard Business Review blog. They become lazy and less productive, quality control goes off the rails, and integrity and trust begin to erode.

Experts urge enterprises to act now, before they lose control entirely.

“When slopification happens at scale and in sequence across a business’s processes, those processes themselves — and their outputs — start to deteriorate,” Matthias Holweg, professor at the University of Oxford’s Saïd Business School, and analyst Thomas H. Davenport argue in the post. “Eventually, people start to lose trust in the processes that they rely on to do their jobs.”

They call this organization-level phenomenon “knowledge decay.”

Three key challenges

Holweg and Davenport identify three key challenges to address when it comes to AI-generated content in the workplace, to ensure knowledge decay isn’t occurring: verification, validation, and entropy.

Verification requires “disentangling” authentic human content from AI-generated content that could contain glaring errors, they note.

This can be time-intensive and involve critical thinking and additional research, and in many cases the effort negates the gains gleaned from AI use. In the case of hiring, for example, in addition to using AI to write their resumes and CVs, tailoring their prompts to the AI ranking algorithms to ensure they rise to the top of the queue, some candidates are getting crafty, using AI clandestinely to generate responses to interview questions in near-real time.

All this taken together can result in candidates who are subpar or simply not a good fit for an organization. As a result, recruiters may then have to spend more time doing on-site interviews where AI access isn’t available, Holweg and Davenport contend.

Another issue is knowledge validation: confirming how and where humans have provided real value when AI is used in a workflow. For instance, a consulting firm can easily use AI to create standard written reports and PowerPoint slides, while their clients are paying for expert human insights.

“Human experts now have to justify not only the quality of the output submitted, but also that actual human intellectual work has produced it,” Holweg and Davenport emphasize.

Finally, knowledge entropy is like a “risky AI-based game of telephone”: As knowledge is passed through an AI again and again in an iterative process, it moves further away from the original “ground truth” data that was used to create it in the first place, they point out.

“The greater the number of iterations of content through an LLM, the more it will depart from the original,” Holweg and Davenport note. LLMs are probabilistic, “context-agnostic” statistical models that provide next-word-prediction outputs. They have “no conception of fact or truth and simply predict the most likely outputs,” they write.

And when, in some cases, large language models (LLMs) are trained on synthetic data created by other models, the authors write, bigger problems emerge. When this manufactured data subsequently repeatedly goes through the model, it can affect the its accuracy and variability. This is known as “generative inbreeding” or model collapse.

Steps enterprises can take to prevent AI slop

The two experts, therefore, argue for a “fundamental step change” in the ways models are architected, as well as in establishing explicit rules around how they are used.

Naturally, one of the first, and potentially the hardest, steps is restricting employee AI use: It should only be applied to scenarios where it truly adds value, the authors advise.

For instance, when employees or job candidates are allowed to freely design their CVs, they’ll likely use generative AI to “optimize” their work. To prevent knowledge decay, recruiters should rely on structured documents that require factual responses that an AI can’t generate, for example, asking a candidate about a specific role, projects completed, team members involved, suppliers served, and budgets managed.

When generative AI use is allowed or unpreventable, organizations should define what value is being added and establish clarity around the implications, Holweg and Davenport emphasize. “Content does not need to be entirely human-created, but if AI is being used, be clear why and how,” they write.

In one beneficial scenario, AI such as Copilot or Gemini embedded in standard office software makes it “virtually pointless” to manually create more versions of the content of reports and PowerPoint slides, Holweg and Davenport write.

In another example, in performance evaluations, managers can gather specific, detailed information from team members and customers, then use AI to synthesize that material, rather than generating a “tick-box report” of generic bullet points.

Enterprises should also consider how individual AI use impacts an overall process. For instance, in an interorganizational flow like a revenue cycle, everyone involved should know about and agree on how AI would be used and at what steps in the process. It’s not a question of whether AI is better at a given task, as it increasingly is in some scenarios, but whether it is taking over a task to make things more efficient, Holweg and Davenport write.

Ultimately, however, they posit, public LLMs add “little to no real value,” because they are generic and often contain mistakes. On the other hand, small language models (SLMs) and proprietary models trained on company-specific data can augment human work.

From an architectural perspective, enterprises should track the history of both structured and unstructured data and understand “ground truth” information. Materials like customer interviews provide critical facts, emotions, and context; if AI is used to alter or summarize these, enterprises must identify and record the underlying ground truth data and point back to verifiable, authentic content.

In the end, Holweg and Davenport emphasize, enterprises should establish pragmatic practices now, lest they repeat the mistakes of the past.

“If we fail to address the uncontrolled proliferation of generative AI in our business processes, we are likely to see a rerun of the ‘productivity paradox’ observed with the growth of corporate computing half a century ago,” they write.

Blending ‘human capital’ and ‘token capital’

Other experts also agree on the importance of blending the best of humans with the best of AI.

Microsoft CEO Satya Nadella describes this model as the incorporation of “human capital’ with “token capital.” The former is the human “knowledge, judgment, relationships, ingenuity, and pattern recognition,” while the latter is in built and owned AI capabilities. The opportunity is in melding the two in a learning loop.

In this loop, humans will guide AI systems, set goals, and identify patterns, so AI isn’t “running in circles,” Nadella wrote in an X post. Internal evaluations can determine whether AI is improving when measured against company-specified benchmarks, thus creating institutional memory that is “query-able,” using fewer tokens and saving enterprises money.

Nadella noted: “Every improved workflow generates a better training signal, which accelerates the accumulation of tacit knowledge unique to the firm.”

This article originally appeared on CIO.com.

Enterprises implementing agentic AI face a challenge: Which tools should they allow their agents to use, where can they be found, and how can they be used safely? A new protocol, Agentic Resource Discovery, or ARD, aims to let agents answer those questions for themselves. Behind it are Google, Microsoft, Cisco, Nvidia, Salesforce and others.

ARD aims to standardize the way that tools and services are shared across systems within a corporate domain. For example, when investigating a production problem, an agent may want to query engineering documentation and open support tickets, deployment history and observability systems, all of which could be managed by different registries and across different silos. There is no common layer that pulls them together. ARD has been designed to be that layer.

It operates across two levels. Catalogs and Registries. In the first, an organization publishes a catalog setting out its available capabilities. The Registries layer act as a form of search engine, crawling those published catalogs.

The ARD specification is available now. Organizations are invited to publish their own catalogs using the quickstart guide. After this, they are able to join the community and participate in the evolution of ARD.

This article first appeared on InfoWorld.

Enterprises implementing agentic AI face a challenge: Which tools should they allow their agents to use, where can they be found, and how can they be used safely? A new protocol, Agentic Resource Discovery, or ARD, aims to let agents answer those questions for themselves. Behind it are Google, Microsoft, Cisco, Nvidia, Salesforce and others.

ARD aims to standardize the way that tools and services are shared across systems within a corporate domain. For example, when investigating a production problem, an agent may want to query engineering documentation and open support tickets, deployment history and observability systems, all of which could be managed by different registries and across different silos. There is no common layer that pulls them together. ARD has been designed to be that layer.

It operates across two levels. Catalogs and Registries. In the first, an organization publishes a catalog setting out its available capabilities. The Registries layer act as a form of search engine, crawling those published catalogs.

The ARD specification is available now. Organizations are invited to publish their own catalogs using the quickstart guide. After this, they are able to join the community and participate in the evolution of ARD.

Google, Microsoft, OpenAI, and others want to help enterprises demonstrate that their AI applications are behaving themselves through the creation of a new foundation.

The Appia Foundation will, it explained rather impenetrably, “establish modular specifications that provide a connecting layer to bridge foundational global standards with practical, trusted assessments across the global AI value chain.”

Those specifications will help AI users ascertain whether the systems they are using meet all the obligations that apply to them in the form of standards and regulations, it said. It’s a challenging task with so much regional variation in requirements, and where the EU, for example, is more tightly controlled than the US.

The Foundation has established a set of criteria to demonstrate conformity with what is expected. There are two layers: the Requirements and Guidance layers will help users determine what is actually required, while the Assessment Enablement layer will look at how those requirements are evaluated.

Appia stressed that what it is offering are not standards — which are set by recognized international bodies such as ISO/IEC — but a means of assessing what those standards mean and how they can be used by organizations. However, the Foundation said that some of the criteria that it is introducing may become standards themselves after a period of time.

The Appia Foundation is hosted by the Linux Foundation’s Joint Development Foundation, and its other members include Arm, Ericsson, Mastercard, Mitsubishi Electric, Omron, Schneider Electric, and Siemens. It is also looking to bring academics and government into the fold, so that it can establish an advisory board.

This article first appeared on CIO.

Google, Microsoft, OpenAI, and others want to help enterprises demonstrate that their AI applications are behaving themselves through the creation of a new foundation.

The Appia Foundation will, it explained rather impenetrably, “establish modular specifications that provide a connecting layer to bridge foundational global standards with practical, trusted assessments across the global AI value chain.”

Those specifications will help AI users ascertain whether the systems they are using meet all the obligations that apply to them in the form of standards and regulations, it said. It’s a challenging task with so much regional variation in requirements, and where the EU, for example, is more tightly controlled than the US.

The Foundation has established a set of criteria to demonstrate conformity with what is expected. There are two layers: the Requirements and Guidance layers will help users determine what is actually required, while the Assessment Enablement layer will look at how those requirements are evaluated.

Appia stressed that what it is offering are not standards — which are set by recognized international bodies such as ISO/IEC — but a means of assessing what those standards mean and how they can be used by organizations. However, the Foundation said that some of the criteria that it is introducing may become standards themselves after a period of time.

The Appia Foundation is hosted by the Linux Foundation’s Joint Development Foundation, and its other members include Arm, Ericsson, Mastercard, Mitsubishi Electric, Omron, Schneider Electric, and Siemens. It is also looking to bring academics and government into the fold, so that it can establish an advisory board.

This article first appeared on CIO.

Because generative AI (genAI) tools and services have become so ubiquitous (and popular), the costs of using them are going through the roof — leading to an insatiable appetite for tokens.

Tokens represent a common way to measure and price AI use. Much like letters and words in English, large language models (LLMs) grasp a sentence or query by breaking words into tokens.

With the AI explosion well under way, tokens are now “the fundamental units of data our models process, many representing a problem being solved,” according to Google CEO Sundar Pichai. (Google, by the way, processes about 3.2 quadrillion tokens a month.)

But as the price of all those tokens adds up, business and IT execs are looking for ways to cut costs while keeping corporate productivity up. Uncontrolled token use has already landed one company with an unexpected $500 million AI bill. 

There are a number of ways companies can rein in the price of AI at the model, infrastructure, silicon, and business levels. Here’s a look at how some of those savings might actually be achieved.

Switch to lower-cost models

One way of potentially saving money is by re-routing AI work to a cheaper model, Pichai said. At Google that would Gemini 3.5 Flash. It delivers “frontier-level capabilities at less than half the price of comparable frontier models.

“If companies use a mix of [Gemini 3.5] Flash and other frontier models, they could save a lot of money,” Pichai said.

Those kinds of models provide cheaper tokens, with reasoning that’s good enough for many users — if not as strong as mainstream Gemini 3.5 — to deliver useful results.

“There is sometimes overkill with the [LLMs],” said Deepak Seth, senior director analyst at Gartner. “I don’t always need a large language model which has been trained on the works of Charles Dickens and Shakespeare and Harry Potter.”

Hyperframe Research principal analyst Steven Dickens can’t stop using Amazon’s Quick, which costs $20 a month, for personal tasks. “It is great personal ROI as it has not only made tasks faster, but unlocked tasks I would never have even attempted previously,” Dickens said.

Don’t forget the hardware and software part of the equation

The token crisis isn’t new, said Dheeraj Pandey, CEO of DevRev, who likens what’s going on now in the AI market to the disruptions that emerged with the arrival of cloud computing and virtualization years ago. 

“We let chaos reign and then we had to rein in the chaos,” Pandey said. “The word that people started using was server consolidation and virtualization.”

The answer to the token problem, he said, is the same: “Anything in systems can be solved with caching and indirection.”

DevRev, for example, is building a memory layer between AI agents and primary data sources, such as Salesforce or ERP records; that can cut token load and make data movement more efficient. The layer holds a knowledge graph with answers to common agent questions and runs on cheaper CPUs, avoiding more costly GPU cycles.

Sending agents straight at systems like ServiceNow and Salesforce “will burn a lot more tokens. It’s also not precise. And finally, it’s not safe enough where I can roll it back in case an agent has committed a mistake,” Pandey said.

Network automation firm NetBrain uses a different method: It uses conventional computing to map a network’s layout then feeds only key information to models for planning and reasoning, where AI excels. “So you don’t have to spend all the tokens,” said Netbrain CTO Song Pang.

Focus on prompt efficiency

Staffing firm ManpowerGroup has found that prompt efficiency can be an effective tool for improving token use, both internally and externally for clients.

For example, users accessing its internal labor-market tool initially needed 10 follow-up questions to drill into a query. A year later, more efficient use of prompts has brought that number down to an average of four, said Max Leaming, head of data science and AI solutions at ManpowerGroup. 

“They’re using fewer tokens and they’re simply more efficient,” he said. “And that in large part has to do with your ability to prompt efficiently.”

Go local

New AI hardware that generates free tokens at home could ease some of the cost crisis.

At GTC Taipei earlier this month, Nvidia and Microsoft unveiled RTX Spark, an agentic AI desktop PC that runs agents and 120-billion-parameter models locally on Windows. The goal is “to deliver unmetered intelligence to every home and every desk with Windows,” Microsoft CEO Satya Nadella said in a statement.

Some companies are looking to reduce cloud AI costs by putting their own hardware in data centers, with vendors such as HPE and Dell providing servers installed in independent facilities. (On-premise AI is gaining ground amid sovereign AI and geopolitical concerns, including the recent conflict in the Middle East, where large data centers were struck with missiles.)

“There are local, region-specific and multiple vendor AI solutions. All of those things can help mitigate the risk. But they’re not going to eliminate it,” said Max Goss, senior director analyst at Gartner.

Use forward-deployed engineers

Reducing token costs is something that may fall to forward-deployed engineers (FDEs) in customer environments, said Taimur Rashid, managing director of AWS’s Generative AI Innovation Center.

“I expect these teams to be able to architect systems that have those cost requirements in mind, whether it’s use a different model or a different use case that doesn’t increase the per-token cost,” Rashid said.

Companies may spend heavily on token consumption, “but if you’re generating revenue, as long as the economics work out, then you’re at peace,” Rashid said.

The use of FDEs is gaining ground as IT decision-makers look to both rollout successful AI deployments while also keeping an eye on costs.

Change the measure of success from tokens to outcomes

Even with the current emphasis on reducing token use to save money, the metrics used to measure AI success are likely to shift, Gartner’s Seth said. At some point, token-based pricing will move more toward an outcome-based model, where the unit of value is outcomes, not fragments of words.

“Some companies are moving towards outcome-based pricing,” Seth said. “When people start realizing the real cost of tokens, then companies will start looking at token efficiency.”

Hot AI companies can’t stop talking about forward-deployed engineers (FDEs), which are now very much in vogue. 

FDEs, in case you haven’t heard, are hired by companies looking (hoping?) to successfully deploy AI tools and services. It’s one of the hotter professions in a world still trying to understand the impact of AI on careers.

So, what exactly are FDEs — are they techy lone rangers like the ones OpenAI, Google and Microsoft are hiring? Turns out it’s not so much about individual engineers who swoop in to design and roll out AI deployments; it’s more about a team of engineers working together at customer sites.

At least, that’s the view at Amazon Web Services (AWS).

In fact, according to Taimur Rashid, managing director of the AWS Generative AI Innovation Center, the FDE concept pre-dates the current generative AI (genAI) gold rush. The same kinds of engineering teams were needed for the earlier machine-learning and cloud eras to help companies with deployments.

Rashid recently talked about how AWS sees FDEs as a profession in a conversation with Computerworld. And he weighed in on the desired job skills the company seeks in this increasingly AI-centric era.

What is an FDE? “We view it as a team. It’s a cross-functional team that has engineers, scientists, strategists, and folks that can piece technology and business together. In some cases, we do have to have security engineers in there, too. 

“I see them as anesthesiologists. They have to prep so many things, monitor things throughout. We see ourselves as a frontier deployment team helping customers adopt all forms of AI, whether it’s genAI, agentic AI, even emerging trends like physical AI. We’re helping these companies become frontier themselves.”

How does an FDE engagement begin, and how is it structured? “Where we see the forward deployed model is when customers come in — for example, we have our executive briefing center in Seattle and in Arlington, VA. When customers share what they’re trying to do, very quickly a customer’s like, “What’s the quickest way I can go and build something with you?” 

“We’ll forward deploy our people in, we’ll embed them in your business and we’ll go through these 45-day sprints that we typically design. Through those successive sprints, we’re building stuff together, we’re proving value, and then they can expand that to a much broader engagement.

Where do FDEs actually sit? Client side, internally, or in-between? “It’s mixed, and it largely depends on what the customer’s preference is. We’ve seen models where the customer has been very adamant that, ‘We want your teams with us in our business.’  In those cases, we forward deploy the majority of the teams on site. 

“We have models where customers are fine with you being wherever you’re based, as long as you’re still embedded virtually. And then there’s a hybrid. We deploy anywhere from five to seven people. Sometimes, the baseline is actually three.”

Will cost savings be the job of an FDE, or someone else on the team? “I expect these teams to be able to architect systems that have those cost requirements in mind, whether it’s use a different model for a different use case that doesn’t increase the per-token cost…or think about ways where you can use semantic caching. I personally think you may have a high spend in token consumption, but if you’re generating revenue, as long as the economics work out, then you’re at peace.”

What challenges have you gone through deploying FDEs in the real world? “One of the challenges worth highlighting is when customers get really excited about us forward deploying resources, what they end up realizing is [that] they’re not set up to absorb that right away. They realize they have to go through … process-related things, security access — all those operational things. 

“One very good example is the Commonwealth Bank of Australia. They said: “Prioritization’s a big thing, and if you forward deploy and you’re 100% dedicated, how do we ensure that our teams are also equally 100% dedicated?’ When you’re sitting in your office, you’re distracted by your day-to-day. So they said, ‘Why don’t we create a neutral ground in Seattle? You fly your people, we’ll fly our people. We’ll give them three weeks of dedicated time so they have no distractions.’”

Have you gone into projects where they want AI but have no security or governance ready? “I’ve been through this before, certainly. We do see customers that have security processes and capabilities, but it’s not as tight as it should be in the age of AI. Governance is the biggest area where customers right now have the biggest gap. I’m talking governance around agents. In the past two months, almost 100% of the conversation around agents is not about capability. It’s all about governance. 

“That is a big area right now where forward deploy teams are helping with governance education, and building the scaffolding for that.”

How does software engineering fit into the FDE model? “One of the greatest learnings is that as we forward deploy resources and get customers to take AI and integrate it into their systems, the knowledge of software engineering is so important. Today, a customer can use one of the Claude models and scan their code base and look at vulnerabilities. 

“The tough part is not assessing those vulnerabilities, it’s remediating [them]. Remediating [them] requires software engineering experience, because you have got to merge code, test it, deploy it. We largely see that the frontier software development teams are smaller and they’re managing agents that are doing various tasks across the software development lifecycle.”

AWS has many models at your scale, open source, closed — it’s more complex than what other AI vendors offer.  How do you nail down the talent? “It’s massive, and when you look at not only scale, it’s the complexity of the stack. We take an approach where we fundamentally do three important things: No. 1, we want to ensure people understand concepts; they have to understand pre-training, post-training, reinforcement, fine-tuning. 

“Secondly, we make sure that our teams are well versed in their first-party services. The third thing is that by design, AWS has always been about choice. We say, ‘Let’s do 80-20 here. What is 20% of those specialties that we need to have, which can cover 80% of what most customers are trying to do?’”

What skills should software developers learn to move into FDE work — the top three or four things? “We look at three categories. First category is entirely functional. Are they more engineering specific? Are they science specific? Are they security specific? Our litmus test is not only knowledge of the function, but the actual hands-on work that they can do with it. Secondly is around domain. I focus on what is their domain understanding across the whole AI lifecycle? The third thing is cultural. We are looking for folks that are okay at dealing with ambiguity, being good at stakeholder management, and having that startup mindset. 

“This AI transformation’s not for the faint of heart.”

There’s a rush for FDEs from OpenAI, Google, and others. What’s different about what you look for? “I don’t know entirely what the others are looking for, but I’ll tell you what we have been looking for in the past. When we hired solution architects, it was about systems level understanding. But what I see more and more is hands-on experience, cultural mindset, all these things are very important. If I had to pick one thing that is going to be very important in the talent that we either upskill or future talent that we hire, it has to be the application of AI towards software engineering and system integration tasks.

You’re upskilling AWS talent as well? “We do. You will see some publications coming out in the next couple of weeks around how do we do this across our software teams and how does that translate to customer-facing roles.”

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

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

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

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

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

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

Standards must evolve for AI

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

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

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

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

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

A question of governance

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

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

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

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

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

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

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