← Mengyun Wang

Atlas

Multi-agent execution platform  ·  live demo →  ·  source →

You give Atlas a goal. A Planner turns it into steps; a Safety agent and a fixed set of keyword rules both score the plan, and the higher score wins, so a persuasive model can't talk its way past the gate. Anything over the line stops and waits for a person. Then a Browser searches and reads, a Coder writes and runs Python in a sandbox, a Verifier checks the result against the goal and can send everything back for one more pass. One orchestrator owns every state change and never calls a model itself.

Every event is written to the database before it reaches the UI, so a task survives a restart, can be replayed, and can be audited. The whole thing runs end-to-end with no model keys; point it at Ollama or an API key and the same code talks to a real model.

Open the live demo → It is the real Atlas UI replaying event histories recorded from a demo-mode run. Give it a goal; a risky one stops at the approval gate and waits for you.

5
agents, one orchestrator
2
risk scores, the higher one wins
46
tests, lifecycle to SSRF
0
keys needed to run it

What's in it

AreaUsed here
Agent designFive agents behind one run(task, step) contract; an orchestrator that owns all state and never calls a model
Control flowTask graph, bounded retries with backoff, one verifier-driven rework pass, human approval gate with a timeout
Risk scoringKeyword rules merged with a model score — the model can't lower the floor
LLM plumbingOne layer over Anthropic, Groq, Gemini, Cerebras, Ollama; JSON mode plus a parser that digs JSON out of prose; a deterministic demo provider for tests
Prompt hygieneFetched web text wrapped in markers and declared as data, not instructions, in every system prompt
PersistenceSQLAlchemy 2, SQLite (WAL) by default, PostgreSQL by URL, Alembic migrations; event stored before broadcast
Crash safetyUnfinished tasks resume from the last completed step after a restart; approvals survive restarts and expire on a schedule
Background workCelery with late acks and a per-task Redis lock; a high-risk task pauses in the database and frees its worker
Real-timeSSE with snapshot-on-connect, keepalives, replay from the database on reconnect; Redis pub/sub across API replicas
AuthAPI keys → tenants, constant-time comparison, HMAC-signed HttpOnly cookies, tenant checked on every query
Abuse limitsFixed-window rate limiting (Redis or in-memory), request size cap, trusted-host and CORS allowlists
SandboxingDeny-list, then python -I in a clean env, or a throwaway Docker container: no network, read-only root, dropped capabilities, CPU/memory/PID limits
SSRF defenceScheme/port/credential checks, DNS resolved and every address checked for global scope, redirects re-validated hop by hop, type and size limits
ObservabilityJSON logs, request IDs, Prometheus metrics for HTTP, task events and model calls; health endpoint probes the provider
Failure reportingA dead provider fails the task with a message that says what to run, and shows as a banner before you submit
MemoryPer-task working memory in process; episodic memory in the database, fed back into planning
API & frontendFastAPI with dependency-injected tenant context; plain HTML/JS with EventSource, no build step
PackagingDocker Compose (Postgres, Redis, migrate job, API, worker), non-root read-only image, healthchecks, CI with ruff and pip-audit
Testing46 pytest cases: unit, lifecycle, HTTP with SSE, security; httpx.MockTransport for network paths; monkeypatched agents for retry and rework