OpenHands is one of the best things to happen to coding agents. Its own repository calls it "the self-hosted developer control center for coding agents and automations," and it earns the description: it runs the built-in OpenHands agent plus Claude Code, Codex, Gemini, or any agent that speaks the Agent-Client Protocol, across a laptop, Docker, a VM, or your cloud (OpenHands on GitHub, checked October 2026). If your problem is agents that read and change code in your repositories, it is a strong pick and it is MIT-licensed.
But a lot of teams hit the same wall a few months in. The coding work is handled. Everything around it is not.
The wall: the work that never made it into the repo
OpenHands is built around code. Its agents read repositories, run terminals and tests, and open pull requests. That focus is the point, and it also draws the boundary.
- The job is software. A developer control center knows repositories, terminals and tests. It does not run an outbound campaign, close the books, or clear a support queue.
- Memory is per conversation. Conversations and workspace files persist, but no single repository holds the company's agents, skills, memory and connector rules as versioned files a team reads, greps and diffs.
- Execution starts on a host. The documented quickstart runs the agent server directly on your machine and warns that it then has full access to your filesystem. Docker and VM backends isolate it, and that is still a developer's shape, not one isolated machine per run across an organization.
- The tool surface is developer-shaped. Integrations centre on Slack, GitHub, Linear, Notion and webhooks rather than the thousands of business apps a company-wide workforce touches.
- Review lands on code. OpenHands opens pull requests on engineering changes. It does not put agent work from every department behind one reviewed gate.
None of that is a knock on OpenHands. It is the shape of a coding harness, and a coding team should use one. The trouble starts when the same team wants the other jobs automated too, because those jobs live outside the repo, use different credentials, and end up owned by nobody.
What to look for instead
If the work you want to automate is broader than code, the checklist changes:
- One place the configuration lives. Agents, skills, memory and connector rules should be files you own and can diff, not settings in someone else's database.
- An isolated machine per run. A coding agent on your laptop is fine. A company workflow needs each run in its own sandbox, so a bad run cannot reach the next one.
- Any model, with your own keys. Model choice should be per agent or per task, switchable the day a better model lands.
- The business tools, not only dev tools. The agents need the CRM, the help desk, the billing system and the docs, reached with per-tool permissions.
- A review gate that covers everything. Work from every department should land as a change a person reads before it takes effect, not only as a pull request on code.
Kortix, the open-source AI Operating System
Kortix is open source. It is the open-source AI Operating System: your agents, their skills, your company memory, and every connector live in one git repo you own, and every session runs on its own isolated cloud computer. It is the leading open-source alternative to Claude Cowork and ChatGPT Work.
How it maps onto the checklist:
-
One repo is the company. Agents and skills are Markdown, memory is files, and connectors and triggers are config in
kortix.yaml. Grep the whole company, diff any change, roll any part back. - One isolated machine per session. Thousands run in parallel on the same config with no crossover, each on a branch named after the session.
- Any model, your keys. Pick a model per agent, per session or per message from any provider, or bring your own OpenAI-compatible endpoint.
- 3,000+ apps, plus MCP, OpenAPI, GraphQL and raw HTTP. Connector credentials are brokered server-side, and each tool call can be set to allow, ask or block.
- One gate to land work. The agent commits to its session branch and opens a change request a person reads as a diff before it reaches the main branch.
| Kortix | OpenHands | |
|---|---|---|
| Open source | Yes | Yes, MIT core |
| Built for | A company-wide agent workforce | Coding agents and developer automations |
| Where configuration lives | Files in a git repo you own | Agent Canvas settings and per-conversation state |
| Where agents run | One isolated cloud computer per session | Your machine, Docker, or a VM |
| Tool surface | 3,000+ apps, MCP, OpenAPI, GraphQL, HTTP | Slack, GitHub, Linear, Notion, webhooks |
| How work lands | A change request a person approves | Pull requests on code |
You do not have to give up OpenHands to use Kortix. A coding team keeps its harness for repositories and moves the jobs that leave the repo onto a platform built for them. The full side-by-side is in Kortix vs OpenHands, and the product docs start at kortix.com/docs. Kortix is free to self-host; the source is at Kortix on GitHub.
If your work is only code, use OpenHands. If the work is the whole company, the repo has to hold the whole company.
Top comments (0)