Robocorp leaves Robot Framework — Not a quality verdict

TL;DR: Robocorp was the main sponsor of the Robot Framework Foundation. In January 2024 the company was acquired by AI start-up Sema4.ai and declared RF deprecated — its reasoning: Python is better suited to AI agents. The move was a strategic pivot from RPA to AI agents, not a quality verdict on RF as a test framework. The RF Foundation has weathered the loss and now sits on a broader base of more than 60 member organisations than before.

Reading time approx. 10 min · As of: 2026-04

In early 2024 Robocorp deprecated Robot Framework on its platform. For enterprise teams using RF as a test automation framework, the question was straightforward: if the main sponsor steps away, how viable is the ecosystem still? The answer requires separating Robocorp’s business decision from the framework’s substance.

Timeline of the departure

On 29 January 2024 Robocorp announced its acquisition by the newly founded AI start-up Sema4.ai. Rob Bearden, formerly CEO of Cloudera, headed the new company. Two weeks later, on 15 February 2024, Robocorp published a deprecation page titled «Embracing Python for Automation-as-Code». Robot Framework was officially deprecated on the Robocorp platform. The first quarter of 2024 brought the rebrand: VS Code Extension and Action Server appeared under the new Sema4.ai name. Today the robocorp.com domain redirects to sema4.ai.

Date	Event
01/2024	Acquisition by Sema4.ai
02/2024	RF deprecated on the Robocorp platform
Q1 2024	Rebrand: VS Code Extension → Sema4.ai
06/2024	Additional USD 25M funding (Snowflake Ventures and others)
2025	robocorp.com redirects to sema4.ai

Robocorp had been the main sponsor of the RF Foundation since 2020 and the largest commercial actor in the RF ecosystem. The departure affected not just financial backing but also central tooling infrastructure.

Robocorp’s reasoning in detail

The deprecation page gave four arguments for moving to plain Python.

Python’s ecosystem. Python’s package ecosystem allegedly outperforms RF’s in breadth and development speed. Every Python library is reachable directly, without going through an RF keyword library.

LLM compatibility. LLMs such as ChatGPT understand Python better than RF syntax — speeding up AI-assisted automation development.

The abstraction layer falls away. RF is described as an «unnecessary wrapper» on top of Python. The extra abstraction layer creates overhead with no concrete benefit.

Developer availability. Python developers outnumber RF specialists by orders of magnitude. For organisations, that makes scaling automation teams easier.

CEO Antti Karjalainen positioned Python as the language of choice for AI agent development.

Where these arguments hold and where they don’t

In the context of Robocorp’s new business model, the arguments are coherent. Sema4.ai builds enterprise AI agents, not test automation. For AI agents, Python is the natural choice. The RF abstraction layer does indeed produce overhead there.

For test automation, the arguments carry less weight. The «unnecessary abstraction layer» is exactly what makes RF valuable as a test specification format: separating the domain-level test description from the technical implementation. Python’s LLM compatibility relates to code comprehension, not to domain semantics. And developer availability is irrelevant when business testers write the tests and only the keyword libraries require Python knowledge.

What Sema4.ai does today

The company focuses on enterprise AI agents for finance workflows, SAP automation, and knowledge work. Funding stands at USD 30.5M (Benchmark, Mayfield, Canvas Ventures) plus a further USD 25M in June 2024, including Snowflake Ventures.

The pivot was fundamental: away from RPA (Robotic Process Automation) and toward autonomous AI agents. In that business model, RF really is out of place. AI agents need maximum programmatic flexibility, not keyword-driven test description. The decision against RF was a decision for a different business field, not against a test framework.

Consequences for the RF ecosystem

Robot Framework Language Server

The biggest technical consequence concerns IDE tooling. Robocorp had built and maintained the RF Language Server for VS Code. It was frozen at the RF 6 level. RF 7 is unsupported (GitHub Issue #1051). New syntax constructs such as VAR, GROUP, or Secret Variables receive no IDE support in the Robocorp LSP.

The community has moved to RobotCode, an alternative by Daniel Biehl. RobotCode supports RF 7.x and is under active development. The switch was unproblematic for most teams but required a deliberate decision and migration.

Community reaction

Reactions in the community were mixed. On Hacker News, voices critical of RF questioned the abstraction layer in principle. A widely cited comment makes the point sharply: in the end it would have been simpler to write the tests directly in a programming language than to use an abstraction layer that served no purpose. In the RF forum, the response was largely pragmatic: focus on alternatives to the Robocorp tooling, support for RobotCode, confirmation of Foundation funding.

The criticism of the RF abstraction layer reflects a position seen mainly in pure developer teams without business testers. In those teams, developers write both production code and tests. An additional DSL on top of Python does produce overhead there, because everyone involved already knows Python. In teams where business testers or business analysts read and shape tests, the abstraction layer is the central benefit instead.

Effects on the toolchain

Beyond the Language Server, the departure touched other parts of the toolchain. The Robocorp Cloud platform for orchestrating RF-based RPA bots fell away. Robocorp’s Python packages (rpaframework, robocorp) moved into maintenance mode. Teams using Robocorp tooling in an RPA context had to switch to alternatives.

For teams using RF as a test automation framework (not as an RPA platform) the impact was limited. The core RF packages (robotframework, robotframework-seleniumlibrary, robotframework-requests and so on) are maintained independently of Robocorp/Sema4.ai. RobotCode covers the language-server need as an IDE extension. Test execution runs on the RF engine, which is funded by the Foundation and developed by Pekka Klärck.

The RF Foundation after Robocorp

The Robot Framework Foundation has not just survived losing its main sponsor — it has consolidated. More than 60 member organisations carry the funding, among them KONE, Cisco, Finnair, Deutsche Post, DB Schenker, Capgemini, and Eficode. The Slack workspace has over 33,000 members. The RFCP certification (Robot Framework Certified Professional) provides a formal qualification track. Annual RoboCon conferences took place in 2024, 2025, and 2026 in Helsinki.

Pekka Klärck remains the central figure as Foundation-funded lead developer. Executive Director Miikka Solmela put it this way in July 2025: the Foundation has grown and proved itself as a model of sustainable open-source funding without selling the core.

The broad membership base is an advantage compared to the earlier setup with one dominant sponsor. No single company can destabilise the ecosystem by leaving. Funding is spread across membership fees, RoboCon conference sponsoring, and training licences for the RFCP certification.

RoboCon 2026 reflects the focus: the Ecosystem track centres on IBM MQ, DatabaseLibrary updates, and performance testing. Backend scenarios that have been largely invisible in public community discussion now move to the foreground. A dedicated track addresses integrating AI into RF-based test automation, including AI-assisted SAP automation at a major German bank (Accenture talk).

RF roadmap: version 7.x and the road to 8.0

Robot Framework is in a productive phase. Since January 2024 six feature releases have shipped (7.0 through 7.4.2), roughly one release every six months.

New features in the 7.x line

The most important additions include native VAR syntax (7.0), a reworked listener interface (7.0), JSON as an output format (7.0/7.2), GROUP syntax for grouping keywords (7.2), variable type conversion (7.3), Secret Variables (7.4), and official Python 3.14 compatibility (7.3). Python 3.6 and 3.7 were dropped with RF 7.0.

Status of Set Variable and VAR

Set Variable, Set Suite Variable, Set Test Variable, and Set Global Variable are «soft deprecated». The BuiltIn library source code points to VAR syntax as the recommended alternative. The Robocop linter warns under rule DEPR05. No formal removal has been announced. All four keywords work unchanged in RF 7.4.2.

For teams using RF as a pure test specification format, Set Variable remains a valid option. Switching to VAR has benefits (performance, type conversion, more consistent syntax), but it is not enforced.

RF 8.0

For the next major release the following are confirmed: removal of the [Return] setting (replaced by the RETURN statement since RF 7.0), removal of Force Tags/Default Tags, JSON output during test execution, and changes to the Any type behaviour. There is no fixed release date. The Foundation has shifted RF 8.0 in favour of further 7.x feature releases.

The shift signals a deliberate priority: stability and incremental improvement before large breaking changes. For enterprise teams that depend on long-term API stability, that is a positive signal. The 7.x line delivers functionality without breaking existing test suites.

Framing for enterprise decision-makers

The question raised in steering committees: if the main sponsor leaves, is the framework still future-proof?

Three factors suggest the Robocorp departure does not endanger the RF ecosystem.

The Foundation is diversified: over 60 members from seven countries. No single dependency anymore. KONE, Cisco, Deutsche Post, Capgemini, and dozens of others carry development. Funding is on a broader base than before Robocorp’s departure.

Development is active. Six releases in two years. Python 3.14 support. JSON output. Secret Variables. Pekka Klärck works full time on RF, funded by the Foundation. That is not maintenance mode, but active development.

The reason for the departure concerns a different business field. Robocorp/Sema4.ai builds AI agents, not test automation. The decision against RF was a decision for a product where a test framework has no place. Anyone using RF as a test framework is unaffected by that pivot.

The actual lesson

Robocorp’s criticism of the «unnecessary abstraction layer» contains a kernel that should be taken seriously. Anyone misusing RF as a programming language (with IF/ELSE, loops, and inline Python at the test-case level) really does create an unnecessary abstraction over Python. In that case, plain Python is the better choice. That was essentially Robocorp’s experience in the RPA context: the RF syntax stood between the automators and the task.

Anyone using RF consistently as a test specification format, with keywords and variables at the test-case level and all logic in Python libraries, taps the one benefit no pure Python framework offers: domain-readable tests that testers, product owners, and developers all understand.

The question is therefore not «Robot Framework or Python». The question is: how is RF used? As a programming language it loses to Python. As a test specification format it beats Python. Robocorp’s departure confirms the first half of that statement. The second half is confirmed by enterprise teams that have used RF for over a decade for exactly that purpose.

Risk profile for ongoing projects

For teams already using RF, the risk profile looks like this:

Low risk: RF as a test automation framework with Python keywords. The Foundation funds development, Pekka Klärck works full time, the release cadence sits at two to three releases per year. Python compatibility is actively maintained (3.14 support in RF 7.3).

Medium risk: RF with Robocorp-specific tooling (Robocorp Lab, Robocorp Cloud, rpaframework). These tools are no longer actively developed. Migration to community alternatives (RobotCode, custom CI/CD integration) is required.

High risk: RF as a programming language without a Python foundation in complex scenarios. Exactly the scenario Robocorp identified as problematic. Here it is worth asking whether an architectural cleanup (Python libraries for logic, RF only at the test-case level) or a switch to plain Python is the better investment.

The difference is not in the framework. It is in the architecture.

Sources

Reviewing RF in an ongoing project after Robocorp’s departure? In the UTAA workshop we assess architecture, tooling, and migration paths specifically for your project. More on the method or get in touch directly.