Healthy software companies typically don’t suddenly eliminate one-fifth of their workforce, but monday.com is doing just that as it bets on flatter teams, AI agents, and customer implementation expertise as the winning combination in the AI era.

Monday.com co-founder and co-CEO Eran Zinman today announced the “very difficult decision” to reduce the AI work platform company’s global workforce by about 20%, or 620 people.

The move has nothing to do with increasing margins or replacing humans with AI, he insisted in his post on LinkedIn; rather, it’s a calculated decision to trim down and hone the company’s focus as AI becomes integral to day-to-day workflows.

“This is not a distress signal; it is a deliberate reset, disclosed with its price attached,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. “The industry has quietly swapped the meaning of productivity, and this filing is the clearest exhibit yet.”

A ‘significant opportunity’ in technology

In a SEC filing this week, monday.com said its restructuring plan reflects the “ongoing transformation of its product, marketing, and go-to-market strategy.” The move is intended to support a “leaner, more focused operating model” as the company continues to invest in its AI-driven strategy.

Zinman noted in his post that the company has shifted to “doing the work with AI and not just managing it,” and is focused on building environments where “people and AI agents [work] together in one workspace.”

In recent months, monday.com has evolved its products, strategy, and the way it serves its customers, and Zinman contended that “the organization we built for our previous chapter is not the organization that fits the new AI era.” Monday.com needs to “execute more decisively,” take on new challenges, and quickly respond to market changes, he said.

“We have never seen such a significant opportunity in software, driven by such exciting technology,” Zinman noted. He emphasized that the reduction is not to replace people with AI, nor to improve margins; the “vast majority” of savings will be reinvested into talent, products, and AI.

The restructuring will result in a “flatter organization” with fewer management layers and smaller, more autonomous teams, and monday.com also has a new go-to-market model, Zinman explained. Customers expect “deeper implementation support” as they deploy AI, and the company will work more closely with customers, increase its on-site presence, create new roles, and “adapt many existing ones.” In its SEC filing, the company said it expects to continue hiring in “key strategic areas” throughout 2026.

Workers will be expected to work better, “not harder,” Zinman noted. He pointed to several past examples where work could have been done in a few days, but instead took many months with “multiple meetings and endless friction.”

“This wasn’t people’s fault and everyone was frustrated by this,” he said. “Our new org changes ownership to allow people to make decisions and move fast.”

A spokesperson for monday.com declined to comment further on the staff reductions.

Monday.com’s key market advantages

Monday.com certainly isn’t struggling; the company expects 19% to 20% year-over-year growth in 2026.

“Companies in that position do not restructure because they must,” Greyhound’s Gogia noted. “They restructure because they have decided to become something else.”

Melody Brue, VP and principal analyst at Moor Insights & Strategy, pointed out that organizational redesign is important for real AI transformation, but while it can signal confidence to the market, it can still be “devastating” to humans.

While the company looks as though it’s trying to do right, that ultimately remains to be seen, she said. “There are often hidden internal bruises that can surface long after layoffs.”

Monday.com’s advantage is in its “structured substrate,” Gogia noted; its boards, permissions and typed workflows give agents something firmer to act on than just documents and chat history. The company highlights its natively built agents that can be configured by any team member, as well as connectors with Claude, Microsoft Copilot, and ChatGPT, and dedicated routes for external agents to authenticate and operate.

“For some time, the sharper enterprise question has been shifting from who has an agent to who owns the governed runtime in which an agent can safely act,” he said. “Structured work is a serious claim on that runtime.”

But parts of monday.com’s agent estate remain in staged release, and its product is ultimately “mid-transition,” Gogia pointed out; its agent builder carried a beta label as recently as March,. Also, the company’s pricing model changed in May to a hybrid model charging for seats as well as mandatory AI credits. And, while its AI-powered no-code builder monday vibe passed $1 million in annual recurring revenue within two and a half months, monday.com has not released subsequent outcomes, usage volumes, or attach rates.

Further, there’s an element of “gravity” with its competitors, he observed. Asana is reorganizing teams around agents, Atlassian is wiring agents into the developer estate, and others are simply bundling them into their offerings: Microsoft is doing so across the productivity stack, and ServiceNow across enterprise operations, each with identity and procurement built in.

“Their pull is strongest exactly where monday.com wants to grow, in the largest accounts, where control-plane depth and administrative reach decide the deal,” said Gogia.

Actions for the near-term

Going forward, buyers should focus on operating risk, not headline risk, Moor’s Brue noted. In practice, that’s continuity of service, roadmap consistency, and strength of enterprise support. Productivity should be valued as better outcomes per unit of organizational effort, not mere activity.

“It should be a measure of how much smoother, faster, and more effective the operating model becomes when AI is built into the work,” said Brue.

Gogia noted that strain surfaces first in customer service, and monday.com’s attention is being redistributed. The company’s annual report disclosed that its focus is now concentrated on the largest accounts, with support for medium-sized clients moved to an AI-first and human-supported model.

During the first month of the transition, buyers should track named account continuity and escalation times, he advised. By the first quarter, keep an eye on whether credit governance and admin controls mature on schedule, and if the roadmap beyond the AI estate keeps pace. By the half-year mark, determine whether promised implementation depth is producing outcomes or “simply more billable engagement.”

Support tiers should be enumerated in writing before renewal, and buyers should contract for “side exits,” Gogia emphasized, with overage pricing fixed in advance, the right to pause consumption, and portability for workflows and agent configuration “if the relationship sours.” Finance should also insist on monthly consumption reporting by capability. Further, integration efforts, partner dependency, and change management should be considered first-class costs of the agent era, “not as afterthoughts to a license.”

“A license was a known cost,” said Gogia. “A meter is a behavior, and behavior is harder to forecast than headcount.”

This article originally appeared on CIO.com.

OpenAI has launched Presence, an enterprise service for deploying voice and chat agents that can resolve customer and employee requests, potentially automating some work now handled by frontline support teams.

The agents can answer questions and operate IT systems, and enterprises can decide what actions the agents may take and when they should seek human approval for actions or transfer a case to a human.

OpenAI is already using Presence internally for its English-language phone support channel, where it verifies callers and uses account information to complete approved actions. The company said the system resolves 75% of inbound issues without human assistance.

Another OpenAI service, Codex, can be used to monitor agents and suggest updates or improvements to processes. In OpenAI’s own tests, suggestions from Codex helped reduce handoffs to humans by 15 percentage points over 10 days, it said. Presence also includes simulation and evaluation tools that allow companies to test an agent before deployment. The tests assess whether it reaches the correct outcome, follows company policy, and hands a case to an employee when required.

OpenAI intends each Presence deployment to deal with one kind of task, for example billing issues, insurance claims, or employee IT service requests, with agents getting only the knowledge and system access required for that task.

Presence is not a self-service product: Enterprises will have to sign up for the limited availability program, with integration performed by OpenAI or selected global systems integrators.

Companies exploring or testing Presence include Spanish bank BBVA, which is evaluating the service for everyday banking support in Mexico, and Japanese technology group SoftBank, which is using it in trials involving Japanese-language customer interactions. Australian insurer IAG is assessing whether the technology can help it respond to surges in customer demand during severe weather events.

Workforce impact

OpenAI’s announcement did not address the potential effect of Presence on employment. But its claimed automation rate raises questions about how the technology could affect staffing in customer service and other support functions.

Pareekh Jain, CEO of Pareekh Consulting, said CIOs should regard the 75% figure as evidence that the technology can work, rather than as a benchmark that every enterprise can expect to reach.

Jain said OpenAI’s deployment benefits from being built around the company’s own products and data. Large enterprises may achieve lower automation rates because they must contend with fragmented legacy systems, uneven knowledge bases and more complex compliance demands.

“Most organizations should expect lower initial automation levels that improve over time as the AI agent is refined,” Jain said.

The first workforce effect is more likely to be slower hiring than immediate layoffs, according to Tulika Sheel, senior vice president at Kadence International.

“The roles most exposed are likely to be repetitive, high-volume functions such as frontline customer support and routine back-office processing,” Sheel said. “However, I would expect the first impact to be on hiring and team growth rather than immediate large-scale job cuts. Over time, enterprises may redesign roles around AI-assisted workflows, with humans focusing more on complex cases, escalation, and relationship management.”

Jain said Tier-1 support agents handling predictable queries would face the most exposure. Broader reductions would become more likely only after companies reorganize their operations around the technology.

However, Lian Jye Su, chief analyst at Omdia, said Presence is unlikely to increase the threat of job displacement because companies have used similar customer-support automation from vendors such as Genesys, NiCE, Five9 and AWS for years.

Enterprises are more likely to use Presence alongside employees, with AI handling routine requests while people remain responsible for work requiring judgment and empathy, Su said.

Cost and operational risks

Analysts said CIOs should examine whether Presence can maintain resolution quality as usage grows, since fewer human handoffs could leave employees dealing with a more difficult mix of cases.

“The key question is not simply how many tasks AI can handle, but whether it can handle them reliably at scale,” Sheel said.

The financial case will depend partly on the cost of connecting Presence to existing systems and maintaining the controls needed to govern its use, according to Jain. “Often the biggest cost of enterprise AI is not tokens but integration and governance,” Jain added.

Companies will need to determine what systems and data the agents can access, monitor their performance, and audit the actions they take. Those investments could offset early savings.

Su said the complexity of enterprise IT will make it difficult for OpenAI to automate entire workflows on its own. Enterprises will still need to work with other technology providers and human employees, while CIOs will favor systems that can be audited and integrated with existing infrastructure.

Jain said the economics could improve if companies use the same integrations and governance controls across additional workflows.

This article first appeared on CIO.

AMD executives took to the stage at its Advancing AI 2026 event in San Francisco today to detail the company’s next generation of AI infrastructure solutions, from Instinct MI455X AI accelerator GPUs and 6th Gen EPYC “Venice” CPUs, to Pensando networking, ROCm.AI software and its Helios rack-scale platform that ties it all together.

AMD has been working towards rack-scale AI system solutions for years. Its ZT Systems acquisition last year added valuable engineering talent and intellectual property that is now finally bearing the real fruits. Its Helios AI platform is a major platform evolution for AMD, with shipments scheduled to begin in the second half of this year (which is here and now).

The announcements at Advancing AI show how the company has engineered its AI platform solutions for large reasoning models, sustained inference and agentic workflows. These workloads pressure memory capacity, data movement, networking and CPU orchestration. AMD’s approach is to keep as much data close to the compute engines as possible and move it more efficiently throughout the system, but there’s deeper nuance here that’s obvious versus AMD’s chief rival, NVIDIA.  

AMD’s MI455X targets the AI memory wall

The Instinct MI455X GPU is the compute engine that fuels the Helios rack, and the first GPU based on AMD’s new CDNA 5 architecture. Built with a modular mix of 2nm and 3nm chiplets, it carries 432GB of HBM4 and 23.3TB/s of peak memory bandwidth.

Compared to AMD’s current MI355X, the MI455X offers 1.5 times the memory capacity, up to 2.9 times the peak memory bandwidth and up to four times the peak matrix performance with MXFP4 and MXFP8 data types, which are lower-precision numerical formats designed to accelerate AI processing while reducing memory demands. With MXFP6 (6-bit floating point), performance is rated at up to twice that of MI355X.

AMD also shared some actual, measured internal results using production silicon. The company claims MI455X delivers 3.8 times higher FP8 decode performance, 3.5 times more measured FP4 compute performance and between 2.5 and 3.5 times more networking bandwidth than MI355X, depending on the transfer path tested. Those figures provide more context than just numerical specifications, though they remain AMD-provided comparisons that will need independent validation.

AMD

The architectural choices behind the numbers are important. Reasoning models and long context windows require sizeable KV caches for maintaining AI attention states, while mixture-of-experts models frequently move large amounts of data across accelerators. MI455X should let more model data, activation states and cache remain local. New dedicated IP in hardware can transfer data while the GPU continues processing, and expanded cache and multicast capabilities are designed to reduce redundant data movement to further improve efficiency.

The aforementioned lower-precision formats can also raise throughput and reduce memory use, but model developers still have to determine where they can be applied without unacceptable accuracy loss.

AMD’s Helios rack takes aim at Vera Rubin

Dave Altavilla

Helios is AMD’s primary rack-scale competitor to NVIDIA’s Vera Rubin platform. Each liquid-cooled rack combines 72 MI455X GPUs, 18 single-socket Venice host CPUs and Pensando networking technologies.

In its most complete, premium configuration, AMD rates Helios for 2.9 exaflops of low-precision AI compute, with 31TB of aggregate HBM4 capacity, 1.7PB/s of memory bandwidth, 260TB/s of bidirectional scale-up bandwidth and 43TB/s of scale-out bandwidth.

These are formidable figures, but they are technical specifications rather than actual application benchmarks. The more consequential development is AMD’s move from collections of eight-GPU servers to a 72-GPU shared-memory domain. Models too large for one node can operate across the rack without treating every exchange as a scale-out networking transaction, which benefits large-model inference as well as training.

AMD uses UALink over Ethernet, or UALoE, for an open standard scale-up fabric. Each MI455X provides 3.6TB/s of bidirectional scale-up bandwidth, while the complete rack delivers all-to-all connectivity through a single switch layer. AMD also claims six times more scale-out bandwidth per GPU than MI355X when MI455X is configured with three Pensando Vulcano 800 AI NICs.

While open standards give cloud providers more control over suppliers and system design, AMD and its partners now have to prove those components can deliver the predictable performance, reliability and deployment experience customers expect from a tightly controlled, more vertically integrated platform.

Finally, AMD designed Helios with automatic rerouting around failed links, virtual rack partitions, tray-level serviceability and rack-wide power, cooling and health monitoring. Major hyperscalers and potentially large-scale enterprise customers will likely key in on these capabilities, which can affect the availability, total cost and consistency of the AI services they consume.

Kind of like cowbell, AMD Venice gives agentic AI more CPU

AMD

AMD’s agentic CPU messaging regarding its upcoming Venice-based EPYC processors is mostly marketing speak, but the underlying requirement is very real. An AI agent can invoke retrieval, databases, security checks, code execution and other tools before a GPU generates a response. Running many agents concurrently increases the amount of conventional compute requirements surrounding the accelerators.

Venice scales to 256 Zen 6 cores with support for 512 threads, 16 memory channels, up to 1GB of L3 cache per socket, along with PCIe 6.0 and CXL 3.1 connectivity. AMD is also offering several Venice configurations for other applications, including general-purpose servers, high-frequency workloads, GPU hosts and high-density CPU sandbox systems used to execute agent tools.

Treating the CPU solely as a GPU host understates its role. Gateways, tokenization, vector search, databases and short-lived code execution stress different mixes of per-core performance, thread count, memory bandwidth and I/O. Specifically, AMD’s internal testing shows Venice significantly outperforming its current EPYC 9965 Turin CPU across five parts of the agentic AI pipeline, including gateway processing, context assembly, vector search, enterprise applications and short-lived tool execution. Individual gains vary by workload, but AMD details the overall generational improvement at up to a 1.7 times lift. As with the MI455X figures though, these comparisons come from AMD and will require independent validation.

Pensando networking and ROCm software advance

Keeping GPUs fed with data and coordinating traffic across racks directly affects utilization and operating costs. In fact, GPU utilization is a pretty sad state of affairs currently for some of the major frontier model providers.

As such, Pensando networking has become central to AMD’s roadmap. Helios can connect each MI455X to as many as three 800Gbps Vulcano AI NICs, while Salina DPUs handle front-end networking and infrastructure services.

On the software side, which is an equally critical component, AMD also introduced ROCm.AI, an AI-assisted development layer due to arrive in August. It includes reusable skills for coding agents, simplified management and Hyperloom, which can profile workloads, tune serving configurations, modify kernels and validate results.

These tools address two persistent AMD challenges: developer efficiency and ease of use, and software tuning. Automated optimization still has to produce repeatable gains without creating hard-to-maintain code, however. And while ROCm has progressed significantly over the last few years, NVIDIA’s CUDA retains an advantage in maturity, tooling and developer familiarity.

Customer commitments underscore rack-scale confidence

AMD now has commitments that give its MI450 generation and Helios considerably more weight. Meta and OpenAI have announced multi-generation agreements composed of up to 6GW of AMD compute capacity, with initial 1GW deployments planned for the second half of 2026.

Oracle plans a 50,000-GPU public cloud cluster beginning in the third quarter, while Microsoft will deploy Helios for Azure AI inference. Finally, just before the AMD event, Anthropic announced a strategic partnership for up to 2 Gigawatts of AMD-fueled AI compute, with its first gigawatt expected online in the first half of 2027.

Commitments of this scale reflect confidence in more than just MI455X performance. These customers are evaluating the complete architecture, including Venice CPUs, Pensando networking, ROCm software, rack integration, serviceability and AMD’s ability to deliver and execute across multiple product generations.

There is some financial alignment behind the agreements as well. AMD issued OpenAI performance-based warrants and committed to investing up to $5 billion in Anthropic. That context matters when evaluating these deals as market validation, but these planned deployments are substantial nonetheless and put Helios on a much stronger foundation as it begins shipping.

AMD expands its robotics and embedded foundation

AMD also expanded its physical AI portfolio, building on credible traction from its Xilinx-derived Kria adaptive system-on-modules and embedded technologies that are already powering robotics, machine vision and industrial automation applications.

The new Ryzen AI Embedded X100 combines up to 16 Zen 5 CPU cores, integrated Radeon graphics, a second-generation NPU and as much as 128GB of unified LPDDR5X memory shared across its compute engines. To me this looks a lot like a repackaging and optimization of the company’s Strix Halo platform, but with specific optimizations for the embedded space. Regardless, AMD is pairing X100 with the Kria AI Robotics Developer Platform, which includes a System Module or SOM, and a new Robotics Partner Network spanning hardware, software and platform providers.

Samples began shipping in June, with full production expected in the fourth quarter. This broader objective is to give developers a path across AMD x86 CPUs, GPUs, NPUs and FPGAs for real-time autonomous systems, rather than requiring them to assemble those hardware engines and software components independently.

Execution for AMD is now the test

AMD has assembled a credible platform for the burgeoning agentic AI market that’s blowing up currently with no signs of stopping. MI455X addresses memory and data movement, Venice handles dense agentic CPU workloads, Pensando networking connects global system resources, and ROCm.AI addresses software complexity. Finally, Helios assembles these components into a true competitive threat for NVIDIA’s latest Vera Rubin platform.

AMD’s open architecture may appeal to customers seeking supplier choice, but openness must also translate into reliable deployments, competitive total cost and software that does not require a significant rip-up. NVIDIA enters this cycle with a stronger ecosystem and far more rack-scale deployment experience. The true test will be how easily and reliably customers can integrate, operate and maintain these AMD solutions at scale.

As it stands, AMD now has major customers and a clearly defined architecture with systems engineering expertise behind it. Delivering Helios on schedule and showing that its performance claims translate into a real production workload throughput advantage and total cost of ownership gains will determine how much the competitive gap narrows. And of course, this is in a market that is clamoring for ever-more compute resources with a seemingly insatiable demand for AI services and capacity. That’s an environment for big iron success. Now AMD just has to deliver optimized, turnkey AI platforms. This is far easier said than done, but time will soon tell as deployments take shape this year.

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

Traditional phishing techniques are in decline as a result of the disruption of the Tycoon2FA phishing-as-a-service (PHaaS) platform, Microsoft said in a new report, “Email threat landscape: Q2 2026 trends and insights”.

“Phishing volume linked to the platform fell 92% from pre-disruption averages, including QR code phishing and CAPTCHA-gated phishing both declining from their March highs,” the company wrote in the report.

The takedown reduced activity across multiple phishing categories, forcing attackers to shift to newer delivery methods.

Riding this shift in were a few notable phishing campaigns, including an automated business email compromise (BEC) campaign that reached 42,000 organizations in under three hours, and a multi-stage phishing campaign that used nested email (EML) files, calendar invitations, and a Microsoft authentication redirect to deliver malware.

To counter phishing attacks, Microsoft recommends blocking emails containing known bad URLs/ subject fields, enabling password-less authentication methods, or moving to MFA for accounts that still require passwords.

Tycoon2FA disruption sent attackers exploring

The take-down of Tycoon2FA forced its operators to abandon portions of their infrastructure and rework hosting, domain registrations, and delivery mechanisms.

“After falling 15% in March and another 22% in April, Tycoon2FA-linked phishing volume dropped 74% in May to just 1.5 million messages, then fell another 20% in June to 1.2 million, by far the lowest monthly volumes observed in at least a year,” Microsoft said.

The decline extended to QR Code lures and fake CAPTCHA pages, two phishing techniques in which Tycoon2FA accounted for 12% and 14% of industry activity in June, respectively. This indicated that the platform’s customer base had not been able to migrate to a replacement infrastructure.

But cutting off one head of the hacker hydra only gave rise to new tactics elsewhere.

The adaptation came in the form of using Microsoft Teams as a social engineering channel. Attackers established conversations to build trust before attempting credential theft or delivering malicious payloads. “Teams-based phishing volume climbed steadily throughout Q2, with the average number of detected attacks rising 19% from March to April, holding roughly flat into May (+1%), then increasing another 10% into June,” Microsoft said.

Microsoft also observed a highly automated BEC campaign that reached over 67,000 users using scripted emails, Amazon Simple Email Service (SES), and engagement tracking, alongside a separate phishing campaign targeting 107,000 users that abused Microsoft’s authentication flow and trusted cloud services, including Teams archive recording and ICS calendar invite, to disguise malware delivery behind legitimate infrastructure.

Phishing changes but the defense doesn’t

While QR Code and Captcha-based phishing attacks dropped significantly in the second quarter, business email compromise (BEC) charted jumped 121% between March and April, before dropping down again in May.

QR Code phishing represented 8.3 million attacks in June 2026, down from a peak of 18.7 million in March. Similarly, Captcha-gated phishing fell from 12 million attacks in March to 2.2 million in June.

BEC attacks hit 9 million in March, falling to 3.9 million in June.

But even as these phishing classics lost momentum and newer techniques emerged, Microsoft’s defensive advice remained rooted in the basics. It noted organizations should complement email filtering with phishing-resistant authentication such as passkeys and phishing-resistant MFA to reduce the effectiveness of credential theft campaigns.

The company also recommended strengthening Exchange Online Protection and Microsoft Defender for Office 365 with capabilities such as Safe links and Zero-hour Auto Purge (ZAP), in which malicious emails already delivered to mailboxes are removed before they are read, alongside enforcing password-less authentication methods like Windows Hello, FIDO keys, and Microsoft Authenticator.

Microsoft concluded its report with a list of indicators of compromise (IoCs) from the threats observed in the quarter to support detection efforts.

This article first appeared on CSO.

Foto: I Believe I Can Fly – shutterstock.com

Enterprise Architecture (EA) Tools unterstützen Unternehmen und Organisationen dabei, mit ihren IT-Strategien die Geschäftsziele optimal zu unterstützen. Sie sorgen ebenfalls dafür, dass Unternehmen ihre Roadmaps für die digitale Transformation geordnet vorantreiben können. EA Tools bieten dafür unter anderem Collaboration-, Reporting-, Testing- und Simulationsfunktionen. Mit deren Hilfe lassen sich Modelle implementieren, die Geschäfts- und IT-Prozesse gezielt verbessern.

Um die beste Lösung für Ihr Unternehmen zu finden, sollten Sie zuerst prüfen, ob sich das jeweilige Tool mit Ihrem Technologie-Stack integrieren lässt. Anschließend gilt es abzuwägen, ob die Informationen, Diagramme und Tabellen, die die Software zur Verfügung stellt, für das Unternehmen auch einen echten Nutzwert haben.

Empfehlenswerte Enterprise-Architecture-Tools

Nachfolgend finden Sie einen Überblick über die wichtigsten Enterprise-Architecture-Tools – in alphabetischer Reihenfolge. Sie stellen einen Mix aus Visualisierungs-, Collaboration- und Project-Management-Funktionen bereit und unterstützen eine Vielzahl von Enterprise Architecture Frameworks.

Ardoq

Nachdem zuerst über einfache Formulare Informationen von Usern, Entwicklern und sonstigen Stakeholdern im Unternehmen eingesammelt wurden, lässt sich mithilfe von Ardoq ein digitaler Zwilling der gesamten Organisation erstellen. Der Ansatz setzt also darauf, die Menschen, die in ihren Rollen mit den verschiedensten Systemen arbeiten, realistisch in ihrer Arbeitswelt abzubilden.

Jede Mitarbeiterin und jeder Mitarbeiter im Unternehmen kann später von den Netzwerkvisualisierungen und Datenfluss-Diagrammen profitieren, um seine eigene Rolle optimal zu unterstützen und den Arbeitsplatz immer wieder anzupassen und zu modernisieren. Das Tool lässt sich mit den wichtigsten Cloud-Plattformen integrieren. Es bietet eine API, die individuelle Anpassungen in allen wichtigen Programmiersprachen (Python, C#, Java, etc.) ermöglicht.

Wichtigste Use Cases:

• “Architektonischen Stress” bei Lastspitzen simulieren, falls größere Veränderungen bevorstehen;

• Verstehen, wie verändertes Nutzerverhalten neue Anforderungen generiert;

• Application Portfolio Management, um besser strategisch zu planen.

Atoll Group SAMU

Das EA-Tool SAMU macht die Enterprise Architecture sichtbar, indem es tiefe Verknüpfungen zwischen On-Premises-Systemen, dem Cloud-Layer und Tools für das Business Process Management aufzeigt. Das Tool der Atoll Group bietet vielfältige Integrationsmöglichkeiten, zum Beispiel mit Monitoring-Tools (etwa Tivoli, ServiceNow), Configuration-Management-Datenbanken (zum Beispiel CA, BMC) oder Service-Organisations-Tools (BMC, HPE). Alle Informationen fließen in ein zentrales Datenmodell ein, das um den zusätzlichen Input der Stakeholder weiter angereichert wird.

Wichtigste Use Cases:

• Enterprise-Architektur visualisieren;

• strategische Planungsprozesse und Architektur-Reviews mit Informationen unterfüttern;

• mithilfe einer visuellen Verständnisgrundlage die Kommunikation verbessern.

Avolution Abacus

Dieses Tool erfasst die Breite und den Umfang der Unternehmensarchitektur mit Hilfe eines auf Diagrammen basierenden Dashboards. Die Integration mit gängigen Tools wie SharePoint, Excel, Visio, Google Sheets, Technopedia oder ServiceNow vereinfacht die Nutzung. Abacus wurde inzwischen auch um einen Machine-Learning-Layer ergänzt, der es Anwendern ermöglicht, ein Modell zu trainieren, das ihnen beispielsweise hilft zu erkennen, wer im Unternehmen für welches System verantwortlich ist.

Wichtigste Use Cases:

• die IT für das gesamte Unternehmen “öffnen”, um ein allgemeines Verständnis der Datenflüsse zu erzeugen;

• umfassendes Enterprise Modeling, um eine Roadmap für künftige Entwicklungen zu erstellen;

• Business-Metriken tracken, die mit der Unternehmens-Performance zusammenhängen.

BOC Group ADOIT

ADOIT soll Teams dabei unterstützen, Ressourcen zu verwalten, Bedarfe vorherzusagen und Assets zu tracken. Dazu mappt das Tool jedes System oder Softwarepaket mit einem Objekt. Die Datenflüsse zwischen den Systemen werden in Beziehungen umgewandelt, die von diesen Objekten mithilfe eines anpassbaren Metamodells erfasst werden. Geschäftsprozesse können auf ähnliche Weise über ein gut integriertes Begleitprodukt namens ADONIS modelliert werden. ADOIT ist Web-basiert und lässt sich auch mit Tools wie Atlassian Confluence integrieren, um die Datenerfassung und -entwicklung zu beschleunigen.

Wichtigste Use Cases:

• ein unternehmensweites Modell erstellen, das bei sämtlichen Teammitgliedern ein Verständnis über den Stack schafft – und wie man diesen verbessern kann;

• vollständiger Zugriff auf EA-Daten über eine Mobile-Anwendung;

• bei Fusionen und Übernahmen den Tech-Bereich durch genaues Asset-Mapping orchestrieren.

Bizzdesign Hopex

Nach der Übernahme von Mega International zählt die Hopex-Plattform zum Portfolio von Bizzdesign. Sie soll dabei unterstützen, Unternehmensanwendungen zu modellieren und dabei ein Verständnis der von ihnen unterstützten Geschäfts-Workflows schaffen. Dabei liegt ein Schwerpunkt auf den Bereichen Data Governance und Risikomanagement. Hopex basiert auf Microsoft Azure und stützt sich auf eine Reihe offener Standards wie GraphQL und REST Queries, um Informationen aus Komponentensystemen zu sammeln. Das Reporting ist mit den Office-Tools von Microsoft sowie mit grafischen Lösungen wie Tableau und Qlik integriert.

Wichtigste Use Cases:

• datengestützte Erkenntnisse herbeiführen, um Cloud- und Anwendungsbereitstellung zu steuern;

• akkurate Nutzungsmodelle erstellen, um Architekturanforderungen zu verstehen;

• eine Bedarfsschätzung mit Umfragen und anderen Tools vornehmen, um für die Zukunft zu planen.

Bizzdesign Horizzon

Das Tool dient dazu, Business Workflows und den zugrundeliegenden Tech-Stack zu modellieren. Dazu bietet Horizzon ein Graph-basiertes Modell, das Daten von sämtlichen Stakeholdern einsammelt und diese an eine Analytics-Engine weitergibt. Im Ergebnis entstehen Diagramme, die den aktuellen Systemzustand widerspiegeln. Wichtige Schwerpunkte dieses Tools sind Change Management und Zukunftsplanung: Horizzon ist nicht zuletzt dafür konzipiert worden, die Risiken eines Redesigns zu minimieren. Das Toolset unterstützt die wichtigsten Frameworks ArchiMate, TOGAF und BPMN. Neben Mega hat Bizzdesign im Januar 2025 auch den EA-Geschäftsbereich der Software AG – Alfabet – übernommen.

Wichtigste Use Cases:

• Vorhersage zukünftiger Anforderungen durch Predictive Modeling;

• Orchestrieren von Workflows auf der Basis der technischen und der Business-Architektur;

• Antizipieren von Risiken sowie Security- und Governance-Problemen durch die Modellierung von Datensicherheitsanforderungen.

Capstera

Das Tool von Capstera fokussiert darauf, die Business Architecture selbst abzubilden. Value und Process Maps helfen dabei, die Rollen der verschiedenen Unternehmensbereiche zu definieren und nachzuverfolgen. Dabei können im laufenden Prozess Verknüpfungen mit den zugrundeliegenden Softwarprodukten und Tools hinzugefügt werden.

Wichtigste Use Cases:

• Reports erstellen, die sich erst einmal mit der Business-Architektur selbst beschäftigen;

• Beziehungen zwischen Menschen, Abteilungen und Rollen analysieren;

• die langfristige strategische Planung vorantreiben.

Clausmark Bee360

Teammitglieder, die Clausmarks Flaggschiffprodukt Bee360 (früher Bee4IT) verwenden, wollen eine einfache “Single Source of Truth” über die Workflows im Unternehmen. Ziel ist es, verschiedenen betrieblichen Rollen intelligentere Entscheidungen zu ermöglichen. Das Modul Bee360 FM (Finanzmanagement) bietet etwa die Möglichkeit, Kosten nachzuvollziehen und zuzuordnen. Die Anwender können verschiedene solcher Module miteinander verknüpfen, um EAM, Finanzmanagement, Portfolio Management und Agile Planning nahtlos zu integrieren – bei maximaler Transparenz.

Wichtigste Use Cases:

• C-Suite-Ebene befähigen, Projekte zu managen und Assets zuzuweisen;

• präzise digitale Zwillinge entwickeln, um ein Verständnis über Datenflüsse zu schaffen und künftige Erweiterungen zu planen;

• integrierte Wissensdatenbank aufbauen, um alle digitalen Workflows zu tracken.

EAS

Das Essential-Paket von EAS (Enterprise Architecture Solutions) nahm als Open-Source-Projekt seinen Anfang und hat sich inzwischen zu einer kommerziell verfügbaren Cloud-Lösung weiterentwickelt. Das Tool erstellt ein Metamodell, das die Interaktionen zwischen Systemen und Geschäftsprozessen beschreibt. Ebenfalls enthalten sind Pakete, um gängige Business Workflows wie Datenmanagement oder DSGVO-Compliance zu tracken.

Wichtigste Use Cases:

• den technischen Reifegrad der eigenen Architektur evaluieren;

• Sicherheit und Governance durch besseres Asset Tracking optimieren;

• wachsende Systemkomplexität kontrollieren und managen.

OrbusInfinity

Orbus Software hat Anfang 2025 die Akquisition seines Konkurrenten Capsifi abgeschlossen. Der Anbieter stellt mit OrbusInfinity eine Enterprise-Transformation-Plattform auf KI-Basis zur Verfügung, die schnellere, bessere Entscheidungen, Kosteinesparungen und Risikominimierung verspricht. Architecture-Teams sollen mit Hifle von OrbusInfinity mit einer Vielzahl von Stakeholdern interagieren können, um eine “digitale Blaupause” ihres Unternehmens zu generieren, die eine einheitliche Sicht auf das aktuelle und künftige Geschäft realisieren soll. Diverse Drittanbieter-Tools lassen sich außerdem mit der Plattform integrieren, darunter etwa von Microsoft, Flexera, ManageEngine oder ServiceNow.

Wichtigste Use Cases:

• Stakeholder-Management;

• Enterprise-Landschaften visualisieren;

• Entscheidungsfindung und Datenanalyse automatisieren.

Planview Enterprise One

Planview bietet eine ganze Reihe von Produkten, mit denen Unternehmen Teamwork, Prozesse und die Enterprise Architecture nachvollziehen können. Die Enterprise Tools sind in drei Kategorien unterteilt: strategisches Portfolio-Management, Produktportfolio-Management und Projektportfolio-Management. Im Zusammenspiel entstehen hardware- und Software-übergreifende Layer, die rollenbasierte Perspektiven für Führungskräfte und Teammitglieder eröffnen. Das Toolset integriert mit gängigen Ticket-Tracking-Systemen wie Jira, um Workflow-Analysen und Reports zu erstellen. Inzwischen hat Planview nach einer Übernahme neue Tools in sein Portfolio integriert, die früher unter den Namen Daptiv, Barometer und Projectplace bekannt waren.

Wichtigste Use Cases:

• eine langfristige, strategische Vision für die Architekturentwicklung aufbauen;

• Entwicklungsarbeit auf Projektebene tracken und in eine beliebige Strategie integrieren;

• mit Fokus auf die Customer Experience und die Produktstruktur den Change vorantreiben.

QualiWare Enterprise Architecture

Das Enterprise Architecture Tool von QualiWare ist Teil einer größeren Sammlung von Modellierungswerkzeugen, die darauf abzielt, sämtliche Geschäftsprozesse zu erfassen. Beispielsweise ist es möglich, einen digitalen Zwillinge zu bauen, mit dem sich Customer Journeys nachvollziehen lassen. Qualiware hat diverse KI-Algorithmen integriert, um Dokumentation und Process Discovery zu optimieren.

Wichtigste Use Cases:

• ein kollaboratives Ökosystem für Business Manager aufbauen, das ein Verständnis von der Enterprise Architecture vermittelt;

• architektonische Designelemente erfassen, um ein Wissens-Ökosystem rund um den Stack aufzubauen;

• eine breite Beteiligung in Sachen Dokumentationserstellung und -überprüfung fördern.

Quest Erwin Evolve

Das Erwin Evolve Tool von Quest hat sich von einem Datenmodellierungs-Tool zu einem System für Enterprise-Architecture- und Geschäftsprozess-Modellierung weiterentwickelt. Um die Komplexität moderner, ineinandergreifender Softwaresysteme und der von ihnen gemanagten Geschäftsprozesse zu durchdringen, können Anwender auf benutzerdefinierte Datenstrukturen zurückgreifen. Das Web-Tool erstellt Modelle, rollenbasierte Diagramme und andere Visualisierungen, die in allgemein zugängliche Dashboards einfließen. Zum Paket gehört ein KI-basiertes Modellierungs-Tool, das Whiteboard-Skizzen integrieren kann.

Wichtigste Use Cases:

• einen digitalen Zwilling für die strategische Modellierung der Enterprise Data Architecture erstellen;

• Customer Journeys verstehen;

• Services und Systeme mit Application Portfolio Management tracken.

SAP LeanIX Enterprise Architecture Suite

Die Tool-Sammlung von LeanIX umfasst unter anderem Enterprise Architecture Management und andere Bereiche, die für Aufgaben wie SaaS– und Value-Stream-Management wichtig sind – etwa um Cloud-Deployments und darauf laufende Services zu tracken. Die Daten die dabei über die IT-Infrastruktur gesammelt werden, fließen in ein grafisches Dashboard ein. Das Tool ist eng mit wichtigen Cloud-Workflow-Tools wie Confluence, Jira, Signavio und Lucidchart integriert. Das ist für Teams von Vorteil, die diese Tools bereits nutzen, um ihre Entwicklungsstrategien zu planen und umzusetzen. Seit November 2023 ist LeanIX Teil von SAP.

Wichtigste Use Cases:

• Anwendungsmodernisierung und Cloud-Migration managen;

• Obsoleszenz von Software-Services evaluieren;

• Kosten kontrollieren und managen.

ServiceNow

Die Tool-Sammlung von ServiceNow lässt sich auf verschiedene Architekturtypen herunterbrechen, darunter Assets, DevOps, Security und Service. Die Tools katalogisieren die unterschiedlichen Hardware- und Softwareplattformen, um Workflows und Datenflüsse im Unternehmen abzubilden und zu verstehen. Ausführliche Reportings und detaillierte Dashboards ermöglichen Analysen, auf deren Grundlage Risiken minimiert und die Ausfallsicherheit der Systeme erhöht werden können.

Wichtigste Use Cases:

• Tracken von Assets, Services und Systemen, die das Unternehmen ausmachen;

• Governance-Themen, Risikobegrenzung, IT-Management und Security Operations werden in einer Plattform zusammengeführt;

• durch die Integration von CRM-Tools lassen sich auch kundenorientierte Services managen.

Sparx Systems

Um Teams und Projekte verschiedener Größe und Komplexität zu unterstützen, hat Sparx vier Versionen seines EA-Tools entwickelt. Allen gemeinsam ist eine UML-basierte Modellierung, mit der sich die Komponenten komplexer Systeme tracken lassen. Eine Simulations-Engine ermöglicht “War Gaming” und vermittelt ein Verständnis darüber, wie sich Fehler ausbreiten und kaskadieren können. Sparx stellt zudem eine Vielzahl von vorgefertigten Design Patterns bereit, um Teams bei der Modellierung zu unterstützen.

Wichtigste Use Cases:

• Nachfrage- und Lastveränderungen zur Prognose künftiger Anforderungen simulieren;

• (potenzielle) Probleme durch eine Verbindungs-Matrix im Auge behalten;

• Dokumentation erstellen.

Unicom System Architect

System Architect ist eines der Angebote aus Unicoms Team Blue. Es handelt sich um ein Tool, das ein Metamodell verwendet, um automatisiert so viele Daten wie möglich über die laufenden Systeme zu sammeln – manchmal auch durch ein Reverse Engineering von Datenflüssen. Dieses systemweite Datenmodell kann über benutzerdefinierte Dashboards Teammitgliedern aller Rollen zugänglich gemacht werden. Ein weiteres erwähnenswertes Feature: Die Ressourcenzuweisung lässt sich mit Hilfe von Simulationen optimieren.

Wichtigste Use Cases:

• Was-wäre-wenn-Fragen zum Architekturmodell stellen;

• ein Metamodell von Daten und Systemen aufbauen;

• Migrations- und Transformationspläne erstellen.

ValueBlue BlueDolphin

Dieses EA-Tool sammelt Daten auf dreierlei Art:

1. Es importiert Basisdaten auf der Grundlage standardgesteuerter Automatisierung (ITSM, SAM).

2. Es arbeitet mit den Dateiformaten von Architekten und Systemdesignern – etwa ArchiMate oder BPMN.

3. Es gibt Fragebögen an andere Stakeholder heraus, die auf anpassbaren Vorlagen basieren.

Die aufbereiteten Informationen werden in einer visuellen Umgebung bereitgestellt, die Auskunft über die historische Entwicklung von Systemen gibt.

Wichtigste Use Cases:

• systemweite Daten von internen und externen Stakeholdern automatisiert und formularbasiert erfassen;

• zukunftsorientierte Reportings erzeugen, um den Change zu überwachen und voranzutreiben;

• Kooperation und Zusammenarbeit durch offenes Data Reporting fördern.

(fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation CIO.com erschienen.

Foto: SkillUp | shutterstock.com

Manche Devs arbeiten mit der Kommandozeile (auch Command Line Interface; CLI), weil sie sie lieben – andere, weil ihnen nichts anderes übrig bleibt. Egal zu welcher Kategorie Sie sich zählen: Diese neun CLI-Tools helfen Ihrer Produktivität und Effizienz (zusätzlich) auf die Sprünge.

tldr

Keine Angst, wir ersparen Ihnen an dieser Stelle eine langwierige, faszinative Abhandlung über die ganz eigene Magie, die die Unix-Shell entfaltet. Fakt ist: Wenn man mit ihr arbeiten will, ist es manchmal erforderlich, vorher ein Handbuch zu lesen. Unix Docs (auch man- oder manual pages) sind diesbezüglich allerdings ein zweischneidiges Schwert: Die benötigte Information ist vorhanden – es ist nur die Frage, wo. Den Teil der Dokumentation aufzuspüren, den Sie gerade benötigen, kann ein entmutigender Task sein. Zwar kann die gute alte Befehlszeile dabei helfen – um ein offizielles Handbuch aufzurufen, genügt:

$ man

Allerdings zeichnen sich man-pages vor allem durch ihre Informationsdichte aus – und die Tatsache, dass sie manchmal aktuelle Informationen für neuere Tools vermissen lassen. Das CLI-Tool tldr versetzt Sie in die Lage, zielgerichteter zu suchen:

$ tldr

Foto: Matthew Tyson | IDG

Falls Sie npm installiert haben, ist die tldr-Installation nur einen kurzen Befehl entfernt:

npm install -g tldr

ngrok

Sobald Sie tldr installiert haben, können Sie damit viele weitere Befehle erkunden. Zum Beispiel:

$ tldr ngrok

Reverse proxy that creates a secure tunnel from a public endpoint to a locally running web service.

Mit ngrok eröffnet sich Ihnen eine stressfreie Möglichkeit, von einem Remote-Browser auf eine Entwicklungsmaschine zuzugreifen. Aber das Tool kann noch weit mehr. Sie können damit beispielsweise in der Cloud entwickeln und die Ergebnisse im Browser in Augenschein nehmen. Zudem können Sie mit ngrok auch schnell und einfach laufende Services über HTTPS veröffentlichen – ohne sich mit der Security-Infrastruktur herumschlagen zu müssen. Angenommen, Sie bauen einen Service Worker auf, der HTTPS benötigt, dann ist alles, was Sie für einen sicheren Kontext tun müssen, ngrok zu starten.

Foto: Matthew Tyson | IDG

Ein Beispiel, bei dem der HTTP-Port 8080 freigegeben wird:

$ ngrok http 8080

Der ngrok-Output sieht wie folgt aus:

https://f951-34-67-117-59.ngrok-free.app -> http://localhost:8080

Anschließend kann jedermann die zugewiesene URL aufrufen (machen Sie sich keine Mühe).

screen

Mit diesem Befehlszeilen-Tool können Sie eine Shell-Sitzung mit oder ohne laufenden Prozess “beiseite legen” und sie anschließend zu einem beliebigen Zeitpunkt fortsetzen – auch wenn Sie die ursprüngliche Session beenden.

$ tldr screen

Hold a session open on a remote server. Manage multiple windows with a single SSH connection.

Nehmen wir an, Sie starten ngrok, um remote auf eine Webanwendung zuzugreifen: Sie starten den Prozess, lassen diesen dann in screen laufen und programmieren so lange etwas. Währenddessen läuft ngrok die ganze Zeit weiter – Sie können über screen jederzeit wieder darauf zugreifen. Veranschaulicht in Code würde das wie folgt aussehen:

$ screen

// Now we are in a new session

$ ngrok http 8080

// Now ngrok is running, exposing http port 8080

Type ctrl-a

// Now we are in screen's command mode

Type the "d" key, to "detach".

// Now you are back in the shell that you started in, while screen is running your ngrok command in the background:

$ screen -list

There is a screen on:

128861.pts-0.dev3 (04/25/24 14:36:58) (Detached)

Tipp

Wenn Sie eine laufende Sitzung, in der Sie sich gerade befinden, benennen wollen, nutzen Sie die Tastenkombination Strg + A und geben :sessionname ein. Das ist besonders nützlich, wenn Sie mit mehreren Screen-Instanzen arbeiten wollen.

Foto: Matthew Tyson | IDG

Wenn wie im Beispiel nur eine screen-Instanz läuft, führt der Befehl $ screen -r (für “re-attach”) Sie zurück zu Ihrer ngrok-Sitzung. Im Fall mehrerer Screens können Sie diese mit Hilfe ihrer ID wieder aufrufen:

$ screen -r

Wenn Sie Ihre Session endgültig beenden wollen, beenden Sie ngrok mit Strg + C und geben anschließend exit in die Kommandozeile ein.

sdkman & nvm

Wenn Sie Java oder JavaScript auf einem Server verwenden, sollten Sie sich mit sdkman (für Java) und nvm (für Node) vertraut machen. Beide Kommandozeilen-Tools sind nützlich, wenn es darum geht, mit mehreren Programmiersprachenversionen auf dem selben Rechner zu jonglieren – und dabei sowohl Path Adjustment als auch Umgebungsvariablen überflüssig machen.

Mit sdkman können Sie beispielsweise neuere Java-Versionen erkunden und anschließend wieder zum aktuellen LTS-Release springen. Dieser Prozess wird durch das sdk-Kommando abstrahiert.

Foto: Matthew Tyson | IDG

Zwischen den Versionen zu wechseln, gestaltet sich denkbar einfach – $ sdk use java 19-open führt Sie direkt zu JDK Version 19.

$ tldr sdk

Manage parallel versions of multiple Software Development Kits.

Supports Java, Groovy, Scala, Kotlin, Gradle, Maven, Vert.x and many others.

Die nvm-Utility funktioniert ganz ähnlich:

$ tldr nvm

Install, uninstall or switch between Node.js versions.

Supports version numbers like "12.8" or "v16.13.1", and labels like "stable", "system", etc.

Foto: Matthew Tyson | IDG

fzf

Sowohl grep als auch find sind Standardbestandteile der Kommandozeilen-Befehlspalette. Allerdings sind beide Tools nicht so funktional, wie sie sein sollten. Das ruft fzf auf den Plan – einen “Fuzzy File Finder”. Mit “Fuzzy” ist dabei gemeint, dass die Details zu dem, was Sie suchen, nicht unbedingt klar definiert sein müssen. Ein Beispiel:

$ tldr fzf

Command-line fuzzy finder.

Similar to sk.

Sobald Sie fzf starten, indiziert das CLI-Tool umgehend das Dateisystem, um Ergebnisvorschläge für Ihre Suchen zu unterbreiten.

Foto: Matthew Tyson | IDG

Aus 878.937 Möglichkeiten hat fzf die 25 Dateien und Verzeichnisse ausgewählt, die unseren Anforderungen entsprechen könnten – und das völlig ohne Umwege.

exa

Mit exa werden langweilige alte ls-Listings schöner und nützlicher:

$ tldr

A modern replacement for ls (List directory contents).

Für eine bessere Developer Experience ohne mentalen Overhead statten Sie ls einfach mit einem exa-Alias aus. Das Tool respektiert die meisten ls-Standardoptionen – exa -l funktioniert also (beispielsweise) genau so, wie Sie es erwarten würden.

Foto: Matthew Tyson | IDG

bat

Die bat-Utility ähnelt dem cat-Tool – ist aber besser:

$ tldr bat

Print and concatenate files.

A cat clone with syntax highlighting and Git integration.

Es handelt sich hierbei im Wesentlichen um eine Komfort- beziehungsweise Developer-Experience-Optimierung – ähnlich wie im Fall von exa. Wenn Sie bat verwenden, erwartet Sie ein vollwertiger File Viewer – inklusive Title, Borders, Line Numbers und insbesondere einer hilfreichen Syntax-Highlighting-Funktion für Programmiersprachen oder Konfigurationsdateien. Dabei reagiert bat auf less/more-Befehle – und wird mit “q” beendet. Die Navigation erfolgt über die Pfeiltasten.

Foto: Matthew Tyson | IDG

nethack

Ein absoluter Kommandozeilen-Klassiker ist nethack – der ursprüngliche, Konsolen-basierte ASCII Dungeon Crawler. Das CLI-Tool wird Ihre Produktivität zwar nicht direkt ankurbeln – kann aber durchaus dabei helfen, ein paar Minuten zur Ruhe zu kommen, um komplexe Dev-Probleme zu durchdringen.

Foto: Matthew Tyson | IDG

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.

Every CIO I speak with today is wrestling with some version of the same question: How do we move faster with AI and deliver on our commitments?

It’s an understandable concern. Boards and CEOs are asking about AI. Business leaders are experimenting with use cases. Employees are discovering tools daily, while technology vendors promise unprecedented gains in productivity, innovation, and competitive advantage.

After hundreds of conversations with technology executives over the past year, I’ve become convinced that speed isn’t the real issue. The organizations pulling away from the pack aren’t necessarily adopting AI faster than everyone else. They’re executing more effectively — a subtle distinction that represents one of the defining leadership challenges of the AI era.

Technology has never been the hardest part of transformation. People, priorities, culture, and operating models are the biggest challenges. The ability to translate bold boardroom aspirations into thousands of thoughtful decisions made every day by architects, engineers, product managers, analysts, and business leaders is where competitive advantage is created. AI may be accelerating the pace of change, but it hasn’t changed that fundamental truth.

I’ve met plenty of executives who are exceptional in the boardroom. They know how to frame a vision, influence a board, and build confidence among investors and business leaders. I’ve also met remarkable technologists who instinctively understand the architectural decisions, engineering tradeoffs, and implementation details that determine how great ideas become reality. Modern CIOs, however, must move comfortably between both worlds. Afshean Talasaz is one who stands out among this rare breed.

Long before becoming CIO of Colonial Pipeline, Talasaz built his career from the ground up as a business professional, data scientist, and technologist. He has designed enterprise platforms, built AI capabilities, led technology organizations, and partnered closely with executive leadership teams on business transformation. Today, as an executive in residence with our Practitioners for Practitioners (P4P) community, he helps CIOs and business leaders navigate one of the most significant technology shifts of our generation.

While Talasaz brings deep knowledge of data and AI to the table, his greatest strength is his ability to create strategy and connect it with execution. He can spend the morning discussing enterprise reinvention with the board and the afternoon debating architectural principles with the teams responsible for bringing that vision to life.

That versatility gives Talasaz a unique lens on how CIOs can deliver value with AI.

Software companies have a term for engineers who understand every layer of the technology stack: full-stack developers. Listen to Talasaz and it becomes evident that the AI era requires something similar from technology leaders: a full-stack CIO.

The full-stack CIO: Leading with clarity

A full-stack CIO understands how every layer of the enterprise influences the next. They recognize that every strategic priority becomes a portfolio investment, every investment shapes an operating model, every operating model influences architecture, every architecture choice informs product decisions, every product decision shapes engineering priorities.

The best CIOs understand both ends of that journey. The extraordinary ones understand everything in between.

And those who execute best lead with clarity, Talasaz says.

“Everyone, from executives to middle managers to the people writing code, should be able to explain what we’re trying to achieve,” he emphasizes. “Clarity isn’t that we’ve handed out the PowerPoint. It’s that people genuinely understand where we’re going and can articulate it in their own language.”

One of the unintended consequences of the AI boom is that organizations are beginning to confuse activity with alignment. They have AI councils, AI governance committees, AI innovation labs, AI centers of excellence, AI pilots, and AI roadmaps. Yet if you stop ten people in the hallway and ask a deceptively simple question, What business problem are we actually trying to solve? you’ll often hear ten different answers.

As a result, architects optimize for one objective while product teams optimize for another. Business units pursue opportunities that seem perfectly reasonable from their perspective. Engineers make thoughtful technical decisions based on the information available to them. Individually, none of those decisions are necessarily wrong. Collectively, however, they create organizational drift. AI doesn’t create that problem. It simply accelerates the consequences.

And while AI can be a force multiplier for the positive when every decision is guided by a shared understanding of where the organization is headed, it can also be a force multiplier for the negative, resulting in an organization simply moving faster in different directions.

“When we have the fundamentals right, the tech infrastructure, the operating models, the nuances of how our business actually runs, we get the impacts of AI in a positive way,” Talasaz says. “When we don’t have those in place, AI can amplify the gaps or mute the benefits.”

At a time when so much of the conversation surrounding AI is focused on algorithms, agents, and automation, it’s an important reminder that organizations don’t execute strategy; people do.

Reducing organizational friction

Most executives are familiar with the concept of VUCA that characterizes today’s business environment. But Talasaz stresses the importance of turning this concern inward: “If the world outside our organizations is becoming more volatile, uncertain, complex, and ambiguous, what are we, as leaders, doing to the inside of our organizations?”

Leaders spend enormous amounts of time helping their organizations respond to external disruption but comparatively little time asking whether they are inadvertently re-creating those same conditions internally in response to those external needs. Are we reducing uncertainty or introducing more of it? Are we simplifying work or adding unnecessary complexity? Are we helping people focus on what matters most, or asking them to navigate competing priorities and shifting expectations?

Talasaz refers to this phenomenon as double VUCA — something I’ve witnessed repeatedly while working with CIOs over the past decade. Organizations often assume they’re struggling because of technology limitations when the real constraint is organizational friction. Teams wait for decisions. Priorities shift faster than roadmaps. Governance grows heavier. New committees are formed to solve problems created by existing committees. Everyone is working harder, yet the organization somehow feels slower.

AI amplifies both outcomes. Organizations with clarity become dramatically more effective because AI accelerates good decisions. Organizations without clarity simply accelerate confusion.

Operating model as strategy enabler

AI governance is one way to achieve greater clarity, but as Talasaz says, governance shouldn’t primarily exist inside policy manuals that few people read.

Instead, AI governance should be embedded in the daily rhythms of the organization, shaping how teams collaborate, how decisions are made, how products move from ideas into production, and how innovation happens safely without requiring constant escalation. In other words, it’s all about your operating model.

“If you had to pick one thing that isn’t technology, your operating model is the most important element for executing data and AI at scale,” he says.

The best operating models create enough clarity that capable people can make thousands of decisions independently and confidently, without having to wait for permission. By embedding good governance into the way it works, the organization becomes faster.

This advice echoes something I’ve heard repeatedly from some of the world’s most respected CIOs: High-performing organizations aren’t built on tighter control; they’re built on greater trust, supported by clear principles, shared expectations, and operating models that enable responsible decision-making at every level of the enterprise.

Talasaz points out that technology leaders tend to speak in terms of transformation. He suggests CIOs consider a different word: reinvention.

As he explains, transformation implies replacing what exists today with something new. Reinvention starts with a more clear-eyed and practical premise: Some things absolutely must change; others represent years, sometimes decades, of accumulated expertise, customer trust, operational discipline, and competitive advantage.

Reinvention is about building on those strengths while also creating new ways to deliver value. The leaders making the greatest progress in their AI journeys seem to recognize that it’s less about abandoning the past than thoughtfully preparing the organization for the future.

Closing the gap between strategy and execution

Full-stack CIOs must be able to map out the various layers of execution and planning that need to be done at every level of the organization to be successful. To help with this, Talasaz has developed a data and AI framework that draws on his own experiences “from the keyboard to the boardroom.”

As Talasaz sees it, too many organizations have been doing good work in isolation. “They’re doing a lot of the right things,” he says. “They’re just not connected.”

Boards may be discussing growth while business leaders redesign customer experiences. Product teams may be prioritizing new capabilities while architects modernize platforms. Data teams may be improving quality while engineers focus on delivery. Every group makes meaningful progress within its own domain, yet somewhere between strategy and execution, the connective tissue begins to disappear. Talasaz’s framework brings those connecting points to the forefront.

Crucially, the framework doesn’t begin with technology or AI or even with data. It begins with the experiences the organization hopes to create for its customers, employees, or partners. Many AI initiatives start with the question, “What can this technology do?” And indeed, we need to be inspired by the possibilities and challenged to think differently by what the technology can do. But, Talasaz emphasizes, we also need to ask what experiences we need to deliver for our business and how the technology can make that a reality.

The framework challenges CIOs to answer that question first. Only after the experiences are clearly defined does the conversation move to the capabilities required to deliver it, the business activities that support those capabilities, the AI and data products that enable them, and finally the data foundation that makes everything possible.

This shift in perspective ensures that, rather than allowing technology investments to search for business value, the business experience defines the technology required to deliver it. For CIOs, that’s more than a planning exercise. It’s a fundamentally different way of leading.

Over the coming months, the P4P community will be convening a series of small CxO roundtables to explore these issues and work more deeply with Afshean Talasaz’s 6×6 Data and AI Framework. CIOs and other enterprise leaders interested in participating are welcome to reach out to me directly.

I haven’t slept much in the past few weeks. Not because of some theoretical cyber risk that keeps many executives awake, but because reality just delivered a real wake-up call to our industry — a call that every executive must answer, now.

Imagine this: A major global enterprise, a company most of us interact with indirectly every single day, wakes up to find its entire digital environment obliterated. Thousands of employees in dozens of offices and remote locations are suddenly offline. Customers are cut off, supply chains grind to a halt and regulators are notified with a chilling admission: “We have no idea when we’ll be back.”

This wasn’t ransomware. There was no negotiation, no decryption key to buy, no easy way out. It was destruction — deliberate, coordinated and geopolitically motivated — not monetary.

As a chief customer officer who’s worked with countless customers on cyberattack risks, my perspective hits a bit differently than a CISO or a CTO. I see the aftermath, not just the attack surface. I see the faces behind the tickets, the operations team locked out of their own systems, the support agent answering panicked calls at dawn. And I ask: How many organizations have actually stress-tested their response to this scenario — not a hypothetical, but this very real, lights-out event? Here’s what every leader needs to confront today:

Recovery is not just a technical exercise

The first assumption to break during a real crisis is the belief that recovery is purely technical.

Many organizations have done tabletop exercises and have a backup and recovery playbook, so they feel prepared. They can point to backup windows, retention schedules and immutability controls. The moment a true blackout happens, a different reality surfaces. The people who own the recovery steps either do not know each other, lack the authority to make decisions without supervisor approval or need guidance from offline systems.

The reality is that technical infrastructure almost always holds up better than human infrastructure. Organizations have built their recovery strategy around the assumption that someone competent will be awake, available and empowered when a cyber event happens.

Still, backups are only as good as their independence. Let’s be blunt: If your recovery infrastructure shares identity, authentication or network trust with your Microsoft tenant (such as Azure, Microsoft 365 or Teams), you don’t actually have a recovery plan; you have a false sense of one — and a liability. A recent survey found that while 90% of organizations express confidence in their ability to recover from a cyber incident, fewer than one in three ransomware victims fully recovered their data.

True resilience means immutable, air-gapped backups, untouchable by the same compromise. Anything less is an illusion. I talk to customers about their recovery plans constantly. The customers who have rehearsed all scenarios sleep soundly. Those who haven’t? They’re rolling the dice.

Most business continuity plans ignore ‘total blackout’

I’ve reviewed hundreds of business continuity plans. Almost all assume partial failures — a region, an application, a data center. But what if every system, in every country, goes dark simultaneously? That’s an entirely different playbook. If your team hasn’t run a drill for a global, simultaneous outage, you’re not prepared. The probability is low, but the cost of being unready is existential.

Connected devices, OT systems, field hardware, partner integrations — they all plug into your enterprise network. When the core collapses, it’s not just IT at risk. It’s operational technology, physical safety systems and in regulated sectors, potentially human lives. Understanding and testing those interdependencies is non-negotiable.

This is also where boards need to change the conversation. A study found that only 5% of companies have cybersecurity experts on their board of directors. Recovery time objectives (RTOs) should not be buried in technical appendices. It’s all jargon to boards. That makes translation essential. RTOs must be explained in terms of business impact. “We can recover in four hours” is a technical statement. “Every hour of downtime costs us $2.3M and creates regulatory exposure in three jurisdictions” is a board statement.

That is the level of clarity leaders need.

The most prepared organizations do not wait for an incident to educate the board. They bring the conversation forward proactively. They frame recovery in business terms: revenue, regulatory standing, customer trust and brand reputation.

The most effective framing is often simple. Show the most critical systems. Show what happens if each one is down for one hour, four hours, 24 hours and 72 hours. Show the current recovery capability against each and then show the gap.

If your board is not demanding real answers, your business continuity strategy is likely underfunded and your business is exposed. This is a risk conversation worth forcing because the consequences do not stay inside IT. They can show up in customer churn or missed revenue and ruin an organization’s reputation.

Threat intelligence must be actionable, not archived

Geopolitical attacks, hacktivist campaigns and nation-state targeting aren’t abstract threats. They are active risks, and that intelligence cannot languish in the security team’s inbox. Executive leadership must be looped in — and immediately — so gaps can be closed before they’re exploited. Too often, intelligence enters the security operations function and never reaches the teams responsible for recovery infrastructure or executive decision-making.

If a threat actor is targeting a specific class of backup agents, the team responsible for those agents needs to know now, not two weeks from now. If intelligence suggests destructive activity against a sector, recovery owners need to validate isolation, access paths and restoration procedures immediately. If geopolitical tension increases the likelihood of targeting, executive leadership needs to understand what exposure exists and what actions are being taken. The organizations that survive aren’t just the best at incident response. They’re the ones who anticipated, rehearsed and invested before the attack.

Part of investing in a recovery strategy requires closing the loop between signal and action. The most prepared organizations have already mapped their critical recovery dependencies to specific threat categories. When intelligence touches one of those categories, there is a named owner and a clear set of actions. No guessing or forwarding emails into the void is needed because the distance between the warning and the employees’ ability to do something is shortened.

Looking ahead, the conversation will continue to evolve beyond traditional cyber response. Because in an AI-enabled enterprise, the new question is whether the data within those systems can still be trusted. When AI systems make decisions based on enterprise data, the attack surface becomes the data’s accuracy. A threat actor who quietly corrupts a dataset over 90 days before a recovery event has done more damage than just downtime. They can poison the inputs driving decisions across the business.

Regardless of how AI will change threat intelligence and cyber response, these principles remain the same. Know your problem, whether structural or technological. Ensure your human infrastructure keeps pace with your technical infrastructure, with clear cross-functional ownership and the tools and knowledge to act autonomously. Communicate with your boards often — and correctly.

Let’s not wait for the next headline to ask, “Are we ready?” Have those conversations now. Test your assumptions. Close your gaps. Because in today’s threat landscape, resilience isn’t IT’s job — it’s everyone’s mandate.

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

Over the past few years, I have learned that basic prompts produce inconsistent, hallucination-prone results that no executive would trust in production. What turned the tide was my move to advanced prompting techniques. These weren’t theoretical experiments; they became a practical foundation for reliable, measurable outcomes. I want to share the techniques that consistently delivered the biggest gains in my projects, complete with real before-and-after examples, copy-paste templates, lessons from failures and guidance on when to evolve beyond prompting to agentic systems.

Why advanced prompting still matters in enterprise settings

Sophisticated prompting remains essential for control, reliability and compliance. If you “ask nicely” and hope for the best, you need deterministic behavior, auditable reasoning and minimal risk of hallucination. Here’s what worked for me.

1. Chain-of-Thought (CoT) and its variants: Unlocking step-by-step reasoning

The problem: Models would jump to conclusions on complex analysis tasks, especially involving data interpretation or multi-step logic.

What I did: I started explicitly instructing the model to “think step by step” and show its reasoning.

Before (basic prompt): “Analyze last quarter’s sales data and recommend three actions.”

After (CoT prompt):

“You’re a senior business analyst. Analyze the following sales data step by step: [data]. First, identify the key trends. Second, calculate the rates and anomalies. Third, link findings to business context. Finally, recommend the three prioritized actions with expected impact. Explain your reasoning at each step.”  

Results: Accuracy and depth improved dramatically.

Variants that worked well: Self-consistency. I ran the same CoT prompt multiple times and took the majority consensus. This reduced variability significantly.

Template you can use:

You are [expert role]. Solve this problem by thinking step by step.

[Task or question]

For each step:

1. State your observation or calculation.

2. Explain the implication.

3. Proceed only when confident.

Final answer in this format: [structured output]

2. Tree-of-Thoughts (ToT): Exploring multiple reasoning paths

For truly complex decisions such as resource allocation or risk assessment, linear CoT isn’t enough. Tree-of-Thoughts lets the model generate and evaluate multiple branches.

Example: I was helping a client evaluate three potential vendor platforms for an AI deployment. A standard prompt gave a superficial comparison. With ToT

Prompt Snippet:

Explore three different reasoning paths for selecting the best vendor platform:

Path 1: Focus on cost and scalability.

Path 2: Focus on security, compliance and integration.

Path 3: Focus on innovation and long-term roadmap.

For each path, evaluate pros/cons against our requirements [list].

Then, compare the paths and recommend the strongest overall option with justification.

Outcome: The model surfaced nuanced trade-offs (e.g., one vendor had superior security, but higher integration cost).

When to use: Strategic planning, troubleshooting or scenarios with high uncertainty and multiple viable approaches.

3. ReAct (Reason+ Act) and prompt chaining: Moving toward agentic behavior

One of the biggest leaps I have noticed comes from combining reasoning with tool use and chaining prompts.

ReAct example: (used in data analytics workflow)

You are an AI analyst with access to tools. For the query below:

1. Reason about what information you need.

2. Choose the appropriate tool or action.

3. Observe the result.

4. Repeat until you can answer confidently.

Query: [user request]

In practice, I chained this with retrieval tools. One automated quarterly compliance reporting; the system reasoned about required data, pulled relevant records, validated them, and generated the reports.

4. Meta-prompting and self-reflection: Letting the model improve itself

Use the model to refine its own prompt. This is a huge time-saver.

You are an expert prompt engineer. Improve the following prompt for clarity, structure and effectiveness with [target model]. Make it more precise while preserving intent.

Original prompt: [paste]

Provide the improved version and explain your changes.

Self-reflection loops (asking the model to critique its own output and revise) are a game-changer for content generation and code-review tasks.

5. Multimodal and structured output techniques

With vision-enabled models, I started combining text with images (e.g., uploading architecture diagrams or dashboards).

Tip from experience: Be extremely specific in describing what the models should focus on.

Best practices I learned the hard way

• Start simple, then layer complexity: Over-engineered prompts from Day One usually backfire.
• Model specific tuning: Some models respond better to XML delimiters; others to explicit reasoning.
• Evaluation and versioning: Treat prompts like code if you track versions and run automated evals.
• Security guardrails: Always include instructions against prompt injections and respect data boundaries.
• When to stop prompting: For repetitive, high-stakes workflows, move to full agents or an orchestration framework.

Final takeaways for technical leaders

Advanced prompt engineering has now become a core competency for anyone responsible for enterprise AI outcomes. Start by picking one technique and apply it rigorously to a real business problem. Document before/ after and you will notice why it’s worth mastering.

The field continues evolving towards more automated and agentic systems, but the ability to precisely direct AI reasoning remains foundational.

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

OpenAI has launched Presence, an enterprise service for deploying voice and chat agents that can resolve customer and employee requests, potentially automating some work now handled by frontline support teams.

The agents can answer questions and operate IT systems, and enterprises can decide what actions the agents may take and when they should seek human approval for actions or transfer a case to a human.

OpenAI is already using Presence internally for its English-language phone support channel, where it verifies callers and uses account information to complete approved actions. The company said the system resolves 75% of inbound issues without human assistance.

Another OpenAI service, Codex, can be used to monitor agents and suggest updates or improvements to processes. In OpenAI’s own tests, suggestions from Codex helped reduce handoffs to humans by 15 percentage points over 10 days, it said. Presence also includes simulation and evaluation tools that allow companies to test an agent before deployment. The tests assess whether it reaches the correct outcome, follows company policy, and hands a case to an employee when required.

OpenAI intends each Presence deployment to deal with one kind of task, for example billing issues, insurance claims, or employee IT service requests, with agents getting only the knowledge and system access required for that task.

Presence is not a self-service product: Enterprises will have to sign up for the limited availability program, with integration performed by OpenAI or selected global systems integrators.

Companies exploring or testing Presence include Spanish bank BBVA, which is evaluating the service for everyday banking support in Mexico, and Japanese technology group SoftBank, which is using it in trials involving Japanese-language customer interactions. Australian insurer IAG is assessing whether the technology can help it respond to surges in customer demand during severe weather events.

Workforce impact

OpenAI’s announcement did not address the potential effect of Presence on employment. But its claimed automation rate raises questions about how the technology could affect staffing in customer service and other support functions.

Pareekh Jain, CEO of Pareekh Consulting, said CIOs should regard the 75% figure as evidence that the technology can work, rather than as a benchmark that every enterprise can expect to reach.

Jain said OpenAI’s deployment benefits from being built around the company’s own products and data. Large enterprises may achieve lower automation rates because they must contend with fragmented legacy systems, uneven knowledge bases and more complex compliance demands.

“Most organizations should expect lower initial automation levels that improve over time as the AI agent is refined,” Jain said.

The first workforce effect is more likely to be slower hiring than immediate layoffs, according to Tulika Sheel, senior vice president at Kadence International.

“The roles most exposed are likely to be repetitive, high-volume functions such as frontline customer support and routine back-office processing,” Sheel said. “However, I would expect the first impact to be on hiring and team growth rather than immediate large-scale job cuts. Over time, enterprises may redesign roles around AI-assisted workflows, with humans focusing more on complex cases, escalation, and relationship management.”

Jain said Tier-1 support agents handling predictable queries would face the most exposure. Broader reductions would become more likely only after companies reorganize their operations around the technology.

However, Lian Jye Su, chief analyst at Omdia, said Presence is unlikely to increase the threat of job displacement because companies have used similar customer-support automation from vendors such as Genesys, NiCE, Five9 and AWS for years.

Enterprises are more likely to use Presence alongside employees, with AI handling routine requests while people remain responsible for work requiring judgment and empathy, Su said.

Cost and operational risks

Analysts said CIOs should examine whether Presence can maintain resolution quality as usage grows, since fewer human handoffs could leave employees dealing with a more difficult mix of cases.

“The key question is not simply how many tasks AI can handle, but whether it can handle them reliably at scale,” Sheel said.

The financial case will depend partly on the cost of connecting Presence to existing systems and maintaining the controls needed to govern its use, according to Jain. “Often the biggest cost of enterprise AI is not tokens but integration and governance,” Jain added.

Companies will need to determine what systems and data the agents can access, monitor their performance, and audit the actions they take. Those investments could offset early savings.

Su said the complexity of enterprise IT will make it difficult for OpenAI to automate entire workflows on its own. Enterprises will still need to work with other technology providers and human employees, while CIOs will favor systems that can be audited and integrated with existing infrastructure.

Jain said the economics could improve if companies use the same integrations and governance controls across additional workflows.

Cloudflare recently beat Q1 2026 earnings. Revenue up 34% year over year. EPS ahead of consensus. Full-year guidance raised. Then, in the same breath, they announced 1,100 layoffs, 20% of the company. CEO Matthew Prince’s explanation: “The way we work at Cloudflare has fundamentally changed.”

Block did the same thing. Beat guidance, raised outlook, cut 4,000+ jobs. Both framed it as architecting for the AI era.

This is not a contradiction. This is the new math boards are running. And if you’re a CIO who hasn’t started running it yourself, you’re behind.

The benchmark has moved

AI-native companies have quietly reset what “efficient” means for a technology organization. Midjourney generates over $500M in revenue with roughly 160 employees, over $3M per head. Anthropic hit a $14B annualized run rate in early 2026 with fewer than 3,000 employees. Across the top AI-native startups, the average revenue per employee is $3.48M, nearly twelve times the traditional SaaS benchmark of $300K.

Boards aren’t comparing you to your 2019 self anymore. They’re comparing you to Anthropic.

This is the pressure Cloudflare and Block are responding to. They’re not cutting people because the business is struggling. They’re cutting because investors have internalized a new denominator. Headcount is no longer a proxy for capacity; it’s a liability on the efficiency ratio.

For CIOs, this creates a hiring problem that looks nothing like the cloud or mobile talent gaps of the past decade. Those gaps were about volume: hire 100 cloud engineers, absorb the cost, build the capability… This one is about density; you’re not looking for 100 people. You’re looking for 10 who can deliver what 100 couldn’t, and justify $1M or more in value per seat.

Finding bodies to fill seats has never been easier. Finding people who operate at that level of leverage is a different problem entirely.

‘Acqui-hires’ are a shortcut with a hidden cost

Companies have figured out that recruiting AI-native talent one by one is too slow and that it’s faster to buy a team. Google’s acquisition of the Windsurf founders, Meta bringing in the Scale AI team, Accenture’s string of AI-focused acquisitions: these are acqui-hires dressed up as M&A. The premium on experienced AI talent is high enough, and the urgency real enough, that organizations are skipping traditional hiring loops entirely and buying their way in.

I’ve been on the other side of this. My company, MadKudu, was acquired by HG Insights specifically to bring AI-native capability into an established enterprise business. HG needed change agents who had already figured out how to build and ship in this new era, not just people who’d read about it. That’s the thesis behind most of these deals.

But there’s a cost that doesn’t show up in the acquisition price.

AI-native teams are fast because they operate with a different set of defaults: full access to tools, minimal governance layers, the ability to experiment and ship without a six-week approval cycle. That operating model is not a perk; it’s the fundamental mechanism. It’s why a team of 10 can do what an enterprise team of 100 can’t.

When you acqui-hire that team and then slot them into your existing approval processes, you’ve bought the people and killed the engine. The change agents you paid for become change-frustrated. The attrition that follows is expensive and predictable.

The harder realization: acquiring an AI-native team means accepting how they work. That requires deliberately carving out space for them to operate differently, not just tolerating it but institutionalizing it. The acquisition is an organizational change program, not just a hiring event.

The CIO’s real problem

The governance stack most enterprise organizations run was designed for a headcount world. Every tool vetting cycle, every vendor review, every security approval was calibrated assuming you were managing a large team where consistency and control were the primary objectives.

That calculus breaks when your goal is talent density. The same approval processes that protect against data leaks are now the reason your best people can’t do their best work. When it takes six weeks to approve a tool that your competitor’s team is already shipping with, you’ve traded velocity for the perception of safety.

The practical fix is structured experimentation: clear guardrails, defined boundaries, but explicit permission to try tools before deciding whether to roll them out broadly. Gating everything prevents you from ever discovering what 10x productivity looks like.

The skills inventory question is also more nuanced than it sounds. Job titles won’t tell you where the leverage is. You need to map the actual tasks within each function and assess which can be automated or augmented with AI. That’s where you find the people who, with the right tools, become your $1M/employee talent, not because you hired differently, but because you enabled better.

This is also where the build-versus-buy question gets genuinely tricky. As AI reshapes how products are built and delivered, your internal operating model — how you work, how fast you ship, how you use data — is becoming core IP. Outsourcing delivery means outsourcing the part of the organization where your competitive advantage is now being built.

Closing the gap without slowing down

The AI talent wars are not primarily a recruiting problem. They’re a rethinking of what organizations are supposed to look like.

Boards have a new benchmark. Cloudflare, Block, Amazon, Meta and others have already started restructuring to meet it, publicly, painfully, even while beating their numbers. The question for CIOs isn’t whether this pressure arrives; it’s whether you’re ahead of it or behind it when it does.

The organizations that navigate this well won’t win by outbidding competitors for a handful of elite engineers. They’ll win by designing operating systems that amplify the leverage of the talent they do have, by enabling their best people rather than constraining them, and by treating AI fluency as a core organizational capability rather than a niche specialization.

Talent density is the new headcount model. The sooner your governance, your tooling and your board conversations reflect that, the better positioned you’ll be when the next efficiency report lands.

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

Late in a large enterprise SAP transformation, the strategic governance conversations began to drift. Instead of executive decisions, we found ourselves debating whether the program needed dedicated testing, whether cutover required a full weekend, whether twenty Agile teams really needed coordination support and whether offshore resources were adding value at all.

The questions were not coming from the delivery teams. They were coming from the executive sponsor.

The sponsor had recently been elevated into a senior leadership role and had never sponsored a technology transformation at this scale. The challenge was not authority. The sponsor had every right to ask any question they wanted. The challenge was that strategic governance had quietly turned into a debate about delivery practices, because the sponsor did not yet have the transformation context to focus the conversation anywhere else.

This is not a story about a bad sponsor. The executive in this case was a capable senior leader with strong judgment and authentic intent. They had been placed into a role they had not yet been prepared for, and the pattern that followed was structural, not personal. It is one of the more common patterns I have observed across enterprise transformation programs, and one of the most consistently misdiagnosed.

Most program failures are not execution failures. They are sponsor mismatches.

When governance becomes a debate about delivery practices

When the sponsor does not understand what an enterprise transformation actually requires, governance forums stop functioning as decision bodies and start functioning as practice debates.

You see it in the questions that get asked. Why do we need a dedicated testing phase? Can the Build timeline be compressed? Why does cutover need a full weekend? Why do we need more Scrum Masters across 20 product teams? Can the US team simply work longer hours instead of using offshore resources? On one program, the sponsor suggested shifting the entire project’s working hours to India time, despite roughly 85 percent of the delivery organization being based in the United States.

None of these questions are unreasonable in isolation. Each one targets a real cost or timeline pressure. The problem is what is missing underneath them: an understanding of the operational risks the original choices were designed to mitigate.

When sponsors ask delivery-practice questions without that context, the program leadership team ends up defending the work instead of advancing it. Decision velocity drops. Trust between the program and its sponsor erodes. Senior delivery talent disengages from governance forums where the conversation never reaches the decisions they need made. What looks from the outside like an active sponsor producing engagement is, from inside the program, an active drain on the cycles needed to deliver.

The compounding cost is not unique to any single program. PMI’s research on executive sponsorship consistently identifies sponsor engagement quality, rather than sponsor presence alone, as one of the strongest predictors of project success. The visible symptom is debate. The actual cost is unmade decisions.

Authority is rarely the issue. Literacy is

When transformations stall under a mismatched sponsor, the diagnostic instinct is to question the sponsor’s authority. Are they senior enough? Do they have the cross-functional reach? Can they unblock?

In most of the programs I have led or advised, authority was not the limiting factor. The sponsor in the SAP program above had ample authority. They could unblock any decision the program needed. What had not been developed was the transformation literacy to know which decisions mattered, which were technical noise and which were execution risks that should not be optimized away.

This is what I have come to think of as the literacy problem. Sponsors elevated into transformation roles often have deep functional expertise (finance, operations, business unit leadership) but limited exposure to the distinct functions of PMO, organizational change management, agile delivery, testing and cutover, and how each one reduces a specific category of implementation risk. They are not expected to be SAP configuration experts. But they need enough transformation literacy to recognize which questions actually belong in a steering committee.

Harvard Business Review’s research on effective executive sponsorship has emphasized that sponsorship effectiveness depends as much on judgment as on authority. Judgment is where literacy becomes operational. A sponsor with authority but limited transformation literacy will optimize for speed and cost in ways that consistently underestimate risk. A sponsor with both will make the tradeoffs the program actually needs.

Prosci’s longstanding benchmark studies on change management have ranked active and visible executive sponsorship as the single greatest contributor to change success for two decades. The word that matters in that finding is active. Active sponsorship without transformation literacy can introduce real cost. Not because the sponsor is acting against the program, but because the optimization choices they make are based on incomplete information about what the program is built to protect against.

Shift the conversation from delivery practices to business risk

When the sponsor relationship is already in place and cannot be changed, the program leadership team has one move that consistently works: shift the conversation.

On the SAP program above, we stopped explaining why the testing phase existed. We started explaining the business risk of reducing it. We stopped debating the number of Scrum Masters. We started connecting delivery capacity to coordination across more than twenty Agile teams and the business cost of losing that coordination. We reframed offshore support as a way to maintain delivery momentum around the clock rather than asking the U.S. team to sustain fifteen-hour days.

The shift is from defending delivery practice to explaining business risk. The sponsor does not need to understand why testing takes the time it does. They need to understand what the program is exposed to if testing is compressed. They do not need to know how many Scrum Masters are statistically optimal for twenty Agile teams. They need to know what coordination breaks when the number is wrong.

This reframing accomplishes two things. First, it brings the conversation back to the level at which sponsors actually make decisions: tradeoffs between business outcomes and business risks. Second, it builds transformation literacy in the sponsor over time, almost as a byproduct. By the third or fourth iteration of business-risk-framed conversations, the sponsor begins to ask the right questions on their own.

In practice, this happens through small but deliberate moves. When the sponsor asks why a phase needs the time it takes, the program lead names two or three things that could go wrong if the time is cut and what each would cost the business. When the sponsor asks why a role is needed, the program lead names the work that would not get done without it. Every delivery-practice question gets converted into a business-risk answer.

The program leadership team’s job is not to make the sponsor an expert in SAP delivery. It is to provide enough transformation context so that executive decisions reflect both business priorities and implementation realities.

There are a few phrases I have used with executive sponsors over the years that capture the underlying issue. The sharpest one:

If the decision has to go above the sponsor, they are not the sponsor.

Sponsorship is defined by what the sponsor can decide without asking someone else. That is the test. Anything else is the appearance of sponsorship, not the substance.

For CIOs supporting enterprise transformation, the implication is direct. Sponsor selection, or sponsor preparation when selection is not an option, is not a hierarchy question. It is a transformation capability question. The same execution discipline that goes into defining decision rights, structuring governance and protecting delivery momentum should apply, with equal rigor, to assessing sponsor fit and building sponsor literacy before the program begins.

A sponsor does not need to be the technical expert. They do need to know when to trust the people who are.

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

Four months of Claude Code — that’s all it took for Uber to burn through its entire annual budget for AI. Token after token, engineers embraced the platform with few control mechanisms tying costs to outcomes. The result was a budget runaway and a clear case study in how limited oversight snowballs into an AI blowout.

This is a phenomenon I like to call “shadow tokens” — AI credits paid for by the company but largely invisible to decision-makers. Too many engineers have the final say over how much they consume and, therefore, what it costs. This all-you-can-eat attitude is part of the reason why Microsoft is reportedly winding down many internal licenses across key engineering teams and why one in five organizations is missing its AI spend forecast by more than 50%.

And the trend is only accelerating. By 2028, Gartner predicts that AI coding costs (driven by this kind of ungoverned consumption) will be as much per developer as the salary companies pay that person.

LLMs and agents introduce a new class of variable cost that scales with behavior rather than headcount, putting enterprises on the hook for tools that balloon with workload. I don’t see this as enterprises overspending because they’re reckless — it’s down to a lack of managerial oversight, budget alignment that demands a proven return on investment, and engineer education on how much is too much.

Going forward, CIOs need to thread the AI needle between governance that encourages transparency and reasonable spend without stifling innovation.

When shadow tokens result in real costs

The issue is that AI isn’t a traditional line item. Previously, enterprise leaders onboarded software-as-a-service (SaaS) with a good idea of the total cost. An allocated software seat or annual contract was a known quantity. The cloud added some variation (with fluctuations depending on hosting size), but instances were still modelable. AI flips this status quo on its head — the unit of consumption is behavior and the cost is exponential.

And these specifics aren’t immediately apparent at pilot. Tools can appear inexpensive in controlled experiments yet unpredictably scale depending on session length, context window size, model selection and whether agents run in parallel. This is the fallacy of the $20-per-seat enterprise plan — tokens are charged separately at API rates with no ceiling. The final dollar value of any session is set by factors that finance can’t always model in advance, particularly when these decisions usually rest with the engineers themselves.

According to Deloitte, only 21% of organizations deploying agents have a mature governance model, a real concern because they’re token-eating machines. This is what was happening at Uber — Claude Code in agentic mode was autonomously reading codebases, planning changes across dozens of files and opening pull requests. Each step quickly adds up, with Anthropic’s own documentation noting that agents consume approximately seven times as many tokens as standard sessions.

This is shadow IT and shadow AI, evolved. This time, however, many leaders approved the tool in question without guardrails governing consumption. AI hype adds fuel to the fire and normalizes long sessions. Uber’s CTO, for example, described a company-wide shift toward “agentic software engineering” with employees “who are quietly experimenting, quietly shipping and quietly pushing things forward”. This is an exciting way to test the limits of what’s possible, certainly, but it’s also a position that goes a long way to explaining how the company spent its annual AI budget by April.

Shifting the culture from usage to yield

Engineers haven’t done anything wrong here. In fact, they’re adopting and experimenting as instructed, with Uber creating leaderboards and ranking users by token consumption. More use led to a better ranking, reflecting a culture that lauds new ways of doing things. This behavior is known as “tokenmaxxing,” and its principal knock-on effect is shadow tokens — quantity-over-quality processes that leaders struggle to control until they’re fully realized in the budget. Of course, if management treats adoption metrics as performance metrics, then engineers can’t be blamed for using more tokens. The tension is that the teams driving adoption aren’t the ones managing spend.

None of this is meant to dismiss AI’s productivity possibilities and potential return on investment. Developers save 3.6 hours per week, achieve 60% higher pull request throughput and cut onboarding time in half with automation. Meanwhile, Uber shared that roughly 11% of live backend updates were written by agents with no human in the loop. However, these wins aren’t the problem — it’s that too many teams aren’t connecting input to output. I’ve spoken to admins who discovered their token spend had tripled in a single quarter after using heavier models or accidentally doubling up on agentic applications. Nobody knew until the financial damage was done.

Automation needs to happen sustainably with an eye on the bottom line. In my view, a much better metric for achieving this is AI yield — the measurable business or engineering output generated per dollar spent on tokens. Otherwise, without a feedback loop, even genuinely productive teams are flying blind.

Stopping token waste before an AI blowout

Creating that throughline between AI investment and token consumption starts with established financial metrics. This is possible via maximum spend limits (dictated by spend tagging, workload tiering and cost-per-output benchmarks) per team or project. Then, any additional allocation requires approval, closing the loop between the engineers spending the tokens and the leaders paying for them. AI isn’t cheap and teams should demonstrate a bang for their buck.

This is something we do with our engineering team at Hexnode. Resource allocation for Claude Code and Cursor is tied directly to ROI rather than letting consumption run open-ended. Given the pay-as-you-go nature of these tools, a firm usage limit per team offers simple but essential control.

Similarly, there’s room to apply some of the governance principles IT uses for device management. Things like policy enforcement, role-based access, real-time monitoring and automated alerts can flag usage behavior in advance. Uncovering such insights at the token layer works to identify power users and prevent excessive spending.

We also need to encourage cultures that praise outputs that actually achieve efficiency. AI applications that result in shipping faster, reducing rework and cutting review cycles are gains that should be celebrated. If your company hosts leaderboards, frame unnecessary token burn as wasteful rather than valuable. The organizations creating healthier consumption habits work with their engineers to understand not just how to use AI, but what responsible use looks like and what it costs.

This is a conversation teams need to have now. Anthropic just ended flat-rate pricing for programmatic workloads from June 15. Now, agents, continuous integration pipelines and automated workflows draw from a dedicated monthly credit pool billed separately from the subscription. Once that pool is exhausted, agent tasks either stop entirely or overflow to extra billing. Work can either get very expensive or grind to a halt for teams that aren’t prepared.

Getting a grip on shadow tokens means better rules and tools connecting spend to outcomes. Only by building the financial and cultural infrastructure that encourages sustainable adoption can leaders see what they’re spending, connect it to what they’re getting and course-correct before the costs become a crisis. Ultimately, shadow tokens are only invisible if we choose not to look.

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

For CIOs, learning from the startup ecosystem has never been more critical.

As pressure mounts to transform business operations with AI and agentic systems, IT leaders should be looking to those on the AI vanguard for insights into the strategic and technical decisions necessary to launch, grow, and thrive in today’s AI-disrupted business environment.

So why not immerse yourself in Silicon Valley’s most famous firehose of hyper-accelerated fail-fast and dream-big culture by registering for TechCrunch Disrupt 2026?

Three packed days of 200-plus sessions across six stages will spark new ideas for reshaping your AI strategy, provide fresh perspectives on the architectural, workflow, and resource decisions involved in moving AI from pilots to scale, and give you a sneak peek of business disruptions to come.

Get 10% off your TechCrunch Disrupt pass with the exclusive code CIO10. 

This year’s TechCrunch Disrupt, held Oct. 13-15 at San Francisco’s Moscone West, will feature big-picture conversations on what’s next in AI; discussions on how AI agents are rewriting SaaS, enterprise workflows, software pricing, and security; and demonstrations of AI’s future across robotics, manufacturing, defense, and industrial operations; and more.

Over 10,000 attendees will hear from 250-plus startup founders, technology executives, and enterprise IT leaders about how the future of programming is being rewritten, what enterprise AI security requires, how startups are orchestrating workloads across models while managing cost and reliability at scale, why creating a safety culture is essential for AI deployment, and how startups are deciding what work humans should own versus what should be delegated to AI as they work to build hybrid teams without losing speed, accountability, or culture.

And of course, the rising tide of enterprise-focused startups will be there seeking to bring agentic systems to your business workflows, as well as vendors familiar to your enterprise IT portfolios, such as AWS, Google, and Databricks, and enterprise IT colleagues creating mutually beneficial partnerships with the startup community, such as American Express.

That’s not to mention TechCrunch Disrupt’s signature Startup Battlefield, in which 200 standout companies showcase their innovations to compete for a $100K equity-free prize. The battlefield will give CIOs a rapid-fire, broad view of what’s possible — and a possible early look at the next big enterprise player. After all, Dropbox, Trello, and Cloudflare, among others, roamed that same battlefield before the world knew their names.

And with M&A now an early-stage startup strategy for many from day one, TechCrunch Disrupt’s exhibition floor provides IT leaders not just an opportunity to discuss the nuts and bolts of innovation architecture or how an upstart product can enhance your workflows, but a chance to find your next innovation partner, or more.

Leading-edge startups are figuring out how to make AI work at scale. Shouldn’t you be?

Don’t miss your chance to experience TechCrunch Disrupt 2026. Book your pass today and use the exclusive code CIO10 to save 10% before prices increase.

For CIOs, learning from the startup ecosystem has never been more critical.

As pressure mounts to transform business operations with AI and agentic systems, IT leaders should be looking to those on the AI vanguard for insights into the strategic and technical decisions necessary to launch, grow, and thrive in today’s AI-disrupted business environment.

So why not immerse yourself in Silicon Valley’s most famous firehose of hyper-accelerated fail-fast and dream-big culture by registering for TechCrunch Disrupt 2026?

Three packed days of 200-plus sessions across six stages will spark new ideas for reshaping your AI strategy, provide fresh perspectives on the architectural, workflow, and resource decisions involved in moving AI from pilots to scale, and give you a sneak peek of business disruptions to come.

Get 10% off your TechCrunch Disrupt pass with the exclusive code CIO10. 

This year’s TechCrunch Disrupt, held Oct. 13-15 at San Francisco’s Moscone West, will feature big-picture conversations on what’s next in AI; discussions on how AI agents are rewriting SaaS, enterprise workflows, software pricing, and security; and demonstrations of AI’s future across robotics, manufacturing, defense, and industrial operations; and more.

Over 10,000 attendees will hear from 250-plus startup founders, technology executives, and enterprise IT leaders about how the future of programming is being rewritten, what enterprise AI security requires, how startups are orchestrating workloads across models while managing cost and reliability at scale, why creating a safety culture is essential for AI deployment, and how startups are deciding what work humans should own versus what should be delegated to AI as they work to build hybrid teams without losing speed, accountability, or culture.

And of course, the rising tide of enterprise-focused startups will be there seeking to bring agentic systems to your business workflows, as well as vendors familiar to your enterprise IT portfolios, such as AWS, Google, and Databricks, and enterprise IT colleagues creating mutually beneficial partnerships with the startup community, such as American Express.

That’s not to mention TechCrunch Disrupt’s signature Startup Battlefield, in which 200 standout companies showcase their innovations to compete for a $100K equity-free prize. The battlefield will give CIOs a rapid-fire, broad view of what’s possible — and a possible early look at the next big enterprise player. After all, Dropbox, Trello, and Cloudflare, among others, roamed that same battlefield before the world knew their names.

And with M&A now an early-stage startup strategy for many from day one, TechCrunch Disrupt’s exhibition floor provides IT leaders not just an opportunity to discuss the nuts and bolts of innovation architecture or how an upstart product can enhance your workflows, but a chance to find your next innovation partner, or more.

Leading-edge startups are figuring out how to make AI work at scale. Shouldn’t you be?

Don’t miss your chance to experience TechCrunch Disrupt 2026. Book your pass today and use the exclusive code CIO10 to save 10% before prices increase.

Four months of Claude Code — that’s all it took for Uber to burn through its entire annual budget for AI. Token after token, engineers embraced the platform with few control mechanisms tying costs to outcomes. The result was a budget runaway and a clear case study in how limited oversight snowballs into an AI blowout.

This is a phenomenon I like to call “shadow tokens” — AI credits paid for by the company but largely invisible to decision-makers. Too many engineers have the final say over how much they consume and, therefore, what it costs. This all-you-can-eat attitude is part of the reason why Microsoft is reportedly winding down many internal licenses across key engineering teams and why one in five organizations is missing its AI spend forecast by more than 50%.

And the trend is only accelerating. By 2028, Gartner predicts that AI coding costs (driven by this kind of ungoverned consumption) will be as much per developer as the salary companies pay that person.

LLMs and agents introduce a new class of variable cost that scales with behavior rather than headcount, putting enterprises on the hook for tools that balloon with workload. I don’t see this as enterprises overspending because they’re reckless — it’s down to a lack of managerial oversight, budget alignment that demands a proven return on investment, and engineer education on how much is too much.

Going forward, CIOs need to thread the AI needle between governance that encourages transparency and reasonable spend without stifling innovation.

When shadow tokens result in real costs

The issue is that AI isn’t a traditional line item. Previously, enterprise leaders onboarded software-as-a-service (SaaS) with a good idea of the total cost. An allocated software seat or annual contract was a known quantity. The cloud added some variation (with fluctuations depending on hosting size), but instances were still modelable. AI flips this status quo on its head — the unit of consumption is behavior and the cost is exponential.

And these specifics aren’t immediately apparent at pilot. Tools can appear inexpensive in controlled experiments yet unpredictably scale depending on session length, context window size, model selection and whether agents run in parallel. This is the fallacy of the $20-per-seat enterprise plan — tokens are charged separately at API rates with no ceiling. The final dollar value of any session is set by factors that finance can’t always model in advance, particularly when these decisions usually rest with the engineers themselves.

According to Deloitte, only 21% of organizations deploying agents have a mature governance model, a real concern because they’re token-eating machines. This is what was happening at Uber — Claude Code in agentic mode was autonomously reading codebases, planning changes across dozens of files and opening pull requests. Each step quickly adds up, with Anthropic’s own documentation noting that agents consume approximately seven times as many tokens as standard sessions.

This is shadow IT and shadow AI, evolved. This time, however, many leaders approved the tool in question without guardrails governing consumption. AI hype adds fuel to the fire and normalizes long sessions. Uber’s CTO, for example, described a company-wide shift toward “agentic software engineering” with employees “who are quietly experimenting, quietly shipping and quietly pushing things forward”. This is an exciting way to test the limits of what’s possible, certainly, but it’s also a position that goes a long way to explaining how the company spent its annual AI budget by April.

Shifting the culture from usage to yield

Engineers haven’t done anything wrong here. In fact, they’re adopting and experimenting as instructed, with Uber creating leaderboards and ranking users by token consumption. More use led to a better ranking, reflecting a culture that lauds new ways of doing things. This behavior is known as “tokenmaxxing,” and its principal knock-on effect is shadow tokens — quantity-over-quality processes that leaders struggle to control until they’re fully realized in the budget. Of course, if management treats adoption metrics as performance metrics, then engineers can’t be blamed for using more tokens. The tension is that the teams driving adoption aren’t the ones managing spend.

None of this is meant to dismiss AI’s productivity possibilities and potential return on investment. Developers save 3.6 hours per week, achieve 60% higher pull request throughput and cut onboarding time in half with automation. Meanwhile, Uber shared that roughly 11% of live backend updates were written by agents with no human in the loop. However, these wins aren’t the problem — it’s that too many teams aren’t connecting input to output. I’ve spoken to admins who discovered their token spend had tripled in a single quarter after using heavier models or accidentally doubling up on agentic applications. Nobody knew until the financial damage was done.

Automation needs to happen sustainably with an eye on the bottom line. In my view, a much better metric for achieving this is AI yield — the measurable business or engineering output generated per dollar spent on tokens. Otherwise, without a feedback loop, even genuinely productive teams are flying blind.

Stopping token waste before an AI blowout

Creating that throughline between AI investment and token consumption starts with established financial metrics. This is possible via maximum spend limits (dictated by spend tagging, workload tiering and cost-per-output benchmarks) per team or project. Then, any additional allocation requires approval, closing the loop between the engineers spending the tokens and the leaders paying for them. AI isn’t cheap and teams should demonstrate a bang for their buck.

This is something we do with our engineering team at Hexnode. Resource allocation for Claude Code and Cursor is tied directly to ROI rather than letting consumption run open-ended. Given the pay-as-you-go nature of these tools, a firm usage limit per team offers simple but essential control.

Similarly, there’s room to apply some of the governance principles IT uses for device management. Things like policy enforcement, role-based access, real-time monitoring and automated alerts can flag usage behavior in advance. Uncovering such insights at the token layer works to identify power users and prevent excessive spending.

We also need to encourage cultures that praise outputs that actually achieve efficiency. AI applications that result in shipping faster, reducing rework and cutting review cycles are gains that should be celebrated. If your company hosts leaderboards, frame unnecessary token burn as wasteful rather than valuable. The organizations creating healthier consumption habits work with their engineers to understand not just how to use AI, but what responsible use looks like and what it costs.

This is a conversation teams need to have now. Anthropic just ended flat-rate pricing for programmatic workloads from June 15. Now, agents, continuous integration pipelines and automated workflows draw from a dedicated monthly credit pool billed separately from the subscription. Once that pool is exhausted, agent tasks either stop entirely or overflow to extra billing. Work can either get very expensive or grind to a halt for teams that aren’t prepared.

Getting a grip on shadow tokens means better rules and tools connecting spend to outcomes. Only by building the financial and cultural infrastructure that encourages sustainable adoption can leaders see what they’re spending, connect it to what they’re getting and course-correct before the costs become a crisis. Ultimately, shadow tokens are only invisible if we choose not to look.

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

Traditional phishing techniques are in decline as a result of the disruption of the Tycoon2FA phishing-as-a-service (PHaaS) platform, Microsoft said in a new report, “Email threat landscape: Q2 2026 trends and insights”.

“Phishing volume linked to the platform fell 92% from pre-disruption averages, including QR code phishing and CAPTCHA-gated phishing both declining from their March highs,” the company wrote in the report.

The takedown reduced activity across multiple phishing categories, forcing attackers to shift to newer delivery methods.

Riding this shift in were a few notable phishing campaigns, including an automated business email compromise (BEC) campaign that reached 42,000 organizations in under three hours, and a multi-stage phishing campaign that used nested email (EML) files, calendar invitations, and a Microsoft authentication redirect to deliver malware.

To counter phishing attacks, Microsoft recommends blocking emails containing known bad URLs/ subject fields, enabling password-less authentication methods, or moving to MFA for accounts that still require passwords.

Tycoon2FA disruption sent attackers exploring

The take-down of Tycoon2FA forced its operators to abandon portions of their infrastructure and rework hosting, domain registrations, and delivery mechanisms.

“After falling 15% in March and another 22% in April, Tycoon2FA-linked phishing volume dropped 74% in May to just 1.5 million messages, then fell another 20% in June to 1.2 million, by far the lowest monthly volumes observed in at least a year,” Microsoft said.

The decline extended to QR Code lures and fake CAPTCHA pages, two phishing techniques in which Tycoon2FA accounted for 12% and 14% of industry activity in June, respectively. This indicated that the platform’s customer base had not been able to migrate to a replacement infrastructure.

But cutting off one head of the hacker hydra only gave rise to new tactics elsewhere.

The adaptation came in the form of using Microsoft Teams as a social engineering channel. Attackers established conversations to build trust before attempting credential theft or delivering malicious payloads. “Teams-based phishing volume climbed steadily throughout Q2, with the average number of detected attacks rising 19% from March to April, holding roughly flat into May (+1%), then increasing another 10% into June,” Microsoft said.

Microsoft also observed a highly automated BEC campaign that reached over 67,000 users using scripted emails, Amazon Simple Email Service (SES), and engagement tracking, alongside a separate phishing campaign targeting 107,000 users that abused Microsoft’s authentication flow and trusted cloud services, including Teams archive recording and ICS calendar invite, to disguise malware delivery behind legitimate infrastructure.

Phishing changes but the defense doesn’t

While QR Code and Captcha-based phishing attacks dropped significantly in the second quarter, business email compromise (BEC) charted jumped 121% between March and April, before dropping down again in May.

QR Code phishing represented 8.3 million attacks in June 2026, down from a peak of 18.7 million in March. Similarly, Captcha-gated phishing fell from 12 million attacks in March to 2.2 million in June.

BEC attacks hit 9 million in March, falling to 3.9 million in June.

But even as these phishing classics lost momentum and newer techniques emerged, Microsoft’s defensive advice remained rooted in the basics. It noted organizations should complement email filtering with phishing-resistant authentication such as passkeys and phishing-resistant MFA to reduce the effectiveness of credential theft campaigns.

The company also recommended strengthening Exchange Online Protection and Microsoft Defender for Office 365 with capabilities such as Safe links and Zero-hour Auto Purge (ZAP), in which malicious emails already delivered to mailboxes are removed before they are read, alongside enforcing password-less authentication methods like Windows Hello, FIDO keys, and Microsoft Authenticator.

Microsoft concluded its report with a list of indicators of compromise (IoCs) from the threats observed in the quarter to support detection efforts.

This article first appeared on CSO.

Traditional phishing techniques are in decline as a result of the disruption of the Tycoon2FA phishing-as-a-service (PHaaS) platform, Microsoft said in a new report, “Email threat landscape: Q2 2026 trends and insights”.

“Phishing volume linked to the platform fell 92% from pre-disruption averages, including QR code phishing and CAPTCHA-gated phishing both declining from their March highs,” the company wrote in the report.

The takedown reduced activity across multiple phishing categories, forcing attackers to shift to newer delivery methods.

Riding this shift in were a few notable phishing campaigns, including an automated business email compromise (BEC) campaign that reached 42,000 organizations in under three hours, and a multi-stage phishing campaign that used nested email (EML) files, calendar invitations, and a Microsoft authentication redirect to deliver malware.

To counter phishing attacks, Microsoft recommends blocking emails containing known bad URLs/ subject fields, enabling password-less authentication methods, or moving to MFA for accounts that still require passwords.

Tycoon2FA disruption sent attackers exploring

The take-down of Tycoon2FA forced its operators to abandon portions of their infrastructure and rework hosting, domain registrations, and delivery mechanisms.

“After falling 15% in March and another 22% in April, Tycoon2FA-linked phishing volume dropped 74% in May to just 1.5 million messages, then fell another 20% in June to 1.2 million, by far the lowest monthly volumes observed in at least a year,” Microsoft said.

The decline extended to QR Code lures and fake CAPTCHA pages, two phishing techniques in which Tycoon2FA accounted for 12% and 14% of industry activity in June, respectively. This indicated that the platform’s customer base had not been able to migrate to a replacement infrastructure.

But cutting off one head of the hacker hydra only gave rise to new tactics elsewhere.

The adaptation came in the form of using Microsoft Teams as a social engineering channel. Attackers established conversations to build trust before attempting credential theft or delivering malicious payloads. “Teams-based phishing volume climbed steadily throughout Q2, with the average number of detected attacks rising 19% from March to April, holding roughly flat into May (+1%), then increasing another 10% into June,” Microsoft said.

Microsoft also observed a highly automated BEC campaign that reached over 67,000 users using scripted emails, Amazon Simple Email Service (SES), and engagement tracking, alongside a separate phishing campaign targeting 107,000 users that abused Microsoft’s authentication flow and trusted cloud services, including Teams archive recording and ICS calendar invite, to disguise malware delivery behind legitimate infrastructure.

Phishing changes but the defense doesn’t

While QR Code and Captcha-based phishing attacks dropped significantly in the second quarter, business email compromise (BEC) charted jumped 121% between March and April, before dropping down again in May.

QR Code phishing represented 8.3 million attacks in June 2026, down from a peak of 18.7 million in March. Similarly, Captcha-gated phishing fell from 12 million attacks in March to 2.2 million in June.

BEC attacks hit 9 million in March, falling to 3.9 million in June.

But even as these phishing classics lost momentum and newer techniques emerged, Microsoft’s defensive advice remained rooted in the basics. It noted organizations should complement email filtering with phishing-resistant authentication such as passkeys and phishing-resistant MFA to reduce the effectiveness of credential theft campaigns.

The company also recommended strengthening Exchange Online Protection and Microsoft Defender for Office 365 with capabilities such as Safe links and Zero-hour Auto Purge (ZAP), in which malicious emails already delivered to mailboxes are removed before they are read, alongside enforcing password-less authentication methods like Windows Hello, FIDO keys, and Microsoft Authenticator.

Microsoft concluded its report with a list of indicators of compromise (IoCs) from the threats observed in the quarter to support detection efforts.

Late in a large enterprise SAP transformation, the strategic governance conversations began to drift. Instead of executive decisions, we found ourselves debating whether the program needed dedicated testing, whether cutover required a full weekend, whether twenty Agile teams really needed coordination support and whether offshore resources were adding value at all.

The questions were not coming from the delivery teams. They were coming from the executive sponsor.

The sponsor had recently been elevated into a senior leadership role and had never sponsored a technology transformation at this scale. The challenge was not authority. The sponsor had every right to ask any question they wanted. The challenge was that strategic governance had quietly turned into a debate about delivery practices, because the sponsor did not yet have the transformation context to focus the conversation anywhere else.

This is not a story about a bad sponsor. The executive in this case was a capable senior leader with strong judgment and authentic intent. They had been placed into a role they had not yet been prepared for, and the pattern that followed was structural, not personal. It is one of the more common patterns I have observed across enterprise transformation programs, and one of the most consistently misdiagnosed.

Most program failures are not execution failures. They are sponsor mismatches.

When governance becomes a debate about delivery practices

When the sponsor does not understand what an enterprise transformation actually requires, governance forums stop functioning as decision bodies and start functioning as practice debates.

You see it in the questions that get asked. Why do we need a dedicated testing phase? Can the Build timeline be compressed? Why does cutover need a full weekend? Why do we need more Scrum Masters across 20 product teams? Can the US team simply work longer hours instead of using offshore resources? On one program, the sponsor suggested shifting the entire project’s working hours to India time, despite roughly 85 percent of the delivery organization being based in the United States.

None of these questions are unreasonable in isolation. Each one targets a real cost or timeline pressure. The problem is what is missing underneath them: an understanding of the operational risks the original choices were designed to mitigate.

When sponsors ask delivery-practice questions without that context, the program leadership team ends up defending the work instead of advancing it. Decision velocity drops. Trust between the program and its sponsor erodes. Senior delivery talent disengages from governance forums where the conversation never reaches the decisions they need made. What looks from the outside like an active sponsor producing engagement is, from inside the program, an active drain on the cycles needed to deliver.

The compounding cost is not unique to any single program. PMI’s research on executive sponsorship consistently identifies sponsor engagement quality, rather than sponsor presence alone, as one of the strongest predictors of project success. The visible symptom is debate. The actual cost is unmade decisions.

Authority is rarely the issue. Literacy is

When transformations stall under a mismatched sponsor, the diagnostic instinct is to question the sponsor’s authority. Are they senior enough? Do they have the cross-functional reach? Can they unblock?

In most of the programs I have led or advised, authority was not the limiting factor. The sponsor in the SAP program above had ample authority. They could unblock any decision the program needed. What had not been developed was the transformation literacy to know which decisions mattered, which were technical noise and which were execution risks that should not be optimized away.

This is what I have come to think of as the literacy problem. Sponsors elevated into transformation roles often have deep functional expertise (finance, operations, business unit leadership) but limited exposure to the distinct functions of PMO, organizational change management, agile delivery, testing and cutover, and how each one reduces a specific category of implementation risk. They are not expected to be SAP configuration experts. But they need enough transformation literacy to recognize which questions actually belong in a steering committee.

Harvard Business Review’s research on effective executive sponsorship has emphasized that sponsorship effectiveness depends as much on judgment as on authority. Judgment is where literacy becomes operational. A sponsor with authority but limited transformation literacy will optimize for speed and cost in ways that consistently underestimate risk. A sponsor with both will make the tradeoffs the program actually needs.

Prosci’s longstanding benchmark studies on change management have ranked active and visible executive sponsorship as the single greatest contributor to change success for two decades. The word that matters in that finding is active. Active sponsorship without transformation literacy can introduce real cost. Not because the sponsor is acting against the program, but because the optimization choices they make are based on incomplete information about what the program is built to protect against.

Shift the conversation from delivery practices to business risk

When the sponsor relationship is already in place and cannot be changed, the program leadership team has one move that consistently works: shift the conversation.

On the SAP program above, we stopped explaining why the testing phase existed. We started explaining the business risk of reducing it. We stopped debating the number of Scrum Masters. We started connecting delivery capacity to coordination across more than twenty Agile teams and the business cost of losing that coordination. We reframed offshore support as a way to maintain delivery momentum around the clock rather than asking the U.S. team to sustain fifteen-hour days.

The shift is from defending delivery practice to explaining business risk. The sponsor does not need to understand why testing takes the time it does. They need to understand what the program is exposed to if testing is compressed. They do not need to know how many Scrum Masters are statistically optimal for twenty Agile teams. They need to know what coordination breaks when the number is wrong.

This reframing accomplishes two things. First, it brings the conversation back to the level at which sponsors actually make decisions: tradeoffs between business outcomes and business risks. Second, it builds transformation literacy in the sponsor over time, almost as a byproduct. By the third or fourth iteration of business-risk-framed conversations, the sponsor begins to ask the right questions on their own.

In practice, this happens through small but deliberate moves. When the sponsor asks why a phase needs the time it takes, the program lead names two or three things that could go wrong if the time is cut and what each would cost the business. When the sponsor asks why a role is needed, the program lead names the work that would not get done without it. Every delivery-practice question gets converted into a business-risk answer.

The program leadership team’s job is not to make the sponsor an expert in SAP delivery. It is to provide enough transformation context so that executive decisions reflect both business priorities and implementation realities.

There are a few phrases I have used with executive sponsors over the years that capture the underlying issue. The sharpest one:

If the decision has to go above the sponsor, they are not the sponsor.

Sponsorship is defined by what the sponsor can decide without asking someone else. That is the test. Anything else is the appearance of sponsorship, not the substance.

For CIOs supporting enterprise transformation, the implication is direct. Sponsor selection, or sponsor preparation when selection is not an option, is not a hierarchy question. It is a transformation capability question. The same execution discipline that goes into defining decision rights, structuring governance and protecting delivery momentum should apply, with equal rigor, to assessing sponsor fit and building sponsor literacy before the program begins.

A sponsor does not need to be the technical expert. They do need to know when to trust the people who are.

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

Earlier this month, Nokia provided an AI-RAN platform update that brings an AI-native and programmable compute which is projected to double spectral efficiency by 2028. This increases speed, but more importantly, it can allow mobile operators to create some actual monetization beyond connectivity.

With this release, Nokia is introducing what it calls the industry’s first commercial AI-RAN platform, built on its AI‑native anyRAN software and Nvidia’s Aerial AI-RAN stack running on merchant GPU-based accelerated computing. The company is already seeing more than 20% gains in spectral efficiency from AI-driven radio algorithms, with a roadmap to reach 50% by 2027 and more than 100% by 2028, effectively doubling capacity on existing spectrum in dense cells.

Legacy RAN infrastructure enables connectivity but not much beyond that. The AI-RAN makes the network intelligent and extends AI into the physical world, enabling telcos to get more from their infrastructure investments, including providing a path to 6G. The partnership with Nvidia brings CUDA and AI into mobile environments.

For Network World readers, the headline isn’t just that Nokia got to market first with AI‑RAN—it’s that the company is using AI and GPUs to break the historical coupling between radio performance and custom silicon refresh cycles, and to turn the RAN into an application platform.

What AI-RAN actually is

At a technical level, Nokia’s AI‑RAN is a software‑defined baseband architecture that runs Layer 1/Layer 2 RAN functions and AI models on accelerated compute, primarily GPUs, instead of being locked into fixed‑function ASICs. Udayan Mukherjee, Nokia’s CTO for RAN and core, summarized the vision in the analyst briefing: “AI‑RAN is essentially a platform that turns the radio network into a true AI‑native programmable platform… one software detached from the hardware, defining flexible hardware deployment configurations, including part of the AI grid.”

Several pillars stand out:

• AI‑native design: Algorithms move from traditional linear models to increasingly nonlinear techniques (e.g., advanced channel estimation, deep receivers/transmitters, RKHS-based methods), which demand tensor-heavy compute best delivered by GPUs.
• Software-defined RAN: The same anyRAN software stack runs across different hardware configurations—plug‑in cards, standalone AI‑RAN nodes, and COTS/cloud RAN—so innovation comes via software releases rather than baseband card swaps.
• Programmable “D‑apps” layer: Nokia is pushing a new real‑time E3 interface from Layer 1/2 into an application layer for distributed apps (D‑apps) that can tap IQ samples, channel estimation and scheduling data for use cases such as sensing and location services.
• Crucially, this isn’t meant to replace all custom silicon overnight. Mukherjee was explicit: “We are not dropping the purpose‑built product… but we want to also get to merchant silicon, because that’s the future as we want to develop bigger models and AI elements and value‑added services on top of it.” The result is a hybrid era where AI‑accelerated platforms coexist with existing basebands but begin to shoulder the most compute‑intensive workloads.

Why AI-RAN matters for operators

Nokia and its early operator partners are trying to solve three perennial problems: finite spectrum, changing traffic patterns, and the drag of hardware refresh cycles.

First, spectrum constraints. Aji Ed, Nokia’s head of AI‑RAN and cloud RAN, called spectrum “the first constraint everybody has,” noting that operators have paid “huge amount of money” for bands and now need to “get up to the 2x spectrum” in terms of usable capacity. By running more complex AI models for multi‑user MIMO pairing, channel estimation, carrier aggregation and deep receiver/transmitter functions on GPUs, Nokia believes it can unlock those gains where traditional platforms simply run out of compute headroom.

Second, traffic is shifting. Generative AI and distributed inference workloads are driving more uplink-heavy, latency‑sensitive patterns that current RANs weren’t designed for. AI‑RAN’s ability to adapt scheduling, beamforming and resource allocation dynamically via AI models deployed at the baseband is meant to keep up with this shift.

Third, innovation cadence. In Ed’s words, “hardware upgrades can’t keep up with the innovation… we can’t really have a silicon refresh cycle linked with every three‑year cycle.” Nokia’s subscription‑based software model is designed to deliver new AI algorithms, spectral‑efficiency improvements and network optimization features continuously, without requiring “forklift” hardware replacements.

For operators, the message is attractive: comparable TCO and power to existing basebands, “no hardware premium” for GPU adoption, but higher capacity and a path to new services. Nokia told analysts it has reached performance, price and energy efficiency parity between its custom GridShark silicon and GPU-based systems, while moving the baseband roadmap to merchant silicon.

Nokia’s differentiation strategy

Every major RAN vendor is talking about AI‑enhanced radio, but Nokia is drawing a line between incremental gains and what it claims is a platform shift. When asked why its 2x spectral efficiency ambition is so much higher than the ~20% numbers competitors discuss, Ed pointed to the underlying architecture: “We are able to bring much more complex algorithms into this compute infrastructure… all of these require much higher compute, which is exactly what is coming from the accelerated computing.”

Several differentiators emerge:

• Aggressive spectral roadmap: Nokia is targeting 1.5x by 2027 and 2x by 2028, across TDD massive MIMO and FDD scenarios, with a feature roadmap built jointly with Nvidia and other partners.
• Single code base, three deployment paths: The same anyRAN software stack runs on (1) a GPU‑powered AirScale capacity plug‑in card, (2) a high‑capacity standalone AI‑RAN node, and (3) GPU‑based COTS/cloud RAN servers. This lets operators modernize “at their own pace” and mix brownfield evolution with greenfield AI-native deployments.
• Open ecosystem with D‑apps: Nokia is leaning into ORAN compliance (front‑haul, O1/O2) and actively championing the E3 interface and D‑apps concept within ORAN and AI‑RAN alliances, with Bell Labs and at least two external partners already building sensing and location applications on the platform.
• Software subscription tied to value: The commercial model builds on existing software subscriptions but ties pricing more explicitly to delivered value, such as spectral efficiency improvements and new AI services, rather than pure license metrics.

Mukherjee emphasized the openness angle in the briefing: “We see a lot of third‑party applications, whether it’s improving spectral efficiency or location service or sensing, can be developed on this platform… any AI‑powered services from us in Nokia or from ecosystems can be actually developed on top of it.” For operators burned by closed optimization stacks, that’s a notable pivot.

How AI-RAN unlocks new revenue

Most operators will sign off on AI‑RAN if the capacity and TCO story holds, but the more strategic question is monetization beyond connectivity. Nokia’s spokespeople spent considerable time on this in the analyst call, pointing to several classes of services that are difficult or impossible to deliver without AI running in the RAN itself.

Examples include:

• Integrated sensing: Turning the RAN into a distributed sensor grid that can support applications such as 3D mapping, gesture recognition and environmental monitoring, using the same RF infrastructure. Mukherjee noted, “We have at least two to three partners developing sensing applications on top of it… as well as two other companies developing location services.”
• Physical AI and location services: For factories, logistics hubs and smart cities, AI‑RAN can provide high‑precision positioning and real‑time telemetry for robots, drones and autonomous systems by fusing radio data and AI models at the edge.
• Distributed AI infrastructure: Operators exploring “AI‑native cities” can use AI‑RAN nodes and COTS GPU servers as a distributed inference fabric for applications that need tight latency to endpoints—think AR/VR offload, real‑time video analytics or interactive generative AI experiences.
• Premium connectivity tiers: With fine‑grained, AI‑driven control over uplink/downlink scheduling and QoS, operators can create differentiated SLAs for enterprise slices, mission‑critical IoT and AI workloads, charging for guaranteed performance rather than best‑effort connectivity.

Ed framed the opportunity as a continuum: Superior connectivity from 2x spectral efficiency creates “space for new AI workloads and other use cases,” while the D‑apps ecosystem and subscription model provide a mechanism to package and sell those capabilities. In practice, that could look like:

• Industrial sensing-as-a-service, where Nokia and partners supply D‑apps for integrated sensing and positioning, and operators monetize them per site or per device.
• Network‑exposed APIs for inference, location and RF sensing, integrated into operators’ broader network API portfolios as they pursue “network-as-a-platform” strategies.
• Sector‑specific AI‑native services, such as stadium analytics, transportation corridor monitoring, or drone traffic management, built by ISVs on top of Nokia’s exposed E3 data.

For operators that already use Nokia’s MantaRay and SMO stacks for cross‑network optimization, AI‑RAN essentially becomes the local real‑time execution environment, while R‑apps/X‑apps continue to orchestrate macro-level behaviors. Mukherjee described this layered architecture as “DU and CU on the platform running D‑apps using E3, interfacing to X‑apps and R‑apps through E2SM and connecting to the overall management system/SMO for lifecycle management.”

Adoption path and reality check

Nokia is not promising instant transformation. AI‑RAN pilots are slated for late 2026, with commercial availability on card‑based systems in 2027 and AirScale-based systems around 2028, all driven from a single software stack that supports 4G, 5G and is upgradable to 6G. The company already has trials and collaborations underway with T‑Mobile US, SoftBank, Indosat Ooredoo Hutchison, BT, Elisa, Vodafone, Orange, NTT Docomo, Deutsche Telekom and others.

There are still open questions around 3GPP vs ORAN standardization of E3, the maturity of the D‑apps ecosystem, and how operators will digest yet another subscription layer tied to radio software. But Nokia’s move puts a stake in the ground: in the AI era, the RAN is not just a throughput engine; it’s a programmable AI computer that can be monetized.

For Network World readers evaluating vendor roadmaps, this launch suggests a clear directional change. If Nokia hits its targets, AI‑RAN could mark the point where baseband becomes less about hardware SKUs and more about an AI platform strategy—one where spectral efficiency and new services are rolled out at “software speed,” as Ed described it, rather than at the pace of the next card generation.

Gorodenkoff | shutterstock.com

Die Debatte über (generative) künstliche Intelligenz (KI) fokussiert sich meist auf die Produktivität des Einzelnen – und die Zahlen hierzu sind bemerkenswert. So zeigte ein großangelegtes Feldexperiment der Harvard Business School in Zusammenarbeit mit der Boston Consulting Group, dass der Einsatz generativer KI bei Wissensaufgaben sowohl die Ergebnisqualität als auch die Bearbeitungsgeschwindigkeit signifikant verbessert. Dabei ist der Nivellierungseffekt besonders beachtlich:

• Während erfahrene Fachkräfte ihre Leistung um rund 17 Prozent steigerten,
• lagen die Verbesserungen bei den schwächeren Teilnehmern bei über 40 Prozent.

Diese individuellen Produktivitätsgewinne übertragen sich jedoch nicht automatisch in gleichem Maße auf die Organisationsebene. Unternehmen schaffen nicht bloß durch die isolierte Performance Einzelner Wert, sondern vor allem durch die Fähigkeit, Wissen zu bündeln, komplexe Entscheidungen zu treffen und gemeinsam Innovationen hervorzubringen.

Wenn jedes Teammitglied zunehmend mit seinem eigenen KI-Assistenten interagiert, kann dies die Kernmechanismen erfolgreicher Zusammenarbeit beeinträchtigen. Die entscheidende Herausforderung besteht somit darin, den Zuwachs an individueller Produktivität in eine echte organisatorische Leistungssteigerung zu übersetzen.

3 Produktivitäts-Bruchstellen im KI-Zeitalter

Ob aus temporären Effizienzgewinnen nachhaltige Wettbewerbsvorteile entstehen, hängt deshalb maßgeblich davon ab, wie Führungskräfte die folgenden drei Bruchstellen gestalten, die aufeinander aufbauen. Diese repräsentieren jene organisatorischen Übergänge, an denen individuelle Produktivitätsgewinne durch KI in kollektive Leistungsnachteile umschlagen können – wenn sie nicht aktiv gestaltet werden.

1. Bruchstelle: Wissenssicherung

Der Weg zur Seniorität folgte lange einer stabilen Logik: Operative Erfahrung führte zu Expertise, diese wiederum zu Einfluss. Wer über mehr Wissen verfügte, übernahm komplexere Aufgaben und wurde zur zentralen Orientierungsperson im Team. Generative KI bricht diese Logik auf, da weniger erfahrene Mitarbeitende mithilfe von KI-Tools heute Analysen, Konzepte und Problemlösungen in hoher Qualität erstellen können. Ein Teil des traditionellen Wissensvorsprungs erfahrener Kräfte verliert dadurch seine Exklusivität.

Auf diese Weise gerät ein impliziter Erfolgsfaktor von Organisationen ins Wanken: der organische Wissenstransfer. Bislang floss Wissen primär über erfahrene Kräfte, was Mentoring und kollektives Lernen quasi „nebenbei“ sicherstellte. Fällt dieser Austausch weg, weil Aufgaben isoliert im Dialog mit der KI gelöst werden, besteht das Risiko eines doppelten Kompetenzverlusts:

• Beschäftigte in Junior-Rollen können mithilfe von KI überzeugende Ergebnisse liefern, ohne den zugrundeliegenden Lösungsweg vollständig verstehen zu müssen. Der Lerneffekt wird dadurch reduziert und die Fähigkeit zur eigenständigen Problemlösung sowie zur kritischen Validierung der KI-Ergebnisse eingeschränkt. Die Folge ist eine wachsende, unkritische Abhängigkeit von der Technologie.
• Erfahrene Fachkräfte laufen Gefahr, zur rein reaktiven Korrekturinstanz von KI-Ergebnissen zu werden. Ihre Erfahrung fließt dann nicht mehr aktiv in die Gestaltung ein, sondern beschränkt sich zunehmend auf die nachträgliche Qualitätskontrolle. Mögliche Folgen sind Motivationsverlust, mentaler Rückzug der Leistungsträger und der schleichende Verlust des in der Organisation vorhandenen Erfahrungswissens.

Um diesen doppelten Kompetenzverlust zu verhindern, müssen Führungskräfte den Rollenwandel der Seniorität aktiv gestalten. Künftig sollte sich diese nicht mehr primär über exklusives Fachwissen definieren, sondern über die Fähigkeit, die richtigen Fragen zu stellen, Zusammenhänge einzuordnen und Teams bei der kritischen Bewertung von KI-Ergebnissen anzuleiten. Diese Begleitung kann nicht erst im Rahmen der abschließenden Qualitätskontrolle erfolgen, sondern muss bereits während der Arbeit mit KI ansetzen.

Ziel ist es, Wissen, Erfahrungswerte und Kontext kontinuierlich zu vermitteln, die Urteilskraft der Junioren gezielt zu entwickeln und sie schrittweise zu einer eigenständigen Validierung und reflektierten Nutzung von KI-Ergebnissen zu befähigen.Gelingt dieser Rollenwandel nicht, können Teams zwar kurzfristig ihre individuelle Produktivität steigern, verlieren jedoch zunehmend das gemeinsame Verständnis für fachliche Zusammenhänge und den organisatorischen Kontext.

Die durch KI erzielten Produktivitätsgewinne können dann durch Fehlentscheidungen, steigenden Korrekturaufwand und einen schleichenden Qualitätsverlust auf Teamebene wieder aufgezehrt werden. Ohne die systematische Sicherung von Erfahrungswissen zu agieren, heißt, teure Fehler zu produzieren – nur deutlich schneller.

2. Bruchstelle: Qualitätssicherung

Die Herausforderung endet jedoch nicht bei der Wissenssicherung. Sie betrifft im nächsten Schritt auch die Art und Weise, wie Teams die Qualität ihrer Entscheidungen absichern, wenn ein wachsender Teil der Analyse-, Bewertungs- und Wissensarbeit durch KI unterstützt wird. Je mehr Vorarbeit KI übernimmt, desto stärker hängt die Qualität organisatorischer Entscheidungen davon ab, die generierten Ergebnisse kritisch zu überprüfen und einzuordnen.

Eine Besonderheit generativer KI besteht darin, dass ihre Leistungsfähigkeit keiner intuitiven Logik folgt. Die eingangs zitierte Studie beschreibt dieses Phänomen als „Jagged Technological Frontier“: KI-Systeme können bei bestimmten Aufgaben eine Performance auf Expertenniveau erreichen, während sie bei scheinbar ähnlichen Fragestellungen überraschend große Schwächen aufweisen. Die Grenzen dieser Leistungsfähigkeit sind jedoch nicht für jeden Nutzer ohne weiteres erkennbar.

Genau daraus entstehen neue Herausforderungen für Führungskräfte: Mit der Integration von KI in den Arbeitsalltag steigt das Risiko des sogenannten “Automation Bias” (PDF), also der Tendenz, algorithmischen Empfehlungen unkritisch zu vertrauen. Die Gefahr liegt dabei selten in offensichtlichen Fehlern, sondern in plausiblen (aber falschen) Antworten, die überzeugend formuliert sind und deshalb ungeprüft übernommen werden.

Zudem greift ein Beschleunigungseffekt: KI verkürzt den Weg von der Fragestellung bis zum Ergebnis erheblich und damit auch jene Diskussionen, mit denen Teams bislang die Qualität ihrer Entscheidungen abgesichert haben. Wo früher Analysen debattiert und Annahmen abgewogen wurden, liegt heute in Sekunden ein Resultat vor. Das eigentliche Risiko liegt dabei darin, dass Ergebnisse schneller entstehen als sie kritisch überprüft werden können. So ist es möglich, dass Produktivitätsgewinne mit einem Verlust an Ergebnisqualität einhergehen.

Führungskräfte sollten daher Strukturen schaffen, die den Einsatz von KI transparent gestalten und Ergebnisse offen zur Diskussion stellen. KI-generierte Inhalte müssen denselben kritischen Maßstäben unterworfen werden wie die Arbeit eines erfahrenen Teammitglieds. Dazu benötigen Teams Validierungskompetenz, eine Verantwortungskultur und etablierte Prüfprozesse. Die entscheidende Frage sollte daher nicht sein, ob ein Ergebnis vom Menschen oder der Maschine stammt. Sondern, wer dieses auf fachliche Korrektheit überprüft und die Verantwortung für die darauf basierende Entscheidung übernimmt.

KI steigert zwar die Geschwindigkeit – das wird jedoch erst dann zum echten Wettbewerbsvorteil, wenn es mit Urteilskraft und gelebter Accountability einhergeht.

3. Bruchstelle: Innovationssicherung

Wie zuvor beschrieben, kann der Einsatz generativer KI gemeinsame Diskussionen verkürzen, was wiederum die Innovationskraft des Unternehmens belasten kann. KI liefert dabei nicht nur einen ersten Lösungsvorschlag, sondern erhöht zugleich die Wahrscheinlichkeit, dass sich Teams früh auf eine gemeinsame Richtung festlegen. Echte Innovationen entstehen jedoch selten durch schnelle Einigkeit: Sie entstehen durch produktive Reibung, tiefgehende Debatten und dadurch, etablierte Denkmuster zu hinterfragen.

Ein wesentlicher psychologischer Mechanismus dieser frühen Konvergenz ist der sogenannte Ankereffekt: Da KI in Sekundenschnelle plausible Ergebnisse liefert, wirkt dieser erste Entwurf als kognitiver Anker. Das menschliche Gehirn orientiert sich somit unbewusst an diesem Startpunkt, was den Suchraum für alternative Lösungen vorzeitig verengt und so die Innovationsfähigkeit schwächen kann.

Führungskräfte stehen deshalb vor der zusätzlichen Aufgabe, produktiven Widerspruch bewusst zu organisieren. Kritische Rückfragen und konträre Sichtweisen sind das notwendige Gegengewicht zur KI-generierten Konvergenz. Und: Organisationen verlieren selten ihre Innovationskraft, weil ihnen Antworten fehlen. Vielmehr, weil sie aufhören, Alternativen ernsthaft zu diskutieren. Eine höhere Geschwindigkeit im Lösungsprozess führt daher nicht automatisch zu höherer Innovationsfähigkeit.

Entscheidend ist, dass Organisationen weiterhin Räume schaffen, in denen unterschiedliche Perspektiven aufeinandertreffen, bestehende Annahmen hinterfragt werden und neue Ideen entstehen können. Mit anderen Worten: KI erzeugt Konvergenz, Innovation braucht Divergenz.

KI schafft eine neue Realität

Diese drei Bruchstellen verdeutlichen, dass generative KI nicht nur Arbeitsprozesse, sondern auch die Grundlagen organisationaler Leistungsfähigkeit grundlegend verändern kann. Wissen entsteht anders, Entscheidungen werden anders getroffen und Innovation entwickelt sich unter veränderten Voraussetzungen.

Je stärker KI in den Arbeitsalltag integriert wird, desto entscheidender wird es, die genannten Bruchstellen bewusst zu gestalten. Der nachhaltige Nutzen von KI entsteht nicht allein durch den Einsatz der Technologie, sondern durch die Fähigkeit einer Organisation, ihre Strukturen, Lernprozesse und Entscheidungsmechanismen an diese neue Realität anzupassen. (fm)

Dieser Beitrag wurde im Rahmen des deutschsprachigen Experten-Netzwerks von Foundry veröffentlicht. Lust mitzumachen? Jetzt bewerben!

A new attack method found by Zenity Labs reveals that AI agents are becoming persistent insiders that attackers can recruit, rather than malware they have to install.

Its researchers have discovered AgentForger, a phishing-based attack that silently creates and launches a fully autonomous AI agent within OpenAI workspaces.

Once running, the agent has full access to apps like Outlook, Slack, SharePoint, and Google Drive. It is configured to operate indefinitely without further user interaction, can approve its own access by toggling “never ask” settings, and can continue to act on new assignments sent via email by the attackers that control it. Broad, unfettered access to systems allows it to perform reconnaissance, harvest sensitive data and credentials, impersonate victims, and launch phishing campaigns.

While OpenAI resolved the vulnerability four days after disclosure, on a larger scale, AgentForger sheds light on what can happen when AI agents go rogue.

“We’re moving into a world where software doesn’t just help people work. It works alongside them,” said Michael Bargury, co-founder and CTO of agentic AI security platform Zenity. “As AI agents become more capable, attackers will naturally look for ways to influence them, just as they’ve always looked for ways to influence people.”

A ‘persistent operator’ that acts without approval

OpenAI’s Workspace Agents can connect and work autonomously across Outlook, Gmail, Slack, Google Drive, SharePoint, and Teams. Users open the agent builder, describe what the agent can do in natural language, connect to tools, set approvals, review and test, schedule actions, then publish. For instance, an agent can autonomously handle incoming emails, review and take actions with approval, gather information from various sources to send out daily briefings, or automatically respond to questions in ChatGPT or Slack channels.

Normally, this is “useful automation,” Zenity AI red team researcher Mike Takahashi wrote in a blog post. But in this attack, “the same scheduler becomes the persistence mechanism.”

The creation workflow kicks off the moment a user clicks on a phishing link containing instructions from the threat actor. For the attack to work, a victim must be logged into ChatGPT and Workspace Agents, and have at least one integration with another app, such as Outlook, Gmail, Slack, Google Drive, SharePoint, or Teams.

Because those connections already exist, OAuth consent screens are not triggered. Furthermore, the victim does not need to click on another link, keep a Builder tab open, or even visit ChatGPT again.

The forged agent is a “persistent operator;” it is installed on the original click and given a schedule, and at those predetermined times, the agent invokes itself, scans for emails from attacker addresses with the subject line “task”, carries those orders out, then returns results to the same attacker-controlled email address.

It goes undetected because the attacker prompt instructs the Builder to toggle Outlook to never ask for approval of its actions. Typically, the default is “always ask,” to keep agents from taking unauthorized action; that switch gives agents the ability to act without asking for human approval.

“AgentForger showed that an attacker could deploy an autonomous insider agent inside your ChatGPT workspace with a single click,” said Bargury. From there, it can continue to access information, harvest credentials from various sources, impersonate employees, and carry out phishing attacks and fraud while “leveraging the trusted victim’s identity.”

A ‘planted accomplice’ that does all the work

Once activated, AgentForger can perform reconnaissance to create an internal map of a company. For instance, agents can scan Outlook, Slack, Teams, Google Drive, SharePoint, or calendar data to identify people, roles, active projects, internal discussions, or all-hands recurring meetings. This can help attackers identify where in the enterprise to target next, based on active teams and channels, projects in the works, or prominent users.

“This is the kind of internal context an attacker normally has to build slowly,” Takahashi noted. But in this scenario, action is based on a single emailed assignment. The attacker’s “planted accomplice” does all the work.

In another scenario, the agent can steal data by searching for and identifying financial documents, business agreements, or invoices. Or, it can steal credentials by scanning for messages containing passwords, one-time codes, access tokens, password recovery links, or API keys. Further, it can impersonate victims to carry out phishing scams, for instance, by sending legitimate-looking Teams messages instructing users to confirm their credentials on a fake Microsoft login page.

In all cases, collected information is organized, analyzed, and sent back to the attacker.

“AgentForger points to something much bigger than a single vulnerability,” said Bargury. “It’s less about one bug and more about understanding how the security model changes as AI becomes part of everyday business operations.”

FOMO exposing security gaps

This isn’t necessarily about trust, but more about the need to move fast and adapt, Bargury emphasized. AI agents are helping employees automate work, make decisions faster, and get more done. But enterprises fear they’ll fall behind if they don’t move quickly enough.

“The challenge is that we’re introducing a fundamentally new kind of technology into the enterprise,” said Bargury. “The pressure to integrate the next AI feature is outpacing the security controls needed to safely deploy it.”

However, the answer isn’t to slow down adoption, he emphasized; the business value is too significant. Rather, the first step is understanding where AI agents exist, who created them, what they’re connected to, and what they’re allowed to do. And when it comes to autonomous agents, enterprises need to pay attention to the processes that trigger them: A schedule, an incoming email, or another automated event.

“Those triggers should be governed just as carefully as the agent itself,” said Bargury.

High-impact actions should require approval where appropriate, and security teams should be able to quickly disable an agent or its triggers if something doesn’t look right, he said.

More broadly, AI agents are introducing the need for a new security model, he pointed out. The question is no longer just “Does this agent have permission?” It’s also, “Is this the behavior we intended?”

“The organizations that answer both questions will be in the strongest position to adopt AI safely,” Bargury said.

AMD executives took to the stage at its Advancing AI 2026 event in San Francisco today to detail the company’s next generation of AI infrastructure solutions, from Instinct MI455X AI accelerator GPUs and 6th Gen EPYC “Venice” CPUs, to Pensando networking, ROCm.AI software and its Helios rack-scale platform that ties it all together.

AMD has been working towards rack-scale AI system solutions for years. Its ZT Systems acquisition last year added valuable engineering talent and intellectual property that is now finally bearing the real fruits. Its Helios AI platform is a major platform evolution for AMD, with shipments scheduled to begin in the second half of this year (which is here and now).

The announcements at Advancing AI show how the company has engineered its AI platform solutions for large reasoning models, sustained inference and agentic workflows. These workloads pressure memory capacity, data movement, networking and CPU orchestration. AMD’s approach is to keep as much data close to the compute engines as possible and move it more efficiently throughout the system, but there’s deeper nuance here that’s obvious versus AMD’s chief rival, NVIDIA.  

AMD’s MI455X targets the AI memory wall

The Instinct MI455X GPU is the compute engine that fuels the Helios rack, and the first GPU based on AMD’s new CDNA 5 architecture. Built with a modular mix of 2nm and 3nm chiplets, it carries 432GB of HBM4 and 23.3TB/s of peak memory bandwidth.

Compared to AMD’s current MI355X, the MI455X offers 1.5 times the memory capacity, up to 2.9 times the peak memory bandwidth and up to four times the peak matrix performance with MXFP4 and MXFP8 data types, which are lower-precision numerical formats designed to accelerate AI processing while reducing memory demands. With MXFP6 (6-bit floating point), performance is rated at up to twice that of MI355X.

AMD also shared some actual, measured internal results using production silicon. The company claims MI455X delivers 3.8 times higher FP8 decode performance, 3.5 times more measured FP4 compute performance and between 2.5 and 3.5 times more networking bandwidth than MI355X, depending on the transfer path tested. Those figures provide more context than just numerical specifications, though they remain AMD-provided comparisons that will need independent validation.

AMD

The architectural choices behind the numbers are important. Reasoning models and long context windows require sizeable KV caches for maintaining AI attention states, while mixture-of-experts models frequently move large amounts of data across accelerators. MI455X should let more model data, activation states and cache remain local. New dedicated IP in hardware can transfer data while the GPU continues processing, and expanded cache and multicast capabilities are designed to reduce redundant data movement to further improve efficiency.

The aforementioned lower-precision formats can also raise throughput and reduce memory use, but model developers still have to determine where they can be applied without unacceptable accuracy loss.

AMD’s Helios rack takes aim at Vera Rubin

Dave Altavilla

Helios is AMD’s primary rack-scale competitor to NVIDIA’s Vera Rubin platform. Each liquid-cooled rack combines 72 MI455X GPUs, 18 single-socket Venice host CPUs and Pensando networking technologies.

In its most complete, premium configuration, AMD rates Helios for 2.9 exaflops of low-precision AI compute, with 31TB of aggregate HBM4 capacity, 1.7PB/s of memory bandwidth, 260TB/s of bidirectional scale-up bandwidth and 43TB/s of scale-out bandwidth.

These are formidable figures, but they are technical specifications rather than actual application benchmarks. The more consequential development is AMD’s move from collections of eight-GPU servers to a 72-GPU shared-memory domain. Models too large for one node can operate across the rack without treating every exchange as a scale-out networking transaction, which benefits large-model inference as well as training.

AMD uses UALink over Ethernet, or UALoE, for an open standard scale-up fabric. Each MI455X provides 3.6TB/s of bidirectional scale-up bandwidth, while the complete rack delivers all-to-all connectivity through a single switch layer. AMD also claims six times more scale-out bandwidth per GPU than MI355X when MI455X is configured with three Pensando Vulcano 800 AI NICs.

While open standards give cloud providers more control over suppliers and system design, AMD and its partners now have to prove those components can deliver the predictable performance, reliability and deployment experience customers expect from a tightly controlled, more vertically integrated platform.

Finally, AMD designed Helios with automatic rerouting around failed links, virtual rack partitions, tray-level serviceability and rack-wide power, cooling and health monitoring. Major hyperscalers and potentially large-scale enterprise customers will likely key in on these capabilities, which can affect the availability, total cost and consistency of the AI services they consume.

Kind of like cowbell, AMD Venice gives agentic AI more CPU

AMD

AMD’s agentic CPU messaging regarding its upcoming Venice-based EPYC processors is mostly marketing speak, but the underlying requirement is very real. An AI agent can invoke retrieval, databases, security checks, code execution and other tools before a GPU generates a response. Running many agents concurrently increases the amount of conventional compute requirements surrounding the accelerators.

Venice scales to 256 Zen 6 cores with support for 512 threads, 16 memory channels, up to 1GB of L3 cache per socket, along with PCIe 6.0 and CXL 3.1 connectivity. AMD is also offering several Venice configurations for other applications, including general-purpose servers, high-frequency workloads, GPU hosts and high-density CPU sandbox systems used to execute agent tools.

Treating the CPU solely as a GPU host understates its role. Gateways, tokenization, vector search, databases and short-lived code execution stress different mixes of per-core performance, thread count, memory bandwidth and I/O. Specifically, AMD’s internal testing shows Venice significantly outperforming its current EPYC 9965 Turin CPU across five parts of the agentic AI pipeline, including gateway processing, context assembly, vector search, enterprise applications and short-lived tool execution. Individual gains vary by workload, but AMD details the overall generational improvement at up to a 1.7 times lift. As with the MI455X figures though, these comparisons come from AMD and will require independent validation.

Pensando networking and ROCm software advance

Keeping GPUs fed with data and coordinating traffic across racks directly affects utilization and operating costs. In fact, GPU utilization is a pretty sad state of affairs currently for some of the major frontier model providers.

As such, Pensando networking has become central to AMD’s roadmap. Helios can connect each MI455X to as many as three 800Gbps Vulcano AI NICs, while Salina DPUs handle front-end networking and infrastructure services.

On the software side, which is an equally critical component, AMD also introduced ROCm.AI, an AI-assisted development layer due to arrive in August. It includes reusable skills for coding agents, simplified management and Hyperloom, which can profile workloads, tune serving configurations, modify kernels and validate results.

These tools address two persistent AMD challenges: developer efficiency and ease of use, and software tuning. Automated optimization still has to produce repeatable gains without creating hard-to-maintain code, however. And while ROCm has progressed significantly over the last few years, NVIDIA’s CUDA retains an advantage in maturity, tooling and developer familiarity.

Customer commitments underscore rack-scale confidence

AMD now has commitments that give its MI450 generation and Helios considerably more weight. Meta and OpenAI have announced multi-generation agreements composed of up to 6GW of AMD compute capacity, with initial 1GW deployments planned for the second half of 2026.

Oracle plans a 50,000-GPU public cloud cluster beginning in the third quarter, while Microsoft will deploy Helios for Azure AI inference. Finally, just before the AMD event, Anthropic announced a strategic partnership for up to 2 Gigawatts of AMD-fueled AI compute, with its first gigawatt expected online in the first half of 2027.

Commitments of this scale reflect confidence in more than just MI455X performance. These customers are evaluating the complete architecture, including Venice CPUs, Pensando networking, ROCm software, rack integration, serviceability and AMD’s ability to deliver and execute across multiple product generations.

There is some financial alignment behind the agreements as well. AMD issued OpenAI performance-based warrants and committed to investing up to $5 billion in Anthropic. That context matters when evaluating these deals as market validation, but these planned deployments are substantial nonetheless and put Helios on a much stronger foundation as it begins shipping.

AMD expands its robotics and embedded foundation

AMD also expanded its physical AI portfolio, building on credible traction from its Xilinx-derived Kria adaptive system-on-modules and embedded technologies that are already powering robotics, machine vision and industrial automation applications.

The new Ryzen AI Embedded X100 combines up to 16 Zen 5 CPU cores, integrated Radeon graphics, a second-generation NPU and as much as 128GB of unified LPDDR5X memory shared across its compute engines. To me this looks a lot like a repackaging and optimization of the company’s Strix Halo platform, but with specific optimizations for the embedded space. Regardless, AMD is pairing X100 with the Kria AI Robotics Developer Platform, which includes a System Module or SOM, and a new Robotics Partner Network spanning hardware, software and platform providers.

Samples began shipping in June, with full production expected in the fourth quarter. This broader objective is to give developers a path across AMD x86 CPUs, GPUs, NPUs and FPGAs for real-time autonomous systems, rather than requiring them to assemble those hardware engines and software components independently.

Execution for AMD is now the test

AMD has assembled a credible platform for the burgeoning agentic AI market that’s blowing up currently with no signs of stopping. MI455X addresses memory and data movement, Venice handles dense agentic CPU workloads, Pensando networking connects global system resources, and ROCm.AI addresses software complexity. Finally, Helios assembles these components into a true competitive threat for NVIDIA’s latest Vera Rubin platform.

AMD’s open architecture may appeal to customers seeking supplier choice, but openness must also translate into reliable deployments, competitive total cost and software that does not require a significant rip-up. NVIDIA enters this cycle with a stronger ecosystem and far more rack-scale deployment experience. The true test will be how easily and reliably customers can integrate, operate and maintain these AMD solutions at scale.

As it stands, AMD now has major customers and a clearly defined architecture with systems engineering expertise behind it. Delivering Helios on schedule and showing that its performance claims translate into a real production workload throughput advantage and total cost of ownership gains will determine how much the competitive gap narrows. And of course, this is in a market that is clamoring for ever-more compute resources with a seemingly insatiable demand for AI services and capacity. That’s an environment for big iron success. Now AMD just has to deliver optimized, turnkey AI platforms. This is far easier said than done, but time will soon tell as deployments take shape this year.

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

Revenue from IBM’s z mainframe portfolio declined 42% in the quarter ended June 30, dragging infrastructure revenue down 7% compared to the year-ago quarter. But Big Blue executives remain positive on the mainframe’s role as an important AI platform.

After warning of an earnings shortfall, IBM lowered its full-year forecast. It now expects 2026 revenue to grow between 4% and 5%, rather than its previous forecast of more than 5% growth. Some parts of its business did well: Software revenue grew 5% in the second quarter to $7.76 billion, fueled by 11% growth in hybrid cloud, 18% growth in data, and 3% growth in automation.

On the infrastructure side, IBM posted second-quarter revenue of $3.8 billion, which is down 7%. Within that business, distributed infrastructure grew 37%, but those gains were offset by a 10% decline in hybrid infrastructure and IBM Z’s 42% drop.

In a July 14 letter to investors released prior to IBM’s July 22 earnings call, CEO Arvind Krishna warned of the earnings shortfall and laid out current challenges. He related the infrastructure performance shortfall to “wrapping on the launch of z17 in the second quarter” and stated: “Given this was the strongest start to a mainframe program in our history, we expected Infrastructure revenue to decline low-single digits for the year, beginning this quarter. What played out was worse than our expectations, driven by a shortfall in our Z performance and the associated software stack, primarily in Transaction Processing.”

In the last few weeks of June, customers shifted capex spending and started purchasing more AI infrastructure components in the form of servers, storage, and memory “to secure supply-constrained infrastructure ahead of expected price increases,” Krishna stated. “This dynamic impacted client buying patterns. While we anticipated some supply chain related impact in our expectations, we did not anticipate the magnitude of the capex reprioritization.”

Yet despite challenges this last quarter, z17 remains at nearly 130% growth program-to-program, according to IBM. That’s “well ahead of z16, which was our strongest program on record, with clients representing 85% of installed MIPs maintaining or growing capacity,” the July 14 letter stated.

Mainframe infrastructure momentum is expected to continue, and IBM is anticipating strong workload growth and AI-driven capacity expansion as clients modernize mission-critical systems and emphasize resiliency and security, Krishna said during the company’s Q2 2026 earnings call on July 22.

“AI is driving incremental capacity growth and new workloads as clients look to run AI closer to their most sensitive data,” IBM senior vice president and CFO James Kavanaugh said in the call. “We are seeing strong early adoption of our AI innovations with nearly 50% of z17 customers investing in AI capabilities with Spyre AI accelerator, and clients deploying Watson X Code Assistant for Z are growing MIPS capacity three times faster than those who are not.”

“In a world where infrastructure costs are rising and efficiency matters more than ever, IBM Z offers a compelling economic advantage,” Kavanaugh continued. “Depending on the size and complexity of workloads, clients can realize a 2 to 15x total cost of ownership benefit versus moving these workloads off the platform, reinforcing why the platform remains central to their operations and positioning us to capture additional value as AI workloads grow.”

“We see no evidence of clients moving off mainframe,” Kavanaugh added. “Clients continue to invest in IBM Z to modernize mission-critical workloads with a focus on resiliency and security.”

In responding to an analyst question, Kavanaugh said three key things drive mainframe demand and purchasing requirements:

“One is capacity workload. It’s the most important determinant. 85% Of the installed MIPS capacity out there in the marketplace today running all those core mission critical workloads are either stable or growing. Clients are adding capacity and workload to mainframe, the viability. And by the way, that’s coming in new AI workloads, analytics workloads, Linux-based workloads, and those MIPS are growing program to date over 15 to 20% installed capacity,” Kavanaugh said.

Number 2 is economic factors. “We don’t talk a lot about this, but I think it’s important for our investors to understand things like total cost of ownership. Depending on the size and complexity of the workload, we have anywhere from a 2 to a 15x TCO advantage running on the mainframe [over smaller server systems]. Again, we do not see any evidence of clients migrating off mainframe and lease propensity, which is a great indicator,” Kavanaugh said.

The third driver is AI. “When you look at it, applications, data security, all on the platform, we do 450 billion inferences per day at 1 millisecond with 8 nines availability,” Kavanaugh said. “We’ve got clients that have already purchased over 50% of our Spire inferencing, and those clients that have purchased that are growing MIPS capacity, the way [we monetize value], by over three times faster than others.”

OpenAI has launched Presence, an enterprise service for deploying voice and chat agents that can resolve customer and employee requests, potentially automating some work now handled by frontline support teams.

The agents can answer questions and operate IT systems, and enterprises can decide what actions the agents may take and when they should seek human approval for actions or transfer a case to a human.

OpenAI is already using Presence internally for its English-language phone support channel, where it verifies callers and uses account information to complete approved actions. The company said the system resolves 75% of inbound issues without human assistance.

Another OpenAI service, Codex, can be used to monitor agents and suggest updates or improvements to processes. In OpenAI’s own tests, suggestions from Codex helped reduce handoffs to humans by 15 percentage points over 10 days, it said. Presence also includes simulation and evaluation tools that allow companies to test an agent before deployment. The tests assess whether it reaches the correct outcome, follows company policy, and hands a case to an employee when required.

OpenAI intends each Presence deployment to deal with one kind of task, for example billing issues, insurance claims, or employee IT service requests, with agents getting only the knowledge and system access required for that task.

Presence is not a self-service product: Enterprises will have to sign up for the limited availability program, with integration performed by OpenAI or selected global systems integrators.

Companies exploring or testing Presence include Spanish bank BBVA, which is evaluating the service for everyday banking support in Mexico, and Japanese technology group SoftBank, which is using it in trials involving Japanese-language customer interactions. Australian insurer IAG is assessing whether the technology can help it respond to surges in customer demand during severe weather events.

Workforce impact

OpenAI’s announcement did not address the potential effect of Presence on employment. But its claimed automation rate raises questions about how the technology could affect staffing in customer service and other support functions.

Pareekh Jain, CEO of Pareekh Consulting, said CIOs should regard the 75% figure as evidence that the technology can work, rather than as a benchmark that every enterprise can expect to reach.

Jain said OpenAI’s deployment benefits from being built around the company’s own products and data. Large enterprises may achieve lower automation rates because they must contend with fragmented legacy systems, uneven knowledge bases and more complex compliance demands.

“Most organizations should expect lower initial automation levels that improve over time as the AI agent is refined,” Jain said.

The first workforce effect is more likely to be slower hiring than immediate layoffs, according to Tulika Sheel, senior vice president at Kadence International.

“The roles most exposed are likely to be repetitive, high-volume functions such as frontline customer support and routine back-office processing,” Sheel said. “However, I would expect the first impact to be on hiring and team growth rather than immediate large-scale job cuts. Over time, enterprises may redesign roles around AI-assisted workflows, with humans focusing more on complex cases, escalation, and relationship management.”

Jain said Tier-1 support agents handling predictable queries would face the most exposure. Broader reductions would become more likely only after companies reorganize their operations around the technology.

However, Lian Jye Su, chief analyst at Omdia, said Presence is unlikely to increase the threat of job displacement because companies have used similar customer-support automation from vendors such as Genesys, NiCE, Five9 and AWS for years.

Enterprises are more likely to use Presence alongside employees, with AI handling routine requests while people remain responsible for work requiring judgment and empathy, Su said.

Cost and operational risks

Analysts said CIOs should examine whether Presence can maintain resolution quality as usage grows, since fewer human handoffs could leave employees dealing with a more difficult mix of cases.

“The key question is not simply how many tasks AI can handle, but whether it can handle them reliably at scale,” Sheel said.

The financial case will depend partly on the cost of connecting Presence to existing systems and maintaining the controls needed to govern its use, according to Jain. “Often the biggest cost of enterprise AI is not tokens but integration and governance,” Jain added.

Companies will need to determine what systems and data the agents can access, monitor their performance, and audit the actions they take. Those investments could offset early savings.

Su said the complexity of enterprise IT will make it difficult for OpenAI to automate entire workflows on its own. Enterprises will still need to work with other technology providers and human employees, while CIOs will favor systems that can be audited and integrated with existing infrastructure.

Jain said the economics could improve if companies use the same integrations and governance controls across additional workflows.

OpenAI has launched Presence, an enterprise service for deploying voice and chat agents that can resolve customer and employee requests, potentially automating some work now handled by frontline support teams.

The agents can answer questions and operate IT systems, and enterprises can decide what actions the agents may take and when they should seek human approval for actions or transfer a case to a human.

OpenAI is already using Presence internally for its English-language phone support channel, where it verifies callers and uses account information to complete approved actions. The company said the system resolves 75% of inbound issues without human assistance.

Another OpenAI service, Codex, can be used to monitor agents and suggest updates or improvements to processes. In OpenAI’s own tests, suggestions from Codex helped reduce handoffs to humans by 15 percentage points over 10 days, it said. Presence also includes simulation and evaluation tools that allow companies to test an agent before deployment. The tests assess whether it reaches the correct outcome, follows company policy, and hands a case to an employee when required.

OpenAI intends each Presence deployment to deal with one kind of task, for example billing issues, insurance claims, or employee IT service requests, with agents getting only the knowledge and system access required for that task.

Presence is not a self-service product: Enterprises will have to sign up for the limited availability program, with integration performed by OpenAI or selected global systems integrators.

Companies exploring or testing Presence include Spanish bank BBVA, which is evaluating the service for everyday banking support in Mexico, and Japanese technology group SoftBank, which is using it in trials involving Japanese-language customer interactions. Australian insurer IAG is assessing whether the technology can help it respond to surges in customer demand during severe weather events.

Workforce impact

OpenAI’s announcement did not address the potential effect of Presence on employment. But its claimed automation rate raises questions about how the technology could affect staffing in customer service and other support functions.

Pareekh Jain, CEO of Pareekh Consulting, said CIOs should regard the 75% figure as evidence that the technology can work, rather than as a benchmark that every enterprise can expect to reach.

Jain said OpenAI’s deployment benefits from being built around the company’s own products and data. Large enterprises may achieve lower automation rates because they must contend with fragmented legacy systems, uneven knowledge bases and more complex compliance demands.

“Most organizations should expect lower initial automation levels that improve over time as the AI agent is refined,” Jain said.

The first workforce effect is more likely to be slower hiring than immediate layoffs, according to Tulika Sheel, senior vice president at Kadence International.

“The roles most exposed are likely to be repetitive, high-volume functions such as frontline customer support and routine back-office processing,” Sheel said. “However, I would expect the first impact to be on hiring and team growth rather than immediate large-scale job cuts. Over time, enterprises may redesign roles around AI-assisted workflows, with humans focusing more on complex cases, escalation, and relationship management.”

Jain said Tier-1 support agents handling predictable queries would face the most exposure. Broader reductions would become more likely only after companies reorganize their operations around the technology.

However, Lian Jye Su, chief analyst at Omdia, said Presence is unlikely to increase the threat of job displacement because companies have used similar customer-support automation from vendors such as Genesys, NiCE, Five9 and AWS for years.

Enterprises are more likely to use Presence alongside employees, with AI handling routine requests while people remain responsible for work requiring judgment and empathy, Su said.

Cost and operational risks

Analysts said CIOs should examine whether Presence can maintain resolution quality as usage grows, since fewer human handoffs could leave employees dealing with a more difficult mix of cases.

“The key question is not simply how many tasks AI can handle, but whether it can handle them reliably at scale,” Sheel said.

The financial case will depend partly on the cost of connecting Presence to existing systems and maintaining the controls needed to govern its use, according to Jain. “Often the biggest cost of enterprise AI is not tokens but integration and governance,” Jain added.

Companies will need to determine what systems and data the agents can access, monitor their performance, and audit the actions they take. Those investments could offset early savings.

Su said the complexity of enterprise IT will make it difficult for OpenAI to automate entire workflows on its own. Enterprises will still need to work with other technology providers and human employees, while CIOs will favor systems that can be audited and integrated with existing infrastructure.

Jain said the economics could improve if companies use the same integrations and governance controls across additional workflows.

This article first appeared on CIO.

Cloudflare recently beat Q1 2026 earnings. Revenue up 34% year over year. EPS ahead of consensus. Full-year guidance raised. Then, in the same breath, they announced 1,100 layoffs, 20% of the company. CEO Matthew Prince’s explanation: “The way we work at Cloudflare has fundamentally changed.”

Block did the same thing. Beat guidance, raised outlook, cut 4,000+ jobs. Both framed it as architecting for the AI era.

This is not a contradiction. This is the new math boards are running. And if you’re a CIO who hasn’t started running it yourself, you’re behind.

The benchmark has moved

AI-native companies have quietly reset what “efficient” means for a technology organization. Midjourney generates over $500M in revenue with roughly 160 employees, over $3M per head. Anthropic hit a $14B annualized run rate in early 2026 with fewer than 3,000 employees. Across the top AI-native startups, the average revenue per employee is $3.48M, nearly twelve times the traditional SaaS benchmark of $300K.

Boards aren’t comparing you to your 2019 self anymore. They’re comparing you to Anthropic.

This is the pressure Cloudflare and Block are responding to. They’re not cutting people because the business is struggling. They’re cutting because investors have internalized a new denominator. Headcount is no longer a proxy for capacity; it’s a liability on the efficiency ratio.

For CIOs, this creates a hiring problem that looks nothing like the cloud or mobile talent gaps of the past decade. Those gaps were about volume: hire 100 cloud engineers, absorb the cost, build the capability… This one is about density; you’re not looking for 100 people. You’re looking for 10 who can deliver what 100 couldn’t, and justify $1M or more in value per seat.

Finding bodies to fill seats has never been easier. Finding people who operate at that level of leverage is a different problem entirely.

‘Acqui-hires’ are a shortcut with a hidden cost

Companies have figured out that recruiting AI-native talent one by one is too slow and that it’s faster to buy a team. Google’s acquisition of the Windsurf founders, Meta bringing in the Scale AI team, Accenture’s string of AI-focused acquisitions: these are acqui-hires dressed up as M&A. The premium on experienced AI talent is high enough, and the urgency real enough, that organizations are skipping traditional hiring loops entirely and buying their way in.

I’ve been on the other side of this. My company, MadKudu, was acquired by HG Insights specifically to bring AI-native capability into an established enterprise business. HG needed change agents who had already figured out how to build and ship in this new era, not just people who’d read about it. That’s the thesis behind most of these deals.

But there’s a cost that doesn’t show up in the acquisition price.

AI-native teams are fast because they operate with a different set of defaults: full access to tools, minimal governance layers, the ability to experiment and ship without a six-week approval cycle. That operating model is not a perk; it’s the fundamental mechanism. It’s why a team of 10 can do what an enterprise team of 100 can’t.

When you acqui-hire that team and then slot them into your existing approval processes, you’ve bought the people and killed the engine. The change agents you paid for become change-frustrated. The attrition that follows is expensive and predictable.

The harder realization: acquiring an AI-native team means accepting how they work. That requires deliberately carving out space for them to operate differently, not just tolerating it but institutionalizing it. The acquisition is an organizational change program, not just a hiring event.

The CIO’s real problem

The governance stack most enterprise organizations run was designed for a headcount world. Every tool vetting cycle, every vendor review, every security approval was calibrated assuming you were managing a large team where consistency and control were the primary objectives.

That calculus breaks when your goal is talent density. The same approval processes that protect against data leaks are now the reason your best people can’t do their best work. When it takes six weeks to approve a tool that your competitor’s team is already shipping with, you’ve traded velocity for the perception of safety.

The practical fix is structured experimentation: clear guardrails, defined boundaries, but explicit permission to try tools before deciding whether to roll them out broadly. Gating everything prevents you from ever discovering what 10x productivity looks like.

The skills inventory question is also more nuanced than it sounds. Job titles won’t tell you where the leverage is. You need to map the actual tasks within each function and assess which can be automated or augmented with AI. That’s where you find the people who, with the right tools, become your $1M/employee talent, not because you hired differently, but because you enabled better.

This is also where the build-versus-buy question gets genuinely tricky. As AI reshapes how products are built and delivered, your internal operating model — how you work, how fast you ship, how you use data — is becoming core IP. Outsourcing delivery means outsourcing the part of the organization where your competitive advantage is now being built.

Closing the gap without slowing down

The AI talent wars are not primarily a recruiting problem. They’re a rethinking of what organizations are supposed to look like.

Boards have a new benchmark. Cloudflare, Block, Amazon, Meta and others have already started restructuring to meet it, publicly, painfully, even while beating their numbers. The question for CIOs isn’t whether this pressure arrives; it’s whether you’re ahead of it or behind it when it does.

The organizations that navigate this well won’t win by outbidding competitors for a handful of elite engineers. They’ll win by designing operating systems that amplify the leverage of the talent they do have, by enabling their best people rather than constraining them, and by treating AI fluency as a core organizational capability rather than a niche specialization.

Talent density is the new headcount model. The sooner your governance, your tooling and your board conversations reflect that, the better positioned you’ll be when the next efficiency report lands.

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

Over the past few years, I have learned that basic prompts produce inconsistent, hallucination-prone results that no executive would trust in production. What turned the tide was my move to advanced prompting techniques. These weren’t theoretical experiments; they became a practical foundation for reliable, measurable outcomes. I want to share the techniques that consistently delivered the biggest gains in my projects, complete with real before-and-after examples, copy-paste templates, lessons from failures and guidance on when to evolve beyond prompting to agentic systems.

Why advanced prompting still matters in enterprise settings

Sophisticated prompting remains essential for control, reliability and compliance. If you “ask nicely” and hope for the best, you need deterministic behavior, auditable reasoning and minimal risk of hallucination. Here’s what worked for me.

1. Chain-of-Thought (CoT) and its variants: Unlocking step-by-step reasoning

The problem: Models would jump to conclusions on complex analysis tasks, especially involving data interpretation or multi-step logic.

What I did: I started explicitly instructing the model to “think step by step” and show its reasoning.

Before (basic prompt): “Analyze last quarter’s sales data and recommend three actions.”

After (CoT prompt):

“You’re a senior business analyst. Analyze the following sales data step by step: [data]. First, identify the key trends. Second, calculate the rates and anomalies. Third, link findings to business context. Finally, recommend the three prioritized actions with expected impact. Explain your reasoning at each step.”  

Results: Accuracy and depth improved dramatically.

Variants that worked well: Self-consistency. I ran the same CoT prompt multiple times and took the majority consensus. This reduced variability significantly.

Template you can use:

You are [expert role]. Solve this problem by thinking step by step.

[Task or question]

For each step:

1. State your observation or calculation.

2. Explain the implication.

3. Proceed only when confident.

Final answer in this format: [structured output]

2. Tree-of-Thoughts (ToT): Exploring multiple reasoning paths

For truly complex decisions such as resource allocation or risk assessment, linear CoT isn’t enough. Tree-of-Thoughts lets the model generate and evaluate multiple branches.

Example: I was helping a client evaluate three potential vendor platforms for an AI deployment. A standard prompt gave a superficial comparison. With ToT

Prompt Snippet:

Explore three different reasoning paths for selecting the best vendor platform:

Path 1: Focus on cost and scalability.

Path 2: Focus on security, compliance and integration.

Path 3: Focus on innovation and long-term roadmap.

For each path, evaluate pros/cons against our requirements [list].

Then, compare the paths and recommend the strongest overall option with justification.

Outcome: The model surfaced nuanced trade-offs (e.g., one vendor had superior security, but higher integration cost).

When to use: Strategic planning, troubleshooting or scenarios with high uncertainty and multiple viable approaches.

3. ReAct (Reason+ Act) and prompt chaining: Moving toward agentic behavior

One of the biggest leaps I have noticed comes from combining reasoning with tool use and chaining prompts.

ReAct example: (used in data analytics workflow)

You are an AI analyst with access to tools. For the query below:

1. Reason about what information you need.

2. Choose the appropriate tool or action.

3. Observe the result.

4. Repeat until you can answer confidently.

Query: [user request]

In practice, I chained this with retrieval tools. One automated quarterly compliance reporting; the system reasoned about required data, pulled relevant records, validated them, and generated the reports.

4. Meta-prompting and self-reflection: Letting the model improve itself

Use the model to refine its own prompt. This is a huge time-saver.

You are an expert prompt engineer. Improve the following prompt for clarity, structure and effectiveness with [target model]. Make it more precise while preserving intent.

Original prompt: [paste]

Provide the improved version and explain your changes.

Self-reflection loops (asking the model to critique its own output and revise) are a game-changer for content generation and code-review tasks.

5. Multimodal and structured output techniques

With vision-enabled models, I started combining text with images (e.g., uploading architecture diagrams or dashboards).

Tip from experience: Be extremely specific in describing what the models should focus on.

Best practices I learned the hard way

• Start simple, then layer complexity: Over-engineered prompts from Day One usually backfire.
• Model specific tuning: Some models respond better to XML delimiters; others to explicit reasoning.
• Evaluation and versioning: Treat prompts like code if you track versions and run automated evals.
• Security guardrails: Always include instructions against prompt injections and respect data boundaries.
• When to stop prompting: For repetitive, high-stakes workflows, move to full agents or an orchestration framework.

Final takeaways for technical leaders

Advanced prompt engineering has now become a core competency for anyone responsible for enterprise AI outcomes. Start by picking one technique and apply it rigorously to a real business problem. Document before/ after and you will notice why it’s worth mastering.

The field continues evolving towards more automated and agentic systems, but the ability to precisely direct AI reasoning remains foundational.

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

I haven’t slept much in the past few weeks. Not because of some theoretical cyber risk that keeps many executives awake, but because reality just delivered a real wake-up call to our industry — a call that every executive must answer, now.

Imagine this: A major global enterprise, a company most of us interact with indirectly every single day, wakes up to find its entire digital environment obliterated. Thousands of employees in dozens of offices and remote locations are suddenly offline. Customers are cut off, supply chains grind to a halt and regulators are notified with a chilling admission: “We have no idea when we’ll be back.”

This wasn’t ransomware. There was no negotiation, no decryption key to buy, no easy way out. It was destruction — deliberate, coordinated and geopolitically motivated — not monetary.

As a chief customer officer who’s worked with countless customers on cyberattack risks, my perspective hits a bit differently than a CISO or a CTO. I see the aftermath, not just the attack surface. I see the faces behind the tickets, the operations team locked out of their own systems, the support agent answering panicked calls at dawn. And I ask: How many organizations have actually stress-tested their response to this scenario — not a hypothetical, but this very real, lights-out event? Here’s what every leader needs to confront today:

Recovery is not just a technical exercise

The first assumption to break during a real crisis is the belief that recovery is purely technical.

Many organizations have done tabletop exercises and have a backup and recovery playbook, so they feel prepared. They can point to backup windows, retention schedules and immutability controls. The moment a true blackout happens, a different reality surfaces. The people who own the recovery steps either do not know each other, lack the authority to make decisions without supervisor approval or need guidance from offline systems.

The reality is that technical infrastructure almost always holds up better than human infrastructure. Organizations have built their recovery strategy around the assumption that someone competent will be awake, available and empowered when a cyber event happens.

Still, backups are only as good as their independence. Let’s be blunt: If your recovery infrastructure shares identity, authentication or network trust with your Microsoft tenant (such as Azure, Microsoft 365 or Teams), you don’t actually have a recovery plan; you have a false sense of one — and a liability. A recent survey found that while 90% of organizations express confidence in their ability to recover from a cyber incident, fewer than one in three ransomware victims fully recovered their data.

True resilience means immutable, air-gapped backups, untouchable by the same compromise. Anything less is an illusion. I talk to customers about their recovery plans constantly. The customers who have rehearsed all scenarios sleep soundly. Those who haven’t? They’re rolling the dice.

Most business continuity plans ignore ‘total blackout’

I’ve reviewed hundreds of business continuity plans. Almost all assume partial failures — a region, an application, a data center. But what if every system, in every country, goes dark simultaneously? That’s an entirely different playbook. If your team hasn’t run a drill for a global, simultaneous outage, you’re not prepared. The probability is low, but the cost of being unready is existential.

Connected devices, OT systems, field hardware, partner integrations — they all plug into your enterprise network. When the core collapses, it’s not just IT at risk. It’s operational technology, physical safety systems and in regulated sectors, potentially human lives. Understanding and testing those interdependencies is non-negotiable.

This is also where boards need to change the conversation. A study found that only 5% of companies have cybersecurity experts on their board of directors. Recovery time objectives (RTOs) should not be buried in technical appendices. It’s all jargon to boards. That makes translation essential. RTOs must be explained in terms of business impact. “We can recover in four hours” is a technical statement. “Every hour of downtime costs us $2.3M and creates regulatory exposure in three jurisdictions” is a board statement.

That is the level of clarity leaders need.

The most prepared organizations do not wait for an incident to educate the board. They bring the conversation forward proactively. They frame recovery in business terms: revenue, regulatory standing, customer trust and brand reputation.

The most effective framing is often simple. Show the most critical systems. Show what happens if each one is down for one hour, four hours, 24 hours and 72 hours. Show the current recovery capability against each and then show the gap.

If your board is not demanding real answers, your business continuity strategy is likely underfunded and your business is exposed. This is a risk conversation worth forcing because the consequences do not stay inside IT. They can show up in customer churn or missed revenue and ruin an organization’s reputation.

Threat intelligence must be actionable, not archived

Geopolitical attacks, hacktivist campaigns and nation-state targeting aren’t abstract threats. They are active risks, and that intelligence cannot languish in the security team’s inbox. Executive leadership must be looped in — and immediately — so gaps can be closed before they’re exploited. Too often, intelligence enters the security operations function and never reaches the teams responsible for recovery infrastructure or executive decision-making.

If a threat actor is targeting a specific class of backup agents, the team responsible for those agents needs to know now, not two weeks from now. If intelligence suggests destructive activity against a sector, recovery owners need to validate isolation, access paths and restoration procedures immediately. If geopolitical tension increases the likelihood of targeting, executive leadership needs to understand what exposure exists and what actions are being taken. The organizations that survive aren’t just the best at incident response. They’re the ones who anticipated, rehearsed and invested before the attack.

Part of investing in a recovery strategy requires closing the loop between signal and action. The most prepared organizations have already mapped their critical recovery dependencies to specific threat categories. When intelligence touches one of those categories, there is a named owner and a clear set of actions. No guessing or forwarding emails into the void is needed because the distance between the warning and the employees’ ability to do something is shortened.

Looking ahead, the conversation will continue to evolve beyond traditional cyber response. Because in an AI-enabled enterprise, the new question is whether the data within those systems can still be trusted. When AI systems make decisions based on enterprise data, the attack surface becomes the data’s accuracy. A threat actor who quietly corrupts a dataset over 90 days before a recovery event has done more damage than just downtime. They can poison the inputs driving decisions across the business.

Regardless of how AI will change threat intelligence and cyber response, these principles remain the same. Know your problem, whether structural or technological. Ensure your human infrastructure keeps pace with your technical infrastructure, with clear cross-functional ownership and the tools and knowledge to act autonomously. Communicate with your boards often — and correctly.

Let’s not wait for the next headline to ask, “Are we ready?” Have those conversations now. Test your assumptions. Close your gaps. Because in today’s threat landscape, resilience isn’t IT’s job — it’s everyone’s mandate.

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

Every CIO I speak with today is wrestling with some version of the same question: How do we move faster with AI and deliver on our commitments?

It’s an understandable concern. Boards and CEOs are asking about AI. Business leaders are experimenting with use cases. Employees are discovering tools daily, while technology vendors promise unprecedented gains in productivity, innovation, and competitive advantage.

After hundreds of conversations with technology executives over the past year, I’ve become convinced that speed isn’t the real issue. The organizations pulling away from the pack aren’t necessarily adopting AI faster than everyone else. They’re executing more effectively — a subtle distinction that represents one of the defining leadership challenges of the AI era.

Technology has never been the hardest part of transformation. People, priorities, culture, and operating models are the biggest challenges. The ability to translate bold boardroom aspirations into thousands of thoughtful decisions made every day by architects, engineers, product managers, analysts, and business leaders is where competitive advantage is created. AI may be accelerating the pace of change, but it hasn’t changed that fundamental truth.

I’ve met plenty of executives who are exceptional in the boardroom. They know how to frame a vision, influence a board, and build confidence among investors and business leaders. I’ve also met remarkable technologists who instinctively understand the architectural decisions, engineering tradeoffs, and implementation details that determine how great ideas become reality. Modern CIOs, however, must move comfortably between both worlds. Afshean Talasaz is one who stands out among this rare breed.

Long before becoming CIO of Colonial Pipeline, Talasaz built his career from the ground up as a business professional, data scientist, and technologist. He has designed enterprise platforms, built AI capabilities, led technology organizations, and partnered closely with executive leadership teams on business transformation. Today, as an executive in residence with our Practitioners for Practitioners (P4P) community, he helps CIOs and business leaders navigate one of the most significant technology shifts of our generation.

While Talasaz brings deep knowledge of data and AI to the table, his greatest strength is his ability to create strategy and connect it with execution. He can spend the morning discussing enterprise reinvention with the board and the afternoon debating architectural principles with the teams responsible for bringing that vision to life.

That versatility gives Talasaz a unique lens on how CIOs can deliver value with AI.

Software companies have a term for engineers who understand every layer of the technology stack: full-stack developers. Listen to Talasaz and it becomes evident that the AI era requires something similar from technology leaders: a full-stack CIO.

The full-stack CIO: Leading with clarity

A full-stack CIO understands how every layer of the enterprise influences the next. They recognize that every strategic priority becomes a portfolio investment, every investment shapes an operating model, every operating model influences architecture, every architecture choice informs product decisions, every product decision shapes engineering priorities.

The best CIOs understand both ends of that journey. The extraordinary ones understand everything in between.

And those who execute best lead with clarity, Talasaz says.

“Everyone, from executives to middle managers to the people writing code, should be able to explain what we’re trying to achieve,” he emphasizes. “Clarity isn’t that we’ve handed out the PowerPoint. It’s that people genuinely understand where we’re going and can articulate it in their own language.”

One of the unintended consequences of the AI boom is that organizations are beginning to confuse activity with alignment. They have AI councils, AI governance committees, AI innovation labs, AI centers of excellence, AI pilots, and AI roadmaps. Yet if you stop ten people in the hallway and ask a deceptively simple question, What business problem are we actually trying to solve? you’ll often hear ten different answers.

As a result, architects optimize for one objective while product teams optimize for another. Business units pursue opportunities that seem perfectly reasonable from their perspective. Engineers make thoughtful technical decisions based on the information available to them. Individually, none of those decisions are necessarily wrong. Collectively, however, they create organizational drift. AI doesn’t create that problem. It simply accelerates the consequences.

And while AI can be a force multiplier for the positive when every decision is guided by a shared understanding of where the organization is headed, it can also be a force multiplier for the negative, resulting in an organization simply moving faster in different directions.

“When we have the fundamentals right, the tech infrastructure, the operating models, the nuances of how our business actually runs, we get the impacts of AI in a positive way,” Talasaz says. “When we don’t have those in place, AI can amplify the gaps or mute the benefits.”

At a time when so much of the conversation surrounding AI is focused on algorithms, agents, and automation, it’s an important reminder that organizations don’t execute strategy; people do.

Reducing organizational friction

Most executives are familiar with the concept of VUCA that characterizes today’s business environment. But Talasaz stresses the importance of turning this concern inward: “If the world outside our organizations is becoming more volatile, uncertain, complex, and ambiguous, what are we, as leaders, doing to the inside of our organizations?”

Leaders spend enormous amounts of time helping their organizations respond to external disruption but comparatively little time asking whether they are inadvertently re-creating those same conditions internally in response to those external needs. Are we reducing uncertainty or introducing more of it? Are we simplifying work or adding unnecessary complexity? Are we helping people focus on what matters most, or asking them to navigate competing priorities and shifting expectations?

Talasaz refers to this phenomenon as double VUCA — something I’ve witnessed repeatedly while working with CIOs over the past decade. Organizations often assume they’re struggling because of technology limitations when the real constraint is organizational friction. Teams wait for decisions. Priorities shift faster than roadmaps. Governance grows heavier. New committees are formed to solve problems created by existing committees. Everyone is working harder, yet the organization somehow feels slower.

AI amplifies both outcomes. Organizations with clarity become dramatically more effective because AI accelerates good decisions. Organizations without clarity simply accelerate confusion.

Operating model as strategy enabler

AI governance is one way to achieve greater clarity, but as Talasaz says, governance shouldn’t primarily exist inside policy manuals that few people read.

Instead, AI governance should be embedded in the daily rhythms of the organization, shaping how teams collaborate, how decisions are made, how products move from ideas into production, and how innovation happens safely without requiring constant escalation. In other words, it’s all about your operating model.

“If you had to pick one thing that isn’t technology, your operating model is the most important element for executing data and AI at scale,” he says.

The best operating models create enough clarity that capable people can make thousands of decisions independently and confidently, without having to wait for permission. By embedding good governance into the way it works, the organization becomes faster.

This advice echoes something I’ve heard repeatedly from some of the world’s most respected CIOs: High-performing organizations aren’t built on tighter control; they’re built on greater trust, supported by clear principles, shared expectations, and operating models that enable responsible decision-making at every level of the enterprise.

Talasaz points out that technology leaders tend to speak in terms of transformation. He suggests CIOs consider a different word: reinvention.

As he explains, transformation implies replacing what exists today with something new. Reinvention starts with a more clear-eyed and practical premise: Some things absolutely must change; others represent years, sometimes decades, of accumulated expertise, customer trust, operational discipline, and competitive advantage.

Reinvention is about building on those strengths while also creating new ways to deliver value. The leaders making the greatest progress in their AI journeys seem to recognize that it’s less about abandoning the past than thoughtfully preparing the organization for the future.

Closing the gap between strategy and execution

Full-stack CIOs must be able to map out the various layers of execution and planning that need to be done at every level of the organization to be successful. To help with this, Talasaz has developed a data and AI framework that draws on his own experiences “from the keyboard to the boardroom.”

As Talasaz sees it, too many organizations have been doing good work in isolation. “They’re doing a lot of the right things,” he says. “They’re just not connected.”

Boards may be discussing growth while business leaders redesign customer experiences. Product teams may be prioritizing new capabilities while architects modernize platforms. Data teams may be improving quality while engineers focus on delivery. Every group makes meaningful progress within its own domain, yet somewhere between strategy and execution, the connective tissue begins to disappear. Talasaz’s framework brings those connecting points to the forefront.

Crucially, the framework doesn’t begin with technology or AI or even with data. It begins with the experiences the organization hopes to create for its customers, employees, or partners. Many AI initiatives start with the question, “What can this technology do?” And indeed, we need to be inspired by the possibilities and challenged to think differently by what the technology can do. But, Talasaz emphasizes, we also need to ask what experiences we need to deliver for our business and how the technology can make that a reality.

The framework challenges CIOs to answer that question first. Only after the experiences are clearly defined does the conversation move to the capabilities required to deliver it, the business activities that support those capabilities, the AI and data products that enable them, and finally the data foundation that makes everything possible.

This shift in perspective ensures that, rather than allowing technology investments to search for business value, the business experience defines the technology required to deliver it. For CIOs, that’s more than a planning exercise. It’s a fundamentally different way of leading.

Over the coming months, the P4P community will be convening a series of small CxO roundtables to explore these issues and work more deeply with Afshean Talasaz’s 6×6 Data and AI Framework. CIOs and other enterprise leaders interested in participating are welcome to reach out to me directly.

Running containers on Windows has never been as easy as it should be. While there are versions of Docker Desktop and Podman that work with both the Windows Subsystem for Linux (WSL) and Hyper-V, I’ve found both overly complex and unstable. Where they have worked, it’s turned out that Hyper-V has been the best option, using a Linux virtual machine to host my containers. That all adds up to overhead, layers of virtual infrastructure that get in the way of work and that need to be rebuilt every time I restart my PC.

Part of the problem is WSL. It’s a good tool, but WSL2’s file-system integration is slow, and you’re left having to work with code using Visual Studio Code’s remote integration, which means putting a VS Code Server in every container you’re building and testing. If you’re working with Kubernetes, that’s even more complexity that needs to be managed, dragging you away from code.

I ended up running most of my container testing and development from a separate machine, a Linux server running containerd. But though it worked (and had all the resources of workstation-class device), it wasn’t portable, and for some reason I’ve yet to uncover, Ubuntu’s remote desktop access doesn’t work for me.

So, it was good to see Microsoft make several announcements around WSL at Build 2026 as part of a push to make Windows a developer platform again. The first, an improved WSL3, is still some way away, but the second, WSL-native container support, shipped at the end of June. It is already seeing community-driven development of Docker Desktop-like tooling to help monitor and manage your containers.

Delivering a WSL-based container platform fits in with the other developer-focused Windows announcements at Build. Making Windows behave more like Linux is Microsoft responding to developer needs, given that more than 50% of servers on Azure run a Linux distribution. Linux is the basis of cloud-native infrastructure, so developers need to be able to build on it wherever they are.

Getting started with WSL container

WSL container provides a new CLI that works in parallel to the familiar WSL, with commands to support the entire container life cycle, from creation to shut down. All you need to do to get started is upgrade your WSL installation to the current pre-release build (at the time of writing this was 2.9.3). Simply open an administrator PowerShell terminal and enter wsl --update --pre-release.

This downloads and installs the latest WSL release. Once you’ve closed and re-opened your terminal (to ensure that you’ve updated its context) you can check that WSLC has installed by entering wslc, which should list the available commands. The new CLI is aliased to WSL container, if you prefer to keep your container work separate from WSL (and avoid typos that might accidentally affect your WSL installations).

Under the hood Microsoft is using WSL container to trial new integration points for Linux in Windows. One key change is the use of a new file system that significantly speeds up access to Windows from inside a container. Another improvement gives WSL container a new networking mode that relays networking connections directly through the Windows network stack, ensuring it has access to the same resources and security as Windows.

Calling Linux containers from Windows applications

Things get more interesting when you start to use the WSL container API from inside your Windows code. Here you can include calls to Linux containers inside your desktop applications, taking advantage of existing services, building and deploying containers from inside your CI/CD pipeline. Using the new file system and networking stack helps reduce the friction that comes with crossing the boundaries between the two platforms.

The WSL container API is available as a NuGet package, with support for C, C#, and C++. It allows your code to start and stop containers, and interact directly with them, sending command-line calls and reading back responses. Where things get interesting is being able to launch a containerized service from your code, exposing its REST or gRPC APIs on a local network port. Microsoft has provided sample code to show you what’s possible at this early stage.

Microsoft is doing something revolutionary here. It’s taking the cloud-native, service-driven model and bringing it into Windows and using it to bridge decades of divergent development. You no longer have to rewrite a service that works on Linux to run in Windows; all you need to do is containerize the service and launch it from the WSL container API. When you’re done, the API will tidy up after you, shutting down the container and reclaiming the memory it used.

It’s important to remember that this is only the first public preview of a rapidly developing platform. There are many opportunities here to, say, build on the syscall translation layer developed for WSL1 to produce a native Windows-to-Linux application integration stack that removes the overhead of using web-based service calls. It will be interesting to see what develops, but this first release is very interesting indeed.

Manage Linux containers from Windows

If you want a Docker Desktop-like experience for building and testing containers on Windows developer hardware, you may not have long to wait. WSL container’s underlying API is already being used to build tools that manage and monitor containers for you. One such tool is the WSL Container Desktop, under development on GitHub. While there aren’t any release builds yet, it’s easy enough to compile and get running by cloning the source repository and building using the .NET CLI. You do need to have the Windows App SDK installed, and some features require access to the Azure CLI.

WSL Container Desktop is built in C#, with a WinUI front end. It’s currently only verified for use on x64, though I was able to compile and run it on an Arm64 PC and use it to test and run containers. Once running, it gives you a well-designed front end for your WSL-hosted containers, showing what’s running and what resources they are using. You can link WSL Container Desktop to container registries, like Docker’s and Azure’s, so you can quickly pull base containers and then use the WSL container environment to add your own code and customizations.

Your main interaction point is the WSL Container Desktop dashboard, which shows what containers are running and their current resource usage. Elements are displayed in cards, taking a cue from Windows’ own user interface and especially from its Settings app. From the dashboard, you can drill down into the available containers, with quick start, stop, and reload options, as well as an extended memory that includes the ability to open a web browser to the appropriate port. I tested this with a container that included an entire KDE webtop, giving me a Linux distro running in a container in my browser.

Other options include a details view that displays current logs and provides tools for inspecting the state of a container. This is the type of tool that comes in useful when debugging and testing container applications, as it can provide insights that the WSL container CLI doesn’t offer. Another option helps you clean up after you’ve downloaded an image and don’t need it anymore, with analytics that show the largest images and images you haven’t used for some time. On top of its tooling for working with WSL containers, WSL Container Desktop provides a basic settings tool that helps you configure its look and feel, as well as how it integrates with Windows.

Run Kubernetes inside Windows for cloud-native development

One of the more useful features of WSL Container Desktop is the ability to quickly stand up a K3s Kubernetes instance in WSL that can be used to host WSL containers, providing a local environment to build and test cloud-native applications wherever you might be. The K3s tooling offers a similar experience to the Kubernetes project’s own Headlamp UI, making it easy to go between your development environment and a production Kubernetes cluster.

It’s fair to describe WSL container as one of those Windows features you didn’t think you needed, but now it’s here you can’t live without it. WSL container simplifies building a container development tool chain in Windows, and at the same time allows you to think about a new generation of hybrid applications that take advantage of decades of development in both Windows and Linux.

The result is something that was unimaginable a few years ago: dropping a Linux container into the middle of a Windows application and treating it as another local service. As the WSL container platform evolves, you should expect to see more ways of bringing Linux and Windows together, using containers to deliver a hybrid platform that gives us the best of both worlds at long last.

Foto: N Universe | shutterstock.com

Unter den Massen von KI-Tools und -Anwendungen, die aktuell als Mobile-, Desktop- oder Web-App zur Wahl stehen, gibt es nicht wenige, die sich in erster Linie dadurch auszeichnen, dass sie:

• Output von fragwürdiger Genauigkeit liefern,

• dubiose Texte erzeugen, oder

• Bilder generieren, die zum Klick auf den X-Button verleiten.

KI-Tools dieser Art sind vor allem darauf ausgerichtet, vom anhaltenden Generative-AI (GenAI)-Hype zu profitieren – und trüben leider auch den Blick für die echten Anwendungsperlen im Bereich generative KI. Wie etwa die folgenden GenAI-Apps, die Ihre Produktivität im Arbeitsalltag drastisch steigern und damit erhebliche Zeitgewinne realisieren können. Probieren Sie’s aus!

1. ChatPDF

Sie kennen solche Situationen: Jemand schickt Ihnen einen schlanken 300-Seiter im .pdf-Format und bereits nach Seite Zwei stellt sich heraus, dass sich dieser in etwa so faszinierend liest wie eine Steuererklärung. In Zukunft dürfen Sie sich bei solchen und ähnlichen Gelegenheiten auf ChatPDF verlassen und dabei richtig Zeit einsparen.

Dieses rein webbasierte Tool – nicht zu verwechseln mit gleichnamigen Mobile Apps – tut exakt das, was es verspricht: Sie befähigen, mit .pdf-Dateien zu chatten. Darüber hinaus können Sie über das Webportal auch Office-Dokumente im .doc- oder .docx-Format hochladen, um anschließend dank KI-Unterstützung möglichst schnell und einfach Informationen über den Inhalt zu erfragen. Dabei kann es sich konkret um einfache Zusammenfassungen oder spezifische, inhaltsbezogene Fragen handeln. Sie können bei Bedarf sogar mehrere Dokumente einspeisen und diese gemeinschaftlich abfragen. Die Verantwortlichen von ChatPDF versprechen dabei, sämtliche Daten sicher zu speichern, auf Anfrage zu löschen und keinesfalls an Dritte weiterzugeben. Dennoch sollten sensible unternehmensbezogene Dokumente eher nicht diesen Weg nehmen.

ChatPDF verarbeitet davon abgesehen Dokumente in (fast) jeder Sprache – und unterstützt diese auch mit Blick auf die KI-Chat-Funktion. Zwei Dokumente dürfen Sie täglich kostenlos über den Service hochladen und abfragen – wobei die Dateien maximal 120 Seiten lang oder 10 MB groß sein dürfen. Die GenAI-Webanwendung dürfte also in ihrer kostenlosen Variante bereits für die meisten Gelegenheits-User ausreichend sein. Sollten Sie Bedarf haben, der darüber hinausgeht, steht Ihnen die Bezahlversion ChatPDF Plus ab 24,99 Euro pro Monat (oder circa 120 Euro pro Jahr) zur Verfügung.

2. Beautiful.ai

Präsentationen (richtig) zu erstellen, kann zum Pain geraten. Es sei denn, Sie lassen Generative AI den wesentlichen Teil des Gestaltungsprozesses übernehmen. Das funktioniert mit der KI-basierten Präsentationssoftware Beautiful.ai. Das (möglicherweise) größte Defizit dieses ebenfalls webbasierten KI-Tools ist, dass es zwar auch deutschsprachige Prompts verarbeitet, zur Zeit aber nur englischsprachige Präsentationen erstellt. Das tut es dafür aber richtig gut, wie bereits die Mini-Demo auf der offiziellen Webseite zeigt. Die KI-App unterstützt Sie nicht nur beim Design der einzelnen Folien, sondern auch bei der Formatierung von Inhalten und dabei, Brand Guidelines einzuhalten – sowie bei allen anderen Aspekten, die wichtig sind, damit Ihre Präsentation einen möglichst professionellen Eindruck hinterlässt.

Foto: JR Raphael | IDG

Die generativen KI-Funktionen des Web-Services umfassen auch eine Funktion, um Inhalte zu generieren. Sie können die KI beispielsweise damit beauftragen, eine ganz bestimmte Art von Präsentation zu einem bestimmten Thema zu erstellen. Dazu zieht die Anwendung öffentlich verfügbare Daten heran. Das Ergebnis bedarf zwar sehr wahrscheinlich einer gründlichen Überprüfung, Überarbeitung und Re-Formulierungskur. Dennoch kann es Ihnen eine nützliche erste Grundlage liefern, auf der sich aufbauen und damit potenziell eine Menge Zeit sparen lässt. Beautiful.ai lässt sich mit PowerPoint, Slack, Webex und Dropbox integrieren.

Leider gibt’s den KI-Präsentations-Zauber nicht umsonst. Ein Abonnement für Beautiful.ai kostet für Einzelpersonen 12 Dollar pro Monat. Im Team mit der GenAI-App zu arbeiten, schlägt mit mindestens 40 Dollar pro Nutzer und Monat zu Buche. Einen individuellen Enterprise-Preisplan gibt’s auf Anfrage.

3. Toki

Allen technologiegetriebenen Productivity-Fortschritten zum Trotz bleibt ein Task lästig: mit einem Kalender zu interagieren. Dieser Aufgabe verschreibt sich der KI-Kalenderassistent Toki, der zuvor unter dem Namen Dola bekannt war. Dabei handelt es sich um eine Chatbot-Lösung, die sich in die Messaging-Plattformen WhatsApp, Telegram, Line sowie iMessage einbinden lässt und sich anschließend zum Beispiel mit den Kalender-Apps von Google und Apple verbindet. Da dieses KI-Tool das Netzwerkprotokoll CalDAV nutzt, um auf die Kalenderdaten zuzugreifen, müssen Sie im Fall von Outlook leider den Umweg über ein Drittanbieter-Plugin nehmen.

Ist die Integration erledigt, steht Toki über integrierte Schaltflächen in den Messaging-Apps zur Verfügung, um Termine zu erstellen, zu verschieben – oder direkt Fragen zu freien Terminslots zu stellen. Darüber hinaus kann dieses Tool auch genutzt werden, um Termine mit Infos anzureichern – beispielsweise Vorschläge für beliebte Restaurants in einer bestimmten Gegend oder auch Ideen für den neuen Firmenslogan, der beim Meeting gefunden werden soll.

Der Service ist in so gut wie allen Sprachen verfügbar und in begrenzten Umfang kostenlos nutzbar. Zahlende Benutzer erhalten mehr Features ab 3,99 Dollar pro Monat.

4. Fathom

Dass virtuelle Meetings richtig schlimm werden können, wissen wir wohl alle. Und auch wenn selbst Generative AI Sie (noch) nicht davor bewahren kann, an digitalen Foltersessions teilzunehmen: Es gibt eine KI-App, die das erträglicher macht – Fathom.

Bei dieser Anwendung handelt es sich um einen KI-Assistenten für Videokonferenzen in Form klassischer Software für Windows– oder Mac-Systeme, die wahlweise mit Zoom, Microsoft Teams oder Google Meet integriert wird. Nach der Installation läuft Fathom unauffällig im Hintergrund und transkribiert (über eine Kalender-Integration) entweder automatisch oder auf Knopfdruck sämtliche Videoanrufe. Notizen machen gehört damit in beiden Fällen der Vergangenheit an. Die Zusammenfassungen oder Informationen stehen direkt zur Verfügung und lassen sich gezielt durchsuchen, weiterverarbeiten oder auch in anderen Produktivitäts- und Collaboration-Tools wie Slack nutzen.

Sämtliche Daten werden dabei laut Fathom während der Übertragung und im Ruhezustand verschlüsselt. Außerdem versprechen die Verantwortlichen ausdrücklich, keine KI-Modelle auf Kundendaten zu trainieren. Sämtliche Details zu Security- und Compliance-Themen sind – vorbildlicherweise – über ein dediziertes Trust Center abrufbar.

Foto: JR Raphael | IDG

Die KI-Software unterstützt diverse verschiedene Sprachen, darunter Englisch, Französisch, Spanisch, Italienisch und Deutsch. Noch dazu ist Fathom komplett kostenlos nutzbar – ohne Einschränkungen hinsichtlich der Anzahl oder Länge der aufgezeichneten Videokonferenzen. Erst fortschrittlichere KI-Funktionen lässt sich das Team hinter der GenAI-Anwendung bezahlen.

Die Fathom Team Edition bietet weitergehende, fortschrittliche KI-Funktionen – beispielsweise automatisierte Keyword Alerts, Highlight-Zusammenstellungen oder Team-Management-Funktionen. Die kostenpflichtige Variante ermöglicht darüber hinaus die Integration in Enterprise-Systeme wie HubSpot, Salesforce oder Zapier. Die Preise beginnen bei 15 Dollar pro Monat und User. Die kostenlose Version bietet Premium-Features für fünf Anrufe pro Monat.

5. Whisper Web

Falls Sie bereits Audiodateien besitzen, die beispielsweise im Rahmen von Meetings oder Telefongesprächen entstanden sind und jetzt in Text umgewandelt werden sollen, ist Whisper Web die richtige Adresse – zumindest, wenn es sich um englischsprachige Audioaufnahmen handelt. Diese quelloffene Webanwendung basiert auf der Entwicklungsarbeit von OpenAI und bietet Echzeit-Transkriptionen direkt im Browser. Das Large Language Model, das dazu zum Einsatz kommt, wird über die App heruntergeladen und lokal ausgeführt – die Daten, die Sie der KI übermitteln, verlassen also das Device nicht.

Whisper Web kann Audioinhalte entweder direkt über Ihr Mikrofon erfassen oder aus entsprechenden Audiodateien extrahieren. Laut den Entwicklern ist die KI-App auf mehrsprachige Daten trainiert und unterstützt auch die Transkription anderer Sprachen (zu Englisch). Der Test mit einem deutschsprachigen Audio-File brachte allerdings nicht mehr als undefiniertes Kauderwelsch hervor. Dafür ist das Tool Open Source und komplett kostenlos nutzbar – Sie benötigen dazu auch kein dediziertes Konto.

6. AudioPen

Wenn Sie nicht ohne Ihr Notizbuch (oder eine entsprechende App) auskommen, könnte das KI-Tool AudioPen sich zu Ihrer neuen Lieblings-App mausern. Die Software erfasst auf Knopfdruck Sprachnotizen jeglicher Art und erstellt daraus im Handumdrehen eine schriftliche Zusammenfassung. Und zwar in “schön”: Füllwörter oder Wiederholungen werden automatisiert eliminiert. Jede Aufnahme wandert direkt in das digitale Notizbuch und lässt sich anschließend durchsuchen, teilen oder auch in eine andere Sprache übersetzen. Auch bei AudioPen handelt es sich um eine vollständig webbasierte Applikation, die sich übrigens optional auch in Form einer Progressive Web App installieren lässt.

Foto: JR Raphael | IDG

Das KI-Tool für Sprachnotizen ist kostenlos nutzbar, solange Sie sich auf Aufnahmen mit bis zu drei Minuten Länge und maximal zehn Notizen beschränken können. Für Ansprüche, die darüber hinausgehen, steht eine “Prime”-Version der App zur Verfügung, die mindestens 99 Dollar pro Jahr kostet – dafür aber uneingeschränkt nutzbar ist und eine Reihe zusätzlicher Funktionen bietet. (fm)

Dieser Beitrag ist im Original bei unserer Schwesterpublikation Computerworld.com erschienen.

Healthy software companies typically don’t suddenly eliminate one-fifth of their workforce, but monday.com is doing just that as it bets on flatter teams, AI agents, and customer implementation expertise as the winning combination in the AI era.

Monday.com co-founder and co-CEO Eran Zinman today announced the “very difficult decision” to reduce the AI work platform company’s global workforce by about 20%, or 620 people.

The move has nothing to do with increasing margins or replacing humans with AI, he insisted in his post on LinkedIn; rather, it’s a calculated decision to trim down and hone the company’s focus as AI becomes integral to day-to-day workflows.

“This is not a distress signal; it is a deliberate reset, disclosed with its price attached,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. “The industry has quietly swapped the meaning of productivity, and this filing is the clearest exhibit yet.”

A ‘significant opportunity’ in technology

In a SEC filing this week, monday.com said its restructuring plan reflects the “ongoing transformation of its product, marketing, and go-to-market strategy.” The move is intended to support a “leaner, more focused operating model” as the company continues to invest in its AI-driven strategy.

Zinman noted in his post that the company has shifted to “doing the work with AI and not just managing it,” and is focused on building environments where “people and AI agents [work] together in one workspace.”

In recent months, monday.com has evolved its products, strategy, and the way it serves its customers, and Zinman contended that “the organization we built for our previous chapter is not the organization that fits the new AI era.” Monday.com needs to “execute more decisively,” take on new challenges, and quickly respond to market changes, he said.

“We have never seen such a significant opportunity in software, driven by such exciting technology,” Zinman noted. He emphasized that the reduction is not to replace people with AI, nor to improve margins; the “vast majority” of savings will be reinvested into talent, products, and AI.

The restructuring will result in a “flatter organization” with fewer management layers and smaller, more autonomous teams, and monday.com also has a new go-to-market model, Zinman explained. Customers expect “deeper implementation support” as they deploy AI, and the company will work more closely with customers, increase its on-site presence, create new roles, and “adapt many existing ones.” In its SEC filing, the company said it expects to continue hiring in “key strategic areas” throughout 2026.

Workers will be expected to work better, “not harder,” Zinman noted. He pointed to several past examples where work could have been done in a few days, but instead took many months with “multiple meetings and endless friction.”

“This wasn’t people’s fault and everyone was frustrated by this,” he said. “Our new org changes ownership to allow people to make decisions and move fast.”

A spokesperson for monday.com declined to comment further on the staff reductions.

Monday.com’s key market advantages

Monday.com certainly isn’t struggling; the company expects 19% to 20% year-over-year growth in 2026.

“Companies in that position do not restructure because they must,” Greyhound’s Gogia noted. “They restructure because they have decided to become something else.”

Melody Brue, VP and principal analyst at Moor Insights & Strategy, pointed out that organizational redesign is important for real AI transformation, but while it can signal confidence to the market, it can still be “devastating” to humans.

While the company looks as though it’s trying to do right, that ultimately remains to be seen, she said. “There are often hidden internal bruises that can surface long after layoffs.”

Monday.com’s advantage is in its “structured substrate,” Gogia noted; its boards, permissions and typed workflows give agents something firmer to act on than just documents and chat history. The company highlights its natively built agents that can be configured by any team member, as well as connectors with Claude, Microsoft Copilot, and ChatGPT, and dedicated routes for external agents to authenticate and operate.

“For some time, the sharper enterprise question has been shifting from who has an agent to who owns the governed runtime in which an agent can safely act,” he said. “Structured work is a serious claim on that runtime.”

But parts of monday.com’s agent estate remain in staged release, and its product is ultimately “mid-transition,” Gogia pointed out; its agent builder carried a beta label as recently as March,. Also, the company’s pricing model changed in May to a hybrid model charging for seats as well as mandatory AI credits. And, while its AI-powered no-code builder monday vibe passed $1 million in annual recurring revenue within two and a half months, monday.com has not released subsequent outcomes, usage volumes, or attach rates.

Further, there’s an element of “gravity” with its competitors, he observed. Asana is reorganizing teams around agents, Atlassian is wiring agents into the developer estate, and others are simply bundling them into their offerings: Microsoft is doing so across the productivity stack, and ServiceNow across enterprise operations, each with identity and procurement built in.

“Their pull is strongest exactly where monday.com wants to grow, in the largest accounts, where control-plane depth and administrative reach decide the deal,” said Gogia.

Actions for the near-term

Going forward, buyers should focus on operating risk, not headline risk, Moor’s Brue noted. In practice, that’s continuity of service, roadmap consistency, and strength of enterprise support. Productivity should be valued as better outcomes per unit of organizational effort, not mere activity.

“It should be a measure of how much smoother, faster, and more effective the operating model becomes when AI is built into the work,” said Brue.

Gogia noted that strain surfaces first in customer service, and monday.com’s attention is being redistributed. The company’s annual report disclosed that its focus is now concentrated on the largest accounts, with support for medium-sized clients moved to an AI-first and human-supported model.

During the first month of the transition, buyers should track named account continuity and escalation times, he advised. By the first quarter, keep an eye on whether credit governance and admin controls mature on schedule, and if the roadmap beyond the AI estate keeps pace. By the half-year mark, determine whether promised implementation depth is producing outcomes or “simply more billable engagement.”

Support tiers should be enumerated in writing before renewal, and buyers should contract for “side exits,” Gogia emphasized, with overage pricing fixed in advance, the right to pause consumption, and portability for workflows and agent configuration “if the relationship sours.” Finance should also insist on monthly consumption reporting by capability. Further, integration efforts, partner dependency, and change management should be considered first-class costs of the agent era, “not as afterthoughts to a license.”

“A license was a known cost,” said Gogia. “A meter is a behavior, and behavior is harder to forecast than headcount.”

This article originally appeared on CIO.com.