Skip to main content
Observability is the first half of Belvedir; the second half is closing the loop. Every project can run one or more improvement loops that feed on the same production traces: Harness evolution and Prompt evolution rewrite what your agent runs and reads, and LoRA finetuning distills your best traffic into a small model’s weights. All of them end back in production, producing better traces.

​
Types of training

Each loop evolves a different layer of your agent against its own production traces:
  • Prompt evolution: a recursive self-improvement loop over what your agent is told and remembers (system prompts, skills, instructions, memory files), never its application logic. Production sessions show what it misses and should have remembered; the loop distills that back into the scaffolding.
  • Harness evolution: the same loop with the whole harness on the table: prompts, tools, and code all improve together, opening a PR with the winner.
  • LoRA finetuning: train lightweight LoRA adapters on your traces instead of touching the full weights: cheap to run, quick to iterate, and swappable per task type, on top of the supported open base models. See Model Training.
Loops are configured per project from the Training section (Training → Loops → Make a loop), and a project can run several at once. Harness evolution, Prompt evolution, and LoRA finetuning are the loop types; each loop you make takes a name of your own in the wizard.

​
Harness evolution & prompt evolution: two designs

Both loops start from your repo exactly as it is today (the “seed”); each dataset example is one real trace: the transcript of what your agent actually did, plus its outcome. The difference between the two loops is what may be touched: Harness evolution can edit the whole repo, while Prompt evolution is constrained to scaffolding (prompts, skills, memory files, instructions), so it improves what the agent is told and remembers, never its application logic. Each project also picks a design: the algorithm that proposes changes. Loop 2 is the default; Loop 1 (GEPA) is the original design. Pick it in the setup wizard’s approach step, or with belvedir setup <project> --design loop1|loop2.

​
Loop 2 (default): diagnose and repair

Loop 2 works the way an engineer would: triage the failing traces into failure modes, diagnose each one’s root cause against the relevant repository files (reading a structured step graph of each trace, not just the transcript), and write one targeted patch per failure mode with checkable fix criteria. It can create new files (skills, memory) outright, remembers what earlier runs shipped or had rejected, and every proposed change cites the traces that motivated it.

​
Loop 1: GEPA

Loop 1 runs GEPA (Genetic-Pareto), an evolutionary optimizer: natural-language reflection rewrites one file at a time and a diverse pool of variants competes across traces.
The scoring trick is shared by both designs and is what makes this work without re-running your agent: unchanged code is graded by what actually happened, and each proposed edit is graded by a judge reasoning about whether it would have prevented the failures visible in the transcript. Failing traces are deliberately over-sampled so there is always something to win. By default nothing ships without you: proposals wait as per-file diffs on Training History, and approving opens the GitHub PR. Each loop has its own autonomy, set in the Training section’s setup wizard. Switch a loop to Auto-PR to skip the gate.

​
Failure signals & repo access

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 training setup wizard suggests signals from your improvement-target text; the optimizer over-samples traces matching the selected signals and scores its baseline against the same definitions. To read your repo and open PRs, the optimizer needs GitHub access. Connect the Belvedir GitHub App from Account settings → Integrations. You choose exactly which repositories the app may touch (all of a namespace, or hand-picked ones; GitHub’s own grant screen). Then, in Project settings → Repository access, pick the repos this project’s loops may use from your connected accounts. Adding a repo is verified against your GitHub access, and from then on it works for everyone on the project: teammates run loops and approve PRs through Belvedir without ever holding repo credentials (the platform mints short-lived tokens per run; nothing is stored). You can revoke at any time by uninstalling the app or narrowing its repo selection on GitHub.

​
One skeleton

Every loop shares one skeleton: propose a variant, score it against reality, keep the winner. The optimization loops’ variants are text scored against past traces; the model loop’s variants are weights scored by harness runs. Auto-training can keep the model loop turning on its own, retraining after every N new traces or on a schedule.