Last week, while finalizing a proposal to modernize a large core banking system using our iBeam engineering agents, two people close to me asked me the same question, independently, within days of each other.

My COO asked it first: once we modernize this CBS, what intelligence layer will the new application actually need? His reasoning was straightforward. Software has traditionally been built by humans, for humans. We are now bringing agents in as the analysts, developers, and QA engineers who build the application. Should we also be building agents to help the humans who will use it? A core banking system is full of workflow-heavy processes, customer onboarding, KYC, loan origination, insurance servicing, that real people navigate every day inside the application we are about to modernize. What intelligent agents belong inside those workflows, not just around the engineering that produces them?

A colleague, in a routine monthly one-on-one, asked essentially the same thing from a different angle: why aren’t we focused on embedding intelligence into the modernized application itself?

Both questions stopped me. Not because I didn’t have an answer, I did, immediately. It just was not a good one.

The honest answer is that the client we are modernizing this system for has not explicitly asked for an intelligence layer yet. And my team and I have had our hands completely full doing something else: building and integrating engineering agents into the SDLC itself, the BA, Dev, and QA agents that convert legacy code, generate requirements, and validate output, which I have written about at length in this series.

We have been so consumed with rewiring how the software gets built that we have not yet had the conversation about what the software, once built, should actually do differently for the people who use it.

That is a real gap. And it took two people, asking the same question independently in the same week, for me to notice it clearly enough to write this.

It is worth being precise about the distinction here, because I think it explains exactly how this blind spot formed.

The agents I have spent most of this year building, the BA, Dev, QA, and soon DevOps agents in our iBeam trio, are build-time agents. Their job is to produce modernized applications. Once the system ships, their work is largely done. They do not live inside the banking application a customer or a bank employee interacts with.

What Jai and my colleague were both asking about is something structurally different: run-time agents. Agents that live inside the modernized application itself, assisting the humans who use it to actually get their work done, a KYC analyst working through document verification, a loan officer navigating origination, a customer trying to complete onboarding without waiting on a queue.

We solved, quite deliberately, for the first category. We have not yet started deliberately thinking about the second. And until last week, I had not clearly named that as two separate problems requiring two separate answers.

I have written in this series about a lesson that keeps repeating in every AI adoption effort I have been close to: dropping agents into an existing process without reengineering that process around them yields a fraction of the value that is actually available. This was true of our own SDLC. It was true of the healthcare and procurement examples I have used to illustrate the same pattern in other domains.

There is no reason this lesson should stop applying at the SDLC boundary. A core banking system’s KYC, onboarding, loan, and insurance workflows are themselves complex business processes, executed today largely by humans, inside software that was designed for exclusively human use. If we modernize the technology stack underneath those workflows without asking what an intelligence layer inside them could do, and, more importantly, without reengineering the workflow itself to accommodate that intelligence, we will very likely get the same disappointing result we have already seen elsewhere: a modest efficiency bump that leadership reads as evidence AI isn’t delivering, when the real issue is that nobody redesigned the process around it.

Here is where this gets genuinely difficult, and where I do not have a clean answer yet.

Reengineering our own SDLC was, relatively speaking, within our control. We are the subject matter experts on software delivery. We could whiteboard the process, separate execution from judgment, and redesign the pipeline ourselves.

Reengineering for a bank’s KYC or loan origination process is not something we can do unilaterally. It requires deep buy-in from banking domain SMEs, people who understand regulatory constraints, risk tolerances, and operational realities we do not have full visibility into. And right now, those SMEs are focused on a different question entirely: whether the underlying modernization, on its own, delivers enough return to justify the investment. Asking them to simultaneously commit to a second, harder conversation, redesigning their business processes around an intelligence layer that does not exist yet, while they are still validating the first investment, is a genuinely difficult ask.

I do not think the answer is to wait until the modernization ships and then start this conversation from scratch. That guarantees the intelligence layer, if it ever gets built, gets bolted onto an unchanged process, the same mistake, one layer up.

Assuming this conversation is worth having, there are really only two ways to get it started, and I think it is worth being honest about the limitations of both.

The first is client-led: raise the possibility of a run-time intelligence layer during the modernization engagement itself, even without a committed scope or budget for it. If the timing is right, or if it genuinely captures the client’s interest, that conversation can create space to plan for it during the current engagement, or at minimum leave architectural hooks that make it easier to add later. The risk is obvious, without sustained attention, this kind of conversation quietly becomes “let’s revisit it next year,” and next year rarely arrives with more urgency than this year did.

The second is proactive: OptiSol brings in a domain SME – banking, healthcare, procurement, whichever vertical applies, and embeds them directly with the engineering team, ahead of any client ask. That SME partners with the team to identify concrete, low-effort opportunities for a run-time intelligence layer within the application being modernized, and builds out a real scope: solution architecture, integration patterns, timeline, cost, and ROI justification. The pitch to the client then arrives with the groundwork already done, which meaningfully raises the odds that a first version actually gets built, because the client is reacting to a concrete proposal rather than an abstract idea.

The second path is the stronger one. It is also the harder one for us, internally, because we do not currently have ready domain SMEs sitting across banking, healthcare, procurement, and whichever vertical comes next. Building that bench requires proactive recruitment, and that requires buy-in and investment from my own management, which makes this less an engineering decision than an organizational one.

I’ll close with something that reframes the urgency of this for me.

N Chandrasekaran, Tata Sons’ chairman, told shareholders at TCS’s Annual General Meeting this year that the company could have roughly as many AI agents as human employees within the next three years. TCS employs more than 600,000 people. If that prediction holds even directionally, we are talking about several hundred thousand agents working alongside, not instead of, TCS’s human workforce, in a similar timeframe.

That is one company, in one industry. The same shift is underway across BFSI, healthcare, and manufacturing, wherever large enterprises are rethinking how work gets done. For technology providers like OptiSol, and for CTOs inside these industries themselves, the moment to start solving for both halves of this problem, the build-time agents that build the software, and the run-time agents that will live inside it, is now, not after the first modernization ships.

We solved the first half before we had even clearly named the second. I don’t think we’re unusual in that. I do think it’s worth fixing before the gap gets wider.