Atlas — Autonomous multi-agent research platform

Atlas is a multi-agent research platform. A planner decomposes a question into independent subtasks, researcher agents investigate them in parallel against live web search, a critic reviews the findings against the sources actually retrieved and can send specific branches back, and a synthesizer writes a cited answer. The whole run streams to the browser as it happens.

Built and verified against live providers through Phase 4. A graded regression eval suite (Phase 5) is in progress and Langfuse tracing (Phase 6) comes next, so no quality scores are reported yet. Atlas runs locally, with Postgres and Redis in Docker Compose.

I built Atlas to practice the engineering that separates an agent demo from an agent system: concurrency that is genuinely concurrent, a quality gate that can reject work, cost limits that are enforced rather than hoped for, and runs that survive a dropped connection.

• Sole engineer — architecture, backend, frontend and verification.
• Documented every phase: design decisions, defects found, and how each fix was verified against live providers.

1. 01

   Fan-out that is genuinely concurrent

   The planner emits self-contained subtasks and LangGraph's Send dispatches one researcher per subtask. On a live five-branch run the slowest branch took 23.3 s against 93.4 s summed — the fan-out costs the slowest branch, not the sum.

2. 02

   A critic that can say no

   The critic returns a structured verdict per subtask, judged against the sources actually retrieved rather than the model's own knowledge. Routing is derived from the verdict: accept, re-research only the faulted branches, or rewrite the synthesis alone.

3. 03

   Cost enforced, not hoped for

   A per-run token counter in Redis is checked at the critic — the only node from which a new iteration can begin. If the budget runs out, the answer ships with an explicit “unverified” note instead of silently looping.

4. 04

   Runs that outlive the connection

   The API enqueues and relays; an arq worker executes. Nine typed event kinds go to a Redis Stream and an SSE endpoint relays them with Last-Event-ID replay. Killing the API mid-run was tested: the run completed with nothing listening, and the UI converged to the identical final state on restart.

5. 05

   A graph view that cannot drift

   The frontend draws topology from an endpoint derived from the compiled LangGraph. The critic → researcher retry edge is declared, so it is drawn dormant from the first frame and lights up when it fires. A test pins the node and edge sets.

• Targeted retry over full re-runs

  Re-running the whole graph would cost ~72 s and ~31k tokens per iteration, and re-planning produces a different decomposition, so per-subtask feedback has nothing to attach to. Targeted retry costs the slowest faulted branch plus one synthesis.

• Upsert results, don't append them

  Once a branch can be retried, appending produces two contradictory results for one subtask. Results are upserted by subtask id — proven with a negative-control test that fails under the old reducer.

• arq over Celery

  Atlas is async end to end. Celery would mean a synchronous worker spinning up an event loop to call an async graph, plus a second broker; arq is async-native and uses the Redis already in the stack.

• A fixed pipeline before ReAct

  Each subtask arrives self-contained, so researchers use bounded search rather than an open-ended tool loop. Swapping in a ReAct researcher changes nothing about the graph shape or the tests — a decision to make with eval data, not speculation.

Measured on local runs against live providers, as documented in the repository. These are latency and cost measurements, not answer-quality scores.

• In progress: a graded question set with regression runs against known-good answers. Langfuse tracing follows. Quality numbers will be published once a baseline exists.

1. 01

   A fallback that always fires looks like a working system

   An explicit temperature the primary model rejected sent every call to the fallback while every answer still looked fine. A regression test now asserts the primary path works, not just the fallback.

2. 02

   Live verification finds what unit tests can't

   Every Phase 1 defect — including a search tool that reported 401 errors in-band as “no results” — was a failure wearing the costume of success, and none was caught by tests.

3. 03

   Declare structure instead of inferring it

   On a clean run the critic never retries, so a graph inferred from events would hide the most interesting edge exactly when the system works well.

• LangGraph
• Claude Sonnet 5
• GPT-4o (failover)
• FastAPI
• arq
• Redis
• PostgreSQL
• Next.js
• React Flow
• Tavily
• Docker Compose