Agents often fail because their instructions, planning, tool guidance, and context are weak, even when the underlying model is capable.
2
Prompt learning uses evaluator scores together with written explanations from humans or LLM judges to improve system instructions over repeated runs.
3
A train-test loop can produce better prompts without fine-tuning, tool changes, or architecture changes, but its results depend on the quality of the evaluators.
Summary
SallyAnn DeLucia and Fuad Ali explain a feedback loop for improving prompts used by AI agents. They argue that many failures come from weak system instructions, limited planning, missing tools, poor tool guidance, and incomplete context. Prompt learning combines evaluation labels with written explanations of why an answer failed, then gives that feedback to an LLM that proposes revised instructions. In their coding-agent example, adding engineering rules to a system prompt improved performance by 15%, with no fine-tuning, tool changes, or architecture changes. The workshop builds a JSON webpage example using OpenAI, binary and rule-based evaluators, a train-test split, and repeated optimization loops. The speakers also describe a second loop for improving the evaluators themselves. Their practical advice is to start with a scrappy agent, use an off-the-shelf evaluator if needed, and refine both the agent prompt and evaluation prompts as failures accumulate.
Agent failures often come from weak instructions and missing context
SallyAnn DeLucia says agents frequently break because the environment and instructions are weak, rather than because the model is weak. Common problems include having no learned system instructions, no planning, or only a rigid plan. Agents may also lack the required tools or guidance about which tool to choose. Context engineering is another recurring problem, especially when the model lacks relevant data or cannot confirm the information it receives. She groups these issues around adaptability, planning, and context. Her examples include Claude Code and Cursor, which she describes as stronger examples of planning that have not yet become common across all agents.
Prompt learning adds written failure explanations to evaluation scores
The speakers distinguish prompt learning from reinforcement learning and metaprompting. Reinforcement learning updates model weights from scalar rewards, which they say is difficult to apply directly to LLM prompting. Metaprompting asks an LLM to improve a prompt from evaluation results. Prompt learning gives that LLM richer feedback: which answers were wrong, why they were wrong, and where the student needs to study. The feedback can come from subject matter experts or an LLM judge. The optimizer then changes the system prompt using both labels and explanations, rather than optimizing only a score or looking only at the output.
Human instructions and judge explanations provide useful text for optimization
Traditional prompt optimization treats the task like a prediction problem with data and a prompt. SallyAnn DeLucia says this misses the useful information contained in explanations. A subject matter expert might write that an answer failed to follow a specific instruction or lacked required context. An LLM judge can provide similar reasoning. Prompt learning points the optimizer toward the exact instructions that need changing. The speakers' claim is that this text gives direct guidance about how to improve, because it describes the failure in the same language domain in which the application operates.
Adding explicit engineering rules improved a coding agent without changing its architecture
In a coding-agent case study, the initial system prompt identified the agent and its coding task but had no rules section. The revised prompt added instructions for handling errors and exceptions, keeping changes aligned with the system design, and adding appropriate tests. The updated system prompt produced better results. SallyAnn DeLucia reports a 15% improvement on a coding benchmark from adding rules alone. She says the change involved no fine-tuning, tool changes, or architecture changes. She also says the 4.1 model reached performance near 4.5 while costing two-thirds as much in their comparison.
Prompt optimization should build application-specific expertise over time
The speakers address the concern that training on failed examples could overfit the prompt. Their approach uses a train-test split and favors reusable coding standards over fixes for individual repository quirks. They also describe application-specific fitting as expertise: an engineer should learn the codebase they work on instead of remaining completely general. Prompt learning is intended to run repeatedly as new failures appear. The prompt can then adapt to the application's current problems. For multi-agent systems, they currently optimize specialized agent tasks separately, while testing the full interaction remains a separate concern.
Evaluator quality determines whether the agent loop can be trusted
Prompt learning depends on reliable evaluation feedback. The speakers advise improving evaluator prompts alongside agent prompts when evaluator outputs provide the optimization signal. Their evaluation loop collects cases where the evaluator is uncertain or wrong, then uses annotations and confidence information to revise the evaluator. They describe this as a pair of co-evolving loops: one improves the agent from failures, and the other improves the evaluator from evaluator failures. Their warning is direct: the agent loop works only as well as its evaluation. A score without a trustworthy explanation can send optimization in the wrong direction.
Success criteria can be turned into evaluations for subjective tasks
For tasks that are harder to quantify than coding, the speakers recommend gathering the relevant stakeholders and defining what success means before converting those criteria into evaluations. For an agent, this might include finding the right data, making the right tool call, calling tools in the right order, or producing a correct plan. They also discuss a subjective property-listing example from Booking.com. A team can begin with a good-or-bad judgment about a property image, then use accumulated feedback to refine the evaluator with reasons such as dim lighting or an unsuitable room layout. Binary judgments can become more detailed as signal improves.
The workshop loop generates, evaluates, and refines prompts on a train-test split
The workshop uses a JSON webpage example with a data set of queries, outputs, and feedback. The configuration includes the sample size, train split, number of rules, and number of optimization loops. The code generates outputs from the current system prompt, evaluates them on test data, and, when results are unsatisfactory, uses training outputs and feedback to create a revised prompt. The evaluators return correctness labels, explanations, and rule violations. The loop records accuracy, prompts, and raw results, then stops when it reaches a target score or exhausts the configured iterations. The best prompt is extracted from the saved results.
