Select gives AI agents more freedom only after code verifies their work

Trust built from a track record

Select, a project posted to Show HN and hosted on GitHub, is built around one idea: an AI agent should not get freedom because you hoped it would behave. It should get freedom because its work has been checked, repeatedly, and held up. As github.com describes it, agents of any kind (developers, marketers, support, sales) work inside an organization you design.

The project contrasts itself with multi-agent tools where you decide up front what each agent may do alone. Select calls that a guess. It replaces the guess with evidence gathered while the agents work.

How the checking works

Every type of task has a delivery contract, a short file written in YAML (a plain-text format for settings). The contract lists what a finished result must contain and which checks it must pass. The system runs those checks itself and keeps a receipt: the contract version, a fingerprint of it, each check, and the evidence behind it. The AI model never gets to announce that a check passed.

The example in the project is a support reply. One check confirms the recipient address is the one that actually wrote to the company. Another scans the body for phrases the agent is not allowed to promise, such as "refund", "discount" and "guarantee". The contract also says that sending the email depends on the agent's current level of autonomy.

A related rule covers numbers. Every value an agent writes must carry its source, and a quantity that does not appear in the customer's email fails verification. That targets a common failure of text-generating models: confidently stating figures that were never provided.

The autonomy ladder and its hard stops

Autonomy is tracked for each agent and each task type separately. A new agent starts supervised, so a person approves its output. After a streak of verified successes it becomes sampled, meaning only some of its work is reviewed. After a longer streak it becomes autonomous. The default streaks are 20 and 50 successes in a row, and the project says plainly that these are starting hypotheses to calibrate.

The ladder runs both ways. The first failure that blocks a result, or the first time a human corrects the agent, sends it back to supervised.

• Payments, contracts, taxes and hiring stay supervised no matter what the score says, and this is enforced in code.
• An email to an address that never wrote to the company always goes to a person.
• Agents never hold permission to send, pay or sign. The server applies the approval rules and does the sending.

The project also shows an "honest counter": the share of work finished without a person, placed beside the rate of errors people found afterwards. A high automation figure alone would be flattering; pairing it with later-discovered mistakes keeps it honest.

What is not proven yet

The project is candid that this is version 0.2. The end-to-end tests, the account setup, the routines and the verification loop pass, and the Docker setup builds and starts in automated testing. But real calls to paid model APIs have not been verified. The tests use a stand-in server that mimics a local model, so the pipeline is exercised without a real model answering.

Email has the same caveat. It was tested against local test mail servers, not a real provider. There is no OAuth sign-in, so Microsoft 365 and Outlook.com cannot connect, and Gmail needs an app password. Attachments are not read, and quotes go out as plain email text.

Code-writing agents are also out of reach for now. Select can check the basic structure of a proposed code change and send it to mandatory human review, but it does not edit, run or push code. There is no two-factor sign-in or sandboxed code execution either.

The project plans a benchmark called autonomy-bench, which would compare autonomy rate and undetected-error rate against a single agent and against a tool named Paperclip. No results are published, and until they are, Select says it makes no comparative claim.

Who should look, and what to watch

The most interesting part is the principle, not the software: verification done by ordinary code, with limits that no score can override. That answers the obvious weakness of any graduated-trust scheme, which is a weak check making the whole ladder meaningless. Here the checks are deterministic rules, so quality depends on how well the contracts are written. The project invites contributions of new contracts and rules, each with one accepted and one rejected example.

On the technical side, it uses a web app, an API and a PostgreSQL database, with a background worker running agents. The verification library is separate, licensed Apache-2.0 so other tools can adopt it, while the application is AGPL-3.0-only. Discussion so far is thin, so this is one to watch rather than deploy on company data.