HCLSoftware Buys Robotiq.ai: Why Agentic AI Still Needs RPA

On September 28, 2026, HCLSoftware, the software business division of HCLTech, announced its intent to acquire Robotiq.ai, a Zagreb-based provider of an enterprise robotic process automation platform. According to HCLTech's regulatory disclosure, the enterprise value is EUR 9 million, payable as 100 percent cash, with completion expected by the end of November 2026. The interesting part is not the price. It is that a vendor whose pitch is agent orchestration is buying task-level execution, because a large share of enterprise work still lives in applications that expose no usable API.

1. What Was Announced

Start with the deal. HCLSoftware announced it on September 28, 2026. The target, Robotiq.ai, is legally Robotic Process Automation d.o.o., incorporated in Croatia on August 21, 2018. HCLTech's filing reports revenue of EUR 0.9 million for 2023, EUR 0.9 million for 2024 and EUR 1.4 million for 2025, with profit after tax of EUR 0.2 million and net worth of EUR 0.8 million for the year ended December 31, 2025. The enterprise value of EUR 9 million is to be paid in cash, with 100 percent of the equity acquired by HCL Technologies Austria GmbH, a step-down wholly owned subsidiary of HCLTech. HCLSoftware said the acquisition adds RPA capabilities to HCL UnO Agentic, its AI-powered enterprise orchestration platform.

# The routing decision you now have to make explicitly: price the API path
# first, and only fall back to the interface (RPA) path when there is none.
# HCL's own framing is that RPA covers "applications where APIs are
# unavailable or insufficient" -- that clause is the whole justification.

from dataclasses import dataclass

@dataclass
class Target:
    name: str
    has_api: bool
    api_scope_ok: bool
    ui_stable: bool

def execution_tier(t: Target) -> str:
    if t.has_api and t.api_scope_ok:
        return "api"          # cheapest, fastest, easiest to test
    if not t.ui_stable:
        return "manual"       # do not automate a moving target
    return "rpa"              # interface-level fallback, governed + logged

print(execution_tier(Target("core-banking", False, False, True)))   # rpa
print(execution_tier(Target("payments", True, True, True)))         # api

RPA's contribution is reach, not intelligence

2. The Thesis: Agents Reason, RPA Executes

The framing in the announcement is unusually direct. HCLSoftware says enterprises are looking beyond experimentation toward production-scale automation that is secure, governed and reliable, and that Robotiq.ai adds RPA so AI-driven workflows can automate tasks in applications where APIs are unavailable or insufficient. That last clause is the whole argument. An agent that can call tools is limited to the systems someone has already wrapped in a tool. A bank's core system, a thirty-year-old insurance portal, a telecom provisioning console, a supplier's web-only admin panel: none of these ship an MCP server. RPA reaches them the way a human does, through the interface.

# A Robotiq-style "digital teammate" is really a task contract. Keep the
# contract small and declarative so a human can review it before it runs.
# HCLTech notes the platform is used in banks, insurers and telcos, where
# an unexplained automation step is a compliance problem, not a bug.

task:
  id: close-month-end-reconciliation
  system: legacy-insurance-portal      # no supported API
  steps:
    - action: open_report
      selector: "#menu > .reports > a[data-key='recon']"
    - action: export_csv
      selector: "button[aria-label='Export']"
    - action: upload
      target: "s3://fin-ops/recon/inbound/"
  guards:
    destructive: false
    max_runtime_minutes: 30
  on_failure: screenshot_and_stop

3. Why API-less Systems Are the Real Blocker

Model Context Protocol has made it easy to give agents tools, but only for systems that expose one. The long tail of enterprise software is exactly the part that does not. This is why the agent conversation keeps stalling in pilots: the demo works on a modern SaaS API, and the production task involves five desktop applications plus a spreadsheet that only opens on Windows. RPA's contribution is not intelligence, it is reach. Robotiq.ai describes its software robots as digital teammates that can be built, deployed, operated and monitored at scale, with ISO-certified security, audit logs and flexible deployment, and HCLTech notes the platform is used in large banks, insurance groups and telecom providers. Code sample 1 shows the routing decision you now have to make explicitly: try the API first, fall back to the interface only when there is none.

# Every robot action should leave a record a compliance team can read.
# "ISO-certified security and audit logs" is a vendor claim; the schema
# below is what you actually have to be able to produce on request.

def audit_event(actor, task_id, system, action, decision, result, ts):
    return {
        "ts": ts,                    # UTC, RFC3339
        "actor": actor,              # "rpa:month-end-recon" (not a human)
        "task_id": task_id,          # the reviewed contract that approved it
        "system": system,            # which application was touched
        "action": action,            # open_report / export_csv / upload
        "decision": decision,        # allow | ask | deny
        "result": result,            # ok | failed | timed_out
        "evidence": "run-2026-09-29/recon.mp4",  # screen capture
    }

Extending orchestration from decision-making to execution

4. The Price and What It Implies

Work the arithmetic on the disclosed figures and the multiple becomes the story. EUR 9 million against EUR 1.4 million of revenue is roughly 6.4 times sales; against net worth of EUR 0.8 million it is about 11 times; against profit after tax of EUR 0.2 million it is around 45 times. Nobody pays that for a services-like company whose revenue was flat the year before. They pay it for a capability: execution inside systems that were never designed to be automated through an API. For developers, the useful reading is that the execution layer is now a paid, strategic component of the agent stack rather than an afterthought bolted on with a screen scraper.

# Destructive interface actions are where agentic autonomy gets expensive.
# Gate them behind an explicit human approval, and record who approved.
# The point is not to slow the workflow down -- it is to make the one
# irreversible class of action impossible to trigger unattended.

DESTRUCTIVE = {"delete_record", "send_payment", "approve_claim", "upload"}

def gate(action, approver=None, policy=None):
    if action not in DESTRUCTIVE:
        return {"decision": "allow"}
    if approver is None:
        return {"decision": "ask", "reason": "destructive interface action"}
    if policy and approver not in policy.allowed_approvers:
        return {"decision": "deny", "reason": "approver not authorised"}
    return {"decision": "allow", "approved_by": approver}

5. Where RPA Belongs in an Agent Stack

Treat RPA as the fallback tier, not the first choice. An API or an MCP tool is faster, cheaper, more testable and easier to govern. A UI robot is the opposite: brittle to layout changes, expensive per run, and hard to test deterministically. So use an explicit decision order. Code sample 1 routes by availability. Code sample 3 defines the audit record every robot action should emit, because a governed process has to answer who acted, on which system, with what result. Code sample 4 gates destructive actions behind human approval. Code sample 5 compares the cost of an agent turn against a robot run, so you can see when RPA is buying reach and when it is just buying spend.

# Cost sanity check: a robot run and an agent turn are priced very
# differently. Use this to see when RPA is buying reach (worth it) versus
# when it is just buying spend (write the API instead).

AGENT_TURN_USD = 0.012      # one model call + a couple of tool calls
ROBOT_RUN_USD  = 0.35       # hourly RPA licence + VM, per run
API_CALL_USD   = 0.0004

def monthly(tasks_per_day, tier, days=22):
    per = {"api": API_CALL_USD, "rpa": ROBOT_RUN_USD, "manual": 4.00}[tier]
    return round(tasks_per_day * days * per, 2)

print(monthly(500, "api"))     # 4.4
print(monthly(500, "rpa"))     # 3850.0  -> build the API if volume is real
print(monthly(20,  "rpa"))     # 154.0   -> fine for a long-tail exception

A governed process must answer who did what

6. What This Signals

Two things are worth taking away. First, the agent control-plane conversation has a physical floor: orchestration is only as valuable as the actions it can actually take, which is why the money is moving toward execution. Second, the RPA-versus-agents framing was always a false choice. The stack that survives contact with production looks like API-first with a governed interface tier underneath, and a single audit trail across both. If your roadmap has agents that must touch a system with no API, the question is not whether to add an execution tier but who governs it. Decide that now, in writing, because the interface layer is exactly where automation quietly acquires permissions nobody remembers granting. Start by listing, per agent, which actions are API-backed and which are interface-backed, then put an approval requirement on everything destructive in the second list. That single exercise tells you whether you need RPA at all, or just better APIs.