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 that uses GEPA (Genetic-Pareto) to evolve 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 GEPA loop with the whole harness on the table: prompts, tools, and code all evolve together. Natural-language reflection samples execution paths, diagnoses issues, and synthesizes improvements from the Pareto frontier of its own attempts, 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 any open base model. 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 (GEPA)

Both loops run GEPA, an evolutionary optimizer. The starting point (the “seed”) is your repo exactly as it is today; each dataset example is one real trace: the transcript of what your agent actually did, plus its outcome. The only difference between the two loops is what GEPA is allowed to touch: 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.
The scoring trick 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 New Project form 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. GEPA’s 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.