An AI agent can decide what should happen next, yet still fail at the final step: entering an approved change into an old application. That gap matters to Indian banks, insurers, telecom operators and service businesses with systems that cannot all be replaced at once.
HCLSoftware's plan to acquire Robotiq.ai puts that gap in focus. The useful question is where an API, a software robot or a person should execute each step of an agentic workflow.
What the HCLSoftware announcement actually changes
On 28 September 2026, HCLSoftware said it intended to acquire Zagreb-based Robotiq.ai and add its enterprise RPA capability to HCL UnO Agentic. The combination is meant to let AI-led workflows act where APIs are unavailable or inadequate. It expects the acquisition to close in November 2026, so integration remains a stated direction, not a finished product fact. Those details come from the official HCLSoftware acquisition announcement.
An agent may interpret an email, classify a request and propose the next action. RPA can reproduce controlled actions in a legacy system. Neither capability proves that the full process is safe, reliable or economical.
Use an API when the system offers a dependable one
An API is usually the cleanest route because it gives software a defined contract: accepted fields, authentication rules, responses and errors. It is easier to test than screen automation and less likely to break when a button moves. If the target system offers a maintained API for the required action, begin there.
Check whether it covers the complete task. A customer-service platform might permit reading a ticket but not changing a sensitive account field. An agent could prepare that change for human approval instead of forcing RPA into a privileged action.
Use RPA for stable gaps, not as a universal connector
RPA earns its place when an application has no suitable API, its interface is reasonably stable and the action follows explicit rules. Examples include transferring approved information into a long-running desktop application or collecting status from a fixed internal screen.
It is a poor fit when layouts change frequently, data is inconsistent or the task requires judgment. A bot can fail on a pop-up, changed label or partially loaded page. List likely exceptions and decide how the workflow will stop, alert an operator and resume without duplicating work.
Keep people at irreversible decision points
Human review belongs before actions that are difficult to reverse or materially affect a customer, employee or supplier. Releasing a payment, closing an account, changing an entitlement or sending a binding communication should not become automatic merely because tools can execute it.
Permissions also need precise design. IndiaPress24's AI agent tool-permissions checklist explains why teams should separate read, propose, approve and execute rights. Keep that separation when an RPA bot becomes the agent's hands.
A three-route decision framework
For every process step, choose the narrowest route that works:
| Route | Best fit | Main failure to test | Default control |
|---|---|---|---|
| API | Supported, structured system action | Timeout or rejected request | Idempotency key and logged response |
| RPA | Stable legacy interface without a sufficient API | Screen or field change | Screenshot evidence and exception queue |
| Human | Ambiguous, sensitive or irreversible decision | Inconsistent judgment or delay | Approval criteria and escalation time |
One workflow can use all three. Choosing one technology throughout may simplify a diagram while making operations more fragile.
Example: a service-request workflow
Illustrative example: an Indian telecom enterprise receives a business customer's service-address request. An agent reads the message and extracts the account number. An API retrieves the account and checks mandatory fields. A person reviews the address proof and approves the change. RPA enters the approved address into a legacy provisioning tool without a suitable API; the API then sends confirmation.
This keeps document judgment with a person and gives the bot one bounded task. It creates separate evidence for retrieval, approval, legacy entry and notification. It is a decision model, not an HCLSoftware deployment claim.
Run a bounded pilot before comparing vendors
Start with one process, one legacy application and one defined output. The same-site guide to automating admin work with a prototype and fallback is relevant: keep a usable manual route while measuring the pilot.
Track completion rate, exception types, human-review time, duplicate-action prevention and recovery time. Record software versions and interface changes. A demonstration that completes ten clean cases is less useful than a pilot that exposes the eleventh, messy case.
Questions to answer before production
- Which steps read data, propose an action, approve it and execute it?
- Why is RPA needed where an API or manual approval is insufficient?
- Can the automation detect an already successful action before retrying?
- What evidence is stored without unnecessary personal data?
- Who owns exceptions, access reviews and interface-change monitoring?
- How quickly can the team disable the bot and return to manual work?
If owners cannot answer these questions for each step, the process is not ready for production-scale agentic automation.
Conclusion
The HCLSoftware–Robotiq.ai announcement highlights a real need: AI agents require a controlled way to act in older systems. Prefer dependable APIs, reserve RPA for stable gaps and keep people at sensitive decisions. Map one workflow step by step, assign the safest route and test recovery before evaluating scale.
