From Agents That Build Software to Agents That Live Inside It
Two agent problems, not one
There are two structurally different categories of agentic transformation happening in any modernisation initiative, and it is worth being precise about the difference.
Build-time agents produce the software. In our case, that is the iBeam trio — BA, Dev, QA, soon DevOps — parsing legacy systems, generating requirements, writing code, validating quality. Their job is largely done once the system ships.
Run-time agents live inside the software once it exists, assisting the humans who use it. A KYC analyst working through document verification. A loan officer navigating origination. A claims processor resolving a denial. A procurement analyst validating a vendor recommendation against policy.
Most organisations we talk to including, until recently, our own delivery teams have started seriously investing in the first category and have not yet turned deliberate attention to the second. That is not a criticism. Build-time agent adoption is itself hard, urgent, and immediately fundable, because the ROI case is direct: faster delivery, lower engineering cost. The run-time case is less obvious upfront, harder to scope, and easy to defer indefinitely as we ourselves just discovered we were doing.
The same pattern, in every vertical we serve
This is not a banking-specific observation. It is the same two-wave shape in every domain elsai Platform is built for.
In Healthcare Revenue Cycle Management, the build-time problem is standing up the systems and integrations that generate and process claims. The run-time problem is an agent that assists a biller or coder in real time flagging a likely denial before submission, suggesting the correct code against payer-specific rules, surfacing the two or three cases in a queue that actually need judgment instead of forcing a flat, undifferentiated review of everything.
In Procurement, the build-time problem is integrating sourcing and contract systems. The run-time problem is an agent embedded in the procurement workflow itself helping a buyer evaluate a vendor recommendation against policy in the moment, rather than after the purchase order has already been raised.
In core banking, as Jai’s question crystallised for me, the build-time problem is the platform modernisation. The run-time problem is agents assisting KYC analysts, loan officers, and onboarding teams inside the workflows the modernised platform now runs.
Every vertical has this shape. Almost every organisation we have spoken with has invested seriously in only one half of it.
Why bolting intelligence on afterward doesn't work
I have written before in this series about a pattern that shows up whenever agents are introduced into an existing process without redesigning that process around them: the efficiency gain is a fraction of what is actually available. This was true of our own SDLC before we reengineered it. It is equally true of a business workflow.
A KYC or loan origination process, executed today largely by humans inside software built for exclusively human use, will not meaningfully benefit from an intelligence layer added on top without also rethinking the workflow itself what a human still needs to judge, what an agent can execute, where the handoffs and guardrails belong. This is precisely the execution-versus-judgment exercise that has to happen before any agent, build-time or run-time, gets deployed against a real process. Skipping that exercise for run-time agents produces the same disappointing result we’ve already seen when it gets skipped for build-time agents: a chatbot bolted onto an unchanged workflow, delivering a marginal improvement that quietly convinces leadership the technology doesn’t work.
Why this requires a governance layer that spans both waves
This is the specific problem elsai Platform is built to solve. We do not see it as an engineering-agent or application-agent platform, but as a governance layer that works across both.
The same disciplines apply in both waves: a shared, versioned instruction and acceptance-criteria layer, so a run-time KYC assistant and the agents around it are operating against the same definition of a compliant, complete customer file that build-time agents operate against for a completed sprint. Deliberately designed agent-to-agent workflows, so a document-verification agent and a risk-scoring agent inside a banking application coordinate the same way a BA agent and a Dev agent should. A defined human-in-the-loop threshold, so a run-time agent escalates to a named KYC officer under the same disciplined logic that a build-time agent escalates to a named code reviewer. And full observability over what every agent build-time or run-time actually did, and what it cost.
The platform’s control plane does not distinguish between these two waves architecturally. The same governance principles that keep engineering agents coordinated instead of adversarial are exactly what keep a run-time KYC agent, a loan-eligibility agent, and an onboarding agent from producing the same kind of conflicting, ungoverned mess inside a live banking application.
Two paths to buy-in and why we're building for the second one
In practice, there are two ways this conversation starts, and it’s worth naming both honestly.
The first is client-led: surface the run-time agent opportunity during the modernisation engagement itself, and see whether it gets traction. Sometimes it does. Often, without sustained push, it quietly becomes “let’s revisit next year” and the moment passes.
The second is proactive: bring a domain SME into the engineering team ahead of any client ask, and use that expertise to identify concrete run-time agent opportunities, build out the architecture and integration approach, and pitch a scoped, costed proposal with the groundwork already done. This path converts far more often, because the client is reacting to something concrete rather than a hypothetical.
This is the model we are building toward with elsai Platform not just a governance platform, but a practice that pairs the platform with real domain expertise across banking, healthcare RCM, and procurement, so that the run-time agent conversation can start with a credible, scoped proposal rather than an abstract pitch. That bench of domain SMEs does not build itself; it takes deliberate investment, which is exactly the kind of commitment we believe this moment calls for.
“elsai Platform exists to make sure organisations don’t have to choose which half to solve. It is built as one governance layer, spanning the agents that build your software and the agents that will one day live inside it.”
Why this can't wait
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 a workforce of over 600,000 people, matched by a comparable number of agents working alongside them.
That scale of shift is not unique to one company or one industry. It is coming across BFSI, healthcare, and manufacturing the same verticals elsai Platform is built to serve. For CTOs inside these industries, and for technology partners like us, the moment to plan for both waves of agentic transformation build-time and run-time is now, while the modernisation is still underway, not after it has shipped and the architecture has already foreclosed the easier path.
Recent blogs
Secure your agents
We’d love to chat with you about how your team can secure and govern Ai agents everywhere
Get a demo →
