Atlas AI

Company intelligence platform

Company Intelligence, Grounded in Evidence.

Discover company insights through semantic search, hybrid retrieval, and evidence-grounded AI.

Explore company information, ask questions, and investigate relevant evidence through a focused research experience.

Get started

No password required. We email you a one-time verification code. Public email providers such as Gmail and Outlook.com are not accepted.

What you can do

How Atlas AI works

Atlas AI combines company intelligence, evidence-grounded retrieval and controlled AI workflows to support informed business decisions. This is the target architecture: the intended final design. Every component carries its own status; this application is not deployed at atlas-intelai.com yet.

Target architecture diagram

Atlas AI target architecture Public entry point, the Atlas AI application, the separate Research Agent, one shared PostgreSQL database named atlas_app with four schemas, and external SMTP and AI providers. Each component carries its own status; the numbered connectors are explained in the list below the diagram. PUBLIC ENTRY POINT - the internet side of the trust boundary User browser EXTERNAL https://atlas-intelai.com DNS + HTTPS/TLS EXTERNAL Nginx reverse proxy TLS ends here EXTERNAL 1 ATLAS AI APPLICATION - one trust domain (FastAPI backend) Web frontend static HTML/JS (no React yet) E2E PENDING API layer FastAPI routes, CSRF VERIFIED Auth & sessions email one-time code VERIFIED Human approval single-use, expiring VERIFIED Orchestrator planner + validator E2E PENDING Workflow engine durable state, recovery VERIFIED Dashboard & results Research tab; dashboard planned E2E PENDING Quota service reserve, settle, reconcile VERIFIED Research adapter client + handler (fakes) E2E PENDING Atlas owns identity, authz, workflows, approvals, quota. Research Agent owns its runs. Email never decides. Policy & authorization roles, deny by default VERIFIED Email service (SMTP) login codes; alerts planned E2E PENDING 2 3 4 5 6 7 11 12 10 13 8 9 RESEARCH AGENT - separate service, own trust boundary Internal HTTP API POST /v1/research, status, result; bearer token E2E PENDING Worker, leases and fencing claims queued runs; heartbeat E2E PENDING Research execution & providers Claude Managed Agents + Parallel E2E PENDING Run state & results (RunStore) SQLite today, dev only; PostgreSQL planned PLANNED Status, result & usage reporting token usage per run, estimates only E2E PENDING Recovery, idempotency, safe retry no automatic resubmission E2E PENDING SMTP provider mail transport only EXTERNAL AI & search providers paid, budgeted EXTERNAL 14 15 POSTGRESQL - production persistence: ONE shared database named atlas_app, four schemas atlas_auth identity & authentication owner: Atlas VERIFIED atlas_workflow workflows, executions, approvals owner: Atlas VERIFIED atlas_quota allowance, reservation, usage owner: Atlas VERIFIED atlas_research proposed Research Agent persistence owner: Research Agent PLANNED Least privilege (planned): each service gets its own database login limited to its own schema. The Research Agent cannot read or write atlas_auth, atlas_workflow or atlas_quota; Atlas reaches research results only through the Research Agent API. SQLite is not the production persistence layer. Today the Research Agent still stores runs in a local SQLite file for development; its PostgreSQL RunStore is planned after review. identity workflow & approval state quota ledger run state (planned)

Solid arrows are the primary request path; dashed arrows are status, notification and planned flows. Numbers match the list below.

Data flows

  1. Request path. The user reaches the application over HTTPS; Nginx terminates TLS and proxies to the FastAPI backend. External infrastructure, not verified for Atlas AI.
  2. Authentication. The API layer checks the session cookie and CSRF header; sign-in uses an e-mailed one-time code. Atlas owns identity.
  3. Workflow creation. A validated request becomes an execution plan in the orchestrator (permission check first, deny by default).
  4. Durable registration. The workflow engine stores the execution and its tasks in PostgreSQL before any work starts; duplicate submissions return the same execution.
  5. Task execution. The engine claims each task exactly once and hands research tasks to the Research Agent adapter.
  6. Authorization gate. Policy and authorization are checked per task; approval-protected actions are denied unless a human has approved.
  7. Quota reservation and reconciliation. The adapter reserves tokens BEFORE submitting. After the run it settles from the usage the Research Agent reports, releases only a definite non-submission, and keeps uncertain outcomes held for reconciliation.
  8. Submission. One authenticated request per logical operation, carrying an Idempotency-Key, so a retry returns the same run instead of a second paid one.
  9. Status, result and usage evidence. Atlas polls status, then fetches the result and the reported token usage. Progress goes back to the workflow; usage is the evidence for reconciliation.
  10. Completion to dashboard. Workflow state, progress and results are read through the API and shown in the interface (a full dashboard is planned).
  11. Human approval requested. A protected task is parked; an approval record with an expiry and a hash of the exact action is created.
  12. Approval resolved. A signed-in, authorized person decides through an authenticated backend endpoint (session and CSRF checked); the approval can be consumed once.
  13. Notifications (planned). Approval links and workflow completion or failure notices are to be sent by the native e-mail service. Transport never decides anything.
  14. SMTP delivery. The e-mail service hands messages to the SMTP provider. Login codes use this path today.
  15. Provider calls. Only the Research Agent talks to AI and search providers, under its own spend limits.

Ownership and trust boundaries

Components and their status

Public entry point
  • Domain, DNS, HTTPS and Nginx External infrastructure dependency

    The public name atlas-intelai.com, its DNS records, the TLS certificate and the Nginx reverse proxy are infrastructure outside this application. This application is not deployed at atlas-intelai.com yet.

    Evidence: a read-only check found the domain served by a separate website host, not by Atlas AI

Atlas AI application
  • Web frontend Implemented, end-to-end verification pending

    A static HTML, CSS and JavaScript interface served by the FastAPI backend: landing page, sign-in, search, the Research tab, approvals and the usage view. It is not built with React today.

    Evidence: served and tested through the API routes; browser-level verification is pending

  • API layer Implemented and verified

    FastAPI routes with security headers, request limits, session and CSRF protection and a readiness probe.

    Evidence: verified against the real database and a running server in earlier milestones

  • Authentication and sessions Implemented and verified

    Passwordless sign-in by e-mailed code, hardened session cookie, server-side logout. Identity data lives in the atlas_auth schema.

    Evidence: real e-mail sign-in, logout and session revocation were exercised

  • Policy and authorization Implemented and verified

    Roles, deny-by-default research permission, ownership checks and an admin-only recovery view.

    Evidence: tested over HTTP against the real database

  • Orchestrator Implemented, end-to-end verification pending

    Plans, validates and schedules tasks. The planner has been exercised with fakes and hostile stand-ins, not with a live model.

    Evidence: no live planner run

  • Workflow engine and durable state Implemented and verified

    Executions, tasks, events, leases and recovery are persisted in atlas_workflow; interrupted runs are resumed without a second remote run.

    Evidence: real-database integration tests, including restart recovery

  • Human-in-the-loop approval Implemented and verified

    Approval records are single-use, expire, and are bound to the exact action; decisions go through an authenticated endpoint. Notification links are planned.

    Evidence: real-database tests including races and expiry

  • Central quota and usage control Implemented and verified

    A durable ledger reserves tokens before a paid call, settles from reported usage, keeps uncertain outcomes held and supports administrator reconciliation. Atlas owns it.

    Evidence: real-database tests of concurrency, recovery and the admin status view

  • Research Agent adapter Implemented, end-to-end verification pending

    The Atlas-side client and task handler for the Research Agent contract, with reservation before submission and idempotent retries.

    Evidence: verified only against an in-process fake of the Research Agent

  • Native e-mail (SMTP) Implemented, end-to-end verification pending

    Atlas sends its own e-mail through SMTP. Login codes are implemented and exercised. Approval notifications and workflow completion or failure notices are planned.

    Evidence: login code e-mail delivered in a real sign-in

  • Dashboard, task progress and results Implemented, end-to-end verification pending

    Task progress, status and results appear in the Research tab and the usage view today; a dedicated dashboard is planned.

Research Agent
  • Separate research component Implemented, end-to-end verification pending

    An independent service in its own repository. It exposes an internal, token-protected HTTP API and runs research on Claude Managed Agents with Parallel search. A worker interface is internal to the service.

    Evidence: offline tests with fakes; Atlas has not yet called a live instance

  • Persistent run state Planned / integration pending

    Runs, leases, results and audit events are stored behind a RunStore interface. The only implementation today is a local SQLite file for development. A PostgreSQL RunStore in the atlas_research schema is planned; it is a new implementation, not a connection-string change.

  • Status, results and usage reporting Implemented, end-to-end verification pending

    Status, result retrieval and per-run token usage (with cost estimates labelled as estimates) are implemented in the service.

    Evidence: offline tests

  • Recovery, idempotency and safe retry Implemented, end-to-end verification pending

    Duplicate keys return the same run, expired leases are taken over with a fencing generation, and uncertain runs wait for an operator instead of being resubmitted.

    Evidence: scripted fakes only; live provider behaviour unverified

PostgreSQL (atlas_app)
  • atlas_auth, atlas_workflow, atlas_quota Implemented and verified

    Three schemas of the shared database atlas_app, owned by Atlas. The application never creates them; they are installed by reviewed migrations.

    Evidence: real-database integration tests and runtime checks

  • atlas_research Planned / integration pending

    Proposed schema for Research Agent persistence, to be designed and implemented after review.

  • Least-privilege database access Planned / integration pending

    Separate logins per service and schema, with no Research Agent access to authentication, workflow or quota data.

Atlas AI is a portfolio project under development. Items marked Planned are not available.

Why do we ask for your email?

  1. Enter your email address. Use your work, business, or institutional address.
  2. Verify ownership. We send a one-time code that works once and expires after a few minutes. Entering an address alone never signs you in.
  3. Access the available features. After verification you can use the features marked available.
  4. Manage your account and usage as those capabilities become available.

Your email identifies your account. It is used for verification and account-related functionality.

Why not Gmail or Outlook.com? Atlas AI is intended for professional use, so public email providers (such as Gmail, Outlook.com, Yahoo and iCloud) are not accepted. The check is made on our server. Verifying a code proves you can read the mailbox; it does not prove which organisation you work for.

Privacy

We store your email address to identify your account, a keyed hash (not the text) of each verification code, and a record of your sign-in sessions. A formal privacy policy and data-retention terms have not been published yet; until they are, treat this service as a demonstration and do not enter confidential information.