verification

A verification agent that checks whether a software change works and returns a concise result. It is designed to keep routine build and test output out of the main conversation unless something fails.

In plain words
What is it for?
Running deterministic build or test checks as a separate verification step and reporting the relevant evidence when a check passes or fails.
Why use it?
Large test logs consume attention even when everything passes, while failures can be buried in noise. This approach keeps successful checks cheap and focuses investigation on the useful failure details.

Agent

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/techygarg/lattice/verification
Clone the repo
git clone --depth 1 https://github.com/techygarg/lattice
Per session 0 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 2,064 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00000 $0.02064
Opus 5 $0.00000 $0.01032
Sonnet 5 $0.00000 $0.00413
Haiku 4.5 $0.00000 $0.00206

Measured 2d ago against content hash 528d5d892e24, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

verification scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

docs/agents/verification.md · 86 lines

How it starts

The opening of the file, as written. The whole thing — 86 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Verification: Design Rationale

Why the verifier exists, the cost model behind it, and how to wire it into your own sessions.

Audience: Teams deciding whether to adopt Lattice's verification gate, and anyone wondering why it's a subagent instead of a slash command. Motivation is coming from : The Orchestrator Tax


The Problem

Confirming a change actually works usually means running the project's build/test commands in the main session. Two failure modes follow from that:

  • On green, the full stdout of every stage — build noise, dependency resolution, hundreds of passing test names — lands in the main session's context anyway, paid for whether or not anyone will ever look at it.
  • On red, the session either re-reads that same noisy output to find the one line that matters, or gives up and pastes the whole thing back to itself.

Either way, the cost of "did this work?" scales with how noisy the tooling is, not with how useful the answer is.

The Hypothesis

A pass/fail check should cost almost nothing when it passes, and only the price of what's actually needed when it fails.

Verification is deterministic — it needs no judgment, no creativity, no large context window. It needs: run the configured commands, in order, report what happened. That's a job for a script, not for the reasoning session's full attention. Wrapping the script in a lightweight subagent adds a second cost win wherever the host supports one: the run happens in an isolated context, and only a small structured verdict — never the run itself — touches the main session.

The Philosophy

  1. Deterministic execution owns the run, not the agent. scripts/run-verification.sh (the portable core) owns config parsing, iteration, stop-on-first-failure, and logging. The verifier subagent (agents/verifier.md, a host adapter) never reimplements that control flow, never greps a log for a root cause, never guesses why something failed. It runs the script once and reports what's already on disk.

Read the full file on GitHub · 86 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 86 lines · 0 tokens per session scan A 528d5d892e24

Subscribe to this mod's changes

verification is an agent published in the GitHub repository techygarg/lattice (183 stars, last pushed 3d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,064 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.