Skip to main content
A project can run one or more loops over its production traces. Harness evolution and Prompt evolution propose changes to what your agent runs and reads, gated on your review. LoRA finetuning trains a small model on your successful traffic; see LoRA finetuning. Loops are configured per project from Training → Loops → Make a loop, and a project can run several at once. Each loop takes a name of your own in the wizard.

Harness evolution and prompt evolution

Both loops start from your repo as it is today, and each example is one real trace: what your agent did, plus its outcome. The difference is what may be touched:
  • Prompt evolution changes only the scaffolding: system prompts, skills, instructions, memory files. Application logic is never edited.
  • Harness evolution can change the whole repo: prompts, tools, and code together.
Your agent is not run against live users; proposals are scored against recorded traces, and every proposed change cites the traces that motivated it.

Two designs

Each loop picks a design, the method that proposes changes, in the setup wizard’s Choose your approach step or with belvedir setup <project> --design loop1|loop2:
  • Loop 2 (diagnose and repair), the default: groups failing traces into failure modes, diagnoses each against your repository, and writes targeted fixes.
  • Loop 1 (GEPA): evolves candidates with GEPA’s evolutionary search.

Review before anything ships

By default nothing ships without you: proposals wait as per-file diffs under Training → History, and approving one opens the GitHub PR. Autonomy is set per loop in the setup wizard: Review first (the default) or Auto-PR to skip the gate.

Failure signals

What counts as a failing trace is a per-project choice of optimization signals: Errors (traces with failed LLM or tool calls), Latency (traces slower than 5 seconds end to end), and User frustration (users repeating themselves or correcting the agent). The setup wizard suggests signals from your improvement-target text; runs focus on traces matching the signals you select.

Repository access

To read your repo and open PRs, a loop needs GitHub access. Connect the Belvedir GitHub App from your account page; you choose which repositories the app may touch on GitHub’s own grant screen. Then, in Project Settings → Repository Access, pick the repos this project’s loops may use. Adding a repo is verified against your own GitHub access, and from then on it works for everyone on the project: teammates run loops and approve PRs without holding repo credentials (access is scoped to each run; nothing is stored). Revoke at any time by uninstalling the app or narrowing its repo selection on GitHub. The Harness access permission under Project Permissions turns repository access off for the whole project; see Data handling.