Enterprise artificial intelligence (AI) has reached a paradoxical stage. It resembles a puppet on strings – owning the technology is not enough; the real skill lies in making it move with purpose and dance to the enterprise’s tune.
Companies have access to more models, copilots, coding assistants, and AI agents than ever before. Yet, for many enterprises, measurable business returns remain frustratingly elusive.
Vaibhav Vora calls this widening gap between AI adoption and business value the “Great AI Disconnect”. The problem, he says, is often not the AI model itself. It is the environment into which the technology is introduced: legacy applications, fragmented data, outdated workflows, disconnected systems, and operating models designed long before agents and real-time intelligence entered the enterprise.
AI readiness, therefore, involves much more than deploying a model or adding a copilot. It requires organisations to modernise applications, prepare data and cloud environments, redesign workflows, rethink software delivery, and create operating models in which people and AI agents can work together.
Ascendion was launched as a separate legal entity in October 2022, drawing on engineering capabilities developed within a longer-established business ecosystem. In 2025, the company began integrating Collabera Digital under the Ascendion brand to expand its global engineering and delivery footprint.
Ascendion describes itself as an AI-native, platform-driven software engineering company. It says more than 11,000 engineering professionals work alongside over 10,000 AI agents across 12 countries, serving more than a third of the Fortune 500. These are company-reported figures.
Its proprietary agentic AI platform, AAVA, applies AI agents across planning, product design, software development, testing, deployment, and operations.
In this conversation with Dataquest, Vaibhav Vora, Chief Technology Officer, Ascendion, explains why enterprises must look beyond coding productivity, how AI agents are changing the software development lifecycle, why legacy modernisation has become a major AI opportunity, and how India’s Global Capability Centres (GCCs) are moving from labour arbitrage towards end-to-end business ownership.
Ascendion describes itself as an AI-native engineering company. What does being AI-native mean in practical terms?
Brownfield transformation is always difficult because an organisation must first unlearn legacy processes and then redesign itself for the future. A greenfield organisation has more freedom to begin with a different operating model.
Ascendion was launched as a separate legal entity in 2022, although our engineering heritage and capabilities go back further through the broader business ecosystem from which the company emerged.
We initially had a strong automation-led mindset. Around four years ago, however, we began rewiring the organisation around AI, generative AI, and subsequently agentic AI.
We describe ourselves as an AI-native, platform-driven engineering services company. Anything we do is approached through a platform-driven lens, supported by AAVA, the agentic AI platform we have developed in-house.
AAVA covers the end-to-end software development lifecycle, with people and AI agents working together as one team in production environments to deliver customer outcomes.
That differs from adding AI to a conventional delivery model as an additional tool. We had the opportunity to redesign our organisation, delivery processes, roles, and technology platform around an AI-native mindset.
You describe a widening gap between AI adoption and measurable business outcomes as the “Great AI Disconnect”. Where does that disconnect come from?
The first thing we must do is move away from trying to assign a cost to digital labour in exactly the same way that we assign a cost to human labour.
What ultimately matters is the outcome delivered to the customer.
Those outcomes cannot be achieved merely by using AI or adding AI to an existing service. Enterprises must become ready for AI.
That involves modernising legacy systems, but it is not limited to rewriting code. Enterprises must also examine whether workflows designed many years ago remain relevant to how technology operates today and how it may operate six months from now.
Data readiness, cloud readiness, infrastructure readiness, and an agentic operating model are equally important.
When we discuss AI-driven revenue, we look at all these elements together. We do not define it narrowly as revenue generated by a particular AI tool, model, or coding assistant.
The opportunity is much larger than using AI to improve delivery productivity. It is about preparing the enterprise to operate differently.
Does that mean enterprises should evaluate AI through business outcomes rather than the cost of human and digital labour?
Yes. The cost of an AI agent, computing capacity, or token consumption is relevant, but it cannot become the primary measure of success.
The customer is ultimately interested in the outcome. That could be faster delivery, lower operating costs, improved customer experience, reduced risk, or the ability to address a problem that was previously too expensive or complex.
The industry must move away from comparing digital labour directly with human effort. We should instead examine what a combined human-and-agent team can deliver.
Ascendion has said that a chief executive officer must also become a chief AI officer. Is this about leadership ownership or applying AI throughout the enterprise?
There are two dimensions to that statement.
The first is how we use AI internally and change the way our own enterprise operates. The second is how we apply that experience when delivering services to customers.
You cannot preach something that you do not practise.
Our internal information technology team is not merely AI-trained; it is AI-skilled. It includes prompt engineers and context engineers alongside people working in conventional enterprise technology roles.
We have also developed an internal knowledge and action assistant called NAVI. Employees do not have to navigate multiple portals to find a policy, submit leave, or undertake an expense-related action.
They can interact with NAVI in natural language. The assistant retrieves the relevant information and, where appropriate, connects with the underlying enterprise systems to carry out the action.
That is similar to the direction in which many customers are moving. Our internal experience gives us a practical foundation when we help customers redesign their workflows and operating models around AI.
Does a customer have to adopt AAVA, or can Ascendion work with AI platforms in which the enterprise has already invested?
It is not a one-size-fits-all approach.
The way we engage depends on where the customer is on the AI maturity curve. AAVA may be appropriate in some situations, but many large enterprises, particularly in financial services, have already invested significantly in enterprise AI and agent platforms.
When customers have developed capabilities around other platforms and coding environments, we work with those investments. We meet them where they are rather than asking them to discard what they have already built.
We can combine our capabilities with the customer’s existing environment using the Model Context Protocol (MCP), agent-to-agent capabilities, and integrations with enterprise systems.
The objective is not to impose a platform. It is to create the right engineering environment for the outcome the customer is trying to achieve.
How is agentic AI changing the traditional software development lifecycle?
We now refer to it as the AI-driven development lifecycle, or ADLC, rather than only the conventional software development lifecycle (SDLC).
The roles involved in software engineering are changing. The traditional definition of a developer is no longer sufficient.
Organisations increasingly require prompt engineers, context engineers, and agent engineers. They also need professionals who understand how enterprise knowledge can be made available to AI systems.
Context is critical. Enterprises hold large volumes of structured and unstructured information, along with knowledge retained by subject-matter experts. Context engineers help make that information accessible and relevant to the programme, workflow, or agent performing a task.
Our team composition has changed significantly as a result. The delivery process has also changed.
The conventional two-week agile sprint is no longer always necessary. Depending on the scale and complexity of a programme, requirement deliberation may happen two or three days before the sprint, while the sprint itself may shrink to three or five days.
Design, development, and testing can increasingly happen in parallel.
Elements of operations must also be considered during the design stage, particularly when systems include predictive maintenance, proactive monitoring, and generative AI capabilities.
Operations can no longer be treated as an afterthought after an application enters production.
Does this change the traditional division between development and operations teams?
The distinction between the two is becoming blurred. Operational requirements must be designed into the system from the beginning. Teams responsible for monitoring, reliability, maintenance, and production support increasingly participate in design and development decisions rather than waiting for an application to be deployed.
Operations itself is also changing. The traditional Level 1, Level 2, and Level 3 support structure is increasingly being preceded by a Level 0 layer, in which an AI agent becomes the first point of interaction.
This applies to both internal enterprise support and external customer service operations. The agent attempts to understand and resolve the request before escalating it to a person.
The type of work undertaken by operations teams changes as a result. Operational knowledge also feeds back into how applications are initially designed.
Can you provide an example of this model being used in a customer environment?
We recently worked with a large grocery retailer in the United States to transform its customer service operations.
Previously, when customers called its toll-free number, most interactions were handled by human agents. The average call-handling time was approximately 20 minutes, and around 90% of incoming calls were routed to people.
We introduced a natural-language AI agent as the Level 0 interaction layer. Customers could speak naturally to the system rather than navigate a conventional interactive voice response menu.
The average handling time fell from around 20 minutes to less than four minutes. The proportion of calls routed to human agents declined from approximately 90% to about 20%.
The retailer’s Net Promoter Score (NPS), which had been in the low 50s, significantly increased.
This illustrates how the build and operations environments are coming together. The operational model is no longer separate from technology design.
Has AI made conventional waterfall development irrelevant, particularly for legacy modernisation?
In my view, the waterfall model had already become less relevant, but agentic AI has accelerated the change.
Legacy modernisation was traditionally one of the areas most likely to follow a waterfall-style approach.
A team would first reverse-engineer the existing application, understand the code and embedded business logic, map the current process, design the future process, and then begin forward engineering.
Agents can now undertake significant parts of the reverse-engineering process. They can examine code and supporting documentation, identify anomalies, and flag areas where an application may not comply with organisational, technical, or regulatory guidelines.
We recently completed a legacy modernisation programme for a large financial services customer without following either a conventional waterfall or agile model.
Reverse engineering was agent-first, with people validating the output. Process transformation and mapping were human-first, with agents providing support. Forward engineering was again agent-led, with people remaining in the loop for validation.
That is closer to an ADLC approach than either waterfall or conventional agile delivery.
How does AAVA support the AI-driven development lifecycle?
AAVA is the agentic platform we use while delivering customer outcomes across the software development lifecycle.
It covers planning, definition, design, development, testing, deployment, and operations. It also extends into areas such as financial operations and the management of token consumption in cloud-native and AI-intensive programmes.
The platform includes seven studios, each designed for a different persona within the lifecycle.
For example, product managers, product owners, and business analysts can use the Product Studio. It can take an initial idea, develop a business canvas, define user personas, create a feature roadmap, and generate epics and user stories.
Those outputs can then be transferred into the enterprise system selected by the customer.
The value of the platform does not come only from providing generative or agentic capabilities. Several other companies offer or claim similar capabilities.
An important differentiator for us is the way AAVA connects with the enterprise technology environment.
Why has context engineering become so important?
The largest problem we have encountered over the past two years is that enterprise knowledge exists in multiple locations and formats.
In many cases, organisations do not know where all that knowledge resides.
AAVA has more than 75 prebuilt integrations connecting with enterprise tools used for work management, documentation, service management, observability, and telemetry.
These integrations allow the platform to access relevant enterprise knowledge and bring it into the workflow or agent performing a task.
We maintain context at several levels: the platform level, the workflow level, and the individual agent level.
A workflow may consist of a sequence or combination of agents, with each receiving the context required for its particular role.
Without this structure, teams can spend days, weeks, or months locating information, supplying it to the AI system, and determining whether it is relevant.
Context engineering makes that process more resilient and efficient.
Why has legacy modernisation emerged as one of the largest opportunities for enterprise AI?
Using AI to assist with tasks that people already perform every day is a reasonable application of the technology, but it may not be its optimal use.
The greatest value comes from solving problems that organisations previously avoided because they were considered too complex, too expensive, or practically impossible.
Legacy modernisation is a good example.
Industries continue to depend on applications written in languages such as COBOL and PL/I. Some of these systems are 40 or 50 years old but continue to perform critical functions, particularly in financial services.
Businesses were often unwilling to fund their modernisation because the programmes would have been too expensive and taken too long, while the applications were still functioning in production.
AI changes the economics and feasibility of that work. It can help organisations understand undocumented applications, reverse-engineer code, discover embedded business rules, and accelerate forward engineering.
That is why companies across the industry now see legacy modernisation as a major AI opportunity. It is an area that was historically neglected but has become much more achievable.
Can AI agents undertake this work autonomously, particularly in regulated industries?
There are still unresolved issues. We have autonomous agents, but auditability and traceability remain significant challenges, particularly in regulated industries.
An organisation must understand why an agent took a particular decision, whether it could have reached a different conclusion, and how that action can be audited if it results in a regulatory inquiry in the future.
Some progress has been made, but I do not believe the problem has been completely solved.
Legacy modernisation also cannot be treated as an isolated coding exercise. To realise its full value, organisations may require cloud modernisation, data modernisation, stronger governance, and changes to the surrounding operating environment.
The market is crowded with AI coding and testing assistants. Where is the larger software engineering opportunity?
Coding and testing productivity should now be considered a given.
Software engineering has been evolving for years. When I began coding more than two decades ago, integrated development environments did not provide the kind of code completion and syntax assistance that engineers later came to expect.
DevOps subsequently improved how software was built, tested, and deployed. Generative AI represents another significant step in that evolution.
There are now many tools that can generate code, create test cases, develop test scenarios, and produce automation scripts.
However, applying AI only to development and testing is not the optimal use of the technology. Enterprises must address the entire lifecycle.
On the left side, that includes how requirements are defined, products are designed, decisions are documented, and business context is brought into engineering.
On the right side, it includes deployment, monitoring, maintenance, reliability, and operations.
The opportunity is to improve the end-to-end lifecycle, not merely accelerate the portion in which code is written.
Which industries are driving demand for this type of AI-led engineering?
Banking, financial services, and insurance are among our strongest sectors, followed by healthcare and life sciences. Retail and consumer goods are also important areas for us.
Banking, insurance, healthcare, and life sciences are heavily regulated, although regulatory requirements differ across North America, the United Kingdom, Europe, and the Asia-Pacific region.
Technology alone cannot solve these problems. Organisations also need deep domain knowledge and an understanding of the regulatory context in which the technology will operate.
We have developed that domain capability internally so that we can combine industry context with engineering and AI capabilities.
How do you see India’s role changing as AI reshapes enterprise technology delivery?
India is at the core of this transformation. The country’s GCC ecosystem has evolved significantly over the past 20 years, but the change over the past four or five years has been particularly striking.
India and its GCCs can no longer be viewed only through the lens of cost or labour arbitrage. Even a few years ago, GCCs were increasingly described as innovation hubs. They are now moving beyond that description.
Many GCCs have become part of global reporting structures. There is no longer always a clear division between the headquarters and the India organisation.
Leaders based in India are increasingly responsible for global verticals, horizontal capabilities, platforms, products, and business outcomes.
India is therefore being viewed as an AI-native hub capable of owning outcomes end to end, rather than as a location that executes one part of a project.
The same applies to our organisation. Leaders based in Bengaluru, Chennai, Pune, Hyderabad, and other Indian locations hold global mandates and manage teams distributed across markets.
What value can an engineering services company bring to a GCC that is already building substantial internal capabilities?
We see a three-part opportunity.
The first is to meet the GCC where it currently stands and help accelerate its AI journey. That may involve applying AI to existing work, redesigning workflows, or reskilling teams in generative and applied AI.
The second is to help the GCC deliver the end-to-end outcomes it owns for the global organisation.
For example, if it has been given responsibility for a legacy modernisation programme, we can work alongside its teams and help deliver the complete outcome rather than only supplying additional capacity.
The third and most significant shift is helping companies either establish an AI-powered GCC from the first day or transform an existing GCC into what we describe as a “GCC to the power of AI”.
That transformation applies not only to software delivery. It can also affect how the GCC itself operates across finance, supply chain, technology, and enterprise operations.
Clearly, GCCs increasingly want to own global outcomes rather than execute isolated parts of a programme. The next stage of their evolution will be defined by how effectively they combine that ownership with AI-native operating models.
