Show HN: Select – AI agents that earn autonomy through verified work

Run your company with AI agents that earn their autonomy. Agents of any kind — developers, marketers, support, sales — work in an organization you design. Every result is checked by code against a delivery contract, and an agent stops needing your approval only once its verified record shows it can — per task type, revocable at any time. Status: 0.2. Accounts, guided setup, local IMAP/SMTP mail tests, routines and the verification loop are covered by end-to-end tests. Docker images build and the Compose stack starts successfully in Ubuntu GitHub Actions CI. Real model API calls have not been verified yet: see Limits. Why Select Multi-agent orchestrators let you decide in advance what agents may do alone. Select replaces that guess with evidence: Delivery contracts. Each task type has a YAML contract. The system runs its checks itself and keeps a receipt — contract version and hash, every check, the evidence. A model never declares that a check passed. Autonomy earned per agent and task type. Supervised → sampled → autonomous after a streak of verified successes; back to supervised at the first blocking failure or human correction. Limits the score never overrides. Payments, contracts, taxes and hiring are always supervised, in code. An honest counter. The share of work finished without a person is always shown next to the rate of errors people found afterwards. No invented numbers. Every value carries its source; a quantity that is not in the customer's e-mail fails verification. Both diagrams are SVG and can be reviewed or edited directly in the repository. What it does These four come from the end-to-end test run against local IMAP and SMTP test servers (E2E_SCREENSHOTS_DIR); the others are the demo company. All are real captures. Explore the interface These are real Playwright screenshots of Select running locally with fictional demo data. No external model provider or mailbox is connected in this capture session. Quickstart Requirements: Docker Desktop (Windows, macOS) or Docker Engine with Compose (Linux). git clone https://github.com/Kirby54/Select.git select cd select ./start.sh # Windows: .\start.ps1 The script writes .env with random secrets (keep a copy), starts the containers and opens http://localhost:3000, where the first visit creates your account. Without the script: cp .env.example .env, set the secrets, docker compose up --build. No API key yet? Open the demo company from the account menu and press Run demo week. Five-minute guide: docs/getting-started.md. Development setup without Docker: docs/installation.md. How autonomy works Default promotion thresholds are 20 and 50 verified successes in a row — starting hypotheses to calibrate, not proven values. An e-mail to an address that never wrote to you always goes to a person. Details: docs/autonomy.md. A contract id: support_reply version: 1 title: Support reply risk: medium required: [to, subject, body] checks: - id: recipient_from_message rule: provenance # the address must be the one that wrote to us params: { fields: [to] } - id: no_unauthorised_promises rule: forbidden_phrases params: { field: body, phrases: ["refund", "discount", "guarantee"] } approval: mode: by_autonomy external_action: send_email More in docs/verification.md. Architecture Next.js 16 web app → FastAPI API → PostgreSQL 16, with a worker on a durable PostgreSQL job queue that runs agents, reads mailboxes, sends approved e-mail and fires routines. select-verify is a separate Python library with no database or network access. See docs/architecture.md and the interface's design system. Security Agents never hold a permission to send, pay or sign; the server applies the approval rules and sends. External content is treated as data and checked against stored sources. Passwords use Argon2id; sessions live in an HttpOnly cookie with an anti-forgery header; provider keys and mailbox passwords are encrypted. Read docs/security.md and docs/deployment.md before opening Select to a network. make test # Python verifier/API tests on PostgreSQL plus frontend unit tests make e2e # Playwright UI scenarios against a running stack e2e/complete.spec.ts (4 more scenarios) runs on a password-mode stack with the local mail servers of scripts/dev-mail.py: first owner, guided setup, a real IMAP mailbox, an e-mail triaged, routed, quoted, approved and sent once over SMTP (the .eml file is checked), a weekly routine seen from a New York browser on Paris time, and an invited colleague joining. Verify a real model (optional) The CI tests use network doubles, not real provider keys. Before connecting production data, use the explicit live-provider probe with your own test credentials. It sends a harmless fixed JSON-generation prompt and reports whether the chosen model returns the expected result. It never stores the key or accesses company data. Real-provider compatibility is not yet certified by the maintainers. Benchmarks None published yet. The protocol (autonomy-bench: same tasks and models, autonomy rate and undetected-error rate side by side, compared with a single agent and with Paperclip) is in bench/README.md. Until it runs, Select makes no comparative claim. Feature parity is tracked honestly in docs/parity.md. Provider calls have not been exercised against real paid-model APIs (no keys in CI). An Ollama-compatible localhost HTTP stub is used to test the full worker, deterministic verification and approval pipeline; it does not execute a real model. Docker: GitHub Actions builds both images, starts PostgreSQL, API, worker and web with Compose, and reaches the API health endpoint through the web proxy on Ubuntu. The start.sh script itself was tested with a stand-in Docker CLI; real macOS/Windows installations and start.ps1 have not been exercised in CI. Mailboxes were tested against local IMAP and SMTP servers, not yet at a real provider. No OAuth: Microsoft 365 and Outlook.com cannot connect yet; Gmail needs an app password. Agents write text and structured results through model APIs. Code-change proposals can be checked for basic diff structure and sent to mandatory human review, but no repository code is edited, executed or pushed by Select. There is no isolated Claude Code or Codex runtime yet. See review-only code proposals. Attachments are not read; quotes are sent as e-mail text, without a PDF. No e-invoice: the invoice draft is not an XRechnung or ZUGFeRD file and is never presented as compliant. Businesses exempt from VAT (franchise en base) are not handled properly yet. No single sign-on, two-factor authentication, plugins or sandboxed code execution. Documentation Five minutes · Installation · Provider probe · Configuration · Mail · Agents · Autonomy · Verification · Workflows and routines · Architecture · Deployment · Security · Troubleshooting · Design system · Français Contributing Start with CONTRIBUTING.md. Good first contributions: a new contract for a task type you know, or a new deterministic rule — each with one accepted and one rejected example. Verify with real model keys and real mailboxes; keep Docker startup, recovery and tests green across supported environments. Coding-agent runtimes: run Claude Code or Codex in a code workspace, verify with the project's tests, approve the exact diff. Run without Docker (embedded database), like a one-command install. Quote PDFs, attachments, OAuth mailboxes, VAT-exempt businesses. Run autonomy-bench and publish the raw results. The application (apps/) is licensed under AGPL-3.0-only (LICENSE). The select-verify library is licensed under Apache-2.0 (packages/select-verify/LICENSE) so that other tools can adopt delivery contracts freely. Questions and ideas: GitHub Discussions. Bugs: GitHub Issues. Vulnerabilities: privately, see SECURITY.md.