Anthropic has a $100 million plan to help enterprises get more from AI. No, it doesn’t involve agents. It involves people. Lots of people.

How retro.

On October 2, the company announced Claude Frontier Academy, with a goal of training 10,000 frontier deployed engineers by the end of 2027. Participants work through a simulated deployment, including use-case selection, security review, and handover, before undertaking a 12-week residency on a real project at their own company.

For a business selling increasingly capable models, it’s telling that Anthropic recognizes some of the thorniest problems in AI don’t involve AI at all. This, to me, is indicative of real progress, because the heart of any technological shift is always people.

Which people? Well, that’s where this idea becomes particularly interesting. As critical as developers are to the success of AI in any particular organization, we need those developers working alongside the people who understand the business, with authority to turn that understanding into systems that other employees can use. That’s the key to AI success.

Old advice for a new assignment

It has always been thus, however much we try to pretend that this time it’s different. Back in 2013, I quoted Gartner analyst Svetlana Sicular discoursing on the rise of big data technologies like Hadoop: “Organizations already have people who know their own data better than mystical data scientists.” She continued, “Learning Hadoop is easier than learning the company’s business.” Data becomes useful when paired with industry expertise—from experts who understand which data actually matters.

This topic is perpetually relevant. I covered the argument in 2023 and again in 2025. We’ve always needed people who can translate business requirements into software.

AI expands the kinds of knowledge that software can work with. Language models extend that work to material that often sat outside our applications: research notes, meeting transcripts, internal debates, and explanations of why a decision was made. An employee can ask questions across that material without someone first designing a report for every possible question. That opens up useful work that would have been difficult or expensive to automate before.

It also creates new ways to be wrong. A model may find a convincing explanation that was superseded six months ago, confuse a proposal with an approved policy, or combine two departments’ incompatible definitions of a customer. The people who understand those distinctions need to help engineers make them explicit, then build examples that reveal when the system gets them wrong. Companies that figure this out stand to benefit disproportionately; hence, PwC’s April survey of 1,217 senior executives found that companies reporting the strongest AI performance were twice as likely to redesign workflows around AI.

Teach the system what’s good

Bridgewater, the world’s largest hedge fund, has done some interesting work here that substantiates this theory. At AI Engineer NYC on October 13, two representatives of Bridgewater described Vault, its repository and access layer for external and internal unstructured information. Vault isn’t designed to be a dumping ground; instead, the company has shaped the way it stores data to make it useful for analysts.

I attended the talk and watched as Sam Green demonstrated a question about AI infrastructure investment and the Korean won. Left on its own, a web-connected AI agent relied on July material to answer a question posted in October. Hedge funds depend on up-to-the-second information to figure out optimal trades, making this initial attempt a failure. Connected to the human-influenced Vault, however, it searched October 1 through October 8 and drew on seven documents rather than one or two.

Knowing which period matters is part of understanding the investment question; making the right material available consistently is an engineering problem. You need both. A plausible answer assembled from stale research can be worse than an obvious failure because it gives the investor little reason to investigate further. The team also collected roughly 200 questions and manually identified useful documents, including misleading matches. Bridgewater’s Aaron Linsky reported that subsequent improvements lifted the share of relevant documents among the top 10 search results from about 60% to between 90% and 95% on that evaluation.

This method is useful well beyond investing. Someone has to distinguish a document that merely sounds relevant from one that actually helps answer the question. Engineers can then use those judgments to measure whether a change improves the system. Business expertise becomes something the team can test against, rather than advice delivered after the application has shipped. It’s not a case of human intelligence or artificial intelligence. You need both.

Make the expertise usable

Of course, a skeptic could reasonably ask why a model can’t learn the business, too. It’s a fair critique, as AI can learn a great deal of it. After all, that’s the reason Bridgewater (and others) make a point of supplying the right documents, definitions, and examples. This ensures AI can take on more of the analysis, thereby reducing dependence on the few employees who currently carry essential knowledge in their heads.

But access to every document doesn’t settle which policy is authoritative when two departments disagree. Nor does it authorize a change to an approval process or establish who owns a mistake. A model can help expose contradictions and propose resolutions, but someone with responsibility for the business has to decide which resolution the company will adopt.

Of course, most companies don’t have Bridgewater’s decades of codified investment knowledge. They may also have conflicting definitions scattered across spreadsheets and a few employees who know why the official process doesn’t quite describe reality. Nor does it make sense to search for one extraordinary hire or a star employee who knows every model, understands every department, and can persuade everyone to change. (Good luck with that!) After all, someone with deep knowledge of the business may also be the exact wrong person to help an organization evolve, wedded as they may be to how things have always been.

Gartner’s Sicular was right about the value of people who understand the business. AI gives companies more ways to put that understanding to work. Give those people engineers to build with, authority to resolve disagreements, and responsibility for leaving behind a system someone else can operate. We need AI challenging people, and people challenging AI.

In olden days — last year, say — employees using unsanctioned AI tools might copy-and-paste sensitive data that could end up in the AI company’s training data set.

Today, an unsanctioned AI can hack into another company for an employee even if they didn’t explicitly ask it to.

This doesn’t just mean the latest unreleased frontier models undergoing security testing. Claude, ChatGPT, and Gemini have all evolved from being mere chatbots, answering questions and helping people write emails. They now have agentic capabilities and are able to carry out complex tasks on behalf of users.

And they do, sometimes to dangerous effect.

In August, ABC News in Australia interviewed a man identified only as “Andrew” who asked an AI agent to sign him up for a gym class. The agent hacked into the gym’s system and deleted someone else’s wait list reservation.

The AI was Anthropic’s Claude, and the agentic framework was OpenClaw.

Now imagine an employee asking their agentic AI assistant to help them make a sale. The request might inadvertently inspire the agent to hack into the prospect’s company.

To keep this — and other worst-case scenarios — from taking place, enterprises are building guardrails around their AI systems, restricting what data the AI has access to and what tools it’s allowed to use.

But none of those guardrails will work if the employee uses a tool that their company doesn’t know about.

“This is a problem we’ve long had,” says Matt Butkovic, technical director for cyber risk and resilience in the CERT division at Carnegie Mellon University’s Software Engineering Institute. “People will find ways to purchase or get access to things they think are useful, even when an organization says you probably shouldn’t do that.”

Ten years ago it was personal email and unauthorized cloud storage.

“The stakes are higher in some ways now,” adds Butkovic, who also teaches in CMU’s CISO program.

Verizon’s 2026 Data Breach Investigations report, released in May, shows that 67% of employees access AI services through non-corporate accounts on corporate devices. Shadow AI was the third most common non-malicious insider action detected in Verizon’s 2025 data loss prevention dataset.

And a May analysis of 1.9 million AI session minutes conducted by Harmonic Security found that when employees accessed personal accounts, 65% of their activity was related to business. They used personal accounts to write work emails and debug code, and even used it for legal work.

In a separate report, released in July, Harmonic reported that every organization the company monitored in the first half of 2026 had at least one employee sending data to a China-based AI tool. The uploaded data included M&A plans, source code, financial projections, and legal material.

To address this problem, enterprises are taking a fourfold approach:

• Figure out what employees want to use AI for and give them sanctioned, safe alternatives.
• Use security tools to monitor activity and keep employees from sharing sensitive data with unsafe systems, or even accessing them at all.
• Educate employees on the risks of AI and how to use it safely, because you can’t solve this problem with technology alone.
• Hold employees accountable when they violate AI policies.

Blocking DeepSeek at a financial services firm

BitGo, a Fortune 500 financial services firm with over $100 billion in digital assets under custody, uses a combination of strategies to combat unsanctioned AI.

“We have enterprise versions of Grok, ChatGPT, Claude and Gemini,” says Manny Khan, the company’s deputy CISO. “We are an AI-first organization. We encourage all of our people to use AI in their work, to try to automate as much of it as possible while keeping the human in the loop to avoid any slop.”

Unsanctioned AI is an industry-wide concern, he says, and having a sanctioned alternative is key.

“We encourage folks to use what is approved and has guardrails and harnesses and trust boundaries and safety checks,” he says.

To make the sanctioned alternatives easier and more appealing, employees use single sign-on, provided by Okta, to log into systems, and the enterprise-grade models also connect to the company’s MCP servers.

Once employees have a safe AI option to use, the next step is to get a handle on the unsafe ones.

For example, BitGo uses a data loss prevention tool from Cyberhaven. DLP was a useful security tool long before AI came along, but today it also helps ensure that sensitive data isn’t copied-and-pasted into untrusted chatbots.

“All traffic is proxied and analyzed by our security tools to identify anything potentially malicious, shut it down, and not allow the connection if it’s a site known to be malicious,” Khan says.

For example, the company blocks DeepSeek, a Chinese AI model. “We don’t want their models to train on our data,” Khan says.

But there’s only so much technology can do.

“Every site has AI now, and we cannot block every single site,” Khan says. “We might as well block the internet at that point.”

That’s where human awareness and education come in, says Khan.

“We do train people,” he says. “And we have an AI governance policy that we share company-wide and enforce this policy by tracking and measuring against it.”

It’s important for a company to have a single voice on AI use, a central figure with authority and ownership who can provide guidance, he adds. “Otherwise, you’ve got a lot of people who try to figure it out on their own. And that’s what you don’t want.”

Docusign on guard against agentic AI

“We want to educate users to do the right things, but people still want to experiment,” says Shivi Verma, senior manager of engineering at electronic signature firm Docusign.

That’s where it helps to have approved, secure tools for people to use, as well as systems in place to block the insecure ones.

“Some of the websites, like DeepSeek, we have blocked,” he says. “But we want to block in a way that focuses on education and focuses people on the right processes and tooling, which will drive people automatically to use approved tools.”

The company is also working on creating an allow list, he says, focusing on tools that employees can use without any concern.

And the company has network management tools like Zscaler, says Verma. “If people are posting confidential data in an external tool, it will give a popup, like a deterrent.”

Now, personal AI agents like OpenClaw are yet another evolution of the shadow AI problem, he says.

“We do monitor and people are using it, but we want to do it in a way that’s under security policies,” he says.

And with OpenClaw in particular, the danger is too high for just a warning.

“If it’s for personal use, that’s one thing,” Verma says. “But if you’re using it at work, your user has to be stopped immediately.”

Nonprofit builds routing system for approved AI

“Simply blocking AI tools is not a sustainable solution,” says Boris Kolev, global head of technology at JA Worldwide, a global educational nonprofit with almost 5,000 employees that serves more than 20 million people a year.

For JA Worldwide in particular, the problem was exacerbated by the fact that there was no approved solution until three months ago. As a result, employees got into the habit of using personal AI platforms.

“It was totally uncontrolled,” Kolev says. “Everyone who wanted to explore AI was using public models.”

At the beginning, people didn’t worry about what they shared and uploaded. “We tried to implement some policies, like ‘don’t upload corporate information.’ But it was hard to know what people were doing.”

Plus, AI was being embedded everywhere. On Windows. In people’s phones. “A user cannot avoid it,” says Kolev.

Then, earlier this year, the organization built a routing system, with enterprise-safe versions of Claude and ChatGPT running in private environments on AWS and Azure, in addition to some open-source models.

“Our colleagues can choose which model to use,” he says. “And sometimes they do a prompt two different times and choose which one works better.”

The system went into production in June, after a couple of months of testing and development.

“Now, after all the policies and rules are implemented, we have our own closed AI system, hosted on our own servers, so no risk of leaking corporate data,” he says. “But still, some projects are using public models, and we are trying to solve this problem.”

Another hitch: individual employees were often invested in the personal AI tools they’d grown comfortable with and reluctant to change to the corporate tools.

“Employees were saying, ‘I have so much history. It knows me, I cannot just switch,'” Kolev says.

And employees still have all the AI tools that come with their devices.

“This is hard to manage, and it’s getting even harder,” he says. There are monitoring and blocking tools available, but they’re too expensive. “We’re a nonprofit, and for us it’s almost impossible to afford monitoring tools. So we do a lot of educational sessions.”

The organization is also trying to make the sanctioned tools more appealing. That includes a mechanism to import the history and context from other platforms, he says. “And we’re trying to convince them that our tool works better and has more functionality, so we’re adding MCPs.”

MCP — model context protocol — allows an AI system to access data and tools directly. That includes connecting to corporate email and calendars, SharePoint, Monday.com, CRM, and all the other software that employees use for work, he says.

Kolev says that it’s a mistake to assume that employees use shadow AI because they don’t respect IT policies. It’s because IT didn’t move quickly enough to meet their needs.

“They find the AI faster than you can produce tools and governance and rules,” he says. “So my advice is that you start with simple rules that employees can understand, provide sanctioned tools, and continuously adapt governance.”

Holding employees accountable

According to an April survey of more than 1,200 employees conducted by Wakefield Research on behalf of PagerDuty, 66% of employees have used unsanctioned AI tools — and of those, 48% faced formal consequences, such as a warning or disciplinary action.

Holding people accountable is critical to a successful AI use policy, says Carnegie Mellon’s Butkovic. “We have to speak definitely about this in organizations,” he says. “If this behavior cannot be tolerated, then it shouldn’t be tolerated.”

Allowing the use of unsanctioned AI doesn’t just create risks but also opens up an organization to legal liability if the AI agents, acting on behalf of employees, harmed other companies or individuals.

“There could be consequential actions,” he says. Even if the employee responsible gets fired, “external parties that have been affected are still going to sue the company.”

The organization needs to be able to show that it has policies in place and enforces them when employees deliberately circumvent the policies.

“If you as an employee make a good-faith effort to comply with the policy, we’ll show you latitude if you’re not malicious,” Butkovic says. “But if you’re actively circumventing the system of controls in your organizations, that’s the case where there have to be swift and profound consequences.”

Related reading:

• 6 ways to make AI accountability stick
• AI policies work better when employees help write them
• Why AI adoption keeps outrunning governance — and what to do about it
• 5 ways to curb AI sprawl without stifling innovation

This series lays out a practical framework for taking generative AI (GenAI) from pilots to dependable production systems in the enterprise. It focuses on four disciplines that determine long-term success: engineering for scale and reliability, designing agentic systems with clear constraints, embedding governance directly into build and runtime controls, and measuring ROI at the workflow level with full cost and outcome visibility. The throughline is operational discipline—treating GenAI as a service with contracts, evaluation, ownership, and measurable business impact.

Post 1: Enterprise GenAI at scale

The first article in the series, “How to run enterprise generative AI like a production service,” focuses on operations. It explains why reliability, retrieval quality, latency control, cost routing, observability, and evaluation harnesses determine success at scale. The article lays out a practical architecture and operational checklist so teams can move from promising demos to stable, supportable systems.

Post 2: Agentic AI in the enterprise

The second article, “Agentic AI in the enterprise: How to balance autonomy with constraints,” defines what an agentic system is and how to operate one safely. It introduces the agent loop (plan, act, verify, commit), tool contracts, policy enforcement, durable state, and verification gates. The emphasis is on constrained autonomy, traceability, and operational ownership so agents can execute real workflows under enterprise controls.

Post 3: Governance by design

The third article, “Governance by design: Turning AI policy into executable controls,” treats AI governance as engineering work. It describes how to translate policy into executable controls in continuous integration pipelines and runtime enforcement layers. Topics include threat modeling, policy-as-code, lineage, audit evidence, and feedback loops. The goal is steady delivery under measurable guardrails.

Post 4: AI ROI beyond pilots

The final article, “AI ROI beyond pilots: Measuring outcomes in production,” addresses how to measure real business value from GenAI. It defines ROI at the workflow level, accounts for full life-cycle costs, and connects usage metrics to operational outcomes. It provides a metrics stack, cost equation, cohort rollout strategy, and a 90-day plan to produce credible, production-grade ROI signals.

—

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.

For most of the history of enterprise software, accountability has been relatively easy to understand. A person logs in, a person has a set of permissions, and a person takes an action. If something goes wrong, you can usually work backwards from there.

Agentic AI changes that. We are moving from systems that suggest what someone should do to systems that can actually do it. Agents can access tools, call other systems, make decisions across multiple steps, and increasingly operate without a human approving every move. That is the point, of course. An autonomous system that needs someone hovering over every decision is not particularly autonomous.

But the more action we hand over, the more important one deceptively simple question becomes: When an agent does something, who did it?

Not philosophically. Operationally. Whose authority was it using? What was it allowed to touch? Who granted those permissions? And if something goes wrong, who owns the outcome?

Accountability starts with identity

The first question is what an agent actually is inside your organization. Should it always be treated as a delegate of a human, acting on that person’s behalf and inheriting some version of their permissions?

That model makes accountability relatively straightforward. If my agent does something, the action can be traced back to me. But it becomes harder to sustain as agents become more persistent and autonomous.

An agent might run continuously or serve an entire team rather than one person. It might perform a business function that continues long after whoever originally configured it has moved on. In those cases, should the agent have an identity of its own? And if it does, who creates that identity, who owns it, who grants its permissions, and how long should those permissions last?

Identity is where accountability starts because if you cannot reliably answer who the agent is, everything that follows becomes harder to reason about.

Identity and permissions are closely related, but they are not the same thing. Consider an agent designed to conduct research using public information. It might be perfectly reasonable for that agent to use a public model, external tools, or public Model Context Protocol (MCP) servers. Now point that same capability at internal finance data.

The agent has not fundamentally changed. Its environment has.

Suddenly, sending information to an external model may be unacceptable. Certain tools may need to disappear from its reach. Data that could previously move freely now sits inside a very different compliance boundary. So permissions cannot simply be a static list attached to an agent. They need to reflect who the agent is, what it is trying to do, and the context in which it is operating.

That becomes even more important when agents can choose different tools and paths through a problem rather than following a completely predictable workflow.

Delegation gets complicated quickly

Now add sub-agents.

An agent receives a goal and creates several others to complete pieces of the work. Do those sub-agents inherit the parent’s identity? Do they inherit its permissions? Should their authority be narrower based on the task they have been given? And who ultimately owns what they do?

There may not be one universal answer, but there does need to be an answer inside the enterprise. More importantly, there has to be a through line.

An agent can delegate execution to another agent, which delegates part of that task again. That cannot mean accountability disappears somewhere along the way. Autonomy can branch. Accountability cannot disappear.

Enterprises need to retain the relationship between the original authority, every agent involved, the permissions each one carried, and the actions they ultimately took. Otherwise, when something goes wrong, everyone gets to participate in a very expensive game of “whose agent was this?”

The same problem appears over time, not just across agent chains. Consider a long-running agent that constantly monitors tickets and takes action. Eventually, it becomes part of normal operations. Then the person who created it leaves the company.

The agent stays.

Who owns it now? Did responsibility automatically transfer to the person’s manager? Was a successor assigned? Does the team own it? Does the enterprise? And what happens to permissions that were originally linked to someone who no longer exists in the organization?

We already manage life cycles for employees, service accounts, and enterprise applications. Agents need the same seriousness. They need an ownership life cycle, not simply a deployment life cycle.

Accountability has to exist in the system

Defining ownership is only useful if you can reconstruct what actually happened. That means connecting an agent’s identity to its permissions, actions, tools, sub-agents, and eventual outcome.

If something fails, the organization should be able to understand what happened, why the agent was allowed to do it, which permissions enabled the action, which agent actually performed it, and where the control failed. That is what makes remediation possible.

This is why identity, permissioning, and execution tracing cannot live only in policy documents. Writing down who owns an agent is not the same as encoding that ownership into the systems governing it. Telling an agent not to access something is not the same as preventing access. And asking teams to piece together an incident afterwards is not the same as tracing execution while the system is running.

The goal is not to put a human approval step in front of every agent action. That would defeat much of the value of autonomy. The goal is to move humans up a level, from making every individual decision to defining the boundaries within which autonomous systems can make them.

As agents take on more work, enterprises need to know what they can do, who owns them, how authority is delegated, and how every action can be traced.

Because the question is no longer simply whether an agent can act. It is whether, when it does, the organization can still answer who.

—

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.

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.