Ruslana Reznikova: Why service operations will decide which AI agents scale in APAC

Many enterprise AI agent projects begin with a narrow service task. The agent is trained on a defined knowledge base, tested on common questions, and evaluated on its ability to respond accurately without human intervention.

That works when the request is simple. It becomes less reliable when customers expect the business to remember earlier conversations, check account or order information, complete service requests, or transfer the case to a human agent without forcing them to start again.

Across APAC, deployment is further complicated by differences in messaging platforms, languages, and rules on identity, consent, and escalation. In this editorial interview, Ruslana Reznikova, VP General Manager, APAC & Eurasia at Infobip, explains why AI agent adoption depends on the service operation around the model.

Production readiness starts outside the model

AI agents are often tested in controlled environments, where the knowledge base, customer scenarios and performance metrics are clearly defined. Live customer service is less predictable. Once an AI agent has to retrieve customer history, move across channels, trigger actions and decide when human support is required, where do weaknesses usually appear first?

Ruslana Reznikova: Once an AI agent enters production, the demand becomes much more operational. Customers ask questions in different ways, switch between channels, refer to past interactions and expect the business to understand the full context of their issue. The agent also needs to act on information, not only respond to questions.

That is where many enterprises discover the gap between a successful pilot and a scalable deployment. Customer data may be incomplete, CRM or contact centre systems may not be fully integrated, channel experiences may vary across markets, and escalation rules may be too vague for agents to make consistent, informed decisions. Production readiness should therefore be assessed beyond model performance. Enterprises need to examine the operating environment around the agent, including data quality, system access, handoff design, audit trails and fallback processes.

This is especially important across APAC, where deployment conditions vary by market. Customers may use different messaging platforms, describe the same issue in different languages and expect service teams to follow local rules on identity, consent and escalation. A model that performs well in testing still needs the right service structure around it before it can operate reliably in live customer journeys.

Data and systems decide whether agents can act

An AI agent can understand a customer’s words and still miss the context behind the request. That happens when order details, complaint history, loyalty records, billing information or previous interactions are stored in separate systems. Once agents are expected to complete tasks rather than answer basic questions, how do fragmented data and legacy systems limit deployment?

Ruslana Reznikova: When customer information is spread across separate systems, the agent only sees part of the picture. The agent may know that someone is asking about a refund, but not that the same person received a promotional message earlier that day. It may see a support ticket, but not the order status, loyalty profile, delivery update or previous complaint linked to that individual.

For instance, a customer asking about a delayed order may receive accurate store information, but not the answer that best fits their profile or past preferences. The answer is correct in isolation, but insufficient for the customer’s situation. The impact becomes more significant when agents are expected to take action because they need current, verified information from the relevant systems. If a customer wants to update an account, change an appointment, process a refund, track an order or retrieve a case record, the agent needs access to systems that can both provide information and receive instructions.

Many older systems were built for internal process execution, rather than real-time customer conversations. They may not expose data easily, may depend on manual updates, or may not support the speed required for live engagement. The most common bottlenecks are typically found in CRM, contact centre, billing, order management, identity and case management systems. If these systems cannot share data quickly, the agent may not understand the customer’s current status or history. If they cannot receive instructions from the agent, the customer may still need to leave the conversation and complete the task elsewhere.

Before scaling, enterprises should examine three areas. The first is data access: what information can the agent safely read, and is it accurate and up to date? The second is actionability: which systems can the agent trigger? The third is control: what permissions, approvals, audit trails and human review processes are required?

It is not always necessary to replace every legacy system immediately. A more practical path is to start with high-impact use cases, connect the systems that matter most and build integrations that can expand over time.

Regional deployment needs a common model with local flexibility

A deployment that works in one market may not translate cleanly into another. APAC enterprises often manage multiple messaging platforms, languages, regulatory expectations, and levels of digital maturity simultaneously. Which factors usually create the greatest complexity when AI agents are deployed across the region?

Ruslana Reznikova: In APAC, complexity rarely comes from one factor alone. It usually comes from the way market, language, channel, regulation and technology differences overlap. Channel diversity is one of the clearest examples. Infobip’s Messaging Trends 2026 Report shows how APAC markets lean toward different platforms, from WhatsApp in Malaysia and Indonesia, to LINE in Japan, Kakao in South Korea, Zalo in Vietnam and Viber in the Philippines.

This is important because the customer experiences the agent through the channel they already use. An AI agent cannot be designed around one channel and then replicated across the region. It needs to recognise intent, preserve context and maintain service quality across the channels customers actually use.

Language and regulation add further complexity. Localisation is more than translation. Customers may describe the same issue differently, while expectations around tone, speed and detail can vary. In regulated sectors, identity, consent, privacy and escalation must also reflect local requirements.

For enterprises, the task is to bring these differences together without creating separate AI deployments for every market. That requires a common operating model with sufficient flexibility to accommodate local customer behaviour, channel preferences and regulatory requirements.

The challenge also differs by sector. BFSI deployments place heavier emphasis on trust, identity verification, audit trails and compliance. Retail and e-commerce deployments tend to face pressure around volume, returns, refunds, product availability and loyalty data. Telco environments can be especially complex because a single request may involve billing, roaming, SIM issues, service troubleshooting, plan changes or upgrades. Across these sectors, context is the deciding factor. What changes when context is missing? In retail, it may mean a lost sale. In telco, it may lead to repeat calls. In BFSI, it may create trust, compliance or risk concerns.

Human handoff and governance define the limits of autonomy

Escalation is often treated as a safety net once automation is already live. In practice, the handoff can determine whether the customer experiences the AI agent as part of the service journey or as another disconnected layer. At the same time, enterprises in regulated sectors must decide which agents are allowed to act, when human review is required, and who remains accountable. What should be designed upfront?

Ruslana Reznikova: Human handoff needs to be designed into the journey from the beginning. Customers quickly lose trust when they explain their issue to an AI agent, get transferred to a human agent, and then have to repeat the same information. That experience makes the automation feel disconnected from the rest of the service operation.

Enterprises should define clear handoff triggers upfront, including low confidence in the agent’s response, signs of customer frustration, sensitive or regulated topics, repeated failed attempts, high-value transactions, or requests that require human judgement. The handoff must also carry the right information. A human agent should receive a concise summary of the conversation, the customer’s intent, relevant history, actions already taken, sentiment signals, the channel used, and any documents or images shared. The agent should also understand what the customer expects next. The aim is to ensure that escalation does not make the journey feel like it’s restarting.

Governance sets the other side of that boundary. In regulated sectors, enterprises should first define the limits of autonomy. This means being clear about what the AI agent is allowed to do, what it is not allowed to do, and where human review is required before the agent is placed in front of customers.

A practical starting point is to classify use cases by risk. A basic FAQ response does not require the same level of oversight as a payment-related request, identity verification, policy change, fraud alert, complaint or healthcare-related interaction. Each use case should have clear rules for authentication, consent, escalation, logging and approval. Internal teams also need to understand why an agent gave a particular response or triggered a certain action. The business should be able to review the decision path, the source of information, the customer context and the escalation logic.

Accountability needs clear ownership, too. Enterprises should know who monitors performance, reviews failures, updates knowledge sources, handles complaints and tests changes before deployment. In regulated sectors, AI agents create value only when automation is paired with governance, auditability and clear limits on autonomous action.

Production success is measured after resolution

Containment rates and automation volumes are often used to judge AI agent performance. Yet a chatbot interaction that stays inside automation is not necessarily a resolved customer issue. What should enterprises measure to determine whether an AI agent is genuinely working in production?

Ruslana Reznikova: Enterprises should measure AI agent performance beyond basic usage or deflection. Those numbers are useful, but they do not tell the full story. An AI agent is genuinely working in production when it simultaneously improves resolution, customer experience, operational efficiency and control.

In one anonymised digital insurer deployment, a GPT-enabled assistant managed 30% of inbound requests, supported a 330% increase in sessions, handled 90% of queries within three to five message exchanges, and contributed to a 31% increase in time spent on the website. In a separate financial platform example, 80% of inbound requests ended within the chatbot flow. These figures are useful, but they should not be read as proof of success on their own. The important question is whether customers completed what they came to do, and whether the experience remained clear, safe and useful.

Enterprises should look at containment rate, first-contact resolution, escalation quality, repeat contact rate, customer satisfaction, average handling time, completion rate, and whether human agents receive full context when cases are escalated. In regulated sectors, auditability, error rates and compliance review outcomes also matter.

The broader lesson is to start with practical, high-volume use cases where automation can create clear value, then scale into more complex journeys once the data, handoffs, governance and integrations are ready.

Service continuity will decide which agents scale

AI agent adoption across APAC is likely to grow first through customer service, where use cases are visible, repetitive and commercially easy to justify. The risk is that enterprises treat the agent as the deployment when much of the work sits elsewhere.

When customer records are incomplete, system access is limited, escalation rules are unclear, or performance is judged mainly by deflection, AI agents can appear effective while leaving service issues unresolved.

The practical divide will be between enterprises that deploy AI agents as a new interface and those that treat them as part of a wider service operation. The second group will be better placed to scale because it is building the customer context, system access, handoff processes and governance needed to resolve real issues without pushing complexity back onto customers or human agents.