PantheonOS: a multi-agent harness for single cell and spatial transcriptomics

The problem PantheonOS picks, and who it is built for

Most LLM agent frameworks are general purpose. They give you a planner, a tool loop and a memory store, then leave the domain to you. PantheonOS takes the opposite position: it is a general framework that ships with a domain. The README states the goal as reconciling generality with domain specificity, and names end-to-end single cell biology analyses as the focus. The topic list on the repository confirms the direction: singlecell, spatial-transcriptomics, bioinformatics, biology.

The audience follows from that. A computational biologist who already runs Tangram, or a batch-correction pipeline, and wants an agent to drive it, is the intended user. The examples directory backs this up with folders such as evolution_batch_correction, evolution_gene_panel, evolution_topact and single_cell_spatial_analysis. There is also a paper_reporter example, which suggests literature work is in scope, not just numeric pipelines.

What the framework does not try to be is a general chat product. The pitch is that agents can improve algorithms, not just call them, and that claim is what separates PantheonOS from a wrapper around a shell.

Pantheon-Evolve and the genetic-algorithm loop

The distinguishing module is Pantheon-Evolve. The README describes it as enabling agents to improve algorithms and code through genetic-algorithm-driven agentic code evolution, and claims super-human performance on specialized scientific tasks. Treat that claim as the project's own, not as a measured result: the README does not publish the benchmark protocol behind it.

The mechanism, as far as the repository shows, is a loop over candidate code. The examples directory contains evolution_circle_packing and evolution_erdos_min_overlap alongside the biology cases. Those two are classic optimization puzzles, and their presence is informative: the module is not tied to biology, it is tied to problems where a score can be computed automatically. That is the real precondition. Genetic-algorithm-driven code evolution needs a fitness function, and a fitness function needs a task where correctness or quality is machine-checkable. Circle packing and Erdős minimum overlap qualify. A novel hypothesis with no ground truth does not.

So the honest reading is that Pantheon-Evolve is a search procedure over generated code, scored by an evaluator you supply. Where you cannot write that evaluator, the module has nothing to optimize against.

Team patterns, the CLI and the chatroom UI

Orchestration is handled by what the README calls PantheonTeam, with named patterns: Sequential, Swarm, Mixture-of-Agents (MoA) and AgentAsTool. The names describe topology rather than behaviour. Sequential is a chain; Swarm implies handoff between peers; Mixture-of-Agents implies several agents answering and a combiner; AgentAsTool means an agent is exposed to another agent as a callable. The README does not document the internals of any of these, so if you need to know how a Swarm decides to hand off, the answer is not in the README.

Two interfaces are documented. The interactive CLI starts with pantheon cli. The chatroom UI starts with pantheon ui --auto-start-nats --auto-ui, which tells you something structural: the UI expects a NATS server, and the flag auto-starts one rather than requiring you to run it separately. The repository root contains nats-ws.conf, consistent with a WebSocket-facing NATS configuration.

Distributed operation is the other half of the design. The README describes NATS-based messaging for scalable, fault-tolerant deployments across machines, and points to Pantheon-Fleet for letting agents control a distributed network of machines. Fleet is the newest piece and the least settled: its release is tagged fleet-v0.2.0-alpha.

Installing PantheonOS and running a first session

Before any install, read the security note at the top of the README. It states that the June 2026 "Hades" incident is resolved, that trojanized pantheon-agents 0.6.1 and 0.6.2 releases were removed from PyPI and the account restored, and that anyone who installed those two versions should uninstall and rotate credentials present on that machine. That is a project-specific instruction, not boilerplate.

The README recommends uv. The commands below clone the repository and sync the environment, which is the path that also gives you the vendored directories:

git clone https://github.com/aristoteleo/PantheonOS.git
cd PantheonOS
uv sync

Optional extras are named in the README. knowledge adds RAG and vector search support, claw adds PantheonClaw mobile gateway channels, and r adds R language support, which the README notes requires R to be installed already:

uv sync --extra knowledge
uv sync --extra claw
uv sync --extra r

If you prefer the published package, the README gives pip as the alternative, with the same extras syntax:

pip install pantheon-agents
pip install "pantheon-agents[knowledge]"

Once installed, the fastest entry point is the interactive REPL:

pantheon cli

For the multi-agent chatroom, the README gives a single command that starts NATS and the UI together. After startup you should see a connection URL to open in a browser:

pantheon ui --auto-start-nats --auto-ui

There is also a container path. The README documents pulling nanguage/pantheon-agents:latest and running it in standalone mode with PANTHEON_MODE=standalone, a mounted workspace at /workspace and port 8080. It notes that the image reads factory templates from inside the running image, so startup does not copy templates into /workspace or the container home, while user-created overrides persist under /workspace/.pantheon/.

Vendored dependencies and what the Hades incident changed

The most consequential detail in pyproject.toml is not a feature. It is a comment explaining that executor-engine, funcdesc and cmd2func are vendored in-tree at the repository root instead of being pulled from PyPI, because their PyPI releases were removed after the maintainer's account was compromised in the June 2026 supply-chain attack. The comment states the GitHub sources are clean.

The practical effect is that four runtime requirements, loky, fastavro, tokenizers and pyyaml, are listed explicitly in pyproject.toml. The reason given is precise: vendoring bypasses those packages' own dependency resolution, so their requirements have to be declared by hand. That is a real maintenance burden. When any of those four packages changes its own dependencies upstream, PantheonOS will not pick the change up automatically.

A second wrinkle: the repository's LICENSE file and the GitHub metadata say BSD-2-Clause, while pyproject.toml declares MIT in both the license field and the classifier. That is an inconsistency in the project's own files, and anyone embedding PantheonOS in a commercial product should resolve it with the maintainers rather than assume either one. This is not legal advice; it is a discrepancy worth raising before you depend on it.

Where PantheonOS is the wrong tool

The clearest limitation is that the README does not document the API. It says so directly: detailed API usage, including creating agents, using toolsets and building teams, lives in the external documentation site, not in the README. If you are evaluating PantheonOS from the repository alone, you will not find the constructor signatures, the tool registration interface or the team configuration schema.

Second, the package is classified as Development Status :: 4 - Beta in pyproject.toml. Combined with an alpha-tagged Fleet release, that means interfaces can move. Building a production pipeline that imports internal modules is a bet against that.

Third, the evolution module needs a scorer. If your analysis has no automatic quality metric, Pantheon-Evolve has nothing to select on, and you are left with the orchestration layer only.

Fourth, the security history is recent and specific. The README's own remediation advice, uninstall and rotate credentials, is the kind of instruction that should make a team pin versions and check provenance rather than track latest. PantheonOS is a poor fit for an environment where you cannot inspect what you install.

How PantheonOS differs from Biomni

Biomni is the natural comparison, and it appears in the related searches for this project, which suggests people are already weighing the two. The difference is architectural rather than a feature checklist.

Biomni is positioned as a biomedical agent that operates over a curated set of tools and databases. The value is the toolset: you get a prepared environment and the agent's job is to select and sequence the right instrument. PantheonOS inverts the emphasis. Its headline module, Pantheon-Evolve, generates and mutates code rather than selecting from a fixed catalogue, and its distributed layer, NATS plus Pantheon-Fleet, is about running agent teams across machines rather than about the breadth of the toolset.

That produces a concrete trade-off. If your task is a standard analysis that an existing tool already performs well, a curated-toolset agent is the shorter path, because it does not ask you to define a fitness function. If your task is one where the existing algorithm is the bottleneck and you can score candidates automatically, code evolution is the more interesting lever. The two designs are not substitutes for the same job.

Maintenance, upgrade cost and licence

The repository is not archived, and the last push was on 2026-09-10, which is recent. Releases are frequent: fleet-v0.2.0-alpha on 2026-08-31, desktop-v0.3.8 and desktop-latest on 2026-08-25. The version tags themselves are the warning. An alpha on the distributed fleet component and a Beta classifier on the Python package mean upgrades should be pinned, not floated.

The upgrade cost concentrates in the vendored directories. Because executor, funcdesc and cmd2func live in-tree, updating them is a repository change, not a version bump, and the four manually declared dependencies have to be kept in step by hand. Anyone forking PantheonOS inherits that responsibility.

On licensing, the repository metadata and LICENSE file say BSD-2-Clause while pyproject.toml declares MIT. Both are permissive, but they are not identical in their patent and attribution terms. Resolve which one governs before you redistribute, and note that the Pantheon Store marketplace content is a separate question the README does not address.

Editorial conclusion

Adopt PantheonOS if your work is single cell or spatial transcriptomics and you want agent teams that can rewrite their own analysis code rather than call a fixed toolchain. Do not adopt it if you need a stable, documented API surface today: the README points to external docs for API usage, the PyPI package is in Beta, and the project is still shipping alpha releases such as fleet-v0.2.0-alpha. Before installing anything, confirm the version you are pulling is not 0.6.1 or 0.6.2, and read the vendored executor, funcdesc and cmd2func directories at the repository root, because dependency resolution no longer covers them.

Frequently asked questions

Official sources

1. aristoteleo/PantheonOS on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases