# Agentlas OS: a local-first hub for specialist agents with a temporary orchestrator per task

> Agentlas OS keeps reusable specialist agents in a hub and spins up a throwaway orchestrator for each task, running through the LLM hosts you already have. The repository is Apache-2.0, Python-based, and its last push was on 2026-09-06.

**agentlas-ai/Agentlas-OS** — Agent OS: keep specialist agents in a hub, spin up a temporary orchestrator per task. Local-first, works with any model.

- Repository: https://github.com/agentlas-ai/Agentlas-OS
- Website: https://agentlas.cloud
- Stars: 1,541 · Forks: 109
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/agentlas-ai-agentlas-os

## The problem Agentlas OS addresses: agents that stay tied to one model workspace

Most agent tooling assumes a single runtime. You build an agent inside one vendor's environment, and it lives there. The Agentlas README states the premise plainly: "An agent you create is not tied to one model workspace or computer." The project's tagline is "Build it or borrow it. The agents you create stay yours."

That framing points at two distinct pains. The first is portability. An agent that only exists inside one host has to be rebuilt when you change tools or machines. The second is staffing. A single general-purpose assistant is a poor fit for work that needs a narrow specialist, and building a permanent multi-agent org chart for a one-off task is overkill.

The intended audience is people already working inside an LLM host: Claude Code, Codex, Gemini CLI, Antigravity, Cursor, DeepSeek, GLM or Ollama, all of which appear in the README's LLM badge. Agentlas OS is not a hosted service you sign up for. It is a set of files installed on your machine, plus a command surface that appears inside the host you already use.

## How the hub-and-temporary-orchestrator design works

The repository description gives the architecture in one line: "keep specialist agents in a hub, spin up a temporary orchestrator per task." The README expands on the build path: you describe work in plain language, and Agentlas "classifies the request, runs the interview and research gate, generates the package, verifies it, then asks whether to keep it only on this computer or save it privately in Agent Cloud for restore on another signed-in Desktop."

That is a pipeline with named stages, and the ordering matters. Classification comes before the interview, and verification comes after generation, so a package is checked before you are asked where to store it. The storage choice is the interesting part: local-only, or private Agent Cloud. The second option is what makes an agent retrievable on another machine, and the README is explicit that retrieval requires installing Agentlas OS on a supported host and signing in.

The repository layout backs the hub idea. There is a top-level agents/ directory, a system-agents/ directory, and a skills/ directory, alongside per-host directories for claude/, codex/, gemini/, cursor/, antigravity/, copilot-cli/, goose/, grok/, kimi/, opencode/ and zcode/. Those per-host directories are how one agent definition reaches several command surfaces. There is also an ontology/ directory and an examples/ontology-corpus/ example, which suggests the classification step is driven by a stored ontology rather than a hardcoded list of categories. The README does not document the ontology format, so treat that as a design signal rather than a documented extension point.

## Installing Agentlas OS and running your first build

The README offers two install paths: a paste-to-install prompt for when you are already inside an LLM, and a direct shell command for when you are not. Both run the same script, scripts/install-all-runtimes.sh, which downloads a release tarball from the repository's GitHub Releases.

The README states the script writes files only under ~/.agentlas, ~/.local/bin, and the host's own plugin or command-adapter directories (for example ~/.claude for Claude Code). The direct command is a single line:

```bash
curl -fsSL https://raw.githubusercontent.com/agentlas-ai/Agentlas-OS/main/scripts/install-all-runtimes.sh | HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1 bash
```

The HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1 prefix is optional. The README says it additionally writes a routing block into the host's global instructions file, such as ~/.claude/CLAUDE.md, that lets substantial tasks be staffed from the agent network. Drop the variable to skip that for now; the README says you can add it later with the command below.

```bash
hephaestus global install
```

On macOS, the README notes that a fresh machine may prompt to install Command Line Tools the first time curl or git runs, in which case you click Install, wait, and run the command again. On Windows the instructions assume Git Bash, installed from git-scm.com/download/win if it is not already present.

After the installer finishes, the README says to close and reopen your AI tool so it picks up the new commands. The first real use is then a build request inside the host. The README refers to this as /agentlas build, or "this host's equivalent command surface," which is worth noting: the command name is host-dependent, and the README does not enumerate the equivalent for every host it lists.

## What the installer does not tell you

The install path is a curl pipe into bash, and the README knows this is uncomfortable. It addresses the objection directly by telling the LLM to fetch and read the script first, and by telling terminal users that reading the script before running it is "recommended if you're security-conscious." That is a candid framing, but it is still a pipe-to-shell install with no checksum shown in the README and no signature verification step described there.

The bigger gap is rollback. The README does not document an uninstall command, and it does not document how to remove the routing block that HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1 adds to your global instructions file. Since that block lives inside a file you own and edit, such as ~/.claude/CLAUDE.md, removing it is a manual edit rather than a command. Plan for that before you opt in.

There is also a versioning question. The installer pulls a release tarball from GitHub Releases, and the repository shows rapid iteration: v1.2.42, v1.2.43 and v1.2.44 all landed between 2026-09-05 and 2026-09-06. Frequent patch releases at that cadence usually mean the install surface is still moving. The README does not describe a pinning mechanism for the tarball, so a re-run of the same command at a later date will not necessarily produce the same files.

## When Agentlas OS is the wrong tool

If you want a Python library to import into a service, this is not it. The primary language is Python and the repository carries contracts/, schemas/ and package-contract.json, but the README's documented entry points are an installer script and a host command surface. There is no documented import path, no pip package name, and no API reference in the README. Building a backend on top of this means reading the source.

It is also a poor fit if you need a fully offline, zero-account setup. The local-only storage option exists, and the README says an agent can be kept "only on this computer." But the portability story, retrieving an agent from Cloud on another signed-in Desktop, depends on signing in. If your constraint is that nothing leaves the machine and no account is created, you are using a subset of the product and paying the full install cost.

Finally, the host dependency is real. Agentlas OS activates inside Claude Code, Codex, Gemini CLI, Cursor and similar tools. If your team does not standardize on one of those hosts, the command surface has nowhere to appear. The README lists many supported hosts, but the per-host directories in the repository are separate implementations, and the README does not claim feature parity across them.

## Agentlas OS compared with framework-style multi-agent libraries

The obvious alternative is a code-first multi-agent framework, where you define agents, tools and handoffs in Python or TypeScript and run them yourself. The difference in approach is where the agent lives. In a framework, an agent is a class in your codebase, versioned with your application and executed by your process. In Agentlas OS, an agent is a package installed into a hub, addressed by a command surface inside an existing LLM host, and optionally stored in a private cloud so it can be restored elsewhere.

That flips the trade-off. Frameworks give you deterministic control, testability and a normal dependency story. Agentlas OS gives you reuse across hosts and machines without rewriting the agent for each runtime. If your agents are tightly coupled to your application's data layer, a framework is the better fit. If your agents are largely prompt-and-tool configurations that you want to carry between Claude Code and Cursor, the hub model removes work that a framework would not.

The second alternative is doing nothing and relying on each host's own agent or skill mechanism. That is genuinely viable for a handful of agents on one machine. Agentlas OS starts to pay off when the count grows, when several people need the same specialists, or when the machine changes. The README's own framing, "The agents you create stay yours," is a claim about ownership and portability, not about capability. Nothing in the README suggests the agents themselves do something a hand-written host configuration could not.

## Licence, maintenance and upgrade cost

Agentlas OS is licensed under Apache-2.0, and the repository carries a LICENSE file at the top level plus a license badge in the README. Apache-2.0 permits commercial use, modification and redistribution, and includes an express patent grant. It also requires that you retain the licence and notice files and state significant changes. If you redistribute a modified installer or a bundled agent package, those obligations follow the files. This is a description of the licence text, not legal advice; the LICENSE file in the repository is the authority.

On maintenance, the last push to the default branch was on 2026-09-06, and the most recent release, v1.2.44, was published the same day. The three most recent releases span roughly a day, which indicates an active release cadence rather than a settled one.

The upgrade cost is where the design bites. Because installation writes into host-owned directories such as ~/.claude and into ~/.local/bin, and because the global router option edits a host instruction file, an upgrade is not confined to one directory. Re-running the installer after a release will touch those same paths. The README does not describe an upgrade command, a migration path, or a way to diff what changed in the global instructions block between versions. Anyone running this on a shared or heavily customized host should read the installer script before each re-run, not only the first time.

## Conclusion

Adopt Agentlas OS if you already work inside Claude Code, Codex, Gemini CLI, Cursor or a similar host and want your specialist agents to survive a switch of model or machine. Avoid it if you need a stable, documented Python API to import into your own service: the README describes a paste-to-install flow and a host command surface, not a library interface. Before committing, read scripts/install-all-runtimes.sh in the repository and confirm exactly which paths it writes on your machine, then run the installer with HEPHAESTUS_INSTALL_GLOBAL_ROUTER unset so no routing block is added to your global instructions until you have read it.

## FAQ

### Can Agentlas OS be used with Claude Code?

Yes. The README lists Claude Code among the hosts the paste-to-install prompt is written for, and the installer writes into the host's plugin and command-adapter directories, naming ~/.claude for Claude Code. The global router option also writes a routing block into ~/.claude/CLAUDE.md.

### What is an agent operating system, in the way Agentlas OS uses the term?

In this project it means a hub of specialist agents plus a temporary orchestrator created per task, rather than a general-purpose assistant. The README describes building an agent by describing the work in plain language, after which Agentlas classifies the request, runs an interview and research gate, generates and verifies a package, and asks where to store it.

### What are some popular AI agent platforms?

This repository does not survey the field, so it cannot answer that. What it does document is its own position: Agentlas OS is local-first, works with any model, and runs through supported hosts such as Claude Code, Codex, Gemini CLI, Antigravity and Cursor.

## Sources

- [agentlas-ai/Agentlas-OS on GitHub](https://github.com/agentlas-ai/Agentlas-OS)
- [License: Apache-2.0](https://github.com/agentlas-ai/Agentlas-OS/blob/main/LICENSE)
- [Project website](https://agentlas.cloud)
- [README](https://github.com/agentlas-ai/Agentlas-OS/blob/main/README.md)
- [Releases](https://github.com/agentlas-ai/Agentlas-OS/releases)

---

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