CIO

A couple of years ago, I did some work with a client’s legacy system. But this wasn’t an ancient relic written in COBOL or Assembler; it was a relatively new C++ application. Let’s call it “App1.” So, when did App1 become “legacy?” When did my client’s relationship with it sour? ## A stale relationship? The UK Government defines legacy IT as “outdated and often obsolete technology.” Or in other words, too old. But when is an application too old? It’s unlikely my client was bored with App1 when it was first commissioned. Even after a honeymoon period, there would have been years when things were going along just fine. But somewhere along the way, the relationship went downhill. The Linux operating system was created in 1991, now over 35 years old. Yet it’s still a key server operating system, not exactly outdated. Java was created in 1995, but at 31 years old remains a strategic programming language. Although not a baby, App1 was younger than both: around 15-20 years old at the time. Some may be happy in a 20-year relationship; others will be ready for something else far before this. Although something becomes legacy with time, there’s no set timeframe for when this happens. It could be 35 years; it could be one. Something happened in the past to make App1 legacy. But, what? ## Money issues The Australian government says that legacy applications can be, amongst other things, “no longer cost-effective.” Like the US government, many organizations spend a lot of their money on legacy systems. But are they really more expensive? Many believe so. A study by banking consulting firm Digital Bank Expert states that modernizing legacy IT infrastructure has reduced banks’ TCO by up to 52%. Not everyone agrees. HPE NonStop expert Justin Simonds agrees with Rocket Software that legacy systems aren’t as expensive as many think. Something doesn’t have to cost more to become legacy: it only needs people to believe it. My application client was aware of costs, but that didn’t seem a big deal. But it was very different for the mainframe infrastructure team and management. Multiple CIOs had set a direction to move away from the mainframe because of its perceived cost alone. Like a frog in hot water, there probably wasn’t a particular time when my client’s legacy application costs became a problem. But at some point, they were noticed, and this crack in the relationship grew. ## Misunderstood Legacy skills are a key concern to many of my clients. They lament the lack of COBOL and Assembler programmers, and staff that understands the mainframe. Like many other clients, they have had little interest in training new graduates, despite options like those from IBM. Understanding the technology or programming language isn’t enough. Legacy systems can be complex, taking even the best experts time to understand. My clients had lost most of their technical knowledge of App1 as older experts retired and weren’t replaced. To mitigate this, they relied on a service provider, who themselves had issues finding staff. This probably became apparent to my client when one of those staff retired, or their service provider struggled to fix a problem. ## Not feeling safe In 2022, Fujitsu announced the retirement of their legacy GS21 mainframes, ending support in 2035. Telling your partner that it’s over is unlikely to help the relationship, even if it is 13 years in the future. If GS21 clients didn’t consider their mainframe legacy before 2022, they do now. All systems require a technology stack supported by someone providing fixes and help to keep it running: vendors or staff. But as highlighted by the US GAO, a big reason for support is security. High-profile issues like the Apache log4j vulnerability were only fixed for supported systems. GS21 mainframes are older technology, missing basic operating system enhancements like 64-bit addressing. So, GS21 users will have considered it legacy far before 2022. Is this when something becomes legacy – when it stops changing or innovating? App1 ran on IBM’s flagship IBM Z mainframe: hardware less than two years old. The rest of the technology stack was similar: recent versions of the z/OS operating system and CICS transaction manager with regular security patches and fixes. In fact, a 2025 survey by ITIC found that IBM Z mainframes had the lowest downtime due to security hacks of any platform. Security wasn’t an issue. Another non-issue was an inert technology stack. The IBM Z mainframes ecosystem continues to adapt with features like onboard AI functionality, new languages like Python and Node.js, and support for Java SpringBoot applications. But the stack was still seen as legacy, and that’s all it takes. A big issue was the application itself. There had been no major enhancements for many years, and my client had little interest in leveraging the new IBM mainframe goodies. Few changes meant that support staff had less experience in making changes, which slowly morphed into a culture where changes were resisted by the supporting teams. At the same site, another application group was making big changes to their application: moving from a legacy file-based storage system to Db2. Despite this, that second application was also considered legacy. Innovation isn’t guaranteed protection against the legacy label. Despite using an active and secure technology stack, App1 itself was stagnant. This didn’t happen in an instant, but was a result of ongoing management decisions, helping App1 win the legacy badge. But this wasn’t the only issue. ## Not enough from the relationship The user interface of App1 was old: old web pages, and even some 3270 screens, like relying on a UNIX Telnet screen. This was fine when the application was first created, but unpopular today. They could have leveraged some of that new IBM mainframe technology but could not get the budget. The old screens were there to stay. Changing legacy systems is always harder than creating new ones. As it gets older, it has more history and becomes more complicated. Any change must satisfy the requirement but also avoid breaking anything else. This ‘technical debt’ can slow down changes, frustrating a business that isn’t standing still. My client felt this, with changes requiring weeks to be migrated into production. Legacy systems can be mission-critical, and there was little tolerance for an outage of App1. No one wants a partner that they’re ashamed of taking out in public, and none saw App1 as attractive. And it’s not just the user interface. I had another client ready to move their application from the mainframe simply because of marketing: a flagship system running on the mainframe was not sexy. When did App1 become difficult and ugly? Perhaps when the business needed a change that could not be made. Or when a manager saw the old interfaces and didn’t like them. ## The moment it changes There’s no official definition of ‘legacy,’ no metric or equation to calculate when something becomes legacy. But the answer is simple: App1 became legacy the moment my client started looking for something better. I don’t know when that was: it’s unlikely there was a ‘eureka’ moment. Senior management fell out with App1 because of the perceived cost; the business unit because the unattractive application resisted change. The application support team was also ready to move on, with few staff capable of supporting App1. The last time I talked with my client, the relationship hadn’t ended yet. They were on the IT application equivalent of dating apps, while their legacy relationship continued to do their critical processing. The reasons they disliked App1 weren’t enough to overcome the cost and risk of moving away. It’s not too late for this relationship. My client could refresh it: train new staff, invest in new technologies. More likely, things will reach a breaking point, and my client will swipe right and move on.

During my younger days in the IT industry, my favourite book was Jack Welch’s “Straight from the Gut.” Anybody who was anybody and aspiring to be a hot-shot leader or manager spoke about this book. Truthfully, it is a good book. But I am not sure that many of us, myself included, really learned much from it. Now, as I sit on the other end of my career, I think that perhaps every age produces its own idea of leadership, and people like me sit in a strange transitional phase where we may have to let go of the past and adapt to the future rapidly. The agrarian age rewarded command. The industrial age rewarded scale. The digital age rewarded speed. Most of my career was spent here. Each age changed not just the tools of production, but the assumptions behind leadership itself. The age of AI will do the same, but with a twist not witnessed before. AI will make intelligence itself sit inside the organization. As I watch AI adoption happening around me, I realize that many organizations mistake AI for the next chapter of digital transformation. Digital transformation changed how organizations connected systems and served customers. AI changes how organizations think, decide, learn and act. The question I keep returning to is simpler to state, and harder to answer. What does leadership look like when intelligence no longer belongs exclusively to humans? Most of modern management history assumed that strategy started at the top, was broken into sub-plans, translated into targets and distributed across people and departments. Intelligence sat at the top and flowed downwards. Employees executed. Systems recorded. Processes coordinated. Dashboards supported. The whole model rested on a clean assumption that humans decide and machines execute. Machines are not just executing anymore. They detect patterns, analyse risks, generate content, recommend action and in some cases take action. They do not just follow workflows. They route, optimize and adapt to them. This does not mean machines have become conscious. It means the distinction between intelligence and consciousness has become stark. A chess programme can beat a grandmaster without feeling any joy. That distinction should make leaders uneasy because a system does not need consciousness to shape an enterprise. It just needs to perform effectively under uncertain conditions. As agentic AI embeds further, systems will not only participate in knowledge work, but they will also act. They will take goals, break them into steps, use tools and data, and execute with decreasing levels of human intervention. What happens to leadership in such environments? The great managerial ambition used to be how to make people perform better with tools. The question now is how to govern systems that can act with partial autonomy inside human institutions. This is not a technology problem. It is a problem of intent, judgment, trust and accountability. Six shifts follow from this. I will name them plainly, because I think the language around AI leadership has become too comfortable and too vague, and vague language is exactly how organizations avoid hard decisions. ## Shift #1: From control to context Organizations were once viewed as large machines where work arrived at one end, went through a process, and emerged as output from the other. Organizations are complex systems made of humans, informal networks, tacit norms, incentives, emotions, habits, fears and aspirations. I have learned this while designing systems for large operating environments. You can define the workflow perfectly and still discover that the real organization lives in exceptions, supervisor judgment, local practices, incentives, workarounds and human fear. Leadership became about influencing conditions and outcomes: establishing purpose, boundaries, values, accountability. As intelligence distributes across organizational platforms and agentic AI makes decisions at machine speed, leaders cannot personally inspect every decision, approve every output or supervise every action. Leadership becomes less about controlling and more about contextualising. About establishing an environment where humans and machine intelligence interact well. AI leadership asks questions such as: what is the purpose of this system? What problem am I trying to solve? Where must human authority always persist? What must it never sacrifice? AI will expose leaders who mistake visibility for control. You may be able to see everything on a dashboard and still have very little control over what an intelligent system does with that information. ## Shift #2: From execution management to intent governance Any AI system follows objectives. But poorly defined objectives can be dangerous. If an AI system is designed only to reduce cost, it may recommend cutting corners and eroding trust. If optimized to improve productivity, it may intensify pressure on employees. If asked to optimize operations, it may discard local nuances that human managers understand intuitively. Execution pursues the target. Intent defines why the target matters and what cannot be sacrificed while pursuing it. But without well-defined intent, extraordinary efficiency can become fatal. Speed cannot undermine care. Personalization cannot become manipulation. Autonomy cannot erode dignity. Leadership must become the force that defines the acceptable shape of outcomes. This is where AI will expose vague leadership rather brutally. A poorly framed intent does not remain vague when a machine begins pursuing it efficiently and at scale. ## Shift #3: From decision-making to judgment Humans will use AI because it works. It searches faster, compares more alternatives, responds without fatigue. A person who receives useful advice repeatedly will naturally begin to trust the system. AI will dish out recommendations that appear rational, data-backed and efficient. Most of the time they will be correct and useful. But once in a while they will be wrong. Some may be biased. Some may be technically perfect but organizationally foolish. Leaders must develop the knack of intelligent doubt. Leaders must know when to use machine intelligence, when to question it, when to override it and most importantly, when to use the ‘kill switch’. AI can approximate some forms of intuition. But approximation is not embodiment. Pattern recognition can approximate intuition without carrying the experience from which human intuition is formed. A leader who blindly accepts AI has abdicated judgment. A leader who ignores AI has rejected useful capability. The successful leader straddles both. AI will also expose the difference between confidence and judgment. An AI answer can appear extraordinarily convincing, but the leader still has to know when being convinced is not enough. Confidence hurries, wisdom hesitates. ## Shift #4: From authority to accountability In traditional structures, authority is visible. People know who approves what, to what extent, whom something will be escalated to and who owns a decision. AI blurs this. AI systems can diffuse accountability, and this becomes critical when something goes wrong. Leadership in the age of AI requires clear attribution. Every model must have an accountable owner. Every important AI-driven decision must be traceable. Every AI action must have defined boundaries and clear escalation, monitoring, appeal and override mechanisms. This is not bureaucracy. It is institutional seriousness. When harm occurs inside an unaccountable AI system, responsibility dissolves into architecture, vendor gaps and dataset problems. That is not failed leadership. That is effective evasion dressed as leadership. ## Shift #5: From transformation drama to adaptive learning Many organizations treat AI leadership as a branding exercise. Pilots are announced. Roadmaps created. Committees formed. AI adoption is not just catchy slogans. AI is remarkably good at exposing management theatre. Organizations that have institutional chaos will not become intelligent by slapping AI on top. They will make their ‘confusion’ faster. AI amplifies whatever already exists. If it is clarity, AI amplifies clarity. If it is bias, AI scales bias. If it is weak leadership, AI will expose it. I have watched these events happen inside large organizations, and sometimes it is not a pretty sight. Leaders must get comfortable with experimentation without going overboard. They must hold discipline while accepting uncertainty. The old command-and-control leader, the “my-company-is-a-well-oiled-machine” chief, will be deeply uncomfortable in the age of AI. The best leaders will be those who think in systems: patterns, feedback loops, resilience and emergence. ## Shift #6: From managing people to preserving humanity inside intelligent systems This shift is perhaps the most important one of all: As AI becomes more pervasive, leaders must decide what must always remain human. Not because humans are good. Far from it. Humans can be inefficient, biased, emotional. But organizations are human institutions, not just economic machines. They exist within society. They directly and indirectly affect dignity, trust, livelihood, aspiration and meaning. AI can uplift execution, but not in a way that becomes detached from humanity. That is the vital part that modern leadership must play: designing and governing the human-machine interface, protecting human agency and recognising that everything valuable cannot be captured in a KPI. Perhaps this is where AI will expose leadership most deeply. It will force leaders to reveal what they actually believe an organization is for. If everything is eventually reduced to productivity, efficiency and measurable output, then AI will simply make that belief visible. AI is almost a reagent in the chemical sense. It reveals what was already present. Leaders who define themselves by control will be exposed. Those who confuse automation with transformation will be exposed. Those who drive efficiency without accountability will be exposed. Those who lack ethical seriousness will be exposed. Those who do not understand technology will struggle. But the most dangerous leader of all may be the one who understands intelligent machines and does not understand human beings. If Jack were around, I wonder what his observation would have been. But in his book, he seems to have alluded to it. The rate of change inside an institution, he believed, must never fall behind the rate of change outside it. When it does, the end is near, he said. And he believed that there are no finite answers to the hardest questions. What really counts is your thought process. He was describing our moment, our predicament. He just did not know it yet.

Together with partner Nvidia, Salesforce today at Dreamforce Conference 2026 unveiled a new CRM domain-specific reasoning model for Agentforce dubbed Koa. “It’s built on Nvidia’s Nemotron and it brings together 27 years of product development in CRM,” said Rohan Kumar, president and chief platform and engineering officer at Salesforce. Kumar explained that Koa was built by post-training Nvidia Nemotron 3 Super with a synthetic data set modeled on the enterprise knowledge Salesforce gleaned from three decades of CRM deployments, not on customer data. Drawn from synthetic scenarios that simulate real-world enterprise workflows across more than 14 industries — including manufacturing, financial services, healthcare, and travel — the training corpus was designed to reflect the reasoning, tool use, and decision-making skills agents perform across CRM workflows. “The genesis of this was looking at all the things we’ve learned in building out our products, the strategy we’ve created, and asking how could we augment a model to make it very specific to this job,” Kumar said. ## Under the hood Salesforce post-trained the model by applying Supervised Fine-Tuning (SFT) and reinforcement learning to Group Relative Policy Optimization (GRPO) and Nvidia NeMo RL, NeMo Gym, and NeMo AutoModel. The idea is to leverage Koa agents for complex sales and service tasks. Salesforce said that in its CRM Benchmark, a model benchmark that includes a suite of real-world tasks like updating opportunities, routing cases, and scheduling follow-ups, Koa already matches or exceeds leading model performance with three times fewer errors. “We use Koa internally at Salesforce for a lot of our employee engagement and it’s actually turning out to be a game changer,” Kumar added. ## Additional applications Salesforce has also created an agent in Slack that helps its employees find information and complete everyday tasks. It also announced a number of customers are using Koa in pilots, including 1-800Accountant, Baxter Credit Union, Engine, Formula 1, UChicago Medicine, and Xero. Salesforce expects to make Koa generally available in Agentforce in winter 2026 in US regions.

Kicking off the Dreamforce Conference 2026 in San Francisco on Tuesday, Salesforce launched AIforce, a live interface layer for enterprise software it hopes will transform the way knowledge workers access enterprise data. By unlocking Salesforce data, workflows, business logic, semantics, permissions, security, and governance for any AI interface, the company also aims to broaden the scope of its business by reaching knowledge workers within the enterprise who’ve never used Salesforce before. The promise is the ability for users to create custom and composable applications that leverage Salesforce as the system of record. “For the last 50 years or so, we’ve been using software the same way,” said Patrick Stokes, president of applications and marketing at Salesforce. “As a human, I ask software for what I want, either at the command line or by clicking through these UIs.” User interfaces can create tremendous friction, however, so users need to know the functions they need from an application and where to click to find them — a task that can grow truly byzantine in more complex applications. So AI agents have the potential to cut through much of that complexity. “They’re able to navigate these applications via the APIs, CLIs, and all sorts of different ways to help us get work done,” Stokes said. ## Laying the groundwork At its TDX 2026 developer conference earlier this year, Salesforce announced Headless 360, which made Salesforce’s AI and developer tools available as a headless, API-driven layer intended to help enterprise teams build agent-first workflows. At the time, Salesforce Cofounder Parker Harris, who designed Salesforce’s Lightning user interface, questioned whether there would be a need to even log into Salesforce going forward. Stokes said Harris sensed something: The UI is not Salesforce’s product. “The Salesforce product is the platform where our customers store their data, metadata, workflows, and all their permissions and security,” he said. “It’s basically where they encode the way their business runs.” Headless 360 was a first step to help customers break free of the shared user interface to a world in which every individual in an organization can have their own dynamic, intelligent interface. While an important step, and one that generated a lot of interest, it was extremely hard to use and scale. But determined users could leverage Headless 360 for interesting results, yet there wasn’t enough infrastructure there to make it viable for businesses to use it to create tools and deploy them across the enterprise. Enter AIforce to address that need. The first implementation of AIforce was Claudeforce, announced by Salesforce and Anthropic in August. Claudeforce allows joint Salesforce and Anthropic customers to leverage Salesforce data, workflows, business logic, actions, and governance within Claude. As part of the AIforce announcement, Stokes said the Claudeforce open beta is now available on the AppExchange. “You can go to our AppExchange, sign up, and grab the plugin in open beta, install it into your Claude enterprise account, and all the hard work is done for you,” Stokes said. “All of the Salesforce MCP servers, the skills that you need, the security, the zero data retention, it’s all wired up and just working almost instantaneously.” Analysts felt the venture could signal a new agentic era for enterprise software. “Core ERP, core CRM, core HR, most of these tools are going to see a similar sort of realignment where the models will provide probabilistic capability that uses the best of breed from your intelligence coupled with the rich, proprietary data that businesses depend on to operate,” said Daniel Newman, CEO and principal analyst of research firm The Futurum Group. But Claudeforce is just the beginning. AIforce is launching with Claudeforce, Slackforce, and Agentforce Coworker (an AI teammate within the Lightning interface), but Stokes made it clear that more AI platforms would be announced soon. Stokes said AIforce makes AI interfaces: - Intelligent and dynamic. Agents are able to reason across all the data, logic, and conversations in Salesforce. - Secure and governed. AI agents still run every request on existing permissions and business rules. - Composable. Anyone can build an interface, agent, or view built on trusted data and business logic by describing it. Zero data retention is also built into AIforce, meaning the model provider doesn’t retain any data used, and the Headless Toolkit powers AIforce, which provides an open architecture that exposes every element of the Salesforce platform. Builders and developers have access to the MCPs, APIs, plug-ins, skills, and developer tools they need to create customized AI experiences on Salesforce architecture.

The first hit is access. I have talked with technology leaders whose teams had a working model but could not secure the capacity to operate it at production scale on the economics they had forecast. The available capacity sat outside the assumptions behind the existing agreement, and market pricing had moved well beyond the budget. As CIO.com has reported, AI is exposing the limits of enterprise cloud strategies created before these workloads became material. Data movement creates another problem. AI workloads may cross regions or providers in search of an available GPU or a better price on a particular chip. I have seen finance teams confront cloud bills that ran well beyond forecast because data had to leave one cloud to reach compute available in another. The increase had nothing to do with headcount or a wave of new applications. It came from an architecture assembled around capacity rather than cost. Egress pricing also changes the economics of portability. Consolidating with one hyperscaler may simplify operations, but it can become expensive to change course when the provider cannot supply the right capacity in the right place. By the time the CIO needs alternatives, the cost of moving data may have weakened the negotiating position. Then the question reaches the board: What will AI cost next year? Some CIOs cannot answer with confidence because the contract and cost model were built around a different workload. That is more than a forecasting problem. It tells the board that the company has committed to an AI roadmap without understanding the infrastructure economics beneath it. ## What prepared CIOs are doing differently The CIOs in the best position separated AI economics from the rest of the cloud estate before returning to a provider. They stopped defending cloud spend as one number and accounted for training and inference by workload, region and chip. That work gave them something far more useful than another high-level forecast: evidence they could negotiate from. Some have resisted the usual pressure to consolidate everything with one hyperscaler. They have kept selected AI workloads portable across providers or moved GPU-heavy training to specialized infrastructure companies. Portability carries its own engineering and governance costs, so it is not automatically the right answer. But a credible ability to move a workload creates leverage that a cloud strategy built around dependence cannot. The contract requests have changed as well. CIOs are asking for guarantees tied to named chip types, shorter terms for volatile AI capacity and the ability to rebalance spend categories as the workload mix changes. One structure is a reserved allocation for a specific GPU generation rather than a general compute credit. Another is a shorter AI-specific commitment layered over a longer agreement for the general-purpose estate. The two workloads do not have to be forced into the same planning horizon. The work should start before the provider puts a proposal on the table. Once the negotiation has been reduced to a renewal number and a discount percentage, the most important assumptions have already escaped scrutiny. Start with the workload rather than the existing agreement. Which AI use cases are expected to reach production during the next term? Which require training, which rely mostly on inference and which can use a managed model without dedicated GPU infrastructure? Those distinctions determine whether the company needs reserved capacity, flexible consumption or no direct GPU commitment at all. Then test the location assumptions. Where does the underlying data reside? What residency or sovereignty rules limit where it can move? If the preferred capacity is available only in another region or from another provider, calculate the transfer, egress and operational costs before calling that option cheaper. A lower compute rate can disappear quickly when the data has to travel to reach it. Capacity and discounts also need to be separated. A favorable price does not guarantee that the required chip will be available when a production workload needs it. Conversely, a capacity reservation can protect access while creating a cost for infrastructure the company does not fully use. The CIO needs both numbers: the economics of consuming the capacity and the economics of holding it. Finally, decide what must remain portable. Full multi-cloud portability is expensive and often unnecessary. But there may be a small number of high-cost AI workloads where dependence on one provider creates more risk than portability costs. That is where an alternative architecture can become negotiating leverage rather than an abstract cloud principle. None of this requires treating the original agreement as a mistake. It was often a reasonable decision based on the company’s workload at the time. What has changed is the cost of leaving it unexamined. A three-year cloud agreement cannot be treated as a three-year suspension of judgment. Before the next renewal, test the commitment against the workload the company is actually running, not the company it was when the agreement was signed.