About

Built to be checked, not admired.

Verity is a self-hosted, multi-service AI orchestrator: a Go gateway, a Python brain, a Rust core and a Rust node daemon, with a web workspace on top. It runs flows and scheduled offices over whichever model providers you configure, remembers by filtering rather than accumulating, and can farm work out to volunteered machines that check each other.

Theambitionisnotasmarteragent.Itisanagentwhoselimits,costsandfailuremodesarewrittendownwhereyoucanfindthem.

Principles

Six rules the code is held to.

  1. 01

    Boot degrades, never dies

    Every dependency has a fallback and every fallback is exercised. Memory drops from the graph store to a vault on disk. The tag registry drops from Postgres to a file to memory. A service that cannot reach its ideal backend comes up worse, not down.

  2. 02

    Identity is proven, not trusted

    The tenant is established from a verified token and carried as call metadata. No handler reconstructs it from something the caller wrote, because a caller who can name the tenant can name a different one.

  3. 03

    Untrusted text stays untrusted

    A web page, an MCP response, a node's output, an uploaded file: all of it is content from elsewhere, and all of it is wrapped before it can influence a model. There is no fast path for sources that look safe.

  4. 04

    Fail closed

    When a check cannot be completed, the answer is no. A vector query without a tenant filter does not run unfiltered; it does not run.

  5. 05

    Bounds are a feature, and they should be visible

    Tool iterations, worker counts and office concurrency are all capped. Publishing the caps is part of the product: an agent with an unstated budget is an agent you cannot plan around.

  6. 06

    The code is the specification

    Documentation drifts. Where a document and the source disagree, the source is right and the document is a bug. That is why Verity's own audit refuses to cite anything but a file and a line.

Where Verity is behind

The list its own audit produced.

Verity keeps a gap audit against the strongest comparable products, with a file-and-line citation behind every claim it makes about itself. These are the findings that went against it.

01

The model cannot write and run its own code

It can call skill scripts that already exist on the server, choosing the script and its arguments, but it never authors a program.

The sandbox to run one (path jail, scrubbed environment, network isolation, resource limits) is already built and tested. The tool that would let a model use it is not.

02

There is no image input

The turn model is text-only. Uploads are converted to markdown, so a screenshot contributes nothing. "What is wrong in this picture" is a question Verity structurally cannot answer today.

03

A running job cannot be interrupted

Flows and offices are start-and-poll. There is no cancel route, and the queue only drains cooperatively at shutdown. Steering a long run mid-flight is not available.

04

Several shipped capabilities have no screen yet

Artifacts, projects, the knowledge base, memory inspection and MCP server management all have working service routes and no user interface.

The backend is further along than the product, and that gap is the top item on the plan.

05

MCP servers are anonymous

You give Verity a base URL and it connects without credentials. The encrypted vault that would hold a per-server secret exists and holds provider keys; wiring connectors through it has not been done.

Deliberately not doing

A scope with an edge to it.

Some of what competitors ship is missing from Verity because it has not been built. The following are missing because building them would make it a different product.

  • Video and music generation. Image generation exists behind a provider gate; the rest is a different product.
  • A node canvas as the primary interface. Verity bet on linear chat plus explicit flows and offices instead.
  • A fleet of interactive remote browsers. The narrow render-to-markdown fetch service is the deliberate slice; a click-and-type browser is a security decision to put to a user, not a backlog item.
  • Hosting user sites on custom domains. That is a hosting business with its own abuse, takedown and certificate burden. Read-only share links stay.

Disagree with any of it in public.

The audit, the plan, the tests and the code are all in one repository. If a claim on this site is wrong, the file that proves it is right there.