While its flagship Dreamforce event was in full swing on Wednesday, Salesforce was triaging a roughly seven and a half hour-long service outage that disrupted user access and caused “severe delays” and intermittent errors. Some customers were also unable to submit new support cases.

The service outage hit at 3:50 a.m. EDT, impacting “multiple instances across all regions,” Salesforce reported. It was marked resolved right around 3 p.m. EDT, after several hours of monitoring to determine that fixes had been successful.

Salesforce initially pegged the issue to an “external dependency failure” impacting the legacy login server. A core system component experienced increased load, limiting its capacity to process requests. The company confirmed that there were no issues with third-party infrastructure.

Beyond the obvious embarrassment from the outage occurring during Dreamforce, an analyst said the incident highlights a cloud resilience problem, rather than purely a legacy one.

“Cloud does not eliminate architectural dependencies,” said Abbas Jaffery, a principal advisory director at Info-Tech Research Group. “It can sometimes make them less visible. And when the platform is your system of record, those hidden dependencies become an enterprise risk rather than simply a technology risk.”

Rolling restarts, persistent issues throughout the day

Salesforce began experiencing service issues at 3:50 a.m. EDT on September 16, and initial investigation determined that requests were stalling while waiting on responses from an internal login service that was using up available server resources.

Initially, Salesforce blocked application programming interface (API) endpoints and attempted rolling restarts to revive the service, then pushed out fixes region-by-region. At 7:20 a.m., some customers were seeing service return to normal, and Salesforce was working on a “code-level permanent fix.”

However, the rollout did not complete for a number of instances, and some automated fixes didn’t fully resolve the issue. For example, customers reported that scheduled jobs were not running as expected, even after service was restored. Salesforce manually restarted those ‌instances.

Salesforce later reported that the impact radius was “narrower than initially understood” and saw signs of recovery by around 11 a.m. EDT, with most customers coming back online.

A sub-set of Hyperforce instances were the last to be restored. Mitigations were in place across all instances by 11:39 a.m. EDT, and Salesforce continued to monitor the issue until marking the incident resolved at 2:59 p.m. EDT.

“We apologize for how this incident affected you and your business,” Salesforce posted on its incident blog. “We will undertake a full investigation of the incident, establishing the technical trigger, the underlying cause, and preventive action to avoid a repeat in the future.”

Creating a ‘temporal’ data problem

For customers for whom Salesforce is a system of record, several hours of authentication and service disruption can create a “temporal data problem,” Info-Tech’s Jaffery explained. “Events that should have happened at different points in time may occur later, fail altogether, or arrive out of sequence,” he said.

For instance, a customer interaction may occur through another channel while Salesforce is unavailable, but an integration, workflow, or scheduled process that normally records or propagates that event is unable to run.

This has several potential consequences, Jaffery said. Transactions and customer service processes are delayed; APIs and middleware may accumulate retries, timeouts, and queues. Records can become temporarily inconsistent, and scheduled jobs and workflows may be missed. Employees could lose visibility into customer history or case status, even when the underlying data has not been lost, creating a “data divergence.”

The first mistake would be to assume that just because users can log in, the incident is over, he noted. “Enterprises should move immediately into a reconciliation and integrity phase,” Jaffery advised. This means not only verifying interactive access, but APIs, integrations, scheduled jobs, queues, workflows, automation, authentication flows, and downstream systems.

Enterprises should ask what transactions failed, partially completed, or were duplicated during the outage? Which scheduled or asynchronous processes did not execute? Did integrations retry successfully, or did they create a backlog or retry storm? Are downstream systems now consistent with Salesforce?

Security teams should also validate authentication and session behavior, privileged access, integration credentials, and any emergency changes made during recovery, Jaffery explained. “The most important question is not simply ‘Is Salesforce back?’, but ‘What did the business expect to happen during the outage, and can we prove that it actually happened?,’” he said.

What to look for in post-incident reports

A credible post-incident review from Salesforce should establish a causal chain: The trigger, dependency failure, technical propagation, customer impact, detection, mitigation, recovery, and permanent corrective action, Jaffery said.

The company should be able to answer these questions, he said:

• What was the actual initiating failure and why did the failure propagate into the login path?
• Why could the affected dependency consume sufficient capacity to affect core services?
• Why didn’t isolation or failover prevent the impact?
• Why did initial remediation attempts fail and why did the subsequent rollout require additional intervention?
• What safeguards are being added to prevent recurrence?
• How will Salesforce demonstrate that the corrective action actually works under failure conditions?

Service restoration simply tells customers: “We got it working again,” he noted. But root cause analysis tells customers: “We understand why it failed, why our controls didn’t prevent it, and what has changed so that the same failure mode is less likely to recur.”

It’s not just about ‘legacy’ pieces in the stack

One architectural lesson is that a legacy component does not have to be large to be critical, Jaffery pointed out. An older authentication service can remain part of a modern stack, and therefore become a dependency for newer services.

“The component’s age matters less than its position in the dependency graph, its blast radius, and the quality of its isolation and failure handling,” he said, pointing to this incident’s progression: Requests stalled waiting on an internal login service due to increased resource consumption led to investigation into an external dependency failure, which in turn revealed impact on a legacy login server. Finally, Salesforce said, “core system components experienced increased load, which limited its capacity to process request”.

That is a classic resilience question, Jaffery pointed out: Can a failure in one dependency remain in that one dependency, or does it become a platform-wide failure?

Modernization should not be identified simply by how much old technology has been replaced, he noted, it should also measure dependency concentration, isolation, “graceful degradation,” recovery paths, and failure blast radius.

“For enterprise architects, that is the real takeaway,” he said.

Maybe driven by agentic AI, exacerbated by layoffs

At this point, there are no obvious signs that this was a security incident, noted David Shipley, CEO of Beauceron Security. “Right now, this bears all the hallmarks of an update gone horribly wrong.”

He pointed to an incident in December 2025 when Amazon’s internal AI coding agent, Kiro, caused a 13-hour AWS outage in a mainland China region, noting, “I’m not going to be shocked if we don’t see some kind of agent role in this kind of scale disaster.”

Significant Salesforce layoffs over the last few years could also have had a negative impact on the outage and recovery, he added. “Having it happen during Dreamforce had to be all kinds of hell, though, for their sales and customer support teams,” he said. “Pour one out for them as they work on rebuilding relationships, face-to-face.”

This article originally appeared on CIO.com.

One of the first questions I ask devops organizations is to walk me through their development and operations standards. What are the non-negotiable devops practices? What are the data governance first principles? What observability standards are in place? How is security embedded in devops? This is the starting point. From there, we might review standards on how functional requirements are written. For businesses developing AI agents, I’ll ask about their non-functional requirements (NFRs) and how testing is performed.

Now that many devops organizations are using AI code generators, vibe coding, and applying spec-driven development practices, the questions increase. How does the AI know your organization’s standards? What processes monitor and enforce these standards? What are the developer responsibilities for owning the outcomes?

“Generative AI will happily hand you the movie set of an app with looks of a house from the street. The doors and windows open, and the demo runs clean,” says Mike Toole, director of security and IT at Blumira. “Behind the facade, there’s no plumbing and no wiring: no input validation, no auth boundaries, nothing actually holding it up. If your only gate is ‘does it run and look right,’ you’re shipping a set, not a building.”

One report shows that 92% of developers use AI coding tools daily in 2026 and that 41% of all global code is now AI-generated. Will all that code deliver value, operational issues, or mounting AI debt? I spoke to several experts about how to keep AI-generated code aligned with organizational standards and how to define an AI code generator’s context beyond just functional requirements.

Document like a construction specification

A general contractor in the construction industry will review building information models that provide a view of what they are developing. But many of the details are in the construction specifications, including component stipulations and performance requirements. Devops teams without equivalent documentation for their organization, architectures, and applications may have gotten away with this omission in the pre-AI era. But institutional knowledge and compliance requirements are the context AI code generators need before you share the first functional prompts with them. 

“AI-generated code stays aligned with engineering standards only when those standards are explicit, available, and difficult to bypass,” says Eddie Zhou, founding engineer at Glean. “Put architecture, approved libraries, data-handling rules, security controls, naming conventions, observability, test expectations, and non-functional requirements into specs and automated checks. Then, ensure you give the model that context but treat its output as untrusted until it passes the same reviews, tests, scans, and production monitoring as human-written code.”

Overcoming tribal knowledge was always challenging as devops teams had too much pressure to push features and little incentive to maintain documentation. Two of my top AI leadership skills are change management and agile collaborative leadership, because devops teams need practice alignment while introducing AI capabilities.  

Zhou adds, “AI amplifies ambiguity and weak governance as efficiently as good engineering. If standards live only in tribal knowledge, AI will expose that problem, not solve it.”

Encode non-functional requirements as automated tests

The problem with requirement documents and reference architectures is they aren’t directly enforceable with human or AI developers. Once a devops team agrees on standards and documents them, the next step is to develop approaches to encode them as automated acceptance criteria in CI/CD pipelines.

“AI code generators and human developers optimize for functional correctness—making the feature work—and quietly skip the non-functional requirements where most of your real standards live, including performance, security posture, error handling, observability, and auditability,” says Michael Bevilacqua, vice president of AI product management at Adeptia. “Encode your NFRs as executable acceptance criteria that generated code must pass before it merges, so ‘aligned with our standards’ becomes a gate the pipeline enforces on every change.”

An example: Performance requirements stating that all web pages should have a total page weight under 2MB can be validated during the pull request, and requiring the time to first byte (TTFB) to be under 800ms can be automated in CI/CD in a staging environment.

Requirements for stakeholders and AI

Architecture and automated non-functional requirements covering performance, security, and other organization-level compliance requirements should become the base-level context standards shared with AI-code generators. The next set of considerations for setting accurate contexts starts with application- and agent-specific requirements, their intended use cases, and specific compliance guardrails.

“CIOs are mandating AI to build apps faster, but many are realizing speed isn’t the bottleneck because more code doesn’t automatically create business value,” says Matt Healy, senior director of product strategy and marketing at Pegasystems. “Before developers write any code, organizations must understand customer needs, assess legacy systems, stay current with regulations and best practices, map enterprise architectures and integrations, and align business and IT.”

Consider three stages of understanding requirements. Once stakeholders set business value and intent, developers must first align on an implementation strategy and discuss performance, cost, and other trade-offs. Then, developers should reconvene with stakeholders and review implementation trade-offs. Healy adds, “On large projects, defining the solution and success metrics can take as much time as building it. Leaders aren’t just using AI to accelerate development, but to help executives, business analysts, product owners, and IT teams collaborate more effectively.”

The third stage is gathering the goals, user requirements, and implementation approach into a development-specific context. But we’re not done yet, because data requirements and operations considerations must also be included in the context fed to AI code generators. 

Build governance into the specs

How the application or AI agent being developed can use the data it has access to requires clear specifications. Data governance programs should have standards based on data sets, defined roles, entitlements, and usage specifications.

Kash Mehdi, vice president and field CTO at Reltio, says the teams that are pulling ahead treat data governance as an input to AI, not an audit after it. “They ground their tools in trusted, semantically consistent data models, approved specs, and security policies, so the AI inherits the organization’s standards instead of inventing its own. Without that governed context layer, you don’t scale from a handful of AI-assisted workflows to thousands; you just accumulate inconsistent code faster,” Mehdi says.

Here are two options to consider in creating standards: First, establish repurposable data sets as data products with defined integrations and usage rules. Organizations with many data sets and integration points should consider data fabrics. The second (and key requirement) is to standardize the format of data contracts, using human- and machine-readable formats so that data owners, users, and AI code generators operate from a consistent set of principles.  

“AI writes code that compiles and passes tests but quietly ignores your data contracts, so the failures show up in production as corrupted state, not build errors,” says Ed Huang, cofounder and CEO of TiDB. “The fix is to make governance machine-checkable, including schema constraints, access policies, and data-quality rules enforced at the database layer where the AI can’t route around them, not documented in a wiki the model never reads. Treat the database as the enforcement point for your standards, and it stops mattering whether a human or an agent wrote the query.”

Observability and testing first

When AI generates the code, a best practice is to use static application security testing (SAST) and other code analysis tools to perform automated code reviews. Another best practice is to put applications through penetration testing and other application security validations. But many of these tools are outside in view of what the AI developed. To get an inside view, observability and testing requirements must be included as a standard, with specific requirements around the key transactions you’re asking the AI to develop.

Sanjay Gidwani, CEO and founder at Kosmos, says, “More code volume just means more time spent investigating, and the fix isn’t reading the code more carefully before it ships. It’s connecting the observability signal, the thing that broke, back to the specific change that caused it. Without that link, you’re doing the same manual investigation as before, just with a bigger haystack.”

Testing requirements must go beyond generating automated tests, using synthetic data to expand the test patterns, and implementing continuous testing. “Instead of testing one input against one output, test whether an invariant holds across a wide range of generated inputs, which is a good fit for AI’s unbounded input space and non-deterministic outputs,” says Lior Gavish, cofounder and CTO at Monte Carlo. “I treat it as one layer in a stack with evals mapping the input space, property-based testing stress-testing it for edge cases and brittleness, and observability on live traffic checking whether production is drifting from the properties you defined as non-negotiable.”

Package and evolve the standards

Ed Frederici, CTO at Appfire, recommends codifying standards as machine-readable rules, including linters, formatters, and type checks. Merge the organizational and application standards into one context shared with the AI code-generating tool. His other recommendations:

• Enforce standards in continuous integration so violations block merges.
• Give the AI persistent context, such as CLAUDE.md, style guides, and architecture docs.
• Keep changes small and reviewable.
• Require human review of every pull request because AI-generated code must get the same scrutiny as any contributor’s. No exceptions.
• Back this approach with solid test coverage to catch regressions.
• Periodically audit for drift as your standards evolve.

It’s also important to remember that as code must be extended and maintained, so must the underlying development standards. “AI-generated code only stays aligned with your standards when it’s powered by a context engine that keeps learning, not a static snapshot of your rules,” says Itamar Friedman, CEO and cofounder at Qodo. “That means an engine that continuously adapts to your codebase’s evolving standards, your team’s PR history, and the prior decisions your engineers have already made, so the AI isn’t just following instructions but actually understands how your team works.”

As more devops organizations rely on AI code-generating tools, developers have an important opportunity to develop the standards and automated validations required to ensure what is built meets engineering and compliance requirements.

Oracle began a new round of layoffs this week, sending early-morning termination emails to staff for the second time in six months.

The latest wave began Monday with affected staff being told, “After careful consideration of Oracle’s current business needs, we have made the decision to eliminate your role as part of a broader organizational change,” according to BusinessInsider. Termination was immediate.

That’s the same wording as in the previous wave of layoffs, which took place on March 31 and affected workers in the US, India, Canada, Mexico and Uruguay. In the 12 months to May 31, Oracle cut its global workforce from about 162,000 to about 141,000, a decline of roughly 13%.

Oracle has made no public statement confirming the latest round of job cuts, but in a regulatory filing days earlier the company said it had set aside a further $700 million for restructuring charges, bringing the total charges this year to roughly $2.8 billion.

What the new termination emails say

Staff receiving the latest termination emails were told termination and compensation details would follow by DocuSign, Business Insider wrote. An internal document reviewed by the publication said severance terms varied by role and region, and some teams facing double-digit percentage cuts.

Affected employees took to social media to vent.

Eric Brunson, a senior principal offensive security researcher at Oracle, described in a LinkedIn post how he had lost access to corporate communication tools before receiving any formal notice. “I woke up to not being able to log back into Slack,” he wrote. “No new emails or notification in email and I’m locked out of there. I was able to get ahold of my manager on LinkedIn and she confirmed.” Brunson said the timing fell two days before a scheduled RSU vesting date, adding, “Probably part of the plan.”

The filing that backs up the layoff accounts

While Oracle is not talking about the layoffs, its 10-Q quarterly report states that management approved and supplemented restructuring plans “to implement certain strategic measures and further improve operational efficiencies, including through the adoption and integration of artificial intelligence technologies across certain functions.” It adds that “subsequent to August 31, 2026, our management supplemented the 2026 Restructuring Plan by approximately $700 million to reflect additional actions that we expect to take.”

Oracle has already spent $1.97 billion of the $2.1 billion restructuring charges it originally budgeted, it reported.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said the filing should be read carefully rather than as confirmation of a headcount. “The supplement is an estimate, not a bill,” he said, noting it raises the program’s estimated cost by about a third without committing Oracle to a timetable.

Gogia said the more significant shift is in the filing’s language rather than the dollar figure. Oracle’s August 2025 and February 2026 filings had described the plan as tied to “acquisitions and certain other operational activities.”

AI was named as a driver of restructuring for the first time in the Sept. 11 filing.

Why the headcount stays unconfirmed

Gogia said no verified figure exists yet for how many employees the September round affected.

He noted that 30,000 was a January forecast of the total 2026 program. Twenty-one thousand is the confirmed net decline in Oracle’s global workforce across the full fiscal year. A reported 3,000 job cuts in India on Sept. 1 remains unconfirmed by Oracle.

The $700 million restructuring supplement “cannot be divided into people,” Gogia said, since it covers termination benefits, contract termination costs and other exit costs across a program spanning multiple countries. “There is no solid headcount for the September round,” he said.

A pattern that began in March

Oracle’s first 2026 layoff wave began March 31, when the Revenue and Health Sciences unit, the SaaS and Virtual Operations Services group, and NetSuite’s India Development Centre saw some of the deepest reductions.

Figures published by Oracle for its fiscal year ending May 31, 2026, show research and development headcount fell from 50,000 to 43,000 employees during the year, sales and marketing fell from 31,000 to 25,000, and services fell from 37,000 to 34,000, according to Gogia’s analysis of the company’s own reporting.

International staff, at 92,000, saw a larger reduction than the 49,000-strong U.S. workforce, he said.

Oracle did not respond to a request for comment.

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

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

Sept. 15, 2026: Oracle forecasts 33% increase in restructuring costs as new round of layoffs hits

Oracle began a new round of layoffs this week, sending early-morning termination emails to staff for the second time in six months. Oracle has made no public statement confirming the latest round of job cuts, but in a regulatory filing days earlier the company said it had set aside a further $700 million for restructuring charges, bringing the total charges this year to roughly $2.8 billion.

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.

Feb. 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.

Jan. 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.

Jan. 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.

Jan. 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.

Cockroach Labs, the company behind distributed SQL database CockroachDB, is betting that the rise of agentic applications will make traditional database provisioning, where systems are sized for peak demand, increasingly difficult to justify as agents create highly concurrent, unpredictable and often short-lived database workloads that can leave provisioned compute idle between bursts.

Its solution to that problem is Cockroach Continuum, a database fleet management platform that pools compute and storage across isolated CockroachDB databases in an enterprise to allow capacity to be shared across workloads rather than reserved for individual systems.

That shared model can help enterprises accommodate sudden bursts of agent activity without maintaining dedicated infrastructure for every database, while paying only for consumption rather than peak capacity, the company said Tuesday.

Continuum does this by combining database virtualization with Cockroach Plenum, a feature that separates compute from storage so that the two capacities can scale independently.

It also draws on Cockroach Aegis, which uses an AI-assisted operations layer to diagnose issues and recommend actions across an enterprise’s database estate to help database administrators (DBAs) reduce the manual work involved in monitoring, troubleshooting and tuning databases while retaining control through policies, the company said.

What Continuum could mean for CIOs

That reduction in manual work for DBAs is likely to benefit CIOs in terms of operational cost.

“Enterprises don’t just pay for database capacity. They pay people to provision, monitor, tune, troubleshoot and scale these environments. If Cockroach can automate a meaningful portion of that work, there is value there and a chance to offset costs,” said Ashish Chaturvedi, executive research leader at HFS Research.

For more direct infrastructure-related cost savings via Continuum, though, CIOs will need to look at how their database estates are provisioned.

Stephanie Walter, practice lead of AI stack at HyperFrame Research, said the greatest savings will come from large fleets of independently provisioned databases that spend much of their time underused: “Sharing capacity across workloads with different demand patterns could substantially improve utilization,” she said.

Not all enterprises will benefit: “Cost savings will be less meaningful for databases that already run near capacity or require tightly dedicated resources,” she said.

One caveat is that, because Continuum shifts the calculation of database costs from provisioned capacity to consumption, unexpected bursts of activity could make it harder for CIOs to forecast database costs.

CIOs will therefore need to assess their own workload patterns and test whether the higher utilization and reduced idle capacity actually translate into lower overall database costs, rather than assuming that consumption-based pricing will automatically deliver savings, Walter said.

While Continuum may simplify database management, it could also deepen dependence on CockroachDB and make workloads harder to move elsewhere, she said — with the added risk that, by coupling independent databases together onto one platform, it creates a new single point of failure.

What Continuum could mean for developers

For developers though, the shift to Continuum could reduce the time and effort required to build applications, especially agentic ones.

Development teams using Continuum can design applications without having to worry as much about the database compute and storage capacity those applications will need, when that capacity needs to scale, or the operational work required to provision and manage it, said HFS’s Chaturvedi.

But, said Walter, those advantages don’t come without challenges.

“Pooling infrastructure as Continuum does is more likely to create questions around workload isolation, performance predictability, and debugging,” she said. “Enterprise teams will want to know whether one demanding workload can affect others and whether they can trace a performance problem through the shared environment.”

Who is likely to adopt Continuum

Existing CockroachDB customers with large fleets of distributed transactional databases are likely to be among the earliest adopters of Continuum, Walter said.

SaaS companies, financial services firms, digital platforms and AI-native businesses could also be strong candidates, particularly where applications generate unpredictable demand and database capacity needs to scale quickly, she said.

For those enterprises, though, one of the capabilities that could make Continuum most useful for unpredictable workloads is yet to arrive.

Automatic compute scaling, which will help scale compute up or down as necessary to maximize cost savings without compromising availability, is “coming soon,” the company said.

For CIOs and CDOs heading into Microsoft Fabric and SQL Community Conference Europe, the main question is not which data technology sits at the center. It is whether the data platform improves revenue, productivity, and decision speed while creating a trusted foundation for AI at scale. That should drive the data strategy.

Enterprise AI is forcing companies to tackle a familiar problem, with data spread across ERP, CRM, operational systems, databases, applications, warehouses, and analytics platforms built over years. That was manageable for reporting and point-to-point integration. Copilots and agents raise the stakes because they need to reason across customers, orders, inventory, financial implications, operating constraints, permissions, and business rules at the same time.

That moves the discussion from architecture into CIO and CDO strategy. What outcomes are we trying to improve? What data and context are required? What needs to move versus connect? Where do Microsoft Fabric, Azure Databases, and other platforms fit? How will governance and authority follow the data? Where should the data be stored and what sovereignty or regulatory restrictions apply? And how will we measure results?

Microsoft is positioning its broader data platform around AI business value. That framing is useful when it translates into an operating strategy. As I wrote in Forbes about Microsoft Build in June, the next phase of AI depends less on the model and more on data readiness, governance, interoperability, and operational execution. The conference should give customers a closer view of how those pieces come together. The question for CIOs and CDOs is how that direction fits their existing data estate.

The AI problem is usually a data problem

Many AI initiatives stall on data readiness rather than the model itself. The issue is not one statistic. It is the combination of fragmented data, inconsistent definitions, and the effort needed to prepare and govern information before AI can use it reliably.

Copilots and agents need trusted context around customers, financials, inventory, operations, permissions, and business rules. AI exposes existing weaknesses. Duplicate customers, poor product data, and inaccurate inventory become more consequential when AI is recommending or taking action. AI does not create the data quality problem; it makes the operating cost harder to ignore.

The goal is to make more of the existing data estate useful for AI without turning modernization into a wholesale rebuild.

Microsoft Fabric and Azure Databases play different roles

For customers, the question is how Microsoft’s broad portfolio translates into architectural choices, including what should move, what should connect, and what can stay in place without limiting the result the business is trying to achieve.

Azure Databases support transactional and operational workloads, each with distinct performance and application requirements. Fabric provides a unified SaaS experience across data integration, engineering, analytics, real-time intelligence, data science, and business intelligence. Fabric IQ adds a semantic intelligence layer that provides shared business context for Copilot and agents. Some workloads may belong in Fabric, others in Azure Databases, and some on third-party platforms; moving them adds cost without creating enough business value.

The architecture should follow workload, data maturity, economics, and business value, not a single destination.

Connected data has to improve the decision

Microsoft’s broader data platform can connect systems of record and operational applications with analytics and AI. Azure Databases, Fabric, OneLake, Power BI, and governance can play different roles. What matters is whether those connections shorten the path from operational data to a decision, not how neatly the products line up.

A customer record may live in CRM, orders in ERP, inventory in operational databases, and demand models in an analytical environment. Fabric Real-Time Intelligence can add live events to that picture. A manufacturer can stream equipment events or production events, detect a developing issue, and alert teams while there is still time to change the outcome. The value comes from reasoning across that context so the business can understand what is happening, why it matters, and what action makes sense next.

Trusted context turns data into AI business value

I recently wrote in InfoWorld that trusted context is becoming the currency for enterprise AI. That is especially relevant here because once copilots and agents rely on enterprise data, then quality, permissions, lineage, and security become operating requirements, not background data issues.

Knowing inventory is 8,000 units is data. Knowing whether those units are available, committed elsewhere, in the wrong distribution center, or on quality hold is business context. As AI moves from answering questions to taking action, that context determines whether the result can be trusted.

Microsoft frames AI business value around growth, insight, and scale. Each needs an operating definition. Growth can mean new revenue, better customer responsiveness, or growing without adding cost at the same rate. Insight means combining context across Microsoft 365, Fabric, and operational systems to make better decisions faster. Scale means expanding AI without rebuilding governance for every use case.

A reusable data foundation can also reduce pipeline and management effort while improving decisions around pricing, inventory, customers, supply chain, and finance. Microsoft cites coverage of more than 100 standards. The practical question is whether AI can scale without risk and complexity growing at the same pace. For multinational or regulated organizations, that also includes where data is stored and processed and which sovereignty requirements apply.

Agentic workloads raise the bar. Organizations need to know what information informed a decision, who or what had authority to act, which policies applied, and how a wrong action can be reviewed or reversed.

That is where the data platform becomes part of what I describe as decision architecture. Context explains what is happening. Decision logic determines what should happen next. Authority defines what a person or agent can do. Orchestration coordinates systems and people. Execution completes the action and provides a path to review or reverse it. Trusted data feeds that architecture. Without trusted data, automation will be difficult to trust at scale.

Microsoft’s breadth is most useful when it reduces complexity

Microsoft’s advantage may be its enterprise footprint. Azure Databases, Fabric, OneLake, Power BI, Microsoft 365, business applications, developer tools, identity, security, and partners touch many of the places where information is created and work gets done.

Most customers will keep data across multiple systems. Microsoft’s opportunity is to use that breadth to create a simpler path from data to workflow to business outcome without requiring everything to live in one place.

Customer proof points matter because data strategies can get abstract. The KPMG Australia example is useful because KymChat moved beyond an internal productivity tool into a client-facing offering, creating a path from internal AI investment to new business. Microsoft also reports that improvements to the data foundation increased KymChat search quality from 50% to 91%, with results delivered in under a second.

BMW Group provides a more recognizable operating example. Microsoft says Azure helped BMW make vehicle data delivery and analysis 10 times faster, cutting the lead time for engineering insights from days to hours or minutes. Audi adds an AI deployment example. It used Azure AI Foundry, Azure App Service, and Azure Cosmos DB to launch a secure HR assistant in two weeks and is extending the same framework to eight additional agents across the enterprise. Levi Strauss & Co. offers another angle. It consolidated nine ERP systems on Azure, reported a twofold improvement in latency and a 60% improvement in IOPS and now uses Fabric IQ for companywide cost reporting. These are the kinds of proof points that connect platform architecture to time, cost, productivity, and decision quality.

Interoperability matters across the enterprise estate

Microsoft sits in a market with Snowflake, AWS, Google Cloud, Oracle, and others, each with different strengths across infrastructure, databases, analytics, openness, and AI. Databricks also plays an important role, but the connection is different because Azure Databricks is provided as a first-party service directly on Azure. Most large enterprises will remain heterogeneous, making interoperability, cross-platform governance, and incremental modernization central to strategy.

The opportunity is to make Microsoft’s data platform useful across the mix of systems that customers already run. Most enterprises are not starting from a blank sheet, so the value is in helping them connect, govern, and modernize over time without forcing everything into one place.

CIO and CDO strategy should start with the business outcome

This is where the conversation becomes most useful at the Microsoft Fabric and SQL Community Conference Europe. For CIOs and CDOs, an architecture diagram matters more when it is backed by a decision model. A useful data and AI strategy should work backward from the business outcome through five decisions.

1. Start with the business outcome. Define what needs to improve, including revenue, margin, productivity, customer experience, decision speed, working capital, or time to value. Let the technology choice follow the objective.
2. Map the data and context required. Identify the operational, transactional, and analytical information, semantics, and business rules that influence the outcome.
3. Decide what moves and what connects. Determine where Fabric, Azure Databases, and non-Microsoft platforms fit. Let workload, economics, and value drive modernization rather than a single destination.
4. Design governance, authority, and economics together. Define how security, permissions, lineage, and controls span operational, analytical, and AI workloads, and identify opportunities to simplify pipeline, integration, and management efforts.
5. Measure the operating result. Set KPIs before scaling. Technology adoption is not the outcome. CIOs and CDOs should know which business measures should change, by how much, and over what period.

That is how the data platform becomes enterprise strategy, tying architecture, governance, AI, and economics to operating outcomes and bringing business leaders into the discussion before the architecture is set.

What customers will still want to understand

Microsoft has many of the pieces required to connect enterprise data, analytics, and AI. Customers will keep looking for guidance on the roles of Azure Databases, Fabric, and the broader data platform, along with cost, licensing, migration, and governance across heterogeneous environments. They will also want more proof points from KPMG, BMW Group, Audi, and Levi Strauss & Co. that start with a business result.

That is where Microsoft’s positioning around a data platform for AI business value comes together. The value is in helping customers connect platform choices to better decisions, faster action, and measurable operating results.

After three decades in enterprise technology, I keep coming back to the same point. The technology is only part of the answer. For CIOs and CDOs, the harder part is deciding how the data platform fits into the way the business operates, how decisions get made, and where AI can improve the outcome. That is really the question behind how Microsoft connects your data across the enterprise. The conference should give customers a useful view of how Microsoft is bringing those pieces together and where that can create better business outcomes.

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

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

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

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

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

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

Don’t put software on the org chart

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

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

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

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

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

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

The employee metaphor has a job to do

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

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

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

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

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

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

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

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

At DXC, professional agents are software

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

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

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

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

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

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

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

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

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

The agent itself never gets handed the blame.

Maybe treat it like an intern after all

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

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

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

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

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

Yet the intern analogy has proved useful operationally.

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

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

Borrow from HR, but keep humans in charge

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

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

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

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

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

Related reading:

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

Postgres just turned 30. Over those three decades, I’ve watched it pick up hot standby replication, logical replication, asynchronous IO, just-in-time compilation, and dozens of other features built for enterprise workloads. Every one of them solved a real problem and raised the floor on what a DBA needs to know just to do the job well.

I don’t think most people outside this world fully register how much that floor has risen. In the early days, improvements were small and mostly about stability. Now, 30 years in, the focus is squarely on enterprise functionality, and that functionality comes with complexity attached. The more you build, the more there is to understand and manage, and that increases every year.

Hiring more people doesn’t solve this

Most organizations treat a scaling database problem as a staffing problem. Hire enough DBAs and you’re covered. I think that’s the wrong way to look at it entirely.

It’s not far off from the old “too many cooks spoil the broth” problem. You don’t make better soup by adding cooks. You make better soup with a better chef. A 100-terabyte database with serious performance issues doesn’t get fixed by putting 10 DBAs on it instead of one. It gets fixed by someone who has seen that failure before and knows exactly where to look.

Experienced DBAs are expensive and hard to find, and the problem is only getting worse. A few years ago, it was IoT driving demand for time series expertise at scale. Now it’s AI, and organizations are building enormous databases to support retrieval pipelines and large language model (LLM) training, often without the experience on hand to run them safely.

Where human error comes from

Humans are unpredictable. We make assumptions. Sometimes, we think the process is getting in the way, so we take a shortcut around it. And we make mistakes because that’s simply human nature.

I don’t think that’s something we’re ever going to fully engineer away as long as a person is in the loop, and honestly, we want a person in the loop making the real decisions. So it becomes a balancing act. You have to understand the mistakes people tend to make, build the discipline to follow good processes consistently, and still know when a situation calls for judgment rather than a checklist.

Why AI helps more than people expect

I think this is where AI has earned its place. It’s not as a replacement for the DBA, but as something that follows a process more consistently than a person under pressure tends to.

Modern AI systems still have problems with hallucination and getting the full picture right. However, with the right guardrails, auditing, and tracking in place, they are able to follow the process very well. It is much easier for me to say, “Forget it, I know a shortcut, I’ll just push this through,” than it is for a well-constrained model to deviate from its instructions. As long as the instructions are clearly defined, LLMs tend to stick to them.

Another advantage worth naming is if an LLM is doing the diagnostic work, you can put much stronger gating around its ability to actually make changes. You can let it follow a tight, well-defined process to diagnose a problem while still requiring a human to approve anything that touches the live system, whether that’s creating an index, dropping one, or changing a configuration value.

That combination gets you to a solution far faster than the old way, using the model’s training plus whatever supplemental knowledge you feed it through retrieval-augmented generation (RAG), while keeping a person at the one point where it actually matters. Did the model get the diagnosis right? Does the proposed fix line up with the actual problem? That’s the question a human needs to answer before anything gets applied.

The industry hasn’t figured out the limits yet

I am not sure we are far enough along the path as an industry to really know what we’re getting wrong. I am working through these questions myself right now, looking at autonomous agents for Postgres operations and where the real risk is.

What’s clear to me already is that strong guardrails matter in two places, not one. You need guardrails on the prompts so the model verifies its findings and doesn’t hallucinate into a bad recommendation. And you also need guardrails on what the model is actually allowed to do. Letting an agent create an index carries a manageable risk. Letting it truncate your orders table does not. Auditing matters just as much; when something does go wrong, you need to see exactly what happened and undo it. The fallback needs to stay in place until the industry broadly trusts these systems more than it trusts a human.

Picture a load spike that hits overnight, the kind where batch processing that normally runs fine suddenly does not. The old way means spending hours trawling logs, index stats, table stats, and query performance before you land on a likely cause and you can apply a fix.

Put an LLM on that same problem and the hours-long process compresses into minutes. It’s the same productivity shift we’ve already seen in software development, where an experienced user with the right skills and guardrails can get LLM output that matches or beats a junior developer’s work. The quality comes down to this process: Structure the work, define a clear spec, build the implementation plan, then verify each stage before moving on.

The same discipline applies to database operations. The worst thing you can do is rush in and say to the model, “This happened, go fix it.” You need to guide the tools properly to get good results from them. When it’s done right, it works.

Where this goes from here

A few things need to be true for this to scale across the enterprise. Frontier models already understand Postgres well, but they don’t know everything, so you need to feed them supplemental knowledge alongside that training. Full documentation matters here, so do internal runbooks. The process has to require the model to actually consult that material rather than coast on what it already knows.

I expect the same kind of structured skills that are common in AI-assisted development, the step-by-step approach to planning and verification, to show up specifically for Postgres operations. That will make the job easier for DBAs, and easier is what matters.

We’re probably not far from agents that sit and watch a Postgres instance around the clock and rarely need a human to step in. The slower part is trust. For example, look at how long it took people to actually believe AI-written code was any good. I would guess it is the same pattern here, but I don’t doubt for a second that we will get there.

In the meantime, you do not need to hand an LLM the keys to your database tomorrow. Start smaller and begin with read access to your monitoring data. It’s a low-risk place to start.

An agent watching constantly can catch the kind of slow, compounding anomaly that threshold-based alerting tends to miss, a gradual rise in IO alongside a gradual rise in memory, and flag it before it becomes the kind of outage that costs real money every hour it runs.

That’s not a small thing. The DBA shortage is not going away on its own, and waiting for the industry to fully trust autonomous agents before using AI at all is the same as falling behind. The teams that figure out where the human belongs in this process are the ones who’ll be ready when the rest of the industry catches up.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Entrusting mission-critical workloads in the cloud puts a lot of pressure on IT operations to build resilience into data infrastructure they don’t even own — to make sure that when an incident happens elsewhere, the lights stay on at home. Fortunately, savvy CIOs are learning they can architect their systems for resilience and high availability to keep mission-critical cloud workloads running when disaster strikes.

When designing for resilient, highly available cloud workloads it is critical to understand the details of your cloud provider’s service level agreement (SLA) and recognize that providers operate on a shared responsibility model. That means there are many things the provider is responsible for, but the workloads you’ve got running on their infrastructure are not among them. With that in mind, we’ll need to focus on three core goals essential to building and maintaining highly available, resilient cloud workloads:

1. Identify and eliminate single points of failure
2. Close or mitigate conditions leading to recovery gaps, and
3. Overcome operational complexity.

Remember, everything fails

Designing for application-level resilience and high availability is predicated on recognizing that everything fails. That’s not pessimism, but realism, and embracing this fact gives you a leg up in architecting resilient IT. Hardware breaks down, disasters occur, mistakes are made, software incompatibilities are common, and limits are exceeded that result in loss of service. There are four categories of failure that need to be taken into consideration when designing for resilience and high availability:

1. Single point of failure: As the term suggests, this describes a non-redundant device, route, or point of connectivity that results in zero fault tolerance in the event of an incident involving that choke point.
2. Excessive load: Exceeding the throughput or memory limits of a device or service can result in latency, service degradation, or failure affecting service level agreements (SLA) and service level objectives (SLO).
3. Misconfigurations and bugs: Perhaps the most common source of failure, these breakdowns often occur during installation, maintenance, and patching leading to the incorrect execution of code.
4. Shared fate: This type of failure is like non-redundant connectivity. When you rely on third-party services and there is an incident beyond your control affecting a partner, it can result in downtime or service degradation.

Having identified the primary challenges to maintaining service uptime and continuity, let’s explore an approach to achieving resilience through high availability, disaster recovery, and the process of continuous improvement.

Working toward continuous improvement

High availability is often thought of as measured by “X Nines,” representing the percentage of time a service is operational over the course of a specified time frame, usually a year. Six nines of availability, for example, means that a service can be expected to run 99.9999% of the time, or 8759.99 hours out of 8760 in a year. That sounds good until a disaster happens. Then we shift to disaster recovery, or the ability to restore a service and its associated data quickly and correctly when things go wrong. Disaster recovery is often measured and evaluated by a recovery point objective (RPO), which is the maximum acceptable amount of data loss, and a recovery time objective (RTO), which is the maximum acceptable amount of time a service can be down.

By learning from our mistakes, incidents, and the ongoing process of testing, observing, and evaluating IT operations, we apply new information in the goal of continuous improvement to get peak performance out of our investments in IT. But because we’re addressing resilience and high availability in the context of workloads operating in the cloud, we should understand the shared responsibility model that most cloud service providers use. Details may differ from provider to provider, but the shared responsibility model of cloud services is your vendor’s statement of responsibility for maintaining its infrastructure and ability to deliver storage and compute capacity in a region and availability zone where you have a need. In return, you accept responsibility for the configuration, maintenance, availability and operation of the workloads you choose to run on your vendor’s cloud.

A cloud service provider will typically operate and maintain physical infrastructure in different areas around the world, with multiple availability zones in each area. Each availability zone will have one or more data centers with its own power, cooling, and other operational support. Data centers are typically located far enough from each other to minimize the chance that a natural or regional disaster will affect multiple data centers, but close enough that they can operate as a single, logical data center — thereby maximizing bandwidth and throughput, while minimizing latency. This is redundancy at scale that eliminates a single point of data center failure.

Designing for application high availability and disaster recovery

To build out or retrofit your infrastructure for application-level resilience and high availability, there are four things you must have: clustering, data replication, failover, and disaster recovery. Let’s look at each and how to architect for them.

Clustering

Clustering is the practice of connecting like and complementary systems to improve availability and reliability. Think of it as putting into practice the maxim “the whole is greater than the sum of its parts.” Traditionally, clustering was achieved using hardware, specifically storage area networks (SAN), to connect and support systems in a physical data center. However, in the cloud age, hardware-based clustering has proven to be expensive and inflexible. Software-based SANless clustering with products such as SIOS LifeKeeper delivers all the benefits of the traditional approach while also working better in cloud and hybrid environments.

SANless clusters enable the configuration of nodes based on the organization’s operational priorities and work easily for enterprises running geographically distributed data centers or cloud availability zones. Because SIOS LifeKeeper supports single-site, multi-site, cloud, or mixed environments, and affords real-time access to operational data during incidents requiring failover, it is ideal when mission-critical workloads are distributed across multiple providers. LifeKeeper clusters create redundancy and eliminate single points of failure, both of which are necessary for achieving high availability. For enterprises operating hybrid or multi-cloud infrastructure, this enables you to shift to secondary resources should your primary service experience an outage.

Data replication

IT operations and your mission-critical applications rely on data, so it’s vital to keep data in sync between nodes in real time, whether synchronously or asynchronously, depending on the application. When working to achieve high availability, it’s important to monitor the health of infrastructure elements and the applications you’re running. This ensures that downtime affecting the application and any downstream dependencies is detected so that failover and recovery to a standby node can occur automatically. When everything is in sync and data replication is happening, this ensures complete readiness; there’s no need to rebuild a database or for any manual operations. And with SANless clusters using SIOS DataKeeper, this will happen across availability zones, regions, and to or from on-premises, cloud, or multi-cloud resources in hybrid environments.

What’s important here is that the software you use for SANless clustering be application aware. That’s SIOS LifeKeeper. Because high availability and resilience mean not just failing over to standby infrastructure resources, but for properly failing over mission-critical workloads (think SQL Server, SAP, Postgres, or industry-specific applications like Meditech), the software needs to understand how those applications work so that they can recover and restart cleanly. Otherwise, when failover occurs, there’s a good chance that workload is not going to be available, or it could be out of sync. When your software is application-aware, failover and recovery is fast and predictable with no API dependencies or last-minute provisioning.

Failover

With SIOS SANless application-aware clustering and replication in place, you can automate real-time failover and achieve the goal of high availability and resilience. Because we’ve chosen a software-based approach, failover occurs in the data plane, so there’s no need to spin up a new instance following an incident. Everything is already running, in sync, and ready. Furthermore, failover is immediate and it’s predictable. That is what you need when dealing with mission-critical workloads. Consider that many of the mission-critical applications you use were not designed to operate in the cloud, so even if your infrastructure is resilient, the application itself represents a single point of failure. Without replication, application monitoring, and real-time failover automation, you risk loss of revenue, security degradation, or worse.

Depending on the size of your enterprise and the industry in which it operates, an hour of downtime can cost $1 million or more, and 90% of organizations report costs of at least $300,000 per hour. Beyond that simple loss of revenue are soft costs associated with reputation damage, lost productivity, missed transactions, and more. Revenue protection is only part of the equation; it is about protecting the business.

Disaster recovery

Any design for high availability and resilience must also take into consideration the risk of a non-IT disaster that disrupts operations. Natural disasters like fires, earthquakes, and floods, or disasters caused by humans like the accidental severing of a trunkline or an act of sabotage conspire to bring operations to a sudden halt. Clustering, replication, and failover all play into disaster recovery, but there are additional considerations that must be addressed. For disaster recovery (DR), you’re going to want geographic distance between your primary site and your DR site to minimize the risk that a regional event doesn’t affect both. That means you’re going to want asynchronous (or near real-time) data replication.

Asynchronous replication is typically only a second or less behind synchronous replication, so it is de facto real-time, but that delay allows you to replicate across higher-latency networks and across longer distances. And because replication is happening continuously, even if you have a local failover between node one and node two, replication to the DR node doesn’t stop. Instead, when node two comes online it becomes the source of the mirror replicating to the DR site and back to node one once it is restored.

Patching and planned maintenance

Beyond the simplicity and cost advantages that come from taking a software-based approach to designing your cloud and hybrid infrastructure for high availability there is another big benefit. You are also better prepared to respond to the increased pressure on rapid implementation of software updates and security patches. No one wants to be the person responsible for taking too long to patch for a vulnerability, but every time you touch a system, you’re introducing the risk of error. That risk is greater when dealing with the cloud where you have less control over the underlying infrastructure, more abstraction, and a lot more moving parts.

In short, patches can break things as well as fix them. They have thus become a significant contributing factor as a cause of downtime. With SANless clusters you’re able to minimize that risk by enabling rolling updates, meaning you can patch a secondary server, verify that the patch didn’t break anything, and then patch the original server where the primary application is still running. If something does break on the secondary server, the primary is unaffected and you can quickly recover to the previous state while you figure out what went wrong. This simplifies the process of executing ad hoc patches and performing planned maintenance, mitigating the associated risks.

An investment in cloud and hybrid infrastructure and services doesn’t have to put IT operations at the mercy of a third party. With the right approach, you can design for high availability and resilience and keep your mission-critical workloads running in the cloud even when things outside of your control go wrong.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.