On February 23, 2026, Anthropic demonstrated a COBOL Modernization Playbook built into Claude Code — an agentic tool designed to automate dependency mapping, risk identification, and incremental refactoring of legacy COBOL systems. The next trading day, IBM's stock fell 13.2%. Its worst single-day decline since October 2000.
The market reacted as if AI had solved the legacy code problem entirely — that modernization was now cheap and the mainframe era was drawing to a close. The conversation that followed was loud, fast, and largely untranslated for the IBM i audience.
That conversation is worth understanding. Because buried inside it is a signal that matters directly to anyone running IBM i infrastructure — or any enterprise codebase with decades of encoded business logic.
"COBOL is the asbestos of programming languages — almost ubiquitous once upon a time, and now incredibly, dangerously difficult to remove."
— Wired, March 16, 2026
The Wired characterization landed in the mainstream press. The banking industry articles that preceded it were sharper: approximately 95% of ATM transactions in the United States still run on COBOL. Hundreds of billions of lines remain in active production. The developers who built those systems have largely retired, taking undocumented institutional knowledge with them.
None of those articles were about IBM i. None of them mentioned RPG. But the dynamics they described — encoded intelligence, aging talent, organizational inertia, and the arrival of AI tooling that can finally reach the logic layer — are not unique to COBOL or to Z mainframes. They describe a category of enterprise environment. IBM i is a member of that category.
I have spent more than thirty years in that category. Working across RPG, DB2, DevOps, open source, front-end, and now agentic architectures, I can say this directly: we are not looking at a future capability. The ability to connect IBM i business logic to an agentic intelligence layer exists today. The tools are here. The architecture is proven. What remains is organizational will and strategic clarity.
This paper provides the clarity. The will is yours.
This Is Not Just an IBM i Story
The IBM i platform is the lens for this paper. But the underlying challenge is not unique to this platform, and leaders who recognize that will take the most value from what follows.
A Java shop sitting on fifteen years of custom business logic has the same problem. A .NET shop with a proprietary ERP core has the same problem. A COBOL mainframe environment has the same problem — and now has the most press coverage about it. The encoded intelligence in all of these environments is real, valuable, and largely disconnected from the agentic layer that is rapidly becoming the primary interface for building and operating software.
The IBM i case is particularly instructive because the platform has exceptional compute reliability, a purpose-built database in DB2 for i, and decades of mission-critical logic running without incident. It is a clear example of the broader pattern: the intelligence is there. The connection is not.
Any technology leader — regardless of platform — should read the IBM i story as a mirror.
Central Thesis
The competition is no longer primarily about which language you write in or which platform you run on. It is about how fast you can direct intelligence to solve business problems. The organization that connects its encoded business logic to the agentic layer — and governs that connection thoughtfully — is positioned to compete at the speed the market now demands.
The most useful strategic posture is to look at the destination first, then work backward to the path. What does a competitive operation look like at each horizon — regardless of platform? What capabilities will be table stakes at 12, 18, 24, and 36 months from today?
These projections are not vendor roadmaps. They reflect the current trajectory of agentic AI adoption across enterprise environments. The IBM i column translates each horizon into platform-specific terms — but the capability curve applies broadly.
| Horizon |
Agentic Capability |
What Competitive Looks Like |
IBM i Implication |
| 12 Months
Q2 2027 |
Agentic coding assistants generate production-ready code in multiple languages from natural language prompts. |
Developers direct agents; they do not write every line. Speed to solution becomes the primary competitive metric. |
IBM i shops integrating AI coding assistance are building a velocity advantage. The developer directing an agent is operating at a different pace than one writing every line manually. |
| 18 Months
Q4 2027 |
Agent-to-system integration becomes standard. APIs and MCP servers connect business logic to AI reasoning layers. |
Competitive shops have mapped their core business logic and exposed it to agents. Systems with an API surface become accessible to the intelligence layer. |
RPG and DB2 logic that can be reached from outside the platform becomes a connectable asset. Building the bridge is what makes the intelligence available to agents. |
| 24 Months
Q2 2028 |
Multi-agent workflows handle end-to-end business processes with human oversight at governance checkpoints. |
Competitive shops have defined agent authority structures. Agents handle routine decisions autonomously. Humans govern exceptions and policy boundaries. |
IBM i operations with a clear agent authority framework are positioned to scale confidently. Governance is what earns organizational trust in the agentic layer. |
| 36 Months
Q2 2029 |
Organizations operating at the Organizational Singularity threshold — doing significantly more with smaller, more capable teams supported by agent infrastructure. |
Shops that built the bridge, governed the agents, and mapped their business logic are competing at a pace that compounds over time. |
The IBM i platform is architecturally suited to this future — always designed to do more with less. The integration layer is what activates that advantage. |
The IBM i implication at each horizon is a function of decisions made in the prior period. But so is the implication for every other enterprise environment. The 36-month outcome is being determined by what organizations choose to do — or not do — right now.
The velocity gap is the real risk.
Not platform obsolescence. Not language irrelevance. The compounding speed advantage that accrues to organizations on the agentic stack — versus those still operating in fully manual development cycles — is what makes this a strategic urgency, not a future consideration.
Having worked across the IBM i stack — RPG, DB2, DevOps, open source, and front-end — and now in agentic architecture, I can describe the current state of most IBM i environments with some confidence. The same patterns appear across Java shops, .NET environments, and COBOL mainframes as well. The specifics vary. The shape of the problem does not.
The important thing to understand is this: the capability to connect IBM i business logic to an agentic layer exists today. This is not a future-state discussion. An RPG and DB2 codebase is, right now, a source of intelligence that agents can consume, reason about, and extend. The technology has arrived. The question is whether the organization is ready to use it.
What Is Working
The platform runs. Reliably, efficiently, correctly. Payroll processes. Orders fulfill. Transactions post. In many shops, IBM i infrastructure has a better uptime record than the modern systems built around it.
The business logic is real. Decades of rules, edge cases, and transaction patterns are encoded in RPG programs and DB2 schemas. That intelligence is among the most valuable things in the building — and it often goes underrecognized.
The practitioners know the platform. The IBM i community has deep expertise, genuine craftsmanship, and institutional knowledge that no AI tool replicates from a standing start.
Where the Opportunity Is
The business logic is often invisible to modern systems. In many IBM i environments, RPG programs operate as closed systems — present, working, and valuable, but not yet speaking to the agentic layer being built around them.
The talent transition is real. The IBM i developer community is experienced and deep — and also aging. Institutional knowledge that lives in people's heads rather than documentation is worth capturing before it becomes harder to access.
AI adoption has largely occurred in adjacent systems. The IBM i core environment has significant runway to close that gap — and the intelligence it already encodes gives it a meaningful head start.
The opportunity is not a platform replacement. The constraint is not the language or the database. The constraint is the connection — and that constraint is solvable with tools and approaches that exist right now. The shops that recognize this are the ones that move first.
The COBOL conversation generated significant market reaction in early 2026. For the IBM i leader, the more useful exercise is to look at what the conversation revealed — about where value lives in enterprise codebases, what AI can and cannot do with it, and what the business implication actually is.
What the Conversation Missed
The Claude Code COBOL announcement prompted a market reaction rooted in a specific assumption: if AI can translate COBOL into modern code, the underlying problem is solved. Migration becomes affordable. Institutional lock-in dissolves.
The more nuanced view — and the one that practitioners with real platform experience understand immediately — is that translating code syntax is a different challenge from transferring the institutional knowledge embedded in that code. Business rules written by developers who retired a decade ago and never documented their logic do not automatically surface through code translation. The code moves. The understanding of why it was written the way it was does not always travel with it.
This applies equally to RPG, to Java, to any environment where the logic has accumulated over decades and the people who built it are no longer in the room. The asbestos metaphor is precise: the surface is visible and addressable. What is inside the walls requires a different kind of work — and a different kind of thinking.
The business problem is not the language. It is never the language.
The business problem is the ability to solve problems at the speed the market requires. An RPG program that encodes thirty years of business logic is a competitive asset — provided it can communicate with the systems solving the next generation of problems. The organizations that understand this are the ones connecting their intelligence floors to the agentic layer. The language they do it in is secondary.
Where IBM Will Go — And What That Means
IBM's response to the Claude Code announcement followed a familiar pattern: watsonx Code Assistant for Z. The positioning is that IBM's AI is better suited to regulated environments because it is trained on proprietary mainframe data and designed for the specific risk profile of financial and government systems.
IBM will make a version of that argument for IBM i. They will invest in modernization tooling. They will extend watsonx capabilities toward the Power platform. They will provide a credible on-ramp. IBM will do what is necessary to protect the platform's installed base.
The question for the IBM i leader is not whether IBM will provide tools. They will. The question is whether the shops that move now — with available tools — will have established an advantage that later arrivals cannot easily close. IBM's tools will be part of the stack. But platform-native tooling does not replace strategic architecture.
The Four-Layer Architecture
The competitive IBM i operation of 2027–2028 is not built by replacing what works. It is built by adding layers that let what works communicate with the world it now operates in.
| Layer |
What It Is |
IBM i Role |
Status Today |
| Layer 4 — Governance |
Authority structure for agents |
Defines what agents can and cannot do inside IBM i workflows |
Largely absent. Critical gap. |
| Layer 3 — Agentic Layer |
AI agents that consume and extend business logic |
Agents that query, reason, and act on IBM i data and processes |
Emerging. Limited IBM i-native examples. |
| Layer 2 — The Bridge |
APIs, MCP, and integration fabric |
Connecting RPG/DB2 to the modern agentic stack |
Achievable now. Underutilized. |
| Layer 1 — Intelligence Floor |
RPG/DB2 encoded business logic |
Decades of rules, transactions, and edge cases — the real asset |
Active and battle-tested. |
Layer 1 is not going anywhere. The goal is not replacement. The goal is connection. Layer 2 is the immediate gate — until the intelligence has an outbound API surface, it is invisible to agents. Layer 3 is where velocity is won or lost. Layer 4 is what makes everything sustainable: the authority structure that earns organizational trust in the agentic layer.
Every IBM i environment is different. The codebase is different. The business logic is different. The team is different. The organizational readiness is different. There is no single implementation sequence that applies universally.
What follows is an architectural orientation — the general direction of travel for the organization that wants to compete in the agentic era. The specific path will be shaped by each environment's priorities and capacity for change.
The destination, however, is the same for everyone: a state in which agents are doing the coding and the engineer is directing the intelligence.
The first question is not which agents to build. It is whether the underlying codebase is in a condition that agents can work with effectively. RPG programs written in fixed-format RPG II or RPG III carry significant value — and also carry structural characteristics that make them harder to connect to modern tooling. Free-format RPG, modular program design, and clean separation of business logic from I/O operations are the conditions that make the subsequent steps possible.
This step looks different in every shop. The point is not to rewrite for its own sake. The point is to create a foundation that can be connected — and that agents can understand, extend, and generate code for without ambiguity.
Once the foundation is ready to be connected, the integration layer is what makes that connection real. This is the MCP server, the REST API surface, the service layer that exposes IBM i business logic to the world outside the platform.
What the integration layer looks like will vary. Some shops will build REST APIs directly on top of existing RPG service programs. Others will use MCP-compatible interfaces to expose IBM i capabilities to AI agents natively. The architecture is less important than the outcome: the intelligence must be reachable.
With a modernized foundation and an integration layer in place, the agent layer is where competitive velocity is generated. Python-based agents — or agents built in whatever framework fits the environment — can now reach the IBM i intelligence layer, call its logic, consume its data, and act on its outputs.
The agent layer is where the developer's role begins to shift. The engineer who once wrote RPG programs line by line is now directing agents that generate, test, and deploy code. The institutional understanding of edge cases, transaction rules, and regulatory constraints does not go away — it becomes the input to the agent. The engineer's value is in knowing what to ask for and how to evaluate what comes back.
The final step is the integration of all three prior layers into a coherent operational system. The modernized IBM i foundation feeds the integration layer. The integration layer feeds the agents. The agents generate code, automate workflows, and extend capabilities at a pace no fully manual development process can match.
At this stage, the IBM i practitioner's deep knowledge of the platform becomes a compounding advantage. Every interaction between an agent and the IBM i layer surfaces institutional knowledge that can be documented, extended, and used to govern what the agent does next. The intelligence floor gets better as the agents use it.
The measure of success is not how much RPG has been replaced.
It is whether the engineer is spending the majority of time directing agents toward business problems — and whether those agents are generating results faster than any alternative approach. Language is incidental to that outcome. Architecture is not.
Signal4i Vol. 7 established the macro frame: the comet has struck, the Cambrian explosion is underway, and the IBM i platform is not the dinosaur.
This white paper establishes what to do about it — and extends the argument to every enterprise environment sitting on decades of encoded business logic, regardless of platform.
Having spent thirty years inside IBM i environments and now building agentic systems from the ground up, I can say with confidence: the capability exists today. The RPG and DB2 codebase is a source of intelligence that agents can consume right now. The integration layer can be built with available tools. The agent framework is proven. What has changed is not the technology — it is the speed at which organizations on the agentic stack are pulling away from those that are not.
That speed is the real urgency. Not platform replacement. Not language migration. The compounding velocity advantage that accrues to organizations directing agents toward business problems — while others are still writing every line manually — is what closes the window. The window is open. It will not remain so indefinitely.
The platform survived because the work was real.
The agents you govern next will survive or fail for exactly the same reason.
Do the work. Make it real.