A verification queue for coding agents.

verifique runs on your laptop. Agents hand over their finished work and carry on, each check runs when a slot is free, and every one ends in a verdict with proof.

~/src/storefront
$ verifique submit --check manual --request-file request.md --brief "Open Settings"
uncommitted work captured as 1170dea76
43
$ verifique wait 43 &
$ verifique status
2/2 slots busy, 2 queued

running
  #41  storefront   feat/search   manual     slot 4
  #42  billing-api  fix/invoices  e2e        slot 5

queued
  #43  storefront   feat/settings manual
  #44  mobile-app   fix/login     typecheck

recent
  #40  storefront   feat/cart     manual     passed: the discount applies at checkout
  #39  billing-api  fix/tax       e2e        failed: check exited with 1

Why it exists

Writing code scales to dozens of agents. Verifying it on one laptop doesn't.

Run fifteen sessions and they all finish around the same time. Each one starts a stack to check its work, and they collide over ports, databases and memory. Worktrees separate your files, not any of that.

Moving to the cloud gives up the fast feedback of working locally. verifique keeps verification on your laptop, and runs only what your laptop can carry.

How it works

  1. Hand it over

    An agent submits your original request and how to reach the change. Uncommitted work is captured for it.

  2. Keep working

    It waits in the background and spends no tokens. Repositories take turns, and fixes go ahead of new work.

  3. Run in isolation

    The check gets its own ports and fresh databases on your existing servers. Your app runs natively, not in a container.

  4. Get a verdict

    A fresh checker compares the work with what you asked for. If it failed, the agent wakes up and fixes it.

One short file

Your agent writes it.

Run verifique init and give the guide to your coding agent. It works out what two copies of your app would fight over and writes this file.

Then verifique doctor proves it: two copies side by side, each using its own data. Your framework doesn't matter. Your database servers just need to be running already.

verifique.yaml
services:
  postgres: {}
  redis: {}

stacks:
  web:
    prepare: [pnpm install, pnpm build]
    seed: pnpm db:seed
    env:
      DATABASE_URL: "{postgres.url}"
      REDIS_URL: "{redis.url}"
    apps:
      web:
        run: pnpm start
        port: 3500
        ready: /
        env: { PORT: "{port}" }

checks:
  e2e: { stack: web, slots: 2, run: pnpm test:e2e }
  manual: { stack: web, type: agent, agent: claude }

Proof

An agent shouldn't mark its own homework.

  • Judged against your words. The checker gets your request and the diff, not just the author's summary.
  • No proof, no pass. A pass needs its steps, what it saw and an evidence file.
  • Crashes never pass. A check that dies can't read as success.
  • Tied to the content. Commit the same files later and the verdict still holds.
  • Clean every time. Databases are created, seeded and dropped for each check.
  • It knows when to stop. Three failures in a row and the branch comes to you.
verifique show 6
job 6: failed on storefront
check   manual
content afa3d3034  commit 511d73986

Google Fonts fetching was correctly removed, but only
weights 300, 400 and 900 are wired into the bundled font.

steps
  - Read the diff
  - Signed in as the setup step instructed
  - Inspected all network requests
  - Parsed the served CSS for @font-face rules
  - Queried document.fonts in the live page
  - Saved a screenshot of the dashboard

saw: exactly three @font-face rules for roboto, at 300,
400 and 900. The 500 and 700 files exist but are never
referenced.

not checked: a pixel comparison against a build from
before the change.

files   ~/.verifique/jobs/6

A real run on a planted bug, shortened, with the project renamed.

Also built in

Any kind of test
Unit tests, Playwright, a typecheck, or an agent driving the app by hand.
Timed holds
An agent chasing a bug can hold a stack. It ends by itself, so it can't jam the queue.
Whole suites
A check can take several slots, one per worker, from a single build.
Headed or headless
Headless by default. Open a real window when you want to watch.

Status

Early, and not released yet.

Working today

  • The queue, slots and background service
  • Isolation on Postgres, Mongo and Redis
  • Agent checks with Claude Code
  • macOS. Linux is written but untested

Still to come

  • A status-bar panel, as Docker has Docker Desktop
  • Homebrew and other install packages
  • Other checkers, such as Codex
  • Windows

It's being proven on real projects before the first release. Until then, you can build it from source.