Prompt optimization

Fitting the prompt instead of writing it. You supply a program, a set of examples and a metric; a search procedure rewrites the instructions and the few-shot demonstrations until the metric stops improving. The prompt stops being authored text and becomes a fitted parameter — the thing that changes when you change models, while the code stays put.

Paged 2026-08-20 when dspy and awesome-prompts arrived together and made the corner nameable. It had been showing up here in pieces for months: the "GEPA + DSPy" loop awesome-hermes-usecases found under hermes-agent's self-improvement claim, the DSPy baseline meaning-typed-programming benchmarks against. Those were the same mechanism seen from two sides.

The families

Sorted by what the search is allowed to move, which is the axis that actually separates them:

Demonstrations. Run the program on training examples, keep the traces that scored well, paste them back in as few-shot examples. DSPy's BootstrapFewShot and BootstrapRS; the cheapest thing that works, and the one that needs no model to do the rewriting.
Instructions. Search over the wording of the instruction itself — propose candidates, score them, keep the winners. COPRO, and MIPROv2 which does instructions and demonstrations jointly across a multi-stage program (arXiv 2406.11695).
Reflective evolution. A model reads the failures, writes a diagnosis in natural language, and mutates the prompt from it. GEPA (arXiv 2507.19457) is the named instance, and its title is the claim: "Reflective Prompt Evolution Can Outperform Reinforcement Learning."
Textual gradients. Treat the critic model's feedback as a gradient and backpropagate it through a pipeline of calls — TextGrad, published in Nature, catalogued by awesome-prompts and not yet paged here.
Prompt and weights together. BootstrapFinetune and BetterTogether optimize the prompt and fine-tune the model in the same loop, on the argument that the two steps interact (arXiv 2407.10930).

The first three are all in dspy's thirteen shipped optimizers, which is why that repo is the corner's centre of gravity rather than one entry in it.

Why it lands in this spoke and not one layer down

An optimizer is not a prompting technique. It is infrastructure for building the agent — a compile step in the toolchain, which is what this spoke covers. The corner also closes a loop the spoke already had open at the top: self-improving-agents describes agents that refine their own capabilities, and until now the only mechanism recorded for that was an agent writing skill files for itself. Prompt optimization is the second mechanism, and the one with published algorithms behind it. hermes-agent is the corpus's proof that a shipping product uses it.

The measurement is real and it does not answer the question

This spoke's standing complaint — restated most sharply on the agent-framework page — is that nobody measures the tooling. Prompt optimization is the one corner where a number is definitionally unavoidable: no metric, no optimizer. You cannot run it and skip the evaluation step (agent-evals).

That is less than it sounds. The optimizer's reported gain is measured against its own starting prompt, on a metric its operator chose, over examples its operator supplied. It is evidence that search beat the seed prompt. It is not evidence that the framework beats a competent human writing the prompt by hand, and none of the sources here run that comparison — the same hole, in the one place that has the instrument to fill it.

There is a reason to expect the hand-written baseline to be weak, and it is already in this corpus. cc-thinking-skills and context-files-ablation-paper ran controls on hand-authored structure and found process effects without correctness effects; reasoning-scaffolds carries the negative result for prescribing how a model should think. If authored scaffolding mostly does not move correctness, an optimizer that ignores authorship entirely and fits to a score is attacking the problem from the side the evidence favours. That is an argument for the approach, not a measurement of it.

Against the corner

The metric is the whole design. Choosing it is the hard part and the optimizer does not help with it; a fitted prompt is exactly as good as the scoring function, and a bad metric buys a confidently overfitted prompt.
It needs labelled examples. Most of what this spoke pages — harnesses, skillpacks, coding agents — runs on tasks with no training set and no scorable outcome.
The artifact becomes unreadable. An optimized prompt is generated text nobody reviewed, which sits badly next to claude-md and agents-md, whose stated discipline is small, universal and hand-authored. The corner trades a reviewable artifact for a scored one.
It moves cost to build time. A compile pass is many model calls before anything ships — the inverse of the deterministic-review-gate trade, where a model runs once at rule-generation time and never again, but with a bill instead of a linter at the end.

Distinct from neighbours

vs. prompt compression / pruning (safe-prompt-pruning, headroom) — those shrink a prompt that already exists to fit a budget. This one rewrites it to raise a score. Both edit the prompt automatically; only one is trying to make it better, and the directories conflate them (llm-engineer-toolkit files dspy in the same nine-entry category as LLMLingua).
vs. structured generation (Guidance, LMQL, byllm) — constraining what the model may emit, not searching for what to ask. meaning-typed-programming's answer to DSPy is from this side: make the prompt disappear into the type system rather than optimize it.
vs. loop-engineering — designing the agent's iteration and stop condition. That is the loop around the call; this is the content of the call.

dspy · awesome-prompts · hermes-agent · awesome-hermes-usecases · meaning-typed-programming · self-improving-agents · agent-evals · agent-framework · reasoning-scaffolds · safe-prompt-pruning · loop-engineering