Skip to main content

The agent framework where nothing is done until a grader returns a verdict — verification + grounded perception (AgentVision eyes), compounding memory, a fleet, agent-built tooling, and agent-run CI/CD.

Project description

Verel — Verified Agents 👁️🧠

Verel — the agent framework where nothing is done until a grader returns a verdict

PyPI Docs tests lint MIT LLM

Problem: AI agents declare work “done” on their own say-so — shipping broken UIs, failing tests and unverified claims they can’t actually check. Result: Verel makes “done” a verdict, not an opinion — every action is graded by real senses (including eyes, via AgentVision), and only verified work compounds into the fleet’s shared memory.

Verel is an agent framework built on the idea that every agent action is a hypothesis:

write → perceive → gate (verdict bus) → fix → re-render → pass (self-computed)

One verdict bus unifies vision + tests + lint + types into a single pass / warn / fail, so progress, “done”, and what compounds are all decided in one place — with grader attestation so a hollow check can’t mint green.

See it in 15 seconds

A repo ships with failing tests and no hint of the fix. Verel runs the real grader, an agent patches the source (never the tests), and the stage re-gates until the graders themselves go green — the agent never decides "done", the verdict bus does:

verel heal — round 1 fails, an agent patches the source, round 2 passes

The 60-second pitch

pip install verel
verel doctor                 # check your environment
verel heal --repo .          # self-healing CI: failing tests → agent fixes → green
from verel.ci import inner_loop_stage, self_heal
result = self_heal(".", inner_loop_stage(".", with_lint=False))   # tests fail → agent patches → pass
print(result.healed, result.terminated_on)                        # True  passed

Default LLM is Ollama Cloud (~/.config/ollama/key, model qwen3-coder:480b); set VEREL_LLM_PROVIDER=openai to switch. Claude is one branch away in agents/llm.py.

New here? 5-minute tutorial →

Verel architecture — the five organs and the eval-driven loop

The five organs

Organ Module What it does
🧠 Brain verel.memory Memory that compounds — trust + provenance, consolidation, and a held-out, attested promotion gate. Only verified facts/skills graduate. Lifecycle controls (pin / volatile-until-confirmed / TTL / correction chains / adaptive decay — useful memories decay slower) keep it from becoming a junk drawer. Consolidation induces structured rules (condition→action), a multi-hop schema hierarchy (rules → principles → meta-principles), and cross-scope rules (a bug recurring across repos becomes a global rule) — and revises by contradiction: a rule a new failure violates is weakened, then split into a narrowed rule + an exception (or rejected) — and the split propagates up the schema hierarchy so principles above it stop over-claiming. A scope lattice (self → team → org → global) turns it into a shared brain: recall resolves down (the most specific scope wins), and a belief verified across sibling scopes graduates up as a candidate that must re-earn trust. A hosted memory service (MemoryServer/RemoteMemory) lets a fleet on different machines share one brain over HTTP — safely: a peer's belief enters as a candidate and re-verifies before it's trusted (import_belief), and author reputation (AuthorTrust) means a noisy agent's claims need more corroboration, so one bad actor can't poison the swarm. A librarian pass (the brain's "sleep") periodically consolidates, graduates, and prunes so it compounds without rotting. For HA, ReplicatedMemory runs the store as a leader-fenced, fault-tolerant cluster — one leader at a time, mutations replicate to followers (a dead follower can't block writes; a write_quorum sets durability), a deposed leader is fenced out (no split-brain, no SPOF), and a lagging node catches up — automatically, via a background anti-entropy reconciler that pulls the current leader's state. Backends: zero-dep LocalMemory or rented mem0; semantic recall + clustering via embeddings.
👁️ Eyes verel.senses AgentVision as a perception organ (DOM/contrast/OCR grounded) feeding both the verdict bus and the brain as one of many senses.
⚖️ Verdict bus verel.verdict One schema for every sense, with an advisory ceiling clamp, grader attestation, scrubbed fingerprints, and strict-subset stuck/progress detection.
🚁 Fleet verel.fleet Agents managing agents — an LLM manager fans out, a scheduler runs workers in isolated git worktrees under budget, each gated by the bus. Concurrent managers are safe via fencing leases (a stale leader's writes are rejected) — enforced even at the remote by a git pre-receive fencing sink (a stale push is refused), and across machines by a hosted control plane (lease authority behind an HTTP API). Multi-repo changes run as one cross-linked DAG and commit as an atomic saga (a failure compensates the repos that already landed, in reverse).
🔧 Tool-smith verel.toolsmith Agents build their own tools: detect → scaffold → test → register → reuse, sandboxed (bwrap), admitted only on a passing attested eval.
♻️ Agent-run CI/CD verel.ci Self-healing pipeline (inner-loop → pre-commit → pre-merge → canary) with a deterministic rollback engine that never acts on advisory evidence. Graders span Python / JS-TS / Go (tests · lint · types) plus perf (budget) and security (SAST/audit) senses — all on one bus, one gate.

Eyes & Brain — Verel × AgentVision

Two systems, one nervous system. AgentVision is the eyes; Verel is the brain. The eyes perceive a rendered artifact and grade it — including does it match what we set out to build? — then hand a clean signal up the optic nerve. The brain decides with grader attestation, acts, and only verified work compounds into memory. Then the eyes look again.

Eyes & Brain — AgentVision perceives and grades intent; Verel decides and compounds verified work into memory

They ship and version independently (pip install agentvision, pip install verel), but in sync: AgentVision's perception maps onto Verel's verdict bus as one grounded sense among many, and its intent conformance (matches_intent) is recorded in the brain's episodic memory every iteration. A full brain like Verel ingests the rich Report and runs its own gate; AgentVision's distilled Handoff is there for simpler brains. See AgentVision's handoff doc.

The eyes can also watch over timeverel.senses.watch(...) drives AgentVision's temporal verification (playback / loading / liveness for streaming UIs, video, live dashboards). A deterministic video stall gates the bus to FAIL, and playing / live / stabilized land in the brain's memory — so a release can be gated on verified playback, and "the player plays" compounds across builds.

What makes it trustworthy

  • Grader attestation — a required grader must present a signed run_receipt proving it ran the frozen suite over the changed files. A hollow PASS, issues=[] fails the gate.
  • Precise vs advisory — per-issue trust keys off the source (DOM/CV/OCR/test = precise; vision/LLM-judge = advisory, clamped to warn). Destructive actions (rollback) never depend on advisory evidence.
  • Only verified work compounds — a consolidated rule starts inferred and reaches verified only by passing a held-out, agent-inaccessible eval (with a leakage canary).
  • Dogfooded — Verel gates its own development with its own verdict bus (CI runs the pre-merge gate over Verel and asserts pass). The infographic above was rendered and verified by the eyes Verel ships.

Many faces, one core

Surface For
Library (import verel) Python apps & custom harnesses
CLI (verel …) doctor · loop · fleet · heal · ci
CI CLI / git hook (verel-ci, python -m verel.ci) agent-run CI, pre-commit gates
MCP server (verel-mcp) Cursor, Claude, any MCP host

Drop it into your workflow & your agents

CI gate (GitHub Action) — unify tests + lint + types into one verdict and fail the build:

# .github/workflows/verify.yml
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: amitpatole/verel@v0.25.0
        with:
          repo: .
          install: "-e .[dev]"     # your project deps so its tests import

pre-commit (this repo ships .pre-commit-hooks.yaml):

- repo: https://github.com/amitpatole/verel
  rev: v0.25.0
  hooks: [{ id: verel-precommit }]

Native git hook / any script:

verel-ci check --repo .       # verdict bus gate; non-zero exit on FAIL
verel-ci install --repo .     # wire a native pre-commit hook

In your agentsverel-mcp exposes the verdict bus + memory to any MCP host; the eyes (AgentVision) plug in as the sight sense. Add verel[sight] for visual gating, and verel.senses.watch(...) to gate on verified playback over time.

Try the demos

python examples/demo_selfheal.py         # failing tests → agent patches code → green
python examples/demo_overflow_loop.py    # fix a UI until AgentVision returns pass
python examples/demo_fleet_worktrees.py  # LLM manager fans out → isolated-worktree workers
python examples/demo_h2_moat.py          # measure cross-tenant skill transfer → moat decision
python examples/demo_canary_rollback.py  # bad merge fails canary → safe auto git-revert
python examples/demo_capability_jail.py  # learn a tool's syscalls → deny everything it didn't earn
python examples/demo_polyglot_ci.py      # Python/JS/Go + perf + security graders on one bus
python examples/demo_consolidation.py    # failures → structured rules → a 2nd-order schema
python examples/demo_shared_brain.py     # scope lattice — recall down self→team→org, graduate up
python examples/demo_distributed_fleet.py # concurrent managers (fencing) + multi-repo DAG
python examples/run_h2.py                # LIVE: build skills, measure cross-tenant transfer
python examples/run_h2_sweep.py          # LIVE: sweep the transfer measurement across models
python examples/demo_hosted_registry.py  # publish a skill over HTTP; another tenant re-verifies

Honesty (what we do not claim)

  • The in-process tool guard is a guardrail, not a sandbox — real isolation is the bwrap container runner (isolation="container"): no network, read-only system-only fs, ephemeral tmp, cleared env, and a seccomp-bpf syscall filter (verel[container]). Three profiles, weakest→strongest: denylist (default; EPERM on ptrace/mount/raw-socket/namespace/module/bpf — safe for arbitrary tools), allowlist (default-deny, only what a pure-compute CPython needs — no network, subprocess, or threads), and capability — the tightest: a tool may use only the syscalls it exercised while passing its held-out eval (learned via strace), so anything it never earned — including a syscall the allow-list would permit — is refused at the kernel.
  • The moat (a public verified-skill registry) is a bet we measure, not assume — the H2 experiment (verel.registry) re-verifies live-built skills against other tenants' held-out cases. A two-model sweep (Ollama qwen3-coder:480b and OpenAI gpt-4o-mini, 12 skills × 4 tenants) measured ~88–89% transfer → BUILD on both (results): universal skills transfer 100%, tenant-specific ones only where the rule matches. The decision is swept across models, not taken from one run — and the registry it justifies now ships (RegistryServer/RemoteRegistry): a fetched skill is a candidate until the importer's own eval passes, so distribution moves bytes, never a verdict.
  • Advisory (vision/LLM) findings are advisory; they inform, they don’t gate destructive acts.

Documentation

📖 Full docs site: amitpatole.github.io/verel

License

MIT © Amit Patole · eyes by AgentVision

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

verel-0.25.0.tar.gz (310.9 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

verel-0.25.0-py3-none-any.whl (149.2 kB view details)

Uploaded Python 3

File details

Details for the file verel-0.25.0.tar.gz.

File metadata

  • Download URL: verel-0.25.0.tar.gz
  • Upload date:
  • Size: 310.9 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: uv/0.11.21 {"installer":{"name":"uv","version":"0.11.21","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Rocky Linux","version":"9.5","id":null,"libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":null}

File hashes

Hashes for verel-0.25.0.tar.gz
Algorithm Hash digest
SHA256 e70eacfb5bdde9b71ea440ddb2c288e84be55c809943585051384c4e64f21dc6
MD5 cf44cca6d9db732b890c0ca750140440
BLAKE2b-256 60130b7780d0e9f1d87a25e647033a3761ad591af01d8a4dcefc6b143222a2ce

See more details on using hashes here.

File details

Details for the file verel-0.25.0-py3-none-any.whl.

File metadata

  • Download URL: verel-0.25.0-py3-none-any.whl
  • Upload date:
  • Size: 149.2 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? No
  • Uploaded via: uv/0.11.21 {"installer":{"name":"uv","version":"0.11.21","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Rocky Linux","version":"9.5","id":null,"libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":null}

File hashes

Hashes for verel-0.25.0-py3-none-any.whl
Algorithm Hash digest
SHA256 30e446a09538bb6aaa8fabf5ff17420c1c27d033645c94c5815a8cf0b9c2d3db
MD5 f8f9da75ff2581b14a0bff2734255e28
BLAKE2b-256 01424bf798f709f95fa68c09859075233295d17b6d3462e1ef80eabe024c09ca

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page