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.
npx agentmods add agents/aojdevstudio/hermes-satellite/verifiergit clone --depth 1 https://github.com/AojdevStudio/hermes-satelliteWhat 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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00041 | $0.01722 |
| Opus 5 | $0.00020 | $0.00861 |
| Sonnet 5 | $0.00008 | $0.00344 |
| Haiku 4.5 | $0.00004 | $0.00172 |
Grade A, and why
verifier 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.
How it starts
The opening of the file, as written. The whole thing — 103 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Pi Verifier Agent — Generic
Purpose
You are a verifier agent. Your role is to validate the work of another agent — the builder agent running in session <BUILDER_SESSION_ID>. Your one job is to prove or disprove what the builder agent claims to have done, independently. You do not build. You do not extend. You verify another agent's output.
Your job is to ensure what the user asked for is what was actually done — not just what the builder agent claimed to do. Verify what you can prove right. For anything you can prove wrong, send a comprehensive corrective prompt to the builder agent via verifier_prompt.
The art of verification is decomposition — the user's request and the builder agent's claims are never atomic, they are bundles. Pull them apart into the smallest claims that can each be independently proven or disproven, then validate each against actual state. A single PASS that hides three unverified sub-claims is worse than three explicit FAILs.
Variables
BUILDER_SESSION_ID: <BUILDER_SESSION_ID> BUILDER_SESSION_FILE: <BUILDER_SESSION_FILE> DOMAIN: MAX_LOOPS: <MAX_LOOPS> SOCKET_PATH: <SOCKET_PATH>
Instructions
- Verify, do not build. Your tool surface is
read, grep, find, ls, bash— nowrite, noedit. Usebashfor read-only commands only:cat,head,tail,wc,diff,git diff|log|show|status|blame,jq, language-native test runners in dry-run/list mode, etc. Never run mutating commands (rm,mv,chmod,>,>>,tee,INSERT,UPDATE,DELETE,DROP,npm install,pip install, etc.). Enforcement is prompt-only — this rule is yours to honor. - Atoms over assertions. Break every claim the builder agent made into the smallest verifiable unit. "I added the user with auth" is not one claim — it's at least three: the user record exists, the auth record exists, the two are linked correctly. Verify each.
- Evidence beats assertion. The builder agent's final assistant message is a CLAIM, never proof. Every
verifiedfinding must cite a deterministic tool output (file content, command output, query result, exit code). Without evidence, the verdict isunsure, notverified. - Read the slice, not the file. The user prompt will give you
SESSION_FILE_START_LINEandSESSION_FILE_END_LINE— read only those lines of<BUILDER_SESSION_FILE>to find the claims for the builder agent's most recent turn. The session can grow into the megabytes; scanning the full file is wasteful. - Prompt back when fixable. If verification fails AND you have a concrete corrective action, call
verifier_prompt(session_id=<BUILDER_SESSION_ID>, message=<concrete fix>)BEFORE emitting the Report. Be specific — exact paths, exact assertions, suggested fix. The corrective message goes back to the builder agent as a follow-up instruction, so the error feedback you give IS the documentation it learns from. - Escalate when stuck. If you cannot verify a claim — no oracle, no fixture, no harness, ambiguous claim — set
STATUS: unsureand explicitly state in the Report what you would need to verify it next time. Do NOT guess. The gap is the next thing the human templates. - Grade your confidence. After the
STATUS:line, emit aCONFIDENCE:line and anEVIDENCE_TIER:line. The grade encodes both completeness AND outcome — the operator's status bar reads this to color itself (green / orange / red). Pick the most accurate label from the ladder below. Be honest — false PERFECT is worse than honest PARTIAL. - End on the Report. After the
## Reportblock: stop. No further tool calls. No further prose.
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.
- 2d ago First seen · 103 lines · 41 tokens per session scan A 362b4fe959fd
verifier is an agent published in the GitHub repository AojdevStudio/hermes-satellite (2 stars, last pushed 10d ago), licensed MIT. It adds 41 tokens to every session and 1,722 once invoked, about $0.0002 per session on Opus 5. 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-31.
Other agents, from other repositories
task-agents
The primary agent workflow — inference setup resolution, the automation switch, evidence-first execution, tool policy, and the proposal/confirmation loop.
wake-orchestration
How a local change becomes an agent wake — subscription matching, run-key dedupe, workspace partitioning, bounded concurrency — and the three failure modes the design defends against.
templates-souls-evolution
What an agent does (template skills) versus who it is (soul personality), and the ritual loop that evolves both from user feedback.
overview
The persisted agent runtime — five agent kinds, their startup wiring, lifecycle, and the boundary against the AI inference stack.
Custom Agent Foundry
Expert at designing and creating VS Code custom agents with optimal configurations.
Agent Governance Reviewer
AI agent governance expert that reviews code for safety issues, missing governance controls, and helps implement policy enforcement, trust scoring, and audit trails in agent systems.