Modernizing Intranet UI Apps in the Agentic Era: Wrap, Extract, Rebuild, or Retire
PowerBuilder or Swing to React is a framework decision. How many screens survive is an architecture decision.
This isn’t about customer-facing software. Set the internet-facing estate aside — nobody is arguing about whether the mobile app needs a UI.
The estate in question sits behind the firewall: the internal applications that exist purely so operations staff can do their jobs. A few hundred of them in a typical institution, invisible to every client. PowerBuilder for securities processing. A Swing desktop pinned to Java 8. Two hundred JSF pages for payments investigation. Reconciliation logic living in button-click handlers.
Each one works. That’s the problem. They work well enough that replacing them was never urgent, and badly enough that someone proposes it every planning cycle.
This year the forcing functions arrive together: a runtime goes end-of-support, a vendor contract lapses, the last engineer who understood the batch layer retires, audit raises a finding. So a modernization program gets funded, and the plan is written the way these plans always are — an inventory of screens on the left, a target framework on the right, three years in between.
In a different portfolio, with a different sponsor, an agentic AI program is standing up its first use cases. Reconciliation triage. Payment failure investigation. Corporate action interpretation. The work those agents are learning to do is, line for line, the work those screens were built to support. The two programs rarely appear in the same steering pack, and neither is asked how the other changes its scope.
This piece isn’t a prediction that agents will replace operations software. It’s an attempt to give architects a way to decide, application by application, what the right disposition is — wrap it, extract from it, rebuild a smaller part of it, or retire it — using properties you can measure in a codebase this quarter.
Modernization isn’t wasted. APIs, clean data access and supportable runtimes are exactly what an agent needs. But the sequencing and the scope are usually wrong, and getting them wrong buys a three-year program that ships on time and delivers three hundred screens nobody has a reason to open.
Which is why the uncomfortable question for anyone holding a modernization budget right now is not which framework to migrate to. It is which of the screens on that migration list will still have a reason to exist when it ships.
Ask an operations analyst to move money between two accounts and watch what actually happens. A dashboard. A search form. Page one of forty-three results. A position detail screen. A forecast screen. A transfer entry screen. A verification screen. An approval screen. Somewhere between twenty and fifty screens for one decision that, stated in plain language, takes six seconds: this account is going to run short, fund it from the concentration account.
The screens are not the work. The screens are the scaffolding we built because a human had to do the work by hand.
Our industry has migrated its user interfaces roughly every fifteen years: mainframe green screens, then client/server, then web, then mobile. Each time, the assumption held steady — a human executes the workflow, and the software’s job is to present that workflow well. The next shift breaks the assumption instead of the technology stack:
From: a human executes the workflow
To: an agent executes the workflow, and a human supervises itThat is not a front-end migration. It changes what an application is for.
Why financial operations are first in line
Strip an operations function down to its verbs and you get a short list: gather data, validate it, reconcile it, investigate what does not match, handle the exceptions, execute the decision, route the work onward.
Every one of those is structured, rule-driven, and heavily documented — the conditions under which agents work best. Cash management, payments operations, asset servicing, securities processing, fund accounting, reconciliation, treasury, middle office, corporate actions, client onboarding. These are not functions that happen to involve some repetitive work. Repetitive work at scale is what they are.
Two things make them unusually exposed. The rules are already written down, because regulators required it. And the work is already measured in volumes — 847 failures, 10,842 items, 214 accounts — which means the cost of doing it a screen at a time is already on someone’s budget line.
What today’s applications actually do
Look honestly at a typical operations screen and its primary function is navigation: helping a person get to the right record, one record at a time.
Twelve filter fields exist because the analyst has to narrow 847 rows themselves. The export-to-Excel button exists because the analysis the job actually needs cannot be done in the application. The status bar admits the real cost: screen 12 of 41.
An agent does not need any of it. It does not need to be told which filters matter, and it does not need to page through results. So the screens that exist to support human navigation are the ones with the least reason to survive.
The five screens that replace the forty
Across the operations estate, applications look likely to converge on a small set of experiences. Not one per workflow — five, reused everywhere.
1. Intent
The entry point stops being a menu and becomes a statement of the outcome the user wants.
The design work here is quieter than it looks. Before anyone types a goal they need to know what the agent can reach, what it is allowed to do on its own, and what it will never do without asking. That is why the two small labels under the field — six systems read, nothing moves without approval — matter more than the input box.
2. The agent workspace
Then the user watches, rather than clicks.
A progress bar is not enough for regulated work. Each step names the system it touched and how long it took, because those are the questions an operations lead will be asked afterward. The running count at the bottom — six systems read, zero writes — is the difference between an agent someone will authorise and one they will quietly stop using.
3. The recommendation
This is where the work lands for the human.
Two details do the heavy lifting. The rejected alternatives, because a reviewer cannot judge a recommendation without knowing what it was chosen over. And the latest safe release time, because in operations a correct answer delivered after the cut-off is a wrong answer.
Get Krishnaraj_Rajan’s stories in your inbox
Join Medium for free to get updates from this writer.
Approve, modify, reject. If a reviewer approves everything, the screen has failed — it has built consent rather than judgment.
4. The exception workspace
For most operations staff, this becomes the daily home screen.
The instruction “show me the items requiring judgment” reorganises the entire working day. The hard part is the third column. Each row has to say why a human is needed — two matches score equally, the evidence is a phone call that never made it into a system, the fix moves NAV beyond the agent’s tolerance — because that is what tells the reviewer where to start and what good looks like.
5. Audit and explainability
In a regulated business this screen ends up more important than any transaction screen.
Three questions arrive whenever something goes wrong, and none of them should require a developer to answer: which data was used, which policy was applied, and would the same decision be produced again. Note the stale collateral feed, surfaced rather than buried. An agent that shows its weak inputs earns more trust than one that presents every recommendation with the same confident tone.
Three operations, rewritten
Cash management. Today: review balances, examine liquidity positions, download reports, chase breaks, initiate transfers, verify forecasts — across a handful of dashboards. Tomorrow the analyst states the goal once and reviews six recommendations, of which one is urgent. The interface moves from operational execution to operational supervision.
Payment operations. The 847 failures from Figure 2, grouped by cause:
The reframing is the whole point. Six hundred and twelve failures were one broken directory refresh job. Sixty-two were a file uploaded twice. An operator working record by record could spend a full day and never see the pattern, because the pattern only exists at the level of all 847.
Asset servicing. The agent consumes the announcement, matches it to holdings, calculates entitlements and withholding, and reconciles the notice against market feeds.
Three accounts are arithmetic. One is a judgment call about an unsettled trade near a record date, worth €5,040 and a footnote in an audit file. That is the item a person should spend their morning on.
What happens to the estate you already own
React survives, but its job changes. Instead of hundreds of workflow screens, it becomes the cockpit: copilot workspace, agent monitor, approval console, exception dashboard. Fewer screens, built to a much higher standard, because every one of them is now load-bearing for a decision.
.NET applications lose their transactional screens first. What remains clusters around risk, audit, governance and compliance review.
JSF applications are mostly searches, forms and workflow navigation — precisely the patterns agents absorb. Approval and exception handling stay. The navigation layer shrinks hard.
Swing and desktop operational systems are the most exposed, because they exist specifically to give power users rich manual workflows. Many become monitoring consoles rather than processing systems.
PowerBuilder applications carry decades of embedded operational logic, which is an asset before it is a liability. The realistic sequence is agent plus existing application, then agent plus extracted APIs, and only then the retirement of screens. The logic is worth keeping; the forms usually are not.
The trap
The tempting roadmap is a straight line:
PowerBuilder → React. JSF → Angular. Swing → web.That modernisation is still worth doing. API surfaces, clean data access and supportable stacks are exactly what agents need, so the work compounds. But it is not sufficient, and if it is the whole plan there is a specific failure mode: spending three years and a large budget rebuilding four hundred screens in a modern framework, and discovering that three hundred of them were scaffolding for work nobody performs by hand anymore.
The real transformation is not workflow-centric to modern-workflow-centric. It is workflow-centric to agent-centric.
What that means for the next planning cycle
A few things travel well regardless of how quickly agents actually arrive:
- Count the screens in your top three processes. If a process takes more than fifteen screens, most of them are navigation, and navigation is the part that disappears.
- Treat every manual workflow step as an unwritten API. The step exists because a human had to bridge two systems. That bridge is the integration you will need.
- Ask which decisions in the process actually require judgment. Those are your remaining screens. Design them properly.
- Build the audit trail before the autonomy. In regulated operations, explainability is what determines how much autonomy you are permitted, so it is the first thing to build rather than the last.
- Modernise in the direction of agents. Same project, different sequencing: APIs and data access first, screens last, and fewer of them than the old system had.
The shift under the shift
Green screen to client/server was a change of platform. Client/server to web was a change of reach. This one is a change in who does the work.
Applications will end up with fewer screens, fewer forms and fewer searches, and the ones that remain will carry far more weight: guidance, monitoring, approval, exception handling, auditability. The people using them will spend less time operating software and more time supervising, approving and governing work that software performed.
The uncomfortable question for anyone holding a modernisation budget right now is not which framework to migrate to. It is which of the screens on that migration list will still have a reason to exist when it ships.
When i analyze using this approach against estates where three-quarters of the screens turned out to be navigation, and one where almost nothing was — a genuinely judgment-heavy risk platform that deserved every dollar of its rewrite.
If you’re holding a modernization plan right now, do this exercise before you start: do an inventory of the screens into navigation, data entry, judgment, and audit, then look at the split. I’d be curious what other people find, because I suspect the answer varies far more by institution than the vendor decks suggest.
