Aria

A multi-agent orchestrator for managing software projects through a hierarchy of specialized AI agents.

Aria gives a human operator a single control point for coordinating multiple software projects at once. A Director works across projects, Project Managers (PMs) coordinate individual repositories, and workers (coding agents) carry out implementation in controlled environments. Planning and coordination stay separate from code execution, and the operator decides what is kept and merged.

Hierarchy

Aria organizes agents into three tiers below the operator:

Operator → Director → Project Managers → Workers

• Director — operates across the whole workspace, tracking projects, priorities, and ongoing work.
• Project Managers — operate within a single project, breaking objectives into tasks and coordinating execution.
• Workers — coding agents that perform the implementation.

The arrows show how work is delegated, not who can talk to whom. The operator can talk directly to any agent, including a worker that is mid-task. Directors and PMs never modify source code directly. They plan, delegate, and communicate through tools that the harness exposes.

Inside the harness

The agents make decisions and write code. The harness underneath them controls the environment in which that work happens: task scheduling, inter-agent communication, process lifecycles, repository isolation, coding backends, concurrency, and recovery.

Message bus and scheduling

All communication runs over an always-on SQLite message bus that connects the Director, PMs, workers, Collab sessions, and the UI. Messages are persisted rather than living only inside an agent's context window, so communication can be asynchronous and reconstructed across agent turns. The bus also serves as Aria's episodic execution-state layer.

On top of the bus, a scheduler manages runnable work. It claims tasks, enforces the configured worker limit, starts the appropriate coding backend, tracks active sessions, and handles task completion or failure. This keeps the decision about what should run separate from the mechanics of running it: a PM decides what runs, and the harness handles processes, terminals, repositories, and concurrency.

Live, addressable sessions

A worker is not a single LLM request. It is a live coding-agent process tied to a task and a working directory. The harness owns that process's lifecycle and exposes a common session interface for sending input, observing output, interrupting work, and shutting the session down.

That makes running workers addressable. The operator, Director, or a PM can send a question or a new instruction to a specific worker without discarding its context and rebuilding the task in a fresh model call. Messages go to the worker's persistent inbox and, when appropriate, directly into its live session. The dashboard attaches to the same underlying session, so human and agent interaction reach the same worker rather than creating parallel copies of it.

Repository isolation and Git ownership

Parallel coding gets much harder once multiple agents can touch the same repository. Aria handles this at the harness level rather than through prompts alone.

Workers can run directly in a project or in isolated Git worktrees for parallel tasks. In isolated mode, worktree creation, commits, merges, conflict handling, and cleanup are all owned by Aria rather than the coding agent. Operations that affect shared repository state are serialized where necessary, so multiple repositories and tasks can progress concurrently without interfering with one another.

Aria owns Git; the agent owns the code it was assigned to change.

Isolated workers are also kept away from Git at the environment level. Their child environment removes Git from PATH, inserts stub git executables that refuse to run, and constrains GIT_EXEC_PATH. These are guardrails, not a security sandbox: they make Git use by the agent fail instead of relying only on instructions to the model. The server's own environment remains Git-capable.

Swappable coding backends

Workers are not tied to one model provider. Aria drives Claude Code, Codex, and Grok Build through a common orchestration layer, and the backend can be chosen per task. Each CLI is installed and authenticated independently.

Most sessions run as interactive terminal processes. Grok Build can also run over the Agent Client Protocol (ACP): Aria launches the CLI with binary pipes and communicates through newline-delimited JSON-RPC instead of a pseudo-terminal. The ACP adapter handles protocol initialization, session creation, prompt serialization, cancellation, stderr draining, and handshake failures. It allows only one prompt in flight at a time, so supervisor questions and Collab messages queue behind the active turn instead of racing it or being dropped.

An ACP session presents the same interface as a terminal session, so the rest of Aria submits to it, closes it, associates it with a task, and renders its output without special cases. The coding model can change without changing the scheduling, repository, communication, or supervision layers around it.

Collab mode

Collab mode turns a single task into a coordinated multi-agent session. Three live coding agents share one isolated worktree, with distinct roles such as implementation, testing, and review.

The harness starts all three together, opens a shared collaboration room, and runs a plan-first huddle before any code is written. In the room, agents can message each other directly and claim ownership of file paths. Path claims stay blocked until the reviewer accepts the plan; the only exception is when a reviewer is explicitly unavailable. A timeout is never treated as approval.

This is what separates Collab mode from simply launching several agents at once. The harness supplies synchronization, role boundaries, shared state, and a controlled point at which parallel planning turns into code changes.

Memory and recovery

Aria separates short-term execution state from long-term knowledge.

• Episodic execution state lives on the SQLite bus and is always on.
• Long-term memory is exposed through a pluggable MemoryProvider, which can be disabled or backed by Recallium or another compatible memory service.

Completed work can be distilled into reusable knowledge. Instead of forcing later workers to search a growing pile of raw task histories, Aria records task outcomes and periodically folds them into project-level decisions and rules, which new workers retrieve when starting related work.

Recovery does not depend on long-term memory. On shutdown, Aria writes local handoff records containing worker-written task logs and server summaries. On resume, these load alongside long-term memory when it is available. Each source has its own retrieval budget, so external memory cannot crowd out the explicit handoff state. Aria therefore resumes cleanly even when the memory provider is disabled or unreachable.

Voice and remote control

The Director and PMs can be reached conversationally. Voice support allows high-level interaction without the dashboard, including wake-word access to the Director.

Aria also provides an installable mobile interface. From a paired phone, the operator can talk to the Director and PMs, question active workers, inspect project and task status, and create or run tasks. Devices pair securely, and remote access can run over Tailscale while the Aria server stays bound to the local machine by default.

Human control at the top

The models inside Aria are deliberately replaceable; the durable part of the system is the machinery around them. Aria decides which work is runnable, which process receives it, where that process executes, what repository state it can affect, how agents communicate, how concurrent work is isolated, how humans can intervene, and what survives after a session ends.

Agents can plan, delegate, implement, test, review, and coordinate with one another, but nothing reaches a project's codebase without the operator. The operator inspects every change and decides whether it is accepted, rejected, or merged.

The aim is to make increasingly autonomous coding agents manageable as a coordinated engineering system, rather than a collection of isolated chatbots.