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.

Among a range of factors leading to a wave of tech sector layoffs in 2026 is the rapid rise of artificial intelligence and automation. Companies are reconfiguring their workforces to leverage AI for increased efficiency and reduced operating costs. This realignment and reduction is implemented even by companies reporting strong financial performance.

But it’s not just AI leading to workforce cuts. Complementing this technological shift are ongoing economic uncertainty, inflation, and higher interest rates, compounded by a chip shortage and rising energy costs. This mix is driving companies to cut costs and streamline operations for increased efficiency.

According to data compiled by Layoffs.fyi, an online tracker that keep tabs on job losses in the technology sector, 123,941 tech employees were laid off at 269 companies in 2025. The site also reports that 71,981 government employees were laid off by DOGE alone, with 182,528 total federal workers laid off.

Here is a list — to be updated regularly — of some of the most prominent technology layoffs the industry has experienced recently.

Notable tech layoffs in 2026

• Monday.com
• Microsoft
• Meta
• Cisco
• Cloudflare
• Oracle
• Atlassian
• Salesforce
• Amazon
• Ericsson

July 22, 2026: Monday.com cuts 20% of its workforce to restructure for the AI era

The company says the decision to cut 620 jobs isn’t about margins, but about creating a flatter organization built around AI agents, autonomous teams, and deeper customer engagement.

July 6, 2026: Microsoft cuts 4,800 jobs, primarily in sales and Xbox teams

As the company trims thousands of jobs, it’s also investing in embedded engineering teams and AI infrastructure. The layoffs come several weeks after the company offered 8,750 US employees voluntary retirement buyouts.

June 5, 2026: Tech industry cut 38,242 jobs in May, worst since 2024

AI was blamed for 40% of the job cuts in May, up from 7% in January, according to research by employment placement company Challenger, Gray & Christmas.

May 20, 2026: Meta cuts 8,000 jobs, around 10% of workforce

The cuts are expected to expected to hit Meta’s engineering and product teams the hardest, arriving as Meta pivots toward AI to boost efficiency across its organization, according to Yahoo Tech.

May 13, 2026: Cisco to cut nearly 4,000 jobs despite strong growth in AI, enterprise networking

Despite reporting positive financial news — including record third-quarter revenue of $15.8 billion, a 12% year-over-year increase — Cisco said it will eliminate almost 4,000 jobs.

May 7, 2026: Cloudflare to cut 1,100 jobs in AI-focused restructuring

About 20% of Cloudflare’s global workforce will be culled as the company pivots for the agentic AI era, Reuters reported.

April 1, 2026: Oracle to cut up to 30,000 jobs globally, putting enterprise support and roadmaps at risk

Oracle began laying off employees on March 31 in what could be the largest workforce reduction in the company’s history. Employees received termination emails at 6 a.m. local time with immediate system lockouts and no prior warning. (Note: in June, CNBC put the final layoff tally at 21,000.)

March 12, 2026: Atlassian cuts 1,600 jobs to fund AI and enterprise expansion

Atlassian will reduce its global workforce by approximately 10%, eliminating around 1,600 roles, as the collaboration software maker redirects capital toward artificial intelligence development and enterprise sales.

March 11, 2026: Tech layoffs surpass 45,000 in early 2026

A recent analysis by RationalFX found 45,363 job cuts globally so far this year—with roughly 68% or more than 30,000 occurring in the U.S. — highlighting ongoing workforce cuts even as many tech companies report strong revenue growth.

February 10, 2026: Salesforce lays off staffers as executive leadership churn continues

Salesforce has reduced close to 1,000 roles earlier this month across teams, including marketing, product management, data analytics, and its Agentforce AI unit, Business Insider reported, quoting employees familiar with the matter.

January 23, 2026: Amazon layoffs expected to disproportionately hit AWS and tech talent

As the market slows down, AWS and other Amazon units are preparing for another round of layoffs, which is expected to overwhelmingly impact tech talent. An email from HR leader Beth Galetti on Jan. 28 confirmed 16,000 job cuts.

January 15, 2026: Ericsson plans to shed 1,600 jobs in Sweden

 Ericsson lans to cut some 1,600 jobs in Sweden, the telecommunications equipment maker said doubling down on recent cost-saving measures that have helped it weather a prolonged downturn in telecoms spending, Reuters reports.

January 13, 2026: Meta plans to cut around 10% of employees in Reality Labs business

Meta plans to cut around 10% of the employees in its Reality Labs division who work on products including the metaverse, according to three people with knowledge of the discussions, according to The New York Times.

Layoffs in 2025

• Cisco
• Oracle
• Windsurf
• Intel
• Microsoft
• Crowdstrike
• HPE
• Autodesk
• HPE
• CISA
• Workday
• Salesforce
• Meta

Global tech-sector layoffs surpass 244,000 in 2025

Economic uncertainty, elevated interest rates, and AI adoption have driven workforce reductions across tech companies worldwide, according to a RationalFX report.

October 28, 2025: Amazon to cut 14,000 jobs across company

Amazon will reduce its overall workforce by 14,000, cutting layers of management across the company and hiring in some areas to support its “biggest bets”.

August 18, 2025: Cisco and Oracle to cut hundreds of Bay Area jobs

Tech companies Cisco and Oracle are cutting hundreds of jobs across the Bay Area. Cisco will eliminate 221 positions at its Milpitas and San Francisco offices, effective Oct. 13. Oracle is reducing 101 positions in Santa Clara on the same date 

August 5, 2025: 3 weeks after acquiring Windsurf, Cognition offers staff the exit door

Cognition, the AI coding startup that acquired rival company Windsurf three weeks ago, laid off 30 employees last week and is offering buyouts to the roughly 200 remaining employees on the team, reports The Information.

July 25, 2025, Intel to lay off 22% of workforce, CEO Tan signals ‘no more blank checks’

Intel will reduce its workforce to 75,000 employees by the end of 2025 as new CEO Lip-Bu Tan implements sweeping changes designed to transform the struggling chipmaker

July 8, 2025, Intel layoffs begin: Chipmaker is cutting many thousands of jobs

Intel has begun laying off employees across the company. CEO Lip-Bu Tan told workers back in April to expect major layoffs at Intel in the coming months as the chipmaker slashes costs and overhauls its organization after years of technical setbacks and falling sales.

July 2, 2025: Microsoft will cut 9,000 workers

Microsoft will lay off about 9,000 employees, a source familiar with the workforce cut told CNBC.  The cuts will reportedly affect less than 4% of Microsoft’s global workforce and will impact different teams, geographies and levels of experience. This is the latest in a string of cuts the tech giant has made this year.

June 17, 2025: Intel looks to factory layoffs to return to profitability

Intel will lay off up to 20% of its manufacturing sector employees starting in July, according to media reports, as the company looks for options as it seeks a return to profitability. The cuts reportedly will be made around the world, but some of the layoffs will be closer to home, according to a report in The Oregonian citing an internal company memo from Intel manufacturing Vice President Naga Chandrasekaran.

May 7, 2025: CrowdStrike to lay off 5% of staff

CrowdStrike announced a plan to cut about 500 roles, roughly 5% of its workforce, to streamline operations and reduce costs. The cybersecurity company will incur about $36 million to $53 million in charges related to the layoffs

March 6, 2025: HPE cuts 2,500 jobs, remains committed to Juniper buy

CEO Antonio Neri told Wall Street analysts that HPE would begin implementing a cost-cutting program involving layoffs of about 2,500 employees over the next 18 months. HPE employs about 61,000 people worldwide.

Feb. 27, 2025: Autodesk to lay off 9% of workforce

Software maker Autodesk is laying off 1,350 staff. With the rise of subscription and multi-year contracts billed annually, and self-service enablement, it finds it needs fewer sales staff, CEO Andrew Anagnost said in a message to employees. And with its cloud, platform, and AI products proving most profitable, it’s concentrating its staff and investments there.

Feb. 27, 2025: HP to lay off 2,000 more

As part of an ongoing restructuring, HP plans to lay off up to another 2,000 workers. In recent weeks, the company has tried — unsuccessfully — to do away with telephone support staff by forcing callers to wait for at least 15 minutes if they refuse to use self-service support resources online. The company swiftly backtracked, but wider job cuts are still on.

Feb. 21, 2025: CISA lays off 130

Government employees get laid off too: In this case, 130 workers at the US Cybersecurity and Infrastructure Security Agency are being shown the door as a result of a DOGE decision. Cybersecurity experts are concerned that the cuts will harm the international collaborations that CISA has fostered, quite apart from their concerns about the security of the DOGE layoff process itself.

Feb. 5, 2025: Workday lays off 1,750

As it moves to invest more in AI and international growth, Workday is laying off 8.5% of its workforce and disposing of unused office space. Some analysts fear the cutbacks will affect the company’s customer service — unless AI can pick up the slack.

Feb. 4, 2025: Salesforce lays off over 1,000

At the same time as it’s hiring sales staff for its new artificial intelligence products, Salesforce is laying off over 1,000 workers across the company, according to Bloomberg. As of June, 2024, the company had over 72,000 employees, according to its website. Salesforce did not comment on the report. In 2024 the company reportedly laid off around 1,000 staff too, in two waves: January and July.

Jan. 14, 2025: Meta will lay off 5% of workforce

Mark Zuckerberg told Meta employees he intended to “move out the low performers faster” in an internal memo reported by Bloomberg. The memo announced that the company will lay off 5% of its staff, or around 3,600 staff, beginning Feb. 10. The company had already reduced its headcount by 5% in 2024 through natural attrition, the memo said. Among those leaving the company will be staff previously responsible for fact checking of posts on its social media platforms in the US, as the company begins relying on its users to police content.

Tech layoffs in 2024

• Equinix
• AMD
• Freshworks
• Cisco
• General Motors
• Intel
• OpenText
• Microsoft
• AWS
• Dell

Nov. 26, 2024: Equinix to cut 3% of staff

Despite intense demand for its data center capacity, Equinix is planning to lay off 3% of its workforce, or around 400 employees. The announcement followed the appointment of Adaire Fox-Martin to replace Charles Meyers as CEO and the departures of two other senior executives, CIO Milind Wagle and CISO Michael Montoya.

Nov. 13, 2024: AMD to cut 4% of workforce

AMD will lay off around 1,000 employees as it pivots towards developing AI-focused chips, it said. The move came as a surprise to staff, as the company also reported strong quarterly earnings.

Nov. 7, 2024: Freshworks lays off 660

Enterprise software vendor Freshworks laid off around 660 staff, or around 13% of its headcount, despite reporting increased revenue and profits in its fourth fiscal quarter. The company described the layoffs as a realignment of its global workforce.

Sept. 17, 2024: Cisco lays off 6,000

After laying off around 4,200 staff in February, Cisco is at it again, laying off another 6,000 or around 7% of its workforce. Among the divisions affected were its threat intelligence unit, Talos Security.

Aug. 20, 2024: General Motors lays off 1,000 software staff

More than 1,000 software and services staff are on the way out at General Motors, signalling that it could be rethinking its digital transformation strategy. In an internal memo, the company said that it was moving resources to its highest-priority work and flattening hierarchies.

August 1, 2024: Intel removes 15,000 roles

Intel plans to cut its workforce by around 15% to reduce costs after a disastrous second quarter. Revenue for the three months to June 29 stagnated at around $12.8 billion, but net income fell 85% to $83 million, prompting CEO Pat Gelsinger to bring forward a company-wide meeting in order to announce that 15,000 staff would lose their jobs. “This is an incredibly hard day for Intel as we are making some of the most consequential changes in our company’s history,” Gelsinger wrote in an email to staff, continuing: “Our revenues have not grown as expected — and we’ve yet to fully benefit from powerful trends, like AI. Our costs are too high, our margins are too low. We need bolder actions to address both — particularly given our financial results and outlook for the second half of 2024, which is tougher than previously expected.”

July 4, 2024: OpenText to lay off 1,200

OpenText said it will lay off 1,200 staff, or about 1.7% of its workforce, in a bid to save around $100 million annually. It plans to hire new sales and engineering staff in other areas in 2025, it said.

June 4, 2024: Microsoft lays off staff in Azure division

Microsoft laid off staff in several teams supporting its cloud services, including Azure for Operations and Mission Engineering. The company didn’t say exactly how many staff were leaving.

April 4, 2024: Amazon downsizes AWS in a fresh cost-cutting round

Amazon announced hundreds of layoffs in the sales and marketing teams of its AWS cloud services division — and also in the technology development teams for its physical retail stores, as it stepped back from efforts to generalize the “Just Walk Out” technology built for its Amazon Fresh grocery stores.

April 1, 2024: Dell acknowledges 13,000 job cuts

Dell Technologies’ latest 10K filing with the US Securities and Exchange Commission disclosed that the company had laid off 13,000 employees over the course of the 2023 fiscal year; it characterized the layoffs and other reorganizational moves as cost-cutting measures. “These actions resulted in a reduction in our overall headcount,” the company said. A comparison to the previous year’s 10K filing, performed by The Register, found that Dell employed 133,000 people at that point, compared to 120,000 as of February 2024. Dell announced layoffs of 6,650 staffers on Feb. 6, but it is unclear whether those cuts were reflected in the numbers from this year’s 10K statement.

See news of earlier layoffs.

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.

When it comes to building an effective AI stack, context is king and power isn’t everything it’s cracked up to be.

“Smaller, smarter, safer — this is a bet our company has taken in how we deploy AI internally,” said Ricky Thakrar, head of sales and account management at Zoho, provider of a suite of popular cloud-based software solutions for sales, marketing, and finance.

“I’m on the business side, and so decisions made by our CIO and IT folks affect me directly, and my teams’ workflows and processes,” he added.

Speaking to a room of tech leaders at the CIO 100 Leadership Live New York event last week, Thakrar explained that every company wants the speed of AI-generated work wedded to the quality of human work, even though these two are diametrically opposed. No amount of model upgrades or spend will close that gap, so the only way forward is to architect your way out. Thakrar encapsulated this idea in a simple formula:

• Smaller: Stop deploying maximum firepower on every task. Many tasks don’t need it.
• Smarter: The system around the model decides more than the model does.
• Safer: Verify at the point a mistake gets locked in, not just downstream of it.

He noted that organizations that win with AI won’t be those deploying the biggest, most powerful models or the most sophisticated architecture, but the ones that figure out that the model is the easy part and the right architecture is harder. That means understanding the hardest element, and the biggest differentiator, is building a human system that learns and compounds alongside agentic systems.

To get it right, organizations need to prioritize the context layer. The size of frontier models like the GPT series, Claude, and Gemini mostly exist to compensate for missing context, Thakrar explained. Without enough context, models need to be able to reason harder and infer more about what a user actually means because it doesn’t know the user’s account, process, or history. A rich context layer makes it possible for enterprises to run workloads on much smaller, lower-power models.

“The intelligence moves from the model into the architecture around it,” he said.

A steep learning curve

One of Zoho’s earliest AI agents was a churn management agent to help the account management team detect churn in customer subscriptions. So when a subscription became inactive, the agent would collect context from notes, meeting recordings, and Zoho’s data enrichment tool, then create a summary of reasons the account might have churned, and schedule a call.

“What happened was I got this churn agent a couple months later, already embedded in our CRM, and within a week my team no longer trusted that agent,” Thakrar said. “The reason is we forgot to collect one very key point.”

In Zoho’s CRM, when a customer buys a bundle of products, that bundle is represented as a single line item. That means the status of any products the customer may have previously purchased individually changes to inactive as they’re moved to the bundle. That’s not churn, but it was interpreted it that way. Zoho fixed it in the second version of the agent.

Then a new problem arose. Many potential customers first purchase Zoho products as pilots or sandboxes. As those customers move from pilot to live instance, they close down the pilot versions. And again, the CRM would record that as subscriptions going inactive.

“The trust deteriorates again because everyone got excited for version 2,” Thakrar said.

Sometimes, a certain product might not be the best fit for a customer and Thakrar’s team will suggest the customer move to another product. That’s deliberate churn, not a churn risk.

“You may have a similar story like this where the agent sounds so good, it’s going to do something quick and add value, but it’s missing context from the account managers, and there are so many more pieces we’re still building out,” Thakrar said. “It’s been almost a year and the problem I have is my team still doesn’t trust it. They’ll see [a message from the agent] and go out and do all the research anyway to make sure it gave the correct answer.”

The team is more on top of potential churn, though, but the promised productivity gains have yet to materialize because the agent has to earn back lost trust due to a lack of context.

“My goal for this year is having an AI-assisted customer journey from sales to account management where the handoff is clean, the context flows, and every piece of information we gather about a customer is weighed, identified, and coached so the sales team can close more deals,” he said.

Zoho’s early experience with agents has led to the idea that constrained, context-rich, deterministic architectures consistently outperform expensive models bolted onto fragmented systems. It all comes down to three pillars: routing, harness, and specialization.

Routing

Routing is about sending workloads to the proper model for the job, which entails providing enough context to a given task that a small, cheap model can handle it without the need for spare reasoning capacity to fill gaps.

Frontier models are expensive and companies can burn through a year’s budget worth of tokens in months. But most tasks can be handled by much smaller, more constrained models at a fraction of the cost.

“You don’t always have to pay the frontier guys for every task,” he said. “We’ve observed with some clients that we could save them 95% with a 3 billion parameter model.”

Harness

An AI agent harness is the software infrastructure scaffolding around an LLM that differentiates an agent from a chatbot. It’s what enables an agent to act on tasks rather than simply respond to prompts. A model reasons through a problem and decides what to do about it. The harness connects the model to the tools, systems, memory, guardrails, and execution environments required to perform the actions determined by the model. The term is frequently used more or less interchangeably with orchestration layer.

“It’s the process around the model, which matters way more than the model itself,” Thakrar said.

In benchmark tests, a superior harness on a less powerful model produces better results than an inferior harness on a much bigger model.

For the best results, Thakrar said, it’s essential to understand the deterministic and non-deterministic elements of a given workload, and build that into the architecture. Machines can read, organize, and validate, and they excel at deterministic tasks. Humans, on the other hand, are exceptional at non-deterministic tasks like judging, synthesizing, and deciding.

Those non-deterministic tasks in a process are the ideal point for AI agents to incorporate a human in the loop, what Thakrar calls human harness. He pointed to a stakeholder mapping agent Zoho built for sales as an example, which takes the context of an initial meeting and third-party enriched data like a LinkedIn profile, weighs probabilities, and makes an educated guess about the stakeholder map.

“The initial goal was just to eliminate that task completely from the human workflow,” he said. “The stakeholder map is done, it’s in the folder, and you can look at it.”

But the agent would struggle to capture nuance. The meanings of titles in organizations always vary, and the politics and dynamics of any given meeting can be difficult for an AI agent to discern. Rather than keep feeding the agent data to try to make it intelligent enough to make those determinations, it was simpler and more efficient for the agent to create a proposed stakeholder map and hand it over to a human who could make changes and explain why those changes were necessary.

Ultimately, Thakrar said the agent still saved human team members time because the stakeholder map was usually pretty close, and the corrections also helped the model grow smarter by adding richer context.

Specialization

Specialization is transitioning a process from testing on a frontier model to production on a much narrower, smaller model. Once you’ve proven that an agent can do a job well, you want to stop paying master-craftsman rates to keep doing that one job well.

Specialization is all about capturing your subject matter experts’ best judgement and pattern recognition to build an open-weight, open source, trained, and fine-tuned model that can be deployed in your own data center.

“The true enterprise bet is to keep that orchestration layer, which is your IP and knowledge, in house,” Thakrar said. “You don’t want to host that on someone else’s model. The goal of everyone in enterprise should be to run, train, and host their own models.”

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.

Agentic AI has advanced from the promises-and-pilots phase of 2025 to reality and rollouts in 2026. In the process, agentic AI is transforming virtually every aspect of customer relationship management (CRM), the platform that manages sales, marketing, and customer service.

“Last year, everybody was dipping their toes into the water,” says Keith Kirkpatrick, research director at The Futurum Group. This year, agentic AI has built momentum from the boardroom down, with companies recognizing that having an AI strategy is imperative. “They feel like if they don’t embrace it now, their competitors will.”

Harry Datwani, a principal at Deloitte Digital, adds that enterprise CRM customers have transitioned from “proof of concept” to “scale and execution.”

“Across sales, service, marketing, even in the commerce space, enterprises are really using AI and agentic,” he says.

“CRM in 2026 is undergoing a structural shift, not just an incremental evolution,” says Forrester analyst Kate Leggett, noting that AI is becoming a core part of CRM infrastructure, not just a feature or an add-on. According to Forrester data, around 70% of companies are already using AI in their CRM systems, she says.

Here are the hot AI-driven trends in CRM this year.

CRM becomes an action hero

CRM platforms have traditionally served as passive, static systems of record. Now, agentic AI is transforming CRM into a powerful, real-time solution that can act autonomously.

“Organizations that rethink CRM as a real-time, AI-powered system of action — and embrace agentic AI to handle complex, unpredictable work — are better positioned to deliver exceptional customer experiences,” says IDC analyst Neil Ward-Dutton. “This approach not only enhances satisfaction and loyalty but also drives operational efficiency and business agility.”

Forrester’s Leggett says that AI-powered CRM platforms have advanced from simple data capture to real-time decision-making and execution. Standard capabilities include next-best action recommendations, call summaries, automated updates, generated emails, knowledge creation, predictive forecasting, and deal scoring.

She adds that AI agents can now execute workflows, such as routing cases, sending follow-ups, and updating records (with human oversight). They can also handle end-to-end service and sales tasks autonomously, including case resolutions and sales development activities.

Agentic drives workforce changes

AI use in CRM systems is also impacting workforce strategies.

“We used to hire for deep expertise,” says Constellation Research analyst Liz Miller. “AI has commoditized expertise because I can take all that data from my CRM and train my AI models to go deep, to know everything about any product I’ve ever sold, from what has worked, what hasn’t, every price, every sale.”

Now, instead of hiring candidates with deep expertise, organizations are looking for candidates who can go wide. “I can train a model to have deep expertise. What I can’t train for is experience, because experience is what happens when a person has gone broad across a lot of different scenarios and faced complexity across that broad scenario,” says Miller.

For example, AI systems can automate many aspects of marketing, Miller notes, but there’s no substitute for creativity: people who can interrogate the data and come up with innovative marketing campaigns that connect with customers.

Terence Chesire, group vice president of ServiceNow CRM and industry workflows, says that organizations are using agentic AI to free up team members from repetitive, lower-value activities. Those employees have now moved to higher-level roles “where they’re working on transformational deals rather than just building a spreadsheet.”

“That’s what we’re seeing as super-exciting as organizations not just free up people, but the speed and effort reduction and the friction reduction in what they can do,” he adds.

Data layer takes center stage

AI’s promise to deliver actionable customer and marketing intelligence has placed even greater emphasis on the importance on sound data management practices for CRM.

“The light bulb has flashed on very brightly for our clients,” says Deloitte’s Datwani. “Everyone is talking about AI agents, but your ability to really extract value is inextricably linked to the quality of your data and the ability to make that data accessible. What we’re finding is that despite large investments over time our clients still have fragmented data. And so, they are data rich and insight poor.”

The good news, says Datwani, is that AI agents themselves can help clean up and organize data. And vendors such as Snowflake and Databricks, along with the traditional CRM powerhouses, are offering powerful data analytics solutions. “Everyone is battling for that data layer,” Datwani says.

Forrester’s Leggett adds that CRM platforms are converging with customer data platforms (CDPs), real-time event streams, and external data sources to create connected customer data networks. These real-time, connected data models can help organizations deliver hyper-personalization at scale.

Agentic ushers in pricing complexity

The shift from license- or subscription-based pricing to an outcome or consumption pricing model has the potential to help CIOs tie their CRM costs to specific business metrics, such as the number of customer service calls resolved per hour. But it has also introduced a new level of complexity when it comes to budgeting for CRM costs.

For example, Chesire says ServiceNow’s CRM pricing plan starts with a baseline subscription model, and on top of that, customers get a certain number of AI tokens per user and can buy additional tokens as AI usage ramps up.

Meanwhile, Salesforce has rolled out pay-per-resolution pricing with its recently unveiled AI Help Agent and last month acquired usage-based billing specialist m3ter. Oracle is also piloting outcome-based AI pricing.

All these approaches undercut the predictability of the subscription model, which will complicate CIOs’ cost calculus, Deloitte’s Datwani says. “Now, as you start to think about consumption and tokens, costs might look different. As folks are opening up the architecture with things like headless CRM, what will the cost model look like for API calls or MCP server calls? So, there’s many more variables,” he adds.

The rise of multi-agent orchestration

To act autonomously, agents need to access multiple data sets and software platforms seamlessly. As a result, the proliferation of agents, some embedded within specific vendor platforms and some created in-house, is going to require an orchestration layer, Futurum’s Kirkpatrick says.

He points out that organizations need to monitor and manage agents, enforcing the same type of policy-based access control that exists for people. Organizations also need to set limits on what domains a specific agent can get into, what types of data they can access, what lines can’t they cross.

Kirkpatrick predicts that a new class of orchestration tools will emerge, although it’s not clear whether that orchestration layer will be provided by the leading CRM vendors, hyperscalers, or third parties.

Datwani agrees. “The orchestration layer is an interesting area, where the traditional vendors are in on it, the hyperscalers are also offering it, and there are third parties. It’s my belief that there’s not going to be a clear winner.”

The interface becomes conversational

Enterprise users who have traditionally had to manually wrangle with CRM systems are likely to find the ability to employ voice commands using a natural language interface to be a game changer. For starters, a salesperson can say, “I have a meeting today with Customer X. Help me prepare.” The agent will collect relevant data, ingest it, and provide a summary with recommendations.

ServiceNow’s Chesire says voice-enabled CRM systems have an “almost magical” ability to record, transcribe, and understand the content of a call between a salesperson and a customer or potential customer. The system can then “build a quote” based on that conversation.

On the customer service side of the equation, AI-driven voice technology enables customers to speak to an AI agent, describe the problem using natural language, and get a response. The agent has the capability to, for example, solve a credit card dispute, order a replacement product, send out a service rep, or do whatever is needed to resolve the issue, says Chesire.

Beyond that, agentic technology is capable of understanding the underlying business process flaws that led to the product snafu, and make recommendations for ways to fix whatever led to the issue in the first place, he adds.

Agentic drives business process transformation

With the emergence of outcome-based pricing, organizations are taking a fresh look at how they measure the benefits of CRM systems. That conversation is leading to an even more important analysis of underlying business processes. Or, as Constellation’s Miller says, “The old adage of applying new technology to old processes only gets you more expensive old processes.”

“When we survey customers, we hear time and time again that the reason why they want to apply AI into their organizations is to foster exponential opportunity and exponential growth,” she says. “How do we get there with CRM has started to become the new conversation.”

According to Miller, AI systems breach the walls of siloed data and can take a fresh look at legacy workflows. They also don’t get sucked into turf wars between marketing and sales teams. As a result, they often recommend new actions that can lead to better processes. “I think it’s starting to happen. You’re starting to see applications where AI is beginning to accelerate decision-making and decision velocity,” she says.

“The next phase of maturity is going to be, how do we start to spread AI across our platforms so that we are seeing that holistic end-to-end relationship that we have always wanted to optimize. How do we thread that across platforms and across solutions. We’re starting to see organizations on the leading edge really start to pull those strategies together,” says Miller.

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.

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.

Among a range of factors leading to a wave of tech sector layoffs in 2026 is the rapid rise of artificial intelligence and automation. Companies are reconfiguring their workforces to leverage AI for increased efficiency and reduced operating costs. This realignment and reduction is implemented even by companies reporting strong financial performance.

But it’s not just AI leading to workforce cuts. Complementing this technological shift are ongoing economic uncertainty, inflation, and higher interest rates, compounded by a chip shortage and rising energy costs. This mix is driving companies to cut costs and streamline operations for increased efficiency.

According to data compiled by Layoffs.fyi, an online tracker that keep tabs on job losses in the technology sector, 123,941 tech employees were laid off at 269 companies in 2025. The site also reports that 71,981 government employees were laid off by DOGE alone, with 182,528 total federal workers laid off.

Here is a list — to be updated regularly — of some of the most prominent technology layoffs the industry has experienced recently.

Notable tech layoffs in 2026

• Monday.com
• Microsoft
• Meta
• Cisco
• Cloudflare
• Oracle
• Atlassian
• Salesforce
• Amazon
• Ericsson

July 22, 2026: Monday.com cuts 20% of its workforce to restructure for the AI era

The company says the decision to cut 620 jobs isn’t about margins, but about creating a flatter organization built around AI agents, autonomous teams, and deeper customer engagement.

July 6, 2026: Microsoft cuts 4,800 jobs, primarily in sales and Xbox teams

As the company trims thousands of jobs, it’s also investing in embedded engineering teams and AI infrastructure. The layoffs come several weeks after the company offered 8,750 US employees voluntary retirement buyouts.

June 5, 2026: Tech industry cut 38,242 jobs in May, worst since 2024

AI was blamed for 40% of the job cuts in May, up from 7% in January, according to research by employment placement company Challenger, Gray & Christmas.

May 20, 2026: Meta cuts 8,000 jobs, around 10% of workforce

The cuts are expected to expected to hit Meta’s engineering and product teams the hardest, arriving as Meta pivots toward AI to boost efficiency across its organization, according to Yahoo Tech.

May 13, 2026: Cisco to cut nearly 4,000 jobs despite strong growth in AI, enterprise networking

Despite reporting positive financial news — including record third-quarter revenue of $15.8 billion, a 12% year-over-year increase — Cisco said it will eliminate almost 4,000 jobs.

May 7, 2026: Cloudflare to cut 1,100 jobs in AI-focused restructuring

About 20% of Cloudflare’s global workforce will be culled as the company pivots for the agentic AI era, Reuters reported.

April 1, 2026: Oracle to cut up to 30,000 jobs globally, putting enterprise support and roadmaps at risk

Oracle began laying off employees on March 31 in what could be the largest workforce reduction in the company’s history. Employees received termination emails at 6 a.m. local time with immediate system lockouts and no prior warning. (Note: in June, CNBC put the final layoff tally at 21,000.)

March 12, 2026: Atlassian cuts 1,600 jobs to fund AI and enterprise expansion

Atlassian will reduce its global workforce by approximately 10%, eliminating around 1,600 roles, as the collaboration software maker redirects capital toward artificial intelligence development and enterprise sales.

March 11, 2026: Tech layoffs surpass 45,000 in early 2026

A recent analysis by RationalFX found 45,363 job cuts globally so far this year—with roughly 68% or more than 30,000 occurring in the U.S. — highlighting ongoing workforce cuts even as many tech companies report strong revenue growth.

February 10, 2026: Salesforce lays off staffers as executive leadership churn continues

Salesforce has reduced close to 1,000 roles earlier this month across teams, including marketing, product management, data analytics, and its Agentforce AI unit, Business Insider reported, quoting employees familiar with the matter.

January 23, 2026: Amazon layoffs expected to disproportionately hit AWS and tech talent

As the market slows down, AWS and other Amazon units are preparing for another round of layoffs, which is expected to overwhelmingly impact tech talent. An email from HR leader Beth Galetti on Jan. 28 confirmed 16,000 job cuts.

January 15, 2026: Ericsson plans to shed 1,600 jobs in Sweden

 Ericsson lans to cut some 1,600 jobs in Sweden, the telecommunications equipment maker said doubling down on recent cost-saving measures that have helped it weather a prolonged downturn in telecoms spending, Reuters reports.

January 13, 2026: Meta plans to cut around 10% of employees in Reality Labs business

Meta plans to cut around 10% of the employees in its Reality Labs division who work on products including the metaverse, according to three people with knowledge of the discussions, according to The New York Times.

Layoffs in 2025

• Cisco
• Oracle
• Windsurf
• Intel
• Microsoft
• Crowdstrike
• HPE
• Autodesk
• HPE
• CISA
• Workday
• Salesforce
• Meta

Global tech-sector layoffs surpass 244,000 in 2025

Economic uncertainty, elevated interest rates, and AI adoption have driven workforce reductions across tech companies worldwide, according to a RationalFX report.

October 28, 2025: Amazon to cut 14,000 jobs across company

Amazon will reduce its overall workforce by 14,000, cutting layers of management across the company and hiring in some areas to support its “biggest bets”.

August 18, 2025: Cisco and Oracle to cut hundreds of Bay Area jobs

Tech companies Cisco and Oracle are cutting hundreds of jobs across the Bay Area. Cisco will eliminate 221 positions at its Milpitas and San Francisco offices, effective Oct. 13. Oracle is reducing 101 positions in Santa Clara on the same date 

August 5, 2025: 3 weeks after acquiring Windsurf, Cognition offers staff the exit door

Cognition, the AI coding startup that acquired rival company Windsurf three weeks ago, laid off 30 employees last week and is offering buyouts to the roughly 200 remaining employees on the team, reports The Information.

July 25, 2025, Intel to lay off 22% of workforce, CEO Tan signals ‘no more blank checks’

Intel will reduce its workforce to 75,000 employees by the end of 2025 as new CEO Lip-Bu Tan implements sweeping changes designed to transform the struggling chipmaker

July 8, 2025, Intel layoffs begin: Chipmaker is cutting many thousands of jobs

Intel has begun laying off employees across the company. CEO Lip-Bu Tan told workers back in April to expect major layoffs at Intel in the coming months as the chipmaker slashes costs and overhauls its organization after years of technical setbacks and falling sales.

July 2, 2025: Microsoft will cut 9,000 workers

Microsoft will lay off about 9,000 employees, a source familiar with the workforce cut told CNBC.  The cuts will reportedly affect less than 4% of Microsoft’s global workforce and will impact different teams, geographies and levels of experience. This is the latest in a string of cuts the tech giant has made this year.

June 17, 2025: Intel looks to factory layoffs to return to profitability

Intel will lay off up to 20% of its manufacturing sector employees starting in July, according to media reports, as the company looks for options as it seeks a return to profitability. The cuts reportedly will be made around the world, but some of the layoffs will be closer to home, according to a report in The Oregonian citing an internal company memo from Intel manufacturing Vice President Naga Chandrasekaran.

May 7, 2025: CrowdStrike to lay off 5% of staff

CrowdStrike announced a plan to cut about 500 roles, roughly 5% of its workforce, to streamline operations and reduce costs. The cybersecurity company will incur about $36 million to $53 million in charges related to the layoffs

March 6, 2025: HPE cuts 2,500 jobs, remains committed to Juniper buy

CEO Antonio Neri told Wall Street analysts that HPE would begin implementing a cost-cutting program involving layoffs of about 2,500 employees over the next 18 months. HPE employs about 61,000 people worldwide.

Feb. 27, 2025: Autodesk to lay off 9% of workforce

Software maker Autodesk is laying off 1,350 staff. With the rise of subscription and multi-year contracts billed annually, and self-service enablement, it finds it needs fewer sales staff, CEO Andrew Anagnost said in a message to employees. And with its cloud, platform, and AI products proving most profitable, it’s concentrating its staff and investments there.

Feb. 27, 2025: HP to lay off 2,000 more

As part of an ongoing restructuring, HP plans to lay off up to another 2,000 workers. In recent weeks, the company has tried — unsuccessfully — to do away with telephone support staff by forcing callers to wait for at least 15 minutes if they refuse to use self-service support resources online. The company swiftly backtracked, but wider job cuts are still on.

Feb. 21, 2025: CISA lays off 130

Government employees get laid off too: In this case, 130 workers at the US Cybersecurity and Infrastructure Security Agency are being shown the door as a result of a DOGE decision. Cybersecurity experts are concerned that the cuts will harm the international collaborations that CISA has fostered, quite apart from their concerns about the security of the DOGE layoff process itself.

Feb. 5, 2025: Workday lays off 1,750

As it moves to invest more in AI and international growth, Workday is laying off 8.5% of its workforce and disposing of unused office space. Some analysts fear the cutbacks will affect the company’s customer service — unless AI can pick up the slack.

Feb. 4, 2025: Salesforce lays off over 1,000

At the same time as it’s hiring sales staff for its new artificial intelligence products, Salesforce is laying off over 1,000 workers across the company, according to Bloomberg. As of June, 2024, the company had over 72,000 employees, according to its website. Salesforce did not comment on the report. In 2024 the company reportedly laid off around 1,000 staff too, in two waves: January and July.

Jan. 14, 2025: Meta will lay off 5% of workforce

Mark Zuckerberg told Meta employees he intended to “move out the low performers faster” in an internal memo reported by Bloomberg. The memo announced that the company will lay off 5% of its staff, or around 3,600 staff, beginning Feb. 10. The company had already reduced its headcount by 5% in 2024 through natural attrition, the memo said. Among those leaving the company will be staff previously responsible for fact checking of posts on its social media platforms in the US, as the company begins relying on its users to police content.

Tech layoffs in 2024

• Equinix
• AMD
• Freshworks
• Cisco
• General Motors
• Intel
• OpenText
• Microsoft
• AWS
• Dell

Nov. 26, 2024: Equinix to cut 3% of staff

Despite intense demand for its data center capacity, Equinix is planning to lay off 3% of its workforce, or around 400 employees. The announcement followed the appointment of Adaire Fox-Martin to replace Charles Meyers as CEO and the departures of two other senior executives, CIO Milind Wagle and CISO Michael Montoya.

Nov. 13, 2024: AMD to cut 4% of workforce

AMD will lay off around 1,000 employees as it pivots towards developing AI-focused chips, it said. The move came as a surprise to staff, as the company also reported strong quarterly earnings.

Nov. 7, 2024: Freshworks lays off 660

Enterprise software vendor Freshworks laid off around 660 staff, or around 13% of its headcount, despite reporting increased revenue and profits in its fourth fiscal quarter. The company described the layoffs as a realignment of its global workforce.

Sept. 17, 2024: Cisco lays off 6,000

After laying off around 4,200 staff in February, Cisco is at it again, laying off another 6,000 or around 7% of its workforce. Among the divisions affected were its threat intelligence unit, Talos Security.

Aug. 20, 2024: General Motors lays off 1,000 software staff

More than 1,000 software and services staff are on the way out at General Motors, signalling that it could be rethinking its digital transformation strategy. In an internal memo, the company said that it was moving resources to its highest-priority work and flattening hierarchies.

August 1, 2024: Intel removes 15,000 roles

Intel plans to cut its workforce by around 15% to reduce costs after a disastrous second quarter. Revenue for the three months to June 29 stagnated at around $12.8 billion, but net income fell 85% to $83 million, prompting CEO Pat Gelsinger to bring forward a company-wide meeting in order to announce that 15,000 staff would lose their jobs. “This is an incredibly hard day for Intel as we are making some of the most consequential changes in our company’s history,” Gelsinger wrote in an email to staff, continuing: “Our revenues have not grown as expected — and we’ve yet to fully benefit from powerful trends, like AI. Our costs are too high, our margins are too low. We need bolder actions to address both — particularly given our financial results and outlook for the second half of 2024, which is tougher than previously expected.”

July 4, 2024: OpenText to lay off 1,200

OpenText said it will lay off 1,200 staff, or about 1.7% of its workforce, in a bid to save around $100 million annually. It plans to hire new sales and engineering staff in other areas in 2025, it said.

June 4, 2024: Microsoft lays off staff in Azure division

Microsoft laid off staff in several teams supporting its cloud services, including Azure for Operations and Mission Engineering. The company didn’t say exactly how many staff were leaving.

April 4, 2024: Amazon downsizes AWS in a fresh cost-cutting round

Amazon announced hundreds of layoffs in the sales and marketing teams of its AWS cloud services division — and also in the technology development teams for its physical retail stores, as it stepped back from efforts to generalize the “Just Walk Out” technology built for its Amazon Fresh grocery stores.

April 1, 2024: Dell acknowledges 13,000 job cuts

Dell Technologies’ latest 10K filing with the US Securities and Exchange Commission disclosed that the company had laid off 13,000 employees over the course of the 2023 fiscal year; it characterized the layoffs and other reorganizational moves as cost-cutting measures. “These actions resulted in a reduction in our overall headcount,” the company said. A comparison to the previous year’s 10K filing, performed by The Register, found that Dell employed 133,000 people at that point, compared to 120,000 as of February 2024. Dell announced layoffs of 6,650 staffers on Feb. 6, but it is unclear whether those cuts were reflected in the numbers from this year’s 10K statement.

See news of earlier layoffs.

When it comes to building an effective AI stack, context is king and power isn’t everything it’s cracked up to be.

“Smaller, smarter, safer — this is a bet our company has taken in how we deploy AI internally,” said Ricky Thakrar, head of sales and account management at Zoho, provider of a suite of popular cloud-based software solutions for sales, marketing, and finance.

“I’m on the business side, and so decisions made by our CIO and IT folks affect me directly, and my teams’ workflows and processes,” he added.

Speaking to a room of tech leaders at the CIO 100 Leadership Live New York event last week, Thakrar explained that every company wants the speed of AI-generated work wedded to the quality of human work, even though these two are diametrically opposed. No amount of model upgrades or spend will close that gap, so the only way forward is to architect your way out. Thakrar encapsulated this idea in a simple formula:

• Smaller: Stop deploying maximum firepower on every task. Many tasks don’t need it.
• Smarter: The system around the model decides more than the model does.
• Safer: Verify at the point a mistake gets locked in, not just downstream of it.

He noted that organizations that win with AI won’t be those deploying the biggest, most powerful models or the most sophisticated architecture, but the ones that figure out that the model is the easy part and the right architecture is harder. That means understanding the hardest element, and the biggest differentiator, is building a human system that learns and compounds alongside agentic systems.

To get it right, organizations need to prioritize the context layer. The size of frontier models like the GPT series, Claude, and Gemini mostly exist to compensate for missing context, Thakrar explained. Without enough context, models need to be able to reason harder and infer more about what a user actually means because it doesn’t know the user’s account, process, or history. A rich context layer makes it possible for enterprises to run workloads on much smaller, lower-power models.

“The intelligence moves from the model into the architecture around it,” he said.

A steep learning curve

One of Zoho’s earliest AI agents was a churn management agent to help the account management team detect churn in customer subscriptions. So when a subscription became inactive, the agent would collect context from notes, meeting recordings, and Zoho’s data enrichment tool, then create a summary of reasons the account might have churned, and schedule a call.

“What happened was I got this churn agent a couple months later, already embedded in our CRM, and within a week my team no longer trusted that agent,” Thakrar said. “The reason is we forgot to collect one very key point.”

In Zoho’s CRM, when a customer buys a bundle of products, that bundle is represented as a single line item. That means the status of any products the customer may have previously purchased individually changes to inactive as they’re moved to the bundle. That’s not churn, but it was interpreted it that way. Zoho fixed it in the second version of the agent.

Then a new problem arose. Many potential customers first purchase Zoho products as pilots or sandboxes. As those customers move from pilot to live instance, they close down the pilot versions. And again, the CRM would record that as subscriptions going inactive.

“The trust deteriorates again because everyone got excited for version 2,” Thakrar said.

Sometimes, a certain product might not be the best fit for a customer and Thakrar’s team will suggest the customer move to another product. That’s deliberate churn, not a churn risk.

“You may have a similar story like this where the agent sounds so good, it’s going to do something quick and add value, but it’s missing context from the account managers, and there are so many more pieces we’re still building out,” Thakrar said. “It’s been almost a year and the problem I have is my team still doesn’t trust it. They’ll see [a message from the agent] and go out and do all the research anyway to make sure it gave the correct answer.”

The team is more on top of potential churn, though, but the promised productivity gains have yet to materialize because the agent has to earn back lost trust due to a lack of context.

“My goal for this year is having an AI-assisted customer journey from sales to account management where the handoff is clean, the context flows, and every piece of information we gather about a customer is weighed, identified, and coached so the sales team can close more deals,” he said.

Zoho’s early experience with agents has led to the idea that constrained, context-rich, deterministic architectures consistently outperform expensive models bolted onto fragmented systems. It all comes down to three pillars: routing, harness, and specialization.

Routing

Routing is about sending workloads to the proper model for the job, which entails providing enough context to a given task that a small, cheap model can handle it without the need for spare reasoning capacity to fill gaps.

Frontier models are expensive and companies can burn through a year’s budget worth of tokens in months. But most tasks can be handled by much smaller, more constrained models at a fraction of the cost.

“You don’t always have to pay the frontier guys for every task,” he said. “We’ve observed with some clients that we could save them 95% with a 3 billion parameter model.”

Harness

An AI agent harness is the software infrastructure scaffolding around an LLM that differentiates an agent from a chatbot. It’s what enables an agent to act on tasks rather than simply respond to prompts. A model reasons through a problem and decides what to do about it. The harness connects the model to the tools, systems, memory, guardrails, and execution environments required to perform the actions determined by the model. The term is frequently used more or less interchangeably with orchestration layer.

“It’s the process around the model, which matters way more than the model itself,” Thakrar said.

In benchmark tests, a superior harness on a less powerful model produces better results than an inferior harness on a much bigger model.

For the best results, Thakrar said, it’s essential to understand the deterministic and non-deterministic elements of a given workload, and build that into the architecture. Machines can read, organize, and validate, and they excel at deterministic tasks. Humans, on the other hand, are exceptional at non-deterministic tasks like judging, synthesizing, and deciding.

Those non-deterministic tasks in a process are the ideal point for AI agents to incorporate a human in the loop, what Thakrar calls human harness. He pointed to a stakeholder mapping agent Zoho built for sales as an example, which takes the context of an initial meeting and third-party enriched data like a LinkedIn profile, weighs probabilities, and makes an educated guess about the stakeholder map.

“The initial goal was just to eliminate that task completely from the human workflow,” he said. “The stakeholder map is done, it’s in the folder, and you can look at it.”

But the agent would struggle to capture nuance. The meanings of titles in organizations always vary, and the politics and dynamics of any given meeting can be difficult for an AI agent to discern. Rather than keep feeding the agent data to try to make it intelligent enough to make those determinations, it was simpler and more efficient for the agent to create a proposed stakeholder map and hand it over to a human who could make changes and explain why those changes were necessary.

Ultimately, Thakrar said the agent still saved human team members time because the stakeholder map was usually pretty close, and the corrections also helped the model grow smarter by adding richer context.

Specialization

Specialization is transitioning a process from testing on a frontier model to production on a much narrower, smaller model. Once you’ve proven that an agent can do a job well, you want to stop paying master-craftsman rates to keep doing that one job well.

Specialization is all about capturing your subject matter experts’ best judgement and pattern recognition to build an open-weight, open source, trained, and fine-tuned model that can be deployed in your own data center.

“The true enterprise bet is to keep that orchestration layer, which is your IP and knowledge, in house,” Thakrar said. “You don’t want to host that on someone else’s model. The goal of everyone in enterprise should be to run, train, and host their own models.”

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.

Outsourcing worked – until it didn’t.

After Akirolabs achieved early market validation and onboarded its first enterprise customers, outsourcing began to create strategic limitations around scalability, intellectual property (IP) ownership, security and delivery execution.

The challenges started after the first enterprise customers confirmed product-market fit. At that point, delivery speed became directly tied to business growth. Product quality expectations increased. Infrastructure and security requirements became stricter. Investors started asking difficult but fair questions about IP ownership, operational dependencies and long-term scalability.

Most importantly, engineering execution was no longer just an operational function – it became part of the company’s strategic advantage. That was the moment when the founders decided the company needed dedicated technology leadership to address these challenges. This is how I joined the company at the beginning of 2023. As VP of Engineering and a bit later as CTO, I led the transformation (usually known as insourcing, repatriating or backsourcing) from an outsourced model to an internal engineering organization while maintaining product delivery continuity and preparing the company for the next growth stage. The process took roughly a year and involved not only technical migration, but also organizational design, hiring, process development, infrastructure modernization and cultural transformation – everything from the ground up.

Building an internal engineering organization while still delivering

One of the biggest misconceptions about insourcing is that it is primarily a technical project. It is a leadership and execution challenge.

When I joined the company, there was effectively no internal engineering structure, limited visibility into the existing system and no clear long-term technical strategy. My first months were dedicated to understanding reality and I began with a comprehensive assessment of the codebase, operational risks, documentation quality and knowledge dependencies to determine the most viable transition strategy.

Very early in the process, I faced a critical strategic decision: whether to gradually assume ownership of the existing platform or rebuild it internally. To make that decision, I evaluated four distinct transition models ranging from limited management insourcing to a complete internal rebuild.

After assessing the technical, operational and long-term business implications of each approach, I selected the most demanding option: rebuilding the product internally while maintaining uninterrupted delivery for existing customers. Although riskier in the short term, a full rebuild offered the clearest route to complete IP ownership, architectural flexibility and long-term scalability.

At the time, this decision ran counter to the approach typically taken by startups in similar situations. Most organizations gradually assume ownership of an existing codebase to minimize short-term risk and preserve delivery capacity. My assessment was that the accumulated architectural debt, fragmented knowledge distribution and long-term maintenance risks would ultimately make a phased takeover more expensive and less scalable than a controlled rebuild. The strategy required significantly higher execution discipline, but it allowed us to establish complete ownership of the platform, eliminate inherited constraints and create an architecture capable of supporting enterprise-scale growth.

The next challenge was hiring.

In Germany, hiring can easily take four to six months – mostly due to a typical 3-month notice period, which is incompatible with startup timelines. We solved this by building a hybrid organization structure early: a lean internal core team combined with carefully selected contractors. Instead of hiring only narrow specialists, we prioritized experienced generalists capable of operating across architecture, infrastructure, security and compliance discussions. Later, we evolved toward a product engineering model, where engineers owned broader product outcomes rather than narrowly defined technical functions.

During the first three months, we established a core engineering team of four senior engineers. Over the following nine months, the organization expanded to roughly fifteen engineers while I strategically designed and executed the transformation of the platform’s architecture to meet the rigorous deployment and compliance standards of our first enterprise clients, including Raiffeisen Bank International and Bertelsmann. This structural overhaul allowed the company to meet the deployment, security and compliance requirements of enterprise customers that had previously been inaccessible under the outsourced model. At that point, we had already achieved complete coverage across backend, frontend, DevOps, QA and security.

I also intentionally kept processes lightweight during the transition. Instead of introducing heavyweight frameworks, we focused on clarity of priorities, fast decision-making and execution discipline. We used Kanban over Scrum, eliminated unnecessary meetings, shortened the remaining ones and emphasized engineering culture over process overhead.

Another major challenge was project estimation. Because dual-track development was unavoidable until the in-house platform reached production readiness, estimation accuracy had a direct impact on budget efficiency. Despite all challenges, my initial estimate ultimately proved remarkably close to the final delivery date, differing by only about a week. Accurate forecasting under conditions of parallel development streams, ongoing customer commitments and active team formation became a critical leadership challenge. Maintaining this level of predictability throughout the transition helped align engineering execution with business planning, hiring decisions and investor expectations.

The engineering transformation enabled capabilities that contributed to Akirolabs being recognized as an IDC Innovator in Procurement in 2023, named amongst the Top 27 AI Startups in Germany in 2024, Sifted’s 100 Fastest-Growing Startups in DACH & CEE 2025 and inclusion in 2024-2026 in ProcureTech100 annual recognition of procurement technology providers shaping the future of digital procurement.

Managing risk without slowing down the business

The hardest part of insourcing is not writing code, selecting the technology stack, designing architecture or configuring infrastructure. It is avoiding disruption while the company is changing underneath the product. I successfully orchestrated the concurrent overhaul of product architecture, cross-functional engineering recruitment, infrastructure modernization and live customer operations under exceptionally tight margins.

To reduce delivery risk, we approached the transition in layers.

First, we focused on infrastructure reliability and operational readiness before feature expansion. Cloud architecture, recovery testing, permission segregation and incident management processes were implemented early, not after launch. We also introduced multiple testing stages and dedicated QA functions after learning the hard way that a “developers-only” quality control approach does not scale for complex web platforms and business domains.

Second, we established a structured knowledge-transfer process to rapidly onboard engineers and reduce external dependencies.

Third, we became extremely disciplined about scope management. One of the most common reasons insourcing initiatives fail is uncontrolled change during the rebuild phase. Every new feature request increases uncertainty non-linearly. We learned to separate strategic improvements from distractions and protect the core delivery roadmap aggressively. Throughout the transition, we successfully maintained uninterrupted customer operations by utilizing planned maintenance windows, achieved a near-zero-downtime migration and permanently doubled product velocity immediately following the migration.

Beyond the technical migration itself, the transition established a repeatable operating model for scaling technology organizations beyond the product-market-fit stage. The framework combined organizational redesign, controlled knowledge repatriation, architecture modernization and enterprise-grade operational practices while maintaining uninterrupted customer delivery throughout the transformation. While the implementation was specific to Akirolabs, the underlying principles are broadly applicable to organizations seeking to transition from outsourced development to internal product ownership without disrupting business operations.

By the time the new platform reached production readiness, I had established not only a functioning engineering organization, but also a stable operational model: internal ownership, production-grade infrastructure, security processes, scalable hiring practices and clear technology and product roadmaps.

A positive side effect of the transition was the creation of internal UI/UX and Data Science capabilities, which later became strategically important for AI product initiatives and created a foundation for the third version of the product, which we released in mid-2025.

My technical restructuring and migration to a secure proprietary platform reduced architectural risk, established full in-house ownership and helped strengthen investor confidence during the company’s successful €5M fundraising round in 2024.

The transition created a stronger foundation for scale and supported the company’s continued expansion among enterprise organizations operating at Fortune 500 scale, including Ahold Delhaize, Workday, IFF, Deutsche Bahn and others.

Lessons learned for CTOs considering insourcing

Looking back, several decisions made the transition successful, and several mistakes made it harder than necessary.

The first lesson is simple: decisiveness in strategic transition is paramount to maintaining business momentum. Rapidly evaluating insourcing frameworks and defining clear boundaries with the external partner allowed us to mitigate operational downtime and execute a highly efficient migration ahead of critical market deadlines.

Second, hire more senior people and do it as early as possible. Strong technical leaders multiply execution capacity far beyond their individual contribution. In our case, the quality of the first hires influenced architecture quality, hiring standards, delivery discipline and engineering culture for the entire organization.

Finally, culture matters more than frameworks. Processes can be added later. Ownership mentality cannot.

The biggest long-term advantage of bringing development in-house was not simply faster execution, not better code quality or operational cost optimization by over 30% after the transition which we also achieved. It was an alignment. Product strategy, engineering decisions, customer priorities and business goals became part of the same conversation instead of being separated by organizational boundaries. For technology companies operating in highly competitive markets, that alignment becomes a compounding advantage over time.

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

A client called me last week with a problem I have been hearing about more often lately. They had made significant reserved instance commitments with a major cloud provider, overbuying for what they thought would be heavy AI training workloads. Now they were sitting on thousands of dollars in idle capacity every month. Their plan was simple: resell it to someone else. Except they couldn’t.

I have been doing cloud consulting for a long time, and this situation once had a straightforward solution. You went to the marketplace, listed your unused reservations, and found a buyer. The process was a bit clunky, but it worked. These days, the answer is far more complicated, and my client learned this the hard way.

AI has made this problem increasingly common. Companies initially committed to compute capacity based on ambitious training plans. Prototype projects were expected to scale, and inference workloads were projected to grow substantially. Then reality hit. Some projects did not materialize. Some models trained faster than expected. Some inference patterns were lighter than anticipated.

Many organizations now hold reserved capacity they can’t use, discard, or share without a complex, increasingly restricted process. This reality is something every company with significant cloud spend needs to clearly understand.

The history of cloud resale

There was once a functioning resale market for cloud reserved instances. AWS, for example, maintained a Reserved Instances Marketplace where companies that had purchased reserved capacity could sell those reservations to other AWS customers. This was a legitimate, AWS-sanctioned process. Companies would register as sellers, list their unused reservations with pricing and terms, and if a buyer appeared, the marketplace would facilitate the transaction.

The resale market was useful for companies that had overestimated their needs or whose business changes reduced their cloud consumption. Instead of simply absorbing the cost of unused commitments, they could recoup some of that investment by selling to other organizations with unmet demand. It created a secondary market that added liquidity to what was otherwise a rigid financial arrangement.

My client had some experience with this resale market a few years ago and assumed they could use it again. They were unpleasantly surprised to learn that the rules had changed.

AWS changes the rules

In January 2024, AWS implemented a significant policy change that effectively shut down the resale of EC2 Reserved Instances on its platform. AWS stopped allowing companies to resell their unused reserved capacity through the Reserved Instance Marketplace or any other official channel. If you have a reserved instance commitment with AWS, you are essentially stuck with it unless you can use it yourself or modify your reservation.

This change had a real impact on companies that had relied on resale as part of their cloud financial management strategy. It reduced flexibility and increased the risk of long-term reserved commitments. When I explained this AWS policy change to my client’s representatives, I could hear the frustration in their voices. They had made their commitment in good faith, carefully modeled their expected AI workloads, and now faced the reality that there was no easy exit.

The reasoning behind this change is not entirely clear, but AWS likely viewed capacity resales as something that complicated their billing and commitment models without providing enough benefit to the overall ecosystem. Regardless of the company’s reasons, the primary resale path for the largest cloud provider has been effectively closed.

What options still exist?

What can companies do now when they find themselves with reserved capacity they no longer need? The first possibility is to work directly with the cloud provider to modify or exchange the reservation if it is convertible. Some reservation types allow modifications, such as changing the instance type, region, or tenancy. This will not eliminate the commitment, but it may help companies better align their reservations with actual workload needs.

The second option is to use third-party brokers and marketplaces that operate independently of the cloud providers. Although AWS has shut down its official resale channel, brokers and marketplaces still facilitate resale arrangements for other cloud providers and for some AWS scenarios. These arrangements can be more complex and carry more risk, but they remain a possibility for companies determined to move unused capacity.

The third alternative is to optimize usage. Companies can invest in better utilization monitoring, workload placement, and automation to ensure that reserved capacity is used as efficiently as possible. This does not recover the money already spent, but it reduces future waste.

My client explored all three alternatives and found that each had significant limitations. Modifications were possible, but only within a narrow range. Third-party brokers were interested, but the process was opaque and uncertain. Optimization helped, but it could not eliminate the fundamental overcommitment they had already made.

The broader implications

Cloud commitments are more rigid than many enterprises initially realize because they lack a liquid market and because providers control modifications, transfers, or cancellations. Right now, I see this pattern most often in the AI space. Companies commit to massive amounts of compute for training and inference based on projections that rarely reflect the actual workloads. Then they are surprised to find themselves locked into payments. The AI boom has led to significant overcommitment because enterprises remain unaware that the resale mechanisms that once existed have been largely shut down.

This is why cloud financial management has become such an important discipline. Companies need to be far more thoughtful about how they commit to cloud resources, how they model their future consumption, and how they build flexibility into their cloud strategies. The days of assuming you can always resell your way out of an overcommitment are effectively over, at least with AWS.

For Azure and Google Cloud, the resale landscape is slightly different, but the same general principles apply. These providers have their own capacity transfer policies and, like AWS, those policies can change at any time. Companies should understand their options before making large, committed purchases and build contingency plans in case their actual usage diverges from their projections—or if resale policies change.

The bottom line is that reselling unused reserved cloud instances is far more complicated than it sounds. The market is not as open as it once was, the options are limited, and the providers themselves hold most of the cards. My client got burned, and I doubt they will be the only one. Companies that want to optimize their cloud spending should focus on accurate forecasting, thoughtful commitment sizing, and ongoing optimization rather than relying on resale as a safety valve. That approach worked at one point, but those days are largely gone.

HireQuotient, an AI-native recruiting platform, today announced its integration with Paylocity (Nasdaq: PCTY), bringing AI-powered candidate sourcing and screening capabilities to Paylocity customers in manufacturing, building services, construction, healthcare and insurance, which are industries where deskless and frontline hiring has historically been underserved by AI recruiting tools.

Employers in these sectors who already use HireQuotient are seeing the impact firsthand.

“By simply putting in vetting criteria, I was able to get a very specific talent pool within a day,” said Niki Simoneaux, COO of Arc Health. “With EasySource, we can reach a huge database or filter for specific licenses and areas.”

“With technology and the ability to work remotely, we’re able to recruit nationwide outside of our footprint. This expands the pool of prospective candidates and gives us access to candidates who might not have ever applied for a position on our website’s career page,” said Jeff McGee, vice president at W3 Insurance.

“HireQuotient’s AI-native product helped my team at Alliance Building Services to cut down time to close position by more than 60%, and their team works very closely with the client to ensure adoption at scale,” said Willow Marcon, senior vice president at Alliance Building Services.

Recruiters in manufacturing, building services, construction, healthcare and insurance often spend more than two-thirds of their time on manual work and using over 10 platforms to just close a hire: sourcing a wide range of profiles, skimming resumes, finding contact information, reaching out and doing hundreds of calls and constant follow-ups. That fragmented process leads to recruiter burnout and leaves gaps in candidate data. Because most HR platforms don’t offer built-in AI native agents that work in tandem to do all it takes to close the hire, employers in these industries have faced hiring delays and platform churn.

The partnership addresses this gap by integrating HireQuotient’s EasySource platform directly into the Paylocity ecosystem. Instead of relying on rigid keyword searches, EasySource identifies strong talent pools, screens for role-specific credentials and licenses and personalizes outreach by phone and email. For mid-market companies with 500 to 1,000 employees, that translates to a 70% faster time-to-hire and an estimated $100,000 in annual savings.

The integration also closes the feedback loop for employers. By feeding post-hire data back into the recruiting system, EasySource learns from successful hires to build smarter talent pools over time, while keeping recruiters engaged longer by freeing them to focus on the human side of hiring.

Gokul Rajaram, board member at Coinbase and former board member of The Trade Desk (Nasdaq: TTD), and also known as the godfather of Google AdSense, said, “Smarthveer is one of those rare founders who picks an unglamorous, deeply underserved market and refuses to leave until it’s fixed. Frontline hiring is exactly that market. Being named to Paylocity’s elite partner network is a testament to his relentlessness and to the team he’s built. Excited for what’s ahead.”

“Paylocity maintains an elite partner network, so being named one of them is a testament to the strength of our product,” said Smarthveer Sidana, founder and CEO of HireQuotient. “By keeping that recruiting activity inside the Paylocity ecosystem, we’re helping them close a critical gap for their employers, capture revenue that previously sat outside their platform, and prevent the client churn that comes with a fragmented hiring process.”

Jim Moffatt, former global CEO of Deloitte Consulting and board partner at Greycroft VC, said, 

“This is a big milestone for Smarthveer and his team. I congratulate them on this big win. Paylocity’s large client base acts as a strong distribution, and HireQuotient’s EasySource acts as a strong product to cater to the needs of Paylocity’s clients. Paylocity is known for its highly selective approach, and I’m glad to see that after months of evaluation and extensive due diligence, they’re going live with HireQuotient’s EasySource. I feel confident in the value this partnership will create for frontline industries. I remember when Smarthveer spoke to me about it in December, and it felt very ambitious. I’m glad to see it turn to reality.”

For employers with a traditionally deskless workforce in industries where AI adoption has lagged, the integration bridges a major capability gap by allowing them to source, screen, onboard and manage payroll all in one place.

For more information, visit www.hirequotient.com.

A media kit with additional partner quotes, executive headshots and logos can be found here.

About HireQuotient

HireQuotient is an AI-native recruiting platform that automates candidate sourcing and screening for employers in manufacturing, building services, construction, healthcare, insurance and other frontline-heavy industries. Its flagship platform, EasySource, is one of a select number of recruiting technologies integrated with Paylocity’s HR and payroll ecosystem. Founded by Smarthveer Sidana, HireQuotient is headquartered in San Francisco. For more information, visit https://www.hirequotient.com/.

Media Contact

Bethany Rhodes

Uproar by Moburst for HireQuotient

bethany@moburst.com

Contact

Bethany Rhodes

bethany@moburst.com

Military strategists know that asymmetric wars are lost not at the point of attack but at the seams between defensive units, where no single commander owns the territory and information moves slower than the threat. In January 2024, a finance employee at Arup’s Hong Kong office learned this lesson for $25 million, joining a video call with what appeared to be the engineering firm’s chief financial officer and several colleagues, receiving instructions to wire funds to a designated account, and complying. Every face on the screen was a deepfake, cloned from publicly available footage of the actual executives. The attackers conducted the entire meeting in real time and vanished before anyone in the organization realized the CFO had never logged on.

The incident would be remarkable enough as a one-off, but it represents a pattern accelerating well beyond isolated cases. Global payment fraud reached $33.4 billion in 2024 according to the Nilson Report, and the US absorbed a disproportionate 42% of those losses despite processing only 25% of global card transactions. The latest FBI Internet Crime report identifies more than one million complaints and nearly $21 billion in cyber-enabled crime losses in 2025 (up from $16 million in 2023), while Deloitte projects AI-enabled fraud in the US will hit $40 billion by 2027. This increasingly includes crypto-related fraud, not just credit card or traditional banking fraud.

For anyone who oversees financial operations, risk or payment technology infrastructure, these numbers are not forecasts of a future “regional conflict.” Instead, they are the current cost of a war most institutions have not yet recognized they are fighting.

Reconnaissance at scale: How AI redraws the attacker’s map

The conventional narrative around AI-powered fraud emphasizes speed: Faster phishing, faster credential stuffing, faster social engineering. Jason Kikta, CTO of Automox, sees the shift differently. “The main threat from AI misuse isn’t faster execution, as automation has been leveraged for years,” Kikta says. “The true dangers are lower barriers to entry and faster adaptation, giving attackers the ability to pivot techniques in near real-time.”

The distinction means that execution is a quantitative improvement, the kind existing defenses can absorb by scaling up. Lower barriers to entry and real-time adaptation are qualitative: A force multiplier that turns every amateur into an equipped operator with a coach that learns from each failed attempt. Deepfake-as-a-service platforms now produce voice clones from three seconds of audio. AI-driven vulnerability scanning maps an institution’s unpatched endpoints while the security team is still scheduling the review meeting. In 2024, 269 million stolen credit card records appeared on dark web platforms, giving AI-equipped attackers what military intelligence analysts would call an order of battle: A detailed map of the defender’s exposed positions, ready to be mined for patterns, tested against live systems and exploited at machine speed.

The result is a combined arms threat, one that operates across domains simultaneously the way a competent military force coordinates air, ground and intelligence rather than running them as independent campaigns. The same AI that crafts a convincing business email compromise can probe unpatched point-of-sale systems to install digital skimmers. The same synthetic identity that opens a fraudulent credit card account can exploit a payment authorization vulnerability discovered through automated scanning. Card-not-present fraud now accounts for 71% of all US card fraud losses, and the attack surface keeps expanding as digital wallets and e-commerce push more transactions into channels where physical card verification is impossible.

Attackers treat endpoint management gaps and transaction monitoring gaps as a single attack surface, while most defenders continue to patrol them as separate territories.

Fragmented command: The structural vulnerability AI exploits

Consider how most financial institutions, crypto platforms and digital asset intermediaries actually organize their defenses: A cybersecurity team focused on identity compromise, endpoint protection and infrastructure threats; a fraud team focused on account takeover, mule networks and scam typologies; an AML or financial crimes team focused on wallet screening, sanctions exposure and suspicious activity reporting; and an AI risk or digital trust team, if one exists at all, focused on synthetic media, model abuse and impersonation. Each function has its own tooling, budget, reporting line and intelligence feeds. In crypto markets, where value can move irreversibly across wallets, chains, mixers, exchanges and OTC brokers in minutes, those silos create exploitable gaps between detection, attribution, interdiction and recovery.

A pig-butchering scam that begins on a dating app, migrates to WhatsApp, directs a victim to a fake crypto investment platform, and then launders proceeds through nested services and cross-chain bridges is not just a fraud event. It is also a cybersecurity event, a financial crimes event, an identity event, a platform abuse event and, increasingly, an AI-enabled social engineering event. Chainalysis reported that high-yield investment scams and pig-butchering schemes were among the most successful crypto scam types in 2024, while also noting growing use of AI in fraud and scams.

Research published by the University of California, Davis found that these schemes follow a staged lifecycle: Trust-building, fabricated investment returns, escalating deposits, withdrawal obstruction and re-targeting of victims after the initial loss. When each part of that lifecycle is monitored by a different team, the institution sees fragments of the attack rather than the economic system of the crime.

“Fraud no longer happens in isolated channels,” observes Jeff Li, Global Product & Designer Lead at Binance. “AI-powered scams move seamlessly across platforms, and payment systems, making fragmented defenses increasingly ineffective.” He believes that the future of security depends on unified intelligence — combining AI, real-time monitoring, secure infrastructure and cross-functional response mechanisms into a single coordinated defense system.

“We’ve invested heavily in AI-driven risk detection, real-time scam warnings and infrastructure to stay ahead of evolving threats, continues Li, claiming that from Q1 2025 to Q1 2026, these efforts helped Binance prevent over $10 billion in potential user losses and protected more than 5 million users globally. As AI continues to reshape both fraud and fraud prevention, the focus remains on building systems that can protect users, not just at scale, but in real time.

Unified command: From org chart to battle plan

Kikta’s assessment contains a contrarian detail worth teasing apart: “The good news is that a strong compliance program prioritizing depth of coverage and speed of enforcement will hold up against AI-enabled fraud,” he says. In a landscape saturated with predictions that existing defenses are obsolete, Kikta argues that the fundamentals of patch management, endpoint hygiene and compliance rigor still hold, provided the clock speed at which those fundamentals execute keeps pace with the adversary.

That clock speed is the operational link between cybersecurity and card fraud prevention. An unpatched point-of-sale terminal or payment gateway exposed for 30 days represents 30 days of reconnaissance opportunity for an AI scanner probing for places to install a digital skimmer or intercept card data in transit. A compliance gap in identity verification is an open invitation for synthetic identities to open accounts and run fraudulent transactions. Endpoint management data and transaction monitoring data describe the same attack surface from different angles, and fusing those streams into a single operational picture, the financial equivalent of a military intelligence fusion center, gives defenders something the current siloed structure cannot: Visibility into an attack developing across domains before it reaches the payment layer.

The value of that convergence extends beyond defense. A unified data layer across cyber, fraud and payments creates consolidated threat intelligence that can inform underwriting decisions, merchant risk scoring and product design. Organizations that treat converged security data as a business intelligence asset (not merely an operational feed) will find they have built something with commercial utility well beyond the security operations center.

Mascaro frames the prescription in terms that belong in a boardroom, not a SOC. “The real competitive advantage in fraud isn’t your AI stack,” he says. “It’s leadership’s clarity to unify risk disciplines that everyone else keeps in separate departments.”

Field manual: What winning institutions do differently

The institutions gaining ground in this new form of asymmetric conflict share a common operational posture: They treat endpoint management as card fraud prevention rather than IT maintenance, and they feed cyber, fraud and payments intelligence into a single picture rather than three separate briefings. The defensive AI advantage, such as it is, comes from that integration, not from any single model’s sophistication.

Adversaries have already unified their operations. Yet, payment processors and financial institutions that keep running separate campaigns on separate fronts, with separate intelligence, will keep conducting after-action reviews of battles they have already lost.

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

When a goal goes in during a tournament quarter-final and a hundred million people watch it at the same time, what they feel is the goal. The roar, the replay, the disbelief.

They do not feel the contribution feeds traversing private media networks across continents, or the edge nodes absorbing a traffic spike that appeared without warning.

They just feel the moment.

And that’s exactly how it’s supposed to work.

And as live sports viewership pushes into territory that makes previous records look modest (driven by a generation that expects to watch anything, on any device, anywhere, without waiting), the gap between getting that delivery right and getting it wrong has never been more consequential, or more public.

As audiences moved to digital platforms, the margin for error disappeared.

There is a version of this conversation that is easy to have: audiences expect more, technology has to keep up. True, but incomplete.

Audiences have always expected live sport to work. What changed is what “working” means, and how quickly they find out when it doesn’t.

Viewers no longer sit in front of a single screen. During a FIFA World Cup match, a household might have the main feed on the living room television, while someone else streams the highlights on a second TV in the bedroom, all while phones flash with live stats and tablets run separate commentary. From the infrastructure’s perspective, that isn’t just one household watching a game; it’s a chaotic web of concurrent demands triggered by the exact same split-second on the pitch.

Multiply that across tens of millions of viewers, and the scale of the challenge becomes clear. Social media raises the stakes further. When a platform fails during a World Cup knockout match, audiences report it in real-time on the same platforms they use to discuss the game. The complaint travels faster than the fix.

Broadcasters no longer have the luxury of resolving an incident before people notice. The incident becomes the story, and in many cases, travels further than the match itself.

What these viewership numbers actually mean for infrastructure

The shift in how people watch live sport has moved well beyond trend territory.

EMARKETER forecasts that digital live sports audiences in the US will grow to 114.1 million viewers, while traditional pay TV audiences decline to 82.0 million, highlighting the continued shift toward streaming.

The concurrency numbers generated by major sporting events now sit in a territory that would have seemed implausible a decade ago.

During the 2026 FIFA World Cup, for instance, streaming platforms shattered every historical ceiling, highlighted by Brazil’s CazéTV repeatedly breaking global YouTube records for concurrent viewership during the group stage. Meanwhile, in the United States, Peacock and Telemundo’s digital platforms logged an unprecedented 13 million concurrent viewers for a single knockout window. 

When tens of millions of people tune into the same live stream at the same moment, it’s a challenge unlike regular web traffic.

Historically, massive global audiences were insulated by geography. The load was spread across distinct regional networks: antenna signals, satellite downlinks, and physical cable architectures. The physical infrastructure of traditional television inherently absorbed the impact. 

Digital streaming removes that buffer. Traffic spikes all at once, often at the most critical moment. The tighter the match, the deeper the stoppage time, the sharper the spike. Network infrastructure is forced to handle its heaviest, most volatile traffic exactly when it has zero margin for error.

Social media compounds the pressure operationally. The second a crucial goal is scored, a wave of real-time reactions floods the internet, instantly dragging a secondary “curiosity audience” into the app. These are people who weren’t even watching the match, but saw the hype and decided to tune in, meaning the network has to absorb a massive new rush of users precisely while the primary stream is already maxing out its capacity.

To survive these surges while satisfying a modern audience, the underlying broadcast playbook has undergone a massive structural shift. It’s no longer just about handling traffic; it’s also about using modern technology like AI to manage it intelligently.

According to an industry survey, 25% of broadcasters integrated AI into live production workflows in 2025, a massive leap from just 9% the previous year, with 64% identifying AI as the single largest impact driver over the next five years. 

The network is no longer just delivering content. AI is now generating highlights and short clips in real time, producing millions of videos that keep fans engaged long after the live moment has passed.

Ultimately, the technical demand is driven by a shift in what viewers expect. An IBM sports study revealed that 56% of fans now want AI-driven insights layered directly onto their content, while 33% point to real-time, automated translation as the feature that most impacts their experience.

Whether it’s one screen or several, viewers don’t notice the edge infrastructure or AI powering the experience. They just expect the game to play without interruption.

The planning mistake most organisations make

Capacity planning is where most organisations spend their time when preparing to stream a major event. Can the system handle a million concurrent streams? Can it scale on demand if the numbers exceed projections? These are real questions. 

The lesson is not unique to sports streaming. Every digital business now experiences moments where demand, visibility, and customer expectations collide. Peak traffic events such as flash sales, ticket releases, and viral campaigns can drive website traffic 2 to 25 times above normal levels within seconds. The infrastructure may be different, but the pressure is remarkably similar.

Large-scale system failures occur when multiple components, each functioning as expected on its own, are overwhelmed by a surge in demand, rising latency, or regional blind spots at the same time.

The problem isn’t the individual systems. It’s how they work together.

Latency is the factor most consistently underestimated. A few seconds of delay is not a minor inconvenience in live sport. It is a fundamentally broken experience. 

A viewer whose stream is running four seconds behind will see a notification before the decisive moment appears on screen. Someone watching a service from the privacy of their room may hear a celebration from another room before seeing it on their screen.

Geography is another planning gap. Streaming growth is increasingly being driven by emerging markets. In Southeast Asia alone, premium video streaming subscriptions grew 19% in 2025, led by Indonesia, while viewing hours continued to climb across the region. Yet much of the world’s media infrastructure was originally designed around North American and Western European demand. An architecture that looks robust on paper can deliver very different experiences depending on where the viewer is.

The reason is simple: physical distance still matters. Every extra hop between the viewer and the content adds latency, making it harder to deliver a consistent experience at global scale.

Then there is the timing question. The decisions that determine whether a platform holds during the most-watched minutes of the year are not made on event day. They are made months earlier through choices around architecture, redundancy, testing, and operational readiness.

Once an event is underway, it’s too late to redesign the architecture behind it. If your system isn’t designed to handle the pressure before the crowd arrives, it’s already too late.

The hidden chain behind every live event

When a streaming disruption becomes public, people naturally look for a single point of failure: the app, the platform, or the provider.

A live event depends on dozens of systems working together, and any one of them can become a problem.

And the experience is only as good as the weakest handoff between them.

It all starts with the live camera feed moving from the venue to the production studio. This is a real-time stream, not a file download. If you drop even a single packet at the wrong moment, everything down the line breaks, no matter how perfect the rest of your setup is.

Remote and cloud-based production workflows have redefined how live sports are produced, enabling broadcasters to operate with greater agility and scale. As production becomes more distributed, success increasingly depends on ensuring every stage of the delivery chain works together seamlessly.

Each transition is a potential failure point. Managing them requires visibility that extends across providers, platforms, and networks simultaneously.

Behind every live stream, technologies like encoding, transcoding, packaging, rights management, and ad insertion are constantly at work. If any one of them fails, the stream can go down altogether.

Global distribution introduces another layer of complexity. Viewers in Asia, Africa, and South America may all be watching the same match, but each stream travels across different networks and infrastructure. That means performance can vary by region, and issues may affect one audience without impacting another. 

AI is increasingly helping operators detect anomalies in real time, pinpoint affected regions and trigger corrective actions before disruptions become widespread. Combined with point-to-point monitoring, it provides the visibility needed to keep live events running smoothly at global scale.

Edge delivery is where the difference between preparation and improvisation becomes most apparent. Bringing content closer to users reduces latency, absorbs local traffic surges, and improves performance in markets with variable connectivity. 

The value of technology investments such as AI and Edge becomes clearest during the moments when demand is highest.

Monitoring is what turns visibility into action. With AI helping analyze telemetry and detect anomalies in real time, operations teams can identify issues sooner and respond before they affect viewers. By the time customers start reporting a problem, the opportunity to prevent it has already passed.

What reliability is actually worth

For most of early broadcast history, audience tolerance provided some buffer. Disruptions happened. People accepted them. There was nowhere else to go, and the story rarely escaped the room.

Neither of those things is true now.

A streaming failure during a major match becomes public within seconds. Viewers don’t distinguish between a network issue, a processing failure, or a distribution problem; they simply see a service that failed. That single experience can shape the broadcaster’s reputation, credibility and customer loyalty, influencing whether viewers come back for the next event or recommend the service to others.

The commercial implications are significant. Global tournaments such as the FIFA World Cup illustrate just how valuable live sports rights have become. Their return depends on reliably reaching the audience that was promised.

Advertisers invest in live sport for one reason: to reach a large, engaged audience at the exact moment it matters most. If the stream fails during that window, the opportunity is lost. Those viewers, impressions, and advertising value cannot be recovered once the moment has passed.

The same principle increasingly applies outside media. Customers rarely know nor care whether an outage originated in the application, the cloud environment, the network or a third-party dependency. They experience a failure of the brand. In a digital-first economy, reliability has become part of the customer experience itself.

For broadcasters and streamers, reliability is no longer just an operational KPI. It directly influences audience trust, advertising revenue, and the long-term value of premium sports rights.

The demands ahead are bigger

AI-assisted production is already changing how live events are created. Broadcasters are using AI to automate highlight generation, camera selection and real-time clip packaging for social media, with new AI-assisted workflows producing sports highlights up to 80% faster than traditional methods. 

All of this processing happens within the live delivery chain, where every additional task must be completed without adding latency or compromising the viewing experience.

Personalisation at scale is the next significant challenge. Not personalisation in a vague sense, but the specific technical reality of delivering multi-language commentary tracks, different languages, different statistical overlays, and different camera angles to different viewers watching the same event simultaneously. 

Instead of one stream per event, the infrastructure has to manage a matrix of concurrent variants, each with its own encoding, storage, and delivery requirements. 

Interactive experiences add bidirectional data flows: real-time polls, integrated second-screen data, live wagering. These move data from the viewer back through infrastructure that was primarily built to push content outward. Managing that at scale is a different engineering problem from managing delivery.

Higher-resolution formats (4K now becoming a standard expectation in premium markets, 8K moving into early deployment) are bandwidth-intensive at exactly the scale where bandwidth is already under pressure. Consumer devices are ready. Infrastructure in many high-growth markets is not uniformly there yet.

Many of these capabilities are already being deployed for major global sporting events. The organisations investing seriously in technology, innovation, and infrastructure now are building toward a standard that will be the baseline requirement within a few years. Those that are not will be closing the gap under the worst possible conditions.

The technology you never think about

The broadcasters that succeed don’t leave reliability to chance. They plan for it from the outset, designing their infrastructure to handle peak demand long before the audience arrives.

This reality hits hardest during massive global events. When a stream glitches, millions of people feel it simultaneously in a matter of seconds. Keeping those streams alive doesn’t happen by accident; it takes massive scale, intense discipline, and deep experience controlling everything from the stadium camera to the viewer’s screen.

The lesson extends well beyond live sports. Every enterprise is becoming a real-time digital business, whether it’s delivering AI-powered applications, launching digital products, processing financial transactions, or handling a sudden surge in customer demand. Different industries may face different triggers, but the expectation is the same: the experience has to work, even when demand is at its highest.

Delivering that level of reliability is why many of the world’s largest sports brands rely on Tata Communications. Supporting the broadcast, production, and management of 80% of the world’s sporting events, and reaching more than two billion viewers across 190+ countries, Tata Communications operates in the invisible layers that make every live moment possible. We call this the “Virtual Stadium of the World”, the technology and infrastructure that connects fans, broadcasters, rights-holders, and sporting moments at a truly global scale.

By managing the critical handoffs across contribution networks, edge processing, and global media infrastructure, we engineer the resilience required to keep 120,000 live events running flawlessly every year.

Live sport may be the most visible test of digital infrastructure, but it won’t be the last. As AI, personalisation and real-time experiences become the norm across industries, the ability to deliver reliably at scale will define far more than match day.

To learn more, visit us here.

The biggest and loudest prediction about AI is that it will eliminate millions of jobs. It is dramatic and easy to repeat. But from what I’ve seen, inside most enterprises the more immediate problem has turned out to be something else entirely: a growing mass of tools, agents, models and usage costs spreading faster than most organizations can govern or connect to real business value, also known as AI sprawl.

None of that invalidates the initial fear. Indeed, AI can clear backlogs, speed up analysis, draft usable content and reduce time spent on repetitive work. In my opinion, what goes wrong is the assumption that those gains will scale seamlessly, and that more AI will automatically produce more value.

What really matters is not only how much AI a company can deploy, but whether its use fits inside a growth strategy, an operating model and an organization that can use it well.

The early results of AI use made the logical progression feel obvious, even a foregone conclusion. If it could already improve output in narrow use cases, then broader deployment should produce broader gains. Simple! Better models were expected to deliver better results. More agents were expected to drive more automation. For many companies, this logic held for long enough to encourage overexpansion.

But this logic has started to break down as usage continues to scale. I’ve seen returns diminish much quicker than expected. To illustrate, one industry analysis found that developers who used AI most heavily produced about twice the output of moderate users, but consumed roughly ten times the compute.  

At a certain point, more AI does not create proportionally more value – it simply becomes more expensive. But where, exactly?

From experimentation to sprawl

Experimentation played a key role in this downturn, but it’s not the culprit. As AI continues to sprawl, the problem continues that AI is spreading faster than most companies can coordinate. Teams often solve the same problem in parallel, paying for overlapping capabilities and layering new tools atop existing ones without any clear inventory of what ‘s already in place. What can appear as momentum is really turning into redundancy.

I’ve seen versions of this play out repeatedly. At one financial firm, several business units were pursuing AI projects aimed at automating research and reporting. Each team moved independently; selecting their own tools, building their own workflows and creating separate data pipelines, with little to no coordination between teams. In some cases, different groups were developing nearly identical capabilities without realizing it, solving the same problems twice without any shared visibility into each other’s work.

Individually, the projects showed real promise. Collectively, the projects created duplication, fragmented data and inconsistent standards business and enterprise wide.

By the time leadership stepped back to assess, the company found itself paying for overlapping capabilities, maintaining multiple versions of the same underlying data, and struggling to determine which solutions were actually delivering value versus which were simply consuming budget and eating at engineering time.

Perhaps most troubling: nobody at the enterprise level had a complete view of what was being built, by whom or why. What began as healthy, well-intentioned experimentation had, without anyone deciding it should, evolved into full-blown AI sprawl, creating a patchwork of disconnected initiatives that was difficult to govern, harder to secure and far more expensive than a coordinated approach could and should be.

Early wins encourage a still wider rollout, but many organizations expand usage before they put real controls in place. Experimentation becomes sprawl. Budgets grow quickly, and few leaders have a reliable view of who is using what or why.

AI strategy cannot sit beside growth strategy

This is where I see many companies still get the issue wrong. They treat AI and growth strategy as two separate efforts, then wonder how adoption gets so messy. A business cannot drop AI into its operations and expect momentum to take over. The technology has to support a clear path to growth, whether that means improving margin, speed, service, capacity or decision-making. At the same time, growth plans cannot assume AI changes nothing about delivery, design or operating leverage. The real challenge is in ensuring the two work together.

Personally, I’ve seen better results when AI initiatives are tied to a specific business objective from the beginning, rather than launched as broad, abstract or transformative effort. One mattress retailer I’ve worked with took this approach, starting with a single, focused and well-defined use case rather than trying to transform or overhaul the entire organization at once. The company introduced an AI-powered training platform for store associates, giving employees a low-pressure way to practice sales conversations and product recommendations before applying them to external situations with customers on the floor.

Because employees experienced immediate and tangible value from the tool, adoption spread quickly across locations, with minimal need for top-down mandates. Early, visible success helped to build internal credibility and generate momentum, which leadership then leveraged to expand into more complex AI initiatives across areas such as inventory management, demand forecasting and replenishment planning.

Ultimately, the technology succeeded not because it was innovative for its own sake, but because it was connected to a larger growth strategy: improving sales effectiveness on the floor, driving operational efficiency behind the scenes and strengthening workforce capability at entry level. A major lesson we walked away with here was that starting small and specific, with a clear throughline to business value creates a strong foundation for sustainable and scalable AI use.

What implementation actually takes

All this takes more than a few easy guardrails. It takes strategy. Leaders need a real inventory of the tools, agents and assistants already in use across the business, who owns them, what data they can access and everything that they support.

They also need financial controls that match the economics of token-based usage, including role-based access, thresholds and review processes that make spend visible before it becomes a surprise. Similarly, they need metrics that go beyond mere activity. More prompts do not mean more value. If a deployment cannot be tied to throughput, margin, quality, cycle time or another tangible result, it is still unfinished.

This is also why blunt shutdowns rarely work. If leaders clamp down too hard, employees often move to unsanctioned tools and create a larger shadow AI problem, or the unauthorized use of artificial intelligence tools, models or chatbots by employees, without the knowledge or approval of IT and security teams, with even less visibility and more risk. The better answer is disciplined adoption: clear ownership, rules, metrics and enough flexibility for teams to use AI where it works.

That matters for the people as much as it does for the budget. Those that modernize well end up with better work – not just less of it.

The story of the moment isn’t about AI replacing people – or even AI in general. It’s about whether companies know their own businesses well enough to keep incorporating powerful new tools without mistaking activity for progress. As technological capabilities continue to appear, the winners will be the organizations that understand where it belongs, what it can improve and how to turn each new wave into something permanent.

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

Major AI labs are unleashing forward-deployed engineers (FDEs) to try and grab enterprise customers. Large consultancies are dishing out tokens and assembling armies of consultants — both human and agent — to do the same.

But smaller firms are in the mix now, as well. AI is helping 28Stone Consulting, a New York-based, 230-person technology consultancy for capital markets, punch above its weight against larger rivals in the rush to deliver FDEs.

In this Q&A, Thomas Dolan and Frank Erickson, founders of 28Stone, argue that agentic AI isn’t a one-size-fits-all solution in vertical markets; success takes discipline, deep domain expertise, and human involvement to mitigate risk.

Many enterprises continue to struggle with the use of AI agents, which is consultancies are stepping in to get projects off the ground. 28Stone is among those that have published blueprints and methodologies on the development and delivery of agentic AI workflows with humans in the loop.

Computerworld spoke with both founding partners about why companies are still stumbling with agentic AI rollouts, and what a disciplined delivery process actually looks like.

After 15 years of delivering software for capital markets firms, is ‘AI-first’ a real distinction or just positioning?

Dolan: “We’re not shying away from being AI-forward. What needs to shine through is AI done intelligently — not stuff you get by buying some tokens for somebody on the trading desk. We’re an AI-first firm.”

Erickson: “And it’s temporary. At some point, AI is going to be synonymous with software development.

“The whole idea of an AI SDLC (software development lifecycle) versus an SDLC is going to be one and the same, a lot like cloud computing today. To not include AI in your strategy, you’d look like a COBOL vendor.”

What does agentic AI delivery look like?

Dolan: “We’ve got several AI initiatives delivering a pure agentic approach. We’ve doubled down on the human expertise wrapper in the SDLC. That doesn’t mean sacrificing any of the benefits of the AI models — quite the opposite.

“You don’t achieve anywhere near the same level of value from applying AI without keeping that expertise — industry, functional and technical — throughout the process.”

Where do humans stay in the loop once agents are doing the work?

Dolan: “We’re believers in starting with requirements discovery. Someone who knows the analytical nuances of a good business analyst is critically important; shaping a product owner’s business information through a markup file that can be fed into a BA agent, then treating the output as if it came from a very fast junior BA. Only then is the story complete.

“The developer takes that story, transforms it into the most efficient input, then owns the output, because they’re accountable for that code. A developer should own the code on both the input and output side.

“Your product owner, who knows the business, that’s great. But expecting them to interact with an agent and output enterprise code is ridiculous. It’s not a great plan.“

Why not just put one do-everything person in charge of AI and agents?

Erickson: “Every analyst, programmer or software engineer isn’t a great requirements analyst. And a great domain analyst with some technical background won’t know if the agent’s code is garbage, maintainable, performant.

“It’s unrealistic to expect one individual to have that breadth across domain, software engineering, testing, deployment. Clients ask all the time, and we push back: ‘Great, if you can find that guy, they’re few and far between.’ To deliver at the enterprise level, you need the human expertise, at depth.“

Dolan: “There’s system speed and latency, important in parts of finance. Then there’s speed of delivery, because other areas evolve quickly and time-to-market is critical.

“Our human wrapper may at first pass come across as a little slowed down. Maybe it is. But [Erickson] has a good analogy about one of the dangers of AI: you can end up going really fast in the wrong direction. By the time you look up, you’re way off base and have to backtrack.“

What about AI in your sector do you think is overhyped?

Dolan: “The hype around the ease of use of AI and the democratization of enterprise software delivery — that ‘anybody could do it now, it’s all being done by machines’ — is another idea that could prove costly in the long run.

“This do-it-yourself reaction is dangerous for clients, and for trust in the overall AI benefit, which is real. We compare it to the beginning of offshoring 20, 30 years ago: a golden idea that was going to cure everything. A lot of firms did it thoughtlessly, thinking it’s just labor arbitrage, and it almost inevitably failed. That all-or-nothing mentality missed that offshoring is an amazing way of getting better value for your dollar, but it has to be done thoughtfully, so the delivery process — the thing that ties it all together — stays unsevered.

“We’re seeing that now. I’ve heard, ‘We’ll just push a button, the machine’s building the system.’ The machine is not building the system. It might be writing the code, the story, running the tests.

The system is built by a team of engineers you bring in and trust. My fear is that people will say, ‘We don’t need this vendor or this technology team. I’ve got a product team. They might not be able to code at all, but they know the business,’ and it fails dramatically. 

“Then people say, ‘We played with AI, it’s not ready yet,’ and throw it all away. One of the best things we can do is ensure clients know the benefit is real.“

Erickson: “The hype can be summed up in a single phrase: vibe coding. That has done AI a massive disservice, because there’s a huge difference between vibe coding and enterprise software development, and some of the loudest proponents of AI are too latched on to it. In our industry, the only way to succeed would be a stable of unicorns. It just doesn’t scale. I get perturbed when our people internally refer to AI tooling as vibe coding; if they think that’s what they’re doing, they’re misunderstood.“

When you engage clients at different levels of AI maturity, how do you get them to a understand what works?

Dolan: “95% of our take on an agentic approach is in line with everyone else’s, but that 5% matters, especially in requirements discovery, in who’s giving the requirements and how they’re thought of. It can set you up for dramatic errors, given the speed at which you’re moving.

“There’s a dangerous human tendency we’re seeing among clients to try and cut corners at the start of a project and — in lieu of having deep, expert driven discovery sessions — just summarize what they may want using AI.

“We would hope our clients are collaborative, everyone understanding it’s early days. If a client insists on doing something we feel strongly against, like a product owner completely owning everything right up to code generation, that’s an issue we have to either push back strongly on or step out of the accountability for.“

AI body shops — LLM providers and giant consultancies — are emerging to help enterprises deploy AI. Does that model work?

Dolan: “Whether you’re partnering with an LLM or with an AI-first, generic software provider — ‘Hey, we’re not industry guys, but we know AI delivery’ — you end up, if you’re a bank or a broker-dealer, saying: ‘All right, we know our business, these guys know the AI side of it. What could go wrong? Put us together and we’ll have quality engineering.’

“The problem is what you miss: the know-how of putting industry and technical expertise together and actually delivering financial services systems. The people working at the generic delivery firms, whether an AI-only firm or a body shop somewhere, don’t have that capability.“

Does AI change the economics for smaller consultancies like yours competing against the big firms, and does it cut both ways?

Dolan: “Over our 15 years pre-AI, there were two recurring reasons we’d lose a project. One: ‘We’d love to work with you guys, given your subject matter expertise, but the costs just aren’t there compared to my budgets. I’m being forced to go to a body shop or an [offshore] delivery center.’ The other side of that coin: ‘We love your capabilities, but you’re a firm of 230 people and I need 300, 400 people.’

“AI changes the options for clients. You don’t have to sacrifice the niche vendor who knows your space just because you need a larger team or a cost target. AI levels the playing field and should allow smaller firms to compete with the larger, big-box generic firms, the Accentures of the world.“

Erickson: “It redefines what scale means. You can look at velocity as a measure of your cost to deliver, not a rate card. Scale can’t be defined in terms of headcount anymore. It’s got to be defined in terms of output.

“There’s a threat in it, too. If you’re an Accenture with hundreds of thousands of low-cost software engineers, how do you train all those people? I feel for them. But for us, a couple hundred people with a specific domain focus, it’s a huge opportunity.“

How has the profile of the people you and others hire changed with this agentic process?

Erickson: “You’re still looking for people with strong engineering and design backgrounds, and communication skills, because they interact across the software development lifecycle more than in the past.

“Many take too much joy in typing out perfect code. Sorry, I don’t need you writing for-loops and classes anymore. I need you reviewing them, understanding them, operating at a higher level. That’s a different kind of person: an engineer, not a programmer or a coder. On the [business analyst] side it’s similar: people took great pride in detailed user stories covering every path. Now it’s conversations, prompts, reviewing output — less doing, more interacting.

“More than ever, they have to be interested in the domain. They can’t just be, ‘I want to learn everything there is to know about Java.’ That’s too narrow. They don’t have to be an expert; they have to be interested. In our case, capital markets is a specific niche. The biggest challenge is getting familiar with the tools — finding time, while delivering for customers, to ramp up and make the mistakes you need to without jeopardizing projects.“

What about governance? Who’s keeping AI delivery and its costs under control?

Erickson: “This is evolving rapidly. People aren’t sure how to put governance around this. The most obvious is financial governance. People are starting to get hefty bills. One of our clients spent a million dollars on tokens over the last eight weeks alone. Sticker shock. The token-maxing policies are starting to show their flaws. It’s wild west still: learn on the fly, then figure out what needs to be governed.“

Are CIOs actually opening their wallets? And when they do, what’s the smarter way to invest?

Erickson: “There’s still a lot of caution. Forecasts keep going down on how long something should take. So: ‘I could wait three months and maybe still get it delivered by the same date someone’s promising me now, but for half the price. I’m going to wait and see when equilibrium is met.’ We haven’t seen the wallets open up like crazy — it’s slow adoption.“

Dolan: “One of our clients is looking at it from a productivity-boost perspective: instead of doing the same for less, I can do much more for the same. AI lets clients pull the trigger on things they wouldn’t have in the past — projects that might not have been approved pre-AI, where the costs have come down to a point that’s palatable with the business.“

Erickson: “And that’s the story we’re hoping to hear more of. There isn’t a huge cost anymore to exploring a business opportunity. The time and money that would have gone to a return-on-investment study could be spent on a proof-of-concept with AI, and the project done a few weeks later. Maybe [there’s] a hint of things to come, where decisions start being made quicker. 

“There’s a little fear on our side, though: a lot of tiny little projects is tough for a consulting business.“

For diversified enterprises, few operating model questions are as persistent or polarizing as centralization versus decentralization. Decentralization promises speed, ownership, and local responsiveness. Centralization promises efficiency, standardization, and leverage. Both can be right. Both can be wrong. The challenge is that many organizations end up with both models operating at once, without enough clarity about why.

The result of fragmented systems, duplicated capabilities, inconsistent data, rising IT spend, and a complexity tax that compounds over time is familiar to many CIOs. What starts as autonomy can become architectural sprawl. What starts as enterprise leverage can become bureaucracy. And as companies modernize core platforms, integrate data, and scale capabilities like AI, the tension becomes harder to ignore.

Paul Krebs has lived that tension from multiple vantage points. Most recently as CIO and chief transformation officer at Koch Industries, and previously a technology and transformation leader at The Coca-Cola Company, he’s worked in environments where business units value autonomy, enterprise scale matters, and the wrong operating model can slow progress just as easily as the wrong technology architecture.

His conclusion isn’t that CIOs should pick a side, but they need a more intentional form of centralization, one that starts with business architecture, clarifies decision rights, and continually revisits where capabilities should sit as the organization matures.

Centralization: a design choice, not a doctrine

In diversified organizations, decentralization often starts as the default because it aligns with how the business creates value. Local businesses understand their customers, markets, regulatory environments, and operating realities, and giving them decision rights can increase speed and accountability.

In Krebs’ experience, the default model often leaned toward decentralization, he says, with the belief that optimizing for customers and markets would allow different businesses to be as responsive as possible to the specific customers and markets they served. But that logic isn’t complete. Leaders also need to ask whether there’s a compelling case where a more centralized approach can generate additional value, accelerate progress, or optimize investments.

Digital transformation created one of those moments. Krebs recalls around 2016 when Koch challenged its businesses to build multi-year digital transformation roadmaps. The ambition was there, but the capabilities to execute at the necessary pace weren’t evenly distributed. In response, the organization invested more aggressively from the center, building shared services and centers of expertise in areas such as business transformation, enterprise applications, and data and analytics.

The purpose was acceleration, not control. Centralizing those capabilities helped accelerate learnings, capability building, and their ability to deploy new solutions at scale. But the move wasn’t treated as permanent. “There was always a belief that the centralization push should be re-looked at on a regular basis, not thought of as a forever decision,” he says.

Know what belongs at the center

Over time, Krebs learned that  the capabilities most likely to remain centralized were those where scale, consistency, and risk management mattered more than local differentiation. Infrastructure, collaboration platforms, cybersecurity, cloud management, FinOps, and the help desk were natural candidates to remain shared services.

Other areas were more nuanced. Some application capabilities moved back into the businesses as local maturity increased. Many data and insights capabilities also moved closer to the business once teams had built enough muscle to own them. Meanwhile, certain emerging capabilities such as spatial technologies like AR/VR remained centralized because it didn’t yet make sense for each business to build them independently. Many companies have lived this journey as well, for example, with gen AI, which often started with a center of excellence, and then evolved into a more decentralized approach, enabling teams across the business to innovate quickly.

That distinction avoids the trap of treating the enterprise as one uniform operating model. “Both models can be successful, and both have advantages,” he says. “That’s what makes the balance so difficult.”

Centralization provides a clearer path to execution at scale and cleaner decision rights, but it requires change management and careful attention to bureaucracy. Decentralization provides ownership and speed, but it can also over index toward preference versus real differentiation, he adds, while making architecture harder to scale later.

Don’t confuse standardization with centralization

One of the most important distinctions Krebs makes is between centralization and standardization. Many organizations treat them as interchangeable, but they’re not.

“You can have a centralized team that can manage the nuances of different requirements,” Krebs says. “You can also have a centralized standard platform that can be used in a decentralized manner.”

That distinction opens up more operating model choices. A company may centralize a platform but decentralize how business teams configure or use it. It may standardize process patterns while keeping execution close to the region or business unit. It may also centralize architectural governance while allowing local teams to move quickly within defined guardrails.

This is especially important in global organizations, where regional needs are real but not always unique. Krebs advises leaders to examine whether local requirements can be made more generic and reusable. The risk is solving each local requirement as a one-off, so the better path is to understand the underlying requirement, build it in a way that can scale, and still allow local teams to execute within the standard model.

Let business architecture lead technology architecture

Few topics expose the centralization tension more clearly than ERP consolidation. Many diversified companies, particularly those shaped by acquisition, end up with dozens or hundreds of ERP instances. Some leaders push for massive consolidation. Others prefer to build integration layers on top of the existing environment.

Krebs’s starting point is neither technology nor cost. It’s business architecture. “The easiest and most effective path is when the IT or systems architecture follows and aligns to the business architecture,” he says.

If the business is truly going to operate processes separately, separate systems may be appropriate. But if the organization has numerous teams, processes, and tools, leaders need to ask whether there’s enough differentiation and value to justify that complexity.

The same logic applies to M&A. Companies can get into trouble when integration synergies are held hostage by ERP migration timelines. Instead, Krebs advises starting with the business integration strategy. Understand where the synergies are, how the business architecture should come together, and then decide whether the IT architecture needs to be fully integrated, or whether a data layer, reporting platform, or other integration approach can deliver value faster.

Make the cost of complexity visible

CIOs in decentralized companies often face a frustrating dynamic. The business wants autonomy and speed, but the same leadership team still questions why IT spend is high relative to benchmarks. Krebs says the answer starts with cost alignment and visibility.

In environments with a mix of centralized and decentralized services, Krebs saw centralized capabilities like infrastructure, help desk, and security perform well on benchmarks. More decentralized areas, such as BI, reporting, and commercial applications, often had more redundancy and higher cost.

The point isn’t to blame the business but make the economics of complexity visible. CIOs need to show how flexibility in one area may require multiple systems, data stores, or teams elsewhere. “I understand we want flexibility here,” Krebs says. “But leaders must see when that flexibility may cost the company money, and be clear on whether the value justifies it.”

That shifts the conversation from IT cost to business service economics. A single aggregate IT spend number is rarely useful in a decentralized environment. More helpful is a capability-based view that shows which areas are scaled efficiently, which are fragmented, and where the business architecture is driving the technology cost structure.

Revisit the model as maturity changes

For a new CIO entering a decentralized environment, Krebs cautions against immediately declaring that too many things need to be centralized. The better starting point is curiosity. “I would begin with just trying to understand why they’ve made the decisions they have,” he says.

From there, CIOs can engage leaders in a conversation about the target operating model, connecting business architecture to technology, data, and organizational capabilities. Once the direction is clear, he advises CIOs to work with the willing. Find the parts of the organization that already see the need for change, prove the model there, and scale from demonstrated success.

Regardless of execution, though, the right model changes over time. A low-maturity capability may benefit from centralization because the organization needs to build talent, avoid reinventing the wheel, and accelerate learning. As maturity grows, decentralization may make more sense because business teams need flexibility to adapt quickly. Once maturity is high and patterns stabilize, the organization may be ready to centralize again to leverage scale.

“Once I’ve decided I’m going to start with centralized or decentralized, you don’t necessarily need to stay in that model,” Krebs says. “You need to be continually revisiting the operating model as your organization matures and evolves.”

That may be the heart of smart centralization. It rejects the false permanence of operating model decisions, and recognizes that autonomy and scale are both valuable, but in different places, at different times, for different reasons.

Somewhere in the last eighteen months, “AI agent” stopped being a useful term. CIOs may even be afraid to ask what “agent” truly means, as it now seems to describe everything from a chatbot that answers HR questions to an autonomous research system that plans its own week of work. When a single phrase carries that much weight, well, it stops carrying any.

I’ve spent the last three years inside hundreds of enterprise AI deployments, and the factor that separates the programs scaling elegantly from the ones still shuffling is often the CIO’s architectural fluency: The ability to look at business problems across the organization and recognize, on sight, what kind of AI architecture is the right fit. In my experience there are six archetypes, each with their own nuances, that CIOs should internalize to make well-informed decisions going forward.

1. The conversational assistant

The first, and the one most enterprises meet first, is the conversational assistant: The chat-based partner that an employee or customer opens when they want to think out loud. Deloitte found that 38% of organizations report AI is already strengthening their client or customer relationships. This is the architecture people fall in love with: A well-designed assistant with constantly updated information, persistent user-level memory, tools that can act on behalf of users, and citations on every factual claim becomes a useful problem-solver that’s available at any hour of the day.

A global law firm I work with deployed an internal assistant that gives every attorney instant access to the firm’s accumulated precedent, memos and prior matter work. Associates who used to spend the first hour of a research task hunting through document management systems now start with a grounded, citation-backed answer and refine from there. This helped the firm’s institutional knowledge, previously locked in the heads of senior partners, become queryable by anyone with a deadline at 11 p.m., or later.

A second example: A mid-market wealth management firm built a client-facing assistant that handles portfolio questions, statement explanations and routine servicing requests. The assistant draws from each client’s actual holdings, recent activity and the firm’s published market commentary, with citations linking back to source documents. Advisors stopped being interrupted for the questions that didn’t require an advisor, and clients got answers on a Sunday.

2. The triggered workflow

Another pattern producing the value across the enterprises I work with is something that runs silently: An email arrives, a ticket is created, a file lands in a folder and the agent executes a process utilizing both reasoning and determinism. These agents don’t even require user adoption, because they’re invisible to the end user. They produce measurable outcomes, but fit cleanly into the audit and change-control processes IT teams have run for decades.

A commercial insurer I advise built a triggered workflow for inbound submissions. Every broker email that arrives at the underwriting inbox is classified by line of business, the attachments are parsed, key risk fields are extracted into the policy administration system, and a draft acknowledgment is queued for the underwriter’s review. Seemingly overnight, the inbox began arriving pre-sorted, and submission throughput rose meaningfully without any change to headcount.

Another example, this time from a private equity firm: Every inbound confidential information memorandum (CIM) that hits the deal team’s shared inbox triggers a workflow that extracts the financial summary, screens it against the firm’s investment criteria, drafts a preliminary memo and posts the result into the deal-tracking system. Associates still make the call on what to pursue, but the first three hours of manual work on each opportunity now happen before anyone even opens the file.

3. The autonomous agent — with sub-agents

Here we have the architecture that gets the most conference attention: The autonomous agent, given a task and left to plan its own steps by utilizing its own sub-agents. Autonomous agents are not one-size-fits-all, but they do meet a specific need: Multi-source research, complex cross-system lookups, deep-dive investigations. All of these are processes where the path isn’t usually specified in advance, but the tools are. With the right design discipline, an autonomous agent feels like having a self-sufficient teammate who can call in the right resources and specialists if needed.

A global consulting firm I work with uses an autonomous research agent for early-stage engagement scoping. Given a target company and a strategic question, the agent decides for itself which sub-agents to consult (choosing from internal proprietary databases, prior engagement archives, licensed market data, public filings) and produces a structured briefing with its reasoning chain attached.

Another large technology company I know of deployed an autonomous agent for cross-system incident investigation. When a production alert fires, the agent forms a hypothesis, queries the necessary sub-agents with relevant monitoring tools, log stores and deployment systems, and follows the trail until it reaches a defensible root-cause summary to surface to an engineer.

4. The multi-agent team

The fourth pattern is where the next wave of enterprise quality gains is going to come from. According to Databricks, usage of multi-agent systems grew 327% in just four months as enterprises moved beyond single chatbots. Several specialized agents, each with its own role and toolset, coordinate through a shared protocol: A researcher and a writer, a planner and a set of executors, a proposer and a critic. The proposer-critic feedback loop is one of the smartest techniques in agent design today. One model produces an answer; a second, with a different prompt and often a different provider, evaluates it against explicit criteria. For compliance review, contract analysis, high-stakes classification and any output that will be audited, this second pass is extremely helpful and mirrors how human teams work.

A global bank I work with uses a multi-agent system for marketing and communications review. One agent drafts client-facing copy, a second checks it against the firm’s regulatory and brand guidelines and a third checks it against jurisdiction-specific disclosure rules. Disagreements among the agents are surfaced to a human reviewer with the specific clauses flagged. The compliance team stopped being the bottleneck on every routine piece of copy and started focusing on the high-judgment cases instead.

The next example: A pharmaceutical company built a multi-agent workflow for medical literature summarization. A retriever agent gathers candidate studies, a reader agent extracts study design and findings, a critic agent challenges the reader’s claims against the source text, and a synthesizer agent composes the final brief. The proposer-critic loop in the middle is the reason the medical affairs team trusts the output enough to act on it.

5. The human-in-the-loop (HITL) agent

The fifth pattern is the one I think we’ll see increasingly more of in the future. While many see “full automation” as the goal, the right target is actually to let the agent handle the 80% of a task that is mechanical, while preserving human judgment at the most critical moments. This is achievable via human-in-the-loop (HITL) agents. According to Moody’s, 42% of compliance professionals believe that human oversight is mandatory, and I agree: AI should run right, by getting approval and review before any sensitive business action is taken. HITL is the architecture that can help turn a skeptical team into an enthusiastic one.

A regional health system I worked with uses a HITL agent for prior-authorization letters. The agent assembles the clinical evidence, drafts the letter against the relevant payer’s criteria, and routes it to a nurse case manager for review inside the existing workflow tool. The nurse approves, edits or rejects in seconds rather than minutes, and every edit helps make the next draft better.

A property management company uses a HITL agent to run its maintenance work orders. When a tenant emails about a problem (an HVAC unit that died overnight, say), the agent pulls the structured details (tenant, unit, issue type, urgency), matches the job to the right vendor from the directory, and drafts the work order. A team member approves it in Slack before anything goes out. From there the agent emails the vendor with the full order, confirms with the tenant that someone is on the way and updates Airtable, closing the loop completely.

6. The scheduled agent

On a set schedule or against a batch of inputs, this agent runs the same defined task: Produce a report, refresh a dataset, monitor a set of sources or summarize a period of activity. Under this archetype, unsexy work gets done consistently, integrated into existing operational rhythms like the Monday morning meeting, the daily standup and the monthly board deck, without asking anyone to change their behavior. This is the architecture that shifts AI from feeling like even more work, to a seamless teammate that just works.

A private equity firm I work with runs a scheduled agent every Monday at 6 a.m. that monitors news, filings and earnings activity across every portfolio company and produces a single PDF that lands in the deal partners’ inboxes before the weekly investment meeting. No one logs into a dashboard. The agent shows up, on time, with the same format every week, and the meeting now starts from a shared baseline rather than from whatever each partner happened to read over the weekend.

A second example: A global manufacturer runs a nightly batch agent that ingests the day’s quality-control reports across plants, summarizes anomalies against a rolling baseline, and produces an end-of-shift handoff document for each site lead’s morning. The agent doesn’t flag emergencies, but it ensures that the slow-moving patterns no human would catch reading one shift’s data in isolation get surfaced.

Bringing it together

None of these six archetypes is more advanced than the others or inherently better. But CIOs can have an edge by choosing the one that the operational problem actually calls for.

Before you scope a single deployment, you should be able to look at a business problem and name its shape: Is this a question someone needs answered in the moment, or a process that should run the instant a trigger fires? Does the path need to be discovered, or is it known in advance and just waiting to be executed? Where, exactly, does human judgment have to stay in the loop, and where is it just friction?

Going forward, CIOs should start treating the architecture decision as the first design choice. Everything downstream — adoption, governance, trust — only gets easier if the architecture is the right fit.

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

We are inundated with promises that artificial intelligence will save us and that the next governance framework will protect us. Buy this platform, adopt that model and the hard part finally gets easier. After 15 years in this field, I have wanted that shortcut as much as anyone.

But both promises are downstream of something neither one can produce. You cannot automate trust between two people. You cannot govern your way to a relationship. As AI moves into the core of how organizations operate, and accountability stops mapping cleanly to the org chart, what holds when the stakes are highest is not the platform or the policy. It is two human leaders who know each other well enough to carry the weight together.

I think about this often now, a year after publishing a book about the pressures bearing down on security leaders, “The CISO On The Razor’s Edge: Leading Cybersecurity When The System Is Designed To Break.” The partnership between the CIO and the CISO is the last human relationship in cybersecurity. AI raises the stakes. Governance sets the floor. The relationship is what holds.

I saw it work once, up close. When I worked in Washington State, the CIO, Bill Kehoe, talked to his CISO, Ralph Johnson, every day. Weekends included. Not because a policy required it, but because the mission did. That partnership is a large part of why the role stayed sustainable for them when it broke so many others.

The promise we keep believing

Walk any conference floor and you will hear the same pitch in a hundred variations. The next AI layer will close the gap. The next framework will lock down the risk. The technology is usually ready. The organization is not. I have watched too many well-funded programs stall to still believe the tool is the answer, and almost every time, the breakdown traced back to leaders who were not aligned before the work began. A framework run by misaligned leaders inherits the misalignment. You can buy the best controls on the market and still watch them fail when two leaders work from different assumptions about who owns what.

Bill and Ralph understood this. Security decisions were not handed to Ralph after the fact to bless or block. They were made with him, inside the technology decisions, because the two had already agreed on what mattered. That is not governance. That is leadership creating the conditions in which governance can work.

It is the real lesson I came to in the book. Technical knowledge matters, but it is not enough. As I wrote then, “Influence, trust and internal relationships are non-negotiable.” Without influence, CISOs cannot lead. Without technical substance, they cannot prioritize what matters. And without partnership, especially with their CIO, “they’re operating without a safety net.”

AI does not change that truth. It raises the cost of ignoring it.

When decisions move at machine speed

The ground under both roles is shifting. Work no longer flows through people alone. It moves across people, platforms, partners and agents at the same time, and it moves fast. Decisions that once waited for a meeting now form in seconds. The org chart, built for an era when humans did the work and reporting lines explained accountability, struggles to keep up.

This is where the partnership stops being a nicety and becomes infrastructure. When decisions form at machine speed, the human escalation path has to be instant. There is no time to negotiate a relationship in the middle of an incident. Either the trust is already there, built in the quiet stretches before anything goes wrong, or it is not there when it counts.

I asked Bill what he would lose if his daily calls with Ralph dropped to once a week. His answer cut straight to it.

“Cyber does not rest,” he told me. “It is active and dynamic and requires 24/7/365 attention.” Drop to a weekly check-in, he explained, and “I am treating the CISO like any other executive position.” For Bill, AI only raises the stakes on that daily contact. “Relationships and partnerships between the CIO and CISO will never die due to AI,” he said. “I can’t even imagine a scenario where I don’t talk to my CISO on a daily basis including weekends to discuss the latest risks and vulnerabilities or news on potential AI attacks.”

That is the point most of the market misses. A platform can flag the anomaly. It cannot decide what the organization is willing to risk, who carries that decision or how two leaders stand behind it together. The faster the machines move, the more the partnership has to already be in place.

The loneliest seat in the building

There is a reason some now call the CISO job the least desirable role in business. The seat carries enormous accountability and rarely the authority to match. As one security leader put it, the pressure has never been higher and the control has never felt lower. People are burning out and walking away from a role that has never mattered more.

Here is the hard part. There is no log file for burnout. No alert fires when the weight finally exceeds the leader. That drain is invisible right up until it is not, and it raises organizational risk as surely as any unpatched system. The structural fixes the industry debates are all real and all slow.

The fastest source of relief available to a CISO is not a framework. It is a CIO who treats the relationship as a daily partnership rather than a line on a chart. An isolated CISO is a vulnerability. A partnered one is an asset.

You see what that partnership is worth in the worst moment. I asked Bill what it looks like when an incident hits and public trust is on the line. He did not reach for a tool.

“I am accountable as CIO to everything that occurs in the state from a technology lens including cyber,” he said. When a severe incident hits, the call comes to him from agency leadership or the Governor’s Office. Then he follows the plan, but never alone: “I will be in constant contact with the CISO on the details of the incident.”

That is the safety net made real. The CISO is not carrying the mission alone at the moment it matters most. On the razor’s edge, leadership keeps you upright. Partnership keeps you in the fight.

The work no tool will do for you

In my advisory work, I sit with C-suite leaders who share values and still cannot find alignment. The barrier is rarely disagreement. It is that they are not communicating clearly or often enough to build the trust that alignment requires. I have watched negotiations that could only happen by proxy, over email, because two capable leaders had stopped talking directly.

I recently sat in an hour-long discussion where alignment and shared values were present the whole time. It did not become clear until the final fifteen minutes. That is what real alignment costs: patience, persistence and a stubborn commitment to clarity. If leaders cannot do that work themselves, no AI model or governance tool will do it for them.

This is why I stand up an AI review board for the organizations I work with and host the leadership conversations that decide whether a company’s AI ambitions thrive or stall. The board itself matters less than what it provides: neutral ground, a regular cadence and an agenda that forces the hard issues into the open before a crisis forces them. If your organization has no venue like that, that absence is its own form of dysfunction. The cadence is what makes communication effective. Not easy. Effective.

Build the bond on purpose

You cannot framework your way to trust. But you can build it deliberately, and that is a leadership act, not a governance one. The partnership and stakeholdering skills that once looked like soft extras are now the core executive work. A few moves matter most:

• Set a standing contact rhythm with your counterpart before you need one, daily or near-daily, not quarterly
• Make decision rights and accountability explicit while it is calm, so no one improvises them mid-incident
• Translate security into business outcomes together, so the board hears one aligned voice

Build the relationship as deliberately as you would build any critical control, because that is what it is. If you cannot connect the partnership to outcomes the business actually feels, you have a friendship, not a performance lever.

A year after writing “The CISO On the Razor’s Edge,” I am even more convinced that strong leadership precedes effective governance and partnership precedes them both. This is the good news, not the hard news. The CIO and CISO who build real trust do not just reduce risk. They move faster than their competitors, because they spend no energy fighting each other. They earn the board’s confidence, because the board hears one clear voice. And they unlock the AI strategy everyone else is still struggling to govern, because they have already done the human work that makes governance hold.

That is the upside waiting on the other side of this relationship. AI will keep advancing. Governance will keep maturing. But the organizations that win the next decade will be the ones where two leaders decided the partnership was worth building before they needed it. Bill and Ralph knew it every day, weekends included. The edge is there for anyone willing to do the same.

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

I keep seeing a version of the same scene. A CEO has a question about AI. It is a real question, the kind that will shape where the company spends the next two years. The CEO does not bring it to the CIO. They bring it to a data leader two levels down, or to a vendor who presented at a conference, or to an AI specialist a board member recommended. The CIO finds out the strategy is forming when a slide shows up that they did not build. By then, the direction is already half-set, and the CIO is being asked to react to it rather than shape it.

I want to be precise about what is happening, because it is easy to misread. The CIO has not been removed from anything. Title intact, budget intact, seat at the table intact. What has changed is quieter. On one of the most consequential technology conversations the company will have this decade, the CIO is being routed around. The work still flows through them eventually. The thinking no longer starts with them.

I have watched this happen to capable people who would have given the CEO a better answer than the person who was asked. That is what makes it worth naming. This is not a competence gap. It is a positioning gap, and positioning gaps close in the wrong direction if you ignore them long enough.

How the routing actually starts

The routing does not begin with a decision to exclude anyone. It begins with a CEO who is anxious about AI and looking for someone who sounds certain. AI is moving fast enough that executives feel the pressure to have a point of view before they have earned one. That pressure usually arrives secondhand, from a board member or a peer on the golf course describing what is working at their company. So the CEO goes looking for someone who will confirm the answer they already want to hear, and they keep going back to whoever gives it to them.

Here is where many technology leaders lose the thread. For years, the safe posture in the CIO seat was measured caution. You raised the risks, you flagged the integration cost, you asked who owns the data and what the compliance exposure looks like. That posture built credibility in an era when the failure mode was moving too fast on technology nobody understood. With AI, the same posture reads as drag. A CEO who is being told by three vendors that “the future is already here” does not want to hear why they should slow down and be cautious. They hear caution as losing the race, and they go find a point of view somewhere else.

The data leaders, vendors and specialists who get the call are not necessarily more capable. They are more available with a confident answer. A vendor’s whole job is to arrive with conviction. A data scientist who has shipped one impressive model carries more apparent authority on AI, in that moment, than a CIO who runs the entire estate but talks about AI the way they talk about every other risk. The CEO is not weighing depth against depth. They are weighing the person who said yes against the person who said it depends.

Once that pattern sets, it compounds. The CEO who got a satisfying answer from the data leader goes back to the data leader. The vendor who shaped the first conversation gets invited into the second. Each loop the CIO is not in makes the next one easier to run without them. The org chart still says the CIO owns technology strategy. The actual conversation has relocated.

What it costs before anyone notices

The cost shows up late, which is exactly why it is dangerous. For a while nothing looks broken. The CIO is still delivering. The AI initiatives are still landing on their plate to execute. The damage is happening upstream, in the room where the bets get made, and the CIO is not in that room.

I have seen what arrives downstream when the strategy was set without the person who has to run it. A model gets championed that the data cannot actually support. A vendor commitment gets made that locks the company into an architecture the CIO would have flagged in the first meeting. An agent gets deployed inside a business unit, with executive blessing, and the CIO inherits accountability for it months later without ever having shaped how it was governed. The recent IBM finding that CIOs are increasingly held accountable for AI they do not fully control is the visible end of this. The invisible front end is the conversation the CIO was routed around, the one where the accountability got created in the first place.

What I find most corrosive is what it does to the CIO’s standing over time. Every initiative the CIO executes but did not shape reinforces a story about what the CIO is for. They become the person who runs the technology other people decided on. That is a fine description of an order taker and a poor description of a strategic leader, and CEOs do not promote, fund, or defend order takers when budgets tighten. The routing-around does not just cost the company a worse AI strategy. It quietly recasts the CIO as the implementer of everyone else’s thinking, and that recasting is hard to reverse once the executive team has internalized it.

What the leaders who stayed in the conversation did

The technology leaders I have watched hold their position on AI did one thing first. They stopped leading with caution and started leading with a point of view. Not a reckless one. A real, defensible position on where AI creates value in their specific business and where it does not, delivered with the same conviction the vendors bring, before the CEO went looking elsewhere for it. They made themselves the person with the clearest answer, which is the role the routing-around was filling with someone else.

That requires giving up a posture that felt safe for a long time. The CIOs who made the shift accepted that on AI, being right and cautious is worth less than being early and directional. They formed a view ahead of being asked. They walked into the CEO’s office with where we should place our AI bets and why, rather than waiting to be handed someone else’s bets to pressure-test. The difference is whether you are the author of the strategy or its editor, and CEOs route around editors.

They also changed how they talk about risk. Instead of presenting risk as the reason to slow down, they folded it into the recommendation. The data is not ready for that use case, so here is the use case where it is ready, and here is what we do in parallel to unlock the first one. That framing keeps the CIO inside the conversation as the person making AI happen responsibly, rather than the person standing outside it explaining why it is hard. Same expertise, opposite effect on whether the CEO keeps coming back.

None of this is about pushing the data leaders and specialists out. The strongest CIOs I know pulled those people closer and brought them into the room under their own framing, so that when the CEO wanted the specialist’s input, it arrived through the CIO rather than around them. They made themselves the orchestrator of the AI conversation instead of one of its casualties.

If you are a technology leader right now, the question worth sitting with is not whether you are good at AI. You probably are. The question is whether the most important AI conversations in your company are still starting with you, or whether you have quietly become the person they get handed to after the thinking is done. That answer is set in rooms you may not be in, and the only way to find out is to ask who your CEO called the last three times AI came up. If the answer is not you, the role is still yours. The conversation has already started leaving.

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

Organizations usually face the same questions concerning XLAs: What should we measure, who owns the data, how should incentives work, and how will this change provider behavior after signature.

There are no easy answers either, but after advising clients in MSP relationships with major providers, I’ve seen what works and what doesn’t. Successful XLA programs rarely start with massive transformation, nor rely on perfection before adding experience accountability to the contract.

Start with the right metrics

The first concern I hear is what to measure. MSPs often steer that discussion toward metrics already in their reporting stack. That’s a trap.

Unlike SLAs, which measure operational outputs, XLAs should focus on employee experience and business outcomes. The strongest programs start with three to five high-signal metrics tied to the employee journeys creating the most friction. More than that and the program loses focus before it gains traction.

I typically recommend starting with employee satisfaction scores, perceived lost productivity time, repeat incident rates, task completion success, and ease of getting support. Then focus early measurement on common employee experiences like service desk interactions, employee onboarding, application reliability, and device performance.

Trying to measure everything is understandable, but it’s also one of the fastest ways to stall an XLA program.

Precisely define roles and responsibilities

This is the part of XLA contract design where I spend the most time with clients, and it’s the part that major MSPs are most likely to leave vague if you let them. Accenture and TCS both have mature commercial teams skilled at agreeing to things in principle while avoiding specific accountability in writing. Don’t let that happen here.

Employee experience isn’t solely the vendor’s responsibility. It’s genuinely shared, which is a more productive framing than pure vendor accountability, but only if the split is clearly spelled out. This is what I’ve found works in practice.

Customer responsibilities

• Selecting tools and platforms
• Managing data infrastructure
• Sharing experience data openly with the provider
• Supporting internal improvement initiatives that the provider flags

Vendor responsibilities

• Running the measurement cadence
• Delivering monthly experience reporting
• Identifying and surfacing improvement opportunities from the data
• Executing operational improvements within agreed timelines

Without this level of specificity, XLA programs almost always become reporting exercises. The data gets collected, the scorecard gets presented, and nothing actually changes.

Build flexible targets

One of the biggest mistakes in XLA design is treating experience targets like traditional SLAs,  setting once at contract signing and left unchanged for years. Employee expectations, workforce patterns, and technology environments, after all, evolve constantly. A target that feels ambitious in year one may become meaningless by year three.

The strongest XLA contracts include formal reviews every three to six months to recalibrate targets, align with business priorities, and raise expectations as experience improves. This prevents providers from locking in easy wins and coasting. When providers resist review cycles, it’s often a sign they believe the targets can be met on autopilot, a red flag in any XLA program.

Use the right scoring method

One overlooked XLA best practice is how experience scores are calculated. Point-in-time scores can be distorted by outages, isolated incidents, or low survey participation, and providers sometimes exploit that volatility.

I advise clients to calculate official XLA scores using rolling two-month averages instead of snapshots. It creates a more stable and accurate view of experience trends, and makes operational timing games much harder. Most importantly, define the scoring methodology explicitly in the contract. Don’t leave it to be worked out operationally after signing.

Structure incentives carefully

Relying on penalty-only incentives is one of the most expensive XLA mistakes. On paper, the model is simple: miss the target, pay the penalty. In practice, it drives the wrong behavior. Providers focus on protecting themselves instead of improving employee experience, optimizing survey timing, and managing averages rather than solving problems collaboratively.

I’ve seen this repeatedly in Infosys, HCL, and TCS relationships. The strongest XLA structures combine risk and reward where providers earn meaningful upside for exceeding targets, innovating, and improving outcomes. Penalties still matter, especially in mature programs, but they can’t be the only lever otherwise the contract becomes another SLA model with better branding.

Define escalation processes

When experience scores fall below threshold, the contract needs to specify what happens next. This sounds obvious, but I’ve reviewed many service delivery measurement frameworks in clients’ incumbent MPS contracts that specify financial consequences without defining any collaborative process to address the underlying problem.

The escalation language I push clients to include specifies:

• a joint review process triggered when scores fall below threshold.
• root cause analysis expectations and timelines.
• remediation planning requirements with named owners on both sides.
• timelines for corrective action and progress reporting.

The framing matters as much as the mechanics. Escalation should be positioned as collaborative problem-solving, not blame assignment. Contracts that turn every missed score into a commercial dispute damage the relationship when provider engagement matters most. The best MSPs treat escalation as a shared diagnostic exercise, not a contractual confrontation.

Establish an operating rhythm

Signing the contract is the beginning, not the end. In my experience, the organizations that get the most out of XLA programs are those that build a disciplined operating cadence and stick to it. The ones that treat XLAs as a reporting exercise almost never see meaningful improvement.

This is the cadence I recommend:

Daily: Both parties maintain live dashboards showing experience trends, application performance, regional issues, and persona-specific insights to catch emerging issues.

Weekly: Customer and vendor teams hold focused working sessions to determine what improved experience this week, what hurt it, which remediation actions were completed, and what’s the priority for next week.

Monthly: Formal governance meetings to review experience scores, improvement actions, root cause discussions, and cross-functional issues that need escalation.

Biannually: Leadership steering meetings to assess overall experience performance, recalibrate targets, and align the XLA program with evolving business priorities to honestly evaluate whether or not the program is driving the outcomes the organization actually cares about.

Common mistakes organizations make

After working through XLA design and implementation with clients across their MSP relationships, the failure modes are predictable. Here’s what to watch for.

Setting targets before establishing a baseline
Rushing into targets before understanding your current state is one of the fastest ways to create disputes. Spend the first three to six months gathering baseline data, then negotiate targets based on evidence rather than guesswork.

Measuring too much
More metrics don’t create more insight. Frameworks with 20 data points rarely survive operational reality. Start focused and expand gradually.

Hiding the data
Transparency is foundational to XLAs. Providers who obscure poor scores, especially when controlling the measurement platform, undermine the entire model. Clients who weaponize the data create the same problem. Build mutual transparency obligations into the contract.

Over-relying on penalties
Penalty-only structures recreate legacy SLA behaviors. Balanced incentives drive better long-term outcomes.

Treating XLAs as static
Employee expectations, technology, and business priorities evolve constantly. Without formal review cycles, XLA programs quickly become irrelevant.

Start smaller than you think you need to

The organizations that get XLAs right are rarely the ones with the most sophisticated tooling. They’re the ones that stopped waiting for a perfect program and introduced real accountability into the contract with what they had.

The most effective starting points are often simple: agree on a focused set of experience metrics, establish a six-month review cycle, commit to shared visibility and data transparency, and create joint accountability for continuous improvement.

From there, maturity develops over time. Governance builds trust, data becomes more actionable, and targets evolve alongside business priorities. The relationship shifts from compliance management to outcome-driven partnership.

In my experience, the organizations that succeed are the ones that stopped accepting green scorecards at face value and demanded something more meaningful.

Today’s CIOs must master a complex balancing act of maintaining operational excellence while enabling AI experimentation, modernizing legacy environments while accelerating innovation, leading workforce transformation while maintaining culture, and communicating fluently across boards, business units, customers, and technical teams alike.

Few leaders understand this balancing act better than former Verizon CIO Jane Connell. Over her career, Connell has helped some of the world’s largest enterprises modernize operations, reduce complexity, and transform how technology enables business value at scale. As a 2026 CIO Hall of Fame inductee, she is widely respected not only for operational excellence and strategic vision but also for her commitment to mentoring, workforce transformation, and preparing the next generation of leaders for a rapidly changing future.

On a recent episode of the Tech Whisperers podcast, we unpacked Connell’s unconventional leadership story and the playbook that has shaped one of technology’s most impactful leaders. In this exclusive interview after the show, edited for length and clarity, Connell shares more lessons from her Hall of Fame journey and why she believes the future of technology leadership will depend less on org charts and more on curiosity, credibility, and human connection.

Dan Roberts: When you think about preparing the next generation of technology leaders, what capabilities or mindsets do you believe will matter most in this next era?

Jane Connell: One is curiosity, or what I call the “why” factor: What do we need to do and why do we need to do it? It’s having a mindset of unlocking the art of the possible. You must be comfortable with what you know, what you don’t know, and asking the question why, because in this era of AI and where technology is going, it’s not about automating things you know; it’s about what you don’t already know, and what that unlocks. AI creates patterns and opportunities and re-engineers through its own intelligence, so there has to be a lot of instinct involved, and you’re going to have to understand and learn what it’s telling you.

I’m on the board of Rutgers, and one of the conversations we’re in with future leaders in education is that you don’t have those entry-level jobs anymore. They’re going to be AI. But those were building blocks for us. We came up the ranks and did those jobs, and that created the knowledge. [Future leaders are] not going to have that, so how do you create the foundation of knowledge — which is that art of asking why or what — to question if the bots or the patterns are biased or wrong. You’re not going to have the experience to rely on and say, “That’s wrong; I know that’s wrong because I did those. I know how this operates.”

Second is having humility and being comfortable in your skin — that you don’t know everything, but you’re going to learn it. You’re going to involve yourself with people. It’s about workforce structure, not organizational structure. Who do you need to talk to, and what do you have to find out?

I also believe followership is going to be huge, because the way work gets done is not hierarchical. It’s going to be engineered based on the process and AI. You have to create followership of people working together, and they’ve got to want to work with you. This isn’t going be “you work for me, do as I say.” Followership is going to be a key skill for influencing and organically having that kind of impact, versus someone with authority.

With that is the accountability to have high integrity, be credible, and be a person someone would trust. Because all this is going to break down the hierarchy of authority, you have to bring that human side and be a really good leader, which means people want to follow you, they trust you, they want to work with you, and they know you’re going to take them to a better place.

One recurring theme throughout your career has been your ability to bridge deep technology expertise with strong business acumen. Why is that combination becoming even more critical in the age of AI and digital transformation?

You can’t impact anything tech-alone. It all resides on having business acumen and then having the technical ability to know how to use tech to solve the problem, not the other way around.

At the root of all this is every company’s Achilles’ heel: the data. Access to data has been a privilege — those who have it, those who don’t. Now you’re bringing structured and unstructured [data] together for these AI models to work, and that’s a new skill set that requires you to know the business inside and outside.

You also have to stay externally relevant and know where innovation is coming from. And you’re going to need to know how to architect that into the way your company goes to market, which requires you to know the business processes, how it runs, and how it could run.

That’s the role of leaders moving forward, immersing yourself in the problems the business needs to solve. There’s no boundaries there. It’s not what department you report in and what process you own. It’s seamless. That’s the duality people need to command and grow into.

Looking back on a career that spans multiple industries with different operating models, cultures, and regulatory environments, what were some of the most important calculated risks you took in terms of your growth?

There were two pivotal moments in my career that were the biggest risks but probably my biggest gains in growth. One was when I went into a full-time tech role and ran infrastructure. I was a fish out of water, and not the likely successor. Part of the reason I did it goes back to a something we talked about on the podcast: Well, why not me? And I want more. That’s just my tenacity.

It was during the dot-com days of the late 90s, early 2000s. It didn’t matter if you were the CEO or a board director, if you didn’t know tech and you didn’t understand how to wield it, you were never going to be successful. I knew that no matter what job I may want in the future, I had to know tech. So it was a calculated decision: I’m going to jump into tech.

Some very senior supply chain leaders who controlled my career told me, “You’re going to fail, and I’ll have a safety net for you when you come back.” Well, I didn’t fail and I never went back. That pressure was there, but I knew why I was doing it. This wasn’t just a job for ego’s sake. This was, I have to know tech. The future is tech. It’s kind of like AI now.

The other pivotal moment was changing industries. I left Johnson & Johnson at a great time. We had gone through a huge transformation, started our global services organization, and the perfect moment happened for me to retire early there. I didn’t know what I wanted to do. It was the first time I took a break in my career to let the world come to me instead of me planning it. Do I want to open a business? Do I want to consult? Do I want to stay retired? I was fortunate enough that I could, but I got bored.

The financial industry wasn’t on my radar. Coming out of healthcare, with the purpose and the connection with saving lives, helping people, it’s easy to connect to. Financial wasn’t, for me. But one of the executive search firms said to me, when you interview, the biggest question hanging over your head is going to be, could you be successful elsewhere because you grew up in J&J. You had advocates, you had influence, you knew the industry. It’s like your deck was stacked for you. Could you do all that when you’re a nobody coming off the street?

So when the CIO role opened at State Street, I interviewed — and talk about being your authentic self. I had already done all this transformation, I already knew the outcomes, I knew everything I did was always enterprise and always end-to-end transformation. And because I wasn’t really vying for the job, I was having this conversation with the CFO and saying, “Here’s what your organization is lacking, here’s the noise you’re going to hear, do you really have the appetite for it?” And “I’d like talk to the COO and see if they’re ready to hear this about the value chain. I may not know your problem yet, but I guarantee it’s one of these three things.”

I was testing their advocacy of, do you really want to transform? Are you ready? Because you have to own this. I can’t take accountabilities for your organizations. I can help you get there. I’m an enabler for you, but you have to own it. And it was a very different interview. By the end of it, I loved Ron [O’Hanley, State Street Chairman and CEO] and his whole team. I took the job on the leadership and the person more than the industry, and it was very successful.

I followed the same recipe when I went to Verizon. Those were big growing moments. They were risky, they were very uncomfortable, but it was the biggest growth that I’ve ever had.

Whether it’s a tough message to the C-suite, a difficult conversation with peers, or helping teams make sense of uncertainty and change, you tell people the truth in a way they can hear it. How can other leaders develop that ability to take people on the journey, especially when the message isn’t easy?

Skirting a problem is not the way to solve it. I’ve never been the person to say what you want to hear. I’ll tell you how you get there, and I’ll get you the results you want, but I’m going to be super honest because I want to manage the expectations of what we have to achieve.

What I’ve learned as a leader is to take accountability. Say what you’re going to do, then do it, and if you hit a roadblock, be the first to call it. That gets you access, because people see it as a calculated risk. Anybody in the C-suite has resources and budget, but the earlier you signal and don’t waste money and resources, the more access to people and resources you will have.

The greatest lesson I learned from one of the leaders in my path was: If you can’t say it in an elevator, and you can’t say it on one slide, you’re talking too much. So, think about it as one slide: What is it you need? What are you going to achieve? What are the risks? What are you taking accountability for? How will you measure it? It doesn’t matter what the message is when you can be that succinct. You’ve got them laser-focused on what it is. You gave them just enough of the periphery to know how you got there, and then it’s their belief in you that you can do it if they give you the money and resources, because that’s what you’re looking for.

It sounds so simple but putting things together succinctly is hard work. You have to take all the unnecessary noise out, and keep the conversation focused. You don’t want their mind wandering, wondering where is she going, or what are they doing? Give it to them upfront and tell them what you need.

You’ve spoken about entering corporate environments early in your career feeling intimidated by people with more traditional credentials or educational backgrounds. What advice can you give rising leaders about battling imposter syndrome?

Take the time to figure out what makes you uncomfortable, what makes you feel like an imposter, or what in that meeting you dread going in where you’re not acting like yourself. Are you more quiet than usual? Are you not asking the question you’d normally ask? Figure out what those issues are, and then address the things that make you uncomfortable. I went to college later because that bothered me. Those credentials do matter. So I addressed it and got my degrees and certifications.

The other thing is to find people you trust, people whose opinion you respect, and bring them on the inside of what you’re working on. Maybe it’s dealing with a difficult business partner. You may not particularly want to be friends with them, but you’re going to have to work with them. Find the people that work effectively with them. You do this with high integrity — this is not about talking about that person — but find the allies that work with them. Nine times out of ten, they feel the way you do, but they found a way to work with the person. Pick their brain. Bring them in the fold and say, “I need this alliance. I can’t get there, and quite frankly, I know I’m resisting because maybe I just don’t like them. How did you get there?”

People are generous. Ask their opinion, ask how they’re showing up. “Am I creating the trigger? Is there something I’m doing in that meeting or in that room that I’m not coming out with a decision or whatever I needed?”

The greatest gift is feedback. There’s feedback you do something with, and there’s feedback you don’t, but either way, it’s a gift. Somebody’s giving it to you. It’s not personal; it’s business. And those things really help build your confidence and leadership style.

In an era increasingly shaped by automation and disruption, Jane Connell believes the most enduring competitive advantage may come from something deeply human: the ability to inspire confidence, curiosity, resilience, and possibility in others. For more advice from this Hall of Fame CIO, tune in to the Tech Whisperers podcast.

See also:

• Mastering the chess of IT leadership today
• Developing a customer-first culture for IT
• Coherence: Where leadership and AI success intersect

Every major sporting and pop culture event creates a familiar conversation among employers: How much productivity will be lost?

This year’s FIFA World Cup was no exception. Before the tournament began, UKG research found that 37% of employees globally planned to adjust their work schedules during the tournament. Some intended to take time off. Others expected to arrive late, leave early, or otherwise alter their work patterns. The estimated global productivity loss from presentism and absenteeism ranged from $17 billion (UKG) to an astonishing $30.2B (Challenger, Gray & Christmas).

As tournament play began, viewership surged across broadcast and streaming platforms: FOX Sports reported record audiences, while Peacock and Telemundo viewership increased more than 230% compared to the 2022 tournament through the first 12 matches.

Those numbers are interesting, but, as a CIO, I think they point to a more important question: Why do events like this still disrupt organizations in the first place?

The World Cup is unique because it is one of the few workforce disruptions we can see coming years in advance, and the tournament game schedule is a blend of predictable (pool play) and unpredictable (knockout stage). We know employees will modify schedules. We know customer-demand patterns will shift. We know some industries will experience staffing challenges while others see increased activity.

None of this is a surprise.

That is what makes the UKG survey results so interesting. They reveal a broader truth: Even when change is predictable, many organizations still struggle to prepare for it effectively.

The issue is rarely a lack of data. Most organizations have access to workforce, operational, financial and customer information. The challenge is that those signals often live in disconnected systems, making it difficult to translate information into action before problems emerge.

In my experience, this is where many operating models begin to break down.

Organizations need to optimize operations for adaptability

For years, organizations optimized for efficiency, standardization and predictability. Those priorities helped businesses scale, but they also created processes that can struggle when conditions change. Increasingly, the ability to adapt is becoming just as important as the ability to execute efficiently.

Adaptability is often discussed in the context of unexpected events, but many operational challenges are highly predictable. Major sporting events, seasonal demand fluctuations, weather patterns, holiday periods and workforce trends all generate signals organizations can anticipate.

The question is not whether the information exists. The question is whether organizations can connect workforce, operational, financial and customer data in a way that allows leaders to act on those signals before they become problems.

This is where technology leaders have an important role to play.

Access to real-time insights leads to agile decision making

As CIOs, we are increasingly responsible for creating the conditions that allow organizations to sense changes, make decisions and respond quickly. That requires more than modern technology. It requires connected data, simplified processes and operating models designed to support faster decision making across the business.

When workforce planning, scheduling, labor costs, customer demand and operational performance exist in separate systems, organizations spend their time reconciling information. When those signals are connected, they can spend their time making decisions.

This is also where AI has the potential to create significant value. Much of today’s conversation focuses on productivity gains, but I believe the larger opportunity is responsiveness.

Organizations generate millions of operational signals every day. AI can help process those signals, identify patterns, surface risks and recommend actions faster than traditional approaches. The value is not simply producing more insights. The value is helping organizations shorten the distance between awareness and action.

When AI is combined with connected data and embedded into operational workflows, it can help leaders respond to changing conditions with greater speed and confidence. That is ultimately what organizations need: not perfect predictions, but the ability to make better decisions faster.

Three questions to ask right now to test operational effectiveness

For CIOs, the World Cup offers an interesting stress test. It creates a visible, measurable change in workforce behavior, but the lessons extend far beyond a sporting event. I think there are three questions every technology leader should consider:

1. Can we identify operational changes as they happen, or only after they appear in reports?
2. Can our teams make decisions quickly when conditions change?
3. Are our systems helping employees adapt, or creating additional complexity when flexibility is required?

The answers often reveal more about organizational readiness than any technology roadmap.

Operational excellence means moving from information to action

Eventually, the tournament will end. The broader challenge it exposes will remain. Workforce expectations will continue to evolve. Economic conditions will continue to change. New technologies will continue to reshape how organizations operate.

Organizations cannot predict every disruption. But they should be able to prepare for the ones they can see coming.

The World Cup is a reminder that operational excellence is not just about responding to change. It is about recognizing signals early, connecting information across the business, and acting before predictable challenges become operational problems.

In my experience, the companies that do this well are not necessarily the ones with the most detailed plans. They are the ones with the clearest visibility, the simplest operating models and the ability to turn information into action quickly. Increasingly, that is what modern operational excellence looks like.

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

In many teams, dependency security still happens after the most important trust decision has already been made. A package is added, the lockfile changes, the feature moves forward, and only later does the pipeline ask whether the application should have trusted that code in the first place.

That workflow made sense when dependency security was mostly viewed as a compliance check. Run a scanner. Produce a report. Fail the build if the risk crosses a threshold. Let someone decide what to do next.

But the modern Node.js ecosystem has changed. The risk no longer begins in CI. It begins earlier, at the moment a developer decides to trust a package.

That is why the next phase of Node.js security cannot be limited to better pipeline enforcement. It has to move closer to the developer workflow, before dependencies become part of the application, before a pull request becomes someone else’s problem, and before a build log becomes the first moment anyone realizes that something important has changed.

Every install is a trust decision

The npm ecosystem is built on trust at an enormous scale. Every install is a trust decision. Every transitive dependency extends that decision to maintainers, packages, scripts, release pipelines, and infrastructure the application team may never inspect directly. This model gave JavaScript its incredible velocity. It also created one of its deepest security weaknesses.

Recent npm supply chain incidents show why this matters. In March 2026, malicious Axios versions were published to npm through a compromised maintainer account. Microsoft later described how those packages attempted to retrieve a second-stage payload during installation. In May 2026, TanStack published a postmortem explaining that 84 malicious versions across 42 npm packages were published through a legitimate release pipeline after an attacker abused GitHub Actions behavior and runner trust boundaries. Security researchers also reported broader Mini Shai-Hulud activity across the npm ecosystem in May, including hundreds of malicious package versions published in a short period.

Not every one of these incidents is a traditional CVE. Some are malicious package compromises. Some involve CI/CD credential theft. Some involve maintainer or pipeline compromise. But they all point to the same larger issue: dependency risk is now part of everyday software engineering, not something that can be pushed entirely to a downstream security process.

The problem is not the scanner. It is the handoff.

Ubiquitous dependency risk changes what developers need from security tooling.

The problem is not that teams lack scanners. Many organizations already run security checks in CI. The problem is that the output of those checks often arrives too late and speaks the wrong language for the person expected to act on it.

A pull request fails. A long vulnerability report appears. The report may be technically accurate. It may contain the right advisory IDs, affected versions, dependency paths, severity labels, and references. But the developer still has to comb through the output and reconstruct the actual engineering decision from the evidence provided.

That reconstruction is rarely simple. The developer has to understand which package introduced the issue, whether the vulnerable dependency is direct or transitive, whether the fix is actually within the application team’s control, and whether the recommended version is safe to adopt. They also have to determine whether the dependency is used in production or only during development, whether the update might break the application, and whether the fix belongs in the current pull request or requires separate engineering work.

That uncertainty is where security work often slows. The scanner has detected risk, but the developer has not been given a clear path from detection to decision.

Security needs to move closer to engineering judgment

This is not a criticism of scanning. Scanning is necessary. CI enforcement is necessary. Centralized security platforms are necessary. But they are not sufficient, because they often operate after the trust decision has already been made.

The real architectural question is this: where should dependency security live in the software development life cycle?

If it lives only in CI, it becomes an interruption. If it lives only in dashboards, it becomes someone else’s queue. If it lives only in periodic audits, it becomes a backlog. But if it lives at the moment a dependency is introduced, upgraded, or reviewed, it becomes part of engineering judgment.

That shift matters because modern JavaScript development is becoming faster than human review can comfortably handle. Developers no longer add dependencies only by reading documentation and choosing libraries manually. AI coding assistants can suggest packages, generate install commands, modify package files, and rewrite code around third-party APIs. Agentic development workflows can make dependency changes as part of broader automated refactors.

AI makes the trust boundary harder to see

That acceleration is useful. It also changes the risk model.

When a human developer adds one package, the team can review the decision. When a coding agent modifies several dependencies as part of a larger task, the trust boundary becomes harder to see. The package file changes, the lockfile changes, the application still runs, and the pull request may look like a normal feature update. But the real security question may be hidden inside the dependency graph.

This is where Node.js teams need a different mental model.

Dependency adoption should not be treated as a small implementation detail. It should be treated as an architectural decision with security consequences. A new package is not just code reuse. It is a new trust relationship.

That does not mean developers should stop using packages. The npm ecosystem exists because reuse works. Most teams cannot and should not build everything themselves. But convenience should not erase visibility. If a dependency becomes part of the application, the team should understand what was added, what changed in the lockfile, what risk comes with it, and what action is available if something is wrong.

Developers need confidence, not just reports

The same applies to remediation. Developers do not want a wall of vulnerability text. They want confidence. They want to know what action reduces risk, what version should be targeted, whether the change is safe, and whether the fix is actually under their control. A vulnerability report that leaves the developer uncertain may satisfy a process requirement, but it does not necessarily improve the speed or quality of remediation.

That is the gap many teams feel today. Security tools are often very good at saying, “There is a problem.” They are less consistent at helping the developer answer, “What should I do next?”

This is the broader problem I have been exploring through CVE Lite CLI, now an OWASP project. The point is not that one command-line tool solves Node.js security. It does not. The larger idea is that dependency security has to move closer to the developer’s moment of decision. A useful developer-side security workflow should not merely report that risk exists. It should help the engineer understand whether the issue is in their control, what change is available, and whether the fix actually reduces risk.

The future is decision support, not just detection

That distinction is important. The future of Node.js security is not just more detection. It is better decision support.

Security teams still need policy. Enterprises still need dashboards. CI still needs gates. But developers need something more immediate: a way to reason about dependency risk while the code is still fresh in their mind. That is where the ecosystem has to evolve.

We already accept that testing belongs close to development. We accept that linting belongs close to development. We accept that formatting, type checking, and build validation belong close to development. Dependency security should follow the same path. It should not be treated as a mysterious report that appears at the end of the process. It should become part of the normal rhythm of engineering work.

Before adding a package, developers should understand what trust relationship is being introduced. Before accepting an AI-generated dependency change, they should inspect what entered the graph. Before merging a pull request, teams should understand whether a vulnerability is direct, transitive, fixable, or blocked by another package. And before treating a CI failure as noise, organizations should ask whether the workflow is giving developers enough information to act confidently.

Node.js security will be won, or lost, before CI runs

The Node.js ecosystem will not become safer by slowing down all development. That is unrealistic. It will become safer when security work is placed where developers can actually use it.

The next generation of Node.js security will be won or lost before CI runs.

It will be won when dependency decisions are still small enough to understand, fresh enough to review, and close enough to the developer for action to feel natural.

That is the shift teams need to make now. Not from insecure to secure in one step, but from late detection to earlier judgment. From vulnerability reports to engineering decisions. From trusting packages by habit to understanding trust as part of software design.

Every day this past week I did something I suspect millions of other people also did: I stared at an LLM model picker and wondered which one I was supposed to want.

OpenAI just released ⁠GPT-5.6 Sol, Terra, and Luna. Sol is the flagship. Terra offers much of its intelligence for less money. Luna is cheaper still. Anthropic released ⁠Claude Sonnet 5 at the end of June and Opus 4.8 the month prior, with a little Fable 5 emerging in between. Meanwhile, Google, which seemed to be winning the model wars a few months ago, is now getting shade from Gergely Orosz, who ⁠argues that Gemini has slipped outside the top tier for software development and has been out of the major model release game for eons (May 19).

Perhaps Orosz is right. Perhaps he’ll be wrong again in six weeks. Honestly, it’s exhausting.

I use ChatGPT and Claude constantly and still have no principled idea which model to choose most of the time. I tend to click whatever looks like the biggest, most expensive option because I don’t know what I’m giving up by choosing something smaller. “Instant” sounds dangerously unserious. “Thinking” sounds expensive but powerful.

A quick survey of my LinkedIn crowd suggests others also feel my “WHICH MODEL???” pain. More importantly, I suspect most enterprises do, too.

A model doesn’t rot

Before getting carried away, however, it’s worth considering whether any of this model churn actually matters. After all, a model doesn’t rot. The model an enterprise put into production in March performs just as well in July as it did when the company selected it. “Obsolete” generally means that something better now exists, not that the deployed model suddenly stopped summarizing insurance claims or classifying support tickets. (In other words, once you have something working, the idea that “but maybe Opus 200.2 is better!” is really a FOMO problem, not a performance issue.)

Most enterprise workloads don’t live at the frontier anyway. Extraction, summarization, classification, document comparison, and customer-service assistance often work perfectly well with smaller, cheaper models. OpenAI’s own pitch for the trio of GPT-5.6 models isn’t simply that Sol is better. It’s that ⁠Terra and Luna deliver different combinations of intelligence, latency, and cost. Luna, the cheapest tier, nearly matches the previous generation’s peak performance at less than half the estimated cost, according to OpenAI.

The practical question, of course, is where to start. An enterprise can’t test every model, every reasoning setting, and every price tier before doing any work. So here’s my advice (which I don’t follow in my own work, but I’m not defining enterprise strategy and can be a little price-insensitive). Start with the cheapest credible model that appears capable of the task. Give it a representative set of real examples and, before you start testing, define what counts as good enough. If it passes, stop. If it fails, move up a tier or try a model with strengths better suited to the work.

That sounds almost offensively simple, but it reverses the way many people, including me, use these products. We start with the biggest model because we’re afraid of what we might lose. Enterprises should start lower and require evidence before paying for more intelligence.

There are exceptions, of course. For genuinely difficult work, such as autonomous coding, complex research, or high-stakes reasoning, beginning with a frontier model may save time. But even then, the goal should be to establish a quality ceiling, then test whether a cheaper model can meet it. It’s changing the question from “which model is best?” to “what is the least expensive model that reliably clears the bar for this job?”

For many workloads, that price improvement matters more than a few extra benchmark points. ⁠As I argued back in 2023, following AI hype doesn’t help anyone. If your model strategy depends on whichever benchmark screenshot is circulating on X this week, you don’t have a strategy. Not a viable one, anyway. Pick a model and ignore the noise.

Except, of course, when that noise suggests a serious signal.

Sometimes better really is better

Frontier improvements aren’t always incremental, making it advantageous to consider an upgrade. Coding is the obvious example. There’s a significant difference between a model that suggests the next few lines of code and one that can inspect a repository, plan a change, use tools, run tests, discover its own mistakes, and keep working for an extended period. That isn’t merely a nicer autocomplete experience. It can reorganize a development workflow.

This is why enterprises can’t simply standardize on an 18-month-old model and declare victory. In some areas, particularly software development and other agentic work, better models can unlock compounding productivity. A model that reliably completes 80% of a bounded task rather than 50% may justify an entirely different division of labor between humans and machines.

Still, that upgrade isn’t free.

Models differ in how they interpret instructions, call tools, manage context, refuse requests, and fail. Prompts and scaffolding tuned for one model can regress when moved to another. Or costs can explode. As one of my Oracle colleagues discovered just this week, running the same tasks in GPT 5.6 was orders of magnitude more expensive than 5.5. The API change may be trivial, but the revalidation and implications are not.

This leaves enterprises caught between two bad options. They can freeze and potentially miss out on meaningful improvements or chase every release and repeatedly test production systems on faith. What to do?

Stop making model bets

The answer is to stop making LLM bets and start making job-to-be-done bets. Stop asking which model is fastest. Instead, figure out what work you are trying to improve. What does a good result look like? How much latency and cost can the workflow tolerate? How wrong can it be before a human must intervene? Once those questions have answers, model selection becomes less opaque.

A difficult code migration may justify GPT-5.6 Sol or Claude Sonnet 5. A repetitive classification task may work just as well with Luna or another smaller model. A regulated workflow may require a model or deployment option that offers particular data controls. Sometimes the correct model is no LLM at all, like when I’m writing this post. Sorry, AI vendors! (At least you won’t get blamed for my mistakes.)

This is where evaluations become the center of enterprise AI strategy. ⁠As I’ve said before, most companies don’t have an AI quality problem so much as an AI measurement problem. Hence, a private evaluation suite built from real company work is the only leaderboard that matters. Does the new model materially improve quality? If so, use it! Does it reduce cost or latency? Again, that’s your free pass to adoption. Does the improvement justify the expense and effort of revalidation? If yes, continue.

Make model releases boring

As important as the model is, keep in mind that AI success always comes back to your company’s data, your company’s workflows, your company’s integrations, etc. That’s the ⁠dull reality behind sexy AI. Retrieval, memory, governance, data quality, observability, and feedback loops aren’t as exciting as a new model launch, but they’re what ultimately make AI truly work.

Again, when it’s time to consider something new, the principle should be to default to the least expensive model that reliably passes your evaluations. Only escalate harder tasks to more capable models when measurement shows that the premium pays. Tip: Make this invisible to employees so that the system routes to the best model for a particular prompt. As dbt Labs’ Jon Lewis expresses it, “The best model is ‘Auto’ and I won’t hear anyone say otherwise.” OpenAI’s own ⁠migration guidance recommends testing models on representative tasks, including trying a lower reasoning level rather than automatically cranking everything to the maximum.

As for me, I’ll probably keep clicking the shiniest option. I don’t have a formal evaluation suite for InfoWorld columns, and the marginal cost is a subscription I already pay. Enterprises don’t get that excuse.

If you just read the headlines, it would seem as if AI is now writing all of the world’s code and powering every application businesses run on.

That’s far from true. Just 4 of 33 AI pilots reach production, according to IDC Research — leaving legacy applications still fueling the wheels of commerce. This “silent majority” represents trillions of dollars spent each year on building, maintaining, testing, validating and monitoring legacy applications.

These applications won’t be replaced overnight. Companies and organizations depend on their predictability. The 60-plus-year-old COBOL programming language remains the backbone of banking software for good reason: it is extraordinarily efficient at processing massive transaction volumes with precision. Furthermore, do you want your bank revolutionizing how they manage your money? Probably not.

So, while AI investment continues to build inside the software development lifecycle (SDLC), it isn’t instantly rendering older software obsolete. What it will do is steadily enable easier tweaking, updating and testing of legacy applications — and in some cases, full migrations to modern platforms. And really, this isn’t a new phenomenon. Businesses have always looked to wring more efficiency and profit from existing products through intelligent prioritization.

The argument then is that CIOs and CTOs can take a proactive look at their legacy application portfolios to determine which ones, if any, should migrate sooner. Five considerations can help guide that decision.

Before replacing legacy apps with AI, ask these 5 important questions

1. Does the legacy application still work?

Is its utility still there? Customers often appreciate the consistency of legacy applications. They’re reliable, predictable and well understood. Don’t fix what isn’t broken. Another way to think about this is the degree to which the technical approach of your legacy application is still viable. It’s pretty much a guarantee nowadays in software that an application built one way, with some set of technologies, would be built a totally different way just two to three years later. There is no avoiding that, but what you want to avoid is investing further into a technical approach powering a legacy application that has been completely replaced with new software or a technical approach, especially if it is 10x better across the vectors of software development (latency, cost, accuracy).

2. Does it still make financial sense?

Running a system over a long period amortizes costs significantly. Even as growth rates slow or plateau, it can still be less expensive to let legacy applications run than to overhaul them. Another way to think about this is: how viable is my customer base in the near-term and the long-term? If you anticipate modest—or even flat—earnings growth for your product, then that’s an indicator that it’s possibly worth optimizing your development processes with AI. Where it’s probably not worth investing is when you have no confidence in your future earnings, whether that’s due to the customer base shrinking or commoditization or something else.

3. Can you integrate AI into existing workflows?

A significant portion of upcoming software development lifecycle work will focus on refactoring applications to be more AI-native. Some legacy applications may be strong candidates for a full AI rebuild, while others are better positioned for an AI add-on. Gartner research from 2025 found that only 28% of AI use cases in infrastructure and operations fully succeeded.

Among those that did, success was attributed primarily to integrating AI into existing workflows and systems. “As AI becomes part of day‑to‑day operations, it boosts adoption and creates visible impact within the organization,” Gartner states.

It’s important to keep in mind the distinction between using AI to optimize an existing process or workflow within your application, versus powering a workflow or feature with AI. The former approach is more palatable for legacy applications because it generally doesn’t change the cost profile of running that application. In the latter case, if you’re introducing an AI-powered module into the application, you’re generally going to incur inference costs at runtime, and they are an order of magnitude more expensive for today’s frontier models than base compute.

4. Do you have documented processes for maintaining legacy applications?

If so, you’ll more quickly identify where AI can optimize. The more coherent, organized and detailed processes are, the faster AI can find its footing and drive tangible efficiency gains. If documentation is lacking, start there. Keep detailed instructions and workflows for how you do things. Consistency matters. Don’t do things by heart. Don’t approach tasks casually, and don’t do things differently each time. The more uniform your process, the more easily you can insert AI into discrete steps and achieve efficiencies without disrupting the broader software development lifecycle. The organization in the most precarious position is the one managing legacy applications with no documented process for doing so.

5. Can you prioritize?

Making a change to a piece of legacy software might involve 20 or more steps. Only one or two of those steps may be clear candidates for AI-driven optimization. Identifying and prioritizing those opportunities will help you realize early wins and build the case for broader return on investment. Also, not all candidates for optimization make sense in light of broader financial and operational constraints. As always, prioritize ruthlessly in favor of ROI—bang for your buck. If your team has been struggling to operate a particular part of your system due to a lack of expertise or time, you might consider using AI to buttress the maintenance of that component. Having AI own that part of the workflow might unlock big time savings—or it might erode crucial domain knowledge that your team used to possess through repetition. There is no one-size-fits-all; think through the second-order effects.

Adding AI in testing in the SDLC

Beyond coding and application development, AI is opening new possibilities in how we test software. As leaders examine processes and look for places to insert AI, testing is often a natural entry point. There has been substantial innovation here, including new autonomous AI-driven testing solutions, those that have been enhanced with AI, and hybrid approaches that blend both. Each organization will be at a different place in its AI journey. Testing solutions exist to meet everyone where they are. Also, the state of applications will help determine which approach fits best—and when it fits as you evolve applications.

Of course, there is some substance to the AI hype around how much code AI will write and how many applications it is already creating faster than ever. But one school of thought is that AI’s biggest economic impact will be in the creation of massive new markets and industries rather than in the complete displacement of existing industries. Regardless of how far AI takes us through the universe, it’ll take some time and it’ll be bankrolled by the trillions of dollars of existing products and industries that we depend on every day.

That’s all good news for legacy players, but no one can afford to stay still. AI capabilities are advancing rapidly. Make it a habit to revisit legacy applications and workflows regularly. The right moment to introduce AI will keep shifting, and staying ahead of it is a competitive advantage.

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

When people hear the term artificial intelligence, they usually think of chatbots or data analysis. But at BMW’s Spartanburg plant in the US, AI is now getting hands, legs, and eyes. Under the term physical AI, the automaker is integrating the new humanoid AI robt Figure 03 into its production logistics.

The move comes as no surprise: For almost a year, BMW had the predecessor (Figure 02) welding body parts for more than 30,000 vehicles. The conclusion of this practical test: The machines can precisely perform monotonous, heavy tasks. Now the technology is leaving the testing phase and moving to where things get highly complex: logistics.

The task: Transform chaos into order

While its predecessor simply lifted sheets of metal, the further enhanced Figure 03 has to solve cognitive and tactile tasks. In logistics, it picks unsorted components from large boxes and sorts them into carts in the exact required order. Automated transport systems then take over, carrying them to the assembly line.

To achieve this, the manufacturer has upgraded Figure AI. The new robot has:

• Cameras and tactile sensors directly in the palms of the hands for greater sensitivity
• Audio functions for true speech-to-speech communication in the factory hall
• Wireless charging for continuous, autonomous operation
• Softer components to increase safety for human colleagues

At first glance, a humanoid robot might seem like a project solely for the production manager. That’s a misconception. This use case is relevant for everyone, and is highly relevant for CIOs. Figure 03 is ultimately nothing other than a highly complex, mobile edge client that has to process large amounts of data (video, audio, sensor data) locally and in real-time.

BMW AG

BMW is demonstrating in Spartanburg that such a robot works, but only in a fully digitized ecosystem like an automotive plant. This means that the IT department is the enabler for the production environment of the future.

1. Virtual twins: Even before the first robot touches a box, BMW simulates Hall 52 and all movement sequences in a 3D “Virtual Factory.” IT provides the planning basis.
2. AI Quality Control (AIQX): Error detection is performed using cameras and microphones along the production line. The algorithms perform visual and audible checks and send the feedback directly to the smart devices of human colleagues.
3. Infrastructure scaling: When robots communicate via voice, charge wirelessly, and interact with autonomous transporters, the WLAN, 5G, and network backbone in the factory must have low latency and be fail-safe.

On the one hand, the humanoid robot relieves BMW factory workers of physically demanding work; on the other hand, it forces the IT department to merge traditional IT infrastructure and factory technology (OT). “Physical AI” has thus arrived in everyday industrial practice.

If you spend enough time in Silicon Valley AI circles, you’ll hear the same message over and over again: AI needs context.

The statement is broadly true. The problem is that “context” has become one of the least precise terms in the industry.

Depending on who is using it, context can mean documents, dashboards, reports, metadata, business rules, policies, transaction histories, CRM records, knowledge bases or institutional expertise. The word has become a catch-all for virtually any information that might be made available to a model.

As a result, many organizations have started treating context as a volume problem. Conversations quickly turn to larger context windows, additional data sources and broader system access, while far less attention goes toward determining whether that information actually improves the quality of the outcome.

What we’re seeing in practice suggests a different way of thinking about the problem. The organizations making the most progress with enterprise AI are not necessarily the ones exposing the largest amount of information to their systems. They are the ones spending the most time understanding which information should influence a decision, which information should not and how to ensure that business logic is applied consistently.

That distinction matters because the industry is beginning to repeat a mistake enterprises already made once before.

Context has become the new ‘big data’

For much of the last two decades, organizations operated under the assumption that collecting more data would naturally produce better decisions. Massive investments were made in data warehouses, reporting platforms, analytics systems and business intelligence tools. Those investments created tremendous value, but they also exposed an important reality: Collecting information and creating clarity are not the same thing.

Today, AI is heading down a similar path.

Many enterprise AI projects measure progress by counting how much information a model can access. More documents become better than fewer documents. More systems become better than fewer systems. Larger context windows become better than smaller ones. The conversation often assumes that quantity and quality move together.

Well, they don’t.

According to Salesforce research, only 35% of business leaders say they are completely satisfied with their organization’s ability to use data effectively despite years of investment in data infrastructure and analytics. Enterprises learned long ago that information alone does not create understanding. The same lesson applies to AI.

When a model gains access to five versions of the same metric, conflicting definitions of a business process or documentation that has not been updated in years, it does not magically resolve those inconsistencies. It consumes them. More context can just as easily increase ambiguity as reduce it.

Simply exposing more information to a model does not guarantee better outcomes. What matters is whether the information available to the system helps it make the right decision at the right time.

Most AI failures are actually context failures

One of the more interesting things we’ve observed over the past year is how many AI projects are blamed for problems that have very little to do with AI.

The model answers a question incorrectly, and the immediate assumption is that the model failed. In reality, the underlying issue often sits elsewhere. The organization may have multiple definitions of the metric being requested. Customer information may exist across several systems with conflicting values. Business rules may be documented in one location, partially implemented in another and understood differently by different teams.

In many deployments, the issue is not that the AI lacks information. The issue is that it has access to several competing versions of the truth.

Anyone who has worked inside a large enterprise will recognize the pattern. Revenue means one thing to finance and something slightly different to sales. Product usage metrics evolve over time. Operational processes change while documentation remains frozen. Human employees learn how to navigate these inconsistencies through experience and institutional knowledge. AI systems inherit them immediately.

This is why the conversation around context often misses the point. The challenge is not simply providing more information. The challenge is determining which information should be trusted, how conflicts should be resolved and what business logic should govern the final answer.

A single trusted source can be more valuable than a hundred loosely connected ones. A clearly defined rule can be more useful than thousands of pages of documentation. The quality of the context matters far more than the volume.

Access does not create trust

Many organizations can tell you exactly how their AI systems retrieve information. They can explain retrieval pipelines, vector databases, ranking systems, semantic search architectures and context windows in extraordinary detail.

Far fewer can explain how they determine whether the answers produced are consistently correct.

That gap becomes especially important in enterprise environments where the cost of an incorrect answer can be substantial. A sales leader making a forecast, a finance team evaluating performance or an operations executive making a resource allocation decision does not care how many documents were retrieved. They care whether the answer is right.

Trust has always been one of the hardest problems in enterprise data. According to Accenture research on data trust and decision making, only about a quarter of employees report high confidence in their organization’s data when making decisions. That challenge does not disappear when AI enters the picture. If anything, it becomes more visible.

Organizations frequently measure access because access is easy to quantify. Reliability is harder. Reliability requires understanding whether an answer remains consistent across users, across prompts, across time periods and across changing business conditions. It requires understanding whether the same question produces the same answer and whether that answer reflects the business logic the organization intends to enforce.

Those are fundamentally different measurements, and they point to a different definition of success.

Context requires measurement

One reason this problem is becoming more pronounced is that enterprises accumulate information far faster than they eliminate it.

New systems are added, new reports are created, processes evolve. Teams develop local definitions and specialized workflows. Documentation grows continuously, while very little of it gets removed. Over time, organizations build large collections of information that contain years of historical decisions, exceptions, workarounds and competing interpretations.

We’ve yet to encounter an enterprise that doesn’t have some version of this problem.

That reality turns context into an operational challenge rather than a technical one.

Simply connecting AI systems to enterprise information does not improve the quality of that information. In some cases, it exposes longstanding inconsistencies that were previously hidden by human interpretation and tribal knowledge. Gartner has long identified poor data quality as one of the most significant obstacles to successful analytics and AI initiatives because bad inputs inevitably produce unreliable outputs, regardless of how sophisticated the technology becomes.

As AI becomes more deeply integrated into business operations, organizations will need new ways to evaluate the context their systems rely on. They will need visibility into how information is being used, where definitions conflict, which sources are trusted and how context quality affects outcomes. Context cannot be treated as a static asset. It must be measured, monitored and improved over time, just as organizations measure the quality of the models and applications built on top of it.

The shift from access to reliability

The industry has spent the last several years focused on access. How do we connect models to enterprise systems? How do we expose organizational knowledge? How do we give AI visibility into the information people use every day?

Those questions were important because they represented genuine technical barriers. Today, many of those barriers are disappearing.

Most enterprises can already connect AI systems to data warehouses, applications, dashboards, documents and knowledge repositories. The conversation is beginning to shift toward a more difficult problem: Determining whether those connections actually produce outcomes people trust.

That is where the next phase of enterprise AI will be decided.

Organizations that treat context as a quantity problem will continue adding more information and hoping accuracy improves. Organizations that treat context as a quality problem will focus on trust, consistency, governance and outcome reliability.

The difference between those approaches may sound subtle, but it has enormous implications. One produces systems that can access information. The other produces systems that people are willing to use to make decisions.

And in the enterprise, that distinction is ultimately what matters.

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

Security engineers play a pivotal role in enterprise cybersecurity, because they are the professionals who design, build, and deploy security systems to protect an organization’s data, applications, systems, networks, and other IT components against a variety of cyber threats.

Finding not just qualified security engineers, but the best and brightest available, needs to be a priority for CISOs and others overseeing security at their organizations. That’s especially true with the rapid rise of AI and the threats that brings to the enterprise.

Here are some of the key skills and traits of elite security engineers to look for when hiring — or to acquire in order to uplevel your cybersecurity career.

Acumen with AI-powered tools

These days, AI-related skills are in demand regardless of domain, and this certainly applies to security engineers. There’s a wealth of solutions leveraging AI in the market, tools that engineers can add to their defense arsenal.

“AI is transforming security engineering from reactive alerting to predictive threat detection,” says Praveen Margabandhu, digital engineering anchor at financial services firm Navy Federal Credit Union. “AI-driven anomaly detection now identifies behavioral patterns that indicate fraud or compromise before traditional threshold-based systems would fire. This shifts the security engineer’s role from incident responder to threat model designer.”

AI-powered tools have taken over a large portion of the detection and triage work that used to be the core of a security engineer’s day, says Maruf Ahmed, cofounder and CEO of global tech staffing firm Dexian. “Vulnerability scanning runs on its own now,” he says. “Threat flagging that used to require a team pulling through logs for hours happens in minutes.”

This has freed up capacity on most security teams and changed what the day-to-day work looks like, Ahmed says. “With detection increasingly automated, the engineer’s value sits more in interpreting what gets flagged and deciding what to do about it,” he says.

Keen understanding of emerging and established AI threats

Engineers must also have a thorough understanding of the risks AI presents, including AI-enhanced cyberattacks using large language models (LLMs) to automate and scale highly personalized social engineering attacks, craft sophisticated malware, and generate deepfakes.

Other AI threats they need to be aware of include prompt injections, data and model poisoning, disclosure of sensitive information, model theft, supply chain compromises, and excessive agency.

“The same generative tools that help security teams work faster are available to adversaries, and it shows,” Ahmed says. “Phishing campaigns read better and land more precisely than they did a year ago. Social engineering is harder to catch when the language is polished and tailored to the target, and security engineers are now defending against threats built with the same class of technology they use on the defensive side.”

That has raised the bar for what reliable detection looks like, Ahmed says. “The objective shift I hear most from clients is about trust in their own systems,” he says. “Two years ago, the priority was visibility — making sure you could see across your environment. Most organizations have that now. The harder problem is knowing whether what those tools are telling you holds up under scrutiny and having people on the team who can stand behind those findings in front of a regulator or a board.”

Appreciation of performance and business goals

The best security engineers understand how performance and security intersect, says Margabandhu, who leads performance engineering across Navy Federal Credit Union’s digital banking infrastructure, including real-time fraud detection, identity and access management, and cybersecurity infrastructure resilience.

“A fraud detection system that is secure but too slow to catch transactions in real-time is not secure at all,” Margabandhu says. “Elite engineers optimize for both simultaneously.”

Engineers must be able to put things in business context, Ahmed says. “An engineer who can work across domains, validate AI outputs, and learn new tools fast is valuable. But that value compounds when the person also understands what the organization is trying to protect and why,” he says.

Security engineers who understand the business make better risk decisions, write more effective policies, and generate less friction with the teams around them, Ahmed says. “That is the profile employers are hiring toward right now, and it is where the talent shortage is most pronounced,” he says.

Systems mindset

“One of the biggest misconceptions in cybersecurity hiring is that elite security engineers are defined purely by technical certifications or tool familiarity,” says Juan Mathews Rebello Santos, an independent cybersecurity researcher and ethical hacker.

“Technical skill absolutely matters, but the strongest engineers I’ve worked with consistently share a combination of analytical thinking, operational adaptability, communication ability, and deep systems understanding,” Santos says.

Elite security engineers understand how infrastructure, cloud services, identity systems, applications, APIs, networks, users, and business operations connect, Santos says.

“Modern attacks rarely target a single isolated component anymore,” he says. “Threat actors chain together weaknesses across environments. Engineers who can understand those relationships holistically are significantly more effective at both prevention and incident response.”

Cross-disciplinary fluency and broad stack know-how

Being an elite software engineer today means having a range of technology experience and knowledge. “Organizations want engineers who can work across more of the stack than they used to,” Ahmed says. “A role that might have asked for deep specialization in one area now expects someone who can move between cloud infrastructure, application security, and compliance without needing a handoff at every boundary.”

The attack surface has continued to get wider, and the job descriptions for security engineers has followed suit. “That cross-domain fluency matters because security incidents rarely stay contained in one layer,” Ahmed says. “The engineer who can follow a problem from the network through the application to the data governance framework resolves it faster, with fewer people involved.”

The strongest security engineers bridge infrastructure, application, and business domains, Margabandhu says. “They can speak to a CISO, a developer, and a cloud architect in the same conversation,” he says. “An engineer who can explain what an authentication problem means for fraud exposure moves faster in a room full of executives than one who can only describe it in infrastructure terms. I’ve watched technically brilliant people lose that race repeatedly.”

Having the ability to communicate technical risk clearly to non-technical leadership can mean the difference between success and failure of attacks.

“Many security failures today are not caused by lack of tooling, but by misalignment between technical teams and business decision-makers,” Santos says. “Elite engineers can explain operational risk, prioritization, and security tradeoffs in language executives understand.”

Deep understanding of third-party risk and non-human threats

Threats can come from anywhere, including supply chains and non-human combatants. Third-party cybersecurity risks are on the rise. The 2026 Global CISO Leadership Report by executive search firm Hitch Partners, based on a survey of more than 625 information security executives across the US and Canada, says 43% put third-party risks as the No. 1 priority.

“Most teams are still better at securing what they own than securing what they depend on,” Margabandhu says. “The mental shift from perimeter thinking to dependency thinking is real and not everyone has made it. The engineers who treat every API call, every credentialed vendor, every third-party model as part of their attack surface approach design differently.”

Another growing source of potential threats are not human. Machine identities now outnumber human identities by ratios exceeding 100 to 1 in most enterprise environments, with some sectors closer to 500 to 1, according to the ManageEngine Identity Security Outlook 2026 report.

This includes service accounts, API keys, automation tokens, and AI agents, any one of which can present data governance and security risks.

Many organizations are still managing machine identities through manual processes that weren’t designed for scale, Margabandhu says. “Engineers who understand non-human identity governance are rare and increasingly important. This is not a future problem.”

Willingness to keep learning

Security engineers need to have a desire to never stopped learning.

“That sounds obvious until you work with people who’ve been doing this for 15 years and are still operating from the same threat models they built in 2012,” Margabandhu says. “Security changes fast enough that standing still is the same as going backwards.”

The security engineers who keep up aren’t reading one report a year. “They’re genuinely curious about what attackers are doing right now, this month, and they adjust how they think accordingly,” Margabandhu says. “That quality is harder to hire for than most technical skills, because it’s not on a resume.”

With AI presenting new and more sophisticated threats, keeping up with the latest developments is perhaps more important than ever. “Strong engineers are naturally investigative,” Santos says. “They actively study attack techniques, test assumptions, reverse engineer failures, and continuously adapt their understanding of risk.”

The best security engineers are often the people who remain intellectually uncomfortable because they know the landscape is always evolving, Santos says.

Employers have started paying closer attention to how fast someone can learn, Ahmed says. “The threat landscape and the defensive toolkit are both moving faster than any certification program can track, so hiring managers are probing for adaptability in interviews: how candidates have responded to recent shifts, whether they have picked up unfamiliar platforms on their own, how they work through problems they have not seen before,” he says.

A few weeks ago, a new hire at Aviator, fresh out of college, asked me a question I didn’t have a clean answer to. How do I become a senior engineer, or even a staff engineer? What should I learn, and how?

It’s a fair question and a harder one to answer than it was just a year ago.

The path used to be well-known. As a newly hired junior software engineer, you were given an experienced mentor who would assign you simple tasks to learn the ropes. You’d write some code, ask plenty of questions, open a pull request, get feedback in code review, think about it and fix your code. Rinse and repeat that a few hundred times. The tasks became more complex; the feedback got shorter and along the way you’ve been building judgment, the thing that separates a senior engineer from a junior one.

Now AI writes most of the code. The loop looks different and the easy assumption is that it’s broken: fewer tasks for juniors to cut their teeth on, an agent fixing the code that another agent wrote, thinner path to judgment.

Mentoring got easier, not harder

I knew just the person to ask: how do we grow senior and staff engineers in the AI era? Adam Berry is a staff engineer at Netflix, a member of The Hangar, our community of engineering leaders, and someone I have been discussing the evolving role of code review and knowledge sharing for a while now. He spends his time on getting AI adoption right, rather than just fast, in their engineering organization and has been working out the question of growing new engineers in practice. Mentoring juniors in an agentic world, Adam says, isn’t harder; it’s embarrassingly easy.

“You grow juniors and help them become better engineers the same way you always did. AI isn’t changing the methodology. It’s changing the details,” he told me. His point is that the agentic world gives a lot more options for giving juniors bounded tasks to work on and more feedback. The scattered remarks and comments seniors used to give in person now can be put into instructions and guardrails.

Adam breaks working with agents into three foundational skills:

• If you don’t know how to do something with the agent, ask the agent.
• If the agent does something you don’t like, figure out how to correct it and then codify it so it doesn’t happen again.
• Your sense of when the agent has gone off the rails.
  
  

“Most juniors can pick up the first two on their own. On the third one, they need guidance, he says.

His process for building it is staged. “The stages are about growing scope. First, you give a junior engineer a well-specified task—and these are now bigger than what you’d have given a junior before. You can give them task definitions that are like a prompt and instructions to drive that prompt, make sure they got to a good plan, make sure they understood the plan, and that they thought through the test cases, etc.

Then gradually you peel off some of that specificity so they have to build the muscle themselves. Once they’ve gotten good at that level of scope, they’re ready to work on larger scoped problems.”

Starting from more specific problems and going towards ambiguous problems is the definition of growing as an engineer.

Pair programming with the agent in the room

Seniors can still do pairing sessions with juniors, now with the agent in the room.

“In the pairing session, the earlier-career engineer should be the one driving. The agent can be set up to interrogate the junior rather than just answer them. None of you is manually writing code, but you’re still doing pair programming and mentoring. Even if it’s just a trivial bug fix, if you guide a junior through it, it forces them to do just that little bit of thinking.”

Adam says mentoring juniors today does not have to mean forcing them to write code manually. Seniors should teach them the process of agentic engineering, and that’s exactly what they should focus on during the pairing sessions. The habit he wants to be installed early is asking for options instead of answers.

“I aim to teach juniors to ask for options and think through them, even on small tasks. I ask them to explain what their input to the AI tool was that led to the code they got. But I’d also show them how I would have done the same thing.”

The pairing produces artifacts as it goes. “That’s where you get into conversations of, ‘This is why that wasn’t quite it for me,’ and if I see that that’s not baked into the repo, I’m going to add this into the ADR, into the design, into the instruction set. I’ll codify that so the junior gets it too, and they know why it exists, because they watched me go through it with the tool myself.”

That reshapes the code review instead of removing it. Making that work puts more on senior engineers, not less. “Senior engineers need to ensure that things like ADRs, or whatever system you use, are properly encapsulated in the repo for both the agents and the humans to consume.” His team also attaches the prompts to the pull request and has the agent summarize what it did against what the prompt asked.

Adam also teaches junior engineers how to bring in expert sources from outside into AI tools. He’ll point an agent at a book like Michael Feathers’ Working with Legacy Code as an example of what quality code looks like and have it work from the concepts directly.

Don’t outsource the thinking

His arguments make sense, but I also recently came across research examining the influence of AI tools on how and why members of software engineering teams interact. Their finding was not surprising: of the 131 surveyed developers, 51% said they now ask GenAI for technical help they once would have asked a person, and 62% said it was easier to ask GenAI without fear of embarrassment.

When a junior gets stuck now, their first move usually isn’t to message a senior on Slack. It’s to ask the agent. This is also the case in code reviews. The purpose of code reviews was always knowledge sharing as much as it was a quality gate. What I see junior engineers do now is take the feedback and, without reading it closely, hand it straight to the agent to resolve. The part where they would have to understand how their work differed from what the senior expected disappears. It got passed from the reviewer to the agent, and the junior skipped the understanding.

This isn’t really the junior’s fault. They need the motivation and the space to do it differently, and the default pattern under delivery pressure is to push the thing out and worry about it later.

The same research showed that developers turned to colleagues with questions about context (65% to clarify business logic or requirements, 50% for how something had been done before).

Respondents were also aware of the trap that Berry’s approach was created to avoid: AI tends to hand back a single answer, compared to multiple perspectives a colleague surfaces and they kept seeking teammates for context-specific expertise, mentorship and plain social connection.

The fix is almost mechanical: if you have to make a choice, you have to think about it. I do this in my own product thinking. Most of it happens by bouncing ideas off Claude, but whenever something is complex, I make myself lay out a few options, trade them against each other and decide which direction to take. That’s the same move Berry wants juniors making, and it’s what builds judgment, whether you’re twenty-two or forty.

Why we should still hire juniors

There’s also a hiring question underneath all of this. We recently hosted Kent Beck, an industry legend, at the Hangar in a session we called “Juniors FTW,” and his reasoning was that the industry is being remade fast enough that being new is an advantage. Juniors are too new to have absorbed what everyone “knows” is impossible, which leaves them less biased, more creative and carrying fewer preconceived mental barriers.

Beck also wrote about how important it is to hire juniors without the calculation of how many tasks they can perform.

“If all we cared about was today’s productivity, we wouldn’t have hired you at all. Instead, we (the seniors) are focused on the future: we know there’s going to be far more work here than we could possibly accomplish. We are paying your salary now as the option premium on the engineer you will become. If we play this game right, we’ll have a kick-ass next generation of engineers. If not, we’ll have to be doing the same engineering jobs ten years from now, and we really don’t want to be doing that.”

The pipeline is thinning

The trend is running the other way. Entry-level hiring at the 15 biggest tech firms fell 25 percent from 2023 to 2024, according to a report from SignalFire. In a recent survey of engineering leaders, a majority said they plan to hire fewer juniors, on the logic that AI lets seniors cover more ground.

That logic is short-sighted in a specific way. Senior engineers don’t appear from nowhere. They’re the juniors someone hired five or ten years ago and invested in mentoring them. Stop hiring and growing juniors now, and the gap doesn’t show up this year. It shows up later, when the industry needs people with the judgment that only comes from years of making mistakes and recovering from them and finds it stopped producing them.

So, here’s the answer to the question that the new hire asked: the path to senior and to staff is the same path it always was. You grow the range of ambiguity you can handle, and you stay honest about the part you can’t handle yet. What changed is the interface. The agent writes the code. Your job is to keep asking questions to your colleagues and the agents and keep doing the thinking until the thinking is good.

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

Deluxe may have prevailed against the odds when it successfully migrated from a 50-plus-year-old mainframe recently.

The company was able to move from it to a cloud environment in about 12 months without a major hitch, and while AI did some of the heavy lifting. The save will amount to about $4.9 million a year by retiring old hardware and software, cutting labor costs, and consolidating IT resources.

Deluxe, based in Minneapolis and traditionally known as a check printer, has transformed itself into a payments IT provider in recent years. But it desperately needed to end its reliance on its ancient mainframe, says Yogaraj Jayaprakasam, the company’s chief technology and digital officer, pictured.

So AI played a huge role in the IT modernization project, he says, using it to rewrite the old mainframe code, generate documentation, and regenerate code test cases. The company also used an AI-powered test automation suite, as well as AI tools to help move assets to the new cloud environment.

While AI can’t do everything during mainframe migration, it can make the move easier, Jayaprakasam says. “The biggest lessons learned is AI is one of the missing tools in your transformation tool set,” he adds.

Failing projects

Deluxe’s mainframe migration earned it a 2026 CIO 100 Award for IT innovation and leadership, but it also seems to have bucked a recent trend. Many mainframe migration projects haven’t gone as planned, and Gartner recently predicted that more than 70% of mainframe exit projects that started in 2026 will fail to produce intended benefits because of an overreliance on gen AI.

Mainframe transformation projects tend to work better when they’re part of a larger business transformation rather than a one-off project using gen AI to do most of the work, says Gartner analyst Alessandro Galimberti.

“Generative AI and agentic AI are extremely powerful, but they also have their own limits,” he says. “With all these kinds of tools trying to convert code or somehow fit into a non-mainframe workload, we don’t really see a track record of success.”

Gartner also sees a declining interest in mainframe migration projects, Galimberti says. With mainframes getting support from several IT vendors, and with a general lack of migration success, many companies are choosing to keep many workloads on their existing big iron.

But mainframes also have a proven track record of very high uptime and backward capability, Galimberti says.

“If I’m a bank, a financial institution, or a transportation company, I need to run applications that are the core of my business,” he adds. “I need reliability, transactional integrity, and security, and these applications have a low change rate over the years because they map very stable business processes.”

The Gartner prediction makes sense to John McKenny, senior VP and GM of Intelligent Z optimization and transformation for mainframe support vendor BMC Software.

“With organizations thinking about mainframe exits, the expected benefits they’re looking for are usually pretty straightforward,” he says. “They think, ‘It’s going to be lower cost, I’m going to get equal or better capabilities, I should be more agile.’  The reality is those outcomes rarely show up at scale.”

Mainframe migration is possible, but the successful projects tend to be small scale, McKenny adds. He was on a recent call about a failed migration project in Europe, with a large bank cancelling the project at the end of 2025 and recommitting to the mainframe as a strategic platform.

“I’ve never seen a large-scale mainframe migration project finish under budget, ever,” he says. “Most of the projects I hear about fail outright.”

Trying again

Like some organizations that Gartner has observed, Deluxe tried to move away from its mainframe several years ago, but the project failed, Jayaprakasam says. Yet the company took the steps it needed this time to ensure the new migration succeeded.

While a mainframe migration isn’t for every organization, the latest move made sense for Deluxe, he says.

The mainframe, after all, was the backbone for a large portion of the company’s annual revenue, and interfaces with several top banks across North America. The modernization effort rebuilt core business processes and data, moving them from the mainframe to a modern cloud-native technology stack, including Salesforce, Mulesoft, and SAP S4/HANA.

While AI played a big part, there’s danger in overestimating the power of AI during a migration project, Jayaprakasam says, and organizations need to follow best practices for IT migration.

“If you minimize the importance of communication, risk planning, and business alignment because you have AI, you tend to fail,” he says. “But as long as you play all those cards and recognize AI was the missing piece to the puzzle, then you have a much better chance of winning.”

Deluxe also used a cross-functional tiger team to look at the various options available to accelerate reverse engineering, including AI tools from OpenAI, Anthropic, as well as GitHub Copilot throughout the project.

In addition, AI was useful to dig through the mainframe code and understand what needed to be updated, Jayaprakasam says. Organizations sitting on decades-old code often no longer have people who understand it.

“I always tell people that the code remembers what the organization forgot, because with people going and changing, people don’t remember what we wrote in the code, but the code remembers,” he adds. “The amazing tool that was missing before is we didn’t have an interpreter who understood what the code remembered. Now with AI, you have the interpreter.”

Over its more than 15 years in the wild, Google’s Go programming language has evolved from a curiosity for alpha geeks to the battle-tested programming language behind some of the world’s most important cloud-native software projects.

If you’ve ever wondered why Go is the language of choice for projects like Docker and Kubernetes, this article is for you. We’ll discuss Go’s defining characteristics and how it differs from other programming languages. You will also learn what kinds of projects Go is best suited for, including the state of Go development for AI-powered tools. We’ll conclude with an overview of Go’s feature set, some limitations of the language, and where it may be going from here.

Also see: Golang tutorial: Get started with the Go language.

Go is small and simple

Go, or Golang as it’s often called, was created by Google employees—chiefly longtime Unix guru and Google distinguished engineer Rob Pike—but it’s not strictly speaking a “Google project.” Rather, Go is a community-developed open source project, spearheaded by leadership with strong opinions about how Go should be used and the direction the language should take.

Go is meant to be easy to learn and straightforward to use, with syntax that is simple to read and understand. Go does not have a large feature set, especially when compared to languages like C++. Go’s syntax is reminiscent of C, making it relatively easy for longtime C developers to learn. That said, many features of Go, especially its concurrency and functional programming features, harken back to languages like Erlang.

As a C-like language for building and maintaining cross-platform enterprise applications of all sorts, Go has much in common with Java. And as a means for enabling rapid development of code that might run anywhere, you could draw a parallel between Go and Python, though the differences outweigh the similarities.

The Go documentation describes Go as “a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language.” Even a large Go program will compile in a matter of seconds. Plus, Go avoids much of the overhead of C-style include files and libraries.

Advantages of the Go language

Go is a versatile, convenient, fast, portable, interoperable, and widely supported modern language. These characteristics have helped to make it a top choice for large-scale development projects. Let’s look more closely at each of these positive qualities of Go.

Go is versatile and convenient

Go has been compared to interpreted languages like Python in its ability to satisfy many common programming needs. Some of this functionality is built into the language itself, such as goroutines for concurrency and thread-like behavior, while additional capabilities are available in Go standard library packages, like the http package. Like Python, Go provides automatic memory management capabilities including garbage collection.

Unlike interpreted languages, however, Go code compiles to a fast-running native binary. And unlike C or C++, Go compiles extremely fast—fast enough to make working with Go feel more like working with an interpreted language than a compiled one. Further, the Go build system is less complex than those of other compiled languages. It takes few steps and little bookkeeping to build and run a Go project.

Go is faster than many other languages

Go binaries run more slowly than their C counterparts, but the difference in speed is negligible for most applications. Go performance is as good as C for the vast majority of work, and generally much faster than other languages known for speed of development—including JavaScript, Python, and Ruby.

Go is portable and interoperable

Executables created with the Go toolchain can stand alone, with no default external dependencies. The Go toolchain is available for a wide variety of operating systems and hardware platforms, and can be used to compile binaries across platforms. What’s more, Go delivers all of the above without sacrificing access to the underlying system. Go programs can talk to external C libraries or make native system calls. In Docker, for instance, Go interacts with low-level Linux functions, cgroups, and namespaces to work container magic.

Go is widely supported

The Go toolchain is freely available as a Linux, macOS, or Windows binary, or as a Docker container. Go is included by default in many popular Linux distributions, such as Red Hat Enterprise Linux and Fedora, making it somewhat easier to deploy Go source to those platforms. Support for Go is also strong across many third-party development environments, from Microsoft’s Visual Studio Code to ActiveState’s Komodo IDE.

Also see: 8 reasons developers love Go—and 8 reasons they don’t.

Optimal use cases for the Go language

No language is suited to every job, but some languages are suited to more jobs than others. Go shines brightest in cloud-native development projects, distributed network services, and for developing utilities and stand-alone tools. Let’s consider the qualities that make Go especially well-suited to each of these project types.

Cloud-native development

Go’s concurrency and networking features, and its high degree of portability, make it well-suited for building cloud-native apps. In fact, Go was used to build several cornerstones of cloud-native computing including Docker, Kubernetes, and Istio.

Distributed network services

Network applications live and die by concurrency, and Go’s native concurrency features—goroutines and channels, mainly—are well suited for such work. Consequently, many Go projects are for networking, distributed functions, and cloud services. These include APIs, web servers, Kubernetes-ready frameworks for microservices, and much more.

Utilities and standalone tools

Go programs compile to binaries with minimal external dependencies. That makes them ideally suited to creating utilities and other tools, because they launch quickly and can be readily packaged up for redistribution. One example is an access server called Teleport, which can be deployed on servers quickly by compiling it from source or downloading a prebuilt binary.

Limitations of the Go language

Now let’s consider some of the limitations of Go. For one, it omits many language features developers may desire. It also packs everything into its binaries, so Go programs can be large. Furthermore, Go’s garbage collection mechanism delivers automatic memory management at the cost of absolute performance. The language also lacks a standard toolkit for building GUIs, and it is unsuited to systems programming.

Let’s look at each of these issues in detail.

Go omits many desirable language features

Go’s opinionated set of features draws both praise and criticism. Go is designed to err on the side of being small and easy to understand, with certain features deliberately omitted. The result is that some features that are commonplace in other languages simply aren’t available in Go. This is purposeful, but it’s still a drawback for some types of projects.

One thing Go omits that you will find in other languages is macros, commonly defined as the ability to generate program code at compile time. C, C++, and (the rising star) Rust all have macro systems. Go does not have macros, or at least not of the same variety as those languages. What Go does have is a tool command, go generate, which looks for magic comments in Go source and executes them. This can be used to generate Go source code, or even run other commands, but its main use is to programmatically generate code, usually as a precursor to the build process. (Technical blogger Eli Bendersky explains the ‘go generate’ command in detail.)

Another longstanding complaint with Go was, until recently, the lack of generic functions, which allow a function to accept many different types of variables. Go’s development team held out against adding generics to the language for many years because they wanted a syntax and set of behaviors that complemented the rest of Go. But as of Go 1.18, released in early 2022, the language includes a syntax for generics. Because go generate and its code-generation abilities emerged as one possible way to partially address the lack of generics, this functionality is no longer as commonly used in Go.

The fact is that Go adds major language features rarely, and only after much consideration. This works to preserve broad compatibility across versions, but it comes at the cost of slower innovation.

Also see: What you need to know about Go, Rust, and Zig.

Go’s binaries are large

Another potential downside to Go is the size of the generated binaries. Go binaries are statically compiled by default, meaning that everything needed at runtime is included in the binary image. This approach simplifies the build and deployment process, but at the cost of a simple “Hello, world!” weighing in at around 1.5MB on 64-bit Windows. The Go team has been working to reduce the size of those binaries with each successive release. It is also possible to shrink Go binaries with compression or by removing Go’s debug information. This last option may work better for standalone distributed apps than for cloud or network services, where having debug information is useful if a service fails in place.

Go’s garbage collection is resource hungry

Yet another touted feature of Go, automatic memory management, can be seen as a drawback, as garbage collection requires a certain amount of processing overhead. By design, Go doesn’t provide manual memory management, and garbage collection in Go has been criticized for not dealing well with the kinds of memory loads that appear in enterprise applications.

That said, each new version of Go seems to improve the memory management features. For example, Go 1.8 brought significantly shorter lag times for garbage collection, and Go 1.25 introduced a new, experimental garbage collector. While Go developers can use manual memory allocation in a C extension, or by way of a third-party manual memory management library, most prefer native solutions.

Go doesn’t have a standard GUI toolkit

Most Go applications are command-line tools or network services. That said, various projects are working to bring rich GUIs for Go applications. There are bindings for the GTK and GTK3 frameworks. Another project is intended to provide platform-native UIs across platforms, although it focuses on Go 1.24 forward only. But no clear winner or safe long-term bet has emerged in this space. Also, because Go is platform-independent by design, it is unlikely any project in this vein will become a part of the standard package set.

You shouldn’t use Go for systems programming

Finally, although Go can talk to native system functions, it was not designed for developing low-level system components such as kernels, device drivers, or embedded systems. After all, the Go runtime and the garbage collector for Go applications are dependent on the underlying operating system. (Developers interested in a cutting-edge language for that kind of work might look into using Rust.)

The future of the Go language

Go’s development is turning more toward the wants and needs of its developer base, with Go’s minders changing the language to better accommodate this audience rather than leading by stubborn example. A case in point is generics, which were finally added to the language after much deliberation about the best way to do so.

The 2024 Go Developer Survey found developers were overall satisfied with Go. Challenges that surfaced were generally due to the verbosity of error handling, missing or immature frameworks, and using Go’s type system—areas ripe for future development.

Like most languages, Go has gravitated to a core set of use cases over time, finding its niche in network services. In the future, Go is likely to continue expanding its hold there. Other use cases cited in the developer survey include creating APIs or RPC services (74% of respondents), followed by CLI applications (63%), web services (45%), libraries/frameworks (44%), automation (39%), and data processing (37%). While only 4% of respondents mentioned using Go to develop AI technologies, those who did reported that Go was a strong platform for running AI-powered workloads in production. For those wanting to develop ML/AI with Go, lack of tooling (23%) and the fact that Python is the default choice for such work (16%) topped the reasons why.

It remains to be seen how far Go’s speed and development simplicity will take it into other use cases, especially those dominated by other languages and their existing use cases. Rust covers safe and fast systems programming (a space Go is unlikely to enter); Python is still a common default for ML/AI, prototyping, automation, and glue code; and Java remains a stalwart for enterprise applications.

But Go’s future as a major programming language is already assured—certainly in the cloud, where the speed and simplicity of Go ease the development of scalable infrastructure that can be maintained over the long run.

Also see: Go language evolving for future hardware, AI workloads.

Generative AI is a kind of artificial intelligence that creates new content, including text, images, audio, and video, based on patterns it has learned from existing data.

Today’s generative models are typically built on foundation-model architectures such as large-language models (LLMs) and multimodal systems, enabling them to carry on conversations, answer questions, write stories, generate code, and produce images or videos from brief prompts.

Generative AI is different from discriminative AI, which draws distinctions between different kinds of input. Where discriminative AI answers questions like “Is this image of a rabbit or a lion?”, generative AI instead responds to prompts such as “Describe to me how a rabbit and lion look different from one another” or “Draw me a picture of a lion and a rabbit sitting next to each other” — and in both cases produces text or imagery that, while grounded in the AI’s training data, isn’t just a copy of something that already existed.

Just a few years ago, generative AI was once a novelty focused on chatbots and artistic image generation. Today, it has become a core enterprise technology, and powers everything from content creation and software development to customer support and analytics workflows. But with that power comes a new set of challenges — from model alignment and hallucination to governance and data-integration hurdles.

In this article, we’ll look at how generative AI works, explore how it has evolved into the foundation-model era, examine how to implement it effectively, and offer best practices for getting value out of it, today and in the future.

How does generative AI work?

For decades, early artificial-intelligence efforts often focused on rule-based systems or narrowly trained models that were built for one task at a time. While these efforts produced useful systems that could reason and solve human tasks, they were generally a far cry from sci-fi visions of thinking machines. Programs that could talk to people never seemed to get very far past the level of ELIZA, a “computer therapist” created at MIT in the mid 1960s; even Siri and Alexa after much fanfare were revealed to be fairly limited.

The big structural shift that gave birth to modern generative AI came with the concept of a transformer, first introduced in “Attention Is All You Need,” a 2017 paper from Google researchers.

Using a transformer architecture as a basis, you can build a system that derives meaning from analyzing long sequences of input tokens (words, sub-words, bytes) to understand how different tokens might be related to one another, then determines how likely any given token is to come next in a sequence, given the others. In AI lingo, we call these systems models. Because a model analyzes very large datasets and parameter counts, it can pick up on statistical patterns and knowledge implicitly embedded in the data.

This is all easier said than done. The process of adjusting a model’s internal parameters so it gets better at predicting the next token in sequences is called training. During training, the model repeatedly guesses the next token in a given sequence, compares its prediction to the actual one, measures the error, and updates its parameters to reduce that error across billions of examples. Over time, that process teaches the model the statistical relationships that will allow it to generate coherent language (or code, or images) later.

What is a foundation model?

You’ll often hear the word large used for transformer-based models of these types, like the LLMs we mentioned earlier. Large in this context refers to the large number of internal numerical values that the model adjusts during training to represent what it has learned, along with breadth and diversity of data used to train the model and the underlying compute resources powering this whole process.

This is in contrast with the narrow models of the earlier era of AI/ML, which werebuilt for one purpose and trained on a limited dataset. For instance, a spam filter may be very good at what it does, but it’s only trained on email data and all it can do is classify emails. Large models, by contrast, serve as what’s known as foundation models. They’re trained broadly on diverse data (text, code, images, or multimodal data) and then adapted or specialized for many downstream tasks.

These foundation models are the basis for most of the popular generative AI tools and services on the market today. They can be specialized in several ways:

• Fine-tuning: Giving a foundation model further training on a smaller, task-specific dataset
• Retrieval-augmented generation (RAG): Giving the model the ability to pull in external knowledge when asked a question
•  Prompt engineering: Tailoring a query so the model gives the sort of answers you’re looking for.

How do AI systems write computer code?

One of the surprising discoveries of the gen AI era was that in recent years was that foundation models trained on natural-language text can also, when fine-tuned with code examples, also write computer code — often better than many purpose-built systems. Still, it makes sense, when you think about it — after all, high-level computer languages are designed by humans and ultimately based on human language.

This 2023 InfoWorld article highlights how models like PaLM, LLaMA and other transformer-based systems fine-tuned on code repositories propelled this shift, but since AI giants like OpenAI have moved into this space. This all matters because code generation (or code-assisted productivity) has become a key enterprise use case of generative AI — perhaps the key use, given the industry’s enthusiastic adoption of it.

What are AI agents?

So far, we’ve been talking about chatbots, writing assistants, image-generation tools. They respond to prompts, output text or images, and then stop. A new category of tool called agentic AI goes further: it plans, executes, and in many cases learns as it works.

Because large models already understand language, code, and even structured data to some extent, they can be repurposed to generate not only descriptive text but operational instructions. For example: an agent might parse the intent “generate a sales-report”, then format internal calls like getData(salesDB, region=NA, period=lastQuarter), and then call an API, all by generating text that’s interpreted as instructions. The MCP framework standardizes the “language” of those instructions and the plug-points into tools and data so that the model doesn’t need bespoke integrations for each new workflow.

These kinds of autonomous agents have several enterprise use cases:

• Software automation: Agents that generate code, call unit tests, deploy builds, monitor logs and even roll back changes autonomously.
• Customer support: Instead of simply drafting responses, agents interact with CRM APIs, update ticket statuses, escalate issues, and trigger follow-up workflows.
• IT operations/AIOps: Agents monitor infrastructure, identify anomalies, open/close tickets, or auto-remediate based on defined rules and context from logs.
• Security: Agents may detect threats, initiate alerts, isolate compromised systems, or even attempt to manage threat containment — though this raises new risks.

How can you implement generative AI in the enterprise?

We’ve now touched on what generative AI can do. But how can you make it work reliably in your business. The difference between a pilot and full-scale deployment often comes down to systems, structure and governance as much as to models themselves. InfoWorld’s Matt Asay offers a deep dive into enterprise gen AI essentials, but here are some important points to keep in mind:

Choosing between API, open-source or custom fine-tuned models. One of the first major decisions for any enterprise project is: do you use a model via an API (e.g., from a vendor like OpenAI or Anthropic), deploy an open-source model internally, or build/fine-tune a custom model yourself? Each has trade-offs.

APIs offer speed and minimal setup, but may expose data, limit customization or accrue high cost — and will leave you at the mercy of your vendor. Open source allows internal control and may ease fine-tuning, but requires infrastructure, expertise, and support. Custom fine-tuning gives you the tightest alignment to your use-case, but lengthens time to value and increases risk.

Governance, data privacy and compliance. Deploying generative AI in an enterprise setting raises new governance, privacy and regulatory issues. For example: Who owns the data that’s ingested? How is proprietary data protected if you call a third-party API? What traceability exists for model outputs—a huge question for regulated industries? One useful framework is covered in “A GRC framework for securing generative AI” Data governance must adapt for the new era,  and new frameworks are evolving to help.

Human-in-the-loop review. Even the best models make mistakes and cannot simply be put on autopilot. You need a human-in-the-loop (HITL) process: real people need to review outputs, validate for bias, approve high-stakes content, and tune prompts or models based on feedback. Incorporating HITL checkpoints helps mitigate risk and improve overall quality.

Integration with existing systems and RAG pipelines. Retrieval-augmented generation, which we touched on earlier, connects foundation models into business workflows, systems, and enterprise data stores. RAG can bind LLMs to your organization’s internal knowledge bases, thereby reducing hallucinations (which we’ll discuss in a moment) and increasing the relevance of gen AI output.

What causes AI hallucinations?

Probably the biggest limitation of generative AI is what those in the industry call hallucinations, which is a perhaps misleading term for output that is, by the standards of humans who use it, false or incorrect.  

Every generative AI system, no matter how advanced, is built around prediction. Remember, a model doesn’t truly know facts—it looks at a series of tokens, then calculates, based on analysis of its underlying training data, what token is most likely to come next. This is what makes the output fluent and human-like, but if its prediction is wrong, that will be perceived as a hallucination.

Foundry

Because the model doesn’t distinguish between something that’s known to be true and something likely to follow on from the input text it’s been given, hallucinations are a direct side effect of the statistical process that powers generative AI. And don’t forget that we’re often pushing AI models to come up with answers to questions that we, who also have access to that data, can’t answer ourselves.

In text models, hallucinations might mean inventing quotes, fabricating references, or misrepresenting a technical process. In code or data analysis, it can produce syntactically correct but logically wrong results. Even RAG pipelines, which provide real data context to models, only reduce hallucination—they don’t eliminate it. Enterprises using generative AI need review layers, validation pipelines, and human oversight to prevent these failures from spreading into production systems.

What are some other problems with generative AI?

Generative AI has proven to be such a disruptive technology that’s stoking near-apocalyptic fears that it will result in a superintelligence that will enslave or destroy humanity. Meanwhile, in the present day, increasingly troubling reports of so-called AI psychosis are emerging, where people have mental health episodes triggered by the uncanny and sometimes sycophantic ways chatbots affirm whatever you talk to them about and try to keep the conversation going.

Compared to such existential questions, the following business-related problems may seem petty. But they’re real issues for enterprises considering investing in AI tools.

• Data leakage and regulatory risk. When a model is fine-tuned or prompted with sensitive information, that data may be memorized and unintentionally reproduced. Using third-party APIs without strict controls can expose proprietary or personally identifiable information (PII). Regulatory frameworks like GDPR and HIPAA require explicit governance around where training data resides and how inference results are stored.
• Prompt injection occurs when an attacker manipulates a model’s instructions—embedding hidden directives or malicious payloads in user input or external content the model reads. This can override safety rules, expose internal data, or execute unintended actions in agentic systems. Guardrails that sanitize inputs, restrict tool-calling permissions, and validate outputs are becoming essential.
• Copyright and content ownership. Many foundation models are trained on data scraped from the public internet, creating disputes over copyright and data provenance. Enterprises using generated output commercially need to confirm usage rights and review indemnity terms from vendors.
• Unrealistic productivity expectations. Finally, organizations sometimes expect generative AI to deliver instant productivity gains. The reality, it turns out, is more mixed. Enterprise adoption requires infrastructure, governance, retraining, and cultural change. The models accelerate work once properly integrated, but they don’t automatically replace human judgment or oversight.

The current generation of enterprise AI systems includes several layers of defense against these risks:

• Guardrails that constrain model behavior and filter unsafe outputs.
• Model validation frameworks that measure factual accuracy and consistency before deployment.
• Policy layers that enforce compliance rules, redact sensitive data, and log model actions.

These safeguards reduce—but don’t remove—the inherent uncertainty that defines generative AI.

GenAI: essential for the enterprise

Generative AI has evolved from a novelty into a core layer of enterprise technology. Foundation models and agentic systems now power automation, analytics, and creative workflows — but they remain fundamentally probabilistic tools. Their strength lies in scale and adaptability, not perfect understanding.

For organizations, success depends less on chasing model breakthroughs than on integrating these systems responsibly: building guardrails, maintaining oversight, and aligning them with real business needs. Used wisely, generative AI can amplify human capability rather than replace it.

Over the past decade, software development has been shaped by two closely related transformations. One is the rise of devops and continuous integration and continuous delivery (CI/CD), which brought development and operations teams together around automated, incremental software delivery.

The other is the shift from monolithic applications to distributed, cloud-native systems built from microservices and containers, typically managed by orchestration platforms such as Kubernetes.

While Kubernetes and similar platforms simplify many aspects of running distributed applications, operating these systems at scale is still complicated. Configuration sprawl, environment drift, and the need for rapid, reliable change all introduce operational challenges. GitOps emerged as a way to address those challenges by extending familiar devops and CI/CD techniques beyond application code and into infrastructure and system configuration.

At the heart of GitOps is the concept of infrastructure as code (IaC). In a GitOps model, not only application code but also infrastructure definitions, deployment configurations, and operational settings are described in files stored in a version control system. Automated processes continuously compare the running system with those declarations and work to bring the live environment back into alignment when differences appear.

In this approach, the version control repository serves as the system of record for how applications and their supporting infrastructure should look in production. Changes flow through the same review, approval, and automation pipelines that developers already use for software, bringing greater consistency, traceability, and repeatability to cloud-native operations.

At a high level, GitOps refers to a set of operational practices for managing cloud-native systems using declarative configuration, version control, and automated reconciliation. Rather than treating infrastructure and application configuration as mutable runtime state, GitOps treats them as versioned artifacts that move through the same review, testing, and deployment processes as application code.

GitOps defined

The term GitOps was originally coined and popularized by Weaveworks, which helped formalize the approach in the context of Kubernetes operations. While that early work shaped the way GitOps was discussed and implemented, GitOps has since evolved into a broadly adopted, vendor-neutral pattern. Today, it describes a shared set of ideas rather than a specific product or platform.

The defining characteristic of GitOps is its reliance on declarative configuration stored in a version control system. Instead of issuing imperative commands to change live systems, teams describe the desired state of applications and infrastructure in configuration files. Automated agents then continuously compare that declared state with what is actually running and work to reconcile any differences. This pull-based model—where systems converge toward the desired state defined in version control—provides built-in drift detection, repeatability, and a clear audit trail for every change.

Because GitOps centers on configuration files stored in a version control system, familiar software development practices carry over naturally. Changes are proposed through commits, reviewed before being accepted, and tracked over time. Rollbacks are accomplished by reverting to known-good versions, and the history of how a system evolved is preserved alongside the configuration itself.

While the use of Git as the version control system is not strictly required, it has become the default choice because of its ubiquity in modern devops workflows and its strong support for collaboration and change management, so its place in the name has stuck.

What is the CI/CD process?

A complete look at CI/CD is beyond the scope of this article—see the InfoWorld explainer on the subject—but we need to say a few words about CI/CD because it’s at the core of how GitOps works. The continuous integration half of CI/CD is enabled by version control repositories like Git: Developers can make constant small improvements to their codebase, rather than rolling out huge, monolithic new versions every few months or years. The continuous deployment piece is made possible by automated systems called pipelines that build, test, and deploy the new code to production.

Again, we keep talking about code here, and that usually summons up visions of executable code written in a programming language such as C or Java or JavaScript. But in GitOps, the “code” we’re managing is largely made up of configuration files. This isn’t just a minor detail — it’s at the heart of what GitOps does. These config files are, as we’ve said, the “single source of truth” describing what our system should look like. They are declarative rather than instructive. That means that instead of saying “start up ten servers,” the configuration file will simply say, “this system includes ten servers.”

GitOps and Kubernetes

GitOps first took hold in the Kubernetes ecosystem, where declarative configuration and continuous reconciliation are core design principles. As a result, Kubernetes remains the most common and best-understood environment for applying GitOps practices. A typical GitOps-driven update process for a Kubernetes application looks like this:

1. A developer proposes a change by committing updated application code or configuration to a version control repository, usually through a pull request.
2. That change is reviewed and approved, then merged into the main branch.
3. The merge triggers an automated CI/CD pipeline that tests the change, builds new artifacts if needed, and publishes them to a registry.
4. A GitOps controller or similar automated agent detects the updated desired state stored in version control.
5. The controller compares that desired state with the current state of the Kubernetes cluster and applies the necessary changes to bring the cluster back into alignment.

This pull-based reconciliation loop—where the cluster continuously converges toward the desired state defined in version control—is central to how GitOps works in practice. While Kubernetes provides a natural fit for this model, it represents just one canonical use case. The same patterns increasingly apply to infrastructure provisioning, policy enforcement, and multi-cluster operations beyond Kubernetes itself.

GitOps tooling in practice: Argo CD, Flux, and the ecosystem

GitOps is enabled by a set of tools that embody the principles we’ve outlined, with some open-source projects emerging as de facto standards in cloud-native environments.

At the center of the GitOps ecosystem is Argo CD, an open-source controller that continuously monitors a version control repository and ensures that the state of running systems matches the declared desired state. Argo CD is widely used in Kubernetes environments because it directly implements pull-based reconciliation: it compares the desired state stored in Git with the cluster’s actual state and applies changes to correct any drift.

Alongside Argo CD, Flux is another prominent open source GitOps engine. Both Flux and Argo CD help teams adopt GitOps workflows by managing the synchronization loop between code and runtime, but they differ in operational philosophy, integration surfaces, and ecosystem fit.

GitOps tooling often appears as part of broader platforms or integrated stacks rather than as isolated utilities. For example, multicloud and cluster management solutions now routinely include GitOps support, with Argo CD or compatible controllers bundled alongside deployment, policy, and governance capabilities.

In addition to Flux and Argo CD, a range of auxiliary tools contribute to a complete GitOps ecosystem: policy as code engines (e.g., Open Policy Agent), drift detection systems, and infrastructure provisioning tools that mesh with Git-centric workflows.

GitOps, devops, and normalization

GitOps grew out of the same forces that drove devops into mainstream IT practice, and in its early days, GitOps was often discussed as a distinct extension of devops, specifically tailored to managing declarative infrastructure and Kubernetes-centric systems. At the time, GitOps was still relatively new and not yet widely adopted outside cloud-native pioneers.

Over the last several years, however, GitOps practices have become deeply woven into how teams operate modern cloud environments. Rather than being treated as an optional add-on or marketing term, the core ideas of GitOps — using version-controlled, declarative configuration and automated reconciliation loops to continuously align running systems with intended state — are now part of standard operational practice in many Kubernetes-centric shops. In this sense, GitOps has shifted from a buzzword about what might be possible to a baseline pattern for cloud-native operations, much like devops itself did years earlier.

In environments where Kubernetes and declarative systems are the norm, GitOps workflows are the default way teams manage and deploy change. Many organizations now implement these patterns without explicitly calling them “GitOps,” just as few teams today explicitly say they do “CI/CD” even though continuous pipelines are taken for granted. The term has become less prominent in marketing, but its practices are often embedded in pipelines, controllers, and platform tooling.

That normalization shows up in how GitOps workflows are woven into broader operational frameworks. For example, platform engineering teams frequently build internal developer platforms that encapsulate GitOps patterns behind standardized developer APIs, making the pattern invisible to most application teams while still providing the auditability and automation that GitOps promises.

GitOps beyond Kubernetes: infrastructure, policy, and drift

While GitOps first gained traction as a way to manage Kubernetes deployments, its core principles apply broadly to infrastructure and operational concerns beyond any single orchestration platform. GitOps treats desired state as declarative configuration stored in version control and uses automated reconciliation to ensure running systems align with that state. That pattern naturally extends to infrastructure provisioning, policy enforcement, configuration drift detection, and governance workflows across diverse environments.

In modern operational stacks, infrastructure is increasingly defined declaratively, whether through Kubernetes manifests, Terraform modules, or other infrastructure-as-code formats. Storing these declarations in version control enables the same peer-review, auditability, and rollback practices developers already use for application code. Automated tooling then continuously detects when the live infrastructure diverges from the declared state and works to bring it back into alignment, reducing the risk of configuration drift and inadvertent misconfigurations.

Configuration drift — the state where an environment has diverged from what’s declared in version control — remains a major operational headache, especially in complex, dynamic systems. Drift can arise from ad hoc fixes, emergency updates, or manual changes made outside normal pipelines, and it can lead to inconsistencies, outages, and security gaps. By continually checking running systems against the desired state in Git and reconciling deviations automatically, GitOps workflows help teams keep environments predictable and auditable.

Policy enforcement and compliance are another natural extension of GitOps patterns. As organizations adopt declarative practices, policy-as-code engines and drift detection systems can be woven into GitOps pipelines to validate that proposed configurations meet security, compliance, or operational standards before they’re ever applied to running systems. Embedding policy checks into declarative workflows brings consistency to governance while preserving the automation and speed that devops teams expect.

GitOps – beyond Kubernetes

GitOps began as a way to bring devops discipline to Kubernetes operations, but its longer-term impact has been more subtle. In many ways, it’s been absorbed into the fabric of modern cloud-native operations, where declarative configuration, version control, and automated reconciliation are taken for granted. Today, GitOps is less about a specific set of tools or a named practice and more about an operational mindset. By treating infrastructure and configuration as versioned, auditable artifacts and relying on automation to enforce consistency, GitOps helps teams manage complexity at scale. Even as the term itself fades from the spotlight, the practices it introduced continue to shape how distributed systems are built, deployed, and operated.

Docker is a software platform for building applications based on containers—small and lightweight execution environments that make shared use of the operating system kernel but otherwise run in isolation from one another. While containers have been used in Linux and Unix systems for some time, Docker, an open source project launched in 2013, helped popularize the technology by making it easier than ever for developers to package their software to “build once and run anywhere.”

A brief history of Docker

Founded as DotCloud in 2008 by Solomon Hykes in Paris, what we now know as Docker started out as a platform as a service (PaaS) before pivoting in 2013 to focus on democratizing the underlying software containers its platform was running on.

Hykes first demoed Docker at PyCon in March 2013, explaining that Docker was created because developers kept asking for the underlying technology powering the DotCloud platform. “We did always think it would be cool to be able to say, ‘Yes, here is our low-level piece. Now you can do Linux containers with us and go do whatever you want, go build your platform.’ So that’s what we are doing.”

And so, Docker was born, with the open source project quickly picking up traction with developers and attracting the attention of high-profile technology providers like Microsoft, IBM, and Red Hat, as well as venture capitalists willing to pump millions of dollars into the innovative startup. The container revolution had begun.

What are containers?

As Hykes described it in his PyCon talk, containers are “self-contained units of software you can deliver from a server over there to a server over there, from your laptop to EC2 to a bare-metal giant server, and it will run in the same way because it is isolated at the process level and has its own file system.”

The components for doing this have long existed in operating systems like Linux. By simplifying their use and giving these bits a common interface, Docker quickly became close to a de facto industry standard for containers. Docker let developers deploy, replicate, move, and back up a workload in a single, streamlined way, using a set of reusable images to make workloads more portable and flexible than previously possible.

Also see: Why you should use Docker and OCI containers.

In the virtual machine (VM) world, something similar could be achieved by keeping applications separate while running on the same hardware. But each VM requires its own operating system, meaning VMs are typically large, slow to start up, difficult to move around, and cumbersome to maintain and upgrade.

Containers represent a defined shift from the VM era, in that they isolate execution environments while sharing the underlying OS kernel. As a result, they are speedier and far more lightweight than VMs.

Docker: The component parts

Docker took off with software developers as a novel way to package the tools required to build and launch a container. It was more streamlined and simplified than anything previously possible. Broken down into its component parts, Docker consists of the following:

• Dockerfile: Each Docker container starts with a Dockerfile. This text file provides a set of instructions to build a Docker image, including the operating system, languages, environmental variables, file locations, network ports, and any other components it needs to run. Provide someone with a Dockerfile and they can recreate the Docker image wherever they please, although the build process takes time and system resources.
• Docker image: Like a snapshot in the VM world, a Docker image is a portable, read-only executable file. It contains the instructions for creating a container and the specifications for which software components to run and how the container will run them. Docker images are far larger than Dockerfiles but require no build step: They can boot and run as-is.
• Docker run utility: Docker’s run utility is the command that launches a container. Each container is an instance of an image, and multiple instances of the same image can be run simultaneously.
• Docker Hub: Docker Hub is a repository where container images can be stored, shared, and managed. Think of it as Docker’s own version of GitHub, but specifically for containers.
• Docker Engine: Docker Engine is the core of Docker. It is the underlying client-server technology that creates and runs the containers. The Docker Engine includes a long-running daemon process called dockerd for managing containers, APIs that allow programs to communicate with the Docker daemon, and a command-line interface.
• Docker Compose: Docker Compose is a command-line tool that uses YAML files to define and run multicontainer Docker applications. It allows you to create, start, stop, and rebuild all the services from your configuration and view the status and log output of all running services.
• Docker Desktop: All of these component parts are wrapped in Docker’s Desktop application, providing a user-friendly way to build and share containerized applications and microservices.

Advantages of Docker

Docker containers provide a way to build applications that are easier to assemble, maintain, and move around than previous methods allowed. That provides several advantages to software developers:

• Docker containers are minimalistic and enable portability: Docker helps to keep applications and their environments clean and minimal by isolating them, which allows for more granular control and greater portability.
• Docker containers enable composability: Containers make it easier for developers to compose the building blocks of an application into a modular unit with easily interchangeable parts, which can speed up development cycles, feature releases, and bug fixes.
• Docker containers make orchestration and scaling easier: Because containers are lightweight, developers can launch many of them for better scaling of services, and each container instance launches many times faster than a VM. These clusters of containers do then need to be orchestrated, which is where a platform like Kubernetes typically comes in.

Also see: How to succeed with Kubernetes.

Drawbacks of Docker

Containers solve a great many problems, but they don’t solve them all. Common complaints about Docker include the following:

• Docker containers are not virtual machines: Unlike virtual machines, containers use controlled portions of the host operating system’s resources, which means elements aren’t as strictly isolated as they would be on a VM.
• Docker containers don’t provide bare-metal speed: Containers are significantly more lightweight and closer to the metal than virtual machines, but they do incur some performance overhead. If your workload requires bare-metal speed, a container will get you close but not all the way there.
• Docker containers are stateless and immutable: Containers boot and run from an image that describes their contents. That image is immutable by default—once created, it doesn’t change. But a container instance is transient. Once removed from system memory, it’s gone forever. If you want your containers to persist state across sessions, like a virtual machine, you need to design for that persistence.

Docker today

Container usage has continued to grow in tandem with cloud-native development, now the dominant model for building and running software. But these days, Docker is only a part of that puzzle.

Docker grew popular because it made it easy to move the code for an application and its dependencies from the developer’s laptop to a server. But the rise of containers led to a shift in the way applications were built—from monolithic stacks to networks of microservices. Soon, many users needed a way to orchestrate and manage groups of containers at scale.

Launched at Google, the Kubernetes open source project quickly emerged as the best way to orchestrate containers, superseding Docker’s own attempts to solve this problem with Docker Swarm (RIP). Amidst increasing funding trouble, Docker eventually sold its enterprise business to Mirantis in 2019, which has since absorbed Docker Enterprise into the Mirantis Kubernetes Engine.

The remains of Docker—which includes the original open source Docker Engine container runtime, Docker Hub image repository, and Docker Desktop application—live on under the leadership of company veteran Scott Johnston, who is looking to reorient the business around its core customer base of software developers.

The Docker Business subscription service, and the revised Docker Desktop product, both reflect those new goals: Docker Business offers tools for managing and rapidly deploying secure Docker instances, and Docker Desktop requires paid usage for organizations with more than $10 million in annual revenue and 250 or more employees. But there’s also the Docker Personal subscription tier, for individuals and companies that fall below those thresholds, so end users still have access to many of Docker’s offerings.

Docker has other offerings suited to the changing times. Docker Hardened Images, available in both free and enterprise tiers, provide application images with smaller attack surfaces and checked software components for better security. And, in step with the AI revolution, the Docker MCP Catalog and Toolkit provide Dockerized versions of tools that give AI applications broader functionality (such as by allowing access to the file system), making it easier to deploy AI apps with less risk to the surrounding environment.

Every day this past week I did something I suspect millions of other people also did: I stared at an LLM model picker and wondered which one I was supposed to want.

OpenAI just released ⁠GPT-5.6 Sol, Terra, and Luna. Sol is the flagship. Terra offers much of its intelligence for less money. Luna is cheaper still. Anthropic released ⁠Claude Sonnet 5 at the end of June and Opus 4.8 the month prior, with a little Fable 5 emerging in between. Meanwhile, Google, which seemed to be winning the model wars a few months ago, is now getting shade from Gergely Orosz, who ⁠argues that Gemini has slipped outside the top tier for software development and has been out of the major model release game for eons (May 19).

Perhaps Orosz is right. Perhaps he’ll be wrong again in six weeks. Honestly, it’s exhausting.

I use ChatGPT and Claude constantly and still have no principled idea which model to choose most of the time. I tend to click whatever looks like the biggest, most expensive option because I don’t know what I’m giving up by choosing something smaller. “Instant” sounds dangerously unserious. “Thinking” sounds expensive but powerful.

A quick survey of my LinkedIn crowd suggests others also feel my “WHICH MODEL???” pain. More importantly, I suspect most enterprises do, too.

A model doesn’t rot

Before getting carried away, however, it’s worth considering whether any of this model churn actually matters. After all, a model doesn’t rot. The model an enterprise put into production in March performs just as well in July as it did when the company selected it. “Obsolete” generally means that something better now exists, not that the deployed model suddenly stopped summarizing insurance claims or classifying support tickets. (In other words, once you have something working, the idea that “but maybe Opus 200.2 is better!” is really a FOMO problem, not a performance issue.)

Most enterprise workloads don’t live at the frontier anyway. Extraction, summarization, classification, document comparison, and customer-service assistance often work perfectly well with smaller, cheaper models. OpenAI’s own pitch for the trio of GPT-5.6 models isn’t simply that Sol is better. It’s that ⁠Terra and Luna deliver different combinations of intelligence, latency, and cost. Luna, the cheapest tier, nearly matches the previous generation’s peak performance at less than half the estimated cost, according to OpenAI.

The practical question, of course, is where to start. An enterprise can’t test every model, every reasoning setting, and every price tier before doing any work. So here’s my advice (which I don’t follow in my own work, but I’m not defining enterprise strategy and can be a little price-insensitive). Start with the cheapest credible model that appears capable of the task. Give it a representative set of real examples and, before you start testing, define what counts as good enough. If it passes, stop. If it fails, move up a tier or try a model with strengths better suited to the work.

That sounds almost offensively simple, but it reverses the way many people, including me, use these products. We start with the biggest model because we’re afraid of what we might lose. Enterprises should start lower and require evidence before paying for more intelligence.

There are exceptions, of course. For genuinely difficult work, such as autonomous coding, complex research, or high-stakes reasoning, beginning with a frontier model may save time. But even then, the goal should be to establish a quality ceiling, then test whether a cheaper model can meet it. It’s changing the question from “which model is best?” to “what is the least expensive model that reliably clears the bar for this job?”

For many workloads, that price improvement matters more than a few extra benchmark points. ⁠As I argued back in 2023, following AI hype doesn’t help anyone. If your model strategy depends on whichever benchmark screenshot is circulating on X this week, you don’t have a strategy. Not a viable one, anyway. Pick a model and ignore the noise.

Except, of course, when that noise suggests a serious signal.

Sometimes better really is better

Frontier improvements aren’t always incremental, making it advantageous to consider an upgrade. Coding is the obvious example. There’s a significant difference between a model that suggests the next few lines of code and one that can inspect a repository, plan a change, use tools, run tests, discover its own mistakes, and keep working for an extended period. That isn’t merely a nicer autocomplete experience. It can reorganize a development workflow.

This is why enterprises can’t simply standardize on an 18-month-old model and declare victory. In some areas, particularly software development and other agentic work, better models can unlock compounding productivity. A model that reliably completes 80% of a bounded task rather than 50% may justify an entirely different division of labor between humans and machines.

Still, that upgrade isn’t free.

Models differ in how they interpret instructions, call tools, manage context, refuse requests, and fail. Prompts and scaffolding tuned for one model can regress when moved to another. Or costs can explode. As one of my Oracle colleagues discovered just this week, running the same tasks in GPT 5.6 was orders of magnitude more expensive than 5.5. The API change may be trivial, but the revalidation and implications are not.

This leaves enterprises caught between two bad options. They can freeze and potentially miss out on meaningful improvements or chase every release and repeatedly test production systems on faith. What to do?

Stop making model bets

The answer is to stop making LLM bets and start making job-to-be-done bets. Stop asking which model is fastest. Instead, figure out what work you are trying to improve. What does a good result look like? How much latency and cost can the workflow tolerate? How wrong can it be before a human must intervene? Once those questions have answers, model selection becomes less opaque.

A difficult code migration may justify GPT-5.6 Sol or Claude Sonnet 5. A repetitive classification task may work just as well with Luna or another smaller model. A regulated workflow may require a model or deployment option that offers particular data controls. Sometimes the correct model is no LLM at all, like when I’m writing this post. Sorry, AI vendors! (At least you won’t get blamed for my mistakes.)

This is where evaluations become the center of enterprise AI strategy. ⁠As I’ve said before, most companies don’t have an AI quality problem so much as an AI measurement problem. Hence, a private evaluation suite built from real company work is the only leaderboard that matters. Does the new model materially improve quality? If so, use it! Does it reduce cost or latency? Again, that’s your free pass to adoption. Does the improvement justify the expense and effort of revalidation? If yes, continue.

Make model releases boring

As important as the model is, keep in mind that AI success always comes back to your company’s data, your company’s workflows, your company’s integrations, etc. That’s the ⁠dull reality behind sexy AI. Retrieval, memory, governance, data quality, observability, and feedback loops aren’t as exciting as a new model launch, but they’re what ultimately make AI truly work.

Again, when it’s time to consider something new, the principle should be to default to the least expensive model that reliably passes your evaluations. Only escalate harder tasks to more capable models when measurement shows that the premium pays. Tip: Make this invisible to employees so that the system routes to the best model for a particular prompt. As dbt Labs’ Jon Lewis expresses it, “The best model is ‘Auto’ and I won’t hear anyone say otherwise.” OpenAI’s own ⁠migration guidance recommends testing models on representative tasks, including trying a lower reasoning level rather than automatically cranking everything to the maximum.

As for me, I’ll probably keep clicking the shiniest option. I don’t have a formal evaluation suite for InfoWorld columns, and the marginal cost is a subscription I already pay. Enterprises don’t get that excuse.

A new era of customer engagement is taking shape. AI agents are quickly becoming integral to the way businesses serve, support, and sell to customers — able to respond, reason, and take action in ways that go far beyond scripted automation.

Many customer journeys, however, are still built on systems that don’t talk to each other. Customer data lives in one place, channel history in another, and AI agents often operate with only part of the picture. Customers feel the pain when they switch between channels like voice and messaging, get transferred, and have to repeat themselves yet again. It doesn’t matter that they’ve been loyal to a brand for years, every interaction feels like a cold start. That is the conversation gap.

It’s clear that AI isn’t the problem, infrastructure is. Closing the gap requires new building blocks that focus on continuity, so context can carry forward across systems, channels, human agents, and AI agents.

To bridge the gap, at SIGNAL 2026, we are introducing a new conversation layer for the Twilio Platform.

Twilio Conversation Orchestrator, Twilio Conversation Memory, and Twilio Conversation Intelligence are now generally available. Together, they help businesses coordinate interactions, preserve context, and connect human and AI agents so every conversation is more continuous and useful.

In addition to the new Conversations layer, we’re also announcing platform updates that make it easier to build, manage, and scale customer engagement on Twilio — from a reimagined Twilio Console to expanded channels and new voice AI capabilities.

New building blocks for connected conversations

The conversation gap does more than create inconsistent customer experiences. It hurts conversion and retention, increases operational costs, adds integration complexity, and makes agents less productive. The new platform capabilities we’re introducing are designed to fix that by coordinating interactions, maintaining context, and surfacing signals as conversations happen.

Conversation Orchestrator

Conversation Orchestrator helps businesses coordinate interactions across Twilio channels without complex custom logic. Teams can configure it in Console or configure their implementation with the API. It connects interactions into a single thread and manages handoffs between human agents and automated systems.

Conversation Memory

Conversation Memory creates a living, identity-resolved profile by connecting customer data with conversation history and customer traits. That means each interaction starts with the right context. It’s built specifically for LLMs to reduce latency and token usage by surfacing the most relevant details when they matter.

A new Enterprise Knowledge API (now generally available) also allows teams to deliver more relevant experiences and ground interactions in trusted business knowledge such as FAQs, policies, and product documentation.

Conversation Intelligence

Conversation Intelligence provides real-time understanding of live interactions. Using prebuilt and custom LLM-based operators, it can detect changes in sentiment, flag potential escalations, and trigger action during a conversation, not only after it ends.

That gives teams the ability to respond sooner, support agents more effectively, and improve customer outcomes while the conversation is still in progress.

Together, these products help businesses create customer experiences that feel more connected across channels.

Open by design

Twilio remains neutral by design. We start with the premise that you know your business. We aren’t here to prescribe a model, framework, or data strategy. We provide the infrastructure that helps you build customer engagement in the way that works best for your business. You pick the model and agent runtime. You own the data.

That doesn’t mean you need to start from scratch, either. We partnered with Microsoft, AWS, and others to create blueprints that support faster development. We are also introducing an open-source developer toolkit, Twilio Agent Connect (now generally available), that lets your teams connect agents built on any LLM or framework directly to Twilio’s infrastructure.

For developers, this means more flexibility. For businesses, it means less lock-in and the ability to get value from existing investments. For partners, it means more ways to build with Twilio.

A new front door

We are also introducing a reimagined Twilio Console, because as customer engagement grows more complex, managing the infrastructure behind it should feel effortless.

The new Console is a single mission control center that brings your communications, identity, and data into one experience: one login, consistent logs across every surface, an intelligent Console Assistant, transparent billing insights, and streamlined compliance workflows that no longer slow you down.

Over the coming months, we’ll roll out this new Console experience to customers automatically. You can also opt in to gain early access.

More channels, more control, smarter conversations

In addition to these launches, we are announcing several updates that expand customer reach, support enterprise requirements, and make it simpler to build on Twilio.

• Apple Messages for Business (Private beta) and Twilio Email (GA) give teams new ways to reach customers on the channels they already use.
• Data Residency for SMS (EU) (Public beta) enables teams to manage personal data locally to support regional data requirements.
• Conversation Relay enhancements add PCI compliance, HIPAA eligibility, Insights, and support for Deepgram Flux for smarter turn detection — helping AI agents better understand when a person has finished speaking.
• Stripe Projects integration enables developers and AI agents to seamlessly provision Twilio within Stripe Projects in a single, programmable CLI workflow.

Built with our customers

Bringing these new products to life required a close partnership with many beta customers and partners. This helped us understand real-world signals and needs to help make the capabilities robust from the start.

Among dozens of others, Centerfield, Constellation Dealerships, Car Finance 247, and Meera.ai leveraged Twilio to solve their own customer engagement challenges. These teams showed what is possible when businesses carry context forward, act on live conversation signals, and connect AI agents with human teams in the moments that matter.

Car Finance 247, a leading UK online car finance broker, is using Twilio to help recover stalled loan applications. When customers miss a field, need to correct information, or still need to confirm terms and conditions, AI-powered outreach across voice, SMS, and RCS, Conversation Memory tracks the application state. Conversation Orchestrator manages the outreach journey, and Flex helps bring in a human agent as needed. As Reg Rix, Co-Founder and CEO, shared:

“Because the platform remembers where each customer left off, we can pick up right where they stopped, helping them cross the finish line in a way that is modern, responsive, and genuinely helpful.”

Centerfield, a technology company powering AI-driven commerce, helps brands connect with consumers across digital and phone-based journeys. With Twilio, the team is connecting real-time conversation data with customer context to guide agents and AI systems in the moment, standardise what works, and improve performance at scale. As Aniketh Parmar, Chief Technology Officer, said:

“Performance comes down to how well every interaction moves a customer forward. We’re capturing each conversation in real time and applying what we already know about the customer to guide our agents and AI systems in the moment. With the Twilio Platform, including Conversation Orchestrator, Conversation Memory, and Conversation Intelligence, we can see what’s driving conversations so we can standardise what works, eliminate what doesn’t, and continuously improve outcomes at scale.”

Constellation Dealerships is using Twilio’s agent infrastructure to accelerate AI-powered engagement across its dealer network, moving from evaluation to measurable outcomes in days. As Richard Pineault, Director of R&D, shared:

“The value of this partnership is evident—our team progressed from evaluating Twilio’s agent infrastructure to realising measurable outcomes within days. This rapid speed-to-value exemplifies the agility and innovation required to propel the dealership industry into the future.”

Meera.ai is building on Twilio to modernise outbound engagement, replacing repeated manual follow-ups with always-on conversations across voice, SMS, and messaging. Vivek Zaveri, Chief Executive Officer, said:

“Meera.ai has partnered with Twilio since our inception to champion a conversation-first future for commerce. As the industry shifts toward real-time LLM-enabled interactions, Twilio’s Platform and the new Conversations products will help us reach customers in the moment.”

Together, these customers and partners show that the Twilio Platform can help businesses recover stalled journeys, improve live interactions, accelerate time to value, and create more connected experiences across AI agents, human teams, and every customer channel.

The next era of customer engagement starts here

As AI agents own more of customer engagement, businesses need infrastructure that keeps conversations connected across channels, systems, and teams. That means preserving context, coordinating handoffs, and acting on what is happening in real time.

That is what we are building with this next generation of the Twilio Platform: a new layer that connects channels, context, intelligence, and human and AI agents, helping businesses make every digital interaction more connected, more useful, and more amazing.

For 17 years, Twilio has helped builders create better ways for businesses to connect with their customers. In this next era, that connection matters more than ever.

Explore the new Conversations layer, try the products, and let’s build what comes next, together.