Open source · MIT · runs fully local

Autonomy you can
actually audit.

ATLAS is a multi-team agent system. An orchestrator decomposes each goal, routes it to a specialist team, gates destructive work behind human approval, and refuses to mark anything done until a Critic has reviewed the transcript. Every step streams to a dashboard and lands in an append-only ledger.

swappable providers
3
memory tiers
3
execution tiers live
2
unapproved destructive calls
0
ws://localhost:8000/wslive
mypy --strictruff lint + formatpytest + pytest-asyncioscored eval regressionsnext lint + buildOpenTelemetry spansPydantic v2 boundariesuv lockfileStorybook + a11y addonConventional CommitsMIT licensed

Why this exists

Frontier agents are powerful. They are also forgetful, unchecked, and unbounded.

The model is rarely the bottleneck. What is missing is the engineering around it — the part that makes an autonomous system safe to leave running.

Stateless

every run starts from zero

A frontier model that solved your problem last week remembers none of it today. Nothing accumulates, so the same mistakes get made at the same cost, forever.

Unverified

confident output, no second look

Agents mark their own homework. Without an independent reviewer between the run and the result, a plausible-sounding failure is indistinguishable from success.

Unbounded

delete first, ask never

Give an agent shell access and the blast radius is your filesystem. Prompting it to be careful is not a control — enforcement has to live in code.

How it works

One goal in. Five checkpoints before anything counts as done.

  1. 01

    Decompose & route

    The orchestrator writes the goal into the SQLite ledger as a task, then keyword-routes it to a specialist team: systems, research, or ops.

    _route(goal) -> team
  2. 02

    Recall what it knows

    Procedural memory matches versioned markdown playbooks by trigger keyword and injects them into the prompt, so past lessons show up in the next run.

    SkillStore.match(goal)
  3. 03

    Execute behind a gate

    The team runs against whichever provider is configured. Tools declare a tier and a risk class; destructive ones stop at the approval queue until a human decides.

    Risk.DESTRUCTIVE -> ApprovalQueue
  4. 04

    Verify before done

    A Critic reads the run transcript and returns approve or revise. Only approval moves a task to DONE; revise sends it back with feedback for another attempt.

    Critic.review(goal, transcript)
  5. 05

    Persist & stream

    Every normalized AgentEvent lands in the episodic ledger, gets wrapped in an OpenTelemetry span, and fans out over WebSocket to the dashboard as it happens.

    AgentEvent -> ledger + /ws

Architecture

Six layers, one seam that matters.

Everything above the provider protocol is ours: routing, memory, approvals, verification, observability. Everything below it is replaceable. Swap the agent runtime and the guarantees do not move.

Dashboard

Next.js 14 · App Router

ConsoleActivityLedgerSkillsApprovals

Gateway

FastAPI · REST + WebSocket

/goals/tasks/skills/approvals/ingest/ws

Orchestrator

route → run → review → transition

RouterRunnerRetry loopCritic gate

Teams

prompts + declared tools per team

SystemsResearchOpsCritic

Providers

AgentProvider protocol · ATLAS_PROVIDER

Claude Agent SDKLangGraphOllama

Memory

three tiers, three lifetimes

Episodic — SQLiteSemantic — JSONL storeProcedural — skills/*.md

Capabilities

The engineering that makes autonomy trustworthy.

Provider abstraction, not provider lock-in

AgentProvider is a Protocol with one method. Claude Agent SDK, LangGraph, and a zero-dependency Ollama HTTP client all satisfy it, and ATLAS_PROVIDER picks between them at runtime. Nothing above the protocol knows which one is running.

ATLAS_PROVIDER=ollama

Memory in three tiers

Episodic runs live in SQLite, semantic documents in a keyword-overlap store shaped for a drop-in vector backend, and procedural know-how in git-versioned markdown playbooks.

skills/*.md

Approval queue, enforced in code

Tools declare a risk class. Destructive ones route through ApprovalQueue and block on an asyncio.Event until a human clicks approve or deny in the dashboard.

Risk.DESTRUCTIVE

Critic before completion

The reviewer reads the transcript and answers approve or revise. A task reaches DONE only through approval — a revise verdict costs a retry with feedback attached.

approve | revise

Ingestion that drafts its own playbooks

Feed it a PDF, deck, doc, or video transcript; the pipeline extracts imperative steps into a draft skill. Drafts are never auto-promoted — you review before they join procedural memory.

POST /ingest

Built like production software

Because the codebase is part of the argument.

Open the repo and judge it the way a staff engineer would: typed end to end, tested, gated, documented, and honest about what is heuristic today versus what is finished.

strict

mypy across the backend

Pydantic v2 models at every boundary; the provider seam is a typed Protocol

evals

scored regressions in CI

backend/evals runs on every push, results tracked in results.jsonl

2 jobs

gate every pull request

backend: ruff → mypy → pytest → evals · frontend: next lint → next build

audited

every step is on the record

each AgentEvent persists to the ledger and opens an OpenTelemetry span

The requirements audit maps every claim to the code that backs it — including the parts still heuristic.

Local by default

Point it at Ollama and nothing leaves the machine.

The screenshots in the README come from a Windows workstation running llama3.2:3b with zero cloud calls. Secrets come from the environment or the OS keyring, the ledger is a local SQLite file, and skills are plain markdown you can read in a diff.

Run it in a minute

cd backend
uv sync --all-extras
cp .env.example .env     # ATLAS_PROVIDER=ollama
uv run atlas serve       # API on :8000
uv run atlas goal "..."  # watch it move