# robocorp is the set of Python libraries that Robocorp automations are built from

> The robocorp repository holds the essential Python libraries of the Robocorp Automation Stack, with task entry points, execution logging, work items, secrets, asset storage, browser and Windows automation and Excel support, all under Apache-2.0. It is a libraries repository rather than the platform, and it now ships a skill that teaches coding agents to build Robocorp task packages themselves.

**robocorp/robocorp** — Create 🐍 Python AI Actions and 🤖 Automations, and deploy & operate them anywhere

- Repository: https://github.com/robocorp/robocorp
- Website: https://robocorp.com/
- Stars: 652 · Forks: 107
- Language: Python
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/robocorp-robocorp

## A libraries repository, not the platform

The robocorp repository contains the essential parts of the Robocorp Automation Stack for Python. That first sentence settles the most common confusion about the project, so it is worth reading carefully.

Not everything is here. AI Actions, Data Actions and Action Server live in separate Sema4 Ai PyPI packages, sema4ai-actions, sema4ai-data and sema4ai-action-server. What is in this repository are the Python libraries with which the Automation Tasks are created, plus the framework libraries for configuring a package's entry points and controlling features such as logging.

The audience is a Python developer building an automation that runs in the Robocorp Control Room, or who wants the libraries and nothing else. The project documentation points at robocorp.com/docs/python for the documentation website, and states that the source code and the library API documentation are in the repository itself.

Alongside the libraries there is a substantial selection of libraries for the most common automation tasks, and the documentation is direct about the rest: anything else can be easily done through what is already available in the Python ecosystem. That is a sensible design for a framework that sits on top of a language rather than trying to replace its package ecosystem.

The licence is Apache-2.0, the primary language is Python, the default branch is master, and the last push was on 2026-10-18.

## The metapackage decides what you actually install

The easiest way to get started is to install the robocorp meta-package, which includes the framework's core features such as defining Tasks, logging, Work Items, Vault, Assets and other Control Room integrations.

The individual components can also be installed as separate dependencies, and the table of packages is where the practical detail sits. robocorp.tasks creates entry points for your automation project, robocorp.log configures and controls the execution log, robocorp.workitems interacts with Control Room work items to read data from previous steps and create output data, robocorp.vault stores secret values in Control Room and accesses them during execution, and robocorp.storage stores assets in Control Room and manages them during execution.

Three packages are not in the metapackage. robocorp.browser automates actions in a browser, powered by Playwright. robocorp.windows automates Windows desktop applications, powered by uiautomation. And robocorp.excel reads and writes Excel files directly, with support for both .xlsx and .xls. sema4ai-actions is the fourth entry with no metapackage mark.

The documentation is explicit about the consequence. Any library that is not included by default in robocorp should be added as a dependency if you want it available in your Python environment, by listing it in the dependencies configuration file for your project type: conda.yaml for automation Task Packages, package.yaml for automation Action Packages, and requirements.txt, pyproject.toml or setup.py for the rest.

That is the detail most people get wrong. Installing the metapackage does not give you browser automation, and the warning is in the documentation for a reason.

## Three packages are only useful with a Control Room

The separation between the libraries and the platform is clearest in the three packages that talk to Control Room.

robocorp.vault is the secret store. Secret values are held in Control Room and read during execution, so the library is a client for a hosted vault rather than a local secrets file. robocorp.storage works the same way for assets, which are the files a task needs at runtime, stored in Control Room and managed during execution. robocorp.workitems is the queue and state layer, letting a task read data from previous steps and create output data.

That design is what makes the framework good inside Control Room, because a long-running automation needs somewhere to keep state between runs and somewhere to keep credentials that are not in the repository. It is also what makes three of the libraries less attractive outside it.

The other four core packages are more portable. robocorp.tasks and robocorp.log are about the shape of an automation and about what it prints, and neither needs a server. The browser and Windows packages are automation surfaces and stand on their own.

So the sensible way to evaluate this repository is to separate the portable half from the Control Room half, and to notice that the metapackage mixes them. Installing robocorp pulls in vault, storage and workitems even for a team that will never run a task in Control Room, which is a reasonable trade for a team that will, and a heavier one for a team that will not.

## The agent skill that teaches a model to build task packages

The most recent addition to the repository is aimed at coding agents rather than humans, and it changes how you would start a new automation.

If you are building automations with Claude Code, Codex, Cursor or another coding agent, the repository offers a robocorp-automation skill, and the README describes exactly what it does: it teaches the agent how to bootstrap, build, run and validate Robocorp task packages with robocorp.tasks and rcc.

For Claude Code it is installed as a plugin from the repository:

```
/plugin marketplace add robocorp/robocorp
/plugin install robocorp-automation@robocorp
```

For other agents the skill is copied into the automation project, and the README gives the commands to fetch the skill file and its API reference:

```sh
base=https://raw.githubusercontent.com/robocorp/robocorp/master/skills/robocorp-automation
mkdir -p .agents/skills/robocorp-automation/references
curl -fsSL "$base/SKILL.md" -o .agents/skills/robocorp-automation/SKILL.md
curl -fsSL "$base/references/api.md" -o .agents/skills/robocorp-automation/references/api.md
```

The reference file matters as much as the skill. A model that knows how to lay out a task package but not the API of robocorp.tasks will produce plausible code that does not run, and the api.md reference is the part that grounds it.

The repository also carries a .claude-plugin/ directory at the root, which is what the marketplace install points at, and the skills/ directory holds the skill and its references.

## Versions before 1.0 mean breaking changes on any release

The versioning policy is stated clearly and it is the thing to read before you pin anything.

The project follows SemVer to the best of its ability. That means libraries with a version of 0.x.x are in the development phase, so there can be breaking changes on any version update. The stated aim is to get libraries to version 1 as soon as possible, and after that to follow the expected SemVer rules, with a new major version published when breaking changes are introduced and guidance on migration in the changelog.

The practical consequence for an adopter is that a range like 0.4.1 in a requirements file is not a stable range in the SemVer sense, it is a moving target. Two ways of handling that are visible in the packaging itself. The automation packages are pinned through conda.yaml, where a lock file can hold exact versions, and the Action Packages use package.yaml. For everything else, the requirement is a normal Python dependency file.

The framework also has a central command line, rcc, which the skill description names alongside robocorp.tasks as the tools for building and running task packages. The Makefile-style tooling around it is in the repository too, with a tasks.py file at the root and directories for devutils and integration_tests, which is where the cross-package checks live.

The result is a framework that is still pre-1.0 in places, and a project that is candid about it rather than pretending the numbering is settled.

## A monorepo of libraries with one shared test layer

The repository layout is a directory per library, which is how a monorepo of Python packages is usually arranged when the packages are released independently.

There is a directory for each package: tasks/, log/, workitems/, vault/, storage/, browser/, windows/ and excel/, plus http/ and a log_pytest/ directory, the meta/ directory that holds the metapackage, and docs/. The skill lives in skills/, and the root has tasks.py, the CONTRIBUTING.md and the Apache-2.0 LICENSE.

Two directories are worth a second look. integration_tests/ is the sign that the packages are tested together rather than only in isolation, which is the right call for a framework whose pieces are meant to work as a set. devutils/ is the development tooling, kept separate from the shipped code.

The docs/ directory holds the guides, and the README points at them for the details of working with rcc, so the repository is both the source and the manual.

The split of responsibilities across the wider organisation also shows in the release history. The most recent tags listed for this repository are robocorp-action_server releases, 0.4.1 from 2024-04-17, 0.4.0 from 2024-04-16 and 0.3.2 from 2024-04-12, which is where the action server work was published from at the time, while the libraries themselves are released to PyPI under their own names and version lines.

## What this stack is for, and when it is the wrong answer

Robocorp is at its best when the work is not a one-off script. An automation that runs on a schedule, consumes a queue of work items, holds a credential from a vault, stores output files and produces a readable execution log is exactly the shape the framework is built for, and doing that with plain Python means rebuilding all of it.

The wrong case is the small script. If the task is to open a browser and fill in a form, robocorp.browser on its own is a Playwright wrapper, and the framework around it is overhead. If the task is to read a spreadsheet, robocorp.excel is the useful part and the rest is unused weight.

The middle case is a team deciding where the platform boundary is. The alternative to the full stack is to use the libraries standalone with your own secrets handling, your own scheduling and your own state, which is entirely possible since the four portable packages do not require Control Room. What you give up is work items, the vault and asset storage, and the Control Room integrations that the metapackage includes by default.

There is also a licensing point to note. Apache-2.0 is permissive and carries no copyleft obligation for your own code, which is a genuine advantage for a commercial team that does not want its automations constrained by the tooling it runs on.

## Conclusion

robocorp suits a Python team that wants Robocorp's task model, logging and Control Room integration without adopting the whole platform, and it is the wrong choice for a project that only needs a Playwright script, since the browser and Windows packages are not part of the metapackage and would be extra dependencies for no benefit. Before adopting it, check the version policy for the library you need, because anything still at 0.x can introduce breaking changes on any update, and read the notes on which dependencies you must declare yourself.

## FAQ

### What is in the robocorp repository?

It holds the essential parts of the Robocorp Automation Stack for Python, namely the libraries used to create Automation Tasks, with entry point configuration and logging control. AI Actions, Data Actions and Action Server live separately in the Sema4 Ai PyPI packages.

### What does the robocorp metapackage include?

The core features such as defining Tasks, logging, Work Items, Vault, Assets and other Control Room integrations. Libraries that are not part of the metapackage, such as robocorp.browser, robocorp.windows and robocorp.excel, must be added to your own dependencies configuration.

### How do I use robocorp with a coding agent?

For Claude Code, add the repository as a plugin marketplace and install the robocorp-automation plugin. For other agents, copy the skill into the project, fetching SKILL.md and the references/api.md file, so the agent can bootstrap, build, run and validate task packages with robocorp.tasks and rcc.

### Are robocorp libraries stable?

The project follows SemVer to the best of its ability, and states that libraries at version 0.x.x are in the development phase so there can be breaking changes on any version update. The aim is to reach version 1 and then follow the usual SemVer rules.

### Do the robocorp libraries work outside Robocorp Control Room?

Partly. robocorp.tasks and robocorp.log stand on their own, and the browser, Windows and Excel packages are automation surfaces that do not need the platform, while robocorp.vault, robocorp.storage and robocorp.workitems interact with Control Room and assume it is present.

## Sources

- [License: Apache-2.0](https://github.com/robocorp/robocorp/blob/master/LICENSE)
- [Project website](https://robocorp.com/)
- [README](https://github.com/robocorp/robocorp/blob/master/README.md)
- [Releases](https://github.com/robocorp/robocorp/releases)
- [robocorp/robocorp on GitHub](https://github.com/robocorp/robocorp)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/robocorp-robocorp