Hurlicane: The Multi-Agent Operating System for Claude

The Ten-Contractor Problem

The standard vision for AI software engineering involves a single, highly capable agent working sequentially. You give it a prompt, it reads your files, and it writes code. But what happens when you want to build a feature ten times faster? You spawn ten agents.

That is where the illusion breaks. Traditional AI coding tools are not built for concurrency. If two agents attempt to edit the same router file simultaneously, the result is a massive Git conflict. The race condition becomes the primary antagonist of autonomous engineering.

Hurlicane approaches this problem by treating Anthropic's Claude Code CLI not as an end-user tool, but as raw compute. It wraps the CLI in a command-and-control dashboard that enforces traditional operating system primitives on the AI workforce.

A File System with a Conscience

To prevent agents from overwriting each other, Hurlicane implements a custom FileLockRegistry. Before an agent can modify a file, it must request permission from the orchestrator.

This is enforced at the shell level. A custom pre-tool-use hook (check-lock-hook.mjs) intercepts bash commands and file edits. If Agent A is currently rewriting src/main.ts, Agent B will receive a lock error and must wait. The system even detects deadlocks where two agents are waiting on each other, forcing a reset.

For operations that affect the entire directory tree (like a Git checkout), the system uses a higher-level directory lock. This fail-safe ensures that no agent can pull the rug out from under another process.

Surviving the Crash with PTY Persistence

Most agent frameworks use simple API calls. They hold state in memory and vanish if the server restarts. Hurlicane takes a heavier, more resilient approach.

It uses node-pty and tmux to spawn persistent pseudo-terminals for every agent. The agent runs inside a real interactive shell. This means a human developer can attach to the session, watch the agent type, interrupt it, or provide a password prompt, and the agent will gracefully continue.

If the orchestrator crashes, the agents do not die. They remain suspended in their tmux sessions, waiting for the dashboard to reconnect and resume streaming their output.

The Recursive Manager: Agents Spawning Agents

Hurlicane exposes its own orchestration capabilities to the models it manages via the Model Context Protocol (MCP). The most powerful of these tools is createJob.

A "Lead" agent can break a complex feature request into a Directed Acyclic Graph of sub-tasks. It can spawn a "Worker" agent to update the database schema, another to write the API routes, and a third to update the frontend components. The orchestrator handles the dependency chain, ensuring the frontend worker does not start until the API worker succeeds.

The Brownian Ratchet of Knowledge

Machine learning models are notoriously forgetful within a single context window. Once an agent finishes a task, its specific discoveries about your codebase (like a quirky build script or a required environment variable) are usually lost.

Hurlicane solves this with a MemoryTriager. When an agent completes a job, it reports its learnings. A secondary, high-speed model reviews these notes, deduplicates them using SQLite Full-Text Search, and commits them to a persistent Knowledge Base.

The next time an agent is spawned in that repository, it is injected with this consolidated knowledge. The system acts as a ratchet, ensuring the swarm never makes the same mistake twice.

By enforcing strict primitives around concurrency, persistence, and memory, Hurlicane transforms the chaotic nature of LLMs into a structured engineering pipeline. It is no longer just a chat interface. It is a true multi-agent operating system.

Explore the source code and documentation in the Hurlicane repository.