The duality nobody priced in: Changing landscape of enterprise tech architecture and Agentic AI era

By Hasit Trivedi, Chief Digital & AI Officer, Firstsource

Enterprise technology is heading into its biggest overhaul in thirty years, and AI is handing us both higher velocity and higher complexity at the same time

Every enterprise architecture conversation right now eventually arrives at the same question: do we bolt AI onto what we have, or do we rebuild around it?

It is the wrong question, asked too early. Before an enterprise can answer it, it must understand what it actually built over the last three decades, why that architecture worked, and precisely which of its assumptions Gen AI breaks. Because the shift underway is not a technology refresh. It is the dismantling of a design philosophy that has governed enterprise software since the mid-1990s.

The next decade will bring a duality that most operating models are not built to hold – software will be produced faster than ever, while the work of architecting, designing and assuring it becomes materially harder. Net-net, enterprises will still move faster. But only the ones that see both halves of that equation coming will move faster safely.

How we got here: three decades of engineered sameness

The standardization bargain
Enterprise systems, as we know them, were designed to do one thing supremely well: standardize business process.

That intent gave us ERP, CRM, SCM, and, depending on the industry, CBS in banking, CIS in utilities, BSS in telecom. Each of these platforms encapsulated a decade of accumulated industry best practice. Buy the platform, inherit the process.

But standardization creates a problem: if everyone runs the same process, nobody differentiates. So, enterprises struck a bargain. They accepted the standard core and expressed their uniqueness in the layers above it — through configuration, customization, extensions and integration. The platform carried the process; the customization carried the context. That is where competitive differences lived.

Differentiation kept moving up the stack
As technology matured, the differentiation layers multiplied. Experience layers separated the interface from the engine. Omni-channel strategies made the same process available everywhere the customer was. Data warehouses and analytics platforms turned transaction exhaust into decisions. Together, these became the running machine of the modern enterprise: standardized underneath, differentiated on top, and continuously tuned. It worked, and it is still working today. Nothing about the Gen AI era changes the fact that a general ledger must balance and a policy must be underwritten correctly.

The ceiling nobody could break through
Wherever a process depended on unstructured input — documents, emails, contracts, claims files, chat logs, call recordings, images, video — automation stalled and human effort filled the gap. These became the stubbornly high-touch corners of the operation. Enterprises had squeezed most of the available juice out of structured-data e/efficiency; the remaining value was locked behind formats their systems could not read.

That is the real reason AI entered the enterprise stack — not fashion, but a ceiling.

Wave One: AI as a polite guest
The first AI wave answered that need: voice bots, chatbots, intelligent document processing, vision AI platforms. Adoption was rapid, and for one specific architectural reason — it was not intrusive.

Every one of those tools sat at the edge of the estate or on top of it. A document was read by an IDP engine and handed to the core as clean, structured fields. A chatbot deflected a query before it reached an agent desktop. The systems of record never had to change. AI was a polite guest that entered through the front door, did its job in the hallway, and never asked to move the furniture.

That era is over.

Why Gen AI breaks the pattern
Gen AI does not want to sit at the edge. It wants the middle.
The shift is from transaction-driven to intent-driven software. A traditional application exposes a screen or an API that performs one bounded, pre-defined operation. An agentic application accepts a goal — resolve this dispute, close this month, onboard this supplier, and works out the path, calling systems, reading data and taking actions along the way.

That single change relocates business logic. It stops living exclusively inside the system of record and starts living in an orchestration layer that reasons across systems. Which is precisely why this is an architecture problem rather than a tooling problem.

A caution: intent-driven software reads better on a slide than it runs in production
It is worth being honest about the maturity of what is being proposed here, because the language of intent — give the system a goal and let it work out the path — is seductive and considerably ahead of the engineering reality, exception are specific use cases.

Consider what “let it work out the path” actually means in an enterprise setting. Every alternative path the agent might take has to be one the business would have sanctioned. Every action has to be reversible, or bounded, or approved. Every failure has to be attributable. Traditional software earned reliability by removing optionality at design time. Intent-driven software deliberately reintroduces it — and then has to re-earn the reliability some other way. Nobody has fully worked out how.

Four things are still genuinely immature, and pretending otherwise is how Programmes get cancelled:
Design patterns are unsettled. We have no agentic equivalent of MVC, or of the transactional patterns that made distributed systems tractable. The industry is still arguing over the basics — single agent versus multi-agent, planner-executor versus reactive loops, how much autonomy to grant at each step, when to hand back to a human. These are being decided per project, by individual teams, largely from first principles. That is what an early field looks like.

Repeatability is weak. The same intent, expressed slightly differently, can produce a different path and a different outcome. That is tolerable in a drafting assistant and unacceptable in a payments reconciliation or an underwriting decision. Enterprises are discovering that a workflow which works in nine demos and fails in the tenth is not a workflow — it is a prototype.

Reliability degrades with chain length. Accuracy compounds downward across multi-step reasoning. A step that is 95% reliable is impressive in isolation and close to worthless twenty steps into an autonomous chain. Most production successes today are short-chain, tightly-scoped and heavily guardrailed — which is a very different thing from the open-ended intent-driven enterprise being described in keynotes.

Architecture principles do not yet exist. There is no accepted answer to where business logic should live, how state should be partitioned between the agent and the core, what belongs in a prompt versus in code, or how to version and release a system whose behavior is emergent. Reference architectures are being published faster than they are being validated in production.

None of this argues against moving. It argues against betting the operating model on maturity that has not arrived. The pragmatic posture is to treat intent-driven design as directionally right and operationally immature: scope narrowly, constrain the action space, keep humans on the consequential decisions, and expand autonomy only where evidence — not enthusiasm — supports it.

Four roads out of here
Enterprises will diverge sharply from this point. Four patterns are already visible.

1. Replace the automation layer. Retire RPA scripts and rules-based chatbots in favor of agentic workflows. Lowest risk, fastest payback, least architectural disturbance — the RPA estate was always brittle and was never load-bearing. It is also the road with the lowest ceiling. Nothing structural changes.

2. Build the agentic layer on top of the systems of record. The cores stay intact and become the transactional substrate; agents orchestrate above them. This is the most common enterprise choice and the most defensible one. The risk is subtle: business logic quietly leaks upward into the agent layer until you are running two competing sources of truth about how the business actually works.

3. Build the agentic layer alongside the systems of record — and let some cores go. A parallel system of action runs next to the system of record, and over time absorbs functions that never justified their license cost. Higher ambition, materially higher risk, and it demands genuine engineering depth. This is where the largest prizes and the loudest failures will both be found.

4. Plumb agents deep into the systems of record. Embedding agentic capability inside the core through native extension frameworks. Tightest integration, best data proximity, hardest to reverse — and the road most tightly coupled to a single vendor’s roadmap.

None of these is right or wrong, and most large enterprises will run several simultaneously across different domains. The choice, in practice, is governed by four factors:

Risk appetite — how much operational and regulatory exposure the business will tolerate

Technology capability — whether the engineering muscle to build and run this genuinely exists in-house

Aspiration — whether the goal is cost efficiency or a repositioning of the business
Complexity of the as-is landscape — the single most underestimated variable in every plan

The Complexity Tax
If velocity is the upside, this is the invoice. Six things get structurally harder.

1. Data access: from fine-grained permission to coarse-grained intent
This is the hardest problem in the new architecture, and it deserves to be named first.

Traditional applications received fine-grained access because the purpose of every access was sharply defined at design time. This screen, this role, these fields. Entitlements were static and auditable precisely because behavior was predictable.

An intent-driven agent cannot work that way. To fulfil an open-ended goal it needs to navigate data, which means coarse-grained access — and coarse-grained access is exactly what thirty years of data governance was built to prevent.

Enterprises that treat this as a security workstream to be handled later will discover it is the thing that caps how far agents can go.

2. Caching and cost: every engineer becomes a unit-economics engineer
Application developers were never asked to think about caching. The framework handled it; the architecture absorbed it.

Agentic applications traverse networks and call models constantly, and every one of those hops carries a token cost. Cost per transaction stops being an infrastructure line item and becomes a design variable — shaped by model routing, semantic caching, context size and retry strategy. A workflow that is functionally perfect and economically unviable is a failed workflow.
3. Context and memory: the discipline nobody was trained for
What went into local and global session state used to be settled in design, then templatized and de-skilled to the point where most developers never thought about it.

In agentic systems, memory is the product. Short-term working context, long-term memory, what gets retrieved, what gets summarized, what gets discarded — these decisions determine whether the system behaves reliably or degrades in ways nobody can reproduce. Context engineering is a first-class discipline now, and it sits with a much wider group of people than it used to.

4. Pattern-hopping: deterministic meets probabilistic
Most real functionality will be a hybrid: a web/OLTP front end, an agentic workflow in the middle, a system of record at the back. Each follows a fundamentally different design pattern, and data has to cross those boundaries intact.
Transaction integrity is the flashpoint. A deterministic core assumes commit-or-rollback; a probabilistic agent may take a sequence of actions that no transaction manager is holding together.

5. Assurance: when pass/fail stops working
You cannot regression-test a non-deterministic system with a binary test suite. Quality assurance shifts to evaluation sets, golden datasets, statistical acceptance thresholds and continuous production monitoring. Most enterprise QA functions are not resourced or skilled for this, and it is a common reason capable pilots never clear a risk review.

6. Observability and accountability
Traditional monitoring traces calls. Agentic observability has to trace intent — what the agent was trying to do, what it reasoned, what it touched, what it changed, and who is accountable. Without that trail there is no incident response, no audit defense and no regulatory story.

Code gets cheap, decisions get expensive
Put both halves together and the picture is clear.

Software will genuinely be produced at a rapid pace — that part of the promise is real and is already visible in delivery metrics. But architecture, design and assurance will slow the pace back down. The net is still faster. It is not as fast as the demos suggest.

More importantly, the bottleneck moves. When writing code is cheap, the expensive things become deciding what to build, proving it is safe, and governing it in production. The cost of a bad architectural decision rises precisely because the cost of implementing it has fallen. Bad decisions now scale at machine speed.

The enterprises that will look prescient in 2030 are not the ones with the most pilots. They are the ones that invested in foundations while everyone else was investing in demos.

Speed Is Not the Same as Progress
We habitually associate progress with speed. Yet the most resilient systems, technical and human alike, are the ones built patiently on strong foundations and a shared sense of purpose.

The same holds for organisations. Technology is evolving at an extraordinary pace, and it will keep doing so through this decade. But values, relationships and the trust built between people are what allow an enterprise to adapt without losing its direction.

The coming architectural overhaul is real, and it will be uncomfortable. The enterprises that navigate it well will not be the fastest movers. They will be the ones that moved quickly and knew exactly why, because they understood what they were building on, what they were giving up, and what they refused to compromise.

What road is your organisation taking, and did you choose it, or did your vendors choose it for you?